Why an MIT License

Open and permissive licensing of copyrighted content is a way to increase use of a software product, ease collaboration and re-use, and sharing intellectual ideas with others. This post contains our reasons for choosing the MIT License, which is a very permissive copyright license.

Context and problem statement

When developing a new piece of software it is important to consider the following question as early as possible.

What kind of re-use will we ultimately allow other developers to make of our software?

In order to control this use, it is important to have considered which license type we want our software to be available under, as this will tell the rest of the development community what they can (and can’t) do with it.

Decision drivers

Although no license means that a piece of software on GitHub will be under exclusive copyright, leaving our code without one will make it difficult for other users to (easily) (re-)use, modify, contribute, or enhance our software due to copyright reasons. Our mission isn’t only to build a piece of software; we also aim to develop a creative community around the Seedcase Project and the topics we work on. We want people to be able to freely and smoothly contribute enhancements and other improvements that can be incorporated into future releases of Seedcase software products. It is also our intention to make the Seedcase software available to commercial enterprises, which means that we need to carefully consider which license we adopt.

Considered options

The Open Source Initiative (OSI) approves a specific set of licenses that determine whether a project can be called “open source”. These licenses are our starting point on deciding which license to use and how permissive we want it to be, in terms of who can work on our code and how it can be used.

The primary license is the one that governs how our code can be used, modified, and shared, which is described more below. For managing copyright of contributed code from users who are external to the project, agreements could include either a Contributor License Agreement (CLA), a Developer Certificate of Origin (DCO), or neither of those, which we discussion below as well.

Software licenses

Overall, the open source community have licenses that work along two strands, permissive and copy-left. Both of these “allow software to be freely used, modified, and shared” (see more detail on the OSI website). We will be using the OSI’s definition of free software that among other things covers the source code being available to download and read/study, to allow for derived works to be created and distributed without violating the given license.

The copy-Left licenses generally state that if a third party makes changes to the existing product, or incorporates the code alongside another code set, then the resulting software must also be available under the same license. This is the broadest definition of free software, as it forces any subsequent development to be shared for free (although most of those licenses state that you are allowed to modify code for own use, the copy-left license only comes into play if you make your modifications available outside your organisation). Examples of Copy-Left licenses are EUPL-1.2, GPL, and LGPL.

The permissive licenses gives you all the above mentioned rights, but they do not enforce that derived works or new works created by taking bits of source code from the original product are made available under the same license. These type of licenses are generally seen as more friendly to commercial enterprises as they will allow companies to use bits of code in proprietary software without having to release the source code for free. Examples of Permissive licenses are Apache, BSD (no matter the number of clauses, e.g., BSD 2-Clause or BSD 3-Clause), and MIT.

CLA versus DCO

Some open source projects are asking contributors to sign up to a Contributor License Agreement (CLA) or, alternatively, a Developer Certificate of Origin (DCO).

Looking at a number of CLAs (in particular Threema, Meta, and ImageWorks), it seems that these projects are mainly concerned with the following:

• A person submitting code that they are not the copyright holder for.
• Withdrawal of the right to use the submitted code.
• The need to apply for patents in future for parts or all of the source code.
• A change in the type of license that the source code was given at the time of contribution.

There are also some agreements that touch on the subject of loss and damages that may arise from the use of a particular section of code, as well as how a request for support will be dealt with in future.

An alternative to a CLA is a DCO. The DCO was first employed by the Linux Foundation in 2004 and is basically a short document that confirms that the person contributing code is allowed to do so, gives permission for the project to subsequently use it, by adding a Signed-off-by line to their commit message (for an example see the BeeWare projects DCO).

Decision outcome

It is in our stated goals that Seedcase software is available for commercial enterprises as well as academic/healthcare organizations and groups. Aligning with our stated Guiding Principles, we will use a permissive license as it will be the best fit for the Seedcase Project. Of the permissive license types we will go with the MIT License as it is the most permissive and easiest to understand and use.

Consequences

Currently, we’re not sure if we need to implement a CLA before people outside the team contribute to the code. However, we will likely implementing a DCO that future contributors will need to agree to before making a contribution to the project. This could be done either by checking that a commit contains the signed-off-by clause before merging it, or by implementing something like the GitHub App DCO. The license text itself is available here.