By Jeff Luszcz, Vice President of Product Management at Flexera Software

The U.S. District Court recently ruled in favor of Artifex – developer of Ghostscript which is an open-source PDF interpreter and against Hancom Office – a South Korean developer of  ”office” apps.  The Northern District of California said that General Public License (GPL) can be treated like a legal contract, and developers can sue if the obligations of these licenses are not followed.  This ruling provides strong legal support to the enforceability of open source licenses.

At the heart of the matter is how Hancom used the Ghostscript library.  Ghostscript is a dual-licensed open source library.  This means it can be used under the terms of either an open source GPL, or under the terms of a classic commercial license.  Hancom incorporated the Ghostscript library into its product.  By not paying for a commercial license, the terms that Hancom would have available to them would be the terms of the GPL.  The GPL would require them to open source their product if it was linked to the Ghostscript library, and they then distributed the application.  Hancom did not provide the source code to their product (and did not elect to purchase a commercial license), putting them in conflict with the license that Ghostscript is distributed under.

Due to this, Artifex sued them at the end of last year, and on April 25, the Federal Court ruled in Artifex’s favor stating that the “GPL provides that Ghostscript users agrees to its terms, if the users do not obtain a commercial license.”

Hidden Risk: The Law…

There’s an old adage in the legal profession: Ignorance of the law is no defense.  So software companies need to beware.  Most aren’t aware of their open source components and compliance status – the risk they face as a result is significant.

As much as 50 percent of the code used in all software, including Internet of Things devices, is comprised of open source software.  While open source provides a convenient short cut for software developers to be more agile and efficient – there’s also a hidden risk: The law.

While open source components are, by definition free and available for anyone to use – there are limitations.  Most open source components have licensing obligations that developers must comply with.  And depending on the component – penalties for failure to comply with the open source license can be severe.  For example, in some instances a software company could be prevented from selling the product in which the open source component has been incorporated.  In other extreme examples, the entire software product containing the open source component could be required to be released as open source in order to come into compliance.

Education is the Answer

While the law is established enabling enforcement of open source licenses – most software developers are unaware of them.  Adding to the risk, most CEOs and general counsel are unaware of the open source components their developers are using.  And they don’t have automated means to scan their code for open source and ensure compliance with licensing terms.  CEOs and General Counsel need to educate themselves about open source software license compliance risk, then ensure their development teams have the training, processes and automation in place to ensure continual IP and legal compliance.

The open source movement has significantly changed how we design and build software.  While Open Source Software (OSS) has been around for decades, commercial software companies have had their traditional software design process flipped upside down in the last ten years.  When classic commercial software packages were first created years ago, there was very little third-party compliance that was required.  Commercial packages would be purchased, small pieces of source code from books would be used and possibly some quasi “open source” toolkits or libraries that were in limited distribution would be brought in.

Starting in the late 1980s and coming into its own in the 1990s and 2000s, open source components have become the backbone of the software industry.  The typical commercial product contains hundreds of high quality open source components, though data shows that only a small percentage of these components are having their open source licensing obligations followed.  Development practices have outpaced internal processes to manage the legal obligations and as a side effect, most companies are out of compliance.

Clear Disconnect

In interviews and discussions with legal teams and development teams, it becomes clear what has led to this disconnect.  The legal teams are under the mistaken understanding that developers are aware of the requirements of using open source libraries, and are taking care of them as they select components and use them.  Development is looking for guidance and policy, but at the same time is often under immense time pressure to get products out of the door.  While there may be high-level corporate policies about open source usage, it is very rare for development teams to have a hard requirement that fulfilling open source obligations is a gate for shipping product.

This disconnect is very clear when a company building a software product is required to produce an independently verified disclosure of all the open source and commercial code it uses.  This is very common request during mergers and acquisitions, during Original Equipment Manufacturer relationships and at the request of large enterprise companies.  Organizations are very surprised to see a 20 times or more difference between what they think they are using, and what they are really using.  They are typically out of compliance with each of those previously unknown components.

Acquirers and customers typically require technology companies to come into quick compliance from a legal perspective, as well as a vulnerability perspective.  This means that the technology provider is required to update their software in order to fulfill the obligations of the open source they are using.  The required actions include putting proper license notices and copyright statements in documentation and About Boxes, changing how libraries are linked or used and providing source code for certain components or the entire software product.  These actions are not always easy or possible to perform.

General Public Licenses

A problem that can affect these companies when working under someone else’s time constraints is that it is not always possible to come into compliance with the open source obligations in an already shipping product.  The product may depend on certain libraries that require obligations that are contrary to the company’s business model.  For instance, it is very common to encounter components in use that are licensed under the GPL.  The GPL is a popular and well-regarded license, and is the license used by well-known projects such as the Linux Kernel.  This license requires any source code linked to it to be provided to the end user, if used in a distributed product.  This includes the company’s own source code they wish to keep closed source or proprietary.  Shipped and linking to source under the GPL, while wanting to keep some of that source code proprietary leads to a legal conflict.  In many cases, coming into compliance requires the removal or rewriting of these libraries and features that depend on them.

The recent Versata/Ameriprise court case in the United States, showed the implications of having an unexpected open source component that was not having its obligations fulfilled.  This caused confusion and legal issues for end users, as well as tying up the original software producer in court.  It is not unexpected that more companies will look to undisclosed open source dependences as a defense in unrelated business lawsuits.

Other recent court cases in the United States and Europe have made it clear that companies are responsible for compliance when their software product is distributed.  This can lead to legal surprises due to unmanaged dependencies their developers have selected, as well as open source components introduced by their suppliers as part of their software supply chain.  What this means is that a company is responsible for the compliance for the choices their developers make, as well as the developers that work for the companies providing them Software Development Kits, components, operating systems and other executables.

If it is not clear who will be providing the proper compliance tasks, it often falls to the last organization in the chain to provide the notices, source and other required obligations.  This is a difficult and expensive task and often requires information that only previous members of the supply chain are privy to.  More and more companies are writing open source compliance requirements into supplier agreements, in order to receive any pass-through obligations such as license text and source bundles as well to encourage the proper and timely management of third-party dependencies.  This contract language helps make the case to the supply chain that they should take open source compliance seriously.  Additionally, these agreements may explicitly discuss vulnerability reporting and procedures for handling alerts and upgrades.

Don’t be Vulnerable

Another side effect of not keeping track of third-party components, is that you are not able to respond to reported vulnerabilities or patches required to keep these components up-to-date and secure.  This has the side effect of making products vulnerable to outside attacks.  These attacks can lead to data loss or financial damages.  Legal teams are finding themselves more and more involved with security response, and the legal and financial repercussions of these attacks.  In response, legal teams are putting in place policies around component updating as part of their efforts to reduce risk to their company.

Companies that manage open source components will often put in place an Open Source Review Board (OSRB).  The members of this group come from various teams who can help manage the use of third party and open source software in the organization.  This group typically contains representatives from the Legal, Engineering, Security and Business teams at an organization.  They are responsible for setting policy, educating other employees and being a source of open source knowledge for the company.  The policy they set can be implemented by the various engineering teams, and any new situations can be escalated back to the OSRB when required.

By taking the lead, legal teams can reduce risk for their organizations, and at the same time allow their companies to be good open source citizens.  Even if there was not the power of copyright standing behind the open source licenses we use, the open source development ecosystem depends on the users of open source to respect the philosophy licenses they use and give back where possible as well.  As more companies start to understand their true dependency on open source, we should expect more financial and technical support back to these projects.  Better compliance allows us to deliver higher quality, more secure and better supported products as well as helping to support a stronger open source ecosystem.