4 ms·

I don't like them and won't contribute to projects with them but isn't this the exact point of a CLA[1]? A textfile in the repo seems a lot easier to track and

I don't like them and won't contribute to projects with them but isn't this the exact point of a CLA[1]? A textfile in the repo seems a lot easier to track and audit than PR comments and a bot to chase people. 1. https://en.m.wikipedia.org/wiki/Contributor_License_Agreement https://en.m.wikipedia.org/wiki/Contributor_License_Agreemen...

thayne 2y ago
No. The purpose of a CLA is so that the owner of the project can use the code in a commercial product that might not comply with the OSS license (particularly if that license is a copyleft licence such as GPL, AGPL, or MPL) and/or they can change the license more easily.
- NegativeK 2y ago
  Python has a CLA that allows the PSF board to relicense the code to "any other open source license approved by unanimous vote".
  - lupusreal 2y ago
    Legally speaking, once they own the copyright, is there anything stopping the PSF from selling out and changing their policy to permit proprietary licensing? I have this same concern with GNU. I can imagine a future where some key figures have died or retired and the new org sells out and changes the license to something RMS never would have agreed to.
    - cowsandmilk 2y ago
      The PSF Contributor Agreement doesn’t assign copyright to the PSF, so your question doesn’t apply. Text from their contributor agreement: > PSF understands and agrees that Contributor retains copyright in its Contributions.
    - NegativeK 2y ago
      To go along with the other response, they don't own your copyright -- but I don't know if the language in the Python CLA actually holds them to the "we can only relicense to open source licenses" if challenged in a court. But that's not really a risk I care about. The PSF is a nonprofit that's clearly aimed at being a nonprofit, and a Future Evil Board is beyond what I'm going to worry about.
- bawolff 2y ago
  That's more the risk than the purpose. Some people do CLA's for that purpose, but sometimes it really is about having a paper trail that the software is open source, or to make it easier to sue people who violate the license.
  - thayne 2y ago
    A DCO [1] would serve that purpose better. It's possible that the desire to have the flexibility to change the license at some point in the future is initially well-intentioned (for example you may start out as GPL, but want the option to change to Apache 2.0 later), so having a CLA doesn't necessarily imply they plan on doing a rug pull. And of course there is probably also some cargo cult of using a CLA because that is what other projects do, but there are other ways of insuring everything is open source that don't require the contributor to give you unlimited rights. [1]: https://en.m.wikipedia.org/wiki/Developer_Certificate_of_Origin https://en.m.wikipedia.org/wiki/Developer_Certificate_of_Ori...
    - noirscape 2y ago
      Keep in mind that a DCO is not the same thing as a CLA; kemitchell has written about the subject[0]. In short - the DCO is specifically written to meet the needs of the Kernel and some of it's expectations assume the workflow of the LKML and the code style of the kernel. He lists 6 conditions that you'd need to meet before the DCO is useful for your project. The most notable ones are that or-later licenses aren't a good idea with a DCO, that you must put the license text in a file header and that there's a Signed-Off-By element in your commits. The DCO is also very patch oriented, rather than contributor oriented, which only works if your workflow has more contributors than patches (which isn't how most FOSS projects are organized; you usually have only a few contributors, who submit patches.) Finally, the DCO was put in place to resolve someone being annoying about the licenses rather than existing to unify the copyright of the Kernel behind one entity. [0]: https://writing.kemitchell.com/2021/07/02/DCO-Not-CLA https://writing.kemitchell.com/2021/07/02/DCO-Not-CLA
      - thayne 2y ago
- noirscape 2y ago
  ...and that's why the Free Software Foundation requires signing CLAs[0], those evil commercial, proprietary product making rapscallions! The reality is that without a CLA, copyright enforcement tends to turn into a complete mess. To be clear - that can absolutely be the point; a completely unenforceable copyright that's still enough of a mess to scare off violators can have it's uses; the Kernel jumps to mind. Linus and Greg have both been open about the fact that the license is there to encourage people to contribute as a carrot, not there as a stick to beat them over the head with. Explaining how the license works and why they'd really appreciate cooperation is much more useful for the LKML than it would be to keep a bunch of lawyers on standby and the fractured license helps achieve that goal. They're often used by corporations to rugpull a license change, but the original purpose of a CLA is just to ensure that there's one entity in control of the licenses, which is more useful if an entity prefers the stick approach to compliance. (Which the FSF I would say absolutely lands under by-the-by.) [0]: https://www.gnu.org/licenses/why-assign.en.html https://www.gnu.org/licenses/why-assign.en.html

thayne 2y ago

No. The purpose of a CLA is so that the owner of the project can use the code in a commercial product that might not comply with the OSS license (particularly if that license is a copyleft licence such as GPL, AGPL, or MPL) and/or they can change the license more easily.

NegativeK 2y ago
Python has a CLA that allows the PSF board to relicense the code to "any other open source license approved by unanimous vote".
- lupusreal 2y ago
  Legally speaking, once they own the copyright, is there anything stopping the PSF from selling out and changing their policy to permit proprietary licensing? I have this same concern with GNU. I can imagine a future where some key figures have died or retired and the new org sells out and changes the license to something RMS never would have agreed to.
  - cowsandmilk 2y ago
    The PSF Contributor Agreement doesn’t assign copyright to the PSF, so your question doesn’t apply. Text from their contributor agreement: > PSF understands and agrees that Contributor retains copyright in its Contributions.
  - NegativeK 2y ago
    To go along with the other response, they don't own your copyright -- but I don't know if the language in the Python CLA actually holds them to the "we can only relicense to open source licenses" if challenged in a court. But that's not really a risk I care about. The PSF is a nonprofit that's clearly aimed at being a nonprofit, and a Future Evil Board is beyond what I'm going to worry about.
bawolff 2y ago
That's more the risk than the purpose. Some people do CLA's for that purpose, but sometimes it really is about having a paper trail that the software is open source, or to make it easier to sue people who violate the license.
- thayne 2y ago
  A DCO [1] would serve that purpose better. It's possible that the desire to have the flexibility to change the license at some point in the future is initially well-intentioned (for example you may start out as GPL, but want the option to change to Apache 2.0 later), so having a CLA doesn't necessarily imply they plan on doing a rug pull. And of course there is probably also some cargo cult of using a CLA because that is what other projects do, but there are other ways of insuring everything is open source that don't require the contributor to give you unlimited rights. [1]: https://en.m.wikipedia.org/wiki/Developer_Certificate_of_Origin https://en.m.wikipedia.org/wiki/Developer_Certificate_of_Ori...
  - noirscape 2y ago
    Keep in mind that a DCO is not the same thing as a CLA; kemitchell has written about the subject[0]. In short - the DCO is specifically written to meet the needs of the Kernel and some of it's expectations assume the workflow of the LKML and the code style of the kernel. He lists 6 conditions that you'd need to meet before the DCO is useful for your project. The most notable ones are that or-later licenses aren't a good idea with a DCO, that you must put the license text in a file header and that there's a Signed-Off-By element in your commits. The DCO is also very patch oriented, rather than contributor oriented, which only works if your workflow has more contributors than patches (which isn't how most FOSS projects are organized; you usually have only a few contributors, who submit patches.) Finally, the DCO was put in place to resolve someone being annoying about the licenses rather than existing to unify the copyright of the Kernel behind one entity. [0]: https://writing.kemitchell.com/2021/07/02/DCO-Not-CLA https://writing.kemitchell.com/2021/07/02/DCO-Not-CLA
    - thayne 2y ago
noirscape 2y ago
...and that's why the Free Software Foundation requires signing CLAs[0], those evil commercial, proprietary product making rapscallions! The reality is that without a CLA, copyright enforcement tends to turn into a complete mess. To be clear - that can absolutely be the point; a completely unenforceable copyright that's still enough of a mess to scare off violators can have it's uses; the Kernel jumps to mind. Linus and Greg have both been open about the fact that the license is there to encourage people to contribute as a carrot, not there as a stick to beat them over the head with. Explaining how the license works and why they'd really appreciate cooperation is much more useful for the LKML than it would be to keep a bunch of lawyers on standby and the fractured license helps achieve that goal. They're often used by corporations to rugpull a license change, but the original purpose of a CLA is just to ensure that there's one entity in control of the licenses, which is more useful if an entity prefers the stick approach to compliance. (Which the FSF I would say absolutely lands under by-the-by.) [0]: https://www.gnu.org/licenses/why-assign.en.html https://www.gnu.org/licenses/why-assign.en.html