The ongoing fight against GPL enforcement
Jan. 30th, 2012 06:10 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59GPL 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.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Re: You haven't even got half the story.
Date: 2012-01-31 05:20 pm (UTC)Sheesh, one reason I got into BusyBox development in the first place was that I wanted to create a Linux system even Richard Stallman wouldn't try to bracket with "Gnu/Linux/Dammit". A Linux system that didn't have a single line of FSF code in it.
When Pamela Jones (of Groklaw) referred me to the SFLC and I had my first phone call with them, one of the first things I asked was whether they had anything to do with the FSF. They explained that Eben Moglen used to run the FSF's legal arm but chose to distance themselves from him as Stallman got increasingly nuts. Then a year later they got back in bed with the FSF and launched the most counterproductive, disruptive crap since the Mepis lawsuit.
Anybody remember the Mepis lawsuit?
http://lwn.net/Articles/193852/
Where tiny Linux company shipping an Ubuntu reskin had a partnership with Ubuntu, with a quote from Ubuntu's founder in their press release announcing the partnership, but pointing to Ubuntu's servers for the packages they HADN'T MODIFIED wasn't good enough for the FSF, which sued them to make darn sure they were mirroring all 43,000 packages in the Debian repository.
You're not bitching about the way the binutils 2.17 tarball on the FSF's website got replaced in November by a new one containing GPLv3 source files, so people who want to stick with the old GPLv2 version get TRICKED into shipping GPLv3 code by RETROACTIVE RELICENSING, and the last GPLv2 release has been DELETED off the website.
ftp://ftp.gnu.org/gnu/binutils/
No, _that_ doesn't bother you.
A 2-clause BSD-licensed SUSv4+ command line is exactly what I'm writing at http://landley.net/toybox and if people choose to add to it, or find more uses for it, good for them.
Re: You haven't even got half the story.
Date: 2012-01-31 05:31 pm (UTC)Like I said, I have no problem with you working on a more liberally licensed version of Busybox. I don't even have a problem with *your* motivations. My objection is purely to the fact that the reason other people are interested in this is because they want to reduce the probability of being sued when they violate the GPL.
Re: You haven't even got half the story.
Date: 2012-01-31 05:57 pm (UTC)People can legitimately reduce their legal exposure to the GPL by not using GPL code. They are doing that now in a big way:
http://landley.net/notes-2011.html#16-12-2011
http://lwn.net/Articles/475901
People can legitimately reduce their legal exposure to BusyBox lawsuits by NOT USING BUSYBOX. They're also doing that now, by starting numerous other busybox-like projects, not just android Toolbox but:
http://beastiebox.sourceforge.net/
http://hg.suckless.org/sbase/
I was doing toybox _anyway_, I stopped work on it in 2009 because even if I could produce a technically better package than BusyBox (which is why I was doing it) I didn't think anybody would USE the result.
Tim pointed out that there is a niche with great demand for this. and I went "oh". He hasn't given me a dime. (It'd be nice if he _would_, but it's not like I haven't got a day job. At which I'd have to use toybox rather than busybox anyway, because we're not allowed to deploy GPL code in userspace, due to an edict from senior management before I started working here.)
Rob