Open source software

Digital health and open source software

It is currently estimated that up to 90% of all commercial software packages incorporate some form of open source software (OSS). According to a recent study by cloud provider Rackspace, 90% of the UK’s largest businesses use OSS.

Whilst OSS is nothing new - the concept has been around for as long as software has existed, and the term was coined in 1998 - businesses have only recently started accepting open source techniques. Some of the world’s biggest and fastest growing technology companies such as Facebook, Netflix, Google and Uber are built on OSS and the Digital Health sector is no exception.

Historically approached with caution by many businesses, these statistics demonstrate businesses’ increasing desire to use OSS to reduce costs and development time. However, despite the many benefits of OSS, it should be remembered that it is not entirely free to use without restriction - all OSS is made available subject to a licence and the terms of those licences can be particularly onerous. This section seeks to explain the key legal risks when using OSS, how to select the right OSS for your business and how best to manage those risks in order to reap the benefits of OSS .

OSS terminology

Copyleft licences

A copyleft licence grants the licensee a perpetual, non-exclusive, royalty-free and irrevocable (if stated conditions are met) right to deal with, redistribute, sub-license and on-license the OSS code. However, copyleft or viral licences contain two key restrictions if the licensee wants commercialise the licensed OSS code by incorporating it into proprietary code:

• (i) use of the OSS must be done on the same terms as the original OSS licence; and
• (ii) the whole of any modified code which incorporates the OSS code (ie your proprietary software combined with the OSS) must be made publically available.

Together, these requirements create a viral effect - if you combine OSS code licensed under a copyleft licence, with proprietary code, as part of your digital health product, you must release the entire code under OSS copyleft licence terms e.g. free for third party users. It is worth noting here that, if you are only using copyleft licensed OSS to operate the Digital Health business’s internal systems, the above requirements do not apply.

Examples of these copy-left licences are GPLv2, GPLv3, LGPL and MPL, among others.

Permissive licences

A permissive licence grants the licensee a perpetual, non-exclusive, royalty-free and irrevocable licence to the OSS code. However, once it is incorporated into proprietary code, the former OSS code operates under the business’ own proprietary licence and no longer qualifies as open source. The final product, blending open source together with IP-protected work, is known as a derivative.

Examples of OSS licences that are the least restrictive in terms of the inclusion of proprietary rights are MIT or Apache.

Legal considerations in OSS selection

All OSS code is made available under a non-negotiable licence and must be used in accordance with the terms of that licence, in the same way as any other third party licensed code must be.

There currently exists more than 2500 OSS licences, however, the Open Source Initiative formally recognises only 82 OSS licences. 95% of all OSS code is licensed using one of only ten OSS licences and of that 95% only 19% are licensed under the much discussed copyleft GPLv2 licence.

Some of these OSS licences will be incompatible with the commercialisation of a Digital Health product and some will be incompatible with other licences - both of which present legal risks.

Copyleft licences as an obstacle to commercialisation

Clearly, most businesses will not wish to disclose their proprietary code on an OSS basis as to do so will likely destroy the commercial advantage of their product or their competitor products. For example, if a health monitoring device uses 85% OSS code, the business will be relying on the remaining 15% of code to distinguish its device from those of its competitors.

It does not, therefore, want to have that 15% of proprietary code made available to the public free of charge as as result of its use of copyleft OSS code. The risk can significantly increase where code containing “copyleft” OSS code links with libraries of code owned by the business - you will then need to legally and technically establish whether those libraries of code become part of the OSS “contaminated” code and would also need to be disclosed.

Incompatible OSS licences

Further problems can arise when multiple OSS codes, operating under different licences, are used in the same source code: often the requirements of the different OSS licences will conflict. An open source audit by Black Duck found that over 85% of the commercial applications analysed contained components with licence conflicts, most often violations of the GPL. Often, in order to comply with the requirements of one OSS licence, you will automatically breach another OSS licence.

Impact on digital health businesses

A digital health business must consider the legal risks of failure to comply with the terms of an OSS licence, either by not making its proprietary code available to third parties when it is required to do so, or by using multiple OSS codes which are governed by different licence terms which are mutually incompatible.

As in all cases of copyright infringement, this entitles the owner of the copyright in the OSS code to take action against the company for damages and/or an injunction preventing the continued use of the OSS code.

It should be noted that the number of actions of this nature brought are relatively small, particularly considering the huge scale on which OSS is used, however, whilst significant damages have not been awarded to date - the majority of parties reach confidential settlement - such actions can be costly in terms of reputational damage and will require the development of a 'work around' to allow the business to cease using the relevant OSS code in its product. If shareholders plan to sell the business, a stake therein, or a product it owns in future, it can be a cause for concern for any buyer or investor that discovers a breach of OSS licences in the due diligence that will be carried out.

Copyright infringement is not the only way that breach of an OSS licence can give rise to costly litigation. CoKinetic Systems Corporation, a leader in the in-flight entertainment market, filed a complaint against Panasonic Avionics Corporation seeking damages in excess of $100m.

CoKinetic alleged an array of anticompetitive acts engineered by Panasonic to force CoKinetic from the market, including the allegation that Panasonic has wilfully violated open source licensing requirements by refusing to distribute the source code for its open-source Linux-based operating system, in violation of the GPLv2 licence. This is the first time that a company who is not a copyright holder (and therefore not claiming copyright infringement) is seeking damages for alleged anti-competitive behaviour which it claims, as a third party beneficiary of the GPL, is directly injuring its business.

As with many legal risks, the above should not deter Digital Health businesses from using OSS, but rather a focussed and considered approach should be taken to what OSS code is used, under what licences and in what way. The key is a comprehensive OSS policy, which is discussed further below.

Learning from others' mistakes

Case study 1:

The Oracle v Google case in the United States, which commenced in May 2012, was a prime example of the need to retain a strict OSS policy. Oracle claimed that Google had infringed its code to produce its Android operating system, under both patent and copyright law. It was held in the District Court that Google had infringed merely nine lines of copyrighted code, and nothing more. Following a successful appeal, a second trial found that Android did not infringe Oracle-owned copyrights as Google’s actions amounted to fair use. Oracle filed an appeal in October 2016.

The resources in terms of legal fees and management time spent over just nine short lines of open source code is phenomenal. This is perhaps a lesson to think twice before using open source content. If you want to keep your proprietary rights, then don't spice it up with open source material. When litigation ensues, that extra ingredient - even in the smallest doses - might make for a rather bitter aftertaste: a reminder, once again, that any use of OSS should be carefully monitored by a policy that is adapted to the specifics of how your organisation has chosen to exploit OSS.

Case Study 2:

Companies surveyed by Rackspace cited external security threats as one of the main challenges of OSS. One example of this threat is a bug known as Heartbleed which surfaced in 2012 but resulted in what was described as the "ultimate internet nightmare" in 2014. Heartbleed targeted OpenSSL, an open source project that was originally designed to prevent hackers from accessing personal data as it is transferred between users and banking, shopping or digital content websites. A fix was created, but not before user data was stolen from key data repositories such as tax agencies and health insurance companies.

Design your OSS policy

Follow the guidelines set out in the specific licence for the open source you are using, and understand what they entail to avoid inadvertently infringing copyright - with all of the harm to your business that infringement may entail.

Keep a record of who created the code and when it was written. Also keep a record of the employment or consultancy contracts that you have with all code developers, which should set out requirements to comply with the OSS policy.

Establish rules in the form of a written policy, and make that policy available to all employees, both developers and those in non-technical roles. This includes setting out clear guidelines for managing the implementation and use of OSS, by detailing what is and isn’t acceptable, and clearly explaining the implications of failing to adhere to those rules. You may wish to make it mandatory to read the policy and test key employees/consultants on the content of the policy.

Structure collaboration between the various teams of your organisation, to ensure that the use of OSS is monitored for compliance, an approval process should be put in place. The OSS policy guidelines should be incorporated into the software development and marketing process, in such a way that any risk of deviation is kept in check.

Conduct regular audits to verify consistent implementation of your OSS policy, and update the policy according to relevant legal developments. This may involve taking into account recent case law in various jurisdictions, as many aspects of the law pertaining to OSS still present grey areas, given that it is a relatively new field. If any cases of non-compliance with the company OSS policy are identified, take swift action to remedy the problem and seek legal advice where necessary, before the issue escalates.

Use 'inner-sourcing' where possible, so that the substantial portions of code are sourced from within your business, reducing the risk of infringing OSS or proprietary licences that originate elsewhere. This system has several additional advantages, such as improving time and cost effectiveness, optimising existing know-how that is already present within your team, and encouraging collaboration among employees.