
We're switching to a DCO for source code contributions - brodock
https://about.gitlab.com/2017/11/01/gitlab-switches-to-dco-license/
======
michaelmior
> Debian and GNOME plan to migrate their communities and projects to GitLab

Maybe others were already aware, but this was the big thing for me in this
announcement which I wasn't previously aware of.

~~~
mgbmtl
I thought Debian were moving towards "pagure" (developed by Fedora)?
[https://anarc.at/blog/2017-06-26-alioth-moving-
pagure/](https://anarc.at/blog/2017-06-26-alioth-moving-pagure/)

Then I saw this, which dates from August 2017:
[https://wiki.debian.org/Alioth/GitNext/GitLab](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.

~~~
sverhagen
Your second link goes to a (malformed) rejection:

Forbidden

<p>You are not allowed to access this!</p>

~~~
rahiel
Sounds like a temporary issue? (The link works for me.) You can see a copy of
that page here:
[https://web.archive.org/web/20171102070648/https://wiki.debi...](https://web.archive.org/web/20171102070648/https://wiki.debian.org/Alioth/GitNext/GitLab)

------
solatic
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
> 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
Exactly, you choose the MIT license over the GPL because you are explicitly ok
with this scenario. It's like the entire point.

~~~
jordigh
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
True, not sure why but I guess I thought it was implied that the "malicious
maintainer" would take the software closed course.

~~~
mcguire
... which _is_ explicitly okey-dokey with the MIT license, but not the GPL.

------
JoshTriplett
Huge thanks to GitLab for making this change, which took a lot of detailed
discussion and exploration to reach. And in particular, thank you to GitLab
for carefully considering the needs and desires of the FOSS community, rather
than stopping at the easy answer of defaulting to the status quo.

------
evv
What does this change in practice? Are contributors expected to do anything?
Does the license or source code need to reference the DCO?

The contribution guidelines have not been updated. They still mention the CLA:
[https://gitlab.com/gitlab-org/gitlab-
ce/blob/master/CONTRIBU...](https://gitlab.com/gitlab-org/gitlab-
ce/blob/master/CONTRIBUTING.md)

~~~
sytse
Oops, I still had to merge [https://gitlab.com/gitlab-org/gitlab-
ce/merge_requests/15115...](https://gitlab.com/gitlab-org/gitlab-
ce/merge_requests/15115/diffs) I just did. I also moved the doc to a repo in
[https://gitlab.com/gitlab-org/gitlab-
ce/merge_requests/15139](https://gitlab.com/gitlab-org/gitlab-
ce/merge_requests/15139)

------
saurik
I was under the impression that one of the (multiple) goals of a CLA was to
empower an organization to actually go after license violations; is the reason
this is viable here because of the wide permissions of the MIT license that
make the entire concept of "enforcement" relatively uninteresting?

(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.)

~~~
pm215
If you follow the link to the "analysis" document it summarizes their
rationale. It looks to me that the summary is "in reality we're not going to
be sueing anybody, and we think the chances of a contributor sueing us are
negligible, so while a CLA provides some extra legal protection/capability in
theory, in practice we don't expect to use that and so all we get is the
downside of extra bureaucracy and a barrier to contributors".

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.)

------
riffraff
The document mentions

> 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?

~~~
ajdlinux
The level of bureaucracy depends on the project of course, but any type of CLA
will cause problems for many corporate contributors.

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.

------
s73ver_
As an end user, what does this do for me? I know developers don't always like
CLAs, but as an end user, knowing that the whole project is under one license
with one entity, makes it a lot easier to deal with.

~~~
sytse
For our users and customers nothing changes. It will be the same product with
the same license backed by the same entity. See the analysis link in the blog
post for details.

------
bpicolo
How does this function in the event of e.g. relicensing? (The DCO clauses
don't make it obvious)

~~~
falcolas
By using MIT for contributions, there’s no issues with relicensing them later.

~~~
clarkevans
IANAL, however, I'm pretty sure that software released under the MIT license
can't be _relicensed_. The MIT license may be may be exceptionally permissive,
but you are not given the right to license the contributed works under any
other license terms.

~~~
carussell
Please review the text of the MIT license. Not only is it allowed, it's
allowed explicitly. This is why FSF, for example, is okay with MIT, and so are
many corporate shops: If someone forks an MIT licensed project, the forker is
allowed to make all the fork's releases available under some other non-MIT
license. In the case of copyleft proponents, this can be some reciprocal
license like GPL. In the case of someone doing commercial closed source, this
can be some non-free license that doesn't require offering the source to
recipients.

~~~
drdaeman
Sorry, I must be not getting something, but I'm reading MIT (Expat) license's
text and I don't see this.

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?

~~~
mehrdada
You are both right. You can relicense MIT, assuming you follow certain
requirements, including replicating the copyright notice, but you are not
required to give away the source code (even just to the original artifact) at
all. The user has to find its own way to the source code.

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.

------
cryptonector
Some CLAs don't even specify who at the organization will be making code
contributions, which tends to make lawyers uncomfortable.

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.

~~~
JoshTriplett
> 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.

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.

~~~
cryptonector
CLAs typically require that an _officer_ sign them.

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.

~~~
JoshTriplett
Nothing stops you, as a person wanting to get your code in, from signing the
"individual" CLA and ignoring the fact that you work for a company, either
maliciously or because you don't understand or don't know that your company
holds copyright over the code you've written.

This happens; it isn't a hypothetical.

