Is The Use of Open Source Software Putting Your Business at Risk?

A brief overview

La propriété, c’est le vol! (roughly translated as “property is theft!”). Perhaps the most famous assertion of Pierre-Joseph Proudhon, the French philosopher, considered by some to be the father of anarchy.

A contemporary of Karl Marx, Proudhon’s focus was on physical property. However, this resonates with the early libertarian open source software philosophy, which encouraged the free distribution of software for the purposes of learning and evolving the field of computing.

Much has changed since a senior Microsoft executive once exclaimed that they could not imagine anything worse than open source software for the software and intellectual property business. What was once limited to a few discrete programmes shared between academics has now become a key resource for multi-national PLCs and start-ups, enabling businesses to react quickly and innovate using freely available flexible technology, as well as making significant cost savings for business and consumers.

With no small degree of irony, in 2019 Microsoft counted itself as the world’s biggest open source contributor, paying $7.5 billion to acquire the software development platform GitHub in 2018—GitHub being one of the original promoters of open source software.

Some notable examples of open source software include:

Open source software sounds great so why should I worry?

Using open source comes with some very significant catches. Two of the most notable being:


It would certainly not be fair to claim the issue of vulnerabilities is exclusive to open source software. Far from it. Even the most arrogant of coders is unlikely to be able or wish to claim their code was perfect with absolute confidence and a straight face. However, the National Vulnerability Database (NVD)—the U.S. government repository of standards based vulnerability management data—has identified more than 100,000 vulnerabilities in open source software with 5 new vulnerabilities being discovered every day. This also naturally begs the question regarding the number of known (and unknown) vulnerabilities skulking in the shadows that are not reported to the NVD.

According to a recent report undertaken by leading open source consultants WhiteSource, the number of reported vulnerabilities in open source projects rose by an eye-watering 50 per cent in 2019. This is further evidence of the proliferation of the use of open source software by commercial enterprise. The rise is not necessarily all bad news though. The optimists would say that the fact that the vulnerabilities have been reported indicates a raised awareness of the potential pitfalls of using openly available source code—effectively, people are now looking for them!

However, although all software contains vulnerabilities, the key difference with open source software is that the underlying source code is widely available. Therefore, vulnerabilities in such code are easier to determine and, for the nefarious parts of the community, exploit. Furthermore, once a vulnerability is reported, that vulnerability becomes public knowledge giving such ne’er-do-wells’ access to the backdoor keys left under the plant pot. It is therefore crucial that any known vulnerabilities in open source software are fixed quickly before that brand new 8k Ultra HD TV is stolen (well, that or a lot of very sensitive commercial information).

The pace of development and requirement to exploit new market opportunities means that many businesses will have been caught unaware, with few having developed detailed policies and procedures for tracking, identifying and remediating open source software issues. This is also far from an issue that only IT companies need to worry about as every company worth its salt uses computing software or technology, a portion of which may include open source software. There is a long list of recent and painful examples of hackers exploiting vulnerabilities in open source software used by companies in a range of sectors, including:

Other infamous examples:

Requirement to redistribute source code of modified versions

Open source software by its nature includes protectable intellectual property rights, most notably copyright. Therefore, if a person wishes to use any open source software, that person will be obliged to comply with the associated licence terms.

The Open Source Initiative (OSI), founded in 1998, is the self-titled steward of the open source definition and the community-recognised body for reviewing and approving open source licences. The OSI has approved over 90 licences, with open source software also being made available on countless other licences. One of the most unusual of the non-approved licences being the chicken dance licence (requiring the user to video themselves performing a chicken dance for every 20,000 units distributed).

Chicken dance licence aside, a detailed analysis of open source software licencing provisions would be extremely lengthy (including source code availability, attribution and notices, reciprocity of treatment and other terms) and therefore not appropriate for this note. Instead, a few key points below.

Open source software licences commonly fall into, or between, two camps:

Copyleft is the practice of offering people the right to freely distribute copies and modified versions of a work but with the stipulation that the same rights be preserved in derivative works down the line. Such licences typically require a user to make the source code of the entire programme available to such customers.

This is not necessarily limited to just the source code of the specific open source component but also potentially any work based on / incorporating that open source component. A company could therefore be required to also disclose certain of its own proprietary source code. Examples of copyleft licences include: GNU GPL 3.0 and GNU Affero GPL. The latter GNU Affero GLP was introduced to cover the use of open source software in software provided as a service; such use was not caught by the more traditional licences as they required a form of distribution for the copyleft licence terms to bite. Google is an example of a major company that has banned employees from using any open source software licenced on GNU Affero GPL due to the additional reach of these licence terms.

Permissive licences contain minimal requirements about how the software can be redistributed. Examples include: Apache (Google’s preferred choice), MIT and BSD.

Some licences sit in the middle such as LGPL and Mozilla and it should also be noted that there can be multiple licences that apply to one piece of software.

The various licences use different terminology and are by no means clear. However, in the most basic terms, if a business incorporates open source software into any programme that it makes available to customers, it must comply with the licence terms and, in certain cases, may be required to disclose a lot more than it had bargained for when using that software.

What should we be doing about all this?

Clearly, the use of open source software is only going to grow. There are evident commercial benefits in terms of cost savings, driving innovation as well as the broader societal advantages of sharing knowledge and materials amongst a wider community. Therefore, what should we be doing about the use of open source software (OSS)?

A few points to consider:

For IT companies early identification is crucial as the costs and time required to resolve issues escalates dramatically between the initial coding phase and after release. The cost to fix the same defect can vary from tens of pounds / dollars to tens of thousands of pounds / dollars depending on when an issue is addressed in the timeline!

For non IT Companies, in addition to the points identified above regarding vulnerabilities and distribution of source code, it is also important to note that OSS is typically provided on an “as is” basis, without any commitments regarding quality and performance or that the OSS does not infringe any third party rights. Any use is therefore very much at the user’s own risk.

© Copyright 2024 Squire Patton Boggs (US) LLP
National Law Review, Volumess X, Number 127