As developers today, we stand on the shoulders of giants. By building applications on top of an existing landscape of established open source components, we can spend our valuable time innovating rather than reinventing the wheel. But there is a distinction between using someone else’s code for inspiration and using open source directly without understanding the legal framework.
License restrictions
If you do not follow the license restrictions associated with the open source code you are using in your product, you can open yourself up to not only bad public relations but some serious lawsuits. To help mitigate the risk, someone in your team needs to have at least a basic understanding of open source license restrictions. It helps to put in place an actionable list of best practice and methods to automatically detect open-source components that may find their way into your code base.
Developers should follow the licensing conditions for every piece of code that uses open source, including subcomponents, no matter how small. This can be confusing. There are hundreds of different open source licenses and each has its own unique usage conditions. However, most open source licenses can be split into just a handful of categories. ‘Copyleft’, for instance, usually require developers make source code and binaries also available under the same license, but for documentation, there are different licenses; and ‘permissive’ applies only minimal restrictions such as author attribution.
License Compliance in CI/CD Pipelines
Before licensing considerations can take place you need to know exactly which open source components have found their way into your repository. Most companies we deal with do not know the full inventory of components they use, or manage the inventory in Word/Excel documents, hoping the documents are up-to-date, which is a little scary. That’s where automated tools can come in. With the trend in the industry towards DevOps methods, it is now usual to have an automated toolchain which runs on each code check-in. The standard steps include building the software, testing (unit…
