OPEN SOURCE ISSUES IN BUSINESS
ByCestjon 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
1 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.
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.
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
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. WHY SHOULD A BUSINESS CARE IF THE SOFTWARE IT LICENSES IS OPEN SOURCE OR
NOT?
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:
(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
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
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
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
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
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 UNIX-related 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
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.
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,
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.
ihttp://www.gnu.org/gnu/gnu-history.html, “Overview of the GNU Project.” ii 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?” viihttp://www.gnu.org/gnu/thegnuproject.html, “Copyleft and the GNU GPL.” viiihttp://www.gnu.org/gnu/manifesto.html#f1 at Note 1.
ixhttp://www.gnu.org/philosophy/free-sw.html, “The Free Software Definition.” xhttp://www.opensource.org/licenses/gpl-license.php, Section 1.
xi Id., Section 2(b).
xiihttp://www.opensource.org/docs/history.php.
xiiihttp://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.
xviihttp://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?” xixhttp://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.
xxviihttp://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.
xxxvihttp://www.opensource.org/licenses/bsd-license.php. xxxvii See http://www.mozilla.org/MPL/FAQ.html#5.
xxxviii Id, Section 2.2(a).
xxxix 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.
xlviiihttp://ir.sco.com/ReleaseDetail.cfm?ReleaseID=126359, http://ir.sco.com/ReleaseDetail.cfm?ReleaseID=129996. xlixhttp://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)
