posting fixes, license, and the u-area bug
Dick Dunn
rcd at ico.isc.com
Sat Feb 23 19:00:50 AEST 1991
flint at gistdev.gist.com (Flint Pellett) writes:
> cpcahil at virtech.uucp (Conor P. Cahill) writes:
> >This will take time. I too thought posting the fix would be appropriate, but
> >if there is a licensing agreement that stands in the way, there is nothing that
> >ISC can do about it.
>
> Wrong. ISC can go to AT&T and say "Please give us permission to
> violate the licensing agreement and post this fix."...
#ifndef reality
Wait...OK, I get it! Marty should just spend a little of her copious free
time, or perhaps do it on her lunch hour...just drop by the local AT&T
office and have a friendly chat, say "By the way, we've got this little
problem, so would you folks mind if we posted, oh, say a couple hundred Kb
of the code we license from you?" I'm sure AT&T won't mind if we say
"pretty please".
#else
Folks, I really *do*not* intend to be snide. But let's keep some per-
spective here.
- Even if no other considerations applied, and even if the
corrected code applied to os.o alone, it would require a quarter
meg of code. A posting has to be done in 7-bit, so normal tools
will expand this to a third of a meg. A posting that large is
rude, crude, and socially unacceptable to the point of overt
hostility.
- ISC is not small, but AT&T has more lawyers than ISC has
employees. Even if approval could be granted, it would take
far longer than it will take for ISC to put out a fix. You DO
NOT just go ask a complicated question with various contractual
implications of a large organization and get a quick answer.
The time to answer such questions is measured in months.
- AT&T is serious about its "intellectual property rights" in the
broad sense. I assume you folks have seen the postings regarding
AT&T contacting commercial members of the X consortium for roy-
alties on using backing store? Think about it.
#endif
--
Dick Dunn rcd at ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870
...But is it art?
More information about the Comp.unix.sysv386
mailing list