September 20, 2011 Articles

Complying with Source-Disclosure Obligations

By Edward J. Naughton

It may seem counterintuitive, but using open-source software code does not always require you to open up your source code. There are more than 50 approved open-source licenses, and many of them permit licensees to use or modify code without requiring the distribution of source code for the resulting work.

Copyleft licenses are a different story. Conceived by Richard Stallman, the founding figure of the free software movement, copyleft is a means of ensuring that everyone is free to use, copy, modify, and distribute software. Copyleft software is released under a license that allows downstream recipients to freely use, copy, modify, and redistribute the code, but it also requires any redistribution of the original code and derivations of it to fall under the same license. See Free Software Foundation, Inc., What Is Copyleft?, GNU Operating System.

Among copyleft licenses, the GNU General Public License (GPL) and Lesser General Public License (LGPL) are the archetypes, and they're some of the most popular. Stallman first wrote the GPL in 1989. His Free Software Foundation (FSF) released an updated version (GPLv2) in 1991, which became the most widely used free-software license. In 2007, the FSF released a new version of the GPL (GPLv3) that was designed to address some of the shortcomings of GPLv2, especially with respect to embedded systems. (The obligations created by GPLv2 and GPLv3 are substantially identical in many respects, and I refer to them collectively as "the GPL" when there is no need to distinguish between them.)

The LGPL (originally the Library General Public License) was developed by the FSF as a less-copyleft alternative to the GPL for use with libraries. It permits a non-copyleft application to use free software libraries in certain circumstances without making the application itself subject to copyleft. It requires, however, that the library and any modifications to it remain under the original copyleft license. Version 2.1 (LGPLv2.1), released in 1999, remains the most common version, although version 3 (LGPLv3) was released in 2007. (Again, I'll refer to these versions collectively as "the LGPL" when there is no need to distinguish them.)

Lawyers who work with software companies know that it can be a challenge to determine whether the GPL or LGPL requires the distribution of source code, but the challenges don't end there. Simply complying with the GPL can be tricky, too, particularly when the code is embedded in a device. The consequences of a mistake can be serious. In fact, all of the recent GPL-enforcement cases have turned not on whether the GPL applied, but on whether the defendant had complied with the source-code-disclosure requirements.

What Must Be Disclosed?
GPLv2
GPLv2 requires the provision of a copy of the license and the complete "corresponding source code" of works subject to the license. "Source code" is "the preferred form of the work for making modifications to it." GPLv2, § 3. For an executable, source code "means all the source code for all modules it contains." But it also includes "any associated interface definition files" plus "the scripts used to control compilation and installation of the executable." Because the purpose of the license is to permit a user to modify the original code and generate a new executable, "scripts" includes any software programs, tools, or scripts necessary for a user to install a modified version of the program, such as makefiles, configuration files, build scripts, and packaging scripts.

It usually is not necessary to provide the compiler used to generate the executable, but you must provide information about it. The Software Freedom Law Center (SFLC), one of the primary enforcers of the GPL, recommends that you provide a README file with the name of the compiler, its exact version number, and where it can be acquired, regardless of whether the compiler is proprietary or open source. A Practical Guide to GPL Compliance, Software Freedom Law Center. When the GPLed code is embedded in a device, however, it is usually necessary to provide the cross-compiler and toolchain so a user can build the modified software and reinstall it in the device. A detailed README file should describe, step by step, how to build a binary from the sources.

Because GPLv2 requires the provision of "corresponding" source code, the source code must correspond exactly with the executable that is distributed. Frequently Asked Questions about the GNU Licenses, GNU Operating System. If multiple versions of firmware for a product have been distributed, then the source code corresponding to each such version must be distributed. Good version control, release-management practices, and build documentation are critically important if you want to avoid problems later.

GPLv3
The source-code-disclosure requirements for GPLv3 are similar. "Corresponding Source" means "all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities." GPLv3, § 1. Thus, like GPLv2, GPLv3 requires the provision of all of the programs, files, tools, and scripts necessary to install a modified version of the GPLv3 software, including the compiler or information about it. A copy of the license must also be included.

In addition, when GPLv3 software is distributed in a "User Product," such as a consumer device, it also is necessary to provide "Installation Information." Installation information includes any methods, authorization keys, or other information required to install and execute modified versions of the GPLed code in that user product. The only time installation information does not need to be provided is if the GPLv3 software cannot be modified as a technical matter (for example, if the software is burned onto a ROM chip that cannot be upgraded without replacing the chip), as opposed to a contractual provision that purports to prohibit modification.

LGPLv2
The source-code-disclosure requirements for the LGPL parallel those of the GPL. LGPLv2 requires the disclosure of the license and complete corresponding source code. "Source code" is the preferred form of a work for making modifications to it. LGPLv2.1 § 0. For a library, "complete source code" means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the library. LGPLv2 similarly requires the provision of all of the programs, tools, and scripts necessary to install a modified version of the library, and there must be a 1:1 correspondence between the source and the executable.

LGPLv3
The source-code-disclosure requirements for LGPLv3 depend on how an application interacts with the licensed library. If the application merely incorporates material from the library's header files, it's not necessary to provide source code; it is enough to include copies of the LGPLv3 and GPLv3 licenses and a prominent notice that the library is used by the application and is covered by the LGPLv3. § 3.

If the application is combined with or linked to the library to form a combined work, the source-code-disclosure obligations are more complicated. In addition to including the information described above, it is also necessary to provide the library in a way that permits the user to modify the LGPLed library and recombine or relink it with the application. There are two ways to do this. The first is to provide the "Minimal Corresponding Source" of the combined work, which is the corresponding source code for the combined work, excluding source code for portions of the combined work that are based on the application and not on the library. Id., at § 4(d)(0).

In addition, the corresponding application code must be provided. The corresponding application code may be provided in object code or source code form, along with all data and utilities needed to reproduce the combined work, so long as it is provided in a form suitable for and under terms that permit a user to recombine or relink the application with a modified version of the LGPLed library. Alternatively, it is sufficient to provide a shared-library mechanism that uses at runtime a copy of the LGPLed library already on the computer system, as long as it will operate properly with a modified version of the library. Id., at § 4(d)(1). Finally, it is necessary to provide installation information to the same extent as it is required under GPLv3 (in other words, if the L GPLed code is in a user product that can be field-upgraded). Id., at § 4(e).

How Must the Corresponding Source Code Be Provided?
GPLv2 and LGPLv2
There are three options for providing corresponding source code under GPLv2 and LGPLv2. The corresponding source code can be provided alongside the executable, GPLv2, § 3(a), or the executable can be accompanied by a written offer, valid for at least three years, to give any party the corresponding source code. Id., at § 3(b). Unfortunately, the license, reflecting the prevailing technology when it was drafted, requires the source code to be provided on "a medium customarily used for software interchange." In other words, the code must be on physical media; Internet distribution is not sufficient under GPLv2. Therefore, while it is very common for the written offer (usually in the user documentation) to include a link to a download site, that is technically insufficient.

Section 3(c) of GPLv2 permits a licensee to pass along a section 3(b) written offer, but that is expressly limited to "noncommercial distributions" and only if the licensee received the executable with such a written offer.

GPLv3 and LGPLv3
GPLv3 permits source-code distribution by the same methods as GPLv2, but it also allows some additional options. First, if you offer the object code for download over the Internet, you can offer the corresponding source code over the Internet as well, in the same way and from the same place as the object code. GPLv3, § 6(d). Similarly, if the object code is offered over a peer-to-peer network, the source code can be offered in the same way. In addition, GPLv3 fills the gap in GPLv2; the written offer to provide source codes can be fulfilled by Internet distribution if the download site for the source codes is publicly available and remains active for three years from the last distribution of the binaries (or spare parts for a device containing the binaries). GPLv3, § 6(b). LGPLv3 authorizes distribution by the same methods as GPLv3 or by means of the shared library mechanism described above.

As a practical matter, it may not be possible to take advantage of the new and more convenient methods of source code distribution allowed by GPLv3. Software distributed commercially is almost always subject to multiple licenses, and it is quite likely that a device that includes GPLv3 code also includes code subject to GPLv2 and/or LGPLv2. In that event, the only permissible methods of source-code distribution will be the more restricted methods authorized by GPLv2.

Who Has the Obligation to Provide Corresponding Source Code?
Everyone who distributes (GPLv2/LGPLv2) or conveys (GPLv3/LGPLv3) code must provide source code. In the context of a consumer device, the source-code-provision obligation attaches to every level of the distribution chain, although the scope of those obligations will vary at each stage. Consider, for instance, a DVD player that is sold by an electronics retailer and built by a contract manufacturer, which incorporates a chip obtained from a chip manufacturer whose chip has firmware containing an embedded program subject to GPLv2 that was written by an independent software developer. The original developer makes the source codes for his or her program available under the GPLv2. The chip manufacturer can provide the corresponding source code alongside the binaries on the physical medium of the chip, but will not typically take up that precious space and will instead make a written offer under GPLv2 § 3(b) to provide source code to anyone who asks. Because the contract manufacturer is engaged in commercial distribution, it cannot simply pass along the chip manufacturer's written offer and must make its own source-code provision. The retailer, in turn, must do the same.

This is no mere hypothetical. GPL-enforcement actions have been asserted against retailers such as Best Buy; distributors such as Verizon; device manufacturers such as Cisco Systems, Monsoon Multimedia, JVC, and Samsung; and chip manufacturers such as Broadcom. See, e.g., Software Freedom Conservancy, Inc. v. Best Buy Co., 09-CV-10155 (S.D.N.Y.) (naming 14 defendants); Andersen v. Monsoon Multimedia, Inc., 07-CV-8205 (S.D.N.Y.); Andersen v. Verizon Communications, Inc. 07-cv-11070 (S.D.N.Y.). Companies at every level of the distribution chain need to be mindful of GPL source-code-disclosure obligations.

When Must the Corresponding Source Code Be Provided?
As discussed above, the preferred method for providing corresponding source code is alongside the executable, on the same media, on a CD accompanying a device, or on the same download site. The timing issue arises only when the corresponding source code does not accompany the binaries, when the licensee gives a written offer to provide the source code. The text of the GPL does not expressly specify timing, but the structure and purpose of the license make plain that the corresponding source code must be available simultaneously with the distribution of the object code. The enforcers of the GPL emphasize this:

It is unacceptable to use option [3](b) merely because you do not have Corresponding Source ready. We find that some companies chose this option because writing an offer is easy, but producing a source distribution as an afterthought to a hasty development process is difficult. The offer for source does not exist as a stop-gap solution for companies rushing to market with an out-of-compliance product. If you ship an offer for source with your product but cannot actually deliver immediately on that offer when your customers receive it, you should expect an enforcement action.

A Practical Guide to GPL Compliance, Software Freedom Law Center (emphasis in original); accord gpl-violations.org Source Code Release FAQ, gpl-violations.org ("The GNU GPL demands that as soon as you distribute GPL licensed software in executable format you make available the 'complete corresponding source code'."); but see Google to Delay Open Source Honeycomb Release, Linux for Devices (describing indefinite delay in release of Android Honeycomb source code).

Companies distributing GPLed code must therefore plan ahead to ensure that they are able to provide corresponding source code simultaneously with the shipment of their executables and devices.

What Are the Consequences of Noncompliance?
For many years, the FSF enforced the GPL and LGPL through private negotiations rather than litigation, and there were questions about whether the GPL was enforceable. See Eben Moglen, "Enforcing the GPL," (2001). Perhaps because of these doubts, starting in 2007 the FSF and its allies, the SFLC and the Free Software Conservancy (FSC), began more aggressive enforcement efforts, including filing copyright-infringement actions. Those lawsuits give greater visibility into the enforcement process.

The heart of those enforcement actions is section 4 of the GPLv2 (section 8 of the LGPLv2.1), which provides that any violation, even if inadvertent, results in the automatic and immediate termination of rights to use the licensed code. Curing the violation does not automatically reinstate the license; it is necessary to obtain an explicit reinstatement from the copyright holder:

Since your rights under GPLv2 terminate automatically upon your initial violation, all subsequent distributions are violations and infringements of copyright. Therefore, even if you resolve a violation on your own, you must still seek a reinstatement of rights from the copyright holders whose licenses you violated, lest you remain liable for infringement for even compliant distributions made subsequent to the initial violation.

A Practical Guide to GPL Compliance, Software Freedom Law Center.

As a legal matter, this position has fair support. In fact, in 2007, a German court relied on that very provision to impose an injunction in a case involving Harald Welte, the founder of gplviolations.org and a well-known GPL enforcer in the EU. See Landgericht [LG] München I [Lower Regional Court of Munich], Welte v. Skype Technologies, SA [PDF], File No. 7 O 5245/07 (July 12, 2007); see also Skype Hangs Up on Appeal, Will Fully Comply with GPL, Ars Technica. Recent U.S. cases similarly support the proposition that the breach of a copyright license can result in the loss of rights under the license, such that the continued use or distribution of the work is infringing and subject to an injunction. See, e.g., MDY Industries v. Blizzard Entertainment, 629 F.3d 928 (9th Cir. 2010) (breach is infringement if the licensee breaches condition on a grant of license and the condition is related to exclusive rights under copyright); Jacobsen v. Katzer, 535 F.3d 1373 (Fed. Cir. 2008) (breach of condition on grant of a license is copyright infringement); LGS Architects v. Concordia Homes, 434 F.3d 1150 (9th Cir. 2006) (entering an injunction where the licensee exceeded the scope of the license).

The provision of corresponding source code will always be required before reinstatement, but the copyright holders usually demand additional concessions. Many of the reported settlements involve the appointment of an "open source compliance officer," periodic reporting of compliance efforts, notification to previous recipients of the GPLed program, and monetary payments. E.g., BusyBox Developers and Monsoon Multimedia Agree to Dismiss GPL Lawsuit, Software Freedom Law Center (Monsoon Multimedia settlement); FSF Settles Suit Against Cisco Free Software Foundation (Cisco settlement); BusyBox Developers Agree to End GPL Lawsuit Against Verizon, Software Freedom Law Center (Verizon and ActionTec settlement).

The SFLC takes the view that copyright holders have broad latitude in their reinstatement demands. A Practical Guide to GPL Compliance, Software Freedom Law Center ("Different copyright holders condition reinstatement upon different requirements, and these requirements can be (and often are) wholly independent of the GPL. The terms of your reinstatement will depend upon what you negotiate with the copyright holder of the  GPLed program."). And they do make significant demands: According to affidavits filed in a case brought by the developers of Busybox against Best Buy, the SFC demanded that Broadcom (Best Buy's supplier) disclose the source code of a number of proprietary libraries and programs as a condition to reinstatement. When Broadcom refused, the SFC sought an injunction against Best Buy's sale of a line of Blu-ray players. Declaration of Rashid Khan, Doc. No. 180, in Software Freedom Conservancy, Inc. v. Best Buy Co., 09-CV-10155 (S.D.N.Y.). According to other filings in that case, the FSC also demanded the right to review, prerelease, new versions of products and to review code not authored by the developers it represents.

The GPLv3 and LGPLv3 make it easier to resolve violations. Under those licenses, a licensee's rights are restored upon curing the noncompliance, unless a copyright holder provides notice of violation within 60 days. If the licensee has not previously been notified of a violation by that copyright holder and it cures the violation within 30 days of such a notice, its rights are restored. Otherwise, it must negotiate with the copyright holder for explicit reinstatement of the license, as under GPLv2.

Noncompliance can lead to monetary damages as well. Most reported settlements have involved some monetary payments, and, in the Best Buy [PDF] case, the plaintiffs obtained statutory damages of $90,000 and attorney fees from Westinghouse after it ceased defending the case upon its insolvency.

Conclusion
The GNU licenses are complicated in most respects, and the source-code-provision requirements are no exception. The challenges they present are not going away, but are instead growing more important. As free software has become more widely accepted and as software-supply lines have grown longer and more convoluted, the potential for inadvertent violations increases. At the same time, GPL enforcement has become more active, making the repercussions of noncompliance more real and much more significant. Any lawyer who advises software clients must understand the GNU licenses and educate his or her clients to ensure they are not unwittingly setting themselves up for an embarrassing and costly compliance action.

Keywords: litigation, intellectual property, GNU, copyleft, GPL, LGPL, source code

Edward J. Naughton – September 20, 2011


Copyright © 2011, American Bar Association. All rights reserved. This information or any portion thereof may not be copied or disseminated in any form or by any means or downloaded or stored in an electronic database or retrieval system without the express written consent of the American Bar Association. The views expressed in this article are those of the author(s) and do not necessarily reflect the positions or policies of the American Bar Association, the Section of Litigation, this committee, or the employer(s) of the author(s).