IP Clinic – 4. Open-source software



The potential pitfalls of embracing open-source software

by Donal O’Connell, Managing Director, Chawton Innovation Services

 

Open-source software:

Open-source software is computer software with its source code made freely available via a license in which the copyright holder provides the rights to study, change, and distribute the software to anyone and for any purpose.

“Source code” is the part of software that most computer users do not ever see. It is the code which computer programmers can manipulate to change how a piece of software – a “program” or “application” – works.

Definition of open-source software:

Open-source software does not just mean access to the source code. The distribution terms of open-source software must comply with the following criteria:

  • There must be free redistribution. The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources. The license shall not require a royalty or other fee.
  • The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well-publicised means of obtaining the source code for no more than a reasonable reproduction cost preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program.
  • The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.
  • The license may restrict source code from being distributed in modified form, only if the license allows the distribution of “patch files” with the source code for the purpose of modifying the program at build time. The license must explicitly permit distribution of software built from modified source code. The license may require derived works to carry a different name or version number from the original software.
  • The license must not discriminate against any person or group of persons.
  • The license must not restrict anyone from making use of the program in a specific field of endeavour. For example, it may not restrict the program from being used in a business, or from being used for genetic research.
  • The rights attached to the program must apply to all to whom the program is redistributed to, without the need for execution of an additional license by those parties.
  • The license must not be specific to a product. The rights attached to the program must not depend on the program’s being part of a particular software distribution. If the program is extracted from that distribution and used or distributed within the terms of the program’s license, all parties to whom the program is redistributed should have the same rights as those that are granted in conjunction with the original software distribution.
  • The license must not place restrictions on other software which is distributed along with the licensed software. For example, the license must not insist that all other programs distributed on the same medium must be open-source software.
  • The license must be technology-neutral. No provision of the license may be predicated on any individual technology or style of interface.

Although embracing open-source software can bring tremendous benefits, a company may also face a diverse range of issues

Issues which any company embracing open-source software may face:

Although embracing open-source software can bring tremendous benefits, a company may also face a diverse range of issues associated with open-source software which will all need to be properly and professionally managed. Like many things in life, there is both value and risk associated with open-source software.

At a very top level, these issues or risks associated with open-source software may be divided into the following categories:

  • Legal
  • Intellectual property
  • Security
  • Operational
  • Business

This short paper explores each of these categories providing some real life examples.

A variety of legal issues may arise when a company opts to embrace open-source software.

Legal issues:

A variety of legal issues may arise when a company opts to embrace open-source software. This should not be a surprise given that all open-source software is accompanied by an associated license of one sort or another.

Some of the legal issues relate to contractual breaches by companies. One company faced a GPLv2 license violation because of its non-disclosure of license text and corresponding source code in an OEM contract. Another company faced a CDDL v1.0 license violation because of its non-disclosure of license text and corresponding source code in an ODM contract

Legal issues relating to confidentiality and data privacy may also arise. One company failed to include a data privacy clause in its end-user license agreement. Another company realised that a detailed security evaluation was required just before the launch of its new service because of open-source software usage in the SaaS communication.

Legal issues relating to the open-source software community may also arise. For example, the Oracle binary code license agreement does not allow combined work with GPLv2 license.

Some open-source software engineers working on video-player technology have different and strong views within the community on which licenses should apply to the technology they have developed. Some sub-groups have forked or taken different paths in terms of how they want the project taken forward. Companies wishing to embrace this video-player technology from an open-source software perspective need to be aware of this schism.

Just complying with the terms and conditions of the associated open-source software licenses can be a challenge for some companies.

Some open-source software authors allow patented subject matter to be incorporated into their project while others are very against this. For example, certain open-source software authors do not allow patented ciphers to be enabled in the OpenSSL v 0.9.8j package.

Just complying with the terms and conditions of the associated open-source software licenses can be a challenge for some companies. Companies wishing to ensure license compliance should sanity check that they have indeed included the scripts to control compilation and installation of the software code.

Does the open-source software in use by the company have licensing compatibility, as there are conflicts and compatibility issues between some of the open-source software licenses? If multiple licenses apply, which license takes priority?

Open-source software can also pose some contractual compliance issues for companies. It is imperative for any company embracing open-source software to check if its sourcing or purchasing contracts require suppliers to disclose the presence of any GPL or other open-source software licenses in the products or services it is supplying.

The reverse also applies. Companies should continuously sanity check if its suppliers are providing any products or services that you need to comply with specific open-source software requirements.

The legal obligation to indemnify the authors (“reverse indemnity”) in the event of a company taking up additional warranty or liability may also exist, for example Clause 9 of Apache v2.0. This obligation may not be applicable to all open-source software licenses but that is what a company needs to check for in the licenses that do apply.

Intellectual property issues:

A number of intellectual property issues can arise when companies embrace open-source software, such as with copyright and patent-related matters.

Companies have indeed faced copyright infringement issues when embracing open-source software. A major IC company, BSD (Berkeley Software Distribution), breached copyright in one of its product due to non-disclosure of license information. A major consumer electronics company’s public license breached copyright in one of its products because of non-disclosure of license information.

Firms often run into copyright issues when embracing open-source software, often forgetting to do the basics. Often they fail to put their own copyright notice there when their organization is the author of the source code. However, more often companies fail to include free and open-source software copyright notices of third parties and give proper credit to these third parties, along with the license information.

Anyone embracing open-source software needs to be aware that such licenses are considered as copyright licenses and not a contractual arrangement only. The effect of this is that when courts consider a copyright infringement, in terms of any statutory damages to be paid, the damages are generally higher.

Care is also needed to avoid the viral effect of open-source software licenses.

Patent issues sometimes arise when companies embrace open-source software. Utilising open-source software does not permit a company to just go ahead and infringe a patent belonging to a third party. Embracing open-source software is not a ‘get out of jail free’ card when it comes to third party patents. In one well-publicised example, some companies embracing open-source software were found to infringe the patents of a major audio and video codec entity. In another example, patented ciphers were found to have been enabled in a piece of open-source code.

Care is also needed to avoid the viral effect of open-source software licenses. It is vital that open-source software license terms do not turn a company’s proprietary software coupled with open-source software all into open-source software. Open-source software licenses can require the contributors and the distributors to give a license to their IP rights for use in the open-source software. All such licenses include copyright license. Some licenses include an explicit patent license. A company needs to take care in the case where there’s no explicit patent license included, that there isn’t an implied patent license. The “viral effect” here means that the license given by the distributor is not limited to the open-source component used or modified. There is, therefore, a risk of neutralising a company’s control and value points. This issue depends very much on the open-source license type in question.

Security issues:

Software security is the idea of engineering software so that it continues to function correctly under malicious attack. Some open-source software code unfortunately poses security risks.

‘Heartbleed’ is a security bug disclosed in April 2014 in the OpenSSL cryptography library, which is a widely used implementation of the Transport Layer Security (TLS) protocol. Heartbleed may be exploited regardless of whether the party using a vulnerable OpenSSL instance for TLS is a server or a client.

In early 2015, a bug titled ‘Ghost’ was found. It is a ‘buffer overflow’ bug affecting the gethostbyname() and gethostbyname2() function calls in the glibc library. This vulnerability allows a remote attacker, who is able to make an application call to either of these functions, to execute arbitrary code with the permissions of the user running the application.

Operational issues:

Just like software design, development, test and release with proprietary software code, open-source software can also pose some operational type issues to companies. One company found that the open-source governance tool’s DB was outdated and the vendor in this case needed to update recent released packages in Git.

Another company found that its engineering team was manipulating a source code scanning tool in order to bypass its own open-source software checks.

If a company is contributing open-source code back into the open-source community then is that company hosting the source code on a server that it controls and operates, or is that server operated by a third party with whom there is an explicit arrangement in place?

Some firms concentrate so much on the module or program itself, that they neglect any associated software tools…

Software tools can sometimes pose some operational challenges. Some firms concentrate so much on the module or program itself, that they neglect any associated software tools which may also be governed by the same open-source software license.

Open-source software licenses do not require the user to click an “I Accept” button. This makes it all the more risky when downloading any open-source software, as the general impression is formed that the downloaded software is indeed free and that it can be used without any obligations. This makes the likelihood of open-source software silently entering into a company’s codebase very high indeed.

Business issues:

Open-source software, if not handled properly, can have an adverse impact on the business.

One company discovered that due to a GPLv3 license violation, one of its products which was about to be launched into the market would put its own IP at risk. Its engineering team was thus tasked to replicate the remediation steps provided to it by its open-source software compliance team, greatly delaying the launch of the product.

…its ‘due diligence’ exercise greatly increased in scope when it realised that the company it was acquiring had ten different software products in the market…

Another firm recently went through a major M&A deal and acquired another company. However its ‘due diligence’ exercise greatly increased in scope when it realised that the company it was acquiring had ten different software products in the market, all using a variety of open-source software with associated licenses.

Another company going through a complex M&A deal recently flagged up a number of issues during the due diligence process which all related to open-source software:

  • The software product of the target company required a commercial license from a third party, so the target company was asked to disclose this supplier agreement.
  • The software product of the target company contained a high-risk open-source software component, which required the target company to provide further clarification and to disclose detailed usage scenario information.
  • One of the components in the software product of the target company potentially contained patented subject matter. The target company was asked to disclose whether they were indeed using that patented subject matter in their implementation.
  • The software product of the target company contained a component which had the ‘heartbeat’ security issue. The target company needed to confirm that this issue had already been resolved.
  • The target company had a number of client agreements which lacked any mention of open-source software. The target company was asked to justify the same.
  • Given the use of open-source software by the target company, the target company was asked to disclose its open-source software policy, and explain how they handled compliance.
  • One agreement between the target company and one of its clients did make specific mention of open-source software, with the client requesting the target company about the disclosure of open-source software matters and the corresponding source code. The target company was asked to explain how it had responded to its client.

Within this section on business related issues, I should also include the impact on the reputation or goodwill of a company arising from any copyright and/or patent infringement.

Open-source software brings both value and risks, and these risks need to be understood, appreciated, and then mitigated.

Final thought:

Adopting open-source software brings clear benefits to a company. These benefits are high when there is a clear saving in software development costs, if and when suitable projects exist and the open-source software community can bring value.

However, open-source software brings both value and risks, and these risks need to be understood, appreciated, and then mitigated.

There are a number of tools available to help companies identify open-source software related issues. However, the usage of say a source code scanning tool alone does not satisfy compliance check requirements. No tool currently in the market will identify all of the examples highlighted in this paper. There must be specialized and skilled human intervention in order to ensure comprehensive compliance checks have been conducted in any organisations embracing open-source software.

I trust that this short paper shines some light on the legal, intellectual property, security, operational, and business-related risks which open-source software can pose to companies.

 


Donal O’Connell is the Managing Director of Chawton Innovation Services, a firm which offers consultancy in the areas of innovation and intellectual property management, and also licenses a number of IP software solutions to clients. Previously he enjoyed a 21-year career at Nokia, where he had such roles as VP of R&D and a Director of IP.

He’s an Adjunct Professor at Imperial College Business School in London, teaching about IP management. He is also the author of two books, “Inside the Patent Factory” and “Harvesting External Innovation”, along with hundreds of papers which have been published in magazines, websites, and blogs around the world.