Re: [9fans] licence question

[Dan Cross <crossd@gmail.com>]

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

On Tue, Feb 1, 2022 at 10:08 AM ibrahim via 9fans <9fans@9fans.net> wrote:

> On Tuesday, 1 February 2022, at 3:12 PM, Dan Cross wrote:
>
> This isn't really on-topic for 9fans, but I find this hard to believe.
> Linux used the exact same compiler suite, and became wildly successful
> while the BSD distributions mostly stagnated; certainly, the BSDs never
> grew at the rate or reached the levels of popularity that Linux has
> attained: it wasn't the license on the toolchain.
>
> Berkeley stopped their distribution of BSD systems right after they were
> forced to remove the toolchain. The last releases were 4.3 and 4.4 lite.
>

Hmm, no, that's not quite right. 4.3BSD was in 1986; 4.4-Lite2 was in 1995:
nineish years later, with lots of intervening activity (Tahoe, Reno, Net/1,
Net/2, 4.4, 4.4-Lite, etc). Perhaps you meant to write 4.4 and 4.4-Lite?

Anyway, the toolchain switch had little to do with CSRG shutting down. The
reality there was that Unix stopped being interesting for an academic
department to continue supporting like EECS at UCB was with CSRG and BSD:
this was all spelled out in the 4.4BSD announcement. As Bostic put it, BSD
was always a community effort, but after 4.4, it just wasn't going to grow
within UCB:
https://groups.google.com/g/comp.unix.bsd/c/hZYO7xTDqQ8/m/NE-S-HWH9-wJ

They also understood that GCC was a better compiler than PCC was at the
time: with PCC on the VAX, they had post-processing steps implementing
peephole optimizations with shell scripts, and GCC just generated better
code. It also implemented most of the ANSI standard, which PCC did not. In
other words, there were technical reasons for switching to GCC beyond just
the license. Indeed, the setup document says, "Most 4.3BSD binaries may be
used with 4.4BSD in the course of the conversion. It is desirable to
recompile local sources after the conversion, as the new compiler (GCC)
provides superior code optimization." (
https://docs.freebsd.org/44doc/smm/01.setup/paper.pdf)

Then the project got forked. It led to a stop in development. I personally
> believe that this was the main reason behind the BSD's to lose their charm.
>

By "forked" do you mean the Jolitz's porting it to the 386? That was
independent of what happened with CSRG shutting down, and neither of those
had much to do with the GPL or adopting GCC as the system compiler.

This also ignores a lot of other developments: the VAX stopped being _the_
dominant platform of the Internet, there was a lot more choice for
reasonable Unix distributions from e.g. workstation vendors, many
organizations stopped looking at Unix as primarily a research system which
lead to the rise of standards bodies like IEEE with POSIX, which
subsequently lessened the need for something like BSD as a quasi-standard
for the likes of DARPA. Meanwhile, and the PC platform became huge, and
people who just wanted Unix on cheap machines suddenly had Linux as a free
working alternative that was "good enough". BSDi cost a lot of money for an
individual (around $1000 USD, if I recall correctly), was embroiled in a
lawsuit with AT&T (the outcome of which was not at all certain) and with
Linux you had a reasonable expectation that someone would help you boot it
on your toaster -- or at least accept the patches if you did it yourself --
and you didn't have to put with with some of the "big" personalities in the
traditional Unix world.

If you read about the reasoning why as an example Minix or even plan9 got
> their own toolchains I think you can read between the lines that the lack
> or the existence of a toolchain with the right license is far more
> important than many believe.
>

Plan 9 got its own toolchain because that was part of the project: how
would one evolve a language like C and a compiler/assembler/linker suite to
make it more pleasant for building the sort of holistic system that plan9
became, and how to accommodate cross-compilation and development in a
heterogenous hardware environment: indeed, many of the early plan9 design
choices were motivated by similar concerns. The license had little, if
anything, to do with it, and being an "open source" system was not a
primary goal of plan9 when the compilers were written. I can't really
imagine that GCC was given any serious consideration as a compiler for
plan9 simply on its merits, if indeed it was given any consideration at
all: at the time, it fulfilled a completely different purpose.

You may have a point with respect to the license mattering for the original
Minix, but bear in mind that the ACK predates GCC, and Tanenbaum was
building a pedagogical system, not a production system: he actually needed
to be able to distribute the toolchain with the Minix educational
materials. He probably could have used GCC just as well, but it's clear he
started Minix a few years ahead of the first public release, and GCC wasn't
available then. Since he already had ACK, it was logical to use it.

Of course this is only my personal opinion and probably I'm misinterpreting
> things.
>

I think, bluntly, this ignores a lot of the actual history and is an
example of confirmation bias in an analysis of the use of GPL in OSS OS
projects, or license toolchains more generally. Look at the complaints from
the OpenBSD people when the Clang/LLVM license changed; yet, they continue
to ship a pretty recent clang version despite the "unacceptability" of the
Apache 2.0 license, and let's be honest: they probably will for a long time
to come.

That said, I also think you're perfectly within your rights to ship your
kiosk application as a closed-source system if you want to, despite
protestations to the contrary.

        - Dan C.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T3e07bfdf263a83c8-M7f45cc216a7b9f8059344c85
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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