Open Source Software Licensing

Maeve Dion. Intern. Email.
F. Emily Frye. Assoc. Director for Law & Economics.
Summer 2004.

Background

Open Source Software (OSS) presents liability risks distinct from traditional software licensing. Neither a fad nor a fleeting technology, OSS has claimed an ever-growing market share and has developed a broad user base. Whether in-house counsel or litigator, contractor or consultant, practitioners must understand the OSS business model and licensing issues in order to both advocate and advise effectively.

Traditional software has developed under a closed-source, proprietary model based in the law of copyright. Software developers write the program as source code, and then compile the source code into “executable” code for licensing purposes. While executable code consists of only computer-readable language, the source code contains the command-by-command programming in human-readable terms. The profitable US software industry has been built on a model in which software developers license the executable code while keeping the source code secret. The research and development costs of the software are recouped in licensing fees.

OSS supports a different business model. Having evolved from a philosophical belief that source code should be available to licensees, OSS licenses include both the executable code and the source code. Licensees may run the program, read the source code, modify the code, and redistribute the modifications. This business model produces profit primarily through vendor maintenance and support rather than through licensing fees.

Although skeptics originally believed that OSS would remain an academic endeavor, OSS has been widely deployed throughout the commercial and government sectors.  The absence of initial licensing fees has made OSS attractive across a wide spectrum of users, for a broad diversity of applications.  Additional benefits accrue from access to the source code, which means that a licensee is not locked into a specific software vendor for customization, maintenance, or support. Also, OSS provides broad interoperability, allowing for better system coordination (especially given the complexity of distributed, heterogeneous systems).

OSS also differs from traditional software in its development process. Software has traditionally been developed as a work-for-hire within a software company, or as the project of an individual software developer. OSS, however, is usually the product of code contributions from various individuals collaborating on a common project from disparate geographical locations. These contributions are usually vetted by a group of project managers and displayed online for a sort of peer review critique. Once an OSS program is released for use, the communal critique and debugging process continues. In contrast, closed-source, proprietary software may be reviewed and debugged only (or primarily) by its own developers.

These differences in development processes and business models create different concerns. Such concerns can be grouped under the labels of warranties / indemnification and forced openness.

Warranties / Indemnification

Whereas traditional software licenses include warranties and indemnifications regarding intellectual property of third parties, OSS licenses usually expressly disclaim such warranties and give no indemnification. Most OSS programs evolved through various successions of developers (some uncompensated), none able to warrant each other’s contributions. The typical OSS license is unlikely to trigger any common law or statutory warranties because the software is usually provided for free. Further, while each contributor’s code is copyrighted, the OSS development process may not include a reliable intellectual property audit. As compared to traditional software, OSS creates increased opportunity to introduce infringing code. And without OSS intellectual property indemnification, liability for such infringing code falls to the end user.

Forced Openness

As a mechanism to increase OSS contributions, many OSS licenses include a provision that the OSS community calls “copyleft.”  One of the most common OSS licenses, used for some of the most widely distributed software, is the GNU General Public License (“GNU GPL” or “GPL”), which includes a copyleft provision. Basically, this provision mandates that if a company (1) redistributes a copyleft OSS program, (2) modifies a copyleft OSS program and redistributes it, or (3) includes copyleft OSS code within an otherwise non-OSS program and distributes that program, then the distributed programs must be offered under the same terms as the originating copyleft program. This somewhat circular language means that, in effect, distributing a program under any of these three methods forces the distributed product to be released as copyleft OSS.

A copyleft provision does not automatically place the source code into the public domain. Rather, the source code must be made available to the licensees of the program. Openness is forced only for distributed programs. If a company licenses an OSS program, modifies it, and uses the modifications internally, the copyleft OSS license does not force that company to give the modified code to anyone or to release its source code into the public domain.

While the GPL governs a large portion of the OSS world, a variety of other licenses -- each unique and potentially problematic -- apply to different parts of OSS. The ramifications of forced openness, and the absence of warranties and indemnifications in OSS licenses, are key provisions that require close examination when licensing software into or out of a company and when building software that incorporates code governed by an OSS license.

OSS Licensing

An OSS licensee receives no developer warrantees or indemnifications, but may be able to acquire indemnification from vendors or insurers. Similar to traditional software, OSS almost certainly offers no warranty of fitness for a particular purpose. Unlike some traditional software, though, OSS likely offers no indemnification against damage or intellectual property infringement. However, depending on the type of OSS license, a vendor may provide indemnification. In addition, recent litigation by the originators and endorsers of OSS has spawned various inventive insurance offerings. For example, Open Source Risk Management, Inc. provides an indemnification product for Linux end-users and counsels clients on general OSS risk management.

Although OSS has become a popular and competitive form of software, releasing software under an OSS license may affect the viability of software. For example, traditional software licenses often contain terms that offer users some assurance about backwards capability, forward compatibility, and user support for no-longer-current versions of software. With the exception of a few large, well-commercialized OSS products, these terms are not available for OSS.  The potential lack of support may deter some users from deploying an OSS product.

Software previously licensed as closed-source may later be released as OSS.  In this case,  implications to existing closed-source licensees must be considered as part of the procurement decision-making process.

Software Development

The decision to use OSS code in software development will impact the product’s licensing, marketing, and revenue model. The type of license governing the incorporated OSS code is important, particularly if it includes a copyleft provision. Knowingly incorporating code governed by a copyleft OSS license may increase a developer’s legal liability profile. Further, releasing the product under a closed-source license may violate the licensing requirements of the included OSS code.  For example, it may destroy legal defenses to a hacking attack that uncovers and releases source code into the public domain.

Although no U.S. court has yet tested the validity and strength of an OSS license, Eben Moglen, general counsel for the Free Software Foundation, Inc. (copyright holder of the GNU GPL), claims to have enforced the GNU GPL through numerous settlements worldwide. [Eben Moglen, Freeing the Mind: Free Software and the Death of Proprietary Software, 56 Me. L. Rev. 1, 6-7 (2004).] There is no reason to believe that an OSS license is a lesser beast than a traditional software license. With proper notice, an OSS license may be presumed to be an enforceable contract.

Further, a closed-source, proprietary software program that includes OSS code may be deemed an unauthorized derivative of the OSS. As such, the closed-source, proprietary developer may lose intellectual property ownership of the code he wrote around the OSS code. [See Sean Hogle, Unauthorized Derivative Source Code, 18 No. 5 Computer & Internet Law., May 2001, at 1, 3 (discussing the Copyright Act §103(a) “used unlawfully” exception).]

On a helpful front (and responding to the SCO v. IBM litigation issues), companies have created new tools to help manage software development. For example, “protexIP/Development” (from Black Duck Software, a 2004 start-up) allows a company to restrict inclusion of code governed by OSS licenses judged to be unacceptable liability risks by the company. The program delivers warnings to developers when such code is detected. The program also streamlines OSS code auditing, tracking the contributions of developers. Black Duck also provides a service called “protexIP/Registry,” a sort of third-party register and auditor that provides independent validation of code-building processes in which OSS licensing is implicated.

While these programs are useful tools for developers, their attorneys must rely on the legal tradition of issue spotting. In order to identify the issues, attorneys must know both the practical and the legal distinctions between traditional, closed-source, proprietary software and OSS. The models have different technological and economic benefits, and different liability risks. Recognizing these differences is essential to anticipating and limiting liability, especially as OSS continues to propagate in the software world.

Related links:

GNU GPL http://www.gnu.org/licenses/gpl.html.

Other OSS Licenses http://www.opensource.org/licenses/ and http://www.gnu.org/licenses/license-list.html.

Open Source Risk Management http://www.osriskmanagement.com/.

Black Duck Software http://www.blackducksoftware.com/.