When you want to share your source code (components, libraries, dependencies, etc.), you need to attach an open-source software (OSS) license to it. Other developers can then freely use it in their work or modify it (to the degree defined in the license).
In many cases, besides the rights the OSS licenses grant, there are obligations as well. These obligations will apply once the user distributes the code.
Here’s The Linux Foundation’s take on it:
“Open source compliance is the process by which users, integrators, and developers of open-source software observe copyright notices and satisfy license obligations for their open-source software components.”
Why do you need to worry about license compliance?
Not adhering to the terms of an OSS license or failing to attach one, at best could entail a headache in replacing a component; at worst, it could bring legal suits and the risk of losing ownership over your proprietary code.
Some other potential consequences of non-compliance may include:
- Restrictions on selling your software product until compliance is achieved
- Restrictions on distributing your product until the source code is released
- Jeopardizing your ownership over proprietary code
- Additional expenses on product development if a problematic dependency discovered late
- Negative user feedback and loss of reputation with customers and within the open-source community
- Legal costs to resolve a claim
Many will remember cases of GPL violations by D-Link, TomTom, and more companies in the early 2000s. Without an exception, all the defendants in non-compliance claims ultimately had to comply. The companies spent more money and time resolving non-compliance claims than they would have if they followed a basic compliance procedure.
Why are licenses necessary? Isn’t open source free to use?
Can’t you just release code publicly without a license?
A short answer is no. Your piece of software will not be open-source if it doesn’t have an open-source license. Under copyright law, such software is copyrighted by default, with all the restrictions that this implies.
If you want anyone to use your code freely, you should ensure certain liberties commonly called “the four freedoms“. They say that OS software may be used, studied, modified, and distributed freely, as long as the license is respected.
For the first three, there are no conditions of any kind; you are free to use, study, and modify the code for any purpose. If you move beyond that and decide to distribute your modified version (or the original), this is when open-source license compliance starts.
Missing license texts are the number one cause of license infringement cases, which, as we’ve seen above, can lead to the loss of ownership rights and enforcement actions such as an interim injunction.
Are you using the right open-source licenses?
Using the wrong license is another common issue. This may have large-scale consequences in a popular open-source project.
Some may recall the Nmap case when a change in licensing terms caused version downgrades and removals of the Nmap component from open-source Linux distributions.
When choosing a license, consider carefully how you want your users to use it and what the license says about copyright and jurisdiction.
Some licenses are very permissive and are easy to comply with, such as the Apache, BSD, MIT, and X11. With licenses like CDDL and Mozilla, simply committing code back to the community repository is likely to be enough, but may require some additional consideration. Strong copyleft licenses like the GPL ones may need an audit process.
Your project may require combining a number of different licenses together, as most of the bigger projects do. This presents additional challenges, as you have to make sure licenses’ permissions and conditions do not conflict with the requirements of another. Permissive licenses, as a rule, are compatible with each other and for this reason, are often used as components in proprietary software. Permissive licenses are also compatible with copyleft licenses.
Copyleft licenses are the most tricky to use on commercial products, as they demand any derived code to be released publicly under a compatible copyleft license.
How to stay on top of your open-source software licenses
The code in most of the commercial softwares is 90% open-source, which often has been taken from a third-party source.
Due to this, developers or companies need to make an effort to learn all their product’s codebases to make sure they are compliant and there are no conflicts between licenses, all conditions are respected and necessary attributions are made.
A clear policy regarding OSS compliance is a must. The goal is to have an inventory of all the open-source components, their dependencies, and corresponding licenses in the codebase.
Many software development teams still do this manually. While this may be sufficient for components and their licenses, if we add the dependencies to the mix which may have completely different licenses, things get rather complex. For big engineering teams and software developers license compliance gets burdensome and time-consuming.
An open-source component could be dependent on a myriad of licenses that could only be detected by performing a scan using a semi-automated tool. Such scanning helps identify problematic licenses or detect unlicensed or unstandardized licenses buried deep in the code.
There are many tools available; some of them are called file scanners or code scanners, others CI (continuous integration) scanners and component identification tools.
It usually pays to use one, as an open-source code used in the product can be identified and its licenses verified relatively easily and fast.
