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