This guide is not legal advice. We are not lawyers. It’s a guide to help maintainers think through adopting an ethical license without taking on unnecessary risk.
When starting a new project, review the existing ethical licenses and choose the one that most directly matches the projects goals.
For maintainers of existing projects, there are two strategies:
Regardless of the strategy chosen; maintainers must work to preserve and develop trust between maintainers, contributors, and users of the project throughout the license adoption process.
Maintainers should understand authorship rights and the licensing constraints of their current license. This understanding is demonstrated by answering the following questions clearly, accurately and precisely:
Maintainers should read the rest of this guide to ensure their understanding is correct.
It may be useful to think about intellectual property rights like other property rights. Imagine a project is a neighborhood. Each house has a lock on it installed by the homeowner. The lock is opened by a key that fits.
To continue to use the home, the neighborhood maintainer must carry a key that works in the homeowner’s lock.
To change the lock, a neighborhood maintainer must get consent from the homeowner.
In this analogy, the homeowner is a contributor and a house is a substantial contribution. The lock is the license, and the key is following the constraints the license imposes.
Changing the lock is relicensing. Carrying around a working key for the locks that cannot be changed is sublicensing.
Copyright is the right to exclude others from certain activities relating to that expressive content, and is the main legal basis for software licensing. (Other kinds of intellectual property rights, such as patents, are also important in software licensing, but we’ll ignore them for this guide.) A license is a grant of permission to others to exercise rights that the owner could otherwise restrict. Typically, an employer owns copyright on software created by an employee.
In a collaborative community software project, it is generally understood that each contributor is licensing their copyright under the license selected by the project. Exceptions exist, such as when a project requires contributors to sign a Contributor License Agreement requiring them to license copyright under more generous terms than the project license itself would require.
To maintain trust and integrity of the broader open source community; maintainers must get consent from all contributors whose code remains within the project before relicensing.
When sublicensing or relicensing, maintainers must continue follow their current licenses constraints until clear, positive, informed affirmative consent from past contributors to relicense is received.
Open source and free software licenses are widely permissive. Those permissions often have strings attached. Some require distributing the license along with any copies of the software. Others require the release of derivative works in a compatible license.
This guide cannot cover every license, but maintainers may be able to determine an appropriate and effective course of action from these examples.
The MIT License is one of the most widely used open source licenses, and also one of the most permissive. This makes it one of the easiest to sublicense or relicense.
To sublicense, maintainers may add an ethical license while continuing to conform to the constraints imposed by the MIT licensed contributions.
The core constraint of the MIT license is that the body of the license must be included in any copy or derivative works. This constraint persists so long as any code that was contributed under the license remains in the project or every contributor whose code remains in copy agrees to relicense their contributions under the new license.
This is the strategy used by Kurtis Rainbolt-Greene with the assistance of Richard Fontana in VCR.