The Right to Sublicense

The MIT license also grants the right to sublicense, a word missing entirely from the BSD license grant. Sublicensing is an important concept in open source licensing.

Referring back to the chain of title explanation earlier in Chapter 2, I described how contributions from many people can be combined into collective and derivative works, and how those works can in turn be used by others to create still more collective and derivative works. That is the very premise and promise of open source development. The ever lengthening chain of title is reflective of the robust creative energies of community development. A major open source software program may have a long chain of title by the time it arrives on your computer.

From whom does the person at the end of the chain of title get a license to use, copy, modify, and distribute the software? Does the user receive a set of licenses, one from each of the original authors of each of the contributions all the way along the chain, or is there a single license from the immediate predecessor on which the user can rely?

If a license is not sublicensable , then only the owner of the original work can grant licenses. For each nonsublicensable component of a collective or derivative work, each prospective licensee must obtain a license to that component directly from its owner. In principle this requires tracing the entire chain of title, obtaining copies of each copyright or patent license up the chain, but in practice it means nothing so complicated. Leaders of nonsublicensable open source projects take steps to ensure that licenses to components will be available for the asking, but they don't actually expect everyone to ask. The project team merely announces that licenses are available and points to the open source code, with its copyright, patent, and other attribution notices there for all to read, for information about where to get those licenses. If you want to make sure you have a license to each component, they in effect say, go get it yourself; but considering the low risk, most licensees don't bother. This is a reasonable solution for most open source software, but as a legal matter it is risky not to confirm that all licenses up the chain are actually available.

On the other hand, if a license is sublicensable , then any distributor has the right to grant a license to the software, including its component parts , directly to third parties. For each sublicensable work that is a component of a collective or derivative work, each prospective licensee obtains a license directly from the owner of the collective or derivative work. Leaders of sublicensable open source projects take steps to ensure that licenses to components are consistent with their own licensing terms and are sublicensable. They then extend sublicenses to their customers sufficient to allow those customers to exercise their rights under the open source licenses.

Note that the license terms for a sublicense must be consistent with ”not necessarily the same as ”the original license terms. A sublicensor cannot sublicense more rights than have been granted by the original author. The sublicensors needn't use the identical words as in the earlier license they received, but they cannot override terms and conditions that are mandated by that license.

This subject will be addressed again in Chapter 10 when I discuss how open source projects should in-license contributions and how they can relicense their collective and derivative works when new and better licenses become available despite being bound by the licenses of their contributors.

The fact that the MIT license is sublicensable is an advantage for anyone who wants to distribute copies or derivative works of MIT-licensed works. A distributor can provide to his customers all the rights needed to the entire work without expecting those customers to follow the chain of title to its beginning.