Hacker News new | past | comments | ask | show | jobs | submit login

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.

[1] https://www.ubuntu.com/legal/contributors/submit

[2] https://www.fsf.org/bulletin/2014/spring/copyright-assignmen...

[3] 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)


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.


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


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


See also:

BitKeeper


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.

[0]: https://wiki.debian.org/Alioth


From Debian News (https://www.debian.org/News/weekly/): yes and it is going to be named Salsa (https://wiki.debian.org/Salsa).


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.


That's exactly what the link you pasted says - Debian is closing Alioth and migrate to using gitlab.

No automatic migration is planned - you need to migrate the repos you are responsible for yourself.


I follow the debian devel list and yes they are moving away from alioth


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.


Contributing to GitLab itself.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: