[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