Please tone down the GPL3 paranoia

Rob Landley rob at landley.net
Thu Sep 14 02:48:15 UTC 2006


On Wednesday 13 September 2006 6:29 pm, Bruce Perens wrote:
> Folks,
> 
> I think it would be supportive of the rest of the free software
> community to tone down the GPL3 paranoia until there is a GPL3.

Would you prefer I just make an executive decision without so much public 
discussion?

I've always identified with the open source community myself:
http://news.com.com/Open-source+board+eyes+fewer+licenses/2100-7344_3-5578799.html
http://www.infoworld.com/article/05/03/04/10OPopenent_1.html
http://linux.about.com/b/a/256777.htm

> When I created Busybox, the policy was that it could be distributed
> under the GPL.

I have neither the inclination nor the ability to change that policy.

> There was no restriction to prevent future versions of 
> the GPL.

No future versions of the GPL existed yet.

Why is chosing a specific license for the project a "restriction"?  If I'm 
writing new code and licensing it GPLv2, merging it with existing code that 
can also be licensed under GPLv2, packaging it, and releasing tarballs...  
Where's the downside?  Is it a "restriction" to _not_ release code under 
other licenses?  Is it a restriction if I've not chosen to license my 
contributions under BSD/MIT, or place it in the public domain?

I'm not making old versions go away.  The existing versions of BusyBox still 
remain, licensed "or later" up through (and including) 1.2.x.  Those licenses 
can't be revoked, the code has already been published under them without a 
revocation clause.  If somebody wants to start a GPLv3-only fork based off of 
that, more power to 'em.  I'm not taking that ability away from anybody.  I 
can't.

And it doesn't take any special privileges to drop all but one license of a 
multi-licensed project.  It happens all the time:
http://www.openoffice.org/FAQs/license-change.html

As an individual developer, I could fork the project and create new versions, 
and as with all dual licenses I could choose only one for the new version.  I 
could create a GPLv2-only or GPLv3-only version, without being maintainer of 
the existing one.  If my patches were only under one of the dual licenses, 
then that's the only license the resulting tarball could be distributed 
under.

The existing versions will remain under the licenses they were released under.  
That's a fact.  However, I'm the guy putting out new versions.  I only 
maintain the new versions that I put out.  (And there's nothing special about 
that, anybody who wants to put in the shoveling can do so.  That's the nice 
thing about the GPL.)  I'm talking about the license on those new versions.  
I don't have the authority to add licenses, but anyone who packages a tarball 
can drop one.  You only need one to be able to distribute the result.

> Over time, my work has been submerged in that of other authors. 
> But IMO it would be respectful of the original author to continue to use
> those license terms.

I am taking that into consideration, and it's definitely a factor in why I've 
been mulling the decision over for so long.

That said, you're asking me to license new code I'm writing under a license 
that didn't exist either under your tenure as maintainer, or under the tenure 
of the maintainer after you.  I hope you can also respect the desires of the 
current maintainer of a project you haven't touched in six years.

Since you left the project sucked in "advertising clause" BSD code, code with 
no attribution, and code from the Linux kernel (a project that is already 
GPLv2 only).  One of my first acts as maintainer was to track down and engage 
legal representation to actually enforce the license.  The subject of whether 
or not to keep the dual licensing clause came up while policing our licensing 
and attribution.  There's real work happening here.

> Later on, when there is a GPL3, you may decide not to accept GPL3-/only/
> submissions to this project's source code repository so that the GPL2
> can continue to be applied  to the entire project.

We will never accept GPLv3-only patches into the project.  That was never even 
considered.  We are never abandoning GPLv2 (no matter what GPLv3 turns out to 
be) because we can't and shouldn't, but mostly because there is no reason to.  
There's nothing wrong with GPLv2, and if there was it would be wrong with the 
Linux kernel, a project at the center of a multi-billion dollar industry with 
the resources to lobby for changes in the law to protect itself.

You seem to be suggesting it would be acceptable to simplify the project's 
license to GPLv3 only, but not to GPLv2 only.  When the project has 
practically speaking been GPLv2 only for its entire history because GPLv3 
didn't exist yet, with no guarantee it ever would.

I disagree.  Abandoning GPLv2 would be morally wrong, and betray our users' 
trust.  The only license terms under which anyone has ever been able to copy 
and distribute any version of BusyBox ever released is GPL version 2.  
The "or later" has been purely theoretical up to this point, because no such 
license exists.  Moving to an only slightly more restrictive license for an 
established project is what XFree86 did, and look where that got them.

Abandoning GPLv2 would also cause practical problems for BusyBox, because we'd 
be under a different license than the Linux kernel, and probably couldn't 
continue to use the Linux kernel's build infrastructure.  I strongly suspect 
we have used kernel source without properly tracking it.  (I actually know of 
an instance off the top of my head, loop.c, but might be able to legally 
defend that one as fair use if necessary.)

Not a line of code has ever shipped under GPLv3.  Infrastructure was put in 
place way back to potentially support it some day, but this was purely 
theoretical because this new license did not exist.  Now that the license is 
under development, the question has been raised as to whether or not it's 
worth the effort to maintain a real dual license on the project.  This dual 
license has costs (we first noticed it blocking diethotplug), and has no 
benefits that I am aware of.

> But I hope that when 
> that time comes, you will remember that much of the success of this
> package can be attributed to the use of a strong share-and-share-alike
> license

Yes, the GPLv2.  The same one that's on the Linux kernel.  I'd like to stay 
with that license.  I like it.

What's wrong with GPLv2?  It strikes an excellent balance that's lasted 15 
years already.  It's been a stable social contract the entire time I've been 
using Linux.

Everything up to this point has had NOTHING to do with the contents of GPLv3.

> rather than a license that would have allowed improvements to 
> the package to be locked down in some way.

You're implying GPLv2 would allow this?

"Locked down in some way" could simply mean that I don't give you root access 
to a server running BusyBox just because I give you an account on that 
server.  (If my account is to play World of Warcraft on Blizzard's servers, 
I'm ok with not having root access, even if they use BusyBox.  I want their 
source code back.  That's all GPLv2 ever asked for.)  I realize that Richard 
Stallman resisted putting a password on his internet account for years, but 
that's not the world I live in.

Nobody's ever told me what's actually wrong with GPLv2.  It's not forbidding 
device manufacturers from burning BusyBox into ROM, and for BusyBox it's GOOD 
that it doesn't forbid this.  (Hello, what do you think goes _in_ romfs?)  
Yes, it is not upgradeable if you do that, yes doing that prevents you from 
running arbitrary new code on the box, but in the embedded world it's an 
important option to have.  In such a case, I cannot run arbitrary code on 
that device without a soldering iron, and I'm ok with this.  GPLv3 is (at 
least in its goals) not ok with this.  (Or if it is, then what's wrong with 
the Xbox DRM?  If people want to manufacture a STUPID device, fine.  I just 
want to get back changes to the source code.  That's all I ever asked for, 
under GPLv2.)

I don't personally care that an unmodified Xbox doesn't let me run arbitrary 
code on it.  GPLv2 never asked for access to hardware, what it asked for was 
the source code to modified versions.  If they're doing something I didn't 
ask about, I'm fine with this.  I'm somewhat unhappy that the FSF quoting 
Darth Vader to my project's users: "I am altering the bargain, pray I don't 
alter it any further."  The FSF may think it has excellent reasons for doing 
so, but you thought Sun was being divisive with CDDL:
http://developers.slashdot.org/comments.pl?sid=137327&cid=11480318
And I think the FSF is being divisive with GPLv3, whether it means to or not.  

And again, we're back to an argument that have nothing to do with the contents 
of GPLv3.  You wonder why waiting for the final text is losing its appeal for 
me?  It could cure cancer; it still wouldn't be compatible with the license 
the Linux kernel is under.

As both an ethical and a practical matter, the versions of BusyBox I put out 
cannot leave GPLv2 behind, and if I don't drop that then the extra 
restrictions of GPLv3 are a moot point anyway.  They're unenforceable.  So 
why spend effort maintaining them?  Any project that requires GPLv3 only in 
order to use our code is one that we can't accept code back from.  That's 
just silly.

>     Thanks

Thanks for expressing your viewpoint.  I disagree with it.

>     Bruce

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list