3 ms·

Can somebody explain the difference between a CLA and a DCO arrangement when the project license is a permissive license like MIT? From what I understand, the

Can somebody explain the difference between a CLA and a DCO arrangement when the project license is a permissive license like MIT? From what I understand, the main difference between a CLA and a DCO is that a CLA is typically used to transfer ownership of the contribution in all but name (where ownership is meant to be understood as the right to control the contribution's destiny and not just due credit on authorship) to the project maintainers, whereas a DCO allows the contributor to retain ownership. This can be important in projects that are licensed under, say, the GPL, because it ensures that the wishes of the original contributors to keep the code freely and openly licensed are respected. If the maintainers wish to relicense the codebase under a more permissive license, then they need the permission of their contributors under a DCO, but not under a CLA where they maintain full legal control. But if the code is permissively licensed, say, under MIT, then a malicious maintainer (or forker) can easily take the code, change it, sell it, do whatever the hell he wants with it - so what, exactly, does a DCO give a contributor compared to a CLA? The ability to restrict his code from being relicensed verbatim under a license like the GPL? The "draw" of being the target of a liability lawsuit of somebody who wants to test the no-warranty clause of the MIT license in court? What is ownership worth under MIT+DCO?

floatboth 9y ago
> a malicious maintainer (or forker) can easily take the code, change it, sell it That's… literally not malicious at all (except if the original copyright notice is removed). > what, exactly, does a DCO give a contributor compared to a CLA? Not being required to sign anything. CLAs are just annoying, especially when the signing form requires personal information (hi Google).
- opportune 9y ago
  Exactly, you choose the MIT license over the GPL because you are explicitly ok with this scenario. It's like the entire point.
  - jordigh 9y ago
    You can sell GPLed software too. Allowing commercial use is part of the definition of free software and open source. People sell phones with Android in them; Red Hat sells lots more.
    - opportune 9y ago
      True, not sure why but I guess I thought it was implied that the "malicious maintainer" would take the software closed course.
      - mcguire 9y ago
        ... which is explicitly okey-dokey with the MIT license, but not the GPL.
- solatic 9y ago
  > That's… literally not malicious at all Yeah, 'malicious' was probably the wrong word choice there. What I meant was somebody acting in such a way as to fully take advantage of / exploit the code without regards to the wishes of the owners, which you would ordinarily think of as 'malicious' except that pretty much the whole point of the MIT license is that the owners wish for you to do just that, so it's not ethically wrong in the sense that 'malicious' is. > Not being required to sign anything. Is a DCO even legally binding then, if this is the point? Makes it sound very "gentleman's agreement"-ish, in that a contributor who later regrets licensing his contribution could sue the maintainers for copyright infringement for not abiding by a cease and desist to immediately purge the relevant commits from the project, which the maintainers won't be able to do of course because it would leave the project in an unusable state.
ajdlinux 9y ago
The point of the DCO is to protect downstream, not upstream. It's a method of certifying the origins of the code, no more, no less. There's no transfer of rights whatsoever in either direction.

floatboth 9y ago

> a malicious maintainer (or forker) can easily take the code, change it, sell it That's… literally not malicious at all (except if the original copyright notice is removed). > what, exactly, does a DCO give a contributor compared to a CLA? Not being required to sign anything. CLAs are just annoying, especially when the signing form requires personal information (hi Google).

opportune 9y ago
Exactly, you choose the MIT license over the GPL because you are explicitly ok with this scenario. It's like the entire point.
- jordigh 9y ago
  You can sell GPLed software too. Allowing commercial use is part of the definition of free software and open source. People sell phones with Android in them; Red Hat sells lots more.
  - opportune 9y ago
    True, not sure why but I guess I thought it was implied that the "malicious maintainer" would take the software closed course.
    - mcguire 9y ago
      ... which is explicitly okey-dokey with the MIT license, but not the GPL.
solatic 9y ago
> That's… literally not malicious at all Yeah, 'malicious' was probably the wrong word choice there. What I meant was somebody acting in such a way as to fully take advantage of / exploit the code without regards to the wishes of the owners, which you would ordinarily think of as 'malicious' except that pretty much the whole point of the MIT license is that the owners wish for you to do just that, so it's not ethically wrong in the sense that 'malicious' is. > Not being required to sign anything. Is a DCO even legally binding then, if this is the point? Makes it sound very "gentleman's agreement"-ish, in that a contributor who later regrets licensing his contribution could sue the maintainers for copyright infringement for not abiding by a cease and desist to immediately purge the relevant commits from the project, which the maintainers won't be able to do of course because it would leave the project in an unusable state.

ajdlinux 9y ago

The point of the DCO is to protect downstream, not upstream. It's a method of certifying the origins of the code, no more, no less. There's no transfer of rights whatsoever in either direction.