Re: [TUHS] SunOS code?

[Warner Losh <imp@bsdimp.com>]

[-- Attachment #1: Type: text/plain, Size: 2326 bytes --]

On Thu, Aug 30, 2018 at 2:22 PM Larry McVoy <lm@mcvoy.com> wrote:

> On Thu, Aug 30, 2018 at 02:04:10PM -0600, Warner Losh wrote:
> > On Thu, Aug 30, 2018 at 1:41 PM Noel Chiappa <jnc@mercury.lcs.mit.edu>
> > wrote:
> >
> > >     > and finding a proper distribution tape to officially release.
> > >
> > > Why do we need that? Can't they say 'any and all versions of SunOS',
> and
> > > that
> > > term ('SunOS') is sufficiently well defined in real-world documents
> (e.g.
> > > Sun
> > > licenses) that that should be 'good enough'.
> > >
> > > It sounds like the _actual code_ is reasonably available, we wouldn't
> need
> > > Oracle to go looking around for it, would we?
> > >
> >
> > The trouble, as I was given to understand when I worked at Solbourne, was
> > that SunOS wasn't just AT&T + BSD 4.2 +  4.3 + awesome hacking at SMI.
> > There were a number of third party bits and pieces in there that could
> not
> > be relicensed, even 28 years ago when things were fresh.
>
> So I've been down this path, it was STREAMS and RFS, and maybe a couple
> of drivers.  I pulled all that crud out, put back the BSD tty code,
> and I had a SunOS we could have given away.


Why would STREAMS and RFS be a problem post OpenSolaris?


> It was back when I was
> writing this:
>
> http://mcvoy.com/lm/bitmover/lm/papers/freeos.pdf
>
> and I needed to be able to show that what I was asking for was possible.
>
> > A quick grep of something that fell off an http server suggests that the
> > number of these is quite limited. However, the files they are on have no
> > other license, even though latter-day versions are available of hack,
> hunt,
> > indent and pax are available (though to be fair, the latter two do give
> > permission explicitly, and a good case can be made for hunt).
>
> So you are including userland.  I'm not sure you need to.  Yeah, there was
> some unicode work done there but quite frankly, I'd just have
>
>         /usr/gnu/bin
>         /usr/bsd/bin
>         /usr/sun/bin
>
> and dump anything questionable in sun/bin.  It's the kernel that was the
> most interesting, next would be the run time loader and shared libraries.
> /usr/bin wasn't that exciting, the BSD purists might want that but I gotta
> believe that BSD has caught up to Sun in 25 years (right???).
>

grep -r was easy :).

Warner

[-- Attachment #2: Type: text/html, Size: 3254 bytes --]