Discuss open sourcelicensing

Editor's Notes

• #2: Open source licenses apply mostly to open source software. The open source idea has some application to other copyrightable material. This presentation will discuss and explain open source software, focusing on licensing issues. The discussion will include an overview of the open source movement, a brief overview of copyright and patent law, a discussion of the application of the aforementioned bodies of law to open source software, a discussion of the open source principles, and the various types of licenses available, including a brief overview of some of the more popular open source licenses. It will also provide a brief overview of how people have applied the open source idea to material other than software, through efforts such as Creative Commons. This outline of the presentation is covered on the next slide.
• #3: This part of the presentation will give a very basic overview of open source software, including its history and philosophy, the Open Source Initiative and its Open Source Definition, and how open source projects operate.
• #4: Source: Kennedy at 2-5 (discussing basics of open source software). The specific obligations for a license to be open source is governed by the Open Source Definition. This presentation sets out and discusses the Open Source Definition later.
• #5: Source: http://www.gnu.org/philosophy/open-source-misses-the-point.html (discussing differences between free software and open source and why Stallman opposes the term open source); Kennedy at 11-12 (discussing the change in terminology from free to open source). Free software also has a home on the web, http://ww.gnu.org. Like the Open Source Definition, there us a Free Software Definition. To meet the Free Software Definition, users of the software must have “Freedom 0. The freedom to run the program, for any purpose. “Freedom 1. The freedom to study how the program works, and adapt it to your needs. Access to the source code is a precondition for this. “Freedom 2. The freedom to redistribute copies so youy can help your neighbor. “Freedom 3. The freedom to improve the program, and to release your improvements to the public, so that the whole community benefits. Access to the source code is a precondition of this. GNU philosophy, http://www.gnu.org/philosophy/free-sw.html. Richard Stallman and the Free Software Foundation people oppose the idea of open source, viewing it as a marketing gimmick for wary executives. According to them, free software is a movement, whereas open source is a development methodology. Stallman and the FSF people seem to have a vaguely religious attitude toward Free Software. See http://www.gnu.org/philosophy/open-source-misses-the-point.html (discussing differences between free software and open source and why Stallman opposes the term open source).
• #6: Source: Kennedy at 1; Rosen at 38.
• #7: Source: Rosen at 38
• #8: Source: Kennedy at 5-12 (discussing the history of open source); Rosen at 1-4; History of the OSI, http://www.opensource.org/history. There are three main stories in the open source world. One involves Richard Stallman and the efforts that led to the GPL. Another involves the University of California at Berkeley, the UNIX operating system, and the efforts that led to the creation of the BSD/Academic family of licenses. The third involves the production of major, commercial grade open source projects, and the widespread adoption of open source software, which eventually led to a corporate family of licenses suitable for use by commercial developers and best exemplified by the Mozilla Public License, or MPL. The first two stories began in the 1970s and 1980s; the third one began in the 1990s and continues into the present. I will consider the aforementioned three stories, as well as other related developments, below. Richard Stallman is a computer programmer who, in the 1970s, was working at the Massachusetts Institute of Technology Artificial Intelligence Lab. The culture there encouraged the sharing of source code among programmers, resulting in a community based approach to software development. As time went by, software began to become subject to more and more restrictive licenses, as programmers and others became increasingly concerned with intellectual property rights. Kennedy at 5-6. Stallman was dismayed by the increasingly proprietary nature of software. He believed that these developments would lead to a lack of innovation, incompatible programs, and other similar negative developments. In order to combat the proprietary trend in software, he developed the GNU General Public License, or GPL. The GPL allows licensees to distribute the software and modify it, and requires them make source code available when they distribute the software. Licensees also had to advise future licensees of their rights. Kennedy at 6-7. The rights associated with the GPL are intended to lead to a commons of publicly related software. The GPL is designed to do this by ensuring that once software becomes subject to that license, it, or derivatives of it, will never be proprietary again. Rosen at 103-5. This is the so-called “copyleft” provision (a play on words to contrast with copyright, and pehaps leftist politics. Rosen at 105. The copyleft provision has proven quite controversial, and may be the single largest obstacle to the use of open source software. Rosen at 103-5. Stallman also founded the Free Software Foundation (FSF) to promote what was then called free software, rather than the later name open source. The FSF developed software and then distributed it under the GPL. The idea was that software would be “free as in speech, not free as in beer” (I.e. open access to source code but people can charge for it). The FSF developed a large number of widely used programs. Kennedy at 7. In the 1970s, programmers at the University of California at Berkeley, including Bill Joy, were working with the UNIX operating system, which was originally developed by AT&T. Efforts of these programs led to a version of UNIX called the Berkeley Software Distribution of UNIX. To license the BSD UNIX program, Joy and others developed the BSD license. The BSD license is similar in a number of ways to the GPL, with the major difference being that it does not include the “copyleft” provisions of the GPL. In the 1990s, AT&T decided change its strategy with UNIX, leading to litigation over the inclusion of original portions of UNIX in the Berkeley programs. The BSD community replaced the UNIX code with original code to avoid this issue. Because of the absence of the copyleft provisions, the BSD license is popular with commercial software developers. Kennedy at 8-9. In the late 1990s, Netscape was developing an internet browser to compete with Microsoft’s Internet Explorer. Inspired in part by the essay The Cathedral and the Bazaar, by Eric S. Raymond (which discusses and contrasts two methods of software development, proprietary (the cathedral) and open source (the bazaar)), and by an inability to compete with Microsoft, Netscape decide to release the browser as an open source project. In conjunction with this, Netscape enlisted the aid of lawyers and drafted a new open source license, the Mozilla Public License (MPL), which dealt with certain concerns unique to Netscape’s commercial endeavor. Kennedy at 9-12. The MPL, due to its development in the commercial context, is more professionally drafted and deals with a number of issues that may be of concern to commercial developers more thoroughly than the BSD or GPL. It is perhaps that best, and first, example of a corporate open source license. See Rosen at 141-160 (discussing the MPL). One person involved with the drafting of the MPL, Bruce Perens, developed the open source definition as part of his efforts with the MPL. Perens also started the Open Source Initiative, to maintain the Open Source Definition and to approve licenses that are conformant with the Open Source Definition. Kennedy at 9-12. Perens derived the Open Source Definition from the Debian Free Software Guidelines. Rosen at 3. The Open Source Definition is the subject of the next several slides. Also, since the 1990s, open source software has been involved in a number of large, commercial grade software development projects. Perhaps the most famous is Linux, which was started by the Finnish computer scientist Linus Torvalds (the name is a combination of Linus and UNIX). Also important are the Web server Apache, BIND, which allows web addresses to be displayed in English. Kennedy at 10-12. Another important development is the term open source. When Stallman began the movement, he referred to free software. The term made many commercial developers apprehensive. In order to allay the fears of commercial developers, the community has generally changed to using the term open source software, as opposed to free software, though the latter term is still used occasionally. Kennedy at 12. Some use both terms at the same time. The next section will consider the Open Source Definition.
• #9: Source: Kennedy at 11-12; History of the OSI, http://www.opensource.org/history. The previous slide and its notes discussed the history of the OSI more thoroughly. The next slide’s notes discusses its relationship with the Free Software Foundation. The next several slides and their notes set out and discuss the OSD. As mentioned earlier, the Free Software Foundation also has a definition, but for Free Software rather than Open Source. Like the OSI, the FSF maintains a list of licenses that are compatible with its definition. See http://www.gnu.org/licenses/license-list.html#PythonOld
• #10: Source: http:www.opensource.org/docs.definition.php. The open source definition is maintained by the Open Source Initiative, and can be found at that organization’s website, http:www.opensource.org/docs/osd. According to scholar Dennis Kennedy, the open source definition embodies three principles, “free distribution, readily available source code, and the right to make derivative works.” Kennedy at 12. The Open Source Initiative website discusses the principles, as does Robert W. Gomulkiewicz, How Copyleft Uses Licenses to Succeed in the Open Source Software Revolution and the Implications for Articles 2B, 36 Hous. L. Rev. 179 (1999) [hereinafter Gomulkiewicz]. This slide, as well as the following slides will discuss the principles as well, mostly based on the aforementioned sources. The Open Source Initiative functions as the de facto standards body of open source licenses, maintaining the criteria for a license to be considered open source, and approving licenses as open source licenses. The Free Software Foundation was the original body dedicated to what was then called free software, but, as is evident from the widespread use of the term open source, the FSF seems to have been largely been eclipsed by the OSI, at least as a standards setting body. Condition one protects the right to sell for gratis or for a fee. As freedom refers to access rather than price, there is no contradiction between selling software and free software. See Rosen at 3 (discussing in what way open source software is free). According to Richard Stallman, free software is “free as in speech, not free as in beer.” Kennedy at 3. “Why would anyone pay for free software? Fees may cover the cost or media or duplication. Fees are also earned by including additional software with the free software or by providing training or services. Moreover, fees might be attributable to the benefits associated with acquiring from a trusted distributor with a well-known brand name, such has Red Hat’s version of Linux. Gomulkiewicz at 187. According to the OSI, the rationale for the principle is that “[b]y constraining the licensee to require free distribution, we eliminate the temptation to throw away long-term gains in order to make a few short-term sales dollars. If we didn’t do this, there would be lots of pressure for cooperators to defect.” http:www.opensource.org/docs.definition.php.
• #11: Source:http:www.opensource.org/docs.definition.php. According to the OSI, the reason for this rule is that “[w]e require access to un-obfuscated source code because you can’t evolve programs without modifying them. Since our purpose is to make evolution easy, we require that modification be made easy.” http://www.opensource.org/docs/definition.php. “Though the preferred method of distribution is for source code to come with the compiled code . . . as a general matter, however, distributors prefer to make source code available separately from the compiled code to limit file sizes and ease distribution.” Tim O’Reilly, Open Source Licensing, Contract, and Copyright Law at 9, available at http://www.oreilly.com/catalog/osfreesoft/book/sh01.pdf [hereinafter O’Reilly].
• #12: Source: http:www.opensource.org/docs.definition.php. The rationale for this requirement is that “[t]he mere ability to read source code isn’t enough to support independent peer review and rapid evolutionary selection. For rapid evolution to happen, people need to be able to experiment with and redistribute modification.” http:www.opensource.org/docs.definition.php. “This paragraph concisely describes the open modification principle that is fundamental to open source licensing.” O’Reilly at 9. As this makes clear, the definition permits, but does not require certain generational limitations, such as copyleft. Id.
• #13: Source: http:www.opensource.org/docs.definition.php. “Open source licensing requires that the author of a particular piece of code be acknowledged.” Gomulkiewicz at 187. “This requirement is often satisfied by retaining the author’s copyright notice on the code he or she creates as the code is passed on and modified further.” Id. The reason for this is that one of the principle reasons that programmers freely contribute their time to open source projects is for recognition, which can bring fame, personal satisfaction, and may even lead to monetary rewards due to an enhanced reputation in the professional community. Id. If the incentive of recognition within the community was not present, the open source community would likely not exist, at least not on any significant scale. Id. Similarly, programmers do not wish to be associated with shoddy code that is engrafted onto or modified from their code. Thus, in addition, the open source definition prevents people from using the names of individual programmers to promote products derived from the code, in order to protect programmers’ reputations. Id. at 188; see also O’Reilly at 9. The limitation are permissive, rather than mandatory. The OSI expresses the rationale in the following manner: “Encouraging lots of improvement is a good thing, but users have a right to know who is responsible for the software they are using. Authors and maintainers have a reciprocal right to know what they’re being asked to support and protect their reputations. “Accordingly, an open-source license must guarantee that source be readily available, but may require that it be distributed as pristine base sources plus patches. In this way, ‘unofficial’ changes can be made available but readily distinguished from the base source.
• #14: Source: http:www.opensource.org/docs.definition.php. The OSI gives the following rationales for the two antidiscrimination provisions: 5. “In order to get the maximum benefit from the process the maximum diversity of persons and groups should be equally eligible to contribute to open source. Therefore we forbid any open-source license from locking anybody out of the process. “Some countries, including the United States, have export restrictions for certain types of software. An OSD conformant license may warn licensees of applicable restrictions and remind them that they are obliged to obey the law; however, it may not incorporate such restrictions itself. 6. “The major intention of this clause is to prohibit license traps that prevent open source from being used commercially. We want commercial users to join our community, not feel excluded from it.” http:www.opensource.org/docs.definition.php. For a discussion of both antidiscrimination provisions, see O’Reilly at 10 ((“The antidiscrimination provisions insure that code is available to the widest body of users. “Every limitation on the use of a given piece of code that restricts the number of potential contributors, and thereby limits the flexibility, reliability, and longevity of that code.”)
• #15: Source: http:www.opensource.org/docs.definition.php. According to the OSI, “[t]his clause is intended to forbid the closing up of software by indirect means such as requiring a non-disclosure agreement.” http:www.opensource.org/docs.definition.php.
• #16: Source: http:www.opensource.org/docs.definition.php. Accodrding to the OSI, “[t]his clause forecloses yet another class of license traps.” http:www.opensource.org/docs.definition.php. O’Reilly further explains this principle: “This provision is included to close a loophole under which individual parts of an aggregation of software would be distributed under a different license than the aggregate package, which would be licensed under open source. This loophole allows a fairly obvious end-run around open source principles and is therefore inconsistent with the purposes of open source licensing.” O’Reilly at 11.
• #17: Source: http:www.opensource.org/docs.definition.php. According to the OSI’s rationale: “Distributors of open-source software have the right to make their own choices about their own software. “Yes, the GPL is conformant with this requirement. Software linked with GPLed libraries only inherits the GPL it it forms a single work, not any software with which they are merely distributed.” [The later slide on the GPL and its notes discusses the problem of linking and GPL software more fully]. “[The provision] [e]nsure[s] the freedom of software distributors and maximize[s] the availability of products licensed under open source licensing.” http:www.opensource.org/docs.definition.php.
• #18: Source: http:www.opensource.org/docs.definition.php. According to the OSI, “This provision is aimed specifically at licenses which require an explicit gesture of assent in order to establish a contract between the licensor and licensee. Provisions mandating so-called ‘click-wrap’ may conflict with important methods of software distribution siuch as FTP downolad, CD-ROM anthologies, and web-mirroring; such provisions may also hinder code re-use. Conformant licenses must allow for the possibility that (a) redistribution of the software will take place over non-Web channels that do not supoprot click-wrapping of the download, and that (b) the covered code (or re-used portions of the covered code) may run in a non-GUI environment that cannot support popup dialogues.” http:www.opensource.org/docs.definition.php.; see also O”Reilly at 11.
• #19: This section will discuss the general features of several classes of licenses; a later section will discuss several of the more popular open source licenses.
• #20: Source: Kennedy at 14-24 (discussing types of licenses); Rosen at 69-71 (same). The next two slides will consider the basic difference between the GPL licenses and the BSD family of licenses. Though not open source licenses, I will briefly consider shareware/freeware and software in the public domain. Proprietary licenses are outside the scope of this presentation and will not be considered.
• #21: Source: GNU General Public License; Kennedy at 15-20 (discussing the GPL type licenses); Rosen at 103-140 (same). The GPL, in conformance with open source definition, provides licensees with the basic rights that are associated with all open source licenses: the right to modify and distribute the software, and access to the source code. The most significant aspect of the GPL however, is its so-called copyleft provision. This provision requires anyone distributing “any work . . . 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.” (GPL paragraph 2(b)). This provision effectively prevents anyone from taking software subject to the GPL private. Many proprietary software organizations have been troubled by this provision, and have refused to modify GPL software, or in many cases to even use it. Part of the reason for the concern was that the GPL does not adequately define what “contains or is derived from” means. Companies were concerned that the software would taint their software. In order to deal with the concern over software becoming tainted, the FSF developed the LGPL. “The LGPL explicitly allows proprietary software to be used in connection with GPL software through the use of programming libraries without requiring that the proprietary software also be subject to the provisions of the GPL.” Kennedy at 19. Basically, the LGPL is the same as the GPL, but with a limitation on the applicability of the copyleft provisions to software libraries. The copyleft provision are only an issue if a user plans to distribute the software. If a user does not plan to distribute the software, then the copyleft provisions will not be an issue. As far as a potential licensor considering the GPL is concerned, the issue for them is whether they wish for future licensees to be subject to the copyleft provisions. The copyleft provisions of the GPL have resulted in a large commons of GPL subject software. The specific provisions of the GPL will be considered later in this presentation. The main purpose of this section is to delineate the basic difference between the GPL and BSD families of licenses.
• #22: Source: Berkeley Software Distribution License; Kennedy at 21-24 (discussing the BSD/academic type licenses); Rosen at 73-102 (same). The BSD License, like the GPL, gives the licensee the same basic rights as the GPL – i.e. the right to modify and distribute the software, and access to the source code. The major difference between the BSD and the GPL is that the BSD does not require licensees that wish to distribute the software to license it under the BSD; instead, they may license it under any license that they choose. Thus, BSD software can be included in proprietary programs without concern for any copyleft provisions. For this reason, many commercial developers prefer the BSD license and consider it more free than the GPL. Kennedy at 21.
• #23: Source: Mozilla Public License; Community Public License; Open Software License; Kennedy at 21-23 (discussing Mozilla/corporate type licenses); Rosen at 141-160 (same). The main difference between the Mozilla/corporate licenses and the BSD and GPL licenses is that the Mozilla license was more precisely drafted, due to its arising in a commercial context. It also has certain features with regards to relicensing and reciprocity that differ slightly from either of the other two licenses; due to this issue involving some complexity, I will omit discussion of it until the later section which examines the Mozilla license in detail. Kennedy at 22.
• #24: Source: http://www.opensource.org/licenses/alphabetical (listing all OSI approved open source licenses in alphabetical order); Kennedy at 23-24 (discussing other types of open source licenses).
• #25: Source: Kennedy at 14-15 (discussing shareware/freeware) Shareware/freeware is generally software that is free as in beer, but not free as in speech. See Kennedy at 14.
• #26: Source: Kennedy at 14-15 (discussing the public domain). The public domain is not a license at all. When software, or other copyrightable material enters the public domain, no one holds a copyright to it at that point. Kennedy at 14-15. Licensing software under an open source license is not the same as releasing it into the public domain. Much to the contrary, open source depends on copyright law for its efficacy. See Shawn W. Potter, Opening Up to Open Source, 6 RICH. J. L. & TECH. (Spring 2004), available at http://law.richmond.edu/JOLT/v65/article3.html (discussing how open source licenses depend on copyright law for their efficacy).
• #27: The preceding section discussed a general layout of several different types of open source licenses. This section will provide an analysis of several of the more important specific licenses. The licenses considered in this section include the GPL, the BSD, the MPL, the Community Public License (CPL), and the Open Source and Academic Free Licenses (OSL and AFL respectively). This presentation provides a point-by-point commentary on the GPL, as it is both relatively short and by far the most important of the open source licenses. It deals with the other licenses in a more general fashion. The full text of these licenses can be found at the website of the Open Source Initiative, http://www.opensource.org.
• #28: Source: General Public License; Kennedy at 15-20 (discussing the provisions of the GPL); Rosen at 103-40 (same). At the outset, I mention the single most important provision of the GPL: the so-called copyleft provision. This provision requires that any licensee that distributes software subject to the GPL license it under the GPL. This provision has the effect of growing a large public commons of software subject to the GPL. Rosen at 105. The exact words of the GPL are: “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 (GPL section 2). Lawrence Rosen, general counsel for the Open Source Initiative, has proposed referring to the copyleft provision as a reciprocity provision, because it ensures that both the licensee and the licensor are covered by the GPL. Rosen at 105-6. I continue to use copyleft because it seems to be a more common term in the literature on open source and the GPL. The authors of the GPL, Richard Stallman and law professor Eben Moglen, had three objectives for the GPL. The first was to create the aforementioned public commons of free software. They felt that the academic/BSD licenses, which did not include copyleft provisions, would allow “uncooperative people” to take software out of this public commons. The second was to ensure that improvements and new applications would be compatible with other versions of software. This was a concern, because if companies took software private, many different and incompatible forks of a program could develop. This had been a problem with UNIX. The third was simply to advance what they felt is the ethical imperative of free software. Rosen at 107-109. The first part of the GPL is a preamble. It states what is the purpose of the GPL: “The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software – to make sure the software is free for all its users (GPL Preamble). The GPL provides its “freedoms” by placing restrictions on licensees: “To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.” (GPL preamble). “The preamble also emphasizes that software under the GPL has no warranty and that any patents must be licensed for everyone’s use or not at all.” Kennedy at 16. The preamble is not part of the terms and conditions of the license, and thus is not legally binding. Kennedy at 16; Rosen at 109-112. Paragraph one of the terms and conditions defines “program” as the original program and any derivative work under copyright law. (GPL p.1). P.1 also provides that output from the program is not covered unless it constitutes a derivative work. Paragraph one also provides that “You may copy and distribute verbatim copies of the Program’s source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give to any other recipients of the Program a copy of this License along with the Program. “The CPL is thus a template license, applicable to all software by any author who chooses to use it.” Rosen at 113. There is also a provision for specifying what version of the GPL is being used. See Rosen at 112-113. Section 2 allows licensees to modify the Program or any part of it, and to distribute the modifications under the terms of section 1. There are several restrictions. The licensee “must cause the modified files to carry prominent notices stating that [he or she] changed the files and the date of any change.” (GPL p. 2(a)). Paragraph 2(b) requires any work that a licensee distributes or publishes, “that in whole or in part contains or is derived from the Program of any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.” That is the copyleft provision. P. 2(c) contains restrictions regarding how copyright notices and disclaimers of warranties must be displayed. Paragraph 3 allows the licensee to distribute the program in object code form, provided he or she also makes the source code available. The licensee may make the source code available by distributing it “on a medium customarily used for software exchange” along with the object code, accompanying the object code with an offer, valid for at least three years, to send the code in machine readable form for no more than the charge of physically copying and delivering it, or accompanying it with the offer the licensee received for distributing source code. Paragraph 3 also defines source code as “the preferred form of the work for making modifications to it.” Paragraph 4 provides that any attempt to “copy, modify, sublicense or distribute the Program” not in compliance with the GPL will cause the license to terminate. Violation by a licensee however will not terminate the licenses held by downstream licensees. Paragraph 5 makes the GPL a shrinkwrap license. It does not require a signature. Modifying or distributing the Program counts as acceptance. Paragraph 6 ensures that downstream licensees have a license from the original licensor. It prohibits downstream licensors from placing additional restrictions on licensees, and provides that licensees are not responsible for enforcing the terms of the license. Paragraph 7 provides that if anything should happen that makes a licensee unable to distribute the program in accordance with the license (e.g. being found to be infringing a patent), he or she may no longer distribute the program. Paragraph 8 allows licensors to provide geographical restrictions on the license in case usage of material is limited in certain jurisdictions by patents or copyrighted interfaces. Paragraph 9 allows the FSF (the publisher of the GPL) to develop new versions of the GPL, and allows a licensor to provide that a licensee will be bound by the current version of the GPL or any later version. Paragraph 10 deals with incorporating the program into programs with different distribution conditions, and request those who may wish to do so to obtain the FSF’s permission. Paragraph 11 disclaims all warranties. Paragraph 12 disclaims liability for copyright holders and those who modify or distribute the program. The GPL ends with a section on how to apply the GPL to a program.
• #29: Source: General Public License; Kennedy at 15-20 (discussing the provisions of the GPL); Rosen at 103-40 (same). Paragraph one of the terms and conditions specifies that it applies to a “program or work based on the program.” It then defines “work based on a program” to mean a derivative work under copyright law. P.1. Paragraph one then goes on to define derivative work in a way that extends beyond the definition of derivative work used in the copyright law: “that is to say, [a derivative work is] a work containing the Program or a portion of it, wither verbatim or with modification and/or translated into another work. The definition would seem to include not only derivative works, but collective works as well (I.e. works that include a portion of the work). Because of the broad definition of derivative work in paragraph one, there is a dispute over “the reach of “unmodified programs that merely link to each other but that are collected into one program for convenience.’ Rosen at 114-15. There are several other provisions of section 2 that seem to apply to the whether the GPL covers collective works or just derivative works. Section 2 provides again that “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 a separate works.” Also from paragraph 2 “But when you distribute the 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 this to each and every part regardless of who wrote it.” The quoted sections are not clear as to whether the GPL applies to derivative works only or also to collective works. The GPL states that “the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.” GPL p. 2. While the GPL may have this as its intent, the actual language is not clear. Most programmers for whom this is an issue have simply avoided the problem by separately downloading and installing non-GPL required software to avoid distribution as part of a whole. Rosen p. 118. Also, the GPL advises people who are confused to ask the author for guidance. Linus Torvalds, copyright holder for Linux, for example, has made clear that works including Linux as a collective work are not subject to the GPL. Another problem is that there is no explicit patent grant. The GPL creates a bare license. There is a provision (section 7) that suggests that one cannot charge a royalty for patents while distributing GPL software. However, the law of licenses would not necessarily recognize such an implied patent grant in a bare license. Rosen at 126. Likewise, the GPL does not mention trademarks. Rosen at 127. The GPL also does not address the scope of duration of the license. Rosen at 127. The GPL does not discuss sublicensing either. Rosen at 127-128. The GPL also provides specifically that it is a license and not a contract. Thus, a licensor can only sue for copyright infringement on copyrights that he or she actually owns, and can only sue on federal court. This also might make it revocable, as a license is revocable unless it is coupled with an interest See Rosen at 137-139.
• #30: Library or Lesser General Public License; Kennedy at 19-20 (discussing the LGPL); 121-125 (same). The exact language is “The act of running a program using the Library is not restricted,” LGPL section 0, and “A program that contains no derivative of any portion of the Library, but is designed to work with the Library by being compiled or linked with it, is called a ‘work that uses the Library.’ Such a work, in isolation, is not a derivative work of the Library, and therefore falls outside the scope of this License,” LGPL section 5.
• #31: Source: Berkeley Software Distribution License; Kennedy at 20-21 (discussing the BSD); Rosen at 73-83 (same). The BSD license in very short; it is less than two printed pages. It provides that redistribution and use in binary and source code form are permitted as long as the licensee includes the BSD copyright notice, the name of the organization distributing the software is not used to “promote products derived from this software without specifgic prior written permission.” The BSD also provides a disclaimer, attempting to limit liability and presenting the product “as is.” Like the GPL, it was not written by lawyers and hence is incomplete, failing to discuss patents, sublicensing, scope and duration, etc.
• #32: Source (slide): Kennedy at 20-21 (discussing other BSD type licenses); Rosen at 83-102 (same). The main differences between the MIT license and the BSD are that the MIT license disclaims any warranty of noninfringement and explicitly grants the right to sublicense. See Rosen at 85-90. The main difference in the Apache license is that it explicitly protects Apache’s trademark. See Rosen at 92-93. The artistic license is amateurish and ambiguous. See Rosen at 92-93. Sources (notes): Kennedy at 20-21 (discussing other BSD type licenses); Rosen at 83-102 (same).
• #33: Source (slide): Mozilla Public License; Kennedy at 21-24 (discussing the MPL); Rosen at 141-160 (same). Unlike the BSD and the GPL, the MPL was written by lawyers. As such, it includes many things that are left out of the aforementioned licenses, such as an extensive definition section. See Rosen at 143-145. The MPL states that programmer who contribute to the MPL must also license their contributions under the MPL. See sections 2 & 3; Rosen at 145-47. This effectively deals with the problem of sublicensing, and with the problem of incompatible licenses from multiple contributors. Also unlike the GPL and the BSD, the MPL provides an explicit patent grant. The patent grant covers code from the original contributor (a term of art defined in the license), as well as modifications (another term of art) by contributors (another term of art). The patent grant is too complicated and convoluted to be discussed in full here. The MPL also contains a patent defense provision. This provision terminates the patent grant to any party using software licensed under the MPL if he or she sues the contributor or initial developer for patent infringement. The MPL also contains a representation that a contribution is original to the contributor and that the contributor has the rights required to grant a license to the contribution. The MPL also has provisions relating to U.S. government users, jurisdiction and venue, and attorney’s fees and costs. It specifies hat the software is not subject to the United Nations Convention on Contracts for the International Sale of Goods (section 11), and that an initial developer may make software available under multiple licenses. Contributor, initial developer, contribution and modification are all terms of art that the MPL defines in its definition section. As far as reciprocity, the MPL is somewhere between the BSD and the GPL. When distributing code licensed under the MPL, or modifications thereto, the licensee is only obligated to distribute files containing the original code or modifications to it (modifications and original code are terms of art defined in the definitions section of the license. Thus, only certain files are subject to the MPL for software licensed under the MPL. Thus, a programmer could add files to the files containing covered code, and only the files containing covered code would be subject to the MPL, not the added files. See Rosen at 143-47; MPL sections 1.1, 1.3, 1.9, 1.10, 3.7. The words of the MPL are “You may create a Larger Work by combining Covered Code with other code not governed by the terms of this License and distribute the Larger Work as a single product. In such a case, You must make sure that the requirements of this License are fulfilled for the Covered Code.” (MPL section 3.7). In addition, any modifications to the code must be distributed along with those files. Sources (notes): Mozilla Public License; Kennedy at 21-24 (discussing the MPL); Rosen at 141-160 (same).
• #34: Source (slide): Common Public License; Rosen at 161-177 (discussing CPL). The CPL is corporate license very similar to the MPL. It grants both copyright and patent rights, though the patent rights are subject to some limitations. See CPL section 2(b). Like the MPL, the patent grant is too convoluted to discuss in detail here. The CPL also includes a somewhat limited reciprocity provision. The provision does not apply to works that “(i) are separate modules of software distributed in conjunction with the Program under their own license agreement, and (ii) are not derivative works of the program.” CPL section 1. The CPL also contains a patent provision that is more far reaching than the one in the MPL. Under the CPL, if a licensee institutes litigation against a contributor, it loses its patent license for the software that is claimed to be infringing, as well as any other patents held by the contributor. The copyright licenses also terminate. Se Rosen at 170-72. The CPL (section 4)} also contains a defend and indemnify provision. This provision requires any commercial contributor to defend and indemnify any other contributor for claims by third parties arising out of the commercial contributor’s acts or omission “in connection with it s distribution of the Program in a commercial product offering.” (CPL section 4). IBM grants others the right to copy the license and license software under it, but reserves the right to make derivative works. CPL section 7; Rosen at 176-77. Source (notes): Common Public License; Rosen at 161-177 (discussing CPL).
• #35: Source (slide): Rosen at 179-227 (discussing the OSL and the AFL); Open Source License ; Academic Free License. The AFL and OSL have sections dealing with all of the issues discussed on this slide. They also contain provisions dealing with attribution rights, disclaiming all warranties (including any warranty of provenance), a limitation of liability, acceptance and termination, patent defense, jurisdiction, venue, choice of law, attorney’s fees, interpretation, definitions, the right to use the software, and requirements. The license also requires that a copyright notice be included with the license stating that the license is copyrighted. The author of the license, like IBM and the CPL, authorizes persons to use his license but not to modify it. Source: Rosen at 179-227 (discussing the OSL and the AFL); Open Source License ; Academic Free License. Source (notes): Rosen at 179-227 (discussing the OSL and the AFL); Open Source License ; Academic Free License.
• #36: Source: Rosen at 255-68 (discussing alternatives to Open Source). Microsoft allows it customers access to some of its source code under some licenses. However, it does not allow it under a true open source license, as the license forbids licensees from making derivative works, and for using the source code for commercial purposes. It only allows the license to be used for examination (e.g. to detect security flaws) and for examination. See Rosen at 256-59 (discussing Microsoft’s Shared Source Licenses). There are many companies that allow more substantial access to and use of their code than Microsoft does under its shared source license. These companies, however,will not allow their code to be used for commercial purposes, or will require payment of a royalty for commercial use. These are the licenses referred to as “public source.” Rosen at 259-61 (discussing public source). Companies often issue software under more than one license. One reason to do this would be to offer software to certain customers under a license that said customer found more attractive, often for a fee. An example or this would be licensing software to the open source community under the GPL, and offering it for a fee to interested users under a different license, so that they could make and distribute derivative works without concern for the GPL’s reciprocity/copyleft provisions. See Rosen at 262-264 (discussing these licensing models and providing examples). Some companies license under a proprietary license when first releasing software, and then later release the same software under an open source license. This is done because customers are often willing to pay for the privilege of receiving the most up-to-date versions of software at the earliest possible time. See Rosen at 264-67 (discussing this business model and providing examples). See Rosen at 262-67 (discussing these strategies).
• #38: Sources (slide): Rosen, Kennedy at 24-35 (discussing risks of open source licenses); Pratibha Gupta, Copyright and Open Source Licensing, 30 Les Nouvelles 135 (2008) (discussing possible risks of open source licensing for consumers) .; The Software Licensing Committee of the American Bar Association’s Intellectual Property Section, “An Overview or ‘Open Source’ Software Licenses,” available at http://www.abanet.org/intelprop/opensource.html [hereinafter ABA publication]. The first and most obvious risk is the risk of infringing on the copyrights and patents of third parties. The open source development process introduces many opportunities for programmers to introduce infringing code, and “makes it almost impossible to audit the entire code base.” (ABA publication at 3-4). Most open source licenses do not provide any warranties of non infringement or any provisions for indemnification. Even if there were such provisions, many open source licensees would be incapable of living up to their obligations under them. The shifting of risk from the licensor to the licensee is in contrast to the usual situation in the arena of commercial software (ABA publication at 4). Intellectual property infringement is also a risk with proprietary software. Some have argued that the risk is no greater with open source than proprietary software. See, e.g. Pillsbury Winthrop, Demystifying Common Misconceptions About Open Source, Patents and Legal Liability, available at http://www.prnewswire.com/cgi-bin/stories.pl?ACCT=104&STOR/www/story/12-15-2004/0002633825.. In addition to providing no warranty of non infringement, most open source licenses do not provide any warranty of merchantability or fitness for a particular purpose. This is again in contrast to the commercial world of software. (ABA publication at 4). There may also be trouble with the copyleft provisions of some licenses, but only if a company decides to distribute the software or any derivative works. If the user only intends to use the software and not to distribute it, then there is no problem with this issue. The long list of copyright and attribution notices can become burdensome in some cases. ABA publication at 4. As mentioned earlier, there may be some uncertainty as to who may enforce the open source licenses. If they are viewed as contracts, then each person who licenses under the license could be, if they are viewed as bare licenses, then only the copyright owners could sue to enforce the licenses. Also, there may be issues with enforcing shrink-wrap or click-wrap agreements. Another risk results from the ambiguity of the license terms. This was discussed earlier in relation to various terms in specific licenses. Another issue involves the disclaimers of warranties. These may be an issue for licensors as well as licensees, because the consumer protections was of some jurisdictions may disallow or limit such disclaimers. As open source projects grow, contributions may come to include many different licenses. Some may be incompatible. Generally, license will not be an issue for incorporating open source software in a collective work; for derivative works, there may be a problem, as most licenses require that any derivative works be distributed under the same license as the original. The copyleft provisions of the GPL may also be an issue here. The concerns in this paragraph are only applicable if a user of open source software intends to distribute that software or modifications of it. One thing that adds to the uncertainty revolving around the legal issues of open source is that no court has construed the licenses. An additional legal risk is that open source licenses may be revocable. This is so because they are probably bare licenses, rather than contracts. A license is freely revocable, whereas a contract is not. The reason that open source licenses are not contracts is that there is a failure of consideration. The conditions on the license are not consideration. The licensees’ reliance may be able to function as a consideration substitute, under the doctrine of promissory estoppel. There may also be a problem with acceptance, since many of the licenses involve “click-wrap” agreements; however, these agreements have generally proven valid. See Rosen at 53-66 (discussing whether open source licenses are contracts or not and the implications thereof). As open source licenses are not contracts, there is uncertainty as to how the terms should be interpreted. Contract law has well established doctrine for how to interpret terms; license law does not. Thus, interpretation of terms, such as derivative work, is uncertain. See id. Another risk, though not a legal one, is forking. An open source project could develop into several different incompatible projects. Sources (notes): Rosen, Kennedy at 24-35 (discussing risks of open source licenses); Gupta; The Software Licensing Committee of the American Bar Association’s Intellectual Property Section, “An Overview or ‘Open Source’ Software Licenses,” available at http://www.abanet.org/intelprop/opensource.html [hereinafter ABA publication].
• #39: Sources (for slide): David A. Wheeler, “Why Open Source Software/Free Software (OSS/FS, FLOSS, of FOSS)? Look at the Numbers!, available at http://www.dwheeler.com/oss_fs_why.html#history (reviewing literature on the benefits of open source versus proprietary software); Pratibha Gupta, Copyright and Open Source Licensing, 30 Les Nouvelles 135, 139-40 (2008) (discussing possible advantages of open source licensing for consumers) . One of the advantages, for licensors and licensees, is that open source software can bring an increased user base. For licensors, that may translate into prestige, or a platform for selling other proprietary products. For licensees, that can mean a larger pool of people that are working on bug fixes and that have expertise with the software. Often, open source programs have a longer useful life than proprietary programs. Due to the increased amount of programmers working on open source projects, they are often more stable. This is because open source projects often have access to many more programmers than even a large corporation would. Also due to the amount of programmer, bug fixes are typically quicker. Whether open source is less or more secure, or as secure as, proprietary software is an ongoing debate. Scalability refers to the size of architecture that a program can be run on, such as a personal data assistant on the one end, and a scoreboard or other large apparatus on the other. As with security, the scalability of open source programs is up for debate. Innovation, as with stability, is related to the number of programmers that are available for working on open source projects. Open source programs are generally free, in the sense that there is no licensing cost. However, the relevant measure is total operating cost, including installation and training. Some studies suggest that open source generally has a lower total operating cost than proprietary software. Total cost, as with the other possible advantages, would depend on individual circumstances. Another major advantage for consumers of open source software is that, since they have access to the source code and are allowed to modify it, they can modify the software to fit their individual needs. Sources (for notes): David A. Wheeler, “Why Open Source Software/Free Software (OSS/FS, FLOSS, of FOSS)? Look at the Numbers!, available at http://www.dwheeler.com/oss_fs_why.html#history (reviewing literature on the benefits of open source versus proprietary software); Pratibha Gupta, Copyright and Open Source Licensing, 30 Les Nouvelles 135, 139-40 (2008) (discussing possible advantages of open source licensing for consumers) .
• #40: source: http://en.wikipedia.org/wiki/Free_software; Eric S. Raymond, The Magic Cauldron, available at http://www.catb.org/~esr/writings/magic-cauldron/
• #42: Open content basically refers to intellectual property that is not subject to restrictions on its use, or to minimal restrictions. Some organizations use different terminology, such as open knowledge. Source (slide and notes): Open Content, http://www.wikipedia.org/wiki/Open_content; http://creativecommons.org.
• #43: Source (slide and notes): http://creativecommons.org. Creative Commons is a Massachusetts non profit organization founded in 2001 by law professor Lawrence Lessig. According to its charter, the purpose of the organization “include[es], but [is] not limited to, designing methods and technologies that facilitate the sharing of scientific, creative, and other intellectual works with the general public.” (Creative Commons Charter, available at http://ibiblio.org/cccr/docs/articles.pdf). According to the website, the goal is “to build a layer of reasonable, flexible copyright in the face of increasingly restrictive default rules,” or “to offer creators a best-of-both-worlds way to protect their works while encouraging certain uses of tem – to declare ‘some rights reserved.’” (Creative Commons website, http://wiki.creativecomons.org/History). Creative Commons has a set of licenses that people are allowed to use to license their work. The licenses have four key characteristics, which Creative Commons calls “baseline rights.” They are, in the words of Creative Commons, “Attribution: You let people copy, distribute, display, perform, and remix your copyrighted work, as long as they give you credit in the way you request. All CC licenses contain this property. “NonCommercial. You let people copy, distribute, display, perform, and remix your work for non-commercial purposes only. If they want to use you work for commercial purposes, they must contact you for permission. “ShareAlike. You let people create remixes and derivative works based on your creative cork, as long as they only distribute them under the same Creative Commons license that your original work was published under. “NoDerivatives. You let people copy, distribute, display, and perform only verbatim copies of your work – not make derivative work based on it. If they want to alter, transform, build on, or remix your work, they must contact you for your permission. (Creative Commons Frequently Asked Questions, http:wiki.creativecommons.org/Frequently_Asked_Questions). Based on theses baseline rights, Creative Commons offers six licenses. They are, from most to least restrictive, attribution Non-Commercial No Derivatives, Attribution Non-commercial Share Alike, Attribution Non-commercial, Attribution No Derivatives, Attribution Share Alike, and Attribution. See http://creativecommons.org/abput/licenses/meet-the-licenses. Creative Commons licenses are non-exclusive and non-revocable, and should not be used for software (because there is an existing legal infrastructure for free software). Though Creative Commons originally developed its licenses with the U.S. legal system in mind, it has since, through the efforts of its branch Creative Commons International, developed license geared towards 43 different jurisdictions. The only legal action thus far on a Creative Commons license came from a Dutch court; the license was upheld. “Creative Commons,” http://en.wikipeida.org/Creative_Commons. In addition to the six aforementioned “some-rights-reserved” licenses, Creative Commons has a “Public Domain Dedication” that essentially allows authors to free their creations from any restrictions imposed by copyright law. This license can be found at http://creativecommons.org/license/publicdomain-2. Before using a Creative Commons license, authors should “make sure [their] work falls within the Creatvie commons license,” i.e. is subject to copyright protection, “make sure [they] have the rights,” i.e. that they own the copyright, “make sure they understand how Creative Commons licenses operate,” i.e. understand what rights they are giving away and retaining, “be specific about what they are licensing.” See http:’’wiki.creativecommons.org/Before_Licensing
• #45: Source: http://www.google.com/Top/Computers/Open_Source/Open_Content/Licenses/
• #46: The source of this slide is the Creative Commons FAQs http://creativecommons.org/FAQ
• #51: The book that inspired Netscape to release its Mozilla web browser as an open source project.