The GPL Enforcement Landscape: Lessons from Recent Lawsuits

The GNU General Public License (GPL) is an open-source software license that allows software to be shared, modified, and used in a non-proprietary way. Free and open-source software licenses have been successfully enforced around the world.

Lawsuits and other enforcement actions are an important part of protecting open-source software licenses and confirming their legitimacy. A number of different GPL violation lawsuits have been filed in both the United States and in Europe that highlight both the enforceability of the GPL and the consequences of breaching the licence terms.

This article will cover what the GPL is, how it is enforced, what the most common GPL violations are, as well as major GPL violation lawsuits in both the United States and in Europe. Finally, this article will briefly cover how to protect your business from GPL compliance issues.

Let's get started.

What is the GPL?

The GNU General Public License (GPL) is a widely-used and well-known open-source license. GNU is a mass collaboration project for making and distributing free software.

A similarly-named but rather different license is the Lesser General Public License (LGPL), which is less restrictive when it comes to combining the LGPL with non-LGPL and proprietary software.

The LGPL is often used for small tools or libraries, while the GPL is more-frequently used for whole software applications (where the whole piece of software should continue to be freely shared and adapted).

Open-source software licenses like the GPL were created and applied to software to make sure that software can be freely shared, modified, and distributed with no or few restrictions.

The GPL is what is called a "copyleft" open-source license. Copyleft is not the same as copyright, although they both protect intellectual property in certain ways.

You can see a good explanation of the difference between copyright and copyleft from the Free Software Foundation (FSF) below:

Open-source licenses also have different types. For example, copyleft is contrasted with "permissive" open-source licenses.

Permissive open-source licenses allow software to be shared without restrictions, whereas copyleft licenses require the software to be shared or modified further with the same license applied, as explained in the image below:

This means that if you license something under the GPL, derivative or combined works must also be licensed under the GPL. The GPL is one of the most well-known copyleft licenses.

For the LGPL, in contrast to the GPL, derivative works must be licensed under the LGPL, but combined works do not have to be. For example, if you used an LGPL-licensed tool or library in another, larger work, the larger work can have a proprietary license applied.

Copyleft and other open-source licenses like the GPL are enforceable. This means if you violate the license terms, you can be subject to penalties.

How is the GPL Enforced?

The GPL is enforced both through community-oriented GPL enforcement, as well as actions such as lawsuits.

On the community-based side, organisations such as the Free Software Foundation (FSF) and Software Freedom Conservancy (SFC) take on tasks like promoting education about open-source software licenses, suggesting voluntary compliance measures, and writing to violators and requesting compliance. Generally, community-based enforcement is cheap, quick, and can help to achieve compliance without having to go to court.

Most of these groups prefer education as a primary approach, although litigation is becoming more prominent. You can see a statement from SFC below that outlines the reasons why:

Litigation is very important for protecting the GPL's license terms. It helps to prove the legal legitimacy of open-source software licenses like the GPL, creates a deterrent effect (when businesses get fined for non-compliance), and can recover legal costs for community groups who carry out enforcement tasks.

Financial penalties can be quite important. This is because often, businesses that use the GPL do not have any financial incentive to check the GPL's terms until a lawsuit arrives. However, companies that are initially more compliant bear the costs of compliance upfront, which results in unfairness if no financial penalties are handed down as a consequence of breaches.

Now let's take a look at common violations, and major lawsuits.

What are the Most Common GPL Violations?

There are a number of common GPL violations, many of which have already been litigated.

According to a guide put together by the Free Software Foundation and the Software Freedom Law Center, among other contributors, 95% of the most common GPL violations include:

• The violator fails to provide required information about the presence of copylefted programs. This means that a piece of software that has a GPL-licensed component, simply does not contain a notice about the fact that GPL software is part of the program.
• The violator fails to reliably deliver complete, corresponding source code (CCS) for copylefted programs. This is a requirement of the GPL (to provide "complete, corresponding source code").
• Requests are ignored when enforcers communicate requesting fulfilment of businesses' obligations.

This guide also states that a small minority of violations relate to "derivative, combined, or modified versions of the work."

In most cases when a violation is discovered, enforcement processes begin with a cease and desist letter.

This means that violators are given the opportunity to include the GPL license text and provide relevant source code.

Violations can occur because not enough attention has been paid to licensing during the process of software creation, or there has been a misunderstanding about the GPL's requirements. These first enforcement steps give well-meaning businesses a simple chance to correct their practices and make amends.

In most cases when a violation occurs, "the vast majority of infringers accept to declare to cease and desist from GPL incompliant distribution of their products and to reimburse the costs of the enforcement."

In other cases, out-of-court processes do not succeed, and lawsuits result. Let's take a look at those.

Major GPL Violation Lawsuits

There have been a number of major GPL violation lawsuits over the last 20 years. Some of these were foundational cases that established the validity of the GPL as an enforceable software license. Other more recent cases go into the finer details of what counts as a violation.

This section will go through major lawsuits in both the United States and in Europe.

One of the most frequent countries that appears in the context of GPL lawsuits is Germany due to a particularly dedicated open-source software maintainer who brought a number of lawsuits against large businesses for breaches of the GPL.

In the section below you can see a table with key cases, their jurisdiction, and the main decision points. After the table some cases will be described in more detail.

Table of Key GPL Lawsuits

This table covers some of the main cases, so you can get a clear overview of what enforcement decisions have been made.

Let's take a look at some of those examples in more detail now.

United States

In the United States, several major GPL lawsuits have taken place.

BusyBox series of cases (2007-2012)

Between 2007 and 2012, BusyBox filed (or was involved in) a series of lawsuits against Best Buy and numerous other companies. BusyBox is a set of Unix utilities that are licensed under the GPL.

The first GPL lawsuit filed in the US was BusyBox v. Monsoon Multimedia in 2007, which quickly settled. Monsoon Multimedia had included BusyBox code in its products, but had not released the "complete, corresponding source code". Like many other GPL cases, Monsoon agreed to comply with the GPL's terms and paid a financial settlement.

In 2009, the Software Freedom Conservancy filed lawsuits against a large selection of companies, all of whom had also used the BusyBox code. These companies included Bestbuy, Samsung, Westinghouse, JVC, and many more.

The case noted that the creator of BusyBox had granted "certain permissions to other parties to copy, modify and redistribute BusyBox so long as those parties satisfy certain conditions." These conditions were the license terms of the GPL, as outlined in the case below:

The use of BusyBox was also contingent on "the condition that the Licensee gives recipients access to the source code corresponding to the version of BusyBox they are distributing in object code or executable form."

The court concluded that "On information and belief, each Defendant has distributed BusyBox within firmware – embedded in electronic products or by itself – in a manner that does not comply with the License."

As a result, the court issued an injunction against all of the companies in the lawsuit, stating that they must stop copying, modifying, and distributing the BusyBox software. Damages were also ordered.

These cases set a clear precedent that the GPL is enforceable in the US.

FSF v. Cisco (2009)

More recently, in 2009, the Free Software Foundation won a case against Cisco, which had used a number of GNU programs (including GNU C Library, GNU Coreutils, GNU Readline, GNU Parted, GNU Wget, GNU Compiler Collection, GNU Binutils, and GNU Debugger) in their Linksys router and networking software.

The FSF argued that Cisco had not provided "complete and corresponding source code" for the GNU programs. The lawsuit was eventually settled, with a number of conditions.

First, Cisco agreed to appoint a "Free Software Director" for Linksys, who would supervise the "compliance with the requirements of free software licenses such as the GPL."

In addition, Cisco agreed to:

• Notify recipients of Linksys products of their rights under relevant open source licenses
• Publish a licensing notice on the Linksys website
• Provide additional notices in a separate publication
• Make the complete and corresponding source code freely available on its website

This case was another important early case showing how even large companies need to stay compliant with the GPL's terms.

Software Freedom Conservancy (SFC) v. Vizio (Ongoing)

One of the more recent US cases is Software Freedom Conservancy (SFC) v. Vizio, which is still ongoing. Vizio makes televisions that use Linux, which (as per the GPL license terms) require manufacturers to share the source code.

This case is a particularly notable one, as "the SFC is not filing suit on behalf of a copyright holder of a particular open source project, but instead as the consumer of a product with open source components."

This case attempts to protect consumer rights in open source software. The SFC explains in its press kit why the case is important from a legal perspective, as you can see below:

One of the key points is that "in the past, all related lawsuits have been brought by copyright holders of the software". This case is taking a new and additional legal step to protect the rights of consumers of software licensed under the GPL, and to test whether consumers themselves have legal standing to sue.

If it's successful, consumers of open-source licensed products will be far more likely to be able to enforce open-source licenses themselves.

This case, while yet undecided, could significantly change the GPL enforcement landscape.

The SFC provides all case updates and relevant legal documents on its website.

Europe

Like in the US, there have been a number of GPL lawsuits filed in Europe, across several different countries.

Welte v. Sitecom (2004)

The first GPL lawsuit ever filed was Welte v. Sitecom, in Germany in 2004.

In this case, the court considered the validity and enforceability of the GPL. Harald Welte, a maintainer of the Netfilter/Iptables project, had developed a network software product that was licensed under the GPL. Sitecom used this product without following the terms of the GPL.

Namely, Sitecom did not:

• Provide notice that the software contained products licensed under the GPL
• Provide the license text of the GPL
• Provide the source code of the software

The court found that Welte had standing to sue, and also stated that it found the "GPL license condition to be standard terms of business". While it did not specifically rule as to the entire validity of the GPL, it did rule that Sitecom had agreed to the GPL's terms.

This case was particularly significant as it found that "under German law the GPL is considered more than extra-juridical philosophic document but – in principle – a binding and enforceable license."

While this was an early case, it set a precedent for other GPL cases. As highlighted above, after Welte, commentators noted that "it will hardly be possible to continue to allege that the GPL has no real meaning and that it cannot be enforced in court."

Welte has also brought a number of other cases against manufacturers who were using the Linux kernel without making reference to the GPL in their products.

These cases were all brought in Germany, and include Welte vs Fortinet UK Ltd. (2005), Welte vs Skype (2008), and Welte vs Fantec (2013), all of which found the GPL as valid and enforceable.

Welte v. D-Link (2006)

One particularly important case brought by Harald Welte is the case against D-Link. D-Link had used the Linux kernel in its firmware for devices, but had not provided a copy of the GPL license or made source code available.

Welte complained initially to D-Link, which agreed to cease and desist. It published the source code and informed customers of the GPL violation. However, D-Link did not pay any costs to Welte for enforcing the claim. Welte then sued D-Link for the costs, and was successful.

This is another important early case, because it continued to affirm the validity of open-source licenses like the GPL, when enforcement actions were still in early days. Specifically, it found the GPL to be valid under German law, which was an additional step forward from the Sitecom case.

Educaffix v. CNRS, Université Joseph Fourier et al (2007)

In this case, Educaffix had formed a software transfer contract with different higher education institutions. Educaffix wanted to develop its own software from the software it acquired.

Part of the software that Educaffix had acquired was called Baghera, which was licensed under the GPL. Educaffix decided it couldn't develop software from the GPL licensed version, and wanted their contract with the higher education institutions annulled. They said that it hadn't been disclosed to them that the software was under an open-source license.

The court held that Educaffix was not bound by the GPL or by the contract. Instead, the court terminated the contract between Educaffix and the higher education institutions.

This case was an important early case in French law that considered the GPL, but the court didn't ultimately rule on the enforceability of the GPL itself. At this stage, many courts were not aware of open source licenses or their enforceability.

AVM v. Cybits (2011)

In this case, AVM's routers were being modified by Cybits, through their Internet filtering software "Surf-Sitter DSL". AVM alleged that when Cybits modified the routers through this software, they were infringing AVM's copyright.

AVM argued that the software was embedded in a type of hardware (the router) that was not designed to be changed.

Ultimately, the court found that there was no infringement of AVM's copyright.

Instead, as you can see below, the court found that "the GPL parts contained in the firmware can be lawfully modified and reproduced. Thus it is acceptable that these parts are downloaded from AVM and edited during the installation of the Surf-Sitter software."

This case was important because it confirmed that components licensed under the GPL can be modified freely by future developers, even when the software is embedded in hardware such as a router.

Entr'ouvert v. Orange S.A. (2024)

A recent case in Europe, described as a "wake-up call for open source users" is the Entr'ouvert v. Orange S.A. case.

In this case, a French court awarded Entr'Ouvert over €900,000 in its suit against Orange S.A. for breaches of the GPL. This is an extremely large fine in comparison to suits like Sebastian Steck v. AVM, which awarded only a nominal financial penalty.

In this case, Orange had developed the "Mon Service Public" internet portal, using Entr'Ouvert's single sign-on library software "LASSO", which could either be provided under the GPL license, or an acquired commercial license.

Orange did not acquire a commercial license of the software from Entr'Ouvert, although they inquired about one.

Entr'Ouvert alleged that Orange did not:

• Provide notice of code modifications to the LASSO software
• Provide LASSO source code as required by the GPL.

As a result, Entr'Ouvert claimed that Orange had breached the GPL by making the LASSO software available as part of the Mon Service Public portal.

The court ultimately held that Orange "failed to include required notices and offers to provide source code in violation of Articles 2, 3, 4, and 10 of the GPL."

The reason why the fine was so large was in part because Orange had inquired about a commercial license, which would have cost around €500,000, as you can see below:

This case highlights that if there are dual licensing possibilities, businesses should make careful decisions about which option they choose. If an open-source license is ultimately selected, great care needs to be taken to comply with its terms, or high levels of penalties could result.

How to Protect Your Business From GPL Lawsuits?

There are a number of different ways in which you can protect your business from GPL lawsuits. These include steps taken up-front to ensure that you are aware within your business of what the GPL is, and making sure that you know what the GPL requires of you.

You also need to make use of compliance tools, and adopt auditing processes to make sure that your staff and contractors comply with policies that you set.

In the table below you can see some key points in which you need to consider GPL liability issues. Then we'll go through what you can do to protect your business.

Some of the key ways that you can protect your business from many of the issues mentioned in the table above include:

• Build an open-source compliance program: Set up a process for identifying and keeping track of open-source components that are in your software or hardware.
• Include relevant clauses in legal agreements: When you hire contractors or employees, particularly on software teams, include clauses that require disclosure if open-source code is used. You can also include clauses such as warranties or indemnities to protect your business if they use open-source software without disclosure.
• Use compliance tools: Open-source compliance analysis tools like FOSSA can detect open-source licenses in software. These tools can help keep track of these licenses and flag issues before you release software publicly and risk violations.
• Create internal policies: Set up internal policies that explain to staff and contractors how to deal with open-source software licenses. This is relevant for software teams as well as legal teams, as well as procurement or purchasing teams. Developers must also be required to disclose whenever they include open-source components in software they produce.
• Conduct regular audits and checks: Regular audits and checks help to keep track of whether policies are being complied with. Documentation and records should be kept with license terms, relevant programs, and steps taken to comply. For example, checklists can be used to ensure when an open-source component is incorporated, that staff can check whether a notice has been provided, and whether complete source code has been or is available to be released.

Clauses for GPL Protection

As mentioned above, there are some clauses you can include in legal agreements that can help to protect your business from enforcement actions. These include, for instance, clauses in:

• Contractor agreements
• Employment agreements
• Merger and acquisition contracts
• Service agreements

Let's take a look at a couple of examples now.

One of the most common clauses you can use is in contractor agreements. Here's an example from a contract between TransAct Technologies Incorporated and a developer:

You can see in this agreement that the "developer shall not include in any Software, and … shall not require the use of, any software component that is subject to any open source copyright license agreement."

In addition, the developer is required to "provide TransAct with a complete, machine-readable copy of the source code for any approved open source components" that are used (by agreement). These types of clauses can be used in both contractor and employment agreements.

Here's another example from an M&A agreement, which sets out in the intellectual property section a statement about the IP use and that the company has not used any open source software.

The section outlines that the company should be in compliance with any open source licenses, and that no open source software has been incorporated into, derived from, or distributed with a license that requires disclosure, additional licensing, or free distribution.

These types of clauses (along with taking other policy and practical measures) can help to protect you from liability.

By being aware of what the GPL requires, and setting up business processes to ensure all developers and other staff know about these license requirements, you can avoid lawsuits and other compliance problems.

Summary

The GPL is a copyleft open-source software license, which sets out a number of key terms. These terms are intended to protect the community-based and freely-available values that are a part of open-source code.

Importantly, it is a legally-enforceable license that has been protected and enforced in court in a number of cases in both Europe and the US. Recent cases such as Entr'ouvert v. Orange S.A. also highlights the high level of fines that can be handed down for breaches.

If you are using open-source code, whether libraries, tools, or software, you should immediately ensure you have:

• Open-source identification processes
• An open-source compliance policy
• A compliance tool
• Disclosure processes for developers
• Checklists to ensure compliance steps
• A regular audit schedule

Take open-source compliance processes seriously in your business, and make sure you set up steps such as internal policies and tools to help keep you compliant.