Wake me when they GPLv3 something and create a development community around it so that they aren't the sole copyright holder.
By your own logic if Linux were a Microsoft product that wouldn't be good enough because it is only GPLv2.
A lot chunk of the .Net framework are under MIT license and include this:
https://github.com/dotnet/corefx/blob/master/PATENTS.TXT
Seems pretty comprehensive to me.
Not sure if you've actually looked at Microsoft's CLA or tried to contribute to any of their projects. The CLA signals that, despite having chosen how their projects are licensed themselves, they don't hold those licenses in high regard. And like most CLAs, it creates a needless barrier to entry and turns away real contributors. (Not that this is actually seen as a big concern within MS—at least it doesn't seem to be. Based on the projects I've been watching, development is very cabalistic [read: top-down] and that they might get some outside contributions because they're open source seems more like a nice also-have rather than an outright goal.)
And since you brought up the .NET patent grant, it's hardly comprehensive. It severely limits the practical chances of anybody doing anything with it outside of Microsoft's own .NET Core project and Mono—which is more or less another project under Microsoft control, now that they've acquired Xamarin.
All signs point to the .NET patent grant being specifically written to enable Microsoft's very own version of Sun/Oracle's "don't fragment Java" lawsuits. (Especially ironic given that the whole reason C#/.NET came about in the first place is because, in addition to Google being a target because of Android, the only other big target of such a suit was Microsoft themselves because of Visual J++.)
I think these are just good legal and business a lot of the time. They are the legal protection and audit trail showing that the person really did intend to license their IP.
colby@ruta-corsica:~/src/antiholism$ cat ./_drafts/clas.markdown
List of open source software projects which used to have CLAs but no longer do:
- Neovim ([Keyes])
- Node.js ([Cantrill], [Fontaine])
- Yeoman ([Monge])
List of open source projects that have never used a CLA:
- Linux
- Mozilla
- Swift
[Cantrill]: https://www.joyent.com/blog/broadening-node-js-contributions
[Fontaine]: https://nodejs.org/en/blog/uncategorized/notes-from-the-road/
[Keyes]: https://github.com/neovim/neovim/issues/3036
[Monge]: https://github.com/yeoman/yeoman/commit/5661a34df899126f0372d2c70c48f80b2a03a28f
Here's how most CLAs work, including how it works at Microsoft: The org bugs an anonymous contributor about signing the CLA after contributor submits his or her first change, and if sufficiently cajoled, said anonymous contributor sends in the signed CLA and is never bothered again. If the intent is to protect your org by ensuring you don't accept changes that the contributor doesn't have authorization to submit, then the CLA process outlined here is so ineffective against accidental violations that it's not even worth using. And that is to say nothing of deliberate violations.
Here are some questions to ask:
If I get my employer to sign off on a CLA today, who's checking four years from now to make sure I haven't changed jobs and the whole situation is still kosher?
If I wanted to submit changes to a project without getting permission from my employer, how does the CLA stop me from doing that, given that all of them allow an unemployed/underemployed contributor to say that he or she is the only one who owns rights to the code?
If I can't be trusted not to copy code from another existing project distributed under a conflicting license, how does the CLA stop me from doing exactly that and just lying about it?
If I wanted to sign the CLA with a false identity and submit code using that, how does the CLA stop me?
If the CLA is meant to be an assertion that the org is authorized to accept my changes, how is that at all different from the same assertion I make when I publish my fork or my patches under the same license the original project is using?
> They are the legal protection and audit trail showing that the person really did intend to license their IP
If you want to prove that the contributor really meant to allow you to distribute their changes, then point to the bug where the contributor submitted those changes.
> If you want to prove that the contributor really meant to allow you to distribute their changes, then point to the bug where the contributor submitted those changes.
Lawyers that I've spoken to don't agree with your analysis. Several subject matter experts have articulated a specific risk that a court could find that just because someone apparently submitted code to an open source project does not mean that they knowingly and intentionally did that. It's especially not clear what will happen if the audit trail is scant, in the sense that a commit shows up without any supporting documentation from the person who submitted it explaining their intentions. Just having licenses on the files, or just submitting patches to an OSS project is not enough to be an airtight legal defense.
There's also another aspect of this situation that you might be overlooking. Just because you might prevail in trial either way does not mean the cost of litigation will be equal. Imagine the discussion that I hinted at above playing out before a judge. The open source project owner claims that the code was submitted intentionally under the GPL. The alleged submitter claims that they never did that, and that the code audit trail is incorrect / doesn't capture intent / wasn't a binding contract. Now that's going to play out in a complex way during trial. Even if the court rules in favor of the project owner, that conversation might take a whole lot more time and energy than if there was a clear, obvious, specific contract showing that the submitter was releasing their rights to the project owner.
This audit trail has the capability to significantly simplify and fend off a frivolous lawsuit. Large companies are often sued in a frivolous way, and simply fighting off even totally baseless lawsuits can cost more dollars than settling, so steps taken to make the legal defense airtight have meaningful value from a business perspective.
The other things you're mentioning about CLAs won't be an obstacle to a trial judge. The investigation during a lawsuit will be able to establish whether a CLA was really signed by the submitter, and whether they truly intended at that time to contribute code under CLA / open license. The CLA will make this easier to establish. The other risks that you're talking about are largely risks of fraud which make the situation messy. I'm not sure what will happen if one person submits (and claims to have the rights to) IP that they don't actually own. There's probably precedent for who is liable in that situation. The project owner who requests a CLA and explicit assignment will probably be viewed more favorably by a trial judge, in the sense that they'll be seen as a business that's attempting to do the right thing in the legal landscape sense. An OSS project that just says, "We just take whatever code someone sends our way, while trusting blindly in what they say", will not necessarily receive the same positive treatment. The opposing counsel could easily spin the situation to make it look like the OSS project was knowingly accepting code that they did or should have known was not theirs to accept. The trial judge is going to have to disambiguate those facts. The CLA translates the situation into, "And the person submitted the code committed outright fraud and deceived the project owner", which will not necessarily be easy to establish merely from a commit. CLA demonstrates more of the submitter's mental state than a mere commit. It's far less likely that someone will "sign a CLA by accident" than that a commit could end up in the wrong place by accident.
There are a lot of ways in which CLAs are believed to provide meaningful value to organizations that employ them. Until these things go to court, it's hard to know for sure what will happen.
Even Microsoft's CLA has a backdoor that doesn't require the author of the code to sign the CLA. You can, for example, copy and paste some procedures from a compatibly licensed open source project and mark your submission as containing code from a third party source. (E.g., "What's <project>'s module resolution procedure? Ah, just copy the file defining that class into the source tree; it's already under MIT.")
And as for "knowingly and intentionally" submitting code, Microsoft's CLA in particular exacerbates this rather than ameliorates it, because it broadens the definition of a submission to one that I'm sure would surprise almost every contributor who has actually signed the thing. Any code that you even discuss in a channel affiliated and run for a particular project by Microsoft constitutes a submission if you are the original author of that code, regardless of whether you actually submitted a patch for inclusion in the project, or even made any sign of interest in the development of that project whatsoever. (E.g., signing the CLA and submitting changes for project X means Microsoft gains control of your work around project Y if you link or distribute a personal project on the message board or mailing list for such project Y). So that argument is bunk.
> The other risks that you're talking about are largely risks of fraud which make the situation messy.
I'm at a loss for words.
> An OSS project that just says, "We just take whatever code someone sends our way, while trusting blindly in what they say"
Weird to even use this characterization, since that's an accurate description of exactly the sorts of CLA processes we're discussing.
> The CLA translates the situation into, "And the person submitted the code committed outright fraud and deceived the project owner", which will not necessarily be easy to establish merely from a commit
I have a sort of rule of thumb that I think most readers follow whether they realize it or not. It goes like this, "The first person to use the word FUD loses." Even so, I'm having trouble seeing this comment coming off as anything but that. It comes off as nothing more than casting incredibly dubious aspersions.
Can you point to an instance where such a thing has actually come up in litigation? Alternatively, cite an instance where even just a credible threat of such a thing has come up.
Both Mozilla and Linux each have long and storied histories; both are poster children for what large, successful open source projects can achieve; and both have corporations with serious money backing them. They somehow have managed to get along fine for decades without anything like that posing a realistic problem for either project, or even worthy of a footnote in their history, for that matter.
For a more recent example, I'll point out again that Apple deliberately chose a CLA-free contribution process for Swift, which was initiated as an open source project only months ago. Do you think Apple has reason to believe that the threat you mention is a credible one but that their project (or maybe just some characteristic of the company) has some inherent detail that renders them immune to it in this case only?
CLAs, in the form that we typically see them, are bullshit, and almost every defense of them fares even worse. Once again, CLAs exist for one reason, which is to grant the recipient org rights beyond those they'd ordinarily only receive through the license (that they chose!), e.g., so they can redistribute it under alternative terms, should they decide to do that for whatever reason.
This would be a more productive discussion if you'd actually focus on that, rather than invoking unverifiable claims about advice from phantom counsel and the threat of submarine suits.
The whole SCO Linux controvery also seemed like a major problem for Linux at the time: https://en.wikipedia.org/wiki/SCO/Linux_controversies - it seemed to have a chilling effect that turned a lot of companies off to open source. The court case seemed to take several years to litigate, just to establish that Novell and not the SCO Group owned the copyright to the code. Why did that take so long to establish? The submission governance and CLA were put in place by some companies specifically to mitigate the threat of such a risk applying to them later. As Wikipedia explains regarding the rationale of CLAs: https://en.wikipedia.org/wiki/Contributor_License_Agreement#...
"Contributor Licence Agreements (CLAs) can be used to enable vendors to easily pursue legal resolution in the case of copyright disputes, or to relicense products from which contributions have been received from third parties. The purpose of a CLA is to ensure that the guardian of a project's outputs has the necessary ownership or grants of rights over all contributions to allow them to distribute under the chosen licence."
Emphasis is: "easily pursue legal resolution in the case of copyright disputes" (e.g., SCO Linux)
A lot of your argument seems to boil down to that because some people don't think there is a risk, that no one is right to rationally recognize a risk. I can't really comment on Apple's motivations for not requiring a CLA in Swift, just like I can't really comment on Apple's motivations for masterminding a criminal conspiracy to fix the price of ebooks (for which they were recently fined $450m). I can guess but I don't know for sure.
I think reasonable people could disagree about the risks involved in CLAs. It's not always the case that lawyers agree. As I pointed out originally, we don't have case law for all of this space. Insofar as you're implying that open source projects have been run without legal problems, I think you're wrong. Things like the SCO Linux controversy and the Oracle v. Google lawsuit about Java APIs make me feel like the industry as a whole is on less stable ground than everyone seems to think. Given that there are real cases where such problems have been specific issues, and given that many qualified people (not just me) explain this as their rationale, I don't think it's unjustified FUD. Can you provide a court case where one company sued another about an open source contribution, and the court clearly and convincingly ruled (in a short period of time): "You chose to contribute to open source, so live with it and stop wasting everyone's time". I haven't seen that. I've seen rather the opposite. The court will only muddle through what's happened with years of litigation at exorbitant cost. I've provided some examples of where this actually happened and has been messy, so if you wish to assert that this is all simple and CLA's aren't beneficial, then I'd like to ask you to provide a citation of a court case where such an issue was trivially resolved.
See also Jacobsen v. Katzer for case history. "The case is noted for its contentiousness, the parties filing 405 motions and other pleadings with the trial court, and two appeals to the Ninth Circuit Court of Appeals." (Wikipedia) The case was only resolved in 2010, and since it was settled out of court, I'm not clear whether it establishes binding precedent. As I understand it, the summary judgment left it open whether damages were owed. This is another example where litigation took years.
Are you also aware that the FSF employs copyright assignment to ensure that they can enforce licenses? https://www.fsf.org/bulletin/2014/spring/copyright-assignmen...
> In order to make sure that all of our copyrights can meet the recordkeeping and other requirements of registration, and in order to be able to enforce the GPL most effectively, FSF requires that each author of code incorporated in FSF projects provide a copyright assignment, and, where appropriate, a disclaimer of any work-for-hire ownership claims by the programmer's employer
CLAs are all about copyright assignment.
So in conclusion, I don't find your arguments convincing, in part because you seem to be overlooking or glossing over case history. From my perspective, there is a long and storied history of people actually running into problems in this area, and companies engaging in malicious lawsuits that are without merit specifically to harm competitors, and so on. There are examples of well-informed companies like the FSF taking steps specifically to mitigate these risks. For these reasons I understand why a company would want to protect itself from apparent and legally-advised risks with a CLA, and in general rely on more explicit contractual relationships rather than an open license agreed to without a clear meeting of minds.
http://ebb.org/bkuhn/blog/2014/06/11/nodejs-no-cla.html http://ebb.org/bkuhn/blog/2014/06/09/do-not-need-cla.html http://ebb.org/bkuhn/blog/2011/07/07/harmony-harmful.html