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.
The use of the Android operating system continues to grow. Gartner recently reported that Android had become the leading operating smartphone operating system in the world in the first quarter of 2011. http://www.computerworld.com/s/article/9216848/Gartner_Android_and_Apple_win_big_globally_in_Q1. Android grew from 9.6% to 36% of the market in the last year. Its lead over smartphones running Symbian is now almost 10 million units per quarter. During the first quarter of 2011, manufacturers distributed 36.3 million smartphones running Android while only 27.6 million smartphones running Symbian were distributed.
Yet Android continues to be a very complicated product from a licensing point of view http://lawandlifesiliconvalley.com/blog/?p=635. Peter Vescuso of Black Duck and I worked to provide a summary of the issues in managing licenses in software development based on the Android operating system http://www.law.com/jsp/lawtechnologynews/PubArticleLTN.jsp?id=1202495469387 . I have included a more detailed legal perspective http://www.law.com/jsp/lawtechnologynews/PubArticleLTN.jsp?id=1202495473435.
Recently, Edward Naughton, a lawyer with Brown Rudnick, raised concerns about Google’s potential violation of the license for the Linux kernel (the General Public License Version 2, “GPLv2”) in developing the Android operating system:
“I have serious doubts that Google’s approach to the Bionic Library works under U.S. copyright law. At a minimum, Google has taken a significant gamble. While that may be fine for Google, because it knows about and understands the risks, many Android developers and device manufacturers are taking that same risk unknowingly. If Google is wrong, the repercussions are significant for the Android ecosystem: the manufacturers and developers working with Android would be incorporating GPLv2-licensed code into applications and components and taking on the copyleft obligations of that license”
However, his statements are based on a fundamentally flawed analysis of the application of the GPLv2 to Linux: he ignores the modification to GPLv2 found in the “Note” (see below) which fundamentally limits the scope of “derived works” under the GPLv2 as it applies to Linux (as a matter of transparency, neither I nor my law firm, DLA Piper, represents Google and this opinion is my own and may not reflect the views of DLA Piper or its clients). The Note is found at the top of the GPLv2 on the license page of the website of the Linux kernel:
NOTE! This copyright does *not* cover user programs that use kernel services by normal system calls - this is merely considered normal use of the kernel, and does *not* fall under the heading of “derived work”. Also note that the GPL below is copyrighted by the Free Software Foundation, but the instance of code that it refers to (the linux kernel) is copyrighted by me and others who actually wrote it. http://www.kernel.org/pub/linux/kernel/COPYING
This flawed analysis is coupled with a basic misunderstanding of the intentions of Linus Torvalds and contributors to Linux: Naughton suggests that Linus and other contributors are interested in having GPLv2 apply to “user space” and that the common program used with Linux kernel files, glibc, enjoys a special informal blessing which permits its use without extending the effect of the GPLv2 to programs in “user space”. In fact, the reverse is true. Linus and the contributors to Linux want to avoid the application of GPLv2 to programs in “user space” as a fundamental basis of the development of Linux. This intention has been clear since the initial development of Linux as evidenced by Linus Torvald’s adoption of the “clarification” to the GPLv2 in the form of the Note.
Naughton argues that the GPLv2 requires that any program which reproduces and distributes Google’s “cleaned” Linux header files is subject to GPLv2. It is undisputable that the unmodified GPLv2 requires that programs that are “based on” the GPLv2 licensed software must be distributed under the GPLv2. However, Naughton ignores the critical difference about the scope of the GPLv2 as modified by the Note. The effect of the Note on this issue is substantial.
Naughton mentions this “Note” but only in passing when discussing glibc:
The preferred option in the industry is to build the application against a different set of kernel header files that accompany the GNU C library (“glibc”). The headers in glibc are different from the “raw” header files, because they’ve been created, with the apparent blessing of the Linux kernel maintainers, from a subset of the raw files by means of a standard process. Within the industry, these header files are referred to as “sanitized” header files. Linus Torvalds and the kernel maintainers have publicly declared that applications can use these sanitized header files without becoming subject to GPLv2 because these sanitized header files are “normal system calls” http://lkml.org/lkml/2003/12/4/239.
However, the creation of the “sanitized” header files are not subject to an informal “blessing” with kernel maintainers (in fact, they don’t have the authority to provide such a blessing which can only be done by the copyright owners of the contributions to Linux): the Note, which is part of the legal framework adopted by Linus and agreed to by all contributors, limits the scope of works “based on” under the GPLv2 for the kernel. In fact, Naughton’s description of the Bionic’s Library modification of the Linux header files is very similar to the manner in which he describes the operation of glibc. Thus, it is difficult to understand the difference between the analysis of the scope of the modified GPLv2 with glibc and with the Bionic program. The key issue is whether the interaction of the Bionic Library with the kernel uses “normal system calls” and, thus, it is not a “derived work”. It appears that the Bionic program uses normal system calls. These facts explain why none of the Linux committers (a notably outspoken group) has chosen to challenge the use of the Bionic program.
Naughton makes much of the expressed desire of certain Google programmers to ensure that Android “keep GPL out of user space”. Yet this goal is fundamental to the Linux community. Linus Torvalds stated: “User programs are _clearly_ not derived works of the kernel, and as such whatever the kernel license is just doesn’t matter.” http://lkml.org/lkml/2003/12/3/228. In fact, Linus Torvalds recently stated about Naughton’s article that “It seems totally bogus,” Torvalds told IT World’s Brian Proffitt. “We’ve always made it very clear that the kernel system call interfaces do not in any way result in a derived work as per the GPL.” http://www.networkworld.com/community/node/72428.
Nonetheless, his concluding paragraph focuses on the risks arising under copyright law, a focus which is misplaced: the critical issue, is whether the scope of the modified GPLv2 applied to Linux rather than US copyright law. In fact, his risk of application of the copyleft provisions of the GPLv2 only arises if (i) the Linux header files (as “cleaned” by the Google development scripts) are copyrightable and (ii) the Bionic software reproducing and distributing are “based on” the Linux kernel and, thus, are not exempted by the limitations on “derived works” in the Note. The “copyright” part of his analysis also has flaws although the result is considerably less clear for this analysis than the analysis of the interpretation of the modified GPLv2 (and we may not have all of the relevant facts). For example, one factual error in his discussion is his reference to the Linux header files as part of an “Application Programming Interface”: these files are part of an Application Binary Interface”. It is not clear whether this programming difference has legal consequences, but it is critical for this type of analysis to ensure that the underlying facts are correct.
Even the copyright argument has problems: the copyrightability of the Linux header files is subject to serious doubt. Copyright law protects “works of authorship fixed in a tangible medium of expression.” However, software programs are functional (unlike books and movies) and the scope of protection is limited. The most widely used legal test for determining copyright infringement in software programs expressly limits the scope of protection for certain parts of software program (the “filtration” step):
Professor Nimmer points out that “in many instances it is virtually impossible to write a program to perform particular functions in a specific computing environment without employing standard techniques.” 3 Nimmer § 13.03[F], at 13-65. This is a result of the fact that a programmer’s freedom of design choice is often circumscribed by extrinsic considerations such as (1) the mechanical specifications of the computer on which a particular program 710*710 is intended to run; (2) compatibility requirements of other programs with which a program is designed to operate in conjunction; (3) computer manufacturers’ design standards; (4) demands of the industry being serviced; and (5) widely accepted programming practices within the computer industry. Id. at 13-66-71. http://scholar.google.com/scholar_case?case=6976925648486076739.
Steven J. Vaughan-Nichols noted recently that he interviewed Eric Raymond, then president of the Open Source Initiative, during the SCO litigation and “Eric told him that there was a “reason why Unix and Linux’s header files looked the same: “Do you know that there is not one bit of executable code in those files? They’re pretty much all macros and declarations forced by POSIX and other technical standards.” http://www.zdnet.com/blog/open-source/does-googles-android-violate-linuxs-copyright/8497. Linus Torvald in a statement on March 22, 2011 made the point even more strongly, calling Naughton’s claims “bogus”. These statements are helpful in analyzing the copyrightability of the Linux header files, but only a court can provide a final answer. However, it is interesting that all of the cases cited by Naughton relating to “interfaces” found that the interfaces are not copyrightable.
This dispute reflects the challenges of the analysis of open source legal issues: the law in this area is uncertain and the analysis is very fact dependent. However, the statement that the law is uncertain regarding software is not unusual: this uncertainty has existed from the date that Congress debated whether to apply copyright to software under the Copyright Act of 1976 (they set up a special group to review the issue among others after the adoption of the 1976 Act, the National Commission on New Technological Uses of Copyright Works) Although the violation of the GPLv2 does not appear to be a problem for Android, Android has more than its share of lawsuits on both patent and copyright claims. Anyone who is using Android in their products needs to ensure that they understand these risks and monitor the progress of these suits.
The recent decision in Software Freedom Conservancy Inc. vs. Best Buy, et al (see http://sfconservancy.org/docs/2010-07-27_dj-opinion.pdf ) has been greeted with hosannas by many in the open source community as “proving” that the GPLv2 is enforceable. I don’t want to be negative, but the value of the precedential value of the case is very limited because it is “default” judgment. The ruling is effective between SFC and Westinghouse Digital Electronics, LLC, but will have little effect on disputes between other parties. The decision has two lessons: (1) register your copyright as soon as possible (see below) and (2) don’t annoy a federal judge by dropping out of case. The decision does emphasize the importance of registering the copyright in open source software in the Copyright Office because it enables the copyright owner to seek statutory damages (avoiding the difficult question of how to determine “lost profits” for a software programs distributed for free) as well as attorneys’ fees.
The court ruled that Westinghouse Digital Electronics, LLC (“Westinghouse”) had infringed on the copyright in the BusyBox software by failing to comply with the terms of the GPLv2 in its distribution of the Westinghouse high definition televisions (“HDTV”). Although Westinghouse had originally “answered” the complaint, it then withdrew from participation in the suit, apparently due to financial difficulties, and ceased to respond to discovery requests from the plaintiff. If the failure to respond to discovery requests is due to “willfulness, bad faith or fault,” the court can grant a default judgment and Judge Scheidlin granted the motion. The financial problems of Westinghouse are evident through its use of the “assignment for benefit of creditors” procedure. The “assignment for benefit of creditors” is a California state law procedure similar to federal bankruptcy law to wind down companies. In this procedure, the company assigns its assets to a third party licensed by California who, then, disposes of the assets and then pays off the creditors of the company. Unlike bankruptcy law, the assignment for benefit of creditors does not “stay” litigation.
As part of the default judgment, the court granted four different forms of relief: an injunction prohibiting Westinghouse from copying and distributing the BusyBox software; statutory damages of $30,000 which it tripled to $90,000; “reasonable attorneys’ fees and costs; and forfeiture of all Westinghouse HDTVs which contain BusyBox software. Statutory damages are unique to copyright law; if the infringement takes place after the “registration” of the copyright in the software (or other work) in the Copyright Office, the copyright owner may seek such “statutory” damages rather than “actual damages” (which are the general basis for damages in the common law system). In addition, the copyright owner who is eligible for statutory damages can also obtain the award of reasonable attorneys’ fees and costs (the award of attorneys’ fees and costs is very unusual under US law).
The default judgment requires that all of the “well pleaded facts” in the complaint are accepted as true. The court also noted that Westinghouse’s failure to participate in discovery meant that the court could not determine appropriate damages and, thus, awarded the maximum damages and, then, trebled the damages on the basis that the infringement by Westinghouse was “willful”. As a default judgment, the decision has little precedential value because all of the facts are taken as “true”.