News

Is Your Software IP Really Your IP?

  1. What is in Your Software?
  2. Licence Compliance: Why You Should Keep a Close Eye on Your IP
  3. Managing Licence Compliance
  4. Resources & Best Practices

What is in Your Software?

In the age of modern software development, developers share and contribute the source code of libraries, components and frameworks on code sharing websites such as GitHub and npm. These components are typically shared under an open source software licence.

This enables other developers to re-use these components on other projects and, means they do not need to repetitively code common functionality from scratch. This is a huge benefit as it reduces the time to deliver a solution to market and at a lower cost.

The reality is that the majority of modern software solutions are made up of third-party code. Forrester’s recently reported that modern applications such as mobile, cloud and IoT connected devices may comprise of up to 90% of open source code.

In our experience, when performing audits for investors and software companies, the extent of open source components and their varying licence types discovered in applications is often very surprising to our clients (example see Figure 1).

Figure 1: The Licence Mix Found in a proprietary E-Commerce Cloud Solution audited by Source Code Control – 93% Third-Party Open Source Software

The general understanding is that open source code is freely available for anyone to use, modify, and distribute. However, there are obligations to meet. The capacity of a third party to use and exercise rights over the software depends on the terms of the open source licence granted by the copyright owner (to be explored in more detail in the third article of this series).

You can think of open source licences falling on a spectrum (see Figure 2). The permissive licences present a low level of commercial risk because they do not obligate you to share code and, non-compliance is easily rectified.

Figure 2: Open Source Software Licence Spectrum

The restrictive ‘copyleft’ licences present a higher level of commercial risk because of their obligations to share source code and to license modified or derivative works under the same copyleft licence (also known as reciprocating the licence).

The obligation to share source code may be undesirable for organisations that hold value in their IP as this act could significantly diminish or even eliminate the products commercial viability.

Additionally, the obligation to reciprocate the licence often creates licence conflicts where organisations license their modified works under another licence such as a proprietary End User Licence Agreement or another open source licence.

Developers use open source because of its benefits. However, are often unaware of the licence obligations attached to open source components. Which, unknowingly to them, exposes their organisation and its IP to risks, which may be costly and time consuming to resolve.

The resulting licence violations may expose an organisation to the risk of copyright infringement, litigation, forced source code disclosure, adverse publicity, vilification by the community and in an investment or merger and acquisition (“M&A”) scenario, the devaluation of the organisation.

Licence Compliance: Why You Should Keep a Close Eye on Your IP

At Source Code Control we are often asked why should I worry about open source licence compliance? Are copyright holders enforcing their rights?

In recent years open source software contributions have been made by organisations such as Microsoft and Google, in fact Microsoft is the largest open source contributor on GitHub. As a result enforcement in this space is increasingly driven by companies rather than individual right holders.

This enforcement is concerning for open source users, since it isn’t just about ‘doing the right thing’ but rather motivated by commercial drivers, such as lost revenue or competitive advantage.

The most prevalent and high-profile enforcement is pursuant of compliance with the GNU General Public Licence (“GPL”), a copyleft licence (see Figure 3).

Figure 3: GPL v3 permissions and conditions, Source – GitHub

For example in March of 2017, Cokinetic Systems filed alleging Panasonic Avionics had monopolised the Media Services Market by violating the GPL licence in its Panasonic IFE Software. Cokinetic Systems sought compensatory damages, believing those to be in excess of $100 million. Less than a year later Panasonic Avionics chose to settle the case for an undisclosed figure.

In an effort to monetise open source the dual licencing model emerged. This model offers free use of the software under a copyleft licence like the GPL or a commercial licence can be purchased to take away the obligation to share source code (see Figure 4). Companies such as Artifex are increasingly using copyleft licences under this model as a tactic to drive revenue.

A paper produced by Above The Law explains,

 “Too often, companies will assume that software or code is free to use because a particular company has a reputation for open source development, when that is not in fact the case”

This is a significant issue that is compounded by the fact that companies who own the software are in it to make money. Kate Downing, a California based Lawyer, says,

“They have every incentive to pursue violators and get paid for licenses because that’s how they make their money”.

Figure 4: Artifex’s Dual Licence for Ghostscript

Where rightsholders do not have the resources support can be sought from organisations such as the Software Freedom Conservancy (“SFC”) and the Software Freedom Law Centre (“SFLC”). The SFC is a not-for-profit organisation that helps protect and defend open source software projects from licence violations (see the Tesla example below). Both the SFC and SFLC actively work to defend right holders by seeking out copyleft licence violations.

Evidently, any legal threat is bad publicity for an organisation and can affect its image, incoming investment, future revenues and are ultimately very costly and time-consuming to resolve. Therefore, right holders and users are now using commercial and reputational damage to enforce compliance.

Many members of the open source community are deeply invested in respecting the public software commons and driving collaborative innovation. Therefore, organisations may be subject to vilification for their infringing acts by the open source community, if not by the right holders themselves to force licence compliance.

In January 2016, Jide Technology announced the launch of its crowd-funded project: Remix Operating System for PC. Initially, Jide refused to share the source code for Remix OS on the grounds it is ‘not an open source organisation’. However, users created a lot of noise online after discovering the software contained a GPL component. Reporters picked up on the licence violation which forced Jide to release the source code four days later.

Jide is a relatively small development company that heavily relied on investment. Their lack of software management left them with no other choice but to share their source code for a major new product. Less than two years later Jide discontinued Remix OS ‘to focus on a more profitable enterprise market’.

Another example is Tesla who use GPL licenced components in their autopilot systems. Tesla initially refused to share their source code and as a result, received a lot of heat in the media from the open source community. The SFC provided support to increase pressure on Tesla to comply with the GPL. Consequently, in 2018 Tesla was forced to make the source code for their autopilot system publicly available.

In an M&A or investment scenario, the presence of unmanaged open source components in the target’s software presents a risk therefore may devalue the company. In our experience we have seen that if software contains a large quantity of open source software that is not consistently tracked, acquires have delayed decisions and in some cases changed the terms and conditions of the deal (this will be discussed in more detail in the second article of this series).

Managing Licence Compliance

There are many industry reports providing insight into risks posed by unmanaged open source in software development. One report stated that there is an average of 528 open source components per modern software application.

Mark Radcliffe, a Partner at DLA Piper (Silicon Valley), says,

“virtually all software now has a large number of open source components.”

Because of the increase in commercialisation of open source and the mainstream software vendors becoming open sourced, management of open source has matured. This resulted in the publication of an ISO standard (OpenChain ISO/IEC 5230:2020) to improve licence compliance in the software supply chain.

Microsoft is committed to open source compliance therefore put in the resources to convert the OpenChain specification into an ISO standard. Their motivation was driven by their customers who increasingly requested a demonstration of open source licence compliance.

With the level of use of open source in software development, companies and their legal counsel are increasingly legally challenged. It is imperative that lawyers understand the implications of the use, either knowingly or unknowingly, of open source software on technology companies. Many legal firms are involved with the continual authoring of the OpenChain standard (see Figure 5).

Figure 5: Law Firms Partnered with OpenChain, Source – OpenChain Partners

Open source licencing is not a static field. These changes are driven by changes in technology such as Cloud. Therefore, the legal challenges are likely to become more frequent and possibly more complex.

If this article raises questions or concerns Source Code Control can provide you with support and guidance. Visit our website here or contact us at open@sourcecodecontrol.co

Resources & Best Practices

Author

Holly Wyld

Governance Specialist at Source Code Control Ltd

Share This