License compliance is the process of complying with (i.e. fulfilling) the obligations posed by licenses upon the users of code with that license. Here, we are typically talking about open source license compliance, that is complying with the obligations required by open source licenses. However, to a company distributing program code it doesn’t matter whether any third-party components are open source components or other components: All licenses typically need to be complied with.
I previously discussed open source licenses, though in somewhat general terms. All open source licenses
- Provide defined rights to you,
- Have obligations you must fulfill to receive those rights,
- Are disallowing you to do certain things, and
- Typically also disclaim all warranties and liabilities.
The Open Source Initiative (OSI) has accepted more than 100 licenses as open source licenses, conforming to their open source definition. Of these, about half of them are in actual use, and about 20 licenses are in frequent use.
That said, while some licenses can be used as-is and without modifications, software developers love to fiddle with open source license texts. For example, the popular and quite fundamental JSON project added the obligation
The Software shall be used for Good, not Evil
to the MIT license to create the JSON license. This makes the JSON license a non-open source license, because it restricts the use of any so-licensed code to not do evil. In the case of the JSON license this is a no-op i.e. has no further consequences, as people will not agree on what is good or evil.
In other cases, license text modifications are less harmless. Developers like to take popular open source licenses and subvert some of the wording to make the licensed software commercial software, for example, by restricting fields of use or by requiring financial compensation.
As a consequence, a developer using open source components needs to read each and every license carefully to understand their implications.
At the time of writing, the ScanCode LicenseDB counted more than 2000 practically relevant license texts, commonly derived from any of the OSI-approved licenses. Most modifications are harmless and don’t change the meaning of the underlying open source license, but as noted, some aren’t.
Each license is its own legal text. Developers need to comply specifically with the obligations spelled out by that text. Still, as noted early on, some of the obligations keep recurring and can be handled in a consistent way across all valid and well-intentioned licenses.
Effectively, there are two main obligations that you may have to fulfill:
- Provision of legal notices (attribution, license texts, and other notices). The open source legal notices are a best practice in which you compile all texts you are required to provide to recipients into one file, the legal notices file, which you then pass on to recipients.
- Provision of corresponding source code (copyleft). The provision of corresponding source code is how you comply with a copyleft obligation: By truthfully collecting all needed source code, tooling, keys, etc. so that recipients can rebuild the software and fix any bugs.
These obligations only fall upon you if you are distributing open source code. If you are an end-user, you typically don’t have to do any of this.
Beyond these two main obligations, there are further important but less frequent obligations (like indemnification) that you may be required to fulfill. The details will be explained in the specific licenses and you need to read and comply with them.
License compliance can be a tedious process, so you will want to automate as much as you can and standardize most of the human involvement. We will discuss all this in turn.
© 2024 Dirk Riehle, used with permission.
Next up: The open source legal notices