What can happen when you don’t manage your use of open source?
This article was originally published on JAXenter.com.
It was recently reported that Oracle will begin to enforce commercial terms on customers who thought they were using free Java software. However, companies using Java may not even realize they should be paying for the software in the first place – since most think it is free. Jeff Luszcz, VP of Product Management at Flexera, weighs in on the topic.
The confusion lies with Java Standard Edition, available for download from Oracle’s website. If you only want to write a Java application, feel “free”. The problem arises if you install that application on hundreds of desktops, requiring Microsoft Windows Installer Enterprise JRE Installer – which is NOT free to use… And it does not stop there. There are additional parts and editions of Java that are not free either.
And Oracle is not alone.
The tales are legendary – the software vendor that was forced to take a profitable software product off the market. Or the undiscovered software vulnerability (remember Heartbleed?) that put millions of software users at risk.
Unmanaged open source software
The culprit? An unmanaged open source component that is built into a commercial software product that violated the open source license – or, that contained a software vulnerability that no one knew about. Unmanaged open source security and compliance risk are reaching epidemic proportions – threatening the very integrity of the software supply chain.
Today, as much as 50 percent of the code found in most commercial software packages is open source. Most software engineers use open source components to expedite their work – but they do not track what they use, understand their legal obligations for using that code, or the software vulnerability risk it may contain.
Worse yet, most software executives have no idea that this is going on. And if they do not know what Open Source Software (OSS) is used, they can’t ensure the proper processes and automation are in place to minimize open source security and license compliance risk. Software Chief Executive Officers need to confer with their Chief Technology Officers, security officers and engineers to understand the state of their open source license compliance and security operation. If it is found to be lacking, they should implement best practices and automation that are necessary to reduce the risk.
Start tracking now
Even though their technology depends heavily on OSS, most organizations are not properly tracking and monitoring their use of OSS and third-party components. Many have difficulty producing a Bill of Materials (BOM), or list of the open source they are using. Even during a Merger & Acquisition (M&A) – when a company is expected to provide as much information as possible – most organizations are unable to disclose even a single open source project they depend on. For many companies who have some components on their list, generally it is still a small fraction of the true list of OSS and third-party use. Research shows that a company’s true list is typically on average 20 times larger than their current disclosure.
Pretty much every open source component is governed by a license, with obligations that a company must follow if they are distributing a product containing that component. These obligations typically include passing along the text of the license, copyright statements, and in some cases the source code of the component or complete product. Again, most organizations are not disclosing the content as required by the open source licenses.
How does this happen?
Developers are under intense pressure to build software products and release them on a tight schedule. Tracking and managing their use of open source has not been a part of most organization’s heritage and is often ignored until it causes a serious high-visibility issue. Many people who find themselves managing a software team did not have access to the same amount of open source when they were learning to be developers. Senior management is also unaware of the license compliance and security requirements of using OSS, so do not require compliance or OSS management. Often, it takes an outside event such as a hack, M&A activity, compliance request or OSS disclosure requirement from a customer to kick-start the process.
What can happen when you don’t manage your use of open source?
The two most common issues encountered: not properly managing their use of open source and fulfilling their license compliance obligations, and finding themselves at risk due to vulnerabilities in the open source they are using.
The first issue often leads to the second. If a company does not know what open source and third-party components are used, it is impossible to comply with the license requirements. It may also mean that any current or future security vulnerabilities discovered in those software components are not tracked and handled. It is very common for OSS components to have new vulnerabilities discovered after they are first shipped. These vulnerabilities can sit silently in a product until taken advantage of by attackers.
Revenera’s Monetization Monitor
Our latest research reports explore trends around software monetization, usage analytics, piracy, and compliance.
How to start managing your use of open source
The first element of an open source management program is education. The basics of OSS license compliance management needs to be taught at all levels of the organization, not just at the developer level. Senior management must be made aware of the license compliance requirements, as well as the need to periodically update products in order to repair vulnerable open source components. In many companies, a small team of subject-matter experts across many disciplines at the company forms an Open Source Review Board (OSRB). This team often includes technical, legal, IT and management. The OSRB will help set policies, respond to license compliance and security events and provide training and knowledge to the rest of the company pertaining to open source. The group can be ad hoc or more tightly structured depending on the maturity and size of a company.
These policies can then be implemented by the development teams. First, to comply with all the open source licenses they are using, as well as create a process to discover vulnerable components and release updates as needed. Software Composition Analysis tools exist to help discover and manage the OSS and third-party content that is being used. These tools can also help automate the process of vulnerability alerting.
What does successful management look like?
After a company enacts policy, educates its employees and rolls out a Software Composition Analysis management solution, it will be able to display some of the hallmarks of OSS licensing compliance and vulnerability management. These include creating a BOM for each software release, following the license obligations as required and creating updates to products when vulnerabilities are discovered. By setting up these processes and following OSS best practices, companies are able to successfully comply with community expectations and reduce their exposure to OSS-related vulnerabilities. While OSS is free of costs, it is NOT free of obligations.
Readers also liked:
