att & osf

[Henry Spencer]

In article <2998 at homxc.UUCP> dwc at homxc.UUCP (Malaclypse the Elder) writes:
>> I could be wrong, but my impression is that one of the Consent Decrees
>> required licensing on reasonable terms to all comers.  I know of at
>> least one occasion when lawsuits were being considered over possible
>> refusal to release technology (although of course that may just mean
>> that the potential plaintiffs were going to try it on speculation).
>> 
>i also believe that we were under no obligation to provide our
>developed technologies...

I now have slightly more specific information on this.  The Consent Decree
of 1956 specifically required licensing of patents -- no ifs, buts, or
maybes.  However, it did not touch on non-patented stuff to any extent,
and in particular, except for (presumably) the setuid patent, it did not
mandate release of Unix.  It would appear that the lawsuits I heard about
were indeed on speculation; since they never materialized there's no way
to be sure how they would have turned out.

>> ... when are they going to fix the NULL-pointer bugs?
>> 
>is this really a portability issue or is this an issue of supporting
>a base of applications out there that dereferences NULLs?  are you
>confusing application portability with operating system portability?

I am speaking of portability of Unix, i.e. the kernel AND THE UTILITIES.
As at least one would-be lookalike builder has discovered, the hard part
about duplicating Unix is the utilities, not the kernel.  And at least
the older System V utilities deferenced a lot of NULL pointers.

>> Many people see this as a major conflict of interest for AT&T; how can
>> it remain the paragon of evenhandedness that you claim it is, when it has
>> climbed into bed with one manufacturer to the exclusion of the others?
>> 
>there is only a conflict of interest if one believes that a particular
>hardware architecture can really affect a specification for a user/programmer
>interface...

Well, actually, it can in various ways.  To take a small example, consider
the vile botch in System V interprocess communication of using -1 (rather
than 0) cast to a pointer as an error return code.  That is *not* portable,
but it happens to work on certain architectures.

If you want another example, see the above:  AT&T operated for quite a while
with "it is safe to dereference a NULL pointer" as an implicit part of their
programming interface.

There is also an apparent conflict of interest over more than just the final
shape of the specs.  Little things like "when do others get to see the specs?"
and "do others have any say in the specs?" are not trivial issues either.
-- 
Intel CPUs are not defective,  |     Henry Spencer at U of Toronto Zoology
they just act that way.        | uunet!attcan!utzoo!henry henry at zoo.toronto.edu