I don't actually understand this. Are they referring to the agreements for contributing to GitLab itself, or for contributing to things hosted on GitLab, which surely have nothing to do with the hosting at all?
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.
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.
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.
If FSF can re-license under a more permissive license, then FSF's assignment agreement implicitly allows the contribution to someday be used in proprietary software (since FSF could relicense to BSD or MIT, then someone else could take that code and incorporate it into a proprietary project).
So why doesn't anyone have a problem with the FSF's assignment?
The fsf's copyright assignment is also controversial (at the very least there is the issue that it adds an extra layer of bureaucracy for contributors).
Honestly, I think it only gets a pass because it is the FSF, a nonprofit entity that is probably the most vocal proponent of copyleft licensing out there.
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.
Yeah, I'm not sure what they mean by "migrate their communities".
I'm not exactly real clear on "... and open source projects" either. Debian used to use Alioth [0] pretty extensively. Maybe they're getting rid of that and moving everything that was on there to GitLab.
I get that this is a press release but it could be a bit more informative, IMO.
The Debian project has been investigating several alternatives to Alioth's version control functionality. I have not 100% kept up on the discussion, but I think gitlab is either selected for sure or is a leading candidate. https://wiki.debian.org/Alioth/GitNext
Even if they adopt gitlab for version control and pull requests, it's a very misleading headline that the "debian community" will be migrated to gitlab.
I think they will migrate the systems which they host VCSes. Since they may need to make changes in the code to suit them, abandoning the legal stuff makes using, modifying and contributing back stuff easier.