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.
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?
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.
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.
The point of the DCO is to protect downstream, not upstream. It's a method of certifying the origins of the code, no more, no less. There's no transfer of rights whatsoever in either direction.
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.
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.)
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.)
CLAs neither enable the kind of enforcement you mentioned, nor do they offer any additional legal protection mentioned in other comments. CLAs are good for exactly one thing, which is to provide an "out" regarding obligations that the license imposes. For example, if a project chooses GPL, a CLA can allow the benefitting org to disregard the share-alike clauses it contains, i.e., effectively allowing the org to use third-party contributions under non-reciprocal terms as if it were licensed to the project steward under, say, MIT- or BSD-like terms, or to relicense the project to a different, incompatible, non-GPL license in the future. Alternatively, a CLA for an Apache-licensed project allows the benefitting party to ignore Apache's termination clauses. These things create an asymmetric balance of power. Anyone operating under different beliefs can only be relying on a cargo-cult misunderstanding of what CLAs are actually about. There's no other reason to use a CLA.
My understanding (which could be wrong) is that it also allows them to change the licence down the road.
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.
> 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?
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
You say "smaller open source projects" - it's worth noting that the DCO was devised by the Linux kernel community, and was a direct consequence/response to issues raised in an actual lawsuit, namely SCO v IBM. Most open source projects aren't nearly as big and haven't been subjected to actual lawsuits.
Maybe others were already aware, but this was the big thing for me in this announcement which I wasn't previously aware of.