Issues when embracing FOSS

Free Open Source Software is computer software with its source code made available with a licence 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 computer programmers can manipulate to change how a piece of software – a “program” or “application” – works.

Definition of Free Open Source Software

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

There must be free redistribution. The licence 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 licence 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-publicized 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 licence must allow modifications and derived works, and must allow them to be distributed under the same terms as the licence of the original software.

The licence may restrict source-code from being distributed in modified form only if the licence allows the distribution of “patch files” with the source code for the purpose of modifying the program at build time. The licence must explicitly permit distribution of software built from modified source code. The licence may require derived works to carry a different name or version number from the original software.

The licence must not discriminate against any person or group of persons.

The licence 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 without the need for execution of an additional licence by those parties.

The licence 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 licence, 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 licence must not place restrictions on other software that is distributed along with the licensed software. For example, the licence must not insist that all other programs distributed on the same medium must be FOSS.

The licence must be technology-neutral. No provision of the licence may be predicated on any individual technology or style of interface.

Issues which any company embracing FOSS may face:

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

At a very top level, these issues or risks associated with FOSS 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.

Legal issues:

A variety of legal issues may arise when a company opts to embrace FOSS. This should not be a surprise given that allFOSS  is accompanied by an associated licence of one sort or another.

Some of the legal issues relate to contractual breaches by companies. One company faced a GPLv2 licence violation because of its non-disclosure of licence text and corresponding source code in an OEM contract. Another company faced a CDDL v1.0 licence violation because of its non-disclosure of licence 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 licence agreement. Another company realised that a detailed security evaluation was required just before the launch of its new service because of FOSS usage in the SaaS communication.

Legal issues relating to the FOSS community may also arise. For example Oracle binary code licence agreement does not allow combined work with GPLv2 licence.

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

Some FOSS authors allow patented subject matter to be incorporated into their project while others are very anti patented subject matter. For example, certain FOSS authors do not allow patented ciphers to be enabled in OpenSSL v 0.9.8j package.

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

Does the FOSS in use by the company have licensing compatibility, as there are conflicts and compatibility issues between some of the FOSS licences? If multiple licences apply, which licence takes priority?

FOSS can also pose some contractual compliance issues for companies. It is imperative for any company embracing FOSS to check if its sourcing or purchasing contracts require suppliers to disclose the presence of any GPL  or other FOSS licences 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 FOSS 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 FOSS  licences but and that is what a company needs to check in the licences that do apply.

Intellectual property issues:

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

Companies have indeed faced copyright infringement issues when embracing FOSS. A major IC company BSD (Berkeley Software Distribution) licence’s breached copyright in one of its product due to non-disclosure of licence information. A major Consumer Electronics company’s public licence breached copyright in one of its products because of non-disclosure of licence information.

Companies often run into copyright issues when embracing FOSS, often forgetting to do the basics. Companies 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 FOSS copyright notices of 3rd parties and given proper credit to these 3rd parties along with the licence information.

Companies embracing FOSS need to be aware that such licences are considered as copyright licences 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.

Patent issues sometimes arise when companies embrace FOSS. Embracing FOSS does not permit a company to just go ahead and infringe a patent belonging to a 3rd party. EmbracingFOSS  is not a ‘get out of jail free’ card when it comes to 3rd party patents. In one well publicised example, some companies embracing FOSS 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 FOSS code.

Care is also needed to avoid the viral effect of FOSS licences. Care is needed that FOSS  licence terms do not turn a company’s proprietary software coupled with FOSS all into FOSS. FOSS licences can require the contributors and the distributors to give a licence to their IP rights for use in the FOSS. All such licences include copyright licence. Some licences include explicit patent licence. A company needs to take care in case no explicit patent licence is included if there is an implied patent licence. The “viral effect” here means that the licence given by the distributor is not limited to the FOSS 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 FOSS type in question.

Security issues:

Software security is the idea of engineering software so that it continues to function correctly under malicious attack. Some FOSS 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 that 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, FOSS can also pose some operational type issues to companies. One company found that the FOSS 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 bypass its own FOSS checks.

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

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

FOSS licences do not require the user to click an “I Accept” button. This makes it all the more risky when downloading any FOSS, 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 FOSS entering into a company’s code silently very high indeed.

Business issues:

FOSS if not handled properly can have an adverse impact on the business.

One company discovered that due to a GPLv3 licence violation, one of its products about to launch 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 into the market.

Another company 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 FOSS with associated licences.

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 FOSS.

• The software product of the target company required a commercial licence from a 3rd party, so the target company was asked to disclose this supplier agreement.
• The software product of the target company contained a high risk FOSS 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 FOSS. The target company was asked to justify the same.
• Given the use of FOSS by the target company, the target company was asked to disclose its FOSS policy, and explain how they handled compliance.
• One agreement between the target company and one of its clients did make specific mention of FOSS, with the client requesting the target company about the disclosure of FOSS 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.

Final thought:

Adopting FOSS 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 FOSS 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 Ltd. His company helps clients to understand and appreciate IP, and works to ensure IP adds value to the business.

Interestingly, his company’s IP Risk Management Tool is being taken into use by some clients specifically to help manage their open source software issues.  

A special thanks to my colleagues for their contribution to this paper !!!