How Far Should GPL Enforcement Go? 432
itwbennett writes "The debate over enforcement of the GPL flared up again this week when Red Hat kernel developer Matthew Garrett wrote in a blog post that Sony is looking to rewrite BusyBox to sidestep the GPL. Which is a perfectly legal undertaking. But it raises the question: 'Is there social pressure within the Linux kernel community to not undertake GPL compliance action?' writes blogger Brian Proffitt. 'This may not be nefarious: maybe people just would rather not bother with enforcing compliance. Better, they may argue, to just let the violation go and get on with developing better code.'"
Re:Execution (Score:5, Informative)
"GPL isn't designed to force others to share"
Yes, it is. You can ask Richard M. Stallman if you don't believe me.
"but to facilitate sharing while letting the original authors get credited"
Yes, it is three letters too, but they are not G-P-L. The three letters you are looking for are B-S-D. Seriously: you described the BSD license, not the GPL.
Re:Non sequitur? (Score:5, Informative)
short version: RTFA
long version: Most GPL copyright owners aren't aware, don't care, or don't have the time/legal training to enforce GPL violations of their code. The Busy Box guys actively enforce the GPL license on their code. If you violate the busy box GPL license, they will not re-license it to you unless you also stop violating the license on all the other GPL software that's being distributed. If they replace busy box, nobody will bother them about the other GPL violations.
Go to hell; here's a map. (Score:5, Informative)
Is that really considered a derivative work just because they can see the source?
Proving an allegation of copying requires proving two elements: first, that the alleged infringer had at one time had access to the older work; and second, that there is a level of similarity between the two. "Access" can be as simple as having heard a song on the radio a decade ago (Bright Tunes Music v. Harrisongs Music).
Compaq decided to make lack of access clear when it reverse-engineered the IBM PC BIOS using a "clean room" technique. This involved having one team turn copyrighted code into descriptions of its (unprotected) functionality and a second team turn the descriptions into code, with all communications between the two teams carefully monitored. I've been told it might not be quite necessary to go that far, but in the business world, you'd often rather spend money on engineers than trial lawyers. In such a case, it's best to draw up a plan for "being able to tell IBM to go to hell, and having the federal judge draw them a map for exactly how to go there", as sigwinch put it a decade ago [slashdot.org]. (Here's such a map [mapq.st].)
Re:I'm not sure I understand (Score:5, Informative)
> Sony wants to not use GPL-licensed code in its proprietary products.
Well, no. If you RTFA, it suggests Sony wants to use GPL-licensed code except for projects the license is actually enforced. They'll use the Linux kernel because the Linux kernel community doesn't bother with GPL enforcement. They don't want to use Busybox because the Busybox developers will sue them for license violations.
Of course, it's a bit of a risky strategy. Just because someone hasn't enforced their copyrights so far doesn't mean they still can't or won't. You'd think their own lawyers would raise a stink about it...
Re:I'm not sure I understand (Score:4, Informative)
Re:as far as copyright law allows (Score:4, Informative)
Sorry, but no. Treat the industry as you want to be treated.
Ya know, the golden rule is a nice lesson we learned in grade school, but in the real world, if you treat others as you'd like to be treated, you're either treating them like dirt, or you're treating them well, and they walk all over you. It would work if everyone wasn't a sociopath and actually did treat people how they wanted to be treated, but there are too many people willing to take advantage.
It's not Sony's project! (Score:5, Informative)
Once again, Slashdot links to a blog instead of the original source. The linked blog gets its evidence from a wiki page at http://www.elinux.org/Busybox_replacement_project [elinux.org]
This page has a Q&A which clearly states that it is not a Sony project:
Q. Tim Bird, the proposer of this project, works for Sony. Is this a Sony project?
A. No. Although Tim is employed by Sony, he spends a portion of his employed time working on behalf of the embedded industry to improve Linux and encourage GPL compliance. As of February 2, 2012, Sony has not endorsed or agreed to support this project. This wiki page is for gathering information and project description information, to present to various companies to solicit support and resources for the project.
Q. Can Tim's creation of this proposal be used to infer anything about Sony's compliance record, future compliance intent, or other business practices?
A. Tim has only recently informed his management about this proposal, and Sony has not yet (as of 2/2/12) agreed to support it. So, "no, not really". Sony has a good compliance record, and has strong compliance policies in place. It has never been contacted by the SFC and has no expectation of being contacted by the SFC about any license violation of GPL software. Tim is doing this as part of his (paid for by Sony) role in the industry to address issues which inhibit the adoption of Linux in consumer electronics.
the argument (Score:5, Informative)
The argument that is being made in a nutshell:
Busybox copyright is enforced by the SFLC, which sues companies to get them to comply. When negotiating for compliance, they also request that the company in question comply with the GPL2 license on the Linux kernel. Now, for whatever stupid reasons, some companies don't want to release their kernel modifications for Android devices. So they think that by removing Busybox, the SFLC will no longer have a copyright claim that opens them to litigation which results in their releasing their kernel source. This reasoning is flawed, because there is another, much easier way to avoid Busybox litigation: put the source code on your web site. That's all it takes. They could keep their kernel sources, and just put up the Busybox source, and they would achieve the same thing.
The other argument being made by one developer is that enforcement action is pointless, because he hasn't seen any Busybox source opened up from this route that was worth anything. Others disagree, saying there was some useful code, and that it's not just about Busybox - the Busybox enforcement actions have also resulted in kernel drivers being opened up.
So, the "outrage" here is the allegation that Busybox is being rewritten so that companies can violate the copyright of the Linux kernel without being sued by the SFLC.
Re:I'm not sure I understand (Score:5, Informative)
You can read the actual complaint in the second link. It is not about any copyright violations of busybox code. He's whining about the fact that with a non-GPL busybox replacement he won't have an excuse to sue for Linux kernel GPL violations. Kernel developers are generally not inclined to sue anybody for not releasing the source code to kernel modifications, while busybox developers sue everybody in sight. If busybox is replaced, it would be more likely that device manufacturers who do not release sources for kernel modifications would be able to get away with it.
Re:I'm not sure I understand (Score:2, Informative)
Looks like your skimming didn't profit you much as you missed the entire point. The main point is this quote from Matthew Garrett [lwn.net]: "People want a Busybox replacement in order to make it easier to infringe the kernel's license." Sony DOES want to use GPL code in its proprietary products, it just doesn't want to use GPL code from people who actively enforce the license.
The thing is, being aware of a (L)GPL violation doesn't give you the legal standing to bring a case against the violator; you have to be the copyright holder. Some (L)GPL projects assign their copyright to the FSF, and the FSF takes care of the legal work from there. But a lot of the most important projects-- for instance, the Linux kernel- have no copyright assignment, and individual coders generally avoid getting involved in the legalities.
Just about the only** legal work being done for (L)GPL enforcement on non-FSF software is done by the Software Freedom Conservancy on behalf of the Busybox developers esp. Erik Andersen. This is a problem, and since they're the only ones involved in enforcement they use a controversial kind of leverage to try to make a bigger difference. When somebody's violated the GPL e.g. by distributing Linux-based router firmware without releasing source, the SFC's legal team tells them their violation of Busybox's GPL license has terminated their ability to use Busybox as per GPLv2 section 4 (the GPL "death penalty"). They can't distribute their Busybox-containing firmware any more -- even if they start shipping source for Busybox in compliance with the GPL -- until they have the copyright holders' permission. The SFC won't give this permission until they comply with the licenses of all the open-source packages included in the firmware-- most importantly, the Linux kernel.
So basically the Busybox guys have been the only reason a lot of people have complied with the kernel's GPL license. The rewrite of Busybox is basically being done so the SFC can't take corporations to task for their failure to comply with the GPL license of other packages.
If a few significant contributors to the kernel banded together, got common legal representation, and had their lawyers contact people about GPL compliance, this would be a lot less of an issue. But they don't.
**I should also mention the folks behind gpl-violation.org, but they are only active in European courts and have not AFAIK done much recently.
Re:Waste of time (Score:3, Informative)
"You can spend months trying to rewrite busybox"
Output from sloccount for busybox suggests its more like 50 months.
Busybox is highly optimized code, there has been a lot of rewriting to reduce space, without being an expert on how these estimates work, i suggest it underestimates the effort required to create.
Total Physical Source Lines of Code = 192,634
Development Effort Estimate, Person-Years (Person-Months) = 50.12 (601.42)
Schedule Estimate, Years = 2.37 (28.45)
Total Estimated Cost to Develop = $ 6,770,351
Re:Slashdot double standards (Score:4, Informative)
painting all of Slashdot with one brush only makes people dismiss your position.
You mean, exactly what you did in this post [slashdot.org] just earlier today?
Pot, kettle.
Re:Slashdot double standards (Score:2, Informative)
Sony should be applauded for making their own BusyBox alternative, rather than violate the GPL.
That's not what they're trying to do. Sony wants a non-GPL alternative to Busybox so they can avoid being forced to comply with providing source to other GPL'd components they distribute. There's nothing honorable or applause worthy in that.
Sigh and again with the bad summaries. (Score:5, Informative)
Sony is not doing this project the summary was wrong. From the FAQ on the project.
"Q. Tim Bird, the proposer of this project, works for Sony. Is this a Sony project?
A. No. Although Tim is employed by Sony, he spends a portion of his employed time working on behalf of the embedded industry to improve Linux and encourage GPL compliance. As of February 2, 2012, Sony has not endorsed or agreed to support this project. This wiki page is for gathering information and project description information, to present to various companies to solicit support and resources for the project."
It reason is that it seems that the authors of BusyBox are very willing to go after companies and sometimes ask for remedies outside the scope of compliance with the GPL. At least that is what they are claiming.