Free Open Source Software (FOSS) Risks

Last Updated on January 14, 2024

Free Open Source Software, or FOSS, has revolutionized the software industry and created an entirely new realm of software development. FOSS was the original brainchild of Richard Stallman in 1983 as part of the new Free Software Definition and defined by the GNU Manifesto in 1985 as a means of opposing software patents. But FOSS wasn’t popularized until Linus Torvalds released the Linux operating system in 1991. Linux was the first operating system to incorporate a FOSS license, where the source code was released to the public for review.
Free Open Source Software licenses have expanded since that initial release to a point where there are now over forty license varieties (including the Chicken Dance license). And while FOSS has proven to be advantageous in many areas, risks exist that software manufacturers must be aware of to protect their intellectual property. I’ll discuss these risks and offer recommendations below.

Open Source Licenses Explained

Let’s start by discussing software licensing in general. The five general license categories, in order from most to least restrictive, are:

1. Proprietary license is a license where the owner maintains full control of the source code and the general release is prohibited from modifying it. Windows and Apple iOS are two examples.
2. GNU Public License is the most restrictive of the FOSS category. GNU is a recursive acronym for Gnu’s Not Unix. It is a free software license where any derivative work or use of any part of the source code automatically inherits the license of the parent. In other words, any derivative work from the parent requires that the derivative must be free and is automatically applicable under this license.
3. Permissive Software, also called Limited GPL, or LGPL, has fewer restrictions, meaning the software may be included in proprietary work if attribution is given to the owner of the parent. FreeBSD (Berkeley Software Distribution) is one operating system that utilizes this license.
4. Public Domain is openly defined within the source code as freely available to the public with no requirement to identify the owner.
5. Finally, in the “Other” category is License Free Software where there is no explicit license definition for a given software. There is no guarantee that the software is Public Domain so it should be treated as software under a Proprietary License.

Within this general license framework are a wide range of unique licenses; too many to mention here. However, every license falls under one of the following categories except for Public Domain:

• Copyright, the most well-known, grants the owner full rights to the use of its own software.
• Copyleft is often considered the “anti-copyright,” meaning that applicable software may be modified and distributed provided that the rights from any derivative work be preserved as its parent. The Linux GPL license would be considered copyleft.
• Copycenter is often mistakenly thought of as a balance between copyright and copyleft but is actually a more permissive version of copyleft where derivative work is not required to inherit the license of its parent if attribution must be given to the original owner. Another common term for this category is Permissive Free Software. The purpose of this license is to “make as many copies as you want,” to quote Kirk McKusick who coined the phrase.
• Copyfree is similar in many ways to Copycenter but offers even fewer restrictions.

The Legal Risk of Using FOSS Code in Proprietary Software

Even with the various types of FOSS licenses, there is one common risk: the legal ramifications of incorporating all or part of FOSS code into a commercial or another FOSS product with the intent of promoting that copied code as part of the final product. For example, Apache is an open source web server and may be used commercially provided that proper attribution is given to Apache. Commercial software products may access Apache services directly and legally through its set of Application Programming Interfaces (APIs). However, Apache code may not be incorporated into a commercial product and sold as that commercial product.
Unless specifically permitted, developers are prohibited from copying any source or binary code into their commercial product. Developers are permitted to review any open source code to learn how it works, but they must create their own code from scratch.
The U.S. courts have generally sided with the various FOSS licenses. One example is Artifex v Hancom (2017) where the U.S. District Court ruled that the GPL license is an enforceable contract. Hancom developed office software and, in one case, incorporated the GhostScript library (which is covered under the GPL license) into their product without a commercial license, without proper attribution, and without applying the GPL license to its own code. Artifex, the owner of Ghostscript, sued Hancom and won.

“Nobody Will Catch Me Copying Open Source Software”

The common misconception around illegally copying FOSS software is that the act will never be discovered, but that belief is not always true. Here’s why:
First, software is likely to be unique from developer to developer. Like fingerprints, developers have their own methods of writing code to accomplish a specific task. The more complex and difficult the task, the more the final product will vary across developers. For example, if two developers were required to write code to complete an identical, complex task, their methods of solving the problem would be different even if both modules accomplished the same task. Even simple tasks usually yield different code, since developers often have carte blanche to choose their own variable names, handle branch conditions, etc.
Second, FOSS, like any other code, may contain security vulnerabilities—so copying any open source code may incorporate those vulnerabilities. Whereas when coding functionally similar code from scratch, the possibility of including exactly the same vulnerabilities is extremely remote.
Third, there are methods of including the official license for FOSS in the source and binaries. Those who illegally copy code are sometimes sloppy, so they may miss information that defines the type of license that is applicable to the copied code.
Fourth, good software engineers and forensic experts know how to reverse-engineer code because they understand the inner workings of computer hardware. Prohibiting users from reverse engineering will be hard to enforce since it is possible to debug the code from the operating system, a term known as kernel debugging.

Recommendations for Using FOSS Safely

The issue is not that the use of FOSS should be avoided, but rather that the requirements with the applicable licenses must be followed. These recommendations should reduce your liability with the use of external free open source software:

• Make sure to abide by the FOSS’ licensing requirements. This should include approval by your company’s General Counsel.
• Define the proper use of FOSS in company policies or assign a senior manager with the responsibility—and the authority—to define how FOSS is to be used (or not used.)
• If the company permits the use of certain FOSS licenses, make sure every developer understands the types of licenses that are permitted to be included. A steering committee should be created to authorize specific types of external code that is to be used in the final product. Senior management must approve the use of any external code before it is incorporated into development.
• Leverage training to make sure all developers know their responsibilities and the limitations with the use of FOSS to eliminate any ambiguity.
• If the product needs an external FOSS package to operate, require the end user to install that FOSS package separately and include links to all external code that is to be installed. Users should know the proper link from which to download legitimate FOSS because criminals will distribute false links for users to install what they believe is legitimate FOSS but, instead, contain malware. Make sure to include any limitations; e.g., incompatible FOSS versions. Aside from all legal protections, requiring the separate installation of required FOSS components will permit the user to install later versions when available so that they are better protected.

Commercial software providers should also include copyright notices in their product source and binary code to protect their intellectual property. Some software providers fail to do this, which leaves their code at risk for illegal copying. Consult your company’s General Counsel to ensure the proper use of copyright notices.
With some careful planning and risk analysis, your company’s risk associated with using Free Open Source Software may be easily manageable.
To discuss specific FOSS licensing and application security concerns with an expert, contact Pivot Point Security.