Strange and historically inconsistent comments on GPLv2-only-ness of BusyBox

Good to know. (As I said, I wasn't involved in the decision.)

Code having a lot of component licenses is normal. Even toybox is still using an old (2.6.12 or so) klibc snapshot for menuconfig, which is GPLv2 (as our license page has a footnote about). This doesn't affect the license on the binaries because that code doesn't ship (it generates a .config file from our Kconfig files, and then the rest of the build uses that config file). Rewriting that is on the todo list (among other things that klibc code won't build on bsd, won't build with libfirm... it's a real portability bottleneck), but it hasn't made it to the top of the todo list yet.

But contributions to the project generally don't come with a license statement, and are presumably implicitly licensed under the project's license. (Getting contributors to sign a copyright assignment statement turns out to be a serious drag on the community, resulting in insular closed development community.) Proving that this patch to this file didn't change the license of that file when the rest of the patch was to GPLv2 files... well maybe you have a policy statement somewhere in the project contributors are assumed to have agreed to the same way you've agreed to the terms of service linked from the bottom of every website page you've ever visited...

One license for the project is _so_ much easier...

> Both points are wrong. QEMU's LICENSE file tells you
> that distribution of QEMU is possible under GPLv2 only,
> but that's not a decision and not even a choice. It's a
> statement of fact.

You're right. What I meant is that QEMU chose not to try to find and remove/rewrite existing GPLv2-only code from the project to maintain the "or later", I.E:

> If QEMU (as a whole) was GPLv2 or later, it could *choose
> to become GPLv3 or later* and accept binutils code. Right
> now we cannot even think of that without embarking in a
> relicensing adventure.

The fact you didn't is entirely understandable, we didn't either. It's a huge amount of work, there's no obvious way to test the result, and there's no real advantage. You can't enforce any GPLv3 provisions that aren't in GPLv2 without dropping the dual license, and if you merge GPLv3 only code you become GPLv3 only so you can't do that while maintaining the dual license.

All you'd be doing is preserving the right for a theoretical future relicensing "someday", and usually what happens with mature projects is somebody comes along and writes a new one from scratch after a few decades ala mozilla->chromium or gnome->xfce or openssh->dropbear or samba->smbserver or Fabrice's own http://bellard.org/jslinux/. None of what we've done is irreplaceable.

I've switched to public domain instead of copyleft because I want to provide maximum flexibility to future users. I proved experimentally that a year of license enforcement against multiple companies (even one in France) didn't add any code to busybox.

If GPLv3 actually needed to exist, it means that any _specific_ license terms are likely to become an impediment in future as technology and expectations and languages and laws and nationalities change. It would be nice if later projects could snip out and incorporate at least some of what I've done in their inevitable reboot, and public domain code is most likely to let that happen.

> That's exactly the opposite of mass-relicensing files that
> were GPLv2-or-later to GPLv2-only.

Indeed. And I'm happy that QEMU's TCG subdirectory is BSD licensed (except according to http://lists.landley.net/pipermail/qcc-landley.net/2015-M... they allowed GPL armv8 code in there), because I got permission from Fabrice Bellard to use his original tinycc code under a BSD license, and someday I'd like to find time to glue the two of them together. (Although whether it'll still be relevant by the time I get around to it...)

One of the things I said about busybox at the time is that the old versions are still available, so if you really wanted to fork from the older versions and do your own forensic analysis, you could presumably do a GPLv3 version. Just that _I_ wasn't doing that analysis, and we already had GPLv2-only code in the tree, and maintaining purely theoretical "or later" that you couldn't safely ship a binary under without at _least_ a whole lot of research... not of interest to us. (And since "license of patch submissions" is assumed to be "license of project" for contributors who don't specify and haven't signed anything, it means that individual files would become GPLv2 only next time they were touched anyway, so...)

Policing multiple licenses in the same project is hard. The "tcg is bsd except this bit" example above shows how hard, over time it tends to leak. Extracting and reusing any of the project's code under a different license than the project itself ships under requires you do to a lot of due dilligence if you actually care about licensing. (Most people don't, until somebody sues them. Unless they have lawyers on staff who veto the idea of ever going there in the first place.)

Keep in mind the "what license is busybox really under" debate was back when we were gearing up for the license enforcement lawsuits with the SFLC. Clarifying that Erik and I had standing to sue and that we knew exactly what our license WAS seemed kind of important in context. But now? That ship has sailed...

Really, what my adventure in license enforcement taught me is that programmers trying to be lawyers is about as useful as programmers trying to be cryptographers or medical doctors or anything else requiring massive domain expertise we don't have. Only winning move is not to play.

Rob