What is OpenChain?

TL;DR much of the modern world is built upon software, and much of that software is built upon open-source components. Organisations need to understand and manage the legal and security risks associated with open-source software. The OpenChain Specification (ISO 5230) defines the key requirements for an open-source licence compliance program.

What is OpenChain?

The OpenChain Project was set up by the Linux Foundation to create a standard for creating, using and modifying open-source software. Creating a standard like this is important as more software is being created and used extensively without having a clear baseline of quality or structure. Organisations that have OpenChain have greater control and knowledge about how their open-source software is being created or used, meaning they have a reduced risk of misuse and therefore less legal risk.

The OpenChain Project shows organisations where they need to be to be in line with ISO 5230 standard and ensure open-source licence compliance is met so that it is quicker and easier to use open-source software and improve security.

What is Open-Source Compliance?

Open-source compliance is the process of ensuring that you satisfy the legal obligations and copyright terms that come with open-source licenses. Being compliant means you are observing copyright notices and satisfying the conditions set out in the licence requirements.

The main two categories of open source licences are permissive and copyleft licences. Copyleft licences require any derivative work to be distributed using the same licence as the original software. An example of one of these is the General Public License (GPL). There are two different categories of copyleft licenses: weak copyleft and strong copyleft. A stong copyleft license applies to all derivative works whereas a weak copyleft license applies to only the original copylefted work. An example of a weak copyleft license is the GNU Lesser General Public License (LGPL) because code under LGPL can be combined with code under non-free licenses.

Permissive licences are open-source licences that have minimal conditions that users must follow, meaning that they can be modified and copied without an obligation to share the updates to the code. Examples of permissive licences include the MIT License and Apache License 2.0. The MIT License permits users to reuse the code for any purpose and if they include the original copy of the MIT licence when distributing, they can make changes.

A new licence category is emerging that focuses on trying to limit the internal use of software for commercial purposes. Whilst some companies never supply the software to their customers, they still use it internally, meaning they can bypass the Copyleft licensing rules and make money from the open-source software. An example of this type of licence is the Affero GPL licence (AGPL). The AGPL licence is based on the GNU General Public Licence version 3 (GPL v3). GPL v3 has a "SaaS loophole", meaning Saas companies can use software licensed with GPL without having to share their code or modifications to the code. AGPL, as discussed above, works to combat the "SaaS loophole" and requires full compliance with the software licence, SaaS or not.

The practices that come along with open-source compliance include identifying the open-source licences, tracking them throughout your software, regularly reviewing them to ensure you are using them correctly, and fulfilling the obligations to the licence when the product is published. It is becoming more difficult to track in recent years because of the increasing depth of dependency trees. It's common to not know everything you are using.

Staying open-source compliant means that if you are using open-source software, you must honour the copyright and comply with licences associated with it and all the way down the dependency tree of components.

Whilst you may see a lot of open-source licenses, you've almost certainly come across non-open source licenses too. Proprietary licenses are licenses that generally charge a fee to use the software. They restrict usage, modification and distribution of code, however each license is different as it depends on the organisation licensing their product to write their terms. Typically they trade a compiled version of the software, meaning users don't get the source code along with the software, they only get an executable. An example of this are Adobe licenses which allow the user to download the software on a certain number of devices only, they have restrictions as to how they can distribute the software they are being handed.

What is Dual-Licensing?

Dual licensing is precisely what it sounds like – having two (or more) licenses or legal obligation documents. Generally, it allows users to choose between an open-source license (e.g. GPL) and a commercial license depending on its use.

An example of this is Oracle’s MySQL. If there are commercial users who do not wish to distribute the source code under GNU General Public License v2 (GPL), then they must go into a commercial license agreement with Oracle. However, if they wish to combine and distribute the source code of their own applications using MySQL, then it is licensed under GPL. Having dual licensing is of interest to software developers as they can benefit from the advantages of both types of licenses.

Those who use it and modify it can contribute freely to the software and can help it progress further, whilst making good use of it. Alternatively, if it is being used in a commercial setting then the developer can earn from leasing out the software. Commonly, there are two different ways of presenting dual-licensed software. Oracle has two licenses for the same product set out with separate conditions. However, some organisations decide to have two separate products, one with a commercial license (often presented as an ‘enterprise’ version) and the other with the open-source license (commonly GPL).

The Changing Supply Chain

The software supply chain is made up of all the components, libraries, tools and processes that are needed to build a software system. Having a formal artefact to provide information about the supply chain may show dependencies.

By having these artefacts, software supply chains can be used to track products as they are being developed, how it is going to be used and how the process is currently going.

The above schematic shows the supply chains of systems are becoming less vertically integrated (as shown on the left) and more complex (as shown on the right). Becoming less vertically integrated means more software components are being used from external sources.

As explained in the risks above, having more external open-source components means there is more to track in the system as it increases the number of dependencies. These dependencies are constantly being updated and used by many people, meaning vulnerabilities are more likely to be found in the code.

With the vast amount of open-source code available, making it easier and cheaper to develop programs, it’s bound to be hard to keep up with every single one. Being able to manage all your open-source code so that updates can be easily implemented is key to eliminating vulnerabilities.

Whilst open-source software is generally cheaper than developing internally, it isn't free. The concept "free as in puppy" is based on the idea that you can be given a puppy for free, but it isn't really free, there are a lot of expenses that come with it, for example, food, the vet bill, and the time needed to walk it (whilst not financial, still a cost). This is the total cost of ownership (TCO), which is the price of the asset along with the cost of operation. Whilst you might be able to get free open-source software, both financial and non-financial costs accompany it. This includes the setup costs (training and implementation) and the operational costs (maintenance and development). By taking a dependency on an OSS library, you are essentially signing up to own it. The current maintainers may leave the project, you may discover a vulnerability or bug that no one else is motivated to fix, and if it's critical to your organisation, you have three choices: do nothing, find an alternative, or take ownership of the project.

As systems become more complex and interconnected, tracking these open-source components and staying compliant becomes more difficult. Therefore, there becomes a need for a system that can manage this, which if implemented correctly can improve compliance, meaning ease of risk and an increase in efficiency.

Some sites list the vulnerabilities in open-source code meaning that if you have a software bill of materials (SBOM), you can compare to identify if any of the vulnerabilities listed on these sites match your SBOM. This is a useful tool to have, however it increases the need for management systems to be in place when looking at open-source code and its dependencies. Whilst these sites are open to everyone including people who want to target vulnerabilities, they're brilliant at highlighting areas that need to be updated so that this can happen quickly and efficiently.

For example, one of these websites is GitHub Advisory Database which lists the vulnerabilities to open-source software. It states the severity, when it was found, and what version number it affects. Whilst this is very useful, it increases the need for organisations to have the processes and resources in place to adapt to these changes.

By keeping up with open-source compliance goals by following OpenChain's framework, the risk of vulnerabilities can be reduced. This means that a better understanding of the use of open-source code within an organisation can help better control the software supply chain within it.