3 ms·

GNOME and Debian wanted to replace some of their infrastructure with Gitlab but before they did that they asked Gitlab to get rid of their CLA. Before this anno

by ufo 9y ago

GNOME and Debian wanted to replace some of their infrastructure with Gitlab but before they did that they asked Gitlab to get rid of their CLA. Before this announcement, people contributing to gitlab itself effectively gave full control of copyrights to gitlab but from now on contributors will keep full control of the copyrights for what they contribute. GNOME and Debian are very serious about free software and are wary of using software with CLAs because at any moment the company can switch future versions of the project to a non-free license, without input from the community and despite the software containing code originaly from the community. I wouldn't expect Gitlab to do something stupid like this today but getting rid of the CLA protects the free software community from Gitlab doing stupid things in the future. For example, if they end up being acquired by Oracle or some other FOSS-sabotaging company.

tinus_hn 9y ago
See also: BitKeeper
plupf 9y ago
So how does DCO differ here? I'm not getting anything from three words.
- jabl 9y ago
  The DCO is not a CLA. It's more a document that says that the submitter is indeed the copyright holder of the submitted work (or his/her employer/etc. is) and that the contribution is licensed under the same license as the original software. See https://elinux.org/Developer_Certificate_Of_Origin https://elinux.org/Developer_Certificate_Of_Origin
ubernostrum 9y ago
I wouldn't expect Gitlab to do something stupid like this today but getting rid of the CLA protects the free software community from Gitlab doing stupid things in the future. I'm confused now about what was in Gitlab's CLA. The CLAs I've signed never transferred rights to someone else, only asserted that I had the right to grant a license and was granting a license I wouldn't later revoke (since the point of a CLA is to protect a project from "oops I wasn't supposed to contribute that" or "oops, new boss here decided to revoke all our contributions"). I'm also confused why GNOME and Debian would have a problem with a CLA even if it did constitute a transfer of rights, since FSF actually does require you to sign over copyright to them in order to contribute, and GNOME and Debian seem happy to use FSF projects.
- ufo 9y ago
  I could have been a bit clearer with what I wrote. I can imagine why someone would ask those questions... > The CLAs I've signed never transferred rights to someone else This is in part because copyright assignment/transfer is tricky and in some jurisdictions it isn't even possible. Instead, CLAs will often grant the company a perpetual license to reproduce, redistribute and sublicense the copyrighted work. Technically, the original contributor still owns the copyright to the work but the company is still able to use the contribution as part of non free software because the CLA gave them more powers than the original free software license did. For example, Canonical's CLA[1] contains the following language: > (b) To the maximum extent permitted by the relevant law, You grant to Us a perpetual, worldwide, non-exclusive, transferable, royalty-free, irrevocable license under the Copyright covering the Contribution, with the right to sublicense such rights through multiple tiers of sublicensees, to reproduce, modify, display, perform and distribute the Contribution as part of the Material; provided that this license is conditioned upon compliance with Section 2.3. > Based on the grant of rights in Sections 2.1 and 2.2, if We include Your Contribution in a Material, We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses. As a condition on the exercise of this right, We agree to also license the Contribution under the terms of the license or licenses which We are using for the Material on the Submission Date. Notice how it explicitly mentions that Canonical is allowed to use the contribution as part of non-free proprietary software. I can't find a copy of Gitlab's old CLA now but I guess it had a similar clause somewhere. > (since the point of a CLA is to protect a project from "oops I wasn't supposed to contribute that" or "oops, new boss here decided to revoke all our contributions") If the goal is to provide a paper trail ensuring that the contributor had the copyrights to their contribution, you can do that with a simpler certificate of origin document (like Gitlab is doing now) instead of the stronger terms usually found in CLAs. > since FSF actually does require you to sign over copyright to them in order to contribute The FSF's copyright assignment is a bit of a special case. It doesn't exist to protect the FSF's interests and is instead focused on making it easier for the FSF to litigate against GPL violators[2]. In particular, the FSF's copyright assignment contract[3] has a clause explicitly binding them to keep the software free and forbidding them from re-licensing it as proprietary software. The worst they could do is re-license it under a more permissive non-copyleft license, like MIT or BSD. [1] https://www.ubuntu.com/legal/contributors/submit https://www.ubuntu.com/legal/contributors/submit [2] https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf https://www.fsf.org/bulletin/2014/spring/copyright-assignmen... [3] http://www.dreamsongs.com/IHE/IHE-110.html http://www.dreamsongs.com/IHE/IHE-110.html (I could only find older versions, you apparently need to email the FSF to get the latest version of the contract)

by ufo 9y ago

tinus_hn 9y ago

See also: BitKeeper

plupf 9y ago

So how does DCO differ here? I'm not getting anything from three words.

jabl 9y ago
The DCO is not a CLA. It's more a document that says that the submitter is indeed the copyright holder of the submitted work (or his/her employer/etc. is) and that the contribution is licensed under the same license as the original software. See https://elinux.org/Developer_Certificate_Of_Origin https://elinux.org/Developer_Certificate_Of_Origin

ubernostrum 9y ago

I wouldn't expect Gitlab to do something stupid like this today but getting rid of the CLA protects the free software community from Gitlab doing stupid things in the future. I'm confused now about what was in Gitlab's CLA. The CLAs I've signed never transferred rights to someone else, only asserted that I had the right to grant a license and was granting a license I wouldn't later revoke (since the point of a CLA is to protect a project from "oops I wasn't supposed to contribute that" or "oops, new boss here decided to revoke all our contributions"). I'm also confused why GNOME and Debian would have a problem with a CLA even if it did constitute a transfer of rights, since FSF actually does require you to sign over copyright to them in order to contribute, and GNOME and Debian seem happy to use FSF projects.

ufo 9y ago
I could have been a bit clearer with what I wrote. I can imagine why someone would ask those questions... > The CLAs I've signed never transferred rights to someone else This is in part because copyright assignment/transfer is tricky and in some jurisdictions it isn't even possible. Instead, CLAs will often grant the company a perpetual license to reproduce, redistribute and sublicense the copyrighted work. Technically, the original contributor still owns the copyright to the work but the company is still able to use the contribution as part of non free software because the CLA gave them more powers than the original free software license did. For example, Canonical's CLA[1] contains the following language: > (b) To the maximum extent permitted by the relevant law, You grant to Us a perpetual, worldwide, non-exclusive, transferable, royalty-free, irrevocable license under the Copyright covering the Contribution, with the right to sublicense such rights through multiple tiers of sublicensees, to reproduce, modify, display, perform and distribute the Contribution as part of the Material; provided that this license is conditioned upon compliance with Section 2.3. > Based on the grant of rights in Sections 2.1 and 2.2, if We include Your Contribution in a Material, We may license the Contribution under any license, including copyleft, permissive, commercial, or proprietary licenses. As a condition on the exercise of this right, We agree to also license the Contribution under the terms of the license or licenses which We are using for the Material on the Submission Date. Notice how it explicitly mentions that Canonical is allowed to use the contribution as part of non-free proprietary software. I can't find a copy of Gitlab's old CLA now but I guess it had a similar clause somewhere. > (since the point of a CLA is to protect a project from "oops I wasn't supposed to contribute that" or "oops, new boss here decided to revoke all our contributions") If the goal is to provide a paper trail ensuring that the contributor had the copyrights to their contribution, you can do that with a simpler certificate of origin document (like Gitlab is doing now) instead of the stronger terms usually found in CLAs. > since FSF actually does require you to sign over copyright to them in order to contribute The FSF's copyright assignment is a bit of a special case. It doesn't exist to protect the FSF's interests and is instead focused on making it easier for the FSF to litigate against GPL violators[2]. In particular, the FSF's copyright assignment contract[3] has a clause explicitly binding them to keep the software free and forbidding them from re-licensing it as proprietary software. The worst they could do is re-license it under a more permissive non-copyleft license, like MIT or BSD. [1] https://www.ubuntu.com/legal/contributors/submit https://www.ubuntu.com/legal/contributors/submit [2] https://www.fsf.org/bulletin/2014/spring/copyright-assignment-at-the-fsf https://www.fsf.org/bulletin/2014/spring/copyright-assignmen... [3] http://www.dreamsongs.com/IHE/IHE-110.html http://www.dreamsongs.com/IHE/IHE-110.html (I could only find older versions, you apparently need to email the FSF to get the latest version of the contract)