7 ms·
We're switching to a DCO for source code contributions
- bpicolo 9y agoHow does this function in the event of e.g. relicensing? (The DCO clauses don't make it obvious)
- falcolas 9y agoBy using MIT for contributions, there’s no issues with relicensing them later.
- clarkevans 9y agoIANAL, 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 9y agoPlease 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 9y agoSorry, 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 9y agoYou 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.
- evv 9y agoWhat 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/CONTRIBUTING.md https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBU...
- sytse 9y agoOops, I still had to merge https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15115/diffs https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/15115... 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
- michaelmior 9y ago> 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.
- rahiel 9y agoDebian's GitLab instance will run at https://salsa.debian.org https://salsa.debian.org. In May 2017 they had about 19k git repo's in the old system [0]. [0]: https://wiki.debian.org/Alioth#Deprecation_of_Alioth https://wiki.debian.org/Alioth#Deprecation_of_Alioth
- voltagex_ 9y agoIs there a relatively easy way to keep up with things like this in the Debian project? The "no automatic migration" and the fact that there's 2377 SVN repos still on Alioth worry me a bit.
- rahiel 9y agoYou could subscribe to the debian-devel-announce mailing list (https://lists.debian.org/debian-devel-announce/ https://lists.debian.org/debian-devel-announce/).
- mgbmtl 9y agoI 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 9y ago
- saurik 9y agoI 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 9y agoIf 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.)
- JoshTriplett 9y ago> 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; 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.
- confounded 9y agoMy 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.
- JoshTriplett 9y agoHuge 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.
- cryptonector 9y agoSome 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 9y ago> 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 9y agoCLAs 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 9y agoNothing 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.
- ajdlinux 9y agoYou 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.
- solatic 9y agoCan 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 9y ago> 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 9y agoExactly, you choose the MIT license over the GPL because you are explicitly ok with this scenario. It's like the entire point.
- jordigh 9y agoYou 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.
- s73ver_ 9y agoAs 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 9y agoFor 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.
- riffraff 9y agoThe 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?
- mcguire 9y agoI suppose some might not be comfortable without your signature on file.
- ajdlinux 9y agoThe 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.