Slashdot Mirror
Linus Torvalds: Any CLA Is Fundamentally Broken
sfcrazy writes "The controversy over Canonical's Contributor License Agreement (CLA) has once again surfaced. While Matthew Garrett raises valid points about the flaws in Canonical's CLAs, Linus Torvalds says 'To be fair, people just like hating on Canonical. The FSF and Apache Foundation CLA's are pretty much equally broken. And they may not be broken because of any relicencing, but because the copyright assignment paperwork ends up basically killing the community. Basically, with a CLA, you don't get the kind of "long tail" that the kernel has of random drive-by patches. And since that's how lots of people try the waters, any CLA at all – changing the license or not – is fundamentally broken.'"
Why doesn't the summary for articles like these spell out unfamiliar abbreviations such as "contributor license agreement"?
Yes of course, the CLA. I have long hated CLAs. CLAs are a problem and someone should do something about the CLAs.
Free and Open source software are about working together to write software, its unquestionably good.
There are tens of billions of dollars worth of Libre code out there, with thousands of unpunished violators, and only 2 or 3 people in the world defending it.
And this "community" persistently rallies against working tegether Legally with CLA, i just dont understand, is it purely a trust thing ?
(And if you want to help defend Free Software, consider donating to the Software Freedom Conservency)
But he's a wise asshole. Not cow-towing to the fail that is GPL 3 (kernel, git and subsurface.) Not climbing on the CLA bandwagon...
One day Linus will be gone and Linux will probably fall into the hands of license-mongering zealots. I'm glad I probably won't be around to suffer that.
Lack of trust.
This is what this is all about. Many people view Canonical as untrustwory for one reason or another. I could cite a whole litany. However, that's not the point.
Many people find reason to be suspicious of Canonical in a way that isn't comparable to anything regarding the FSF or Apache. It's not a remotely comparable situation.
As a general rule, CLAs originating from any corporation with the standard "fuck everyone else" style charter should be met with skepticism. They're not your friends. They probably aren't even your ally.
A Pirate and a Puritan look the same on a balance sheet.
Take a look at pretty much any major CLA out there.
I'll name three big ones: OpenJDK, FSF's for GNU, and Apache's.
ALL of them either directly assign the copyright of the contribution to the org, and thus, you lose any ability to control it whatsoever, or give the org the ability to relicense it explicitly.
This is intentional, and a GOOD thing, because it increases the flexibility of the project, including making it easier to defend rights in court. Frankly, have a project with multiple copyright assignment is impossible to manage from a legal standpoint, let alone one where you don't even know the real identity of a contribution's author.
The Linux kernel is stuck on the GNU v2 license for exactly this reason, and can never change. That's the fate of any such non-CLA'd Open Source project (other than something using Public Domain or the BSD license).
FYI: the FSF can (and has) relicensed code contributed to GNU projects under a proprietary license. (gcc and part of the toolchain)
There are always four sides to every story: your side, their side, the truth, and what really happened.
On the contrary, Linux is quite right. Lots of long-term open source projects don't require copyright assignment and I'm not likely to work for any which do. The reason is quite simple: If I'm contributing my time and effort to a project, I don't want the project's code to get relicensed without my concent. If a company, such as Canonical, wants me to contribute then they should be prepared to let me keep copyright of my code so I can be assured it won't get tucked away in a closed source project.
The Linux kernel not getting relicensed under a newer form of the GPL is a feature, not a bug. Some companies which use Linux now wouldn't if it switched to the GPLv3 because the newer license isn't as friendly (or easy to read) as the old one.
Normally, I see Linus being pragmatic about things, but I have no idea why he's against CLAs.
Linus doesn't like them because it's an extra barrier for people who might want to contribute to the code. The more barriers you have to contributors, the fewer will contribute. I can tell you that I fixed some bugs in Android, which I didn't contribute back, because the process was too painful (and that was before I realized there was a CLA; if I'd known that, I wouldn't have even tried).
Of course, there are benefits to CLAs, as you point out, and Eban Moglen points out other benefits. It's a matter of choosing what your priorities are. Linus favors the ease of contribution. He also considers the fact that Linux is stuck forever on GPLv2 to be a feature, not a problem.
"First they came for the slanderers and i said nothing."
A lot of people who skim Slashdot's front page don't know enough to know whether they need to care about a particular story. People don't know what they don't know.
Let me just go ahead and call this bullshit. I am a committer to Apache HBase, and we see (and encourage) drive by patches all the time. The only folks who have to sign a CLA are the committers themselves, which seems reasonable to me.
Yeah, explain that to me in 10 years when some court rules that contributions under the GPL are illegal to distribute due to some legal deficiency in the license.
Actually, it is much more likely that a CLA will be found to be unenforcable than the text of a well-established software license. In fact, CLAs requiring copyright assignment are probably void in large parts of the world, meaning you are back to square one.
OS Reviews: Free and Open Source Software
Linus is correct: even at Slashdot I see a lot of people hating Canonical just for the sake of doing it. They systematically hate Mark Shuttleworth and every new component that is introduced to Ubuntu.