COMPUTING AND THE L AW

0018-9162/12/$31.00 © 2012 IEEE Published by the IEEE Computer Society JUNE 2012 9

Open Source Software

O pen source software (OSS) is available in source code form that developers can view, modify, extend, and,

in many cases, further distribute with or incorporate in their own soft-ware. OSS rarely comes without some restrictions, however. Any company that offers a product that incorpo-rates OSS needs to be aware of those restrictions and other conditions for its use—otherwise it may find itself on the receiving end of a lawsuit.

Be sure to check the IEEE Com-puter Society’s website for the podcast that accompanies this article (www.computer.org/portal/web/ computingnow/computing-and-the- law).

USING OSS—CAREFULLYUsing OSS can be advantageous for

several reasons. It’s readily available, and there are no royalties or license fees. In addition, in many cases there’s a community of users that’s continu-ously improving, debugging, testing, and updating the OSS application or module. Therefore, OSS might be the best solution available from both a quality and cost standpoint. Incorpo-

distributes software that includes or is derived from OSS and doesn’t comply with the terms of the license under which the OSS was made available, the company is likely infringing the copyright in the OSS or breaching the terms of the license agreement—or both.

OSS LICENSESMany OSS modules and applica-

tions are available for download and are accessible without requiring the recipient to expressly assent to any license terms. For example, typically no installation software is included that requires the recipient to affir-matively click “I agree” to the license terms before installing the relevant OSS. However, without possessing a valid license, the recipient would likely be infringing the OSS copyright. At this point, recipients usually can’t escape liability by claiming they don’t agree to the license terms.

Generally, OSS licenses fall into one of three categories: restrictive (also called “copyleft”), moderately restrictive (also called “copycen-ter”), and permissive. In theory, the number of possible licenses is infinite

The sixth in a series of articles providing basic information on legal issues facing people and businesses that operate in computing-related markets focuses on open source software.

Brian M. Gaff and Gregory J. PloussiosEdwards Wildman Palmer LLP

rating OSS into a project might also save a developer time and effort.

But who owns the software code in the resulting project? When dis-tinguishing between software that a company owns and OSS that a com-pany obtained from another source, lawyers and business people will often refer to software that a com-pany owns as “proprietary” software. While this distinction is valid from the company’s perspective—that is, the company doesn’t own the OSS that it downloaded from a website—it’s a mistake to infer from this that no one owns OSS or that it’s in the public domain.

The original developers of the OSS or their assignees own the copyright in the OSS. These OSS owners can make their software available for anyone to use under the terms of a particular license that the owners have chosen. Because they own the copyright, they can require that anyone using the OSS do so according to that license.

If you want to copy, modify, create a derivative of, or distribute OSS, you must either own the copyright in the OSS or have a license from the copy-right owner. Further, if a company

COMPUTING AND THE L AW

10 COMPUTER

An exception does exist under the GPL for a compilation (called an “aggregate”) of the OSS with other separate and independent works. This applies if the separate and inde-pendent works aren’t by their nature extensions of the covered work and aren’t combined with it to form a larger program in or on a storage or distribution medium. This exception also requires that the compilation and its resulting copyright aren’t used to limit the access or legal rights of the compilation’s users beyond what the individual works

permit. If the requirements of this exception are met, then inclusion of a covered work in such an aggre-gate doesn’t require that the license terms to the other parts (such as the company proprietary parts) of the aggregate also be licensed under the GPL.

The GPL doesn’t clearly define when multiple components are deemed to be an aggregate (compi-lation) that isn’t a covered work or when they’re deemed to be one larger program with multiple parts. Many companies won’t risk including GPL-licensed OSS in distributions of their software products unless the distribu-tion clearly fits into the compilation exception—for example, where the operating system software is licensed under the GPL and the application running atop the OS is commercially licensed.

Moderately restrictive licensesModerately restrictive licenses,

such as the LGPL, can also have a

In most cases, license restrictions are only applicable or relevant if a company will be providing copies of the OSS to third parties.

because OSS authors can choose any license or create their own. However, the majority of all OSS modules and applications available today typically use one of the more common OSS licenses.

In most cases, license restrictions are only applicable or relevant if a company will be providing copies of the OSS to third parties. With the notable exception of the Affero variant of the GNU General Public License (GPL), generally the restric-tions aren’t applicable or relevant when the company is only using the OSS internally, which includes hosting the OSS in a software as a service arrangement for customers or using it to operate a customer-facing website.

Restrictive licensesCertain OSS licenses, such as the

GPL, are considered “viral” because they generally require that proprie-tary software that’s distributed with OSS must be licensed under terms consistent with the OSS license—hence, like a virus, the license terms are passed on to other software.

Proprietary code distributed with or alongside GPL-licensed OSS as part of a larger program or applica-tion can in many cases be deemed a “covered work” along with the OSS. This means that the entire covered work—the proprietary code and OSS—can only be distributed under the GPL license terms, including on the condition that the source code to the entire combined program (includ-ing the developer’s proprietary code) be made available to recipients.

In contrast, under the GNU Lesser General Public License (LGPL) and other moderately restrictive licenses, distributing the OSS in separate source code and executable files such as dynamic link libraries (DLLs) that only dynamically link to the propri-etary code at runtime can prevent the proprietary code distributed along-side the OSS from becoming “covered work” under the GPL.

viral effect, treating proprietary code as part of the work covered by the OSS license, depending upon the manner and form in which the OSS is used with the proprietary code. For example, if OSS licensed under the LGPL is statically linked to a proprietary software program—for example, a program that forms an .exe file out of both the OSS and proprietary code—and is then distributed to customers or third parties, compliance with the LGPL would effectively require providing to the recipient the source code to the entire executable—including the proprietary code.

On the other hand, distribution of the same LGPL-licensed OSS with proprietary software when the OSS is distributed as a stand-alone DLL that the executable dynamically links to at runtime is possible under the terms of the LGPL without requiring distri-bution of the proprietary software’s source code.

Permissive licensesPermissive l icenses impose

few, if any, restrictions. In general, restrictions aren’t considered to be burdensome, such as a requirement that certain copyright ownership and attribution notices be included with the distributed files. Examples of permissive software licenses include the MIT License, the Apache License, and the Berkeley Software Distribu-tion License.

LIABILITY FOR FAILURE TO COMPLY WITH LICENSE TERMS

OSS authors, often assisted by organizations formed to advance the enforcement of OSS licensing terms, have been increasingly active in enforcing licenses. In other cases, commercial software companies that make a less functional or older version of their proprietary soft-ware available under OSS licenses actively seek to enforce the terms of the OSS license to ensure that users

JUNE 2012 11

O SS is a great resource and option for companies that want to supplement and extend the

capabilities of their existing soft-ware or hardware products. Using OSS can allow companies to focus internal development work on core proprietary functionality. However, as with any third-party software that a company wants to embed or include with its own proprietary software, it’s important to first understand and carefully consider the applicable OSS license terms.

Brian M. Gaff is a senior member of IEEE and a partner at the Edwards Wildman Palmer LLP law firm. Con-tact him at bgaff@edwardswildman.com.

Gregory J. Ploussios is a partner at Edwards Wildman Palmer and co-chair of the firm’s Technology Practice Group. Contact him at gploussios@edwardswildman.com.

purchase commercial licenses when appropriate. It’s important to note that only the owners of the OSS and agents acting on their behalf have the right to assert a claim against a user of the OSS for violating the terms of the license or infringing the copyright.

In the case where, for example, a company distributes a program com-bining its proprietary software and GPL-licensed OSS and the company doesn’t provide the source code to its proprietary software (or for that matter license it under the GPL) to its customers, legal action against the company could take the form of a copyright infringement claim or a breach of contract claim, with the most likely remedies being

• an injunction that prohibits further sale or license of the combined software and requires cessation of use of the software by the company and its custom-ers (until the OSS is removed);

• impoundment and destruction of the combined software;

• monetary damages in the form of direct damages (often measured as the copyright holder’s lost profits or the price that someone would have been willing to pay) and, if the copyright of the OSS was registered, statutory damages; and

• attorney’s fees if the copyright to the OSS was registered and the infringement is determined to have been willful.

However, a court order forcing the company to “open source” its com-mercial software to comply with the terms of the GPL isn’t a realistic out-come or liability in this example—or any readily imaginable example. This type of court order generally isn’t available for these types of claims, especially when other remedies, such as monetary damages and orders preventing future distribution, are adequate.

Selected CS articles and columns are available for free at http:// ComputingNow.computer.org.

The content of this article is intended to provide accurate and authoritative informa-tion with regard to the subject matter covered. It is offered with the understanding that neither IEEE nor the IEEE Com-puter Society is engaged in rendering legal, accounting, or other professional services or advice. If legal advice or other expert assistance is required, the services of a competent professional person should be sought.

Register today! http://compsac.cs.iastate.edu/

16-20 July 2012

Izmir, Turkey

IEEE COMPSAC 2012 36th IEEE International Computer Software and Applications Conference