The Fantec decision: German court holds distributor responsible for FOSS compliance

No readers like this yet.

Co-authors: Thomas Jansen and Hannes Meyle

The GPLv2 continues to be the most widely used FOSS license, but has been rarely interpreted by courts. Most of these decisions have come from Germany as a result of the enforcement actions of Harold Welte. The recent Fantec decision in Germany is the latest such decision and provides guidance on the requirements for companies to manage their use of FOSS and the lack of ability to rely on statements from their suppliers.

Fantec, a European company, distributed a media player with a Linux-based firmware inside. Like many companies, Fantec used software from third parties. The firmware of the media player included the iptables software which is licensed under the GPLv2. Fantec provided a version of the source code of the firmware for download that they had received from their Chinese manufacturer. Harald Welte is one of the authors of the iptables software and has brought suit a number of times to enforce the GPLv2 for this software. Welte had settled a prior violation by Fantec with respect to violation of the GPLv2. As a result Fantec signed a cease-and-desist-declaration in 2010 and Fantec was contractually obliged to refrain from further GPLv2 violations (and otherwise to pay a contractual penalty).

The software available for download for the Fantec product was reviewed during a "Hacking for Compliance Workshop" in Berlin organized in 2012 by Free Software Foundation Europe. The hackers discovered that the source code provided by Fantec did not include the source code for the iptables software and that the source code for some other components did not match the versions used to compile the binary code of the firmware.

In 2012, the plaintiff gave Fantec notice of another GPLv2 violation and admonished Fantec to cease the infringement and to pay the contractual penalty and the out-of-court costs for legal prosecution. Fantec objected that it had been assured by his Chinese supplier that the source code received from the supplier was complete. And Fantec claimed that they had investigated options with third parties for source code analysis and had been informed  that such reviews were quite expensive and not completely reliable. Welte raised two arguments. First, Fantec provided source code that was incomplete. And, second, that the source code was not the correct version.

On June 14, 2013, the district court of Hamburg found that Fantec violated the obligation in the GPLv2 to provide to its customers the "complete corresponding source code" of the software. The court affirmed a violation of the GPLv2 license conditions because the iptables code was not contained within the source code provided by Fantec. However, the court did not rule on the second argument that the source code was not up to date. Consequently, the decision does not provide significant guidance on the definition of the term "complete corresponding source code."

The court required Fantec to pay a contractual penalty in the amount of € 5,100 based on the prior settlement agreement. In addition, the court awarded the plaintiff’s expenses in enforcing the GPLv2. (This award is standard under German law and is based on Section 97a (1), 31, 69c no. 3 and 4 of the German Copyright Act which awards costs for a justified warning by a party which is so cautioned.) The court affirmed the culpability of Fantec’s violation by classifying the violation as negligent: the seller of firmware may not rely on suppliers'´statements about compliance. The distributor of GPLv2 software must carry out the assessment or commission experts to make the assessment even if they incurred additional costs.

The failure to comply with the GPLv2 may not be defended such failure due to additional costs. Unfortunately, the unusual nature of the facts means that the open source community did not get guidance on other important issues, such as how to measure damages and whether the failure to provide the latest version of the modules in the source code violates the requirement to provide "complete corresponding source code." The damages were based on the breach of a prior cease and desist declaration between Welte and Fantec in which Fantec agreed not to violate the GPLv2 rather than copyright damages. In addition, the court chose not to rule on Welte’s allegations about "old versions of the modules in the source code.

The decision is not surprising given existing German cases regarding the GPLv2. However, the case reinforces the need for each company to have its own FOSS compliance process. Companies cannot simply rely on the statements of third parties.  We recommend that each company ensure that they have the formal process for handling the use of FOSS by their own employees and third parties. This process should include:

  1. Policy for the use of FOSS ("FOSS Use Policy")
  2. Request and approval process for use of FOSS by employees
  3. Approval and audit process for the use of FOSS from third parties, both through third-party products and acquisitions by the company
  4. Auditing process for compliance with the FOSS Use Policy

Given the rapidity of product development and the extensive use of third-party software in most products, a FOSS Use Policy must focus on managing relationships with third-party suppliers. A company must ensure that they have a clear set of standards for third-party providers for FOSS compliance. These standards should include an understanding of the FOSS management processes of such third-party suppliers. The development of a network of trusted third-party suppliers is critical part of any FOSS compliance strategy. The Free Software Foundation Europe has useful recommendations on complying with GPLv2 obligations.

Many companies will decide that they need to automate the process by using the software to scan third-party code and manage the process. And companies may also wish to use the Software Packet Data Exchange framework to help communicate the FOSS in a particular product.

In sum, Fantec is a reminder that companies should adopt a formal FOSS use policy which should be integrated into the software development process. Companies should also be prepared to respond promptly to any assertions of violation of FOSS licenses and swiftly correct the problem.   


User profile image.
Mark Radcliffe is a senior partner who practices corporate securities and intellectual property at DLA Piper. DLA Piper is a global law firm with over 4000 lawyers in more than 40 countries and 65 cities. He earned a B.S. in Chemistry magna cum laude from the University of Michigan and a J.D. from Harvard Law School. Mr.


I think if I were a distributor I would quit carrying FOSS. This sounds expensive.

This is only expensive if you have to do this after the facts. But FOSS softwares have been developed with lots of tools to ensure that they are available at the same time in source form each time you can download the software in compiled form.
In fact the FOSS softwares are FIRST available in source form, and archived in each version submitted to a build farm that will generate the binaries on the same site.
There's no excuse : all providers just have to prove both at the same time (but ideally the providers should better provide JUST the sources; if they want to distribute the binaries as well, as a convenience for the reuser, they should use a FOSS project hosting platform. Most of them do not cost anything to use : publish the source on the repository (most often CVS, SVN or Git), instruct the build farm to produce the binary. The hosting platform will generate the binary along with the correct link to the exact branch in the source repository.

If the IPtable software was modified to adapt it to some device, by adding some additional adapter with it (through some API requiring a few header files) it is very simple to assert on these hosting platforms that the source is complete to allow correct compilation with the necessary supplementary files, the original IPtable package in some version and a list of diff patches in the sources,
If the compilation requires a specific builder tool (such as a specific assembler plugin for GCC, or some custom parser generator to compile some sets of users rules into source code to compile, and if these rules use a specific language, or XML schema or DTD, or an SQL database, or the connection to a remote database to get updated data to include in the generated code, then the connection data must be provided as well (URLs and authentication if needed, and how to create a free account if needed to load these updated data to integrate in the generated source code), then this must be provided.

It is very simple to make sure that the source code is complete: using a third-party FOSS hosting site is the best warranty that the full source code will be available, before using the binary code. A provider that blindly uses the binary code provided without building it itself or on a third-party FOSS hosting site is clearly negligent and liable.

Third-party hosting sites are standard everywhere in all FOSS projects, and this was already used for the original IPtable package used by the chinese provider.

Today, it is extremely easy to create a derived branch from any FOSS software, notably with Git. Every one can create a branch at any point for any kind of modifications and instantly republish it for others. The modifications in branches may or may not be integrated in the original branch by the author of the original package. Everyone is free to do any modifications and adaptations.

FANTAC and its Chinese providers are simply incompetent, they don't want to work like what every other FOSS developers work with common tools like Git repositories, and online build farms.

Quick FYI: Harald's name is spelled wrong in the first paragraph.

I met Harald many years ago and have always deeply respected his work, both technically and in his commitment to upholding the GPL. I used to periodically check his website, but I'm not sure he's been able to keep it uptodate. It is a great source of information for cases like this.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 3.0 Unported License.