[License-review] For Approval: Convertible Free Software License, Version 1.3 (C-FSL v1.3)

[Rob Landley]

On 1/9/19 5:04 PM, Bruce Perens wrote:
> I have helped a large government lab and their legal counsel to do a license
> transition on Open Source with a big external developer community. We know well
> how to do it.
> 
> XFree86 /forked /twice when license decisions prompted the developers to decide
> that their current management was an impediment to the project. It didn't
> destroy the project either time, it just made a particular organization
> irrelevant to its future.

I meant it destroyed xfree86.org, which is so dead the mailing list archives
went away (all the mailman links from http://xfree86.org/sos/lists.html are
404). The code survived, forked under new maintainership and a new name, with
many of the same developers and inheriting pretty much all the users.

Heck, you could view Linux as a fork of the minix develoment community: in 1991
comp.os.minix had a large backlog of patches that couldn't go upstream due for
IP/licensing reasons, Linus posted a new tiny kernel to the minix list, people
ported the minix extensions they maintained to Linux and Linus merged them, and
the existing developer base switched over en masse to the new codebase because
he merged patches and Tanenbaum didn't. That's why Linux went from zero to
hosting the majority of all websites in under 3 years: it inherited an existing
development community maintaining a large pile of mature feature patches, and
provided different license terms that those developers preferred.

That's the context in which the tanenbaum-torvalds debate happened (on
comp.os.minix, when tanenbaum came back from vacation at the end of January 1992):

https://www.oreilly.com/openbook/opensources/book/appa.html

And then Linux got kicked of the minix usenet group and got its own mailing list
at the end of the year:

http://landley.net/history/mirror/linux/1991.html

So Linux wasn't really quite entirely its own project for its first 2 years. (He
wrote it under Minix, used the minix filesystem, posted everything to the minix
mailing list... and swallowed the minix development community whole. And his
original motivation for writing his own kernel is minix's microkernel
architecture dropped characters using a 2400 baud modem so dialing into the
university microvax to _read_ the usenet archive didn't work reliably in minix.
And then needed to upload/download files, so taught it to read/write his minix
filesystem, and then he didn't want to reboot to ls/mkdir/rm when
uploading/downloading so taught it to run bash as a child process, and _that_
turned out to be 95% of the syscalls he needed to run gcc... "My terminal
program grew legs." - Linus Torvalds)

What is and isn't a new project gets a little... fuzzy at times. As an extreme
case, buildroot started life as the uclibc test suite (test uClibc by building a
uClibc toolchain and building packages against uClibc). It's first commit was in
2001:

  https://git.busybox.net/buildroot/commit/?id=ffde94bd2ca2

And I didn't create a buildroot mailing list and kick the traffic _off_ the
uClibc mailing list until 2006:

  http://lists.busybox.net/pipermail/buildroot/2006-July/012219.html

By which point the buildroot traffic on the uClibc mailing list had essentially
steamrollered uClibc. (The 5 year gap between launch and forcing the popular new
thing to leave the nest was structurally really bad for the original project. To
the point buildroot added glibc support, and musl-libc arose to fill its niche,
and _then_ somebody on another continent stepped up and decided to maintain his
own fork of the dead thing, which I thought was really silly to do but it's his
time: http://lists.busybox.net/pipermail/uclibc/2017-March/049251.html and now
there's a uClibc-ng which has nothing to do with uclibc.org, but _buildroot_
says it's the official uClibc now as far as buildroot is concerned... does that
make it the same project? I honestly have no idea! There's a sort of
frankenstein "it's alive, we recycled 60% of the parts, the lightning bolt
revived the corpse it last tuesday!" thing going on...)

Similarly, when Fabrice Bellard started adding multiple backends to his tinycc
project (so it could produce code for multiple targets), he essentially had it
generating x86 bytecodes and then converting them to other processors' machine
codes, and he went "wait, this would let me run wine on powerpc mac hardwar",
and the resulting project was QEMU which sucked all the _developers_ out of
tinycc (and thus the original project stalled hard because Fabrice wasn't
putting any  more time into it, even though https://bellard.org/tcc/tccboot.html
demonstrated _compelling_ todo items for the project that sadly never quite got
done because qemu ate all Fabrice's cycles)...

With tccboot and uclibc, loss of the original maintainer's time killed the
project (but other maintainers did new versions later, both of which are still
pretty darn moribund development-wise and a shadow of what it used to be, but if
people still _want_ to use that old thing they have an option).

With xfree86 and cdrecord, other people picked up the slack. Heck, Bruce and I
argued over maintainership of busybox, resulting in the project passing on to an
unrelated third party (Denys Vlasenko) who's done fine with it.

With xfree86->x.org an earlier maintainer came back, with cdrecord->wodim other
people stepped up.

Meanwhile, Google's boringssl is a hard fork of openssl that mostly removed
stuff and is deployed on an order of magnitude more devices than the original
version (due to android shipping a billion devices a year) but the original
still exists and is used! Is it a new project or not? Who can say?

tl;dr: what this license is trying to do with its "original developers" nonsense
does not match reality, even a little. (At least according to this hobbyist
computer historian's understanding.) It is _conceptually_ broken.

Rob