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 http://www.ifross.org/publikation/lg-hamburg-az-308-o-1013.
The decision is one of the first to deal with this obligation to provide source code but the facts limit its value. For example, the damages are based on the breach of a prior cease and desist declaration between Welte and Fantec in which Fantec agreed not to violate the GPLv2. However, it does provide important guidance on how to manage FOSS compliance and the limits of delegation of these obligations.
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. Ironically, Welte had settled a prior violation by Fantec with respect to this firmware. 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 versions. 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.
The decision is not surprising given existing German cases regarding the GPLv2. However, the case re-emphasizes the need for each company to have its own FOSS compliance process. Companies cannot simply rely on the statements of third parties. Each company should 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 http://fsfe.org/activities/ftf/useful-tips-for-vendors.en.html.
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 http://spdx.org/.
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.
I would like to thank my colleagues in Germany, Thomas Jansen and Hannes Meyle for assisting me on this post.
Recently Laurie Wurster of Gartner wrote an article in the Harvard Business Review which confirms that the free and open source software (“FOSS”) has reached a “tipping point” in adoption by companies which confirms a trend she noted in her 2008 report (Accenture and IDG have reached similar conclusions). http://blogs.hbr.org/cs/2011/03/open_source_software_hits_a_st.html
Yet she notes that this increase in adoption has not been matched by implementing processes to manage such use. She raised the same issue in her 2008 report. http://lawandlifesiliconvalley.com/blog/?p=107. In the Harvard Business Review in March 2011, she states:
Even as our survey painted a rosy picture of the future of enterprise use of open source software, it also surfaced a concern. Most organizations, it revealed, have not established a policy framework to guide decision-making on the use of open source software. A proper framework would outline types of licenses acceptable to the organization, guidelines pertaining to intellectual property, regulations governing contributions to external projects, and an approved vendor/project list. Just a third of respondents claimed their organizations have anything like this kind of policy structure; the rest rely on ad hoc or informal processes
In fact, this problem is sufficiently important that we are having a specific breakout session on FOSS management at the Open Source Think Tank this week. http://lawandlifesiliconvalley.com/blog/?p=600.
Open source has now become ubiquitous, yet management of its use remains uneven. The recent Forrester Research report at LinuxCon notes that 2010 was the year of using open source to improve business process execution speed and company growth. The adoption of open source has decreased in importance because open source is now so widely adopted.
Recently, Dell had problems with compliance with its Stark tablet http://laforge.gnumonks.org/weblog/2010/09/13/. This case illustrates critical lessons in open source management: (1) diligence is essential and (2) open source has many free lance enforcers who are checking compliance. Dell used the Android operating system in the tablet. Dell failed to comply with the terms of the GPLv2 to make available the source code with the object code even though everyone “knows” that the Android operating system is licensed under the Apache license. As Black Duck noted in a recent report on Android software, the Android operating system is based on the Linux operating system and has 185 sub components which use nineteen different open source licenses. The compliance failure was first noted by Harald Welte of gpl-violations. Harald is one of the “free lance” enforcers of the GPL.
The industry is responding to these challenges through a number of initiatives.
1. The Linux Foundation working with the Fossology project has developed: the Software Package Data Exchange™ (SPDX™) specification is a standard format for communicating the components, licenses and copyrights associated with a software package www.spdx.org.
2. The Linux Foundation has developed tools to assist in determining and managing open source http://www.linuxfoundation.org/programs/legal/compliance/tools.
3. HP has made its open source scanning tools available through Fossology http://www.fossology.org/.
4. GPL violations has made its binary scanning tools available http://www.binaryanalysis.org/en/content/show/download.
5. Project Harmony is an informal group of lawyers and industry members who are discussing the role of contribution agreements in open source projects. The discussion ranges from the appropriateness of contributor agreements to the use of assignment or licenses in contribution agreements.
Linux Foundation is also preparing a checklist for compliance which will be available in the fourth quarter of 2010. These efforts should make compliance simpler over time, but it is important for companies to participate in these efforts to make them more effective.