![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
The ongoing fight against GPL enforcement
GPL enforcement is a surprisingly difficult task. It's not just a matter of identifying an infringement - you need to make sure you have a copyright holder on your side, spend some money sending letters asking people to come into compliance, spend more money initiating a suit, spend even more money encouraging people to settle, spend yet more money actually taking them to court and then maybe, at the end, you have some source code. One of the (tiny) number of groups involved in doing this is the Software Freedom Conservancy, a non-profit organisation that offers various services to free software projects. One of their notable activities is enforcing the license of Busybox, a GPLed multi-purpose application that's used in many embedded Linux environments. And this is where things get interesting
GPLv2 (the license covering the relevant code) contains the following as part of section 4:
Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License.
There's some argument over what this means, precisely, but GPLv3 adds the following paragraph:
However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation
which tends to support the assertion that, under V2, once the license is terminated you've lost it forever. That gives the SFC a lever. If a vendor is shipping products using Busybox, and is found to be in violation, this interpretation of GPLv2 means that they have no license to ship Busybox again until the copyright holders (or their agents) grant them another. This is a bit of a problem if your entire stock consists of devices running Busybox. The SFC will grant a new license, but on one condition - not only must you provide the source code to Busybox, you must provide the source code to all other works on the device that require source distribution.
The outcome of this is that we've gained access to large bodies of source code that would otherwise have been kept by companies. The SFC have successfully used Busybox to force the source release of many vendor kernels, ensuring that users have the freedoms that the copyright holders granted to them. Everybody wins, with the exception of the violators. And it seems that they're unenthusiastic about that.
A couple of weeks ago, this page appeared on the elinux.org wiki. It's written by an engineer at Sony, and it's calling for contributions to rewriting Busybox. This would be entirely reasonable if it were for technical reasons, but it's not - it's explicitly stated that companies are afraid that Busybox copyright holders may force them to comply with the licenses of software they ship. If you ship this Busybox replacement instead of the original Busybox you'll be safe from the SFC. You'll be able to violate licenses with impunity.
What can we do? The real problem here is that the SFC's reliance on Busybox means that they're only able to target infringers who use that Busybox code. No significant kernel copyright holders have so far offered to allow the SFC to enforce their copyrights, with the result that enforcement action will grind to a halt as vendors move over to this Busybox replacement. So, if you hold copyright over any part of the Linux kernel, I'd urge you to get in touch with them. The alternative is a strangely ironic world where Sony are simultaneously funding lobbying for copyright enforcement against individuals and tools to help large corporations infringe at will. I'm not enthusiastic about that.
GPLv2 (the license covering the relevant code) contains the following as part of section 4:
Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License.
There's some argument over what this means, precisely, but GPLv3 adds the following paragraph:
However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation
which tends to support the assertion that, under V2, once the license is terminated you've lost it forever. That gives the SFC a lever. If a vendor is shipping products using Busybox, and is found to be in violation, this interpretation of GPLv2 means that they have no license to ship Busybox again until the copyright holders (or their agents) grant them another. This is a bit of a problem if your entire stock consists of devices running Busybox. The SFC will grant a new license, but on one condition - not only must you provide the source code to Busybox, you must provide the source code to all other works on the device that require source distribution.
The outcome of this is that we've gained access to large bodies of source code that would otherwise have been kept by companies. The SFC have successfully used Busybox to force the source release of many vendor kernels, ensuring that users have the freedoms that the copyright holders granted to them. Everybody wins, with the exception of the violators. And it seems that they're unenthusiastic about that.
A couple of weeks ago, this page appeared on the elinux.org wiki. It's written by an engineer at Sony, and it's calling for contributions to rewriting Busybox. This would be entirely reasonable if it were for technical reasons, but it's not - it's explicitly stated that companies are afraid that Busybox copyright holders may force them to comply with the licenses of software they ship. If you ship this Busybox replacement instead of the original Busybox you'll be safe from the SFC. You'll be able to violate licenses with impunity.
What can we do? The real problem here is that the SFC's reliance on Busybox means that they're only able to target infringers who use that Busybox code. No significant kernel copyright holders have so far offered to allow the SFC to enforce their copyrights, with the result that enforcement action will grind to a halt as vendors move over to this Busybox replacement. So, if you hold copyright over any part of the Linux kernel, I'd urge you to get in touch with them. The alternative is a strangely ironic world where Sony are simultaneously funding lobbying for copyright enforcement against individuals and tools to help large corporations infringe at will. I'm not enthusiastic about that.
Re: From the Sony engineer mentioned...
(GPLv2 has the downside of predating the NSF "Acceptable Use Policy" changes circa 1993-ish that allowed commercial ISPs to attach to the backbone. It doesn't have anything in it about internet distribution because that wasn't a viable option for most users when it was published, which is why all the dialup modems were still calling each _other_ and doing uucp and fidonet.)
Re: From the Sony engineer mentioned...
(Anonymous) 2012-02-01 12:55 am (UTC)(link)You've made your opinions on GPLv3 abundantly clear (though I suspect they've been tainted heavily by your unpleasant experiences with Bruce Perens), but GPLv3 specifically set out to update GPLv2 for the numerous issues that simply didn't exist at the time GPLv2 came out.
Out of curiosity, would you consider elaborating a bit on your specific objections to the GPLv3? I've seen numerous comments from you complaining about the GPLv3, but I've never actually seen an explanation of what you don't like about it.
Re: From the Sony engineer mentioned...
> experiences with Bruce Perens)
Yup.
> Out of curiosity, would you consider elaborating a bit on your specific
> objections to the GPLv3?
I answered this question with a bunch of links in lwn comments section. Here's another:
http://lists.busybox.net/pipermail/busybox/2006-September/058505.html
Rob
Re: From the Sony engineer mentioned...
(Anonymous) 2012-02-01 03:57 am (UTC)(link)I read both the LWN comments, the comments here, the mailing list page you just linked to, and a fair bit of your blog that you've linked to. So far, I've seen the following objections you've made about the GPLv3 (with any comments or questions of mine in parentheses):
- It's a new license, and thus contributes to license proliferation.
- You didn't want to have to apply the same degree of careful reading and analysis to the new GPLv3 that you'd already applied to the GPLv2.
- It isn't compatible with the GPLv2. (That one seems pretty much impossible to satisfy with any usefully new version of the GPL, but I do agree that it represents the single biggest issue with the GPLv3. That said, other than the Linux kernel I've seen very few projects which use GPLv2-only, and code in the Linux kernel doesn't tend to find itself in userspace very often, unless you try to write a replacement for coreutils. :) Also, the same problem applies to permissively-licensed code in the other direction, since it can't take GPLed code from other projects.)
- You don't like the idea of relicensing existing GPLv2-or-later projects as GPLv3-only or GPLv3-or-later, because you feel that doing so would betray the users of those projects. (That objection I both understand and sympathize with, and I see nothing wrong with continuing to use GPLv2-or-later or GPLv2-only indefinitely on many existing projects whose users might care about that change, just as I see nothing wrong with releasing MIT-licensed code: they all represent a scale from more permissive to more protective. Whether any given project wants to move to GPLv3{,-or-later} seems like a decision entirely up to that project, and whether it makes sense or not depends on the project.)
- You say that the GPLv3 prevents people from burning code into ROM. (As I understand it, that represented a bug that got fixed in later versions of the GPLv3, hence why it had such a long and drawn-out drafting process.) You also suggested that the GPLv3 would require "root access to a server" based on having an account on one powered by GPLv3 software, using a World of Warcraft account as an example. (Again, that doesn't seem to apply to the released version of the license, and even the Affero GPLv3 doesn't require "root access to a server", just the source code as you said you want.)
- In general, you've objected to the provisions which try to ensure that end users can replace the firmware on their devices with modified versions, to the extent those devices allow the manufacturer themselves to do so. (Considering the origins of the FSF, as well as the current activity around locked-down devices, I personally don't consider that particularly unreasonable, but I can certainly understand your objection.)
- You objected to the language prohibiting the use of GPLv3 code to create anti-circumvention mechanisms, both because you considered it laughable that anyone would do so, and because as a result you considered it an issue not worth adding a use restriction for. (I agree that it seems laughable today, but personally I look forward to a world where proprietary software represents the exception, not the rule, and I think it makes sense to try to deal with that issue accordingly. These days, "the right to read" has become shockingly prescient.)
Have I missed any objections or criticisms, or does the above fairly summarize your problems with the GPLv3?
On a slightly different note, one bit of GPLv3 I think you'd probably like: per section 14 of the GPLv3, instead of saying "or any later version", you can now designate a proxy to choose what new versions of the GPL apply to a program. So, you could potentially say "GPL version 2 or version 3, or any later version accepted by $YOU", which allows you to avoid giving the FSF blanket relicensing permission while also removing the problem of having so many authors that you can never usefully relicense at all.