Skip to content

Legal considerations

Disclaimer

The following is no legal advice. Please see your supervisor(s), better yet your legal department to discuss your specific case. No two are quite the same, it always depends.

What to look out for

1) Your requirements depend on the risk assessment for your code. Some key questions for that can be:

  1. Are you lucky enough to receive external contributions?
  2. Do you currently use an open-source license?
  3. Do you ever want to change your license?
  4. Does your license cover incoming contributions?
  5. Are contributors external to your legal entity?
  6. Are contributors individuals or employees?
  7. Is incoming IP covered within a separate project agreement?
  8. Will the project ever become closed-source?
  9. Will the project be commercialised at some point?

If any of the above is not 100% clear or there may be changes in the future, you may want to take a careful look at your options for treating incoming contributions and seek advice.

Even if the above is clear, does your current license and any contributions require a clear legal framework?

Choice of incoming license

There are two basic options, both of which have advantages and disadvantages: Developer Certificates of Origin (DCOs) and Contributor License Agreements (CLAs). The first appear rather simple and do not require signing legal documents, as such have a low apparent entry barrier for contributors. Depending on your current license, they may (or not) even allow license changes in the future. The latter provide more freedom for your project to define and lay out clear rules. They usually require a binding legal contract to be signed or otherwise agreed upon. Some see this as more restrictive, others could argue the only difference is more clarity and security for the future. The actual outcome of both need not be different - depending on what you desire to draw up.

Please search for others sources to explain the difference or speak to your counsel. (We deliberately will not provide external links so you have your own choice of sources to trust and rely on.)

Depending on your risk assessment, the simplest form may suffice.

Choice of workflow

  • A DCO usually works via specific lines added to commit messages. It also requires to refer to the actual text for the DCO in your contributing guidelines, just as with other licenses. Likewise, you could provide the text to a CLA in your code's repository and refer to it in your contributing guidelines, making every contributor aware of it, noting to adhere to it, and assuming agreement with every contribution.
    This will be the lowest form of interference with contributors. You may not rely completely on them acknowledging your guidelines, after all you do not know if they've read your CLA since they have not actively confirmed them.
  • You can choose to rely on the IdP connected to your GitLab instance and consider users authenticated with their name and email, as well as clearly linked to their user id. Based on that, any contribution that is linked to this user id can be followed up to a person. A workflow based on GitLab can then be seen as identifying contributors once they show agreement on the platform.
    In this case, a bot can check if your guidelines are acknowledged by adding specific comments to commit messages or with merge requests. The automated process may then ask contributors to make such comments, keep a record for future interaction, and make future checks on its own.
  • The IdP does not provide enough reassurance or you do not want to use a workflow within GitLab alone. It may also be more complicated because contributors are employees and you may want an agreement with partnering entities: move to signed CLAs on paper that you keep a record of.
    Still, the bot could help if made aware of your recorded agreements and offer feedback within comments to merge requests.
  • A final option can be to ask for cryptographically signed commits to track committers.