Finalise DCO (previously CLA)

[cportele]

See #3.

JRC will resolve the open comments on the CLA and finalise it. Any European Member State could be the place of jurisdiction. German law will be used, because main contributors so far are from Germany. See minutes of the 3rd SG meeting.

[michellutz]

We had another discussion with our IPR unit on the question who should be the "US" in the CLA.

Please find the summary of our discussion and conclusions below:

1. For the Commission the CLA is suitable as licensing instrument. However, on the receiving side, this instrument requires a subject with the legal capacity to be conferred rights and obligations. Provided that this is available I am ready to proceed with the signature of the CLA.
2. As an alternative, one way to simplify the contribution process (especially when multiple contributors are envisaged) would be that of acquiring these contributions under the same licensing terms as those established by the steering group for the overall project.
3. In this case, if the project adopted the EUPL as distribution method, then we could simply as contributors to release their code under the EUPL terms. That includes us when we contribute to the project.

This solution would remove the problem of identifying a legal person (see point 1 above), because the EUPL is a non-transactional licence (while the CLA is technically speaking a transactional one). Without getting carried away with the legalese, the bottom line is the following: it is easier to manage a software development project when the upstream licensing conditions match the downstream distribution licence. Thus, provided that the EUPL is the licence of choice for the distribution of the project output, you could simply require the contributors release their code under the same EUPL terms.

We then did a bit more digging into the question whether a CLA is strictly needed for our purposes, and what alternatives can be. We found the following posts that share the arguments of our IPR colleague and propose Developer Certificates of Origin (DCO) as a possible alternative:

• Why Your Project Doesn't Need a Contributor Licensing Agreement
• CLA vs. DCO: What's the difference?

From what we understand, DCOs requiring contributors to licence their contributions under EUPL (or an EUPL-compatible licence) might indeed be a middle way that might serve the needs of our project. The only downside we can currently see would be that it will make it difficult/impossible to change the licence of the project in a future point in time.

We suggest to discuss this in the next Steering Group meeting next week.

[MarcoMinghini]

Following the doubts emerged from our 6th ETF SG meeting, we had a further discussion with our IPR unit, here a summary of the main points:

• DCO: it is a viable tool to be used for open source projects, and the Commission is fine with its use. However, the DCO alone is not sufficient to satisfy the copyright requirements for the distribution of software, since it only links back to a project licence (and it is the license that contains the terms and conditions under which each distribution is released). Thus, the DCO complements the EUPL. If we use the DCO, we cannot change the license in the future, because the DCO is linked to a specific license (conversely, with the CLA we can change the license).

• point (c) of the DCO, which reads The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it, covers the scenario where the contribution itself was not generated (solely) by the person who is making the submission. This is for example the case where the contribution is the result of a team of developers working together, each having made substantial work to the contribution. As, in practice, it is one of them which will eventually submit the contribution to the overall project (e.g. the lead developer), then this person will have to certify not only that (s)he complies with points a) and b), but that every other member of the development team does.

• copyright of the software: the copyright should mention those who were the original creators of the main code (i.e. those who agreed to upload it on GitHub under the terms of a specific open source licence). I also found this article that may be useful to define the copyright.

Thus, to answer (in my interpretation) some of the questions raised during the 6th ETF SG meeting:

• does any project contributor become an owner? Not an owner of the project, (s)he is just maintaining the intellectual property on his/her code, which however is shared under the terms of the license chosen (by us) for the project, i.e EUPL.
• what would be the copyright of the software at that point? It will not change, see above.
• since each commit must be signed, is it fine that contractors make commit on behalf of the Commission? This is an open question, whose answer basically defines whether we are ok with the EUPL+DCO or if we have to reconsider a CLA (it depends on us). We can discuss this during tht 7th SG meeting tomorrow.

[MarcoMinghini]

Following the discussion from the 7th ETF SG meeting, here some more information on the DCO:

1) In contrast to the CLA, the DCO shall NOT be signed in advance. The contributor’s agreement to the DCO is certified by signing each commit to the project repository that is adopting the DCO. If a commit is signed, next to it Github shows a button with a green “Verified” string; if you press this button, you will see more details about the signature.

To physically sign the commit, you need a GPG key. The GPG key can be also used to sign e-mails or files, and more in general to communicate securely. You can generate a GPG key using specific tools, available for different operating systems; some instructions are available here: https://help.github.com/articles/generating-a-new-gpg-key

Once you have a GPG key, you can associate it to your Github account and use it for signing git commits: https://git-scm.com/book/en/v2/Git-Tools-Signing-Your-Work

If you set your user.name and user.email git configs (see https://git-scm.com/book/en/v2/Getting-Started-First-Time-Git-Setup), then you can sign your commits automatically with git commit –s. This means that you should add –s to each commit, and the commit will be automatically signed (and this automatically means you are accepting the DCO).

There is also a way to associate your generated GPG key to your Github account from your profile settings on github.com: https://help.github.com/articles/adding-a-new-gpg-key-to-your-github-account, but this is not mandatory. In fact, if you make commits directly from github.com, you will also see the “Verified” button next to them, simply because in this case Github is using its own key to sign, but it assumes that the commit is verified because it comes from the user’s verified username and e-mail address.

From the practical point of view, for us this means that we need just to:

• say that we require contributors to sign the DCO
• show the DCO
• ask contributors to accept it by signing their git commits.

All of this is done for example in the case of Docker: https://github.com/moby/moby/blob/master/CONTRIBUTING.md/#Sign-your-work

2) Usually, projects adopting a DCO decide to use exactly the standard DCO of the Linux Foundation, without changing it (see again the case of Docker). The reason why the standard DCO is usually chosen (i.e. new DCOs are not created) is that, in addition to being rigorous from the legal point of view, it is a well-known document (a “de facto” standard). Creating a new/different DCO would disincentive participation, i.e. new contributors would be less likely to accept it.

[jonherrmann]

@etf-validator/sg @etf-validator/tc

I have activated the option "Require signed commits" in all ETF GitHub repositories. It should no longer be possible to push unsigned commits to the branches. I will check later if this works correctly.

[jonherrmann]

I think we need to point out in the contribution guide, that:

• all commits must be signed-off
• and digitally signed

This means, that a text like Signed-off-by: John Doe <doe@whatever.com> must be added to every commit message and the commit itself must be digitally signed with a GPG signature.

[MarcoMinghini]

@jonherrmann I think this is done automatically. For instance, in my last commit, you can see that this string is automatically visible within the comment to the commit: https://github.com/etf-validator/governance/pull/56/commits/42087d71bff5466e0235ecf8bdee3d3e9cb338f3

[jonherrmann]

@MarcoMinghini I thought so at first, but they're two different things. You can sign-off a commit but it does not necessarily have to be digitally signed and vice-versa.

[jonherrmann]

A short addendum: You signed your commits and confirm that you agree with the DCO, but at the moment you can't prove that the owner of the E-Mail address that is used in the commit message, is really you . You can only prove this with a digital GPG signature.

[MarcoMinghini]

Thanks @jonherrmann, this is also what I figured out. I created the GPG key and linked it with my Git e-mail/password and also to my Github profile. But when making the commit (I used the command line) I was not asked the GPG key, so here is the problem - I'll have to find the missing link. I'm now leaving for a mission, but will check it asap (luckily this is not urgent).

[MarcoMinghini]

We received good news from our IPR Office: the Commission Decision to publish the ETF code under EUPL is currently waiting for signature.

[MarcoMinghini]

The Commission Decision was finally published. It is not publicly accessible but you need to request it here.