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}
no subject
Date: 2012-01-31 12:26 am (UTC)While the underlying reasons are lame and undesirable from an OSS perspective, I'm having a hard time finding fault here. It's like the old joke about Doctor's advice that says, if it hurts when they do something, they should probably stop doing it. In this case, if using GPLed code is getting them sued, one possible solution is to comply with the license, the other solution is to simply stop using GPLed code. Both are equally valid choices, even if one is less desirable from an OSS advocacy perspective.
The onus is on the OSS community to clearly articulate the value provided by compliance that exceeds the value achieved by going back to a mix of proprietary and BSD licensed code.
no subject
Date: 2012-01-31 12:30 am (UTC)no subject
Date: 2012-01-31 03:10 am (UTC)They're basically saying: "we know full well what the implications are of the GPL, but hey, that GPL code is so darn dandy. Let's just avoid this bit here, so it's less likely someone will force us to open up."
This tells me that companies have no intention to abide by the terms of the GPL in the first place. They only grudgingly do it if someone shows up and litigates.
Honestly, if I had embedded GPL code that was likely used (ie. kernel), I'd make it a point to a) proclaim on that wiki that anyone participating in such an endeavor would get extra close attention. And b) simply not reinstate their license, so they'd stuck with a lot of bricks they can't sell.
Maybe I'm a bit petty. But really - abide by the license. There's a lot of BSD/MIT/ISC code out there, there's nothing wrong with it, and as a developer there are sometimes good reasons to prefer one of these over the GPL. But that's up to the developer!
no subject
Date: 2012-01-31 11:05 am (UTC)Look, my personal problem with GPL -- and the reason that I've moved towards more permissive licenses in my own work -- is that there are too many questions involved.
Copyright licensing is fundamentally about the conditions under which you can bring a lawsuit. Any moral or ethical pretense is just bluster -- this is about a legal right, namely, the legal right to copy. The GPL seems to say a lot of things, like "we will sue you if you don't GPL your own work" -- in other words, "we will sue you if you don't threaten to sue other people." What if I release something linked to that file with GPL, but then make it clear that I never intend to enforce the threat -- that as far as I'm concerned, I release my own work under a more permissive license, and if you use my work without GPLing yours, that's okay by me?
Can the project that I'm using sue me? Can they sue someone else who uses my project?
What is "linking" in the GPL, anyway? If my Python code says "import pyskein" does that count? Is the whole Python software license incorrect, simply because they have a "readline" module and readline is GPL and Python is not-GPL? When does something stop being "linking" and start being "systems libraries"? Should I be worried that everything I have ever written in Python is about to become GPL, and I will be legally compelled to threaten to sue others?
What is "the preferred form of the work for making modifications to it"? Is gzipping the source code forbidden by GPL, simply because "that's technically object code"...? And suppose by fiat I decide to say "we are no longer going to make modifications to this product except by hand-modifying the compiled binary" -- is a 'finished' compiled software package no longer coverable by GPL?
What if I license some original code under GPL to you, but forget to give you the source code? You can't convey my works without the source code, but it's a license, not a contract, so you can't compel me to give you the source code either. So you can GPL something while keeping it totally proprietary. Are there other exceptions where the GPL becomes a proprietary software license?
Look, I don't want to sue you. I don't want you to sue me. That is the purpose of a free software license. I understand that the Free Software Foundation wants to stop other people from suing other people, and is trying to enforce this threat with lawsuits, but... for me that just seems like a distant problem which I don't want to have to deal with.
(I hereby release my copyright to this comment under the Creative Commons Zero waiver/license. This comment comes with NO WARRANTIES express or implied.)
-- Drostie
no subject
Date: 2012-01-31 01:03 pm (UTC)First of all, thinking of licenses (copyleft or otherwise) in terms of threats of lawsuits gets it entirely backward. Copyright itself puts you in that position. Copyright gives you a pile of exclusive rights over your code; licenses then grant those rights to others. FOSS licenses provide exceptions to copyright law, providing broad grants of permissions with some conditions attached. You start with a copyrighted work, which normally would not permit copying, modification, or redistribution, and apply the GPL to it, which allows all of those things on the condition that any derived work must also allow all of those things. That seems like a pretty generous offer to me; perhaps not quite as generous as an all-permissive license, but I personally agree with the goals of copyleft, and I see nothing wrong with saying "share and enjoy but don't make it proprietary".
You don't have to use the GPL on your software just because you derive from GPLed code; you can use any GPL-compatible license, which includes all-permissive licenses. The GPL still applies to the overall derived work, but anyone can take your permissively licensed code out of that work and use it under that permissive license, if you want that. A GPLed project can require that you use a GPL-compatible license on your work when it derives from theirs, but they cannot require that you use the GPL itself for that work.
The GPL says absolutely nothing about linking. The GPLv2 talks about derived works, a term defined in copyright law. The GPLv3 uses its own terminology ("propagate"), carefully defined in the license, but it effectively amounts to "anything which would have been covered by copyright law": 'To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.'
While linking often creates a derived work, it doesn't necessarily do so in all cases, and conversely a derived work may exist even in the absence of linking.
A Python program that imports pyskein probably represents a derived work of pyskein. Since pyskein appears to use the GPL, that would then require that the Python program derived from pyskein use a GPL-compatible FOSS license. On the other hand, a program configurable to use umpteen different hashes through a standardized interface does not become a derived work of pyskein simply because pyskein provides that standardized interface.
Similarly, Python's use of readline does not require you to use a GPL-compatible license on your Python programs, unless your Python programs actually use readline.
The "system library" exemption in the GPL (both v2 and v3) has a very narrow definition, which seems fairly self-evident just by reading the license. If a proprietary (non-GPL-compatible) library normally ships with the platform your program builds for, and you don't ship that library with your program, you can link to it even from GPLed code. This allows people to ship GPLed software for Windows and OS X, even though the standard libraries for those platforms do not use GPL-compatible licenses (and don't ship with source code).
"Preferred form for modification" has a similarly straightforward definition; apply your common sense as a programmer. Compressing the source code (reversibly) rather obviously doesn't affect this; source code in an archive does not magically become object code. (Of course, using an archive format nobody else has an un-archiver for does not work, but common sense should tell you that.)
If you as the programmer write a work entirely in machine code, you could certainly make a convincing argument that the machine code represents the preferred form for modification. (That would make your work hard to maintain, but not proprietary.) However, that argument won't fly when you started out with a pile of someone else's GPLed source code, modified it, compiled it, and then threw away the source.
If you give me a binary built from someone else's GPLed code, and don't give me access to the source code as required by the GPL, you've violated the license; the copyright holders can't compel you to distribute source, but they can compel you to stop violating their copyright, and since nothing other than the GPL gives you a license to distribute, you'd need to stop distributing and possibly provide other remedies. (Distributing source code generally represents the least painful option, hence why most GPL enforcement leads to that result.) On the other hand, if you have sole authorship of the code, then you can do whatever you like (since you have all the necessary rights already without needing the license), but in doing so you've created something unredistributable.
Either way, once I have a binary without corresponding source, I can't distribute it to anyone else because in doing so *I* would violate the GPL. I can't compel you to give me the source code, but that doesn't excuse me from my own obligations. To quote the GPLv3 (v2 has an equivalent provision): 'If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all.'
(Also, whether the GPL works as a license or a contract depends on jurisdiction, but the difference doesn't really matter.)
So, again, all of the questions you've asked have come up many times before, and they have well-known answers. The GPL does not represent some wild west of licensing uncertainty and open questions; using it puts you on well-trodden ground. And most importantly, the GPL and other FOSS licenses don't represent threats of lawsuits, but grants of permission that you wouldn't otherwise have.
You're wrong
Date: 2012-02-03 08:26 am (UTC)The purpose of legal counsel before the fact is to be professionally risk averse, and so the only measure of success or failure is gong to be in terms of ability to mitigate risk.
Personally, if I were in Sony's position, I'd do exactly the same thing, especially if my parts supplier were Qualcomm and I was contractually obligated to not reveal the contents of the hypervisor on the Snapdragon ARM processor I used (and in fact could not, because only Qualcomm had it in the first place), or if my supplier were nVidia, and I couldn't reveal the signing keys needed to allow you to comply with the ability to run your own kernel because, frankly, again, only nVidia has them.
Both of these derive from governmental obligations these companies face when these chips are used in mobile phones, and unless those go away, you have a chain of risk that leads to needing to rewrite to get out from under the GPL.
no subject
Date: 2012-01-31 04:24 pm (UTC)Android has an explicit "no GPL in userspace" policy, including LGPL:
http://source.android.com/source/licenses.html
The toolchain replacement is next: everybody stayed with gcc 4.2.1 and binutils 2.17 (the last GPLv2 releases, although the FSF replaced the tarballs on its website with ones it retroactively added GPLv3 files to in 2011). Apple is sponsoring LLVM/Clang, the BSD guys got together to revive pcc and bring it up to date, and companies like Qualcomm are contributing to Open64.
Linus has been ok with binary-only modules in Linux, and digital signatures for locked down hardware, and basically everything else crazy idiots have wanted to do. But if GPL enforcement lawsuits on Linux became a thing, they're quite capable of doing their own development. (It's worked out pretty well for Apple so far...)
I'm not a fan of denying reality. The BusyBox license enforcement lawsuits were a HORRIBLE IDEA, I regret having started that ball rolling, I couldn't stop it. I can only render it irrelevant with fresh development.
no subject
Date: 2012-01-31 10:55 pm (UTC)no subject
Date: 2012-02-01 07:39 pm (UTC)My comment was that if you want them to stop, we've got to provide a compelling reason for them to stop beyond just avoiding being sued.
Like it or not, many businesses operate under the presumption that anything not explicitly illegal is permissible. This includes the supporting viewpoint that, until they're caught, it ain't illegal. (See also: Enron, Tyco, and nearly the whole banking industry.)
I'm not saying these people aren't unethical scumbags. I'm just saying they exist and operate under a different paradigm than more principled folks. ;-)
So, just like your previous blog post about the economic disincentives around open sourcing products, we need to get better about clearly articulating how OSS saves them money and even makes them more money than continuing to operate in a closed environment.
But they aren't...
Date: 2012-02-02 11:46 pm (UTC)And, fuck Sony right in the ear for even suggesting just ditching Busybox and violating every other license.
Re: But they aren't...
Date: 2012-02-03 05:00 pm (UTC)