3 ms·

What's wrong with their CLA? Apache requires a CLA as well: https://www.apache.org/licenses/icla.txt https://www.apache.org/licenses/icla.txt I think these are

• carussell 11y ago
  If only that were why CLAs actually exist. 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 All told, CLAs are actually a terrible way to achieve the things they set out to do, except to grant the org additional rights that the existing project license doesn't handle. They're all ritual and guarantee nothing. (It doesn't help that the ritual is friction-inducing and helps turn away contributors, as I said before.) 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.
  • Pyxl101 11y ago
    The lawyers that I've spoken to don't agree. Until there is case law that sets precedent for how these situations are actually handled during a lawsuit, it's anyone's guess how much they matter. > 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.
• chei0aiV 11y ago
  A few articles about why CLAs are not needed: http://ebb.org/bkuhn/blog/2014/06/11/nodejs-no-cla.html 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/2014/06/09/do-not-need-cla.html http://ebb.org/bkuhn/blog/2011/07/07/harmony-harmful.html http://ebb.org/bkuhn/blog/2011/07/07/harmony-harmful.html