5 ms·

The Community Corrosive Effects of CLAs (2021)

73 points by pabs3 4y ago

deleted 4y ago
[deleted]
joemaller1 4y ago
Define acronyms the first time they appear.
- mayapugai 4y ago
  Agreed! The term CLA wasn't even defined in the article. I had to look it up. PSA: CLA is Contributor License Agreement
  - lmm 4y ago
    Ok but WTF is PSA?
    - denkmoon 4y ago
      Sorry I don't understand the undefined acronym "WTF".
      - spartanatreyu 4y ago
        OK. But what is OK short for?
        tokamak-teapot 4y ago
        It's a misspelling of 0K, or 'zero Kelvin', meaning that there's no energy left to argue, so just 0K, whatever, let's go with what you're saying,
        doctor_eval 4y ago
        TL;DR
        danuker 4y ago
        I thought OK meant "zero kills", as in "none of our soldiers are dead"
        deleted 4y ago
        [deleted]
        jfoutz 4y ago
        The old old joke is “all correct”. I want to say it was about Andrew Jackson’s horrible spelling.
- deleted 4y ago
  [deleted]
- account42 4y ago
  > Define TLAs the first time they appear. FTFY
drunkpotato 4y ago
It would be helpful to explain what DCO (Developer Certificate of Origin, terrible name!) and CLA (contributor license agreement) stand for. I managed to get the idea from context and google though it would have been nice to be explicit in the post. The point about the balance of power and power dynamics involved is interesting. I think it applies more broadly as well. Are these really “agreements” when individuals have no ability to negotiate them? They seem more like playground rules.
- mattigames 4y ago
  You have no power over Netflix terms and conditions, still you _agree_ to them, so it's an agreement even if its not byproduct of a negotiation.
  - justinjlynn 4y ago
    Contracts of adhesion, yay.... /s
- danuker 4y ago
  You can fork the project and ONLY publish your contribution with the public license (i.e. GPL) instead of agreeing to also cede rights to the company. One problem is discoverability. GitHub lists forks in an un-sort-able manner.
  - RobotToaster 4y ago
    >One problem is discoverability. GitHub lists forks in an un-sort-able manner. This obviously doesn't solve the problem generally, but I recently found an extension called lovely-forks[1], that automatically shows the most starred fork for every github repository. 1:https://github.com/musically-ut/lovely-forks https://github.com/musically-ut/lovely-forks
rodgerd 4y ago
CLAs for foundations deserve considerable security, but that's nothing on CLAs for companies; I cannot ever see a good reason to sign on for one of those.
- okasaki 4y ago
  How about because your changes won't be merged if you don't?
  - wmf 4y ago
    I guess you could go one level back and not make changes if there's going to be a CLA for them.
    - sanxiyn 4y ago
      Merging a bug fix upstream relieves you of burden of maintaining it. It is good for both party, not just for upstream. I think signing corporate CLA, if required to merge, is quite reasonable in this case.
      - jabl 4y ago
        > It is good for both party, not just for upstream. Indeed. Maybe, then, it's the corporations who should have a think about requiring a CLA?
        thriftwy 4y ago
        Their business model may rely on dual licensing, whereas fixes coming from you are "nice to have"
    - Aachen 4y ago
      That's me! At least, I read the CLA and when it contains things like "please sign away rights that the law specifically made unwaivable like moral rights to your work", that's me not contributing.
hoseja 4y ago
Really weird to have rms as an example.
- danuker 4y ago
  I hope they don't invent a GPLv4 where nobody is allowed to use any code, period, then promptly switch all code under CLAs to it.
  - jchmrt 4y ago
    Even if something so absurd would happen, the version of the code from just before the change to a new license would still be available under the GPLv3. So everyone who wouldn't agree with this change (which would presumably be everyone), could simply fork the code from that point and continue under the GPLv3. The more realistic risk of a CLA on GPL'ed code is that the person in control would switch it to a more permissive license without the copyleft restrictions of the GPL. That would actually have a negative impact that others can't mitigate by forking (although with a fork you could of course again make any new code added to the project the original license again).
    - danuker 4y ago
      I was attempting humor. The FSF's mission is definitely not to make code unavailable, but to permit tinkering. But in seriousness, you are completely correct, and I agree with you.
- bbanyc 4y ago
  There is little chance of FSF changing the GPL as long as RMS continues to run it, given his monomaniacal, pathological obsession with software freedom at the expense of literally everything else, including basic human decency. But he's not going to live forever (thank god) and his successors might try to use GPL4 as a political wedge within the FOSS community. Put in restrictions on project governance and codes of conduct, make a violation unrelated to the software itself terminate the license, something like that. "Ethical source" didn't get anywhere but something backed with the heft of FSF might. (Given how RMS has stacked FSF with loyalists, it's probably more likely that they'd do something to punish "ethical source" than enshrine it. Both are equally corrosive in my view.) Or it might make FSF even less relevant. We'll see.
chrismorgan 4y ago
(2021)
- dang 4y ago
  Added. Thanks!
gregwebs 4y ago
There’s a CLA that places specific restrictions on how the contribution can be re-licensed: http://www.harmonyagreements.org/docs/ha-cla-i.html http://www.harmonyagreements.org/docs/ha-cla-i.html I think it’s fair to demand that clarity. Keep in mind though that if a project is already using a permissive license it’s always going to be easy to make the project open core or for someone to make a proprietary work with your contribution. Contrary to this article’s statements CLAs are actually easier for everyone involved at least on the second contribution due to the tools that exist. It’s just a checkbox on a PR.
bregma 4y ago
I don't understand how the advantage of the DCO is that the receiving organization does not have to track it: it's a declaration of authenticity that can be used to pursue remedies in court in the even of fraud. Contributors would need to sign and submit and organizations would need to track it for each separate contribution. A DCO is a CLA as far as I can see except on a per-contribution basis instead of on a per-contributor basis.
oytis 4y ago
Are there any community open source projects that use CLA by the way? I've always assumed DCO were for community open source and CLA were for corporate open source.
- CodesInChaos 4y ago
  The FSF requires copyright assignment or a public domain dedication for contributions to many of their projects. I'd consider that as equivalent to a CLA. The article mentions the Apache Foundation as requiring a CLA as well.
- mikecoles 4y ago
  Meshtastic requires a CLA.
kemitchell 4y ago
Good argumentation from very faulty assumptions. The Developer Certificate of Origin is not a contributor license agreement. (See https://writing.kemitchell.com/2021/07/02/DCO-Not-CLA https://writing.kemitchell.com/2021/07/02/DCO-Not-CLA.) It has no part that clearly says the contributor grants a license for their contribution, or on what terms. This is the main disadvantage of the DCO, especially in non-GPL projects. Not that it "encourages distributed ownership". A contributor license agreement doesn't change who owns any copyrights, either. That's a copyright assignment. FSF's copyright assignment paperwork isn't a contributor license agreement, either. Assignment != License. License grants in CLAs are often in different, broader terms than open source licenses for several reasons. For one, many open source licenses are ancient, without clear and complete license grants by today's standards. Second, part of the point of a CLA in many cases is to enable project stewards to change or legally upgrade license terms in the future. CLAs give them all the rights we can think of to license on whatever terms, so they're not caught short. There is no reason CLAs for a project can't be shared openly. If temptation to abuse of power were inevitable, we would see a lot more individual contributors to open projects who retained ownership of their copyrights suing project users about meaningless license violations for monetary settlements. Companies like Elastic have changed to new licenses for future development. None that I'm aware of has tried to change the license terms for previously released open work retroactively, and there are serious legal questions about whether this is even possible or practical. Bloggers and tweeters sow a lot of unfounded fear about "evil corporate relicensing" by using loose terms that can imply, for those ready to see it, that there are releases floating around out there with Apache 2.0 license notices that aren't actually Apache 2.0 licensed anymore. What actually changes is that ongoing development by those companies moves to new terms, and folks interested in continuing development under the old license terms either do or don't step up to "fork" from the last release under those terms.

73 points by pabs3 4y ago

deleted 4y ago

[deleted]

joemaller1 4y ago

Define acronyms the first time they appear.

mayapugai 4y ago
Agreed! The term CLA wasn't even defined in the article. I had to look it up. PSA: CLA is Contributor License Agreement
- lmm 4y ago
  Ok but WTF is PSA?
  - denkmoon 4y ago
    Sorry I don't understand the undefined acronym "WTF".
    - spartanatreyu 4y ago
      OK. But what is OK short for?
      - tokamak-teapot 4y ago
        It's a misspelling of 0K, or 'zero Kelvin', meaning that there's no energy left to argue, so just 0K, whatever, let's go with what you're saying,
        doctor_eval 4y ago
        TL;DR
        danuker 4y ago
        I thought OK meant "zero kills", as in "none of our soldiers are dead"
      - deleted 4y ago
        [deleted]
      - jfoutz 4y ago
        The old old joke is “all correct”. I want to say it was about Andrew Jackson’s horrible spelling.
deleted 4y ago
[deleted]
account42 4y ago
> Define TLAs the first time they appear. FTFY

drunkpotato 4y ago

It would be helpful to explain what DCO (Developer Certificate of Origin, terrible name!) and CLA (contributor license agreement) stand for. I managed to get the idea from context and google though it would have been nice to be explicit in the post. The point about the balance of power and power dynamics involved is interesting. I think it applies more broadly as well. Are these really “agreements” when individuals have no ability to negotiate them? They seem more like playground rules.

mattigames 4y ago
You have no power over Netflix terms and conditions, still you _agree_ to them, so it's an agreement even if its not byproduct of a negotiation.
- justinjlynn 4y ago
  Contracts of adhesion, yay.... /s
danuker 4y ago
You can fork the project and ONLY publish your contribution with the public license (i.e. GPL) instead of agreeing to also cede rights to the company. One problem is discoverability. GitHub lists forks in an un-sort-able manner.
- RobotToaster 4y ago
  >One problem is discoverability. GitHub lists forks in an un-sort-able manner. This obviously doesn't solve the problem generally, but I recently found an extension called lovely-forks[1], that automatically shows the most starred fork for every github repository. 1:https://github.com/musically-ut/lovely-forks https://github.com/musically-ut/lovely-forks

rodgerd 4y ago

CLAs for foundations deserve considerable security, but that's nothing on CLAs for companies; I cannot ever see a good reason to sign on for one of those.

okasaki 4y ago
How about because your changes won't be merged if you don't?
- wmf 4y ago
  I guess you could go one level back and not make changes if there's going to be a CLA for them.
  - sanxiyn 4y ago
    Merging a bug fix upstream relieves you of burden of maintaining it. It is good for both party, not just for upstream. I think signing corporate CLA, if required to merge, is quite reasonable in this case.
    - jabl 4y ago
      > It is good for both party, not just for upstream. Indeed. Maybe, then, it's the corporations who should have a think about requiring a CLA?
      - thriftwy 4y ago
        Their business model may rely on dual licensing, whereas fixes coming from you are "nice to have"
  - Aachen 4y ago
    That's me! At least, I read the CLA and when it contains things like "please sign away rights that the law specifically made unwaivable like moral rights to your work", that's me not contributing.

hoseja 4y ago

Really weird to have rms as an example.

danuker 4y ago
I hope they don't invent a GPLv4 where nobody is allowed to use any code, period, then promptly switch all code under CLAs to it.
- jchmrt 4y ago
  Even if something so absurd would happen, the version of the code from just before the change to a new license would still be available under the GPLv3. So everyone who wouldn't agree with this change (which would presumably be everyone), could simply fork the code from that point and continue under the GPLv3. The more realistic risk of a CLA on GPL'ed code is that the person in control would switch it to a more permissive license without the copyleft restrictions of the GPL. That would actually have a negative impact that others can't mitigate by forking (although with a fork you could of course again make any new code added to the project the original license again).
  - danuker 4y ago
    I was attempting humor. The FSF's mission is definitely not to make code unavailable, but to permit tinkering. But in seriousness, you are completely correct, and I agree with you.
bbanyc 4y ago
There is little chance of FSF changing the GPL as long as RMS continues to run it, given his monomaniacal, pathological obsession with software freedom at the expense of literally everything else, including basic human decency. But he's not going to live forever (thank god) and his successors might try to use GPL4 as a political wedge within the FOSS community. Put in restrictions on project governance and codes of conduct, make a violation unrelated to the software itself terminate the license, something like that. "Ethical source" didn't get anywhere but something backed with the heft of FSF might. (Given how RMS has stacked FSF with loyalists, it's probably more likely that they'd do something to punish "ethical source" than enshrine it. Both are equally corrosive in my view.) Or it might make FSF even less relevant. We'll see.

chrismorgan 4y ago

(2021)

dang 4y ago
Added. Thanks!

gregwebs 4y ago

There’s a CLA that places specific restrictions on how the contribution can be re-licensed: http://www.harmonyagreements.org/docs/ha-cla-i.html http://www.harmonyagreements.org/docs/ha-cla-i.html I think it’s fair to demand that clarity. Keep in mind though that if a project is already using a permissive license it’s always going to be easy to make the project open core or for someone to make a proprietary work with your contribution. Contrary to this article’s statements CLAs are actually easier for everyone involved at least on the second contribution due to the tools that exist. It’s just a checkbox on a PR.

bregma 4y ago

I don't understand how the advantage of the DCO is that the receiving organization does not have to track it: it's a declaration of authenticity that can be used to pursue remedies in court in the even of fraud. Contributors would need to sign and submit and organizations would need to track it for each separate contribution. A DCO is a CLA as far as I can see except on a per-contribution basis instead of on a per-contributor basis.

oytis 4y ago

Are there any community open source projects that use CLA by the way? I've always assumed DCO were for community open source and CLA were for corporate open source.

CodesInChaos 4y ago
The FSF requires copyright assignment or a public domain dedication for contributions to many of their projects. I'd consider that as equivalent to a CLA. The article mentions the Apache Foundation as requiring a CLA as well.
mikecoles 4y ago
Meshtastic requires a CLA.

kemitchell 4y ago

Good argumentation from very faulty assumptions. The Developer Certificate of Origin is not a contributor license agreement. (See https://writing.kemitchell.com/2021/07/02/DCO-Not-CLA https://writing.kemitchell.com/2021/07/02/DCO-Not-CLA.) It has no part that clearly says the contributor grants a license for their contribution, or on what terms. This is the main disadvantage of the DCO, especially in non-GPL projects. Not that it "encourages distributed ownership". A contributor license agreement doesn't change who owns any copyrights, either. That's a copyright assignment. FSF's copyright assignment paperwork isn't a contributor license agreement, either. Assignment != License. License grants in CLAs are often in different, broader terms than open source licenses for several reasons. For one, many open source licenses are ancient, without clear and complete license grants by today's standards. Second, part of the point of a CLA in many cases is to enable project stewards to change or legally upgrade license terms in the future. CLAs give them all the rights we can think of to license on whatever terms, so they're not caught short. There is no reason CLAs for a project can't be shared openly. If temptation to abuse of power were inevitable, we would see a lot more individual contributors to open projects who retained ownership of their copyrights suing project users about meaningless license violations for monetary settlements. Companies like Elastic have changed to new licenses for future development. None that I'm aware of has tried to change the license terms for previously released open work retroactively, and there are serious legal questions about whether this is even possible or practical. Bloggers and tweeters sow a lot of unfounded fear about "evil corporate relicensing" by using loose terms that can imply, for those ready to see it, that there are releases floating around out there with Apache 2.0 license notices that aren't actually Apache 2.0 licensed anymore. What actually changes is that ongoing development by those companies moves to new terms, and folks interested in continuing development under the old license terms either do or don't step up to "fork" from the last release under those terms.