[personal profile] mjg59
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.

Re: From the Sony engineer mentioned...

Date: 2012-01-31 08:59 pm (UTC)
From: [identity profile] landley.livejournal.com
Define "infringing".

I wrote up fairly extensive guidelines about what I did and did not consider infringement:


I.E. using vanilla unmodified code is not infringing, we just want your IMPROVEMENTS. I did't care about forcing you to mirror source tarballs like the FSF did to Mepis, or exploiting crazy loopholes. If you honestly haven't got any code we'd want, there's nothing in it for us.

The SFLC/SFC didn't work that way. They wanted settlement money so they could afford to file the next suit, and they used busybox to sue over OTHER software packages which is disingenuous.

So from my point of view, "Is your code vanilla unmodified busybox" could be answered "yes". From the SFLC's point of view, the answer had to be accompanied with a $20k check and the right to go through your refrigerator looking for expired mattress tags.

I'm aware that you care deeply about the mattress tags, but you're being a slimy weasel exploiting other people's loopholes to get your way, and you're upset that the loophole is closing. You find it an INJUSTICE that the loophole may no longer be leverageable for unrelated purposes.

As the source of the loophole in the first place: "Nuts to your white mice."

Re: From the Sony engineer mentioned...

Date: 2012-02-01 01:36 am (UTC)
From: [identity profile] landley.livejournal.com
I remember when the FSF guys insisted that Tivoization was infringing (even when they had to change the license to make it so), and the kernel developers didn't think so. Your advice to me is a bit like Stallman telling Linus he's definitely being taken advantage of, and Linus being ok with it anyway, because the two of them have different definitions of what being taken advantage of means.

It's kind of sad when the pragmatists are the ones ok letting other people do things they wouldn't personally do, and the proponents of "Free" are the ones trying to control other people's behavior "for their own good".

Re: From the Sony engineer mentioned...

Date: 2012-01-31 09:58 pm (UTC)
From: [personal profile] pehjota
I.E. using vanilla unmodified code is not infringing, we just want your IMPROVEMENTS. I did't care about forcing you to mirror source tarballs like the FSF did to Mepis, or exploiting crazy loopholes. If you honestly haven't got any code we'd want, there's nothing in it for us.

17 U.S.C. ยง 106 defines rights to do or to authorize certain activities, which are held exclusively by the copyright owner. These rights include reproduction of copies, preparation of derivative works, and distribution of copies. So if a company reproduces and distributes even unmodified copies of BusyBox, it is infringing copyright unless authorized by a license. The GNU GPL allows such distribution of unmodified copies so long as a copy of source code or an offer therefor is given.

Of course I suppose that a copyright holder might form an estoppel by knowingly allowing distribution of unmodified copies of BusyBox outside the terms of the GNU GPL. But that incurs legal uncertainty for the company and its downstream recipients.

Re: From the Sony engineer mentioned...

Date: 2012-02-01 12:13 am (UTC)
From: [identity profile] landley.livejournal.com
Basically I was trying to allow everybody to take advantage of 3(C) sans the "noncommercial" bit by pointing back at the busybox website and going "we downloaded it form here, bon apetit".

(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...

Date: 2012-02-01 12:55 am (UTC)
From: (Anonymous)
That was one of the many things the GPLv3 set out to fix, and did; clause 6b allows shipping products to point at a server with the source code rather than a "durable physical medium", and 6d allows downloads of binaries to point at downloads of source code.

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...

Date: 2012-02-01 01:40 am (UTC)
From: [identity profile] landley.livejournal.com
> (though I suspect they've been tainted heavily by your unpleasant
> experiences with Bruce Perens)


> 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:



Re: From the Sony engineer mentioned...

Date: 2012-02-01 03:57 am (UTC)
From: (Anonymous)
I want to lead with the disclaimer that I'm genuinely curious about your opinions on the GPLv3. I don't intend any of the following to try to convince you of anything, or to make you defend your opinions; I'd just like to understand the objections of someone who favors GPLv2 over v3, and you're one of the few people I've seen who actually talks about v2 versus v3 in substantive ways. (We could use more such people, on both sides.) Having read your comment about talking about the GPLv3 ("FSF zealots will jump out of the woodwork and pester me incessantly to recant and confess"), I just felt the need to add such a disclaimer. :)

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.


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags