rcd@ico.isc.com (Dick Dunn) (02/23/91)
flint@gistdev.gist.com (Flint Pellett) writes: > cpcahil@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@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...But is it art?
richard@pegasus.com (Richard Foulk) (03/01/91)
>> 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". Given the egregiousness of the bug in question it would seem quite reasonable for someone at ISC to make such an effort. To assume that AT&T wouldn't allow the public distribution of otherwise useless binaries or parts of binaries seems a little incredible. I'm not convinced that ISC's existing license with AT&T specifically disallows this, or that they wouldn't allow it after a simple phone call. There may be other over-riding reasons why posting fixes to the net is not workable -- but, please don't try to advance your argument by piling it high with ridiculous BS like this. One begins to wonder if ISC's motto isn't something like: `Well, it probably can't be done ... and I'm too busy to check'
rcd@ico.isc.com (Dick Dunn) (03/02/91)
See richard@pegasus.com (Richard Foulk)'s article for the disagreement. Here, I'd just like to point out a couple of facts. First, I have no idea whether anyone in ISC did contact AT&T, or consider contacting them, asking for permission to post a fix. I'm not in a place to know all they've considered or attempted. I was only expressing *my* personal opinion that there were sound reasons to think that might not be an expedient approach. Second, in response to Richard's conclusion: > One begins to wonder if ISC's motto isn't something like: > > `Well, it probably can't be done ... and I'm too busy to check' ...I would like to emphasize that I do not speak for ISC. I am not in Support, nor affiliated with it. Neither am I in the Product group. I'm not even in Santa Monica where the product work is done. Therefore, if you feel Richard's "motto" is an appropriate reaction to what I posted, please apply it to me personally, not to ISC as a whole. It is a reaction to my opinions, not ISC's. -- Dick Dunn rcd@ico.isc.com -or- ico!rcd Boulder, CO (303)449-2870 ...But is it art?
werme@Alliant.COM (Ric Werme) (03/05/91)
In article <1991Mar1.155948.23736@pegasus.com> richard@pegasus.com (Richard Foulk) writes: >Given the egregiousness of the bug in question it would seem quite >reasonable for someone at ISC to make such an effort. [to get permission to post AT&T source code.] Given the egregious nature of this bug and that it came from an AT&T release, it would seem quite reasonable for AT&T to post an apology and their fix. Of course, it probably wouldn't work on ISC's code, but it could provide a basis for a fix ISC could post. I wonder if AT&T is embarassed at all. Given all the flames directed at ISC, I'm surprised people haven't flamed AT&T. Maybe they have means to detect such messages sent over AT&T lines.... -- | A pride of lions | Eric J Werme | | A gaggle of geese | uucp: mit-eddie!alliant!werme | | An odd lot of programmers | Phone: 508-486-1214 |
jca@pnet01.cts.com (John C. Archambeau) (03/07/91)
werme@Alliant.COM (Ric Werme) writes: >In article <1991Mar1.155948.23736@pegasus.com> richard@pegasus.com (Richard Foulk) writes: >>Given the egregiousness of the bug in question it would seem quite >>reasonable for someone at ISC to make such an effort. > >[to get permission to post AT&T source code.] > >Given the egregious nature of this bug and that it came from an AT&T release, >it would seem quite reasonable for AT&T to post an apology and their fix. >Of course, it probably wouldn't work on ISC's code, but it could provide >a basis for a fix ISC could post. > >I wonder if AT&T is embarassed at all. > >Given all the flames directed at ISC, I'm surprised people haven't flamed >AT&T. Maybe they have means to detect such messages sent over AT&T lines.... AT&T fixed the bug. So it's not AT&T's fault per se. ISC just licensed the code that had the bug. Now this can be remotely understandable with ISC 2.0.2, but 2.2.x? // JCA /* **--------------------------------------------------------------------------* ** Flames : /dev/null | What to buy? ** ARPANET : crash!pnet01!jca@nosc.mil | EISA or MCA? ** INTERNET: jca@pnet01.cts.com | When will the bus wars end? ** UUCP : {nosc ucsd hplabs!hp-sdd}!crash!pnet01!jca **--------------------------------------------------------------------------* */
ts@cup.portal.com (Tim W Smith) (03/13/91)
< AT&T fixed the bug. So it's not AT&T's fault per se. ISC just licensed the < code that had the bug. Now this can be remotely understandable with ISC < 2.0.2, but 2.2.x? I believe that in fact ISC only has object code from AT&T for the code in question. To fix the bug properly would require reverse engineering the floating point emulator. If they had decided to do that, you would probably still be waiting for the bug fix. Instead, they had to come up with some other solution - a patch, I would guess. Tim Smith