1. technology and computing
2. software

OPEN SOURCE ISSUES IN BUSINESS
By
Cestjon McFarland
Holly Towle1
I.
INTRODUCTION
Open source software presents issues of increasing significance for businesses. If you are not
already familiar with these issues and your business is using or considering the use of open source
software, it’s time to take note. This article analyzes considerations that businesses should keep in
mind when deciding whether to use this type of software. As with any licensed technology, open
source is governed by the terms of the open source license. Actively copying, modifying, developing
products with, or distributing open source software without understanding those terms can jeopardize a
company’s business endeavors. On the other hand, businesses that take the time to research and
investigate open source licensing models and that are familiar with the issues described in this article
are more likely to be successful in deciding whether and when to use open source.
II.
TWO HYPOTHETICAL SCENARIOS
It’s helpful to ground this discussion in a specific context. Consider the following scenarios:
SCENARIO #1, CODE DEVELOPMENT FOR DISTRIBUTION: Your business is developing a proprietary
software program with high hopes of profitable distribution. Your market edge resides in the
features and functionality that your skilled developers have included in this program, and you
protect your source code from disclosure to unauthorized third parties. But one of your
employees (or an independent contractor working with your development team) included a
small piece of open source code in your product. Or perhaps the code was introduced when
your company merged with another business, and an acquired product was merged into the
original product code base; open source issues weren’t flagged in the acquisition due
diligence process.
SCENARIO #2, INTERNAL USE: You have based your company’s internal operations on open
source software. Your company is not in the software business, you don’t plan to distribute
software, and therefore you don’t care that your open source license requires you to share with
others any adaptations and improvements you make to the source code. You just like the
program. Then you get a notice of infringement – the letter says you must stop using the open
source software because your use violates the rights of one of perhaps several hundred
Cestjon McFarland and Holly Towle are partners in the Technology and Intellectual Property practice group of
Preston Gates & Ellis, LLP, a national law firm (http://www.PrestonGates.com). They are located in the firm’s Seattle
office. Holly is the author of The Law of Electronic Commercial Transactions (2003, A.S. Pratt & Sons). This article
was prepared with assistance from Shankar Narayan, an associate at Preston Gates & Ellis, LLP, and Eric Keppler, an
attorney at Lee & Hayes, pllc.
1
1
developers who contributed to the program. You have to defend the suit and stop using the
software.
As you read through the following sections, you will find that the terms of your open source license
would affect your fate in both scenarios.
III.
BACKGROUND ON OPEN SOURCE
A.
WHAT IS OPEN SOURCE SOFTWARE AND WHERE DID IT COME FROM?
The open source software movement had its origins at the MIT Artificial Intelligence
Laboratory. In the early 1970s, when the source code for most computer software was readily
available, the lab’s programmers were free to refine it for their own purposes. As software increasingly
came to be distributed on a proprietary basis in the early 1980s, a programmer named Richard
Stallman became frustrated with his inability to collaborate with his colleagues on refining proprietary
operating system code. This frustration was the genesis of the “GNU Project” (GNU rhymes with “new,”
but is preceded by a hard “g”). The GNU Project’s mission was to create a non-proprietary UNIX-like
operating system, GNU being a recursive acronym for “GNU’s Not Unix.”i Stallman implemented this
project under the auspices of the Free Software Foundation, which he formed in 1985.ii
Somewhat fortuitously, while Stallman and others at the GNU Project focused on the
development of high-level operating system functions for GNU, a young Finnish programmer named
Linus Torvalds decided to create his own alternative to the Unix operating system.iii Torvalds started
with the low-level functions performed by an operating system. These are known as the “kernel.” He
released his original “Linux” program code in 1991 over the Internet, and encouraged other
programmers to modify and enhance it. Torvalds and the GNU Project team then discovered each
other, and by the mid-1990s had combined the high-level functions produced by GNU and Torvald’s
kernel to form a single operating system known as Linux.iv
Linux was released under an open source license crafted by Stallman called the General
Public License or “GPL.” The GPL was designed so that any enhancements or improvements to
software licensed under the GPL would also be made openly available in source code format, thereby
allowing for development of an ever-expanding common code base that, via the GPL terms, could be
improved-upon by programmers around the world. Ironically, while Stallman abhorred the protectionist
rights imbued upon copyright and other intellectual property right owners, the GPL relies on those very
rights to “free” the software; that is, to require anyone who modifies and distributes GPL software to
grant others the same rights in those modifications as the user received to the original code under the
GPL.v The Free Software Foundation characterizes this as a form of liberation for programmers, as
follows:
[Open source restrictions help] programmers who want to contribute improvements to free
software get permission to do that. These programmers often work for companies or
universities that would do almost anything to get more money. A programmer may want to
contribute her changes to the community, but her employer may want to turn the changes into
a proprietary software product.
2
When we explain to the employer that it is illegal to distribute the improved version except as
free software, the employer usually decides to release it as free software rather than throw it
away.vi
The other common terminology used in reference to open source software is that it is “copyleft” rather
than “copyright.” This term was inspired by a message scribbled on the outside of an envelope sent to
Stallman in the mid-1980’s: “Copyleft—all rights reversed.”vii
B.
OPEN SOURCE SOFTWARE IS OFTEN CALLED FREE SOFTWARE – IS IT REALLY?
In this context, “free” doesn’t necessarily mean at no charge. It does mean that the source
code must be “open” for viewing. Many companies offering open source software derive revenue either
by charging for the copy or related services:
The intention was that nobody would have to pay for *permission* to use the GNU system .
. . I have learned to distinguish carefully between “free” in the sense of freedom and “free”
in the sense of price. Free software is software that users have the freedom to distribute
and change. Some users may obtain copies at no charge, while others pay to obtain
copies--and if the funds help support improving the software, so much the better. The
important thing is that everyone who has a copy has the freedom to cooperate with others
in using it.viii
The GNU web site offers this clarification: “think free as in ‘free speech,’ not as in ‘free beer.’”ix Thus,
the GPL permits charging a fee “for the physical act of transferring a copy” of the open source software,
or for offering warranty protection.x But any work that contains or is derived from the open source
software must be “licensed . . . at no charge.”xi In short, under the GPL some fees may be imposed
subject to restrictions which need to be parsed.
C. HOW MANY TYPES OF OPEN SOURCE SOFTWARE ARE THERE?
The growth of the Internet in the 1990s made “free software” an increasingly attractive model
for developing and distributing software. One challenge posed by this model, however, was enticing
proprietary software vendors to use open source products. To fill the needs of developers interested in
providing open source software for the commercial market, variations of the open source model started
to appear. This ultimately exposed some tensions within the free software community. Inspired by
Netscape’s announcement in early 1998 that it planned to release the source code for its flagship
Netscape Navigator internet browser, a group of Linux developers and other free software enthusiasts
formed the “Open Source Initiative” (OSI) with the goal of making “free software” more commercially
viable. As described on the OSI Web site:
[w]e realized it was time to dump the confrontational attitude that has been associated with
‘free software’ in the past and sell the idea strictly on the same pragmatic, business-case
grounds that motivated Netscape. We brainstormed about tactics and a new label. ”Open
source,” contributed by Chris Peterson, was the best thing we came up with.xii
Though they share a number of goals, the missions of the “free software” camp represented by
Richard Stallman and the Free Software Foundation, and the “open source” camp represented by OSI,
Linus Torvalds, and the various commercial heavyweights who have thrown their support behind Linux,
are different. The Free Software Foundation remains antagonistic toward all forms of proprietary or
“restricted source” software, while the OSI accommodates certain combined open source and
proprietary software development through less restrictive open source license terms. Specifically, OSI
3
developed a certification scheme under which software licenses satisfying the OSI criteria would be
entitled to use the label “OSI Certified Open Source Software.”xiii
There are now many different software programs distributed under the GPL, as well as other
forms of open source licenses.xiv Over fifty licenses currently qualify for OSI certification.xv Even NASA
has developed its own open source license, the NASA Open Source Agreement or “NASA NOSA” (also
recently qualifying for OSI certification), raising interesting issues given that NASA, as a part of the
federal government, does not have a copyright in software developed by its own employees.xvi
In summary, motivations for open source licensing vary, as do the licenses themselves. It is
simplistic and incorrect to assume that all “open source” software licenses are the same. The
differences can have significant consequences for developers and users of the software.
IV.
ANALYZING OPEN SOURCE LICENSES
A.
NOT?
WHY SHOULD A BUSINESS CARE IF THE SOFTWARE IT LICENSES IS OPEN SOURCE OR
As with all software, the license is the key for businesses seeking to use open source software.
Software is protected by copyright and other intellectual property laws which, among other things, allow
the owner to limit a user’s ability to copy, modify or distribute the software. The details regarding what
is or is not permitted are specified in the license. Some open source licenses require users who
combine open source code with their otherwise proprietary software, to make the source code for the
whole product entirely open. That is why some speak of open source software as infecting other code,
or as being “viral.” If a company’s business plan depends upon keeping its code confidential, such a
result would clearly pose a problem. Whether open source software is “better” or “worse” than other
software depends on many factors, both technical and legal, and the user’s ultimate goals. It’s
important to understand these license terms, however, to avoid potentially unpleasant surprises.
B.
WHAT ARE SOME OF THE DIFFERENT TYPES OF OPEN SOURCE LICENSES?
As noted above, there are numerous variations on the open source license theme, making it
impossible to discuss each one in this article. Some of the particularly prominent licenses include, in
addition to the GPL, the Lesser General Public License or “LGPL,” the Berkeley Software Distribution
License or “BSD,” and the Mozilla Public License or “MPL.” This section describes the OSI criteria
mentioned above and some of the salient license terms in the GPL, LGPL, BSD, and MPL, to give the
reader a flavor for some of the variations that one might expect among open source licenses. While by
no means exhaustive, the discussion will help outline the types of issues businesses should consider
when assessing whether to enter into such a license.
1.
THE OSI DEFINITION.
OSI’s definition of an “open source” software license includes a series of ten minimum
requirements that must be satisfied to qualify for the “OSI Certified” label. These requirements are
intended to be flexible enough to embrace a variety of open source licensing models. The OSI
requirements are as follows:
4
(a) Free redistribution. The license can’t prohibit anyone from selling or giving the licensed
software away as part of an aggregated software program containing code from other sources,
nor can the license require a royalty or fee for such a sale.
(b) Source code. The licensed software has to include source code, and the license must
allow distribution in source and binary format. If a version of a product is distributed only in
binary format, then there must be a well-publicized means for obtaining the source code for no
more than a reasonable reproduction cost (preferably, downloading via the Internet without
charge). The source code must be in the preferred form for modification by a programmer.
(c) Derived works. The license must allow the creation of modifications and derivative works,
and must allow any such modifications or derivative works to be distributed under the same
terms as the license for the original software.
(d) Integrity of the Author’s Source Code. A license may require that the base source code
be distributed unmodified, and that any modifications be provided in the form of "patch files"
with the base source code, for the purpose of modifying the program at build time. The license
must explicitly permit distribution of software built from modified source code. The license may
require derived works to carry a different name or version number from the original software.
(e) No discrimination against person or groups. Nothing in the license should discriminate
against any person or group of persons.
(f) No discrimination against fields of endeavor. The license must not restrict anyone from
making use of the program in a specific field of endeavor (such as in a business or for genetic
research).
(g) Distribution of license. The rights attached to the program must apply to all to whom the
program is redistributed without the need for execution of an additional license by those parties
(such as a non-disclosure agreement).
(h) License must not be specific to a product. The rights attached to the program must not
depend on the program's being part of a particular software distribution. All parties to whom
the program is redistributed should have the same rights as those that are granted in
conjunction with the original software distribution.
(i) License must not restrict other software. The license must not place restrictions on
other software that is distributed along with the licensed software. For example, the license
must not insist that all other programs distributed on the same medium be open-source
software.
(j) License must be technology-neutral. Nothing in the license may be conditioned or based
on any individual technology or style of interface. xvii
The first three criteria articulate the open source fundamentals:
•
there can be no prohibitions on distribution, and no fee should be charged for distribution
(though a fee could be charged for support);xviii
•
the source code must be made available; and
•
modification of the source must be permitted (along with distribution of those modifications).
5
The remaining OSI criteria primarily emphasize another fundamental, which is that open source
licenses should otherwise be as unrestrictive as possible as to certain items—no limitation by user, type
of use, type of software distribution, or technology. There is also an express requirement that open
source and proprietary software must be able to co-exist on the same medium, without having the open
source infect the companion proprietary code. Each of the licenses discussed below qualifies as an
OSI Certified license.
2.
THE GPL
The GPL, reflecting its heritage in the free software camp, is the most extreme of the major
open source licenses in its rejection of some typical proprietary software license terms. For example,
simple use of GPL software is outside the scope of the GPL license: “[t]he act of running the Program
is not restricted…..”xix The acts of copying, distributing and/or modifying the Program, however, do fall
within the scope of the GPL provisions and can have significant consequences.
Unlike many other open source licenses, the GPL requires that, when proprietary code is
combined with GPL code, the entire combined work must be distributed under the GPL: “You must
cause any work that you distribute or publish, that in whole or in part contains or is derived from the
Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms
of this license.”xx
The term “Program” is defined to include the GPL program itself and any “work based on the
Program,” with the latter being “the Program or any derivative work under copyright law: that is to say, a
work containing the Program or a portion of it….”xxi The GPL further provides that the distribution
requirement applies to the modified work “as a whole:”
If identifiable sections of that work are not derived from the Program, and can be reasonably
considered independent and separate works in themselves, then this License, and its terms,
do not apply to those sections when you distribute them as separate works. But when you
distribute those same sections as part of a whole which is a work based on the Program, the
distribution of the whole must be on the terms of this License, whose permissions for other
licensees extend to the entire whole, and thus to each and every part regardless of who wrote
it.xxii
Although the GPL clarifies that merely shipping proprietary source code and GPL code on the same
storage medium would not bring the proprietary source code within the scope of the GPL’s terms,xxiii the
precise amount of integration or combination which would make the proprietary source code part of a
“work based on the Program” is not expressly outlined under the GPL.
If, therefore, a proprietary software company wishes to combine GPL code with its proprietary
source code, the company may only distribute the combined work under the terms of the GPL. Since
this would normally be an unacceptable result for a proprietary software company, the practical effect of
these GPL provisions is to preclude a proprietary software company from intentionally combining GPL
code and proprietary source code into one software product.
Proprietary software companies that are aware of the GPL terms are likely to be cautious
about avoiding such combinations. It’s possible, however, for this to happen inadvertently.
A
proprietary software company faces potential GPL “taint” whenever there is an opportunity to introduce
GPL code into its proprietary source code distribution line. Significantly, the GPL contains provisions to
address cases where GPL code is distributed without notice that the GPL is applicable to the open
6
source code (as required by Section 1),xxiv which would be the case where GPL code is inadvertently
incorporated into or combined with proprietary source code. The GPL provides: “[e]ach time you
redistribute the Program (or any work based on the Program), the recipient automatically receives a
license from the original licensor to copy, distribute or modify the Program subject to these terms and
conditions. You may not impose any further restrictions on the recipients’ exercise of the rights granted
herein.”xxv
In a situation, therefore, where an independent contractor or value-added reseller combines
some GPL code with a proprietary software company’s code, and that combined code is distributed
without the proprietary software company’s knowledge that GPL code has been introduced into its
product, the creators of the GPL would likely claim that the company has lost the right to impose its
proprietary restrictions on its code base. There are obvious issues under contract formation, agency
and other legal doctrines that would be raised by any such assertion, but this illustrates the kinds of
tensions that can arise under the GPL.
The increasing use of open source development tools can heighten the risk of inadvertent
inclusion of GPL code into proprietary source code. Can a development tool available pursuant to a
GPL license be used to create untainted proprietary source code? The GPL provides that “[t]he act of
running the Program is not restricted, and the output from the Program is [subject to the terms of the
GPL] only if its contents constitute a work based on the Program (independent of having been made by
running the Program). Whether that is true depends on what the Program does.”xxvi This suggests that
GPL development tools may be used to generate proprietary source code, but companies must
carefully assess the functionality of the tool and whether the output is likely to qualify as a “work based
on the Program.”
3.
THE LGPL
The GNU Lesser General Public License or “LGPL” (and its predecessor, the GNU Library
Public License) was an early concession by the Free Software Foundation to the need for flexibility in
bridging the gap between the open source and the proprietary software models, but in the limited
context of software libraries. This license was designed to permit developers to link such libraries into
non-open source programs. The reason for creating this “lesser” GPL is explained in the license itself:
[O]n rare occasions, there may be a special need to encourage the widest possible use of a
certain library, so that it becomes a de-facto standard. To achieve this, non-free programs
must be allowed to use the library. A more frequent case is that a free library does the same
job as widely used non-free libraries. In this case there is little to gain by limiting the free
library to free software only. . . In other cases, permission to use a particular library in non-free
programs enables a greater number of people to use a large body of free software.xxvii
The LGPL provides that any licensee can distribute the relevant software library, as received, in source
code format (and object code, though the source must accompany any binary codexxviii), as long as
proper copyright notices and warranty disclaimers, as well as a copy of the LGPL license, are provided
with the code.xxix Distribution requirements governing modifications to the software library depend upon
how the library is linked to the non-open source program.
(a) Works Based on the Library. The LGPL distinguishes between “works based on the
library,” which it describes as work containing code derived from the library, and “works that use the
library,” which it describes as works that do not include any derivative of the LGPL library but are
7
designed to work with the LGPL library by being compiled or linked with it.xxx The LGPL licensee may
distribute the former category of works (i.e., works containing code derived from the library) only if (i)
the modified work is also a software library, (ii) the modified files contain prominent notices of such
modification and the dates thereof, (iii) the whole work is licensed under the LGPL at no charge, and
(iv) the licensee makes a good faith effort to ensure that the library, as modified, is able to
independently perform functions that are to be supplied by an application program, should the
application fail to do so.xxxi The modified work may be distributed in object code only if it is also
accompanied by the source code.xxxii
(b) Works That Use the Library. Works that use an LGPL library fall outside the scope of the
LGPL, when distributed in isolation.xxxiii If, however, such a work links to the library in a manner that,
when compiled, the executable contains a portion of the library, then the LGPL licensee can distribute
that work under license terms of the licensee’s choice provided that the license must allow “modification
of the work for the customer’s own use and reverse engineering for debugging such modification.”xxxiv
Further, the licensee in that case must (i) satisfy specific notice requirements designed to inform
downstream licensees that the LGPL library is covered by the LGPL, and (ii) take certain steps to
ensure that downstream licensees have access to source code for the library (and any modifications
thereto) or to a suitable shared library mechanism for linking to the library.xxxv
Tracking the requirements of the LGPL to ascertain when the licensee must distribute source code for
its own work under the LGPL terms, requires precise knowledge of the manner in which the LGPL
libraries will be used and careful navigation of the LGPL terms.
4.
A MORE PERMISSIVE APPROACH: BSD-STYLE LICENSES.
The Berkeley Software Distribution or “BSD” style license is a more permissive alternative to
the GPL, and represents one of the less restrictive licenses to obtain OSI certification. It is quite brief,
with the license terms reading as follows:
Redistribution and use in source and binary forms, with or without modification, are permitted
provided that the following conditions are met:
•
Redistributions of source code must retain the above copyright notice, this list of conditions
and the following disclaimer.
•
Redistributions in binary form must reproduce the above copyright notice, this list of conditions
and the following disclaimer in the documentation and/or other materials provided with the
distribution.
•
Neither the name of the <ORGANIZATION> nor the names of its contributors may be used to
endorse or promote products derived from this software without specific prior written
permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
8
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. xxxvi
Unlike the GPL, the BSD License does not expressly require that the entire work into which BSD code
is combined be distributed in source code form. At the www.mozilla.org Web site, the BSD is described
as follows:
It is very non-restrictive in its terms, basically allowing anyone to do anything with code
covered by the license, but requiring a reference to the copyright holder in accompanying
documentation -- essentially requiring only credit where credit is due. This makes the license
acceptable to commercial developers, but opens others to the possibility that their work may
be incorporated into products that may be proprietary to someone else.xxxvii
5.
MIDDLE GROUND: THE MOZILLA PUBLIC LICENSE
The MPL is notably different from its apparent namesake, the GPL. Most significantly, the
MPL outlines mechanisms for combining proprietary software with open source code without “tainting”
the proprietary software. The MPL also specifically parses copyright and patent rights granted under
the license, and contains a defensive suspension mechanism for terminating MPL license rights as to a
given licensee should that licensee bring patent infringement claims against upstream MPL developers.
(a) Segregation by File. Similar in concept to the GPL, the MPL requires each person or
entity that seeks to modify the MPL code to grant others a “world-wide, royalty-free, non-exclusive
license . . . to use, reproduce, modify, display, perform, sublicense and distribute the Modifications
created by” that person or entity.xxxviii “Modifications” include any additions or deletions from the original
MPL code received by the contributor, but the MPL goes on to clarify that:
When Covered Code is released as a series of files, a Modification is:
A. Any addition to or deletion from the contents of a file containing Original Code or previous
Modifications.
B. Any new file that contains any part of the Original Code or previous Modifications.xxxix
“Covered Code” is the original MPL code and any “Modification,” and “Original Code” is the original
source code first put out under a given MPL license. Unlike the GPL, therefore, the MPL allows
proprietary software companies to protect their proprietary code from being subjected to open source
license terms by putting it in files separate from any MPL or modified MPL code. To the extent,
however, that MPL code (modified or unmodified) is included in the same file as proprietary software,
then the MPL provisions have a similar viral effect on the proprietary software as the GPL.
(b) Patent License and Defensive Suspension. The MPL also expressly delineates the
copyright and patent licenses, providing that “Contributors” to the MPL code base (i.e., each entity that
develops Modifications) grant a world-wide, royalty-free, non-exclusive license under their patents to
make use, sell, offer for sale, have made and/or otherwise dispose of not only the “Modifications” made
by that Contributor, but also the combination of Modifications made by that Contributor with “its
Contributor Version.”xl The “Contributor Version” is defined as the combination of the original code
placed under the MPL license, “prior Modifications used by a Contributor, and the Modifications made
by that particular Contributor.”xli Each Contributor, therefore, grants a combination license for
9
combinations of the original MPL code with any Modifications that Contributor has used (previously) or
developed.
The MPL also includes a section on termination, providing that the license can be terminated
automatically for a breach of the license terms and failure to cure within 30 days of becoming aware of
such breach. The license may also terminate if the licensee commences patent infringement litigation
against the initial MPL code developer or any subsequent Contributor, asserting that either (a) the initial
MPL code developer’s or any Contributor’s contribution directly or indirectly infringes a licensee patent,
or (b) any other software, hardware or other device of the MPL code developer or Contributor (as the
case may be) directly or indirectly infringes a licensee patent.xlii Such a provision seeks to avoid the
scenario where a licensee of the “free” open source software would continue to get the benefit of the
license while asserting patent claims against those who have contributed to the MPL code base. The
reach of this defensive suspension clause, however, is quite broad, covering patent infringement claims
that are related as well as unrelated to the MPL code. Potential MPL licensees, therefore, must
consider the implications that would arise should they find themselves facing patent infringement by
other MPL contributors after the licensee has developed products using MPL code.
C.
HOW CAN OPEN SOURCE SOFTWARE AFFECT A COMPANY THAT ONLY USES IT
INTERNALLY, TO RUN THE BUSINESS?
Companies that modify or distribute open source software, even if only for their internal
business operations (e.g., customization of code for their particular systems or distribution to their
subsidiaries) may be exposed to a copyright infringement action by a party claiming that their software
was introduced into the open source code base without proper authorization. Patent infringement
claims are a similar risk, especially given that the scope of patent rights obtained under a given open
source license can be more limited than a user might expect. For example, the MPL does not require
developers of the initial MPL code to grant a patent license for the combination of their original code
with other software—rather, the combination patent license applies only to subsequent licensees who
modify the original code.xliii
Of course, claims of infringement can happen with any software. One difference with open
source, however, is that the license and development scheme embodies an informal permission and
submission structure that arguably enhances the risk of such claims. One commentator, in fact, has
characterized the Linux kernel code base as “legally radioactive” given the loose manner in which
Torvalds allowed contributors to add to the code base without tracking whether the contributors had
appropriate rights in their submittals.xliv
Perhaps not surprisingly, Linux code is the subject of a prominent lawsuit filed in March 2003
by the SCO Group against IBM Corporation. The SCO Group alleges that IBM violated SCO’s rights by
incorporating pieces of SCO’s proprietary UNIX operating system into the Linux operating system, and
by inducing and encouraging third parties to misappropriate SCO’s proprietary software.xlv IBM, for its
part, contends that SCO has not only failed to allege with specificity the manner in which IBM has
misappropriated the UNIX software, but flatly denies any misappropriation or violation of any
agreement.xlvi IBM has also struck back with counterclaims alleging that it is, in fact, SCO that is
infringing on IBM’s contributions to the Linux platform, as well as violating several of IBM’s UNIXrelated patents.xlvii The case is scheduled to go to trial in November, 2005. In a parallel development,
SCO has become increasingly vocal about its intent to pursue litigation against Linux end users. In
January of 2004, SCO announced on its website its intent to “expand its relationship” with a law firm for
10
the purpose of suing end users of Linux,xlviii and in March of 2004, SCO sued Autozone, Inc., and
DaimlerChrysler Corporation, both Linux end users.xlix The SCO lawsuits reinforce the notion that open
source users should be aware of litigation risks that may be associated with use of a given open source
program.
D.
ARE OPEN SOURCE LICENSES ENFORCEABLE?
Whether a given open source license is enforceable depends on whether contract law
requirements are satisfied, e.g., has each licensee developer ensured that the next transferee agreed
to be bound by the open source license? Where open source code is casually distributed from one
user to the next, scenarios may arise where a user may not know about the license or fails to
intentionally engage in conduct sufficient to pass muster as legal assent. There are many ways to
consent to a contract in modern commerce and there’s nothing about open source that alters those
choices – the problem is in tracking whether they have been used. Failure to obtain proper consent to
the license terms at any point along the open source development chain creates problems everywhere
below the weak link. Contracts can also be formed by trade usage – but this raises issues regarding
whether a licensee was aware of that usage, what the terms of the usage are, and whether the licensee
can be bound by a contract it did not realize it had made.
According to a recent article,l a German court enforced the GPL against a developer who had
incorporated certain code subject to the GPL into the developer’s own program, without abiding by the
GPL terms.li The court noted, according to the article, that rights flow from licenses and deficiencies in
complying with the license requirements can result in a lack of rights:
The right to use the software is lost if the user violates the license requirements, the court held,
and in such case the rights revert entirely to the author of the license. Even if it had found the
GPL invalid, the court added, [the licensee] would still have no privilege of use because if the
license is invalid, then [the licensee] has not received any rights to make use.lii
To complicate the enforceability issue, some open source “licensors” adopt the legal position
that their “licenses” are not contracts at all and that, therefore, contract law can be ignored. Under this
view, open source terms are merely a notice given by the copyright owner of what can or cannot be
done – a user who ignores the notice will not breach a contract, but will be subject to an infringement
action.liii
E.
WHY NOT JUST GET PERMISSION FROM SOMEONE IN AUTHORITY?
That’s easier said than done. Take a children’s story: many people have intellectual property
rights in it, including the illustrator, the author and the publisher. Now make the story a software
product and add music, sound effects, code allowing different endings, film clips and much more. All of
those creators have intellectual property rights too. In a proprietary product, the publisher would
typically obtain appropriate rights from the owners or authorized licensors of each of those components.
Open source software is similarly comprised of contributions from many different sources, and there
may be hundreds of creators, rather than dozens. Further, in many cases these various contributions
will have been submitted over a significant span of time. Identifying all the relevant parties may be
difficult, and even where they can be identified, tracking them down could be quite costly.
11
F.
HOW DO I GET MY DEVELOPERS OR IT STAFF TO THINK ABOUT THESE ISSUES?
What a company communicates to its developers or information technology staff regarding
open source software depends on the nature of that company’s business, the purpose the software is
to fulfill, and the license governing the software. For example, if development is purely for internal
systems and not for software that goes into commercial products, then the issues raised by open
source software may focus on infringement risk and costs of support. These concerns would be
balanced against the uniqueness of the software in fulfilling the identified operational need. If, on the
other hand, the company distributes proprietary software, then the company must take steps to ensure
that its developers do not jeopardize their proprietary distribution by inadvertently introducing open
source software into their products.
With respect to development, ideally the legal department and company programmers will
work together in formulating a company open source policy. Such a policy should be based on the
particular needs and business model of that company, and should include a practical methodology for
promptly addressing open source issues as they arise, whether that be through a single contact
person, intranet guidelines and other documentation, or more detailed authorization procedures. For
example, companies that distribute proprietary software products should have a streamlined process by
which their programmers can quickly assess the legal ramifications associated with using a particular
open source development tool or other open source software. The more knowledgeable the
programmers are about the legal issues, the better equipped they will be to assist in providing
information relevant to the legal analysis. In particular, they should understand that the legal analysis
depends on:
•
What the software is being used for and how (e.g., is it provided in source or object code form?
Will it be copied, modified or distributed, or merely “used”? If the programmer is linking to the
open source code, is it a static or dynamic link)?
•
Will the software be integrated in any way with company proprietary code?
•
What license(s) govern the software?
Another way in which open source can be introduced into a company is through an acquisition.
It is important for the acquiring entity to investigate during the due diligence phase whether the target
company uses any open source software. The acquiring entity should make sure that this inquiry is
posed directly to the target company’s programmers, because their response may be quite different
from that of the target company’s legal department (no big surprise, but it is not uncommon for the legal
department to be unaware of the use of open source code). Ultimately, the company should assess
open source issues revealed during due diligence in the context of the business goals for the
acquisition. For example, if the target company’s software product will be moth-balled following the
acquisition, then the incorporation of open source into that product may be less of an issue, though
there could be some liability exposure associated with pre-acquisition distribution of the product (e.g., in
a merger versus asset purchase scenario).
CONCLUSION
Circling back to the two hypothetical scenarios posited at the beginning of this article of a
company desiring to protect is proprietary software code and hoping to make a profitable distribution,
and a company that simply wants to use open source software for its internal operations: in each case,
12
the software may be “free” but free lunches usually come at some price and so does “free” or open
source software. Both companies need to learn more before consuming their free meal, and to
consider that various issues that we have discussed here.
http://www.gnu.org/gnu/gnu-history.html, “Overview of the GNU Project.”
See http://www.gnu.org/fsf/fsf.html, “Free Software Foundation.”
iii Parloff, Gunning for Linux, FORTUNE, May 17, 2004, at 94.
iv Id.
v See id.; see also http://www.gnu.org/copyleft/copyleft.html#WhatIsCopyleft.
vi See http://www.gnu.org/licenses/licenses.html#Intro, “What is CopyLeft?”
vii http://www.gnu.org/gnu/thegnuproject.html, “Copyleft and the GNU GPL.”
viii http://www.gnu.org/gnu/manifesto.html#f1 at Note 1.
ix http://www.gnu.org/philosophy/free-sw.html, “The Free Software Definition.”
x http://www.opensource.org/licenses/gpl-license.php, Section 1.
xi Id., Section 2(b).
xii http://www.opensource.org/docs/history.php.
xiii http://www.opensource.org/licenses/index.html, “The Approved Licenses.” OSI uses the certification mark “OSI
Certified” to signal that the underlying software license meets OSI’s fundamental requirements. Id. The term “open
source” alone is not necessarily determinative as to the true nature of a given license.
xiv See, http://opensource.org/licenses/index.html, “License Index,” for a list of over 50 open source licenses. See also
Mitre Corporation, Use of Free and Open-Source Software (FOSS) in the U.S. Department of Defense, Version 1.2,
October, 28, 2002, Appendix A for a list of approximately 115 different free and open source software applications
used by the U.S. Department of Defense, and Appendix B for a list of 40 different licenses associated with those
applications.
xv Id., “License Index.”
xvi Warnecke, NASA Will Become First Agency to Get OSI Certification of Open Source Agreement, ELECTRONIC
COMMERCE & LAW REPORT, March 31, 2004, at 304. The NASA NOSA is based in part on portions of the Mozilla Public
License, the GNU General Public License, and the IBM Public License. Because software created by the federal
government is not protected under U.S. Copyright law, NASA looks to contract rights to enforce the terms of the
license for such code. Id.
xvii http://www.opensource.org/docs/definition.php.
xviii See http://www.opensource.org/advocacy/faq.php, “How do I make money on software if I can’t sell my code?”
xix http://www.opensource.org/licenses/gpl-license.php, Section 0.
xx Id., Section 2(b), emphasis added.
xxi Id., Section 0.
xxii Id., Section 2, emphasis added.
xxiii See Id., Section 2: “mere aggregation of another work not based on the [open source program] with the [open
source program] . . . on a volume of a storage or distribution medium does not bring the other work under the scope of
this License.”
xxiv Id., Section 1.
xxv Id., Section 6.
xxvi Id., Section 0.
xxvii http://www.opensource.org/licenses/lgpl-license.php, Preamble.
xxviii Id., Section 4.
xxix Id., Section 1.
xxx Id., Preamble and Section 5.
xxxi Id., Section 2.
xxxii Id., Section 4.
xxxiii Id., Section 5.
xxxiv Id., Section 6.
xxxv Id.
xxxvi http://www.opensource.org/licenses/bsd-license.php.
xxxvii See http://www.mozilla.org/MPL/FAQ.html#5.
i
ii
13
Id, Section 2.2(a).
Id., Section 1.9.
xl Id., Section 2.2(b).
xli Id., Section 1.2.
xlii Id., Section 8.2.
xliii Id., Section 2.1(d). See also, Section 2.2(b).
xliv Parloff, Gunning for Linux, FORTUNE, May 17, 2004, at 94.
xlvhttp://www.caldera.com/ibmlawsuit/second_amended_complaint.pdf.
xlvi http://www.caldera.com/ibmlawsuit/20040329_ibm_2nd_amended_counterclaims.pdf.
xlvii Id.
xlviii http://ir.sco.com/ReleaseDetail.cfm?ReleaseID=126359, http://ir.sco.com/ReleaseDetail.cfm?ReleaseID=129996.
xlix http://ir.sco.com/ReleaseDetail.cfm?ReleaseID=129978.
l “German Court Recognizes Enforceability of GPL License Under German Copyright Law”, 9 Electronic Commerce &
Law, BNA Inc. 678 (8/4/04) (“BNA Article).
li Citing Welte v. Sitecom Deutschland GmbH, LG Muenchen, 21 O 6123/03 (5/19/04).
lii Id. BNA Article.
liii For a brief discussion of the tension this view creates regarding the legal difference between a “notice” and a
“contract,” see Holly Towle and Raymond Nimmer, The Law of Electronic Commercial Transactions at ¶ 8.03[2] (2003,
A.S. Pratt & Sons)
xxxviii
xxxix
14