In 2008, the open source community saw the year end with a headline catching lawsuit, the Free Software Foundation files suit against Cisco for General Public License (GPL) violations. Not to be outdone, 2009 also ended with a bang.

Best Buy, Samsung, JVC and eleven other consumer electronics companies were named in a copyright infringement lawsuit filed on December 14, 2009, by the Software Freedom Law Center (SFLC) on behalf of the Software Freedom Conservancy. The scope of this lawsuit is unprecedented as it includes fourteen defendants.

The suit alleges that the defendants have distributed products containing the Software Freedom Conservancy's product BusyBox in violation of the terms of its GPL Version 2 license (the General Public License Version 2 superseded Version 1 in 1991, and is still widely used despite the creation of Version 3 in 2007).

Specifically, the Software Freedom Conservancy alleges that the defendants have not made BusyBox's source code available to downstream users. BusyBox is a tool that combines many UNIX utilities into a single executable and is commonly incorporated into household electronic devices. The Software Freedom Conservancy is seeking damages, injunctive relief and legal fees. BusyBox has been at the center of several other high profile GPL violations; the SFLC has in the past settled on behalf of BusyBox with Extreme Networks, Monsoon Multimedia, Xterasys Corporation, High-Gain Antennas and Verizon.

The Software Freedom Conservancy was not the only one to file a lawsuit for GPL violations as 2009 drew to a close. On December 2, 2009, Artifex Software Inc. filed a lawsuit against Palm, Inc. based on Palm’s alleged unauthorized copying and distribution of Artifex’s muPDF, a PDF interpreter that can be integrated with PDAs. The muPDF is licensed under the GPL or under Artifex’s standard commercial license for companies that are unwilling or unable to comply with the terms of the GPL. Artifex alleges that Palm has neither obtained a commercial license nor complied with the terms of the GPL.

These enforcement actions drive home the importance of taking inventory of what open source software is included in each product, what licensing obligations apply to each component, and compliance with these obligations. Open source license compliance is particularly important given the growing ubiquity of embedded computer systems -- the impugned products in the lawsuit against Best Buy et al include Insignia Blu-ray Disc players and Samsung LCD HDTVs.

If you're starting the New Year with clean IP in mind, this article endeavors to demystify open source by explaining how it works and providing a primer on some of the most frequently used open source licenses and their obligations.

What Is Open Source Software?

Open source software (OSS) refers to software in which, among other things, the source code is made available to the public. This is important because the open source community and various ecosystems can modify, improve, and incorporate the code into other works. Whereas with proprietary software, usually only the machine-readable compiled code is made available.

It is important to clarify the concept of “free”. OSS is often referred to as free. While most OSS is indeed free of charge, it should be noted that “free” does not necessarily mean free of charge but rather refers to the freedom to use, modify, and redistribute the source code so long as certain conditions are met. Conversely, a product that is free of charge is not necessarily open source.

Many assume that the open source movement runs contrary to the concept of Intellectual Property (IP) rights. This, however, is a myth. The open source movement is actually made possible by IP rights. In most jurisdictions, such as the United States and Canada, software is automatically protected by copyright as soon as an original work has been created. Copyright law grants copyright owners the exclusive right to reproduce, prepare other works based on the protected work, distribute, and publicly display the work. In general, open source licenses use these exclusive rights to ensure that the code remains open and accessible so that successive developers can innovate around it. Anyone violating the conditions of the license may be held liable for copyright infringement.

There are many benefits to using OSS. Users can edit the code, fix programming bugs, and even tailor the program to fit their specific needs. OSS is also significantly less expensive than proprietary software. In Jacobsen v. Katzer, the United States Federal Court of Appeal even recognized the substantial benefits of distributing copyrighted works under public licenses. The Court noted that program creators may generate market share for their programs by providing certain components free of charge. Similarly, a programmer or company may increase its national or international reputation by incubating open source projects. The Court also noted that improvement to a product can occur rapidly and free of charge from an expert not even known to the copyright holder.

What Are Open Source Licenses?

The Open Source Initiative (OSI) is a public benefit corporation that refers to itself as the stewards of the open source definition (OSD). The OSI is a community-recognized body for reviewing and approving licenses as OSD-conformant. A license must comply with the OSI’s ten distribution terms in order to be approved as open source. The three major requirements include royalty free redistribution, available source code, and the license must allow for modifications and derived works. Derived works are essentially works based upon the licensed work. The OSI’s website lists all of the approved open source licenses. You should also be aware that source code that is made available but is not approved by the OSI is still often referred to as open source. Merely making the source code available does not necessarily mean the licensor has permitted you to modify or redistribute the software. The OSI has criticized companies that have advertised their software as open source when the license was not approved by the OSI board. Such software might be more accurately described as source available software.

Open source licenses ensure that others are generally free to use, modify, and redistribute the OSS. More generally, license agreements are a type of contract. There are, however, subtle differences in the interpretation of licenses and contracts that can have harsh implications for a party that is caught offside the license.

A license gives a person permission to use another’s IP in a way that would otherwise constitute infringement. A license will set out the conditions of use and if the user violates these conditions the license allows IP owners to exercise their property rights. This is an important distinction because it is easier to obtain an injunction when one’s property rights have been violated, e.g., copyright infringement, than it is for a breach of contract. An injunction orders a party to refrain from the infringing activity and can halt business operations, whereas the ordinary remedy for a breach of contract is damages. In 2008, the United States Federal Court of Appeal in Jacobsen v. Katzer confirmed that if a license is limited in scope and the licensee acts outside the scope, the licensor can bring an action for copyright infringement.

Why Should I Care About Open Source Licenses?

In all likelihood your company has encountered OSS. OSS is becoming ubiquitous as companies that initially cast a wary eye on it have now realized its numerous benefits, including its ability to drive down development costs. It is now difficult to find commercial software that does not incorporate OSS in at least some areas.

While open source offers many benefits, it also heightens the probability of code contamination or unclean IP. Code contamination occurs when content is brought into a development project without regard for the licensing or copyright obligations.

The value of a company and its product often depend on the cleanliness of their IP and not solely on the protection of it. Disregarding license obligations can have surprising and costly consequences for many stakeholders. In any merger and acquisition or funding deal, uncertainty over clean IP can:

  • Generate risk and threaten successful closure
  • Increase product time to market
  • Affect software IP valuation and overall business valuation
  • Result in a litigation that can drag on for years draining company resources
  • Produce negative press and public scrutiny

One of the most well known examples of an open source surprise attack comes from Cisco and Linksys. Linksys routers used chipsets supplied by Broadcom, and Broadcom outsourced development of these chips to an overseas developer. In 2003, Cisco acquired Linksys for $500 million. After the acquisition, the Free Software Foundation (FSF), an organization that actively seeks companies that violate open source licenses, determined that the chips contained copyrighted code under the GPL and that Cisco was distributing the product in violation of the license. Cisco agreed to remediate the situation by releasing the source code. As a result, the software Cisco believed to be proprietary when it conducted its business and IP valuation of Linksys was now freely available to the public. In 2008, the FSF sued Cisco for copyright infringement claiming that Cisco never completed the compliance process. In 2009, Cisco paid an undisclosed amount to the FSF and settled.

What Are the Main Obligations of OSS Licenses?

Despite the many benefits of OSS, companies often shy away from it because they do not fully understand the obligations of various licenses. There is fear that using OSS will require a company to give away all of its software for free -- this is not accurate.

This section will explain the primary obligations of some of the most frequently used open source licenses. As you will see, open source licenses can be diverse and can range from quite permissive to quite restrictive. Some of the most frequently used open source licenses that will be reviewed are:

The matrix that follows groups together six of the most frequently used open source licenses based on their salient obligations. Please note that this is not an exhaustive explanation and it should not be construed as legal advice. Please consult with an attorney.

OSS Software License Matrix

License \ Obligations
I plan on using the licensed software internally only Can I distribute the licensed software unmodified? Do I have to release the source code of my modifications? Can I distribute licensed software (modified or unmodified) that has been combined or linked with code covered by another licensing model? Can I use the licensed software as part of a technological measure?
GPL v.2 There are no restrictions on use if the GPL licensed software is used internally and is not distributed outside the organization. You may even combine GPL licensed software with proprietary licensed software. Yes If the unmodified licensed software will be conveyed outside the organization, there is an obligation to make the source code available to downstream users and publish the original copyright notices and warranty disclaimers. You may not impose any further restrictions on the recipient’s rights. Yes If the modified code will be conveyed externally, there is an obligation to make the source code for all original and modified portions of the licensed code available to all downstream users. You must prominently notify users what files have been modified and the date of change. Include all original copyright notices and warranty disclaimers. You may distribute the GPL licensed software for a fee, but purchasers have the freedom to release it to the public without a fee. Maybe Any software that contains GPL code or is derived from GPL code must be licensed as a wholeunder the GPL terms. What this means is that in order to distribute software that has combined or linked GPL code with non-GPL code, the licenses must be compatible. For example, GPL v.2 is not compatible with GPL v.3. (See http://www.fsf.org/licensing/licenses) The GPL does not explicitly state that linked files create a work derived from the GPL code. However, it is generally understood that static linking, which modifies the code of one program, creates a derivative work and therefore must be licensedunder the GPL. It is less clear whether or not dynamic linkingcreates a derivative work. Dynamic linking does not necessarily modify any code. As this issue has not been litigated, it might be prudent to assume that under the GPL, statically or dynamically linked files both create derivative works. Yes No specific restriction
GPL v.3 No restrictions on internal use as long as your license otherwise remains in force. Yes If the unmodified licensed software will be conveyed outside the organization, there is an obligation to make the source code available to downstream users and conspicuously publish on each copy the original copyright notices, warranty disclaimers, and give all recipients a copy of the license. You may not impose any further restrictions on the recipient’s rights. However, you may remove additional permissions and place additional permissions on material added by you. Yes If the modified code will be conveyed externally, there is an obligation to make the source code for all original and modified portions of the licensed code available to all downstream users. You must prominently notify users what files have been modified and the date of change. Include all original copyright notices and warranty disclaimers. Prominently notify users that the work is released under this license and of any additional permissions. Maybe Please see the above explanation for GPL v.2 and refer to http://www.fsf.org/licensing/licenses for a more in depth look at license compatibility. Maybe The US Digital Millennium Copyright Act and similar non-US laws prohibit the intentional circumvention of technological measures designed to prevent unauthorized use/access to copyrighted works. (Note: Canada does not currently have any anti circumvention laws) The GPL v.3 does not stipulate what you can and cannot program. However, it does state that the licensed software shall not be deemed part of an effective technological measure. When you distribute the licensed work, you waive any legal power to forbid circumvention of the technological measures.
LGPL v.2.1 No restrictions on internal use. Yes If the unmodified licensed software will be conveyed outside the organization, there is an obligation to make the source code available to downstream users and publish the original copyright notices and warranty disclaimers. You may not impose any further restrictions on the recipient’s rights. Yes If the modified code will be conveyed externally, there is an obligation to make the source code for all original and modified portions of the licensed code available to all downstream users. You must prominently notify users what files have been modified and the date of change. Include all original copyright notices and warranty disclaimers Maybe The LGPL has an exemption that allows for the linking of LGPL code to non-LGPL code, without violating the license and without requiring source code disclosure of non-LGPL files. The license describes a library as a collection of software functions intended to be conveniently linked with application programs to form executables. A program that is designed to work with the LGPL licensed library by being compiled or linked with it, and does not contain a portion of the licensed library, is a work that uses the library, and is not a derivative work and therefore outside the scope of the LGPL. Any modifications to the licensed library itself or any work that contains portions of the licensed library is considered a derivative work and therefore covered by the LGPL. Yes No specific restriction. However, with LGPL v.3 licensed software you waive any legal power to forbid circumvention of the technological measures when you distribute the licensed work.
New BSD License No restrictions on internal use. Yes No obligation to disclose source code. Redistribution of source and binary code must retain the copyright notices, and you must not use the name of the licensor to endorse or promote products derived from the software. No No obligation to disclose the source code of your modifications. Yes No restrictions. Yes No specific restriction.
Apache License 2.0 No restrictions on internal use. Yes No obligation to disclose source code. You may redistribute the original or modified code as open source or proprietary. You may copy and distribute the software so long as you provide a copy of the license and retain the copyright, patent, trademark and attribution notices from the originating file. No No obligation to disclose the source code of your modifications. Prominently notify users of any modified files. You may add your own copyright statement and license terms to your modifications so long as you do not remove any of the original license requirements. Yes No restrictions. Yes No specific restriction.
Mozilla Public License (MPL) 1.1 No restrictions on internal use. Yes Include a copy of the license with every copy of the source code you distribute. Duplicate the notice contained in Exhibit A in each file of the source code. Yes You must make the source code of your modifications available. Maintain a file documenting modifications, date of the change, and a prominent statement that the modification is derived from the original code, and include the name of the initial developer in the source code. Yes Unlike strong copyleft licenses, code under the MPL may be combined with code not licensed under the MPL. When such a larger work has been created, MPL source code and any modifications thereof must remain under the terms of the MPL, however non-MPL code remains non-MPL. Yes No specific restriction.

Lessons Learned

GPL violations and other open source license violations occur on a regular basis even if unbeknownst to the offender. The lawsuits in 2009 demonstrate that licensees cannot simply ignore their open source licensing obligations. As seen in this article, licensors are willing to enforce the terms of the licenses in a court of law. The lawsuit against Best Buy et al highlights the importance of understanding what OSS is, taking inventory of what OSS is included in each product, what licensing obligations apply, and compliance with these obligations. This process can be facilitated by IP audits, now made easier with automated source code scanning tools that analyze and identify the presence of open source code, IP ownership, and what type of license applies.

It’s become common in many industries for products to contain hundreds and thousands of software components, so companies will increasingly seek assurances of clean IP. The Cisco-FSF, saga described above, serves as a cautionary tale to acquirers, targets and other stakeholders in the software food chain that IP audits should be conducted not only during the due diligence phase preceding a closing, but also throughout the product life cycle from conception.