The conditions for the use of open source components depend on the underlying licenses. Therefore, the installers must ensure in the form of a bill of materials of all open source components that it is always clear where which license is used and what obligations arise with it.
That’s why license bills of materials are relevant
There are countless different open source licenses. They should put the principles of open source software on a legal foundation. Although the similarities between the licenses are great, there are still differences – sometimes only nuances, which, however, can have significant consequences.
To give two examples: If the Apache license 2.0 is used, then changes to the source code must be documented and the changes must be supplied in the form of a NOTICE file. The GPL v3 can in turn lead to the fact that the new work must also be published under the GPL.
The problem is that an open source component can make it into a product almost in passing. The developer needed a quick solution to a specific problem? A short search, ignoring the license conditions, a single command line command later and the open source component is integrated. The transitive dependencies of these components, in turn, lead to the fact that numerous open source components end up in the project, which the developer did not even take into account.
Probably the one who employs responsible developers here who coordinate and communicate this step. A bill of materials of the components used together with the licenses then represents the starting point to uncover this circumstance, to identify problems and to take solution measures.
Create license Parts lists
The license bill of materials can be created both manually and automatically. In the end, however, only a combination of both measures remains. Because no matter how sophisticated the automatism used is: there are simply too many exotic licenses and special cases, the consequences of which are not known or unambiguous. A good strategy therefore consists of a high automated proportion combined with the right, manual measures.
Automated measures
All quantitative tasks can be automated. One of these is to search all installed or referenced packages, sources and dependencies for licenses. Corresponding tools already exist in large numbers, such as Scancode Toolkit.
It is important not to run this tool once, but regularly, at the latest before each delivery, but ideally with each build or deployment created. As a rule, the result of such a check is a list that forms an overview of all components and licenses. The most common open source licenses stipulate that the original license must be included in derivative works.
In the next step, the list must be packaged and integrated into the derived work. Either all license texts are attached in the original or – more simply and also usual for large projects such as Chrome – as a list with links, under which the license text can be read and the project can be found. The list should then be sorted alphabetically by component.
Manual measures
Qualitative work, on the other hand, cannot be automated. This includes searching the list of found licenses for outliers or exotics. If there are exotics, then they must be examined in detail professionally or legally. Exotics can be outdated or invalid licenses. It can also be modified licenses that prohibit or prescribe a very specific use. If a license is missing, then the copyright law may apply, which is regulated differently depending on the country.
At the latest with such licenses, the entire component architecture should be checked. This audit must clearly show whether the component is integrated directly into the created product and is therefore a component. Or whether the component is just called. A mere call eliminates almost all the restrictions that an open source license usually imposes.
In the course of the audit – but also independently of it – installed components can of course also be replaced by those that use a license that is easier to comply with. However, this in turn requires a conversion in the project, which in turn can make numerous other measures necessary.
A matter of care
In short: license parts lists are a matter of maintenance, consisting of automatic and manual measures. The bill of materials of open source licenses is not an optional element, it is a mandatory component of today’s software and hardware products. Open source components are used in almost all products. Only those who have a clear overview of the licenses and know all the consequences can deliver products with a clear conscience.
