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"?
Canadian Lacrosse Association
Canadian Library Association
Caprivi Liberation Army
Carry Look-Ahead Adder
Causal layered analysis
Certified Legal Assistant
Cigarette Lighter Adapter
Civil Liberties Association
Communist League of America
Conjugated linoleic acid
Contributor License Agreement
Cuban Liberator Army
Yes of course, the CLA. I have long hated CLAs. CLAs are a problem and someone should do something about the CLAs.
Next thing you know, they'll actually _make_ you RTFA...
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)
The purpose of CLAs is to maintain the hegemony for the ruling clique; the very point of a CLA is to provide the entrenched bureaucrats with a publicly acceptable reason for shutting the door on those pesky newcomers.
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.
The only licences I like are LGPL, MIT, BSD, etc. So basically licenses that don't restrict me in any significant way.
What you say is true of MIT and BSD licenses as well as the GNU All-Permissive License. But LGPL is really just GPL with an exception allowing linking the covered work to a proprietary program in such a manner that the user can replace the covered work with a modified version. This permission is unacceptable on platforms that have a general policy not to execute code that the platform's gatekeeper has not approved or code that has been modified since the platform's gatekeeper has approved it. So you can't really use an LGPL library in an application for an iOS device, major game console, or major handheld game system unless you're the author of the entire library or unless you have a dual license, and the featured article is about opposition to giving the library's maintainer the option of granting such a dual license.
Actually, the GPL doesn't restrict _you_, the developer, in any significant way.
It's 2014 and people are still spreading FUD about this. For god's sake.
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.
Normally, I see Linus being pragmatic about things, but I have no idea why he's against CLAs.
Having a CLA (with some form of copyright assignment or "unlimited" sublicensing) is the ONLY way to run a flexible, long-term Open Source project.
The Linux kernel is the only substantial project that doesn't do this, and, frankly, can only get away with it because it's so critical. Even there, it's a pain, because (to pick a stellar example), Linux will NEVER be able to relicense itself under an improved GNU license. It's stuck FOREVER on the GNU v2 license. Which is hardly a good thing.
CLAs are a consequence of copyright, just like the licenses themselves are. They're necessary to allow a project to update the license, defend the entire codebase in court, keep track of ACTUAL authors, etc. If you don't have this, you have a toy project, one which ultimately will fail to succeed.
If you don't like CLAs, then use the BSD or Public Domain route, because they're the only licenses (or non-license) that avoids all the traps of copyright law. Otherwise, if you want copyleft of any sort, then you have to use a CLA.
Linus is basically complaining that having a driver's license is an obstacle to people just getting on the road and driving whenever they want. Sure, CLAs restrict the "fly by night" patcher. That's a feature not a bug. Sometimes, you do want to set the bar higher than the lowest common denominator. Naturally, some CLAs are worse than others, but the concept as a whole is sound.
-Erik
There are always four sides to every story: your side, their side, the truth, and what really happened.
I've always thought that buying other companies is the first sign that a company has become creatively bankrupt. They now place more faith in the ability of strangers than they do in their own staff (or they'd build a competing product in-house).
Rampant carbon sequestration destroyed the Dinosaurs' tropical paradise. I'm here to help repair the damage.
I'm honestly a bit surprised that anyone interested in commentary by Linus Torvalds, Matthew Garrett and controversy over Canonical's policies in terms of copyright assignment (all of which is in the synopsis) wouldn't know what a CLA is.
I remember sigs. Oh, a simpler time!
Firstly, I'm not sure of examples where that's actually true, but it's at very least worth pointing out that the CLA that the FSF gives folks to sign (and FSF projects don't actually have to sign it, but they are encouraged to) stipulate that such code will always be available under a copyleft license---as Matthew Garrett points out in (one of) TFA. So regardless of any other distributions, the FSF has pledged that all code contributed under CLAs will be available to folks as copyleft-licensed code, end of story. That is fundamentally different from Canonical's CLA which contains no such clause, so unlike the FSF they could theoretically take a codebase proprietary and fail to release further versions under copyleft licenses. Big difference.
I remember sigs. Oh, a simpler time!
It would not be hard at all to find the users who are consistently moderated up in stories relating to a given job skill. Say every time the Linux kernel is discussed, several of your comments get moderated to five. Now a headhunter needs a Linux kernel coder. They call over to the good folks at Dice, who supply them your email.
Please mail me URLs of software employers.
LGPL3 and GPL3 prevent tivoization. LGPL2.1 does not
What GPLv3 and LGPLv3 call "Installation Information" GPLv2 and LGPLv2.1 call "scripts used to control compilation and installation". LGPLv2.1 does permit static linking of "the Library" (a covered work) with a proprietary program so long as the EULA does not rule out end user modification: "you may also combine or link a 'work that uses the Library' with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications." Option 6a lets the application publisher ship .o files of a "work that uses the Library" (that is, the proprietary parts of the application) and "any data and [specialized] utility programs needed for reproducing the executable from it" along with the executable, and option 6c lets the application publisher offer to distribute a copy of said .o files and data to the owner of a lawfully made copy of a combined work. The fact that such "data" would have to include a private signing key is how even LGPLv2.1 could be read to defeat tivoization.
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.
The signature is not required for rebuilding the executable, it is only required for installation and execution on a particular platform which the LGPLv2.1 does not specify is required.
Then we differ on how "the executable" is defined. Some platforms sign an installation package containing the executable, some sign the executable itself, and some sign both. For example, under Windows, both the MSI installation package and the EXE inside it can carry an Authenticode signature. Rebuilding "the executable" would require signing it.
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.
GPL2 code is not GPL3 compatible. That's inconvenient. If a copyright holder of something that is GPL2 licensed doesn't agree to relicense it, then you can't use any GPL3 code in it. That's a GPL3 rule, not a GPL2 rule.
This is precisely why the "or later version" clause is there. Any incompatibility is a problem of the software that was published under a modified GPL without this clause.
With Eclipse and Apache, the CLA is a Contributor License *Agreement*. It is NOT a Copyright *ASSIGNMENT*. Shame on Linus for spreading such FUD!
Linus gets it wrong again: The ASF does NOT require CLAs for "drive-by" patches. It only requires them for official contributors or committers, not for people providing patches on email lists, via JIRA, etc... Only when people have obtained the merit to directly change the official code is an iCLA required. As it *should be* for IP tracking. Double shame!
There is no "or later version" clause, nor does there need to be. The GPL2 license was perfectly valid at the time.
Wow, a Slashdot posting about Linus that doesn't include swearing, name-calling, or flame-baiting. Today is a good day.
"Here Lies Philip J. Fry, named for his uncle, to carry on his spirit"
The Red Pill meant that Neo *was* ready.
Unity? Screw that: XFCE. Slashdot Beta? Screw that: SoylentNews. Australis? Screw that: Pale Moon. UX developers DIAF
The "or later version" clause is in the FSF's recommendations on how to use the GPL. Lots of software has it. The GPLv2 license is still perfectly valid, but much software is available either under it or the GPLv3, also a perfectly valid license.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Signing is a post build process that takes place after the executable has been built.
The word "executable" means "able to be executed". On a platform that enforces digital signatures, a computer program is not executable (and therefore not an executable) until it's signed.
If i build an iOS executable but don't sign it it doesn't cease to be an executable.
On what platform is such an executable executable? If you can tell me which platform, I'll do my best to stop being obtuse.
But coming back to the beginning of the thread: Even though the GPL2 is perfectly valid, the FSF has declared in GPL3 that it is not a compatible license. Through their required copyright transfer, they are able to change the license on their projects from GPL2 to GPL3, thereby putting pressure on other GPL2 projects to relicense as well. That's not promoting freedom, that's promoting control.
Thank you. Let me approach a right angle: I thought the iPhone/iPad simulator used apps recompiled for x86 instead of being an actual emulator like the Android SDK's simulator. But you have a good point about jailbroken devices, at least until the current round of DMCA exceptions expires. At that point, anyone calling an unsigned iOS executable "executable" may be encouraging unlawful circumvention of access control measures.
Hey, check it out. My first post to reach both +5 funny **and** -1 flamebait.
Slashdot moderation is just hilariously broken. This, my friends, is why I read at -1 at all times.
I've fallen off your lawn, and I can't get up.