Are you aware of the business risks with open source licenses?
As a business that builds proprietary applications, no doubt you’ll already be using open source components. Or maybe you are using an application that 9 times out of 10 will contain open source components.
How do we know?
GitHub security researcher Maya Kaczorowski cites data that suggests between 85-97% of enterprise software codebases come from open source components. And the average project now has 203 dependences, according to GitHub’s 2020 State of the Octoverse survey.
The growth in the number of people using open source and the ways in which they can participate, means more and more ways for companies and people to get involved.
Reusing open source components in applications has become simpler and more accessible than ever before. Therefore, the amount of open source components in the codebase of proprietary applications keeps on growing.
Why use open source components?
- Speeds the development of proprietary applications
- Provides useful features that developers would otherwise have to write on their own
- Keeps a business on the cutting edge of technology
- Saves money (It’s free and anybody can use it)
Let’s focus for a second on that last point.
Open source code is free and available for anyone to use — is true, but there are limitations.
Every open source component, as well as any component on which it depends, will have unique terms and conditions contained in a license. These license terms restrict users on what they can or cannot do.
Licenses help companies protect their own intellectual property, that of third-party suppliers and facilitate the use of open source in commercial products.
As a business, you then have the responsibility to remain compliant with all of those license terms.
Open source and licenses
When you decide to use open source components, you’re implicitly agreeing to legal terms that 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 big difference in the rights they grant and the obligations on the user.
As a business, open source can enter your proprietary codebases through a variety of channels. For example, third-party vendors, an external development team you have outsourced work to and of course, in-house developers.
If as an organization you’re not fully aware of all the open source components in your application, as well as the risk of unknown vulnerabilities and dependencies - you’ll expose your business to license compliance risk.
Each open source component, and its dependencies have license restrictions and obligations that must be complied with.
But to comply, you’ll need to know what open source components are in the codebase. Permissive, copyleft or unlicensed - all of which have different conditions and consequences if you fail to comply.
Different types of open source licenses
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 then on a multitude of licenses that you might be unable to identify without performing a scan.
As a business you may be more familiar with proprietary software licenses. They use copyright laws to retain the exclusive and sole rights to edit, inspect, change and enhance the software.
With an open source license the opposite is true, as the user is able to modify, enhance and distribute the code in any way they like. However, license terms and conditions must be followed when the software is distributed.
Open source licenses can generally be divided into two main categories: copyleft and permissive.
Today, permissive licenses far outnumber copyleft licenses as they are the easiest for developers to use. Permissive licenses offer a simpler compliance solution to follow, reducing the licensing and software distribution headache.
A permissive license places minimal restrictions on how others can use the open source components. It is often referred to as “the anything goes” license because of the lack of any obligations.
A copyleft license provides the same permission as a permissive license. But are more problematic for commercial products as it usually requires you to release any derivative works you make under the same copyleft license terms.
For a software component without a license it should not be assumed that this means it is free to use. By default it is fully copyright protected, so developers have no legal rights to use, modify or share it.
Why should you care about compliance or using unlicensed components?
It can be easy to think of open source as free. Everybody uses it, so why should you bother about license compliance. Open source licenses are subjective and their interpretation depends to an extent on the technical usage or distribution of the licensed software.
At an individual level, you are actually using somebody else’s code - so this needs to be respected. But the likelihood of an individual being able to afford the legal costs to litigate against a bad actor is relatively small.
However, the ethos of open source runs strong in a movement where transparency, peer production and collaboration are the values of the community - with hundreds, maybe even thousands of contributors working on a project.
It is at a business level that non-compliance can become a problem.
A typical scenario can be:
- You’ve developed a software project and need to attach an open source license to it so that you can share it
- You’re selling a commercial application and you need to make sure that the open source license attached to a component is compatible
- Or if you’re investing in a company, a critical part of due diligence relates to checking a company’s software license inventory, to identify the components used and ensure compliance
The time and costs of complying outweigh the consequences of responding to a claim of non-compliance.
According to Kamal Hassin, “Proper licensing and copyright compliance, implemented as part of the normal QA process, can yield savings of between and 40% and 65%, relative to the potential costs of non-compliance.” source.
Responding to a claim normally ends up costing more than compliance in the first place. The later a problematic dependency is discovered the more costly it will be to resolve in the software development process.
Making sure your organization understands the different limitations, conditions, and permissions attached to each open source license component is critical.
There can be major consequences for a business because of a claim.
License infringement consequences
- 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
- Discovery and due diligence costs in response to a compliance inquiry on a particular source code
- Possible external legal costs to address a claim
- Potentially jeopardize exclusive ownership over any proprietary code
- A licensor may request a software producer to refrain from future distribution of their components
Non-compliance direct cost consequences
- Negative press coverage for non-compliance
- Loss of reputation with customers
- Damage to credibility with the open source community
- Adding time and expense to removing a component
Bytesafe - About us
Bytesafe’s vulnerability scanning, dependency management and workflow features are designed to fit right into a modern agile process.
The Bytesafe license analysis functionality can scan automatically for packages in a registry to identify license information. The information gathered on the licenses can then be used by the license compliance plugin to identify problematic (non-standard) or unlicensed packages.
Let Bytesafe help you stay on top of your open source software licenses.
- Restrict problematic or unlicensed packages
- Make sure you are compliant with your current licenses
- Flag legal risks and obligations
- Discover when new licenses are introduced
- Watch out for common compliance mistakes
Want to know more? We can help you!
Do you have questions on how to best setup your teams code supply chain or need assistance reviewing your license compliance? You can email me at firstname.lastname@example.org and I’ll gladly set up consultation or answer your questions directly.