OSS compliance

These days a big part of enterprise and other software projects' code bases form out of open-source code, it is crucial for enterprises to follow open-source license obligations and restrictions. Of course these demands apply also to other software projects, but it is particularly important for corporate level projects because of the severity of the sanctions for disobeying them.

Generally open-source licenses can be divided into two groups: copyleft licenses as GPLv2 and GPLv3 and permissive open-source licenses such as MIT license. For commercial software projects, license compliance basically means that components under strong copyleft licenses are not used, since they demand to make source code publicly available. Of course there are many other important issues that need to be pointed out, but that is the most obvious one. Because developers may introduce components to the project as they work without paying attention to the licenses, we must have another way to check the project's licenses and ensure license compliance. Since we want to get the software bill-of-material (SBOM) as soon as new components are introduced into the project, it is most efficient to integrate the generation of the SBOM into the CI/CD pipeline, which is de facto in modern software development. This way we get an up-to-date SBOM at all times which is regenerated for every build. This information must also be made available to all appropriate people, so it is good to have all this kind of build related meta-information collected in one place. We also can generate license disclosure documents from there, when we are shipping our product, since all necessary information is already there.

In some organizations it is required that file level scans are performed for every open-source component to identify which license it is distributed under. This is known as the clearing process and it is good to keep it separated from generation of the SBOM when talking about open-source license compliance. Clearing work requires reviewing scan results manually, because license text may be modified, which makes it really really hard for machines to identify the license with 100% certainty. This is another fact that makes open-source license compliance harder. On the other hand software composition analysis and viewing the SBOM can be fully automated with the help of various open-source licence compliance tools provided by commercial vendors and the open-source community.

This far we have mentioned that we use different software tools in the process of becoming license compliance. As well as processes that we talked about also tools can be roughly divided into two groups. There are license scanning and scan result review tools and on the other hand there are component identification tools. As an example about purely license scanning tools, there are FOSSology and ScanCode, which both themselves are also open-source. For software composition analysis we can use open-source software called OSS-Review-Toolkit or a commercial product Whitesource. The third group of open-source compliance tools are like knowledge bases where information about open-source component usage is gathered. This includes information about which open-source components are there in our project and licensing information of those components. These tools also provide a possibility to generate reports as SBOM and license disclosures from them. As an example of these tools is sw360, which is an open-source project under Eclipse Foundation. For more information about license compliance toolchain and other trends in software development, keep following Verifa's blog posts and at Twitter @verifaio.