We're switching to a DCO for source code contributions
about.gitlab.com
about.gitlab.com
Maybe others were already aware, but this was the big thing for me in this announcement which I wasn't previously aware of.
Then I saw this, which dates from August 2017: https://wiki.debian.org/Alioth/GitNext/GitLab
Personally, I work on a medium-size free software project, which has to choose between JIRA/Confluence (current), Github (where pull-requests currently happen), custom CI scripts/infra with Jenkins and a patchwork of other stuff. So far, Gitlab is the best option.
Forbidden
<p>You are not allowed to access this!</p>
The "no automatic migration" and the fact that there's 2377 SVN repos still on Alioth worry me a bit.
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?
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).
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.
The contribution guidelines have not been updated. They still mention the CLA: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBU...
(What makes this strange to me is that Debian and GNOME, both of which I tend to associate with GPL and copyleft, seem to both be strongly behind this change; if a bunch of BSD/MIT advocates were causing this I would not have paid much attention, but having someone who can actually enforce the license for a GPL project seems important.)
Different GPL projects vary in their attitude to the importance of enforcement -- the FSF cares a lot about retaining that option for their projects, but the Linux kernel community doesn't really care much. (And some kinds of enforcement, especially the most common "work with the violator to help them become compliant without taking legal action" kinds, work fine even if the copyright is not all held by a single entity.)
For example, if you've contributed code to an GPL2-licenced project, and several years later the maintainer wants to change the project's licence to BSD, having a CLA means that the maintainer doesn't need to ask contributor individually.
A copyright assignment would do that, but a CLA doesn't necessarily do that. You still can't enforce someone else's copyrights, only your own.
> Over time, the community started pushing back [against CLAs] due to the bureaucracy of it all
yet, I remember contributing to some apache projects where the bureaucracy amounted to ticking a "I give $project ownership of this patch" box in the issue tracker, which seems as little bureaucracy as possible. I suppose I am missing something, can anyone explain?
Where I am, policy allows us to contribute small patches to open source projects without legal approval - but only if there's either no CLA, or an existing CLA for a major organisation like Apache that our legal team has already reviewed. Otherwise, mandatory legal review for any and all contributions.
A DCO-based system, on the other hand, is fine by us.
On the contrary, it says that the copyright notice (= the license) shall be included in all copies (I assume, it's about derivative works as well).
From my understanding, one can throw in some non-MIT files or code pieces, but MIT code shall remain MIT-licensed until rewritten or removed.
Can you please point on where I'm wrong?
Replicating the copyright notice for attribution does not imply you are licensing it under MIT. You are following the original license requirements that permit your distribution.
A DCO doesn't solve the problem that the recipient wants some sort of guarantee that they won't be sued over copyright infringement or trade secret theft over some contribution, while a CLA does. But a DCO will probably work well for many smaller open source projects that currently do not use CLAs.
People can falsely sign a DCO, and people can falsely sign a CLA, and in both cases you don't have any easy way to check that. Either one provides an explicit assertion by the person proposing a change that they claim to have the right to grant a license over that change.
A DCO could do the same, but it doesn't look like the linked DCO does that, and I expect in general they won't, since otherwise they wouldn't have lower overhead than CLAs.
This happens; it isn't a hypothetical.