Getting your ship in order before you see the iceberg

In today’s fast-paced world, software is built, deployed, and consumed to optimize speed and flexibility – not for minimizing legal risk.  Often, legal risk is only thought about after the fact, when it should instead be taken into consideration before development begins. (Notably, the same can be said about cybersecurity.) 

With more and more companies investing in software development, the risk of developing or running software that isn’t properly licensed is quite big.  For the most part, it hasn’t been a problem to date.  This isn’t because companies have properly licensed what they are using.  Rather, it is simply that copyright owners have thus far decided not to enforce their copyright.  Industry is working on solutions and some cloud providers are helping their customers more than others.  At the end of the day, it is an individual company’s responsibility to make sure they in the clear.  There is no time like the present to start making things right.

Not a new problem…but getting worse

The lack of attention to licensing is not a new issue. In 2015, the vast majority of public repositories did not have proper use licenses, let alone an open source software (OSS) license.  This isn’t the fault of web hosting services like GitHub – they only do what their users request.  Instead, it reflects developers’ thinking (or lack thereof) on the issue.  The availability of code snippets, stack-overflow, or other code sharing websites has compounded the issue with little regard for the licensing issues – Think Napster circa 2000.

The need to accelerate the release of new software has favored the reuse of software from various sources, which are not always subject to the same quality controls as first-party developed products.  Companies frequently adopt onerous software development policies to ensure the software they actually develop in-house is original (in the copyright sense) in order to minimize risk for them and their customers.  At the same time, companies often fail to consider the software they are incorporating into their products from the outside.  Use of OSS in products has risen dramatically over the past couple of years – so much so that it now represents, on average, more than half of a product.  The policies for developing OSS vary widely from project to project. Some require expansive contributor licensing agreements (often signed by corporations), whereas others simply accept code under the project-stated open source license (under the paradigm that inbound equals outbound).  Until now, that model has proven to be adequate, as very little litigation has been generated around code ownership in open source.  So, one might wonder: Why should developers care about intellectual property (IP)?

The underlying assumption is authors of OSS will not sue users of their software, but this expectation may be changing.  We know of at least one copyright “troll” actively pursuing consumers of his software.  Patrick McHardy has purportedly made allegations against at least 50 companies for improperly using his contributions to Linux.  Tesla has also been the target of allegations of improper OSS use, forcing the company to make concessions in an effort to appease its accusers.  The Oracle v. Google case, soon to be considered by the Supreme Court, has substantially raised the stakes of correctly handling software copyright issues.

How do you solve this problem?

In order to address this problem, companies must first utilize software development processes that take these issues into account.  Companies will also need to put in place an open source program office to manage the supply chain of open source components and work with their suppliers to ensure they have adequate open source protection policies. Some cloud vendors, such as Microsoft, have decided to provide IP indemnification for the open source software they have incorporated in their services in order to cover risks linked to compliance. Still, many software vendors don’t offer that option.

The industry is also working to develop innovative mechanisms to improve the situation.  ClearlyDefined is an initiative aimed at crowdsourcing the analysis of licensing information in open source projects. Through this initiative, users of open source can share their analysis of the project in a central repository, or simply rely on the analysis of others. Eventually, such information will find its way to the main project.  OpenChain, a LinuxFoundation project, is aimed at providing a baseline set of policies for companies to manage open source. Companies certified by OpenChain policies could use that certification as a seal of quality, particularly in procurement contexts.