With open source software ubiquitous and irreplaceable, setting up a license compliance and procurement strategy for your business is indispensable. No software engineer I know wants to voluntarily talk about open source compliance but not doing it may lead to a lot of pain. Do you remember the litigations by GPL-violations with D-Link, TomTom and many more in the early 2000s?
It’s better to keep in mind open source license compliance from the early stages of development when creating a product: you want to know where all its parts are coming from and if they are any good. Nobody thinks they will be asked for the bill of material of their software product until they are.
“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.” (The Linux Foundation)
Objectives for open source software (OSS) compliance in companies:
- Protect proprietary IP
- Facilitate the effective use of open source software
- Comply with open source licensing
- Comply with the third-party software supplier/customer obligations
What is a software license?
Put very simply, a software license is a document that states what users are permitted to do with a piece of software. Open source software (OSS) licenses are licenses that the Open Source Initiative (OSI) has reviewed for respecting the Open Source Definition. There are approximately 80 open source licenses (OSI maintains a list and so does the Free Software Foundation although these are called “free software” licenses), split between two larger families:
- So-called “copyleft” licenses (GPLv2 and GPLv3) designed to guarantee users long-term freedoms, make it harder to lock the code in proprietary/non-free applications. The most important clause in these is that if you want to modify the software under copyleft license you have to share the modifications under a compatible license.
- Permissive/BSD-like open source licenses guarantee freedom of using the source code, modifying it and redistribute, including as a proprietary product. (for example MIT, Apache.)
Despite the variety of license, companies sometimes invent new ones, modify them with new clauses and apply them to their products. This creates even more confusion among engineers. If your company is looking to use open source software, tracking and complying with every open source license and hybrids can be a nightmare.
Establish an open source license compliance policy
The goal is to have a full inventory of all the open source components in use and their dependencies. It should be clear that there are no conflicts between licenses, all clauses are met and necessary attributions to the authors are made.
Whether you have an open source project using other open source components, or a proprietary project using open source components, it is important to establish a clear policy regarding OSS compliance. You want to create a solid, repeatable policy to outline what licenses are acceptable for your specific project.
Ways to execute OSS compliance
Manual
A surprising number of companies are still using this approach. Basically, you create a spreadsheet and manually fill it out with components, versions, licenses and analyze it against your policy.
This works out well for smaller projects if they established a compliance policy (list of licenses or clauses acceptable in the company) from the beginning to spare themselves trouble in the future. In this scenario, every developer must review and log a software’s license before introducing the open source component.
The downside of this approach is that as the quantity of OSS components in the project grows, it becomes more difficult to keep track of relationships between licenses (if they all work together or there are conflicts). It is vital to list them as the dependency might have a different license than the actual library you are using.
Semi-Automated OSS Compliance
This is a more reliable approach and is becoming more popular, as the importance of open source compliance practices grows along with the risks associated with ignoring these practices. There are many tools available, in a way that it gets overwhelming. Why semi-automated? Because there are always false positives if the license is not explicitly referenced in the header and you still have to read through some of them to discover special terms or conditions.
Of the tools I’ve seen, there seem to be four main approaches used:
- File scanners – usually involve all sorts of heuristics to detect licenses or components that usually would be missed by developers. Usually, these tools offer different formats for the output.
- Code scanners – it is just exactly what it sounds like. You can use them periodically to check for new open source components.
- CI (continuous integration) scanners – these tools integrate into continuous integration or build tools. This will automatically detect all open source components in the code every time you run a build. The idea is to create a unique identifier for each open source component in the build and reference it against a database of existing components. You can also set policies to break the build if a blacklisted license is found.
- Component identification tools – these tools can help you produce SBOM (software bill-of-material), the list of OSS components in your product.
Tools worth checking
Open source and free tools:
Proprietary Tools:
And so many more…
Organizations:
- FSF Free Software Licensing and Compliance Lab
- Open Source Initiative (OSI)
- Software Freedom Law Center
- Software Freedom Conservancy
- Freedom Task Force (FSFE)
Conclusions
For smaller projects, fully manual tracking might be sufficient to achieve license compliance. For more complex projects, especially the ones built in an agile style with regular releases, automation is better. Whichever way you choose to handle OSS compliance you should not ignore it for the sake of your project and sustaining open source community. Come by our forum to discuss or ask me questions.
