Overview

30% of software at the top 2000 public corporations is "open source" software. Why does that matter? Because any company who distributes products including open source software has an affirmative obligation to comply with the terms of the license agreement(s) corresponding to that open source. Depending on the license agreement, these terms can range from publishing license terms and the open source software itself, to publishing proprietary aspects of your competitive software. Failure to comply with the license terms may not be a matter of contract, but a matter of copyright. Copyright liability may give rise to actual or statutory damages. More importantly, liability may give rise to injunctive relief in certain circumstances.

Open source software has several advantages over proprietary software, and it is here to stay. If you're going to include open source in your products, however, you must take the legal aspects seriously. The key to effectively managing the use of open source in your organization is to (1) know what open source is included in the products you distribute, (2) know what the applicable license terms are, and (3) have a plan for properly complying with those terms. This may sound straight forward, but in practice, it is a challenge and requires specialized legal and technical expertise.

What Is OSS? - Why Use It?

OSS is source code that the programmer/author makes publicly available for others to use or modify to suit a particular application. For example, libraries of open source software are available for constructing a graphical user interface, a real-time operating system, and Bluetooth connectivity. There is no limit to the broad range of open source software applications. There are currently over 4 billion publicly-available open source software files. The advantages to using OSS includes the availability of software packages that are continuously being improved by countless developers, you can save on cost by not reinventing a software project already developed, and you may be able to advance a product faster to market using software projects made available.

Whether a company has its own software team or contracts software development, there is an increasing likelihood that a programmer has knowingly or unknowingly incorporated some OSS into a product along the way. For example, the developer could receive an application or component from a third party that has embedded open source software that the developer is unaware of. In another example, the developer could download an open source software project from the public domain without reading or understanding the license attached to the project. While the programmers may have a thorough understanding of how the code operates, they often do not understand or consider the implications of selecting a particular OSS component.

What Does OSS Require?

There are currently over 2,300 license agreements governing the use of the more than 4 billion open source software files. Open source is "free" in the monetary sense, but it is not free of legal obligations. Every piece of open source software is subject to specific license terms. And, every open source software license includes some affirmative obligation to be undertaken by anyone who distributes the code, or products including the code.

OSS is like proprietary software in that both are protected by copyright when created whether or not the copyright is registered. Similar to other copyright protected works, software is usually owned by the author and licensed for use subject to licensing terms and conditions. Unlike proprietary software licenses with terms negotiated by the parties, OSS licenses are similar to shrink-wrap licenses with implied acceptance of terms imposed upon use. OSS licenses may include affirmative obligations triggered when the software is distributed that require all members of the supply chain to comply with the OSS obligations.

For example, an original equipment manufacturer (OEM) that purchases subsystems with embedded OSS software from a supplier and incorporates them during final assembly into the OEM product may unknowingly have OSS license obligations that apply not only to the subsystem provided by that supplier, but to other subsystems and proprietary code in the final product. Violating OSS license terms, whether knowingly or not, may create exposure for copyright infringement. There are over 20 "most common" OSS licenses, some with different versions (1.1, 2.0, etc.) and most with varying license terms. Licenses include GPL, MIT, Apache, BSD, Artistic, LGPL, CDDL, etc. Representative license term categories and conditions include:

• Source Code: Accompany the work with the complete source code for the library including the changes, use a suitable shared library mechanism for "linking with the library", and/or accompany the work with a written offer to give the user the materials valid for 3 years
• Modifications: If a modified version of the code is distributed, must also make the modified source code available to the customer and include notices indicating that changes have been made to the files and the dates of the changes
• Combinations: Only modify the library with other code that is under a compatible license or in the public domain
• Copyright Notice: If a product presents copyright notices on a display, they must include a reference directing the customer to the copy of this license
• Waiver of Intellectual Property (IP) Rights: Static linking of OSS to proprietary code waives any IP rights in the proprietary code and grants a royalty free license to all the code when the OSS is published/distributed with the proprietary code

What's The Risk?

Failure to comply with OSS license terms may result in termination of the OSS license. See, Jacobsen v. Katzer 535 F.3d 1373, 1382 (Fed. Cir. 2008). As previously noted, sale and distribution of products or software including OSS in violation of OSS license terms could subject the company to a copyright infringement claim.

OSS organizations, such as the Software Freedom Conservancy and the Software Freedom Law Center, provide legal representation to OSS owners to litigate alleged violations of OSS license terms. Copyright infringement lawsuits filed against defendants in federal court for the defendants' alleged breach of OSS license terms often seek damages (statutory or actual) and injunctive relief. Many OSS lawsuits quickly settle because violations are easy to prove and have limited defenses. Various tools can scan the object code embedded within a product to determine if OSS is present and which licenses are associated with that code. In one of the OSS settlements made public, the defendant paid a monetary fee, became OSS compliant for their product, and was required to put in place an OSS Compliance Officer. (see Free Software Foundation, Inc. v. Cisco Systems, Inc., No. 1:08-CV-10764 (S.D.N.Y. filed Dec. 11, 2008, settled May 20, 2009). )

Calculating damages for an OSS violation depends on various case-specific factors and whether the plaintiff is seeking actual damages or statutory damages 17 U.S.C. § 504(a)-(c). Actual damages represent the quantifiable monetary loss the OSS copyright holder has suffered, or the profit the infringer has gained. Id. Statutory damages are set by law, regardless of any actual damages suffered by the OSS copyright holder. OSS plaintiffs often seek statutory damages because they do not sell or distribute the OSS for monetary gain, and infringer profit associated with the OSS may be more difficult to ascertain. Id.

Statutory damages may range from $750.00 to $30,000 per infringement (not per act of infringement). Each infringement may be determined based on case-specific facts. For example, initial release of a software program may be one infringement while each updated release/version (e.g., version 2.0) may be counted as an additional infringement. In addition, if the Court determines that the defendant acted willfully, statutory damages of up to $150,000 per infringement may be awarded. Courts have broad discretion to set statutory damages within the range set forth by the statute, and may consider factors such as the magnitude of the infringement, the harm to the plaintiff, and the knowledge of the defendant. The Court may also award plaintiff's attorney fees and costs. An injunction to prohibit sales of the product containing OSS may also be available, although the Court will weigh a number of factors before issuing an injunction based on finding of copyright infringement. See eBay Inc. v. MercExchange, L.L.C. 547 U.S. 388 (2006).

How Can OSS Risk Be Managed?

While suppliers and developers may disclose OSS they have intentionally incorporated into a product, the bigger problem is the OSS that is unknowingly incorporated. As such, implementing a compliance plan to manage OSS within an organization that includes, developing and OSS policy and educating the product development team of the policy and potential OSS obligations may not be enough. A digital audit should be performed to identify any OSS and associated license(s) that apply to the code. Once OSS is identified, the compliance plan should include procedures to comply with the OSS license obligations.

Many organizations that have embraced OSS have created a website to satisfy publishing obligations including notice, source code, and/or object code based on the particular OSS license(s). A best-in-class policy related to the delivery of a product includes maintaining a public website such as: opensource.insertcompanyname.com. In addition to fulfilling licensing obligations, such a site provides transparency to handling of OSS. Many companies also establish, publicize, and monitor an email address specifically dedicated to open source matters. In addition to license compliance, an important function for a website and email address dedicated to OSS is to facilitate communication between the company and the open source community. In addition to addressing the most common complaint from the open source community and groups such as gpl-violations and the Software Freedom Law Center, which is the inability to communicate with companies regarding open source questions related to products in the market, this facilitates identification and prompt resolution of potential OSS issues that may be unknown to the company.

Any company that sells products having embedded software should develop a plan for managing OSS, selecting OSS licenses, and complying with applicable license terms early in the product development cycle. This requires coordination among developers, engineers, purchasing, and legal counsel. Educating all of these groups with respect to OSS issues and the potential bet-the-company risks is key to successful implementation. Ongoing vigilance in terms of periodic audits for OSS and associated licenses will prove beneficial to long-term success with taking advantages offered by the use of OSS in the product development cycle in developing successful products while minimizing the risks of failing to satisfy OSS obligations.