From: "Theodore Y. Ts'o" <firstname.lastname@example.org> To: Grant Taylor <email@example.com> Cc: firstname.lastname@example.org Subject: Re: [COFF] [TUHS] 386BSD released Date: Sat, 17 Jul 2021 00:09:09 -0400 [thread overview] Message-ID: <YPJX5dfahehgAxsI@mit.edu> (raw) In-Reply-To: <email@example.com> 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. 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.  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
next prev parent reply other threads:[~2021-07-17 4:14 UTC|newest] Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <firstname.lastname@example.org> [not found] ` <CAKH6PiVCjo3YnTZUVYOCDeffQ6POVwGAQA1QMR9UinkfGn+AmQ@mail.gmail.com> 2021-07-15 6:33 ` Michael Kjörling 2021-07-15 20:44 ` Derek Fawcus 2021-07-15 15:07 ` Clem Cole 2021-07-15 19:33 ` Theodore Y. Ts'o 2021-07-15 20:30 ` Clem Cole 2021-07-16 1:58 ` Theodore Y. Ts'o 2021-07-16 2:14 ` George Michaelson 2021-07-16 18:02 ` Grant Taylor via COFF 2021-07-17 4:09 ` Theodore Y. Ts'o [this message] 2021-07-17 6:30 ` [COFF] " Tom Ivar Helbekkmo via COFF 2021-07-17 12:37 ` Theodore Y. Ts'o 2021-07-17 13:30 ` Tom Ivar Helbekkmo via COFF 2021-07-18 3:29 ` [COFF] [TUHS] " Grant Taylor via COFF 2021-07-18 3:42 ` David Arnold 2021-07-18 4:01 ` Grant Taylor via COFF 2021-07-19 13:41 ` Theodore Y. Ts'o 2021-07-19 14:50 ` Clem Cole 2021-07-19 17:38 ` Theodore Y. Ts'o 2021-07-19 19:33 ` John P. Linderman 2021-07-19 20:21 ` Clem Cole 2021-07-20 1:05 ` Grant Taylor via COFF 2021-07-19 20:08 ` Clem Cole 2021-07-20 0:55 ` Theodore Y. Ts'o 2021-07-18 6:44 ` Andy Kosela 2021-07-16 16:11 ` Jonathan Corbet 2021-07-15 23:02 ` joe mcguckin [not found] <alpine.BSF.email@example.com> [not found] ` <213a4c11-3ab2-4b4a-8d6b-b52105a19711@localhost> [not found] ` <CAE49LGn-gY9eikkwUgS+i3p=ZQV+gk_3BJ5V4_6B4HPbdyRuZw@mail.gmail.com> 2021-07-14 15:01 ` Clem Cole 2021-07-14 17:40 ` Theodore Y. Ts'o 2021-07-14 17:50 ` Larry McVoy 2021-07-14 18:28 ` Clem Cole 2021-07-14 20:03 ` John Cowan
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=YPJX5dfahehgAxsI@mit.edu \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [COFF] [TUHS] 386BSD released' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).