[carussell]

> Don't most large organisations require something similar with their own open source projects? I know Google and Facebook do.

Mozilla gets by without one. Apple's approach for managing Swift, too.

> It's just a way of confirming that you own the rights to your contribution, and that you explicitly give Microsoft permission to use it.

If that's all they wanted to do, they could get by with something resembling the terms that Mozilla gets its committer's to sign. Usually these CLAs are specifically written to go a lot further than that, though. They usually take away a lot of the contributors' bargaining power. Microsoft's CLAs included.

[magicalist]

> * Mozilla gets by without one. Apple's approach for managing Swift, too.*

Mozilla does have one.

> Code committed by you to a Mozilla Repository, whether written by you or a third party, must be governed by the Mozilla Public License 2.0, or another license or set of licenses acceptable to the Mozilla Foundation for the Code in question.

https://static.mozilla.com/foundation/documents/commit-acces...

Swift has a much shorter one:

> By submitting a pull request, you represent that you have the right to license your contribution to Apple and the community, and agree by submitting the patch that your contributions are licensed under the Swift license.

https://github.com/apple/swift/blob/master/CONTRIBUTING.md

[carussell]

Neither of those are CLAs. Please correct your comment.

I'm particularly perplexed why you linked to that Mozilla document, for two reasons:

1. It says what it is, and as I said above, it's not a CLA. I've signed that document. It's required by everyone to get commit access to the Mozilla repositories. Here's how it works if you want to contribute to Mozilla: you send in a patch, they accept it, and say thank you. Nobody has to sign anything. (The same process goes for Swift, by the way.)

2. I specifically mentioned such a committer's agreement in my comment. It's even in the part you quoted.

[magicalist]

> Neither of those are CLAs

I see your point now, but the steps are functionally equivalent. The person committing the code has to verify that it's licensable by the contributor under MPL2.0, which means copyright license, patent grant, etc.

The specific terms, however are down to the author of CLAs, not inherent to CLAs themselves. The Apache and the Google CLAs are fine, for instance, and look roughly equivalent to the terms of MPL 2.0.

I can see the user friendliness argument, but functionally it's the same thing. The swift CONTRIBUTING.md could just as easily put in some crazy line about patent negotiations.

> They usually take away a lot of the contributors' bargaining power. Microsoft's CLAs included.

Can you point out which part you object to specifically? On a quick read I don't see anything in here[1] that's not the equivalent of licensing your code to a project under a major OS license with a patent grant (e.g. Apache 2.0).

[1] https://cla.microsoft.com/cladoc/microsoft-contribution-lice...

[carussell]

> I see your point now, but the steps are functionally equivalent.

No, you're equivocating. This part never happens in the CLA-free world: I send a patch in to somebody and they tell me to sign the CLA before accepting it. Or: somebody else sends in to Microsoft some code I've written, and Microsoft tries to get in touch with me to sign the CLA. (This has happened. Not only is it not necessary, but the text of the CLA itself says it's not necessary. The developers of the project don't even understand their own CLA. This is not specific to Microsoft. I wrote about cargo-culted CLAs when Swift was opened up[1].)

> The specific terms, however are down to the author of CLAs, not inherent to CLAs themselves.

This isn't remarkable; I don't know why you chose to make a remark about it. It's fluff. It doesn't legitimize your (still uncorrected) comment, and it doesn't delegitimize mine. Superficially, though, it looks like it does. I don't like this.

> The Apache and the Google CLAs are fine, for instance, and look roughly equivalent to the terms of MPL 2.0.

I'm not going to analyze them here, but let's go with the "equivalence" stance. The argument becomes, "They're equivalent to the terms that are already in the license, so there's no need for them at all." That is, there's no reason not to accept the changes if the contributor never signs the CLA.

Of course, most of the time, the CLA isn't equivalent, which is why you're asked to sign it.

> Can you point out which part you object to specifically? On a quick read I don't see anything in here[1] that's not the equivalent of licensing your code to a project under a major OS license with a patent grant (e.g. Apache 2.0).

To use Apache 2.0 as a specific example, I already wrote a comment about it.[2] The CLA neuters the patent termination clause. This leaves the "beneficiary" of the CLA open to sue anyone over patents with impunity while keeping the hands tied of those on the other end of litigation.

1. https://news.ycombinator.com/item?id=10669891

2. https://news.ycombinator.com/item?id=10896722