There is an old adage in the legal profession: Ignorance of the law is no defence. So, General Counsel (GC) – be they from software/Internet of Things (IoT) corporations, or organisations that develop their own software – and law firms (that advise on IT, Intellectual Property (IP), IoT and/or security) need to beware. Most are not aware of the risk of unexpected open source components in software, and their corresponding compliance status.
As much as 50 percent of the code used in all software is comprised of open source software. While open source provides a high quality way for software developers to be more agile and efficient – there is also a hidden risk: the law.
While open source components are, by definition, free of cost and available for anyone to use – there are limitations. Open source components have licensing obligations that software developers in organisations 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 Key
While the law is established to enable enforcement of open source licenses, most software developers are unaware of them. Adding to the risk, most GCs are unaware of the open source components their developers are using. And they do not have automated means to scan their code for open source, and ensure compliance with licensing terms. GC and law firms alike need to educate themselves about open source software license compliance risk, then ensure their development teams/clients 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.
The 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 a very common request during mergers and acquisitions, during Original Equipment Manufacturer relationships and at the request of large enterprise companies. Organisations are very surprised to see 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 License
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 General Public License (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 organisation 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.
Vulnerabilities and Patches
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 organisation. This group typically contains representatives from the Legal, Engineering, Security and Business teams at an organisation. 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 organisations, 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.
About the author
Jeff Luszcz (pictured) is a VP of product management at Flexera Software. Previously, Jeff was founder and CTO of Palamida. He has helped software companies how to use open source while complying with license obligations and keeping on top of security issues.