License compliance - ignore it at your own risk!

Stay on top of your open source software licenses

Adding new open source packages to applications is simpler and more accessible than ever before.

There has been a continuous rise in the use of open source software components within software development. Right now, there are 40+ million accounts on GitHub, with a projection that it will reach 100 million users by 2025.

However, with such explosive growth comes risk - failing to properly manage the software supply chain by keeping track of components, their dependencies and licenses, can have disastrous consequences.

Using and sharing reusable build-blocks to speed up the software development cycle is now common practice. As a result, development ecosystems such as npm (Node Package Management) have grown in their dependence on third-party libraries.

Npm is the world’s most widely used client for JavaScript and the go-to-place for developers to fetch javascript packages and reuse code to speed up the development process. The npm registry has already reached a milestone of one billion daily downloads.

“There were 1.5 million npm packages in the public registry alone in Feb 2021"

But - it seems developers, security, legal teams and business owners are mostly in the dark when it comes to their license obligations.

What is an open source software license?

Open source software (OSS) licenses, allow developers to share their source code (components, libraries and more) as open-source. Other developers can then freely (to different degrees as defined in the specific license) use these components in their own work.

When you use open source components, you’re implicitly signing a legal contract that is enforceable. It binds you (i.e. developer or company), and the author on how you will use their code. Depending on the license type there can be a wide disparity in the rights they grant and the obligations they enforce.

Why are licenses necessary? Isn’t open source free to use?

Open source code is free and available for anyone to use — but there are limitations. For each particular open source license there are terms and conditions that restrict users on what they can or cannot do. It’s then up to each developer or business to remain compliant.

What could possibly go wrong?

Every open source component, as well as any component on which it depends, will also have unique terms and conditions that must all be complied with.

In the software industry companies adhere to the Software Development Life Cycle (SDLC) to ensure fully-tested, production ready software. Following the process step by step removes the typical pitfalls of software development projects.

But, license compliance needs to be verified from the very beginning of the SDLC process. The later you leave it, the greater the likelihood of disruption that could impact the distribution of your software.

How does licensing affect derivative work?

It’s important for developers to have an understanding of how static versus dynamic links can affect licensing for derivative work. This distinction is critical when it comes to interpreting the licensing requirements.

Once the modified code is released, if the appropriate terms and conditions of the license are not met, there is a real possibility of being forced to distribute all of your proprietary in-house developed software.

What are the potential consequences of non-compliance?

• Penalties and restrictions on selling your company’s software product until compliance is met
• An injunction may prevent distributing a product until the source code is released
• The later a problematic dependency is discovered the more costly it will be to resolve
• Negative press coverage for non-compliance
• Loss of reputation with customers
• Damage to credibility with the open source community
• Discovery and due diligence costs in response to a compliance inquiry on a particular source code
• Possible external legal costs to address a claim

Without fail the consequences of non-compliance claims have been that the defendants have ultimately had to comply. Plus, the costs of responding to a claim have typically exceeded those of the time and money needed to follow basic compliance.

Different types of open source licenses

What are the differences between commercial software licenses and open source software licenses?

With most commercial licenses, the main obligation is to limit the right to use or distribute the proprietary software to authorized users - i.e. those that have paid for it (think Microsoft).

Proprietary software developers use copyright to take away a user’s freedom, which goes against the open source ethos. The licensor retains the exclusive and sole rights to edit, inspect, change and enhance the software.

An open source license is not purchased, it’s free. The user is able to modify, enhance and distribute the code as they see fit. However, there may be terms and conditions that a user needs to respect and comply with once they distribute their software.

Depending on the type of open source license, the user may be required to reproduce specific license text, in addition to making their software available when distributed. The license is there to define what the responsibilities are for those that use and distribute the software.

Do you know which open source licenses you are using?

With thousands of different software licenses in existence, there are more than 200 which are categorized as open source licenses. Of these, roughly 80 are approved by the Open Source Initiative (OSI). All these different licenses have their own terms and conditions, some copy-left, some permissive and others with no license at all.

Today, permissive licenses far outnumber copyleft. The open source community is embracing those components with licenses that are the easiest to use. Permissive licenses offer a simpler compliance solution to follow, reducing the licensing headache.

“90% of the code in modern applications is open source code developed by others"

Understanding the different types of open source licenses

Open source licenses can generally be divided into two main categories: copyleft and permissive. This division is based on the requirements and restrictions that an author places on users.

A permissive license places minimal restrictions on how others can use the open source components. It requires next to nothing in return in regards to any obligations going forward.

A copyleft license provides the same permission as a permissive license, but requires you to release any derivative works you make under the same copyleft license terms.

Many open source licenses dictate how or if the software can be used in commercial applications, and the requirements and restrictions under which this can be done.

For a software component without a licence it is not free to use. By default it is fully copyright protected, so developers have no legal rights to use, modify or share it.

As a community, open source developers are doing their best to make sure open source is easy to adopt, use and comply with. And businesses can also do their bit by making sure that they comply with license requirements for the code they use.

License compatibility

Combining a number of different licenses together can be a challenge. Since a particular license’s permissions and conditions may conflict with the requirements of another.

In general, permissive licenses are compatible with each other, which makes them popular components for proprietary software products. And because they are permissive they are compatible with copyleft licenses.

In general the copyleft licenses are more problematic for commercial software as they are known as reciprocal licenses. This means that derived works must also be released under a compatible copyleft license.

Based on the premise that anyone can benefit freely from the previous work of others, but that any modifications to that work should also benefit everyone else as well, and thus must be released under similar terms.

Why is open source compliance so important?

Why have open source licenses?

Open source components accelerate the software development cycle. Backed by hundreds and sometimes thousands of communities that represent the developers of OSS.

Although the software is free, users do have a responsibility to ensure compliance to the obligations that accompany a license.

Open source compliance is the process by which the users and developers of OSS observe copyright notices and satisfy license terms and conditions.

Licenses help companies protect their own intellectual property, that of third-party suppliers and facilitate the use of OSS in commercial products.

What are the consequences of non-compliance?

Using a package that is unlicensed or with the wrong license can lead to compliance failures, and as a consequence:

• Add time and expense to removing a component
• Mean “back to square one" if you need to replace and redevelop a segment of code
• Post-release face an infringement claim
• Potentially jeopardize exclusive ownership over any proprietary code
• As a result of a breach of the license obligations a licensor may request a software producer to refrain from future distribution of their components.
• Or work with a component that has a license nobody is maintaining that makes it ripe for exploitation

Using a tool like Bytesafe can identify license information in the open source software that you currently use:

• Packages can have multiple licenses
• Use it to restrict problematic or unlicensed packages
• Scan all package files and notify when license issues are identified

Legal risks and obligations

Copyleft effect

Copyleft says that anyone who redistributes the software, with or without changes, must pass along the freedom to further copy and change it.

Modifying of OSS

In distributions of modified versions, some licenses require that such changes be formally highlighted together with accompanying information on the date and scope of changes made, or they require that modified components be renamed to avoid confusion with the original version.

License text

Most open source licenses contain specific obligations concerning information and documentation. In many cases, licenses require that the respective license text be delivered together with the software when it is distributed.

Missing license texts are a classic case of license infringement, which can lead to the loss of all usage rights in the case of some licenses and that, in practice, sometimes entails enforcement actions such as an interim injunction.

Copyright notices

Besides the license text, in many cases the provision of a copyright notice mentioning the name of the author is also required.

The copyright notices can usually be found in several locations within software. Some of them are contained in the file with the license texts. Furthermore, the source files can also contain copyright notices, often distributed over hundreds or thousands of files.

Due diligence

When investing in a company, a critical part of the due diligence process often relates to proprietary software, and the use of open source components.

The OSS used in a proprietary product may have regulatory and compliance ramifications that need to be assessed. So consideration needs to be given to a company’s software license inventory, to identify the components used and ensure compliance.

When do the license obligations apply?

Typically for obligations to apply it requires the distribution of the software.

Composition of your codebase

Where should you focus your compliance efforts?

It won’t surprise you to learn that the code for a typical commercial software product today is in the majority of cases open source.

As the usage of open source continues to grow, it’s critical that developers, companies, legal teams, etc. make an effort to learn the composition of their product’s codebase.

Each component, and its dependencies have license restrictions and obligations that must be complied with, ranging from the permissive “anything goes" to the more restricted, copyleft license.

But to comply, you’ll need to know what open source components are in the codebase. Permissive, copyleft or unlicensed, they all have consequences if you fail to comply.

And just because a component is unlicensed it does not give you carte blanche to do what you want. No license means that by default it is under exclusive copyright, so you can’t use, modify or share the code.

It makes sense then to focus compliance efforts on addressing the obligations of the more restrictive software licenses first.

There are several organizations who provide guidelines and definitions regarding software licenses.

The Free Software Foundation maintains a non-exhaustive list of software licenses and the Open Source Initiative defines a list of some 80 certified open-source licenses.

License scanning

When you incorporate open source into your software product, it’s risky to assume that the main project license that you are aware of is the only license you need to comply with.

A component’s license may not necessarily apply to each individual file or each line of code within a single file. This is because open source projects evolve from the contributions of hundreds or even thousands of community members, all from different sources.

Any open source component could be dependent on a myriad of licenses that you might be unable to identify without performing an in-depth scan. With each license there could be different conditions and imposed obligations.

Observed vs Declared licenses

Packages stored in a Bytesafe registry are scanned for license information - in all package files. Observed licenses, where actual license files or license text has been identified in package files are displayed both for the latest version of a package as well as for individual package versions.

This information supersedes declared license metadata where the actual license text is missing (no guarantee for metadata to be accurate or cover actual licenses).

Scanned license information allows users to identify problematic licenses or receive notification of unlicensed or unstandardized licenses.

Bytesafe License Compliance plugin

When enabled, the plugin scans files in all packages in a registry, compares licenses to the active license policy and flags potential license issues. Identified licenses for a package are then displayed as license badges. A package can have one or multiple license badges (packages can have multiple licenses).

In addition, if no license information is found for a package, this will be flagged as a potential license issue. Packages that are not licensed are normally copyrighted and further investigation may be needed.

The Bytesafe scan can be used in the following ways:

• Block non-compliant licenses - make sure unwanted licenses are not added to your registries with license policies
• Unlicensed source code - identify packages that are unlicensed
• Missing licenses - identify packages that are missing actual license text, a potential license compliance issue
• Non-standardized licenses - identify non-standardized licenses that require a follow-up to review the copyright status

Common Compliance Mistakes

Unlicensed source code

Unless you include a license for your code that specifies otherwise, nobody can copy, distribute, or modify your work. Unlicensed software is fully copyright protected by default, so other developers have no legal rights to use, modify or share it.

So, until it passes into the public domain or is covered by a different license, it is not legally usable. Which will impact directly its reuse and sustainability.

Ensure compliance prior to distributing your software

The most important lesson of non-compliance cases has been that the companies involved ultimately had to comply with the license terms.

So, take the time to familiarize yourself with all the obligations, scan to see all dependencies and their license conditions.

With open source code now so widespread in its use by developers, it is critical that the responsibilities for compliance are shared across an organization. So that all open source software used in products can be identified and its license verified.

Keeping on top of compliance means setting up robust processes and procedures to ensure compliance:

• Read and understand what are the obligations of the license to make sure it matches what you want to do with the software
• With the software that you have developed notify recipients of the product that it contains OSS and inform them of their rights with respect to that software
• Publish a licensing notice on your product website
• Train staff to understand company policy governing the use of OSS.

Don’t forget to support the open source community

For companies using OSS in their commercial products, it’s recommended to develop and maintain a good working relationship with the open source community. That can start by making sure you are complying with the licenses of the open source software being used.