![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
The ongoing fight against GPL enforcement
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.
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.
no subject
Show me the code? Other than the original Linksys code drop circa 2003 which predated the SFLC?
By the way, as a result of that original lawsuit, Linksys ceased all in-house Linux development, replaced Linux with another embedded OS on most of their routers, and outsourced the maintenance of their old Linux stuff to Taiwan.
Five years later, Linksys (now owned by Cisco) started up its in-house Linux development again, hired _me_ as a consultant to help make sure they were properly compliant and doing good things with the community. In addition to publishing all source before the actual product shipped, I was advising them to do things like order their WRT610n serial adapters in bulk and put up a web page where hobbyists could order them, create and release OpenOCD jtag profiles for their hardware, and so on.
That's right before the SFLC hooked up with the FSF, and went back and sued Linksys (now owned by Cisco) AGAIN over the same 5-year-old code as in the original lawsuits (this time over a gcc 3.3 compiler they got from Broadcom, which produced bog-standard unmodified mips output, just like the current ones do; there was NOTHING to be gained from this code-wise. Also, Cisco never recieved the source to that compiler in the first place, but of course the SFLC didn't sue broadcom, they sued Cisco).
The result was that Cisco terminated the Linksys division, reassigned the developers to work on Windows, ended all in-house Linux development, and outsourced the maintenance-only level again (this time to Red hat I think), and started looking at non-linux embedded OSes for future products again.
THIS is why I'm trying to stop busybox from being used as a bludgeon against the world at large. The SFLC sued an awful lot of companies that never got source from their upstream vendor, and COULDN'T do so five years later (and a lot of cases were pretty old since they were grinding through the "hall of shame" backlog), but the SFLC never once sued that upstream vendor (generally some taiwanese company that half-assed a board support package for the hardware they shipped). Instead the SFLC went after the local companies for enough money to sue the _next_ one, and when we did get code drops they were obsolete worthless things with nothing we didn't already have. (Generally some random SVN snapshot, or a release version with a couple backports from source control. The "local modifications" were debug printfs, commented out lines, and the occasional hardwired global variable from people who didn't know how to use the config system properly.)
So tell me: where's all this great code we got out of the lawsuits? In the entire time the SFLC or Conservancy have had the right to sue people over BusyBox, where is ONE LINE OF CODE it resulted in? I honestly want to know, because I can't name any, and I WAS A PLAINTIFF!
no subject
no subject
B) If you want to launch lawsuits based on linux kernel copyrights, be my guest. Suing people over busybox to get kernel code is bass-ackwards.
C) If I started an enforcement action, I get to render it obsolete.
You're still bitching about Tim offering to _help_me_write_code_, and getting his employer to help too. You don't want that code written under those terms, because that code will COMPETE with your code.
It doesn't prevent busybox from being there. It doesn't prevent people from using my YEARS of contributions to busybox, under the same license terms they've always been under.
You're the one going "how dare you compete with me". I wrote the code being replaced, and I'm writing the code replacing it; you did neither. I'm the one who tracked down pro-bono legal representation and was a plaintiff in the lawsuits; you did neither.
I'm the one who consulted not just at Cisco while the SFLC sued it, but for IBM's lawyers helping defend them from the SCO lawsuitm and saw what was actually going on behind the scenes of intellectual property lawsuits in great detail. Heck, I wrote a week long series of articles for The Motley Fool on the five types of intellectual property a dozen years ago, the copyrights one is here:
http://www.fool.com/portfolios/rulemaker/2000/rulemaker000502.htm
I did that way back when because studying intellectual property law was a hobby of mine back in the 90's. (I remember when I visited the patent and trademark office in person with my grandfather, who lived in DC.)
And you're calling _me_ naieve?
Dude: I disagree with you from a far more informed position than yours. :)
Note: I banged on busybox to scratch my own itch. My current day job (at a totally unrelated company) does not allow any of its engineers, company wide, to use busybox in the product. Due to the actions of the SFLC. And they are not alone, this is STANDARD POLICY for anything based on Android. The "no GPL in userspace" thing is from _GOOGLE_, not Sony.
Right here:
http://source.android.com/source/licenses.html
I want my code to be used on Android, so I write new code that can.
Rob
no subject
wrong motivation ascribed
(Anonymous) 2012-01-31 06:23 pm (UTC)(link)-- Tim Bird
Re: wrong motivation ascribed
"Litigants have sometimes requested remedies outside the scope of busybox itself, such as review authority over unrelated products, or right of refusal over non-busybox modules"
If you're in compliance for the kernel and all the other GPL code on your device then there's no justifiable reason for the SFC to ask to see unrelated code. The only reason for this to be a concern to anyone is if they're simultaneously violating the license of Busybox and some other GPLed component.
no subject
(Anonymous) 2012-02-01 01:15 am (UTC)(link)Seems to work pretty well though. Looks like you're starting to get it.
"You're still bitching about Tim offering to _help_me_write_code_, and getting his employer to help too. You don't want that code written under those terms, because that code will COMPETE with your code."
Oh no, you are still very clearly completely missing the point here.
Original lawsuit
Well I could remember wrong, but what I remember from reading the original Wrt54G sources, it was pretty much directly from an taiwanese OEM/ODM company (gemtek?) which in turn was only slightly modified from the broadcom reference designs. There was not much evidence that linksys itself had done much more than the plastic shell of the wrt54g.