[TUHS] [COFF] 386BSD released

[George Michaelson]

I was part of a discussion about a bug in the DECUS tape in Leeds uni,
in '82-84 window. I was a very small part I might add, not the
principal. I can't remember the package. It was probably trivia, like
walking a specific SYS$SYSTEM value in a way which was dangerous or
encoded assumptions about device:directory:user models in VMS.

The feedback I got from this process was "thanks, we'll think about
it" was closure, for those days.  We'd been pretty specific about a
fix. I got the sense the tape was an annual affair. And the likelihood
of our "patch" being both accepted, and added to the next round of the
tape was low-to-zero because everyone wanted "moar" and so people
focussed on adding things, not fixing things.

The exception here was compilers: people always want bugs fixed in a
compiler. Or the NAG library, but both compilers (language spec) and
NAG (strict maths formalisms about correctness) had policed mechanisms
to accept user input, validate, run through a remorselessly tight
compliance check, and emit, if it survived.

A bug in the implementation of MUD for dec-10? ok, so the word
"potato" is misspelled on one screen. Move on.

On Fri, Jul 16, 2021 at 11:59 AM Theodore Y. Ts'o <tytso at mit.edu> wrote:
>
> On Thu, Jul 15, 2021 at 04:30:15PM -0400, Clem Cole wrote:
> >
> > Ted - that *is what* Doug pointed out!!!  They did not create anything that
> > was new.  SHARED / DECUS / USENIX and the like were providing that exact
> > same function starting in the late 1950s!!!  Companies and Universities all
> > pooled their resources to make things better and to get new and improved
> > solutions.    Sometimes they started with things that come from the
> > original OEM.  Also often they created their own technology and made it
> > available to everyone.  Sometime they combine both.  And it was a
> > 'bazaar where everyone had access and you chose to use it to not.  Sounds
> > pretty familiar, BTW.
>
> I remember looking at the DECUS program catalog for the PDP-8, and I
> seem to recall that for the most part, individuals were sharing their
> programs with others.  In that way, it wasn't all that different from
> say, CPM/UG, and HUG (Heathkit Users Group).  But the thing is, for
> the most part, it was a single author sharing individual programs, and
> often changes were not accepted back.
>
> Consider the history of Bill Jolitz and 386BSD, and the collection of
> patches that eventuallya became NetBSD and FreeBSD, which was formed
> because they were frustrated that they couldn't get their patch sets
> back into Jolitz's code base.  Technology plays a part, in that it
> enables the change.  But it's not just about technology.  There is
> also a very strong social component.  Even when you were richly
> interconnected at the network level, this does not guarantee that will
> be willing to be richly interconnected in terms of accepting patch
> sets from people who you may not know across the Internet, into *your*
> program, for which you are the author and high priest.
>
> I don't remember the exact date, but it would have been in the early
> 90's, when at the time I was already contributing patches to Linux,
> and where ftp and e-mail and applying patches via context diffs was
> very much available.  At that time, we were interested in getting
> support for MIT Project Athena's Hesiod extenstions into the BIND
> distributions (we had just been carrying patches against BIND for many
> years).
>
> In order to get those patches integrated, Paul Vixie invited me to his
> house in Redwood City, and so I flew from Boston to San Francisco,
> carrying my Linux laptop with the BIND patches, and we got the patches
> integrated into master BIND sources.  Paul was a gracious host, and it
> was lovely that I got to spend some time with him.  But it was
> interesting that my physical presence was needed, or at least highly
> useful, in terms of getting those patches into BIND.  Requiring
> physical presence to get patches integrated.... doesn't scale.
>
> And so it wasn't a matter of technology, since the technology for
> Linus, who didn't know me from Adam in 1991, to accept patches from me
> implementing BSD Job Control, was certainly available when I was
> working with Paul to get the Hesiod changes integrated into BIND.  But
> like with Jolitz and 386BSD, it's a mindset thing, not just technology.
>
> I also want to emphasize again, the question of business model is also
> something which I think is different, and *important*.  It's one thing
> for Academics and Researchers to be willing to give changes away to
> anyone who wants.  It's quite another for a company to give away their
> intellectual property in such a way that it can actually be used by
> their competitors, either because that's the social convention, or
> because it's enforced by the license.  Was the practices we use today
> for Linux built on the traditions of comp.sources.unix, and BSD, and
> AT&T Research, and IBM making sources available for System/360, yadda,
> yadda, yadda?  Of course!  I'm not denying that.
>
> But at the same time, to claim that nothing is new under the Sun, and
> *all* of this had been done decades earlier, is also not the whole
> story.  And to call IBM releasing System/360, when they retained
> control of the license, and wasn't accepting any changes back, and
> *darned* well would have sued anyone trying to use that code on
> non-IBM computers into a smoking crater, as "Open Source" can be
> highly misleading, because that is not what most people associate with
> the term "Open Source" today.
>
> And if we take a look at what AT&T Lawyers did with the Unix source
> code, at some point, it most *defintely* was the antithesis of "Open
> Source".  Which would lead me to assert that Unix was never really
> released under what today we would call, "Open Source".
>
> Cheers,
>
>                                         - Ted