12

I would like to publish a project under GPL license, but would like to request CLA (Contributor License Agreements) signing before accepting merge requests.

GitHub has a few solutions which automate this (ClaHub, cla-assistant), however I can't find anything similar for GitLab. There is a long standing issue to add support for it natively, but it's been opened 2 years ago.

I know Git sign-off can be used for DCO, but I am wondering if it could somehow be (ab)used for signing CLA agreements?

In short, how do I make the process of signing CLAs as painless as possible for both contributors and myself, while still making the agreements (somewhat) legally binding?

EDIT: To the person who cast a vote for closing: I checked the guidelines again and it seems to me that the question falls squarely in software tools commonly used by programmers; and is a practical, answerable problem that is unique to software development. It also doesn't fall into exceptions listed, at least the way I understand them. That said, I would appreciate a comment about the reasons for the vote, so that I can formulate the question better or find a more suitable StackExchange site if needed.

johndodo
  • 17,247
  • 15
  • 96
  • 113

1 Answers1

8

There is no official native support for CLA in GitLab for now.
The issue you are referencing is linked to issue 48118 ("Stakeholder approval for merge requests"), but itself is linked to two GitLab Enterprise issues -issues 1979 "Multiple blocking merge request approval rules" and issue 965 "Upgrading approvals with approval chain")

So for now, relying on a third-party service site remains the "less painful" solution.
That means, using the services highlighted in the original issue: CLAClub or cla-assistant.io.

The last one (cla-assistant) will, for a public registered repo (registered to cla-assistant) will:

  • Comments on each opened pull request to ask the contributor to sign the CLA
  • Allows contributors to sign a CLA from within a pull request
  • Authenticates the signee with his or her GitHub account
  • Updates the status of a pull request when the contributor agrees to the CLA
  • Automatically asks users to re-sign the CLA for each new pull request in the event the associated Gist & CLA has changed

Note: you can install and run your own instance of cla-assistant in order to store in your own private dedicated database the CLAs for your project.

But: since those services are tied to GitHub accounts, and there is no equivalent for GitLab, DCO should not be dismissed, especially in light of the Nov. 2017 GitLab blog post "GitLab Transitions Contributor Licensing to Developer Certificate of Origin to Better Support Open Source Projects; Empower Contributors "

GitLab’s move away from a CLA is meant to modernize its code hosting and collaborative development infrastructure for all open source projects.

Additionally, requiring a CLA became problematic for developers who didn’t want to enter into legal terms; they weren’t reviewing the CLA contract and they effectively gave up their rights to own and contribute to open source code.

And "We're switching to a DCO for source code contributions". When it comes to GitLab projects, a DCO like this one remains the chosen solution.
See the analysis comparing CLA and DCO.

GitLab 15.5 (October 2022) prpose for non-free editions of GitLab:

Enforce Developer Certificate of Origin on all contributions

The Developer Certificate of Origin (DCO) is a per-commit sign-off made by a contributor stating that they have the right to submit the code to the project. By signing off on a commit, the contributor agrees to the terms published at developercertificate.org.

Now, you can easily enforce this Developer Certificate via a per-project setting to prevent contributors from contributing code that violates your license. When enabled, all new commits must include such a certificate of origin in the form of a line in the commit message Signed-off-by:.

https://about.gitlab.com/images/15_5/enforce_dco_all_contributions.png -- Enforce Developer Certificate of Origin on all contributions

See Documentation and Issue.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • 1
    Thanks! What do you mean when you say "relying on a third-party service site"? Can you maybe outline how the workflow would look like? – johndodo Jan 13 '19 at 07:15
  • @johndodo I have edited the answer to address your comment. – VonC Jan 13 '19 at 11:53
  • Thanks! If I understand correctly, this workflow is then tied to contributors having a GitHub account? – johndodo Jan 17 '19 at 19:37
  • @johndodo Yes: there is no equivalent service using GitLab account for now (https://forum.gitlab.com/t/contributor-cla-checker/9626/2). You can see another approach in https://github.com/silverstripe/silverstripe-framework/issues/7487#issuecomment-342347189. – VonC Jan 17 '19 at 20:18
  • @johndodo I have edited the answer to contrast CLA with the DCO you were mentionning in your question. – VonC Jan 17 '19 at 20:53
  • Thanks, I appreciate the effort! Unfortunately DCO is not a suitable solution for my use case (I would like to have an open-core model), but it might help someone else with the same problem. I am a bit torn - the answer is full of bits of interesting information, but I knew most of it already, and it doesn't actually suggest a way for contributors to sign the CLA for GitLab-hosted project... So let's wait if someone else has any suggestion, otherwise I'll accept your answer (and probably move the project to GitHub, much as I don't like doing it). I do appreciate the effort though! – johndodo Jan 18 '19 at 09:42
  • 1
    @johndodo I understand. The point is: GitLab does not seem encline to use/consider CLAs. Hence its switch to DCO. So I would be surprised if there is any equivalent of CLA-based support *for GitLab projects*. – VonC Jan 18 '19 at 10:06