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.
Re: You?
Date: 2012-01-31 05:07 am (UTC)Red Hat, Inc. would therefore have to either bring enforcement action itself (which is probably not in Red Hat's best interests, as doing so is expensive and suing users doesn't always reflect well on a company) or transfer ownership of its copyrights to another person or entity (such as the Software Freedom Conservancy, Free Software Foundation, or Software Freedom Law Center).
Re: You?
Date: 2012-01-31 05:50 am (UTC)Re: You?
Date: 2012-01-31 06:40 am (UTC)http://www.vegasinc.com/news/2011/jun/14/judge-rules-righthaven-lacks-standing-sue-threaten/
Some Righthaven suits have been dismissed due to "lack of standing". They don't *own* the copyrights, they just have the right to sue. And you can't transfer the right to sue to someone else while retaining ownership of the copyright.
Re: You?
Date: 2012-01-31 09:19 am (UTC)Re: You?
Date: 2012-01-31 07:28 am (UTC)The DMCA, however, does allow authorized agents (and under penalty of law they must indeed be authorized) to issue takedown notices for specific cases of infringement on a network service. Beyond that though, such agents are just about powerless.
Re: You?
Date: 2012-01-31 07:39 am (UTC)In some court cases (e.g. those involving BusyBox and some GNU software), the Software Freedom Law Center led the litigation without having ownership of relevant copyrights. However, that was only possible because the owners of those rights filed the complaints and sought the SFLC's legal representation.
Re: You?
Date: 2012-01-31 09:23 am (UTC)The Software Freedom Law Center provides legal services, which could include GPL enforcement if desired, but they don't actively seek to do GPL enforcement on behalf of any particular project unless that project asks them to do so.
Re: You?
Date: 2012-01-31 06:54 pm (UTC)The lawsuits turned into a big self-financing thing where each settlement netted them somewhere around $20k and they used that to fund the next suit, and our involvement consisted of signing papers and mailing them back. (They decided to make an example of somebody once, and then we actually received a nice check. Most of the time, they just got expenses and we didn't get anything, but we weren't in it for the money. But as I said, I stopped being involved years ago, maybe the conservancy does things differently than SFLC did...)
There's nothing to stop other random contributors over the years (Manuel Nova, Glenn McGrath, etc) from getting their own legal representation and launching their own lawsuits, if they wanted to. Just like with the Linux kernel. (Although as project maintainers we had an easier time proving standing.) The fact is I withdrew my support from the lawsuits at the end of 2008 (when they attacked Cisco while I was _working_ with Cisco; my approach was effective, theirs threw a wrench in the works), but they continued with Erik and Denys as plaintiffs.
Re: You?
Date: 2012-01-31 07:10 pm (UTC)Re: You?
Date: 2012-02-01 01:42 am (UTC)Re: You?
Date: 2012-02-01 06:43 am (UTC)Dan Ravicher is taking time off to write a book, and he took the lead
on the Busybox stuff, but the Center continues.
Getting upset because litigation continued despite Rob's personal
interest in Cisco isn't a reason to put them down. Maybe Rob.