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 Software, 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.

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.