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: please do your homework first
Date: 2012-01-31 05:00 pm (UTC)Re: please do your homework first
Date: 2012-01-31 07:13 pm (UTC)I'm not seeing a fourth option there.
Re: please do your homework first
Date: 2012-01-31 07:36 pm (UTC)Re: please do your homework first
Date: 2012-01-31 08:44 pm (UTC)http://landley.net/hg/toybox/rev/12add511705e
You're complaining about what other people are doing. You didn't contribute code to busybox, you didn't contribute code to toybox, you weren't a party to the busybox lawsuits, you apparently haven't enforced the license on your own copyrights in court.
You're complaining that somebody who objects to the license on one project, and is personally contributing code to a replacement, and writing wiki pages to document and explain the project may have reasons for doing so.
You're not writing any code, you're criticizing people who do.
Re: please do your homework first
Date: 2012-02-01 01:05 am (UTC)...in order to undermine the development model of (much more important) software surrounding it. Great high ground, there!
Re: please do your homework first
Date: 2012-01-31 08:50 pm (UTC)I have the same problem here that Rob has. Are you saying I'm lying about my motive? How could you possibly know my intent? On LWN.net you lay out the logic for your belief that I want to do this because of the kernel. It's a nice bit of logic, but that's not what went through my mind when I made the decision to pursue this. My reasons for pursing this project are on the wiki page. I have ensured that Sony is compliant with it's kernel source release obligations for the last 8 years, and frankly its offensive for you to suggest that I'm trying to avoid my GPL obligations.
Also, I'm doing this, not as a Sony employee (although they pay for my time), and especially not with any kind of directive from Sony. No one else at Sony told me to do this, and only a scant few people know I'm involved.
I'm doing this because it pains me to see this legal issue disrupt the adoption of Linux in embedded systems. I believe the busybox litigation has had a net negative effect on the adoption of GPL software. Apparently you believe otherwise. Reasonable people seeing different examples of the effects on different companies, can disagree on this point.
You have your method of encouraging Linux adoption and GPL compliance, and I have mine. I see you don't agree with mine, but please don't question my motives.
Re: please do your homework first
Date: 2012-01-31 09:15 pm (UTC)1) People who follow all licenses. There's no reason for them to prefer a BSD-licensed Busybox over a GPL one.
2) People who infringe the Linux license but not the Busybox one. There's no reason for them to prefer a BSD-licensed Busybox over a GPL one.
3) People who infringe the Busybox license but not the Linux license. You haven't provided any examples of these people existing, so they're not a significant concern.
4) People who infringe the Busybox license and the Linux license. These people benefit the most from having a BSD-licensed Busybox, because it reduces the risk that they'll be sued over their other violations.
I can't believe that you're unaware of who gains the most from a BSD-licensed Busybox. You must know that the people most interested in having one are the companies that are actively engaged in infringement. So yes, I think you're either lying or painfully unaware of why there's corporate interest in having a BSD-licensed Busybox.
I'm out....
Date: 2012-01-31 11:37 pm (UTC)In particular, people who follow all licenses, Sony among them, are most definitely negatively affected by this litigation (or at least the people who want to work on Linux in them are, myself included).
It's not possible to have a rational discussion with you, if you won't take me at my word. You are too busy trying to make your points to listen. So I'm out...
-- Tim
Re: I'm out....
Date: 2012-02-01 12:53 am (UTC)The risk of being sued for accidental infringement is just as real for the kernel as it is for Busybox. Unless you're proposing to replace Linux (which would be a strange thing for the head of CELF to do) then a year or so down the line you're going to be just as vulnerable as you were before. You could spend the time working on a replacement for Busybox, or you could spend the time working out how to convince companies that the only long-term solution is for them to ensure that compliance checking is present at every stage of the procurement and development process.
The first of those choices helps infringers more than it helps compliant companies. The latter helps compliant companies more than it helps infringers. You've chosen the first, and then seem surprised that people are assuming malicious intent. But, whatever. The good news is that it's spurred increased interest in enforcing the kernel's license, which was an entirely predictable outcome.
Re: I'm out....
Date: 2012-02-01 01:14 am (UTC)How about educating the rest of us, at least a bit? I will freely admit that I have no idea how any company, large or small, could possibly find it difficult to comply with GPL licenses, other than in the particular case of using a low-bid supplier and not checking the result. More generally, I don't understand how any company can think it wise to use a pile of FOSS-licensed software without educating people on how to handle FOSS code properly, just as large companies have people specifically responsible for licensing the proprietary software they use. It still mystifies me how companies continue to screw this up when it takes to little to get it right.
And quite frankly, I'd rather see slower adoption of Linux and more GPL compliance than rapid adoption of Linux and widespread GPL violations. While some companies might shy away from using Linux because they've figured out that they might actually have to comply with the licenses, I keep seeing more and more companies actually shipping Linux and getting the details right. I see little GPL notices and offers of source code in numerous products that I use, which never used to appear before, and I can't help but credit some of the organizations enforcing the GPL for that.
Re: I'm out....
Date: 2012-02-02 03:39 am (UTC)Re: I'm out....
Date: 2012-02-03 09:21 am (UTC)Re: please do your homework first
Date: 2012-02-01 12:21 am (UTC)There's no point publishing it otherwise. (I write all sorts of stuff that never sees the light of day because nobody else cares, usually I lose track of it after I'm done and have to reimplement it later.)
None of the engineers at the company I currently work for is allowed to use busybox in the products we ship. Not because they're not compliant with the license, but because they don't want the _risk_ that a single mistake could shut down the entire production line and force a product recall.
Instead we have to use toolbox, which is crap. (And is intentionally crap because Google just made enough of a stub to launch Dalvik, and ignored the rest of userspace. It is _crying_out_ to be replaced.) I have to write tortured shell scripts that are limited to what toolbox can do, and implement things in C that should be grep/sed/sort but I haven't got 'em.
Writing busybox was scratching my own itch. I cannot use busybox to scratch my own itch anymore, and don't expect to be able to in future in any professional context, because the SFLC poisoned it.
To quote the second doctor, "That thing out there's become a killer. It's _my_ fault, and I'm _sorry_."
And like The Doctor, I gotta go fix it now...
Re: please do your homework first
Date: 2014-02-12 03:31 pm (UTC)The exactly same risk are taking licensing propietary software, a single mistake or legal hole in the license could allow the users copy/use the software against the interest of the company.
But the last never happen (or I have never seen) because companies take it seriously, while complaining with GPL have not been considerer important for them.
Re: please do your homework first
Date: 2014-02-13 11:51 am (UTC)Re: please do your homework first
Date: 2012-02-01 12:33 am (UTC)> BSD-licensed Busybox over a GPL one.
http://mimiandeunice.com/2011/09/01/trigger/
Rob
Re: please do your homework first
Date: 2012-02-01 12:55 am (UTC)