Re: [COFF] [TUHS] 386BSD released

["Theodore Y. Ts'o" <tytso@mit.edu>]

On Fri, Jul 16, 2021 at 12:02:39PM -0600, Grant Taylor via COFF wrote:
> On 7/15/21 7:58 PM, Theodore Y. Ts'o wrote:
> > Requiring physical presence to get patches integrated.... doesn't scale.
> 
> I believe I understand the spirit of what you are saying.  However I have a
> question:
> 
> Was the need / requirement for your physical presence motivated by (a lack
> of) technology?  Or was it more an interview of you / your team to determine
> if your contributions were desired or not?  I see a huge difference behind
> raw code and the team (trust ability / intentions) behind the code.  May
> people can do work required for a job remotely, yet must apply and interview
> for said job in person.
> 
> So, what was the real gate / blocker?  Technology to accept the code? Or
> meeting / getting to know the person / representative of the people behind
> the code?

I'm really not sure what was the blocker.  Hesiod had been used in
production at MIT Project Athena for a number of years, and had been
written up as papers at Usenix and LISA, and had been vetted by the
IETF and the specification was in RFC 1035.  The patches were
available on MIT ftp servers, and there were one or two other sites
who were using it.

I didn't actually write the Hesiod patches; it was originally written
by Steve Dyer, who was a full-time engineer on loan from IBM to
Project Athena.  But this was after Steve had returned to IBM, and I
was maintaining the name servers running at MIT.  I had tried
communicating via email, and to be honest the patches weren't all that
complicated.  But I didn't have any luck, and finally Paul invited me
to his house.

Whatever the reason, if people require physical presence to develop
trust, or something else --- it just doesn't scale.  You can have the
technology, but if people insist on wanting do the whole "dog sniffing
another dog's butt" before trusting a code contribution, that's not a
particularly healthy pattern for an active, vibrant open source project.

> My opinion is that no, the ability to see the source code is not the same
> thing as a license to use said source code.  There are many examples where
> visibility of source code and licensing to use it are two completely
> independent things.

I actually think there are three different dimensions.

* Source Availability
* Licensing which conforms to the Open Source Definition
* Contributions Accepted (in practice)

These are not binary, of course; Microsoft might make only part of its
sources available to various companys or countries.  But trying to
claim that this is "Open Source" is just going to confuse people,
because that is *not* how most people in the industry use that term
today.  So that's why I would suggest the terminology "Source
Available".

The third dimension, whether or not Contributions are accepted, is
also an important distinction.  And again, it's not a binary.  It's
not that it was *impossible* for me to get a new feature into BIND.
It just required a physical visit in order to make it happen.

> Closed Source / Open License
> Open License / Open Source
> Open Source / Closed License
> 
> I believe that many people think of "Open Source" as being the middle
> overlap where both the License and the Source are open.  This may be
> accurate more of the time than it is not.  However I think that assuming it
> to /always/ be the case is ... unsafe.

You may want "Open Source" to mean something else, but the common
language in the industry is that it means "License which conforms to
the Open Source Definition".  That's how it's been used since 1998[1].
Companies have Open Source Compliance Offices/Officers.

The name was chosen specifically because "Free Software" was
considered too scary, and radicalized.  For too many people, brought
to mind a creepy man who would talk about making all programming be
funded by the government (Socialism!), and wearing a disk platter as
"Saint IGNUcius".

So it was very much a rebranding effort, taking the Debian Free
Software Guidelines, changing it slightly, calling it the Open Source
Definition, and then using the term Open Source.  For all intents and
purposes, the set of software which was "Free Software" and the set of
software which was "Open Source" are identical.  "Open Source" was a
name that was picked so as not to scare the suits[1].

[1] https://opensource.org/history

You can try to argue that it should have a different etymology, but
that's not how the name was chosen, from a historical standpoint.  And
trying to change the definition after the fact is likely going to be
as successful as Stallman's attempt to rename Linux to be GNU/Linux.
Trying to dictate to the people who came up with and use a name that
they should change the name, or change the definition, without their
consent, will likely lead to your being ignored in the best case, or
mocked in the worst.

Cheers,

					- Ted
_______________________________________________
COFF mailing list
COFF@minnie.tuhs.org
https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff