Dear FreeBSD hackers,

I've hear rumors that the source code for SCO UnixWare 2.1.x
is now available from SCO for $500 for educational
institutions.

Isn't this interesting as a reference? How do you think?

Best regards,
Andrew Stesin

nic-hdl: ST73-RIPE

>Dear FreeBSD hackers,
>
>I've hear rumors that the source code for SCO UnixWare 2.1.x
>is now available from SCO for $500 for educational
>institutions.
>
>Isn't this interesting as a reference? How do you think?

I have worked on the SVR4 codebase, and there isn't much
to be learned there. The Solaris stuff would be a little
bit more interesting. :-).

John

On Fri, 25 Jul 1997, John S. Dyson wrote:

>I have worked on the SVR4 codebase, and there isn't much
>to be learned there. The Solaris stuff would be a little
>bit more interesting. :-).

Solaris source is also available for interested, isn't it?

On UW. Solaris is SVR4.0 heavily modified by Sun,
with SMP added by them independently; UW is SVR4.2 with
SMP added by USL, am I right? So they might have
some (in theory, at least) interesting differences with regard to
SMP implementation?

Then VXFS; binary compatibility stuff; drivers.

SCO is dropping old SCO OpenServer aka SVR3,
in favor of SVR4.2MP-based system, I think; for now it's UW.
And they have some kind of "unified driver interface" spec for UW.
How nice would it be -- to have an ability to use hardware
vendor's own drivers for UW, compatible with that spec,
just out of the box. Aaghh, dreams, dreams... :(

>John

Best regards,
Andrew Stesin

nic-hdl: ST73-RIPE

Hi Andrew Stesin; On 25-Jul-97 you wrote:

>Dear FreeBSD hackers,
>
>I've hear rumors that the source code for SCO UnixWare 2.1.x
>is now available from SCO for $500 for educational
>institutions.
>
>Isn't this interesting as a reference? How do you think?

It has a descent SMP implementation (Better than Solaris).
The SCSI layer may be interesting.
Used to have a nice desktop for X11

Simon

>>I've hear rumors that the source code for SCO UnixWare 2.1.x
>>is now available from SCO for $500 for educational
>>institutions.

>>Isn't this interesting as a reference? How do you think?
>I have worked on the SVR4 codebase, and there isn't much
>to be learned there. The Solaris stuff would be a little
>bit more interesting. :-).

The VM code is nearly identical, for what it's worth. It was part
of the technology trade between Sun and USL.

I believe the FS SMP locking in Solaris is actually done at the
wrong level. The SVR4 ES/MP 4.0.2 based SMP code from Unisys
did it the right way. The SVR4 code in UnixWare 2.x used the
Sun model (with a bit fewer macro encapsulations; the Sun
implementation is more aesthetically pleasing), which makes it
hard to use SMP unsafe FS's on Solaris (making it a bugger to
incrementally transition code).

Terry Lambert
ter...@lambert.org---
Any opinions in this posting are my own and not those of my present
or previous employers.

>On UW. Solaris is SVR4.0 heavily modified by Sun,
> with SMP added by them independently; UW is SVR4.2 with
> SMP added by USL, am I right? So they might have
> some (in theory, at least) interesting differences with regard to
> SMP implementation?

Not as much as you'd imagine. It's basically differences in wrapping,
more than anything else (ie: cosmetic).

> Then VXFS; binary compatibility stuff; drivers.

The VXFS belongs to Veritas, and is not relicensed. For what that's
worth, all of the VXFS directory code is USL UFS derived (and it has
USL copyright notices all over it).

The binary compatability stuff is... "different".

With the exception of enabling alrentate processor instruction sets
in Solaris implementation (it uses an external program to do the
deed for SunOS compatability), they are nearly identical. The x86
stuff is about the same (both have SCO and Microsoft copyrights
all over the place).

All in all, I would say it is inferior to either BSD approach that
is out there; the instruction set stuff can be handled rather easily
on BSD by trapping at the system call level (at least for BSD's
that didn't follow Linux's lead on register paramter passing to
system calls, making the ABI dependent on wordsize). Basically,
it's no different than deciding to load an "interpreter". The
program mmap's the executable into it's address space as data,
and then "executes" the code via simulation. For system calls,
the conversion from the emulated to the local is rather trivial
(there are a number of issues regarding non-native x86 binaries
being run on non-x86 architectures; they require either duping
the system call conversion glue for the execution class in the
user space simulator, or seperate simulators to invoke seperate
system call lists still in the kernel).

> SCO is dropping old SCO OpenServer aka SVR3,
> in favor of SVR4.2MP-based system, I think; for now it's UW.
> And they have some kind of "unified driver interface" spec for UW.
> How nice would it be -- to have an ability to use hardware
> vendor's own drivers for UW, compatible with that spec,
> just out of the box. Aaghh, dreams, dreams... :(

The net drivers are ODI. The ODI spec is available from Novell
(if they think you are a card vendor) or from USU via anonymous
FTP off their NetWare archive.

Personally, I would not recommend using ODI; the ODI drivers lost
8-15% (depending on the card) over the native UNIX drivers they
replaced. In addition, they added a streams stack transition
(not an issue for BSD, I know) for inbound packet puts, which
added an additional 7% latency. This was determined using formal
testing methods, in Novell labs.

Regards,
Terry Lambert
ter...@lambert.org---
Any opinions in this posting are my own and not those of my present
or previous employers.

[ ... UnixWare ... ]

>It has a descent SMP implementation (Better than Solaris).
>The SCSI layer may be interesting.
>Used to have a nice desktop for X11

Ugh.

The SMP implementation *is* "better"... quoted because it is more
x86 dependent tha the Solaris stuff. Personally, I'd use the
Solaris model, if only for hardware compatability, if I had the
choice to make, and if doing so would not infringe trade secrets
and copyrights, and risk contamination. Remember that both these
source bases are *licensed*, not freely usable.

The UnixWare SCSI layer probably excludes the HIM-derived code for
the Adaptec controllers, which is about the only thing that I found
interesting about the code. Honestly, Julian's code was better
than UnixWare's at the time.

The X11 desktop was only nice in that it was an OpenLook with hacks
to let it have a Motif "look and feel", and let you switch between
them. Like all compromise soloutions, it was vastly disliked.

The major reason the desktop was shipped was "Not Invented Here"
for CDE and Visix Looking Glass.

This type of crap is why UnixWare never succeeded in the desktop
market.

Most of the driving forces behind the UnixWare developement, which
mainly occurred at Univel, a partnership between AT&T and Novell,
before Novell bought USL and owned it all themselves, were people
like Gary Tomlinson and Brian Sparks.

If that second name is familiar, it should be: Brian Sparks was
the person behind the original NetWare for UNIX product, and
through it, the genesis of the Platform Independent NetWare
code (a derivitive of his idea, not something he personally did;
it was, IMO, inferior to the NetWare for UNIX code in many ways,
and ended up being pulled into the mainline NetWare -- an unfortunate
occurance).

Brian Sparks is also the guy behind the Novell project to build
a desktop OS based on Linux (internally, they were called "Linivel"),
and eventually went on to be the principle founder of Caldera
when the internal project was killed for fear of it damaging
UnixWare sales (UnixWare has a rather large footprint).

The shitty UnixWare desktop that could not be replaced because
it was USL technology was IMO, one of the straws that broke the
camels back; I would not recommend getting the code... let it die
in peace.

Regards,
Terry Lambert
ter...@lambert.org---
Any opinions in this posting are my own and not those of my present
or previous employers.

I basically agree with the below comments. The SMP code was derived
(according to legend) from Sequent work and therfore should be interesting.

The only thing I liked about the desktop was the desktop itself (the class
of functionality comparable to xfm). The rest of it was, well... Let it
rest in peace indeed.

I worked mostly on I/O, boot and other such messes and was endlessly amused
at the number of lines of code everything took.

I honestly (as a newcomer to FreeBSD), think we have here a superior O/S.
Much lower level of pompousness, in any case... Much lower.

Simon

Hi Terry Lambert; On 26-Jul-97 you wrote:
>>[ ... UnixWare ... ]
>
>>It has a descent SMP implementation (Better than Solaris).
>>The SCSI layer may be interesting.
>>Used to have a nice desktop for X11
>
>Ugh.
>
>The SMP implementation *is* "better"... quoted because it is more
>x86 dependent tha the Solaris stuff. Personally, I'd use the
>Solaris model, if only for hardware compatability, if I had the
>choice to make, and if doing so would not infringe trade secrets
>and copyrights, and risk contamination. Remember that both these
>source bases are *licensed*, not freely usable.
>
>The UnixWare SCSI layer probably excludes the HIM-derived code for
>the Adaptec controllers, which is about the only thing that I found
>interesting about the code. Honestly, Julian's code was better
>than UnixWare's at the time.
>
>The X11 desktop was only nice in that it was an OpenLook with hacks
>to let it have a Motif "look and feel", and let you switch between
>them. Like all compromise soloutions, it was vastly disliked.
>
>The major reason the desktop was shipped was "Not Invented Here"
>for CDE and Visix Looking Glass.
>
>This type of crap is why UnixWare never succeeded in the desktop
>market.
>
>Most of the driving forces behind the UnixWare developement, which
>mainly occurred at Univel, a partnership between AT&T and Novell,
>before Novell bought USL and owned it all themselves, were people
>like Gary Tomlinson and Brian Sparks.
>
>If that second name is familiar, it should be: Brian Sparks was
>the person behind the original NetWare for UNIX product, and
>through it, the genesis of the Platform Independent NetWare
>code (a derivitive of his idea, not something he personally did;
>it was, IMO, inferior to the NetWare for UNIX code in many ways,
>and ended up being pulled into the mainline NetWare -- an unfortunate
>occurance).
>
>Brian Sparks is also the guy behind the Novell project to build
>a desktop OS based on Linux (internally, they were called "Linivel"),
>and eventually went on to be the principle founder of Caldera
>when the internal project was killed for fear of it damaging
>UnixWare sales (UnixWare has a rather large footprint).
>
>The shitty UnixWare desktop that could not be replaced because
>it was USL technology was IMO, one of the straws that broke the
>camels back; I would not recommend getting the code... let it die
>in peace.
>
> Regards,
> Terry Lambert
> ter...@lambert.org---
>Any opinions in this posting are my own and not those of my present
>or previous employers.

In article<Pine...@trifork.gu.net>you write:
>I've hear rumors that the source code for SCO UnixWare 2.1.x
>is now available from SCO for $500 for educational
>institutions.
>
>Isn't this interesting as a reference? How do you think?

No. Under no circumstances should you use it as a reference. This is
dangerous.

Unless, of course, you don't want to do any FreeBSD development, or, if
you do, you want to get yourself and/or Jordan Hubbard sued for some
intellectual property violation (e.g., copyright or trade secret).

At 09:31 AM 7/27/97 -0700, Sean Eric Fagan wrote:
>In article
<Pine...@trifork.gu.
net> you write:
>>I've hear rumors that the source code for SCO UnixWare 2.1.x
>>is now available from SCO for $500 for educational
>>institutions.
>
>>Isn't this interesting as a reference? How do you think?
>
>No. Under no circumstances should you use it as a reference. This is
>dangerous.
>
>Unless, of course, you don't want to do any FreeBSD development, or, if
>you do, you want to get yourself and/or Jordan Hubbard sued for some
>intellectual property violation (e.g., copyright or trade secret).

HAHAHA

This is the joke of modern software "non-disclosure". Do you really
think that Jordan is worth enough for SCO to deal with suing? Or
any other individual or small company? I love it when a little ISP
tells me they will sign a ND if we give them source...thats all I need, a
bunch of servers and some modem pools in Moosebreath Montana...which is
exactly what I'll get if I have to sue them.

Another interesting issue is that states and universities are exempt
from many copyright infringement type suits (I forget the exact wording),
so giving source to a university is like putting it in skywriting......I
doubt if SCO is that stupid, unless they are hoping that some major concern
blossoms as a result so that they would have someone worth suing.
They know that in todays world if a university has it, the rest of the world
will have it soon. You can't sue Cornell because some freshman puts
a tarball on the internet "by accident".

Dennis

Dennis

>This is the joke of modern software "non-disclosure". Do you really
>think that Jordan is worth enough for SCO to deal with suing? Or
>any other individual or small company?

Yes. If, in fact, SCO believes their trade secrets have been compromised,
Jordan makes a wonderful target. And they would *have* to, due to how
trade secret protection works.

But never let reality get in the way of your amusement, Dennis.

>Another interesting issue is that states and universities are exempt
>from many copyright infringement type suits (I forget the exact wording),

Wrong.

States are immune from copyright infringement, due to emminent domain. This
has been upheld by the Supreme Court within the past 15 years.
(Specifically, someone sued a UCB employee for font copying; the court
concluded that, as long as the employee was acting in an official capacity,
he was immune, and UCB, being part of the state constitution, was also
immune.)

Universities in general do not have this protection; Stanford University's
only protection is that it has more lawyers than most states. And most
state universities do not actually have this protection.

>You can't sue Cornell because some freshman puts
>a tarball on the internet "by accident".

Again: wrong.

And also again: don't bother letting reality get in the way of your
amusement, Dennis.

Sean.

>>No. Under no circumstances should you use it as a reference. This is
>>dangerous.
>
>>Unless, of course, you don't want to do any FreeBSD development, or, if
>>you do, you want to get yourself and/or Jordan Hubbard sued for some
>>intellectual property violation (e.g., copyright or trade secret).
>
>HAHAHA
>
>This is the joke of modern software "non-disclosure". Do you really
>think that Jordan is worth enough for SCO to deal with suing?

USL thought so, when they sent a "cease and desist" letter to all
of the various principle developers in the BSD camps when they
went after UCB for Net/2.

Also, consider that beating Jordan up legally is a lot easier than
beating up, say, MIT. And a decision against Jordan, if he appealed
it and lost again, would be binding against MIT.

They'd have to assume that MIT wouldn't jump in with Amicus Curie,
and that Jordan would be stupid enough to not seek outside help
(Jordan's not that dumb).

But yes, he would be an attractive target of oportunity.

>Or any other individual or small company?

Yes, as the other people who got the letters can attest. As I can
attest, when I marched down to Mike DeFazio's office (then VP in
charge of Novell USG) and fought tooth and nail, risking livelihood
and life savings, and dragging Ray Noorda into the fray, to get
them to drop the damn lawsuit.

>I love it when a little ISP tells me they will sign a ND if we
>give them source...thats all I need, a bunch of servers and some
>modem pools in Moosebreath Montana...which is exactly what I'll
>get if I have to sue them.

The issue here is "due dilligence". You would have to sue *anyone*
who disclosed, period, to show that you were protecting your trade
secrets. Otherwise you lose them.

The issue as to whether or not USL had trade secrets was much more
easily proven against a small company with little capitol; it was
no wonder that BSDI dragged UCB into the fray by claiming them as
path-of-disclosure.

>Another interesting issue is that states and universities are exempt
>from many copyright infringement type suits (I forget the exact wording),
>so giving source to a university is like putting it in skywriting......I
>doubt if SCO is that stupid, unless they are hoping that some major concern
>blossoms as a result so that they would have someone worth suing.
>They know that in todays world if a university has it, the rest of the world
>will have it soon. You can't sue Cornell because some freshman puts
>a tarball on the internet "by accident".

This is wrong. The wording you are looking for is "fair use".

Patents are allowed to be used for research purposes. As far as
copyrights are concerned, "fair use" only applies to excerpting
the material for educational purposes, and not to providing it
in any form for any other reason.

BTW: fair use applies equally well to commercial businesses with
internal training programs, or who wish to use the information
as example or whatever else in a board meeting.

As far as university disclosure: a university is just as subject
to the terms of a license contract as any other legal entity
which enters into the contract. The only potential difference
for a university is it's governmental ties. Which is why you
(or any sane vendor) sites DFARS rights restrictions in their
copyright notice, and again in their license agreement.

Contact the SPA for more information; I've had to research this
subject in incredible detail for two small software companies,
and the SPA has all of the information required.

Regards,
Terry Lambert
ter...@lambert.org---
Any opinions in this posting are my own and not those of my present
or previous employers.

On Mon, 28 Jul 1997, Terry Lambert wrote:

:>No. Under no circumstances should you use it as a reference. This is
:>dangerous.
:
:>Unless, of course, you don't want to do any FreeBSD development, or, if
:>you do, you want to get yourself and/or Jordan Hubbard sued for some
:>intellectual property violation (e.g., copyright or trade secret).

I'm sure that Jordan wouldn't mind doing a little hard time if it was in
the best interest of "The Project." ;-)

K.S.

>I'm sure that Jordan wouldn't mind doing a little hard time if it was in
>the best interest of "The Project." ;-)

Sigh.. :)

>The Classiest Man Alive writes:
>On Mon, 28 Jul 1997, Terry Lambert wrote:
>
>>>No. Under no circumstances should you use it as a reference. This is
>>>dangerous.
>>>Unless, of course, you don't want to do any FreeBSD development, or, if
>>>you do, you want to get yourself and/or Jordan Hubbard sued for some
>>>intellectual property violation (e.g., copyright or trade secret).
>
>I'm sure that Jordan wouldn't mind doing a little hard time if it was in
>the best interest of "The Project." ;-)

I'd strongly contest the notion that inclusion of System V code would
be in the best interest of the project. I've always claimed that the
real reason they want it kept secret is so that people don't find out
how crappily it's written.

Greg