open source licensingopen source licensing

1. Open Source Licensing An Introduction 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. 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.

2. This slide is an outline of the presentation, as the notes to the previous slide discussed. The bullet points on the slide correspond to the parts of the presentation. The intellectual property segment covers copyright, patent, trademark and contract law. Though contract is not exactly a part of intellectual property law, it is important for some points about open source. The part on software covers the distinction between software and hardware, and between object code and source code. It is extremely basic and general. The part on history and philosophy covers the rise of open source in the 1970s as free software through its development in the 1990s as open source. It discusses free software and the distinction between free and open source software. It discusses the Open Source Initiative and its Open Source Definition. The part on general types of open source licenses lays out the general types of open source licenses that are available. The main difference is between the General Public License (GPL) or “copyleft” type licenses and the BSD/academic type licenses, that do not include “copyleft” provisions (the part explains what copyleft means). There is also a difference between the early licenses, which amateurs drafted, and the later corporate licenses, which attorneys drafted, and hence look more like traditional licenses. That part also discusses freeware/shareware, proprietary licenses, and the public domain,none of which are open source licenses, but which illuminate open source through their differences from it. The section on individual licenses provides a brief analysis of several open source licenses. The licenses that it examines are the most popular of all open source licenses, the General Public License (GPL), the second most popular open source license, the Berkeley Software Distribution License (BSD), the first corporate license, the Mozilla Public License (MPL), IBM’s Community Public License (CPL), and Lawrence Rosen’s (general counsel for the Open Source Initiative) Open Source License (OSL) and Academic Free License (AFL), which he drafted to deal with what he perceived to be imperfections in the already existing licenses. The part on the risks and benefits of open source licenses deals mostly with the legal risks of open source licenses; the benefits are mostly with the software itself. The part on open source deals mostly with Creative Commons, though there are several other open content organizations and open content licenses, some of which the part examines. The conclusion is very brief, and does not introduce any new material. This slide is an outline of the presentation, as the notes to the previous slide discussed. The bullet points on the slide correspond to the parts of the presentation. The intellectual property segment covers copyright, patent, trademark and contract law. Though contract is not exactly a part of intellectual property law, it is important for some points about open source. The part on software covers the distinction between software and hardware, and between object code and source code. It is extremely basic and general. The part on history and philosophy covers the rise of open source in the 1970s as free software through its development in the 1990s as open source. It discusses free software and the distinction between free and open source software. It discusses the Open Source Initiative and its Open Source Definition. The part on general types of open source licenses lays out the general types of open source licenses that are available. The main difference is between the General Public License (GPL) or “copyleft” type licenses and the BSD/academic type licenses, that do not include “copyleft” provisions (the part explains what copyleft means). There is also a difference between the early licenses, which amateurs drafted, and the later corporate licenses, which attorneys drafted, and hence look more like traditional licenses. That part also discusses freeware/shareware, proprietary licenses, and the public domain,none of which are open source licenses, but which illuminate open source through their differences from it. The section on individual licenses provides a brief analysis of several open source licenses. The licenses that it examines are the most popular of all open source licenses, the General Public License (GPL), the second most popular open source license, the Berkeley Software Distribution License (BSD), the first corporate license, the Mozilla Public License (MPL), IBM’s Community Public License (CPL), and Lawrence Rosen’s (general counsel for the Open Source Initiative) Open Source License (OSL) and Academic Free License (AFL), which he drafted to deal with what he perceived to be imperfections in the already existing licenses. The part on the risks and benefits of open source licenses deals mostly with the legal risks of open source licenses; the benefits are mostly with the software itself. The part on open source deals mostly with Creative Commons, though there are several other open content organizations and open content licenses, some of which the part examines. The conclusion is very brief, and does not introduce any new material.

3. Part I provides a general overview of intellectual property law. Part I provides a general overview of intellectual property law.

4. What is intellectual property? “Intellectual property refers to creations of the mind: inventions, literary and artistic works, and symbols, names, images, and designs used in commerce.” What is Intellectual Property?, World Intellectual Property Organization (WIPO), http://www.wipo.int/about-ip/en/ Source: What is Intellectual Property?, World Intellectual Property Organization (WIPO), http://www.wipo.int/about-ip/en/. Though property is often thought of as only tangible property, it is not so limited. It includes “every intangible benefit and prerogative susceptible of possession or disposition.” Lawrence Rosen, Open Source Licensing: Software Freedom and Intellectual Property Law 14 (Prentice Hall Technical and Professional Reference 2005) [hereinafter Rosen] (quoting a California court case, which the author decline to name or cite). Three separate types of intellectual property can be abstracted from the definition on this slide: ideas, expressions, and unique commercial identifiers. These three bodies of intellectual property are protected by patent, copyright, and trademark law. Rosen at 13-39 (discussing basic intellectual property law). Software, as it is created by the intellectual efforts of humans, and is capable and being sold, given away, or licensed, is a type of intellectual property. Id. at 14. Software as property has two different aspects. There is the individual copy of the software that one can purchase at a store or download from the Internet, and there is “the intellectual property embodied in that software.” Id. The body of intellectual property law most applicable to software is copyright, though patent and trademark have some application as well. Source: What is Intellectual Property?, World Intellectual Property Organization (WIPO), http://www.wipo.int/about-ip/en/. Though property is often thought of as only tangible property, it is not so limited. It includes “every intangible benefit and prerogative susceptible of possession or disposition.” Lawrence Rosen, Open Source Licensing: Software Freedom and Intellectual Property Law 14 (Prentice Hall Technical and Professional Reference 2005) [hereinafter Rosen] (quoting a California court case, which the author decline to name or cite). Three separate types of intellectual property can be abstracted from the definition on this slide: ideas, expressions, and unique commercial identifiers. These three bodies of intellectual property are protected by patent, copyright, and trademark law. Rosen at 13-39 (discussing basic intellectual property law). Software, as it is created by the intellectual efforts of humans, and is capable and being sold, given away, or licensed, is a type of intellectual property. Id. at 14. Software as property has two different aspects. There is the individual copy of the software that one can purchase at a store or download from the Internet, and there is “the intellectual property embodied in that software.” Id. The body of intellectual property law most applicable to software is copyright, though patent and trademark have some application as well.

5. Source: Rosen at 15. Software is both copyrightable and patentable in the United State. See Rosen at 16-17. The standards for obtaining a patent for software are very high, and will be discussed later in this presentation. The standards for copyright and trademark protection are somewhat lower. See id at 17-19 (discussing how persons obtain copyrights and patents); id. at 37-39 (discussing trademarks). Source: Rosen at 15. Software is both copyrightable and patentable in the United State. See Rosen at 16-17. The standards for obtaining a patent for software are very high, and will be discussed later in this presentation. The standards for copyright and trademark protection are somewhat lower. See id at 17-19 (discussing how persons obtain copyrights and patents); id. at 37-39 (discussing trademarks).

7. Source: U.S. Const. Art. 1 § 8 Cl. 8; 17 U.S.C. §§ 101 et seq.; Berne Convention for the Protection of Literary and Artistic Works; United States Copyright Office, “Copyright Basics,” available at http://www.copyright.gov/circs/circ1.pdf. Article 1, section 8, clause 8 of the United States Constitution gives Congress the authority “[t]o promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the Exclusive Right to their respective Writings and Discoveries.” This section is the authority for both copyright and patent law. Congress first provided copyright protection with the copyright act of 1790. After the Berne Convention, Congress moved to modernize copyright protection in the United States, and produced the Copyright Act of 1976, which is codified in section 101 and the following sections of chapter 17 of the United States Code, the official compendium of statutory law in the United States. See United States Copyright Law, http://en.wikipedia.org/wiki/U.S._Copyright_Law (discussing the history of copyright protection in the United States). The text of the Copyright Act can be found online for free at http://www.law.cornell.edu/uscode/17/ The Berne Convention for the Protection of Literary and Artistic Works was first promulgated in 1886, and underwent major revisions in 1971. It is an international agreement governing the law of copyright, to which the United States and most major industrialized nations are parties. The text of the convention, as well as nations that are a party to it, can be found at the website of the World Intellectual Property Organization (WIPO), http://www.wipo.int/treaties/en/ip/bernre/. As a result of the Berne Convention, the Copyright laws of most nations are similar. Rosen at 23. Source: U.S. Const. Art. 1 § 8 Cl. 8; 17 U.S.C. §§ 101 et seq.; Berne Convention for the Protection of Literary and Artistic Works; United States Copyright Office, “Copyright Basics,” available at http://www.copyright.gov/circs/circ1.pdf. Article 1, section 8, clause 8 of the United States Constitution gives Congress the authority “[t]o promote the Progress of Science and useful Arts, by securing for limited Times to Authors and Inventors the Exclusive Right to their respective Writings and Discoveries.” This section is the authority for both copyright and patent law. Congress first provided copyright protection with the copyright act of 1790. After the Berne Convention, Congress moved to modernize copyright protection in the United States, and produced the Copyright Act of 1976, which is codified in section 101 and the following sections of chapter 17 of the United States Code, the official compendium of statutory law in the United States. See United States Copyright Law, http://en.wikipedia.org/wiki/U.S._Copyright_Law (discussing the history of copyright protection in the United States). The text of the Copyright Act can be found online for free at http://www.law.cornell.edu/uscode/17/ The Berne Convention for the Protection of Literary and Artistic Works was first promulgated in 1886, and underwent major revisions in 1971. It is an international agreement governing the law of copyright, to which the United States and most major industrialized nations are parties. The text of the convention, as well as nations that are a party to it, can be found at the website of the World Intellectual Property Organization (WIPO), http://www.wipo.int/treaties/en/ip/bernre/. As a result of the Berne Convention, the Copyright laws of most nations are similar. Rosen at 23.

8. Source: 17 U.S.C. § 102; Rosen at 13-39 (discussing copyright law). I.e., copyright protects expressions. Examples of copyrightable material include “literary works; pictorial, graphic, and sculptural works, motion pictures and other audiovisual works; sound recordings; and architectural work.” Rosen at 19. If a work is made for hire, the copyright is owned by the person that paid for the work to be done, even if there is no written contract. 17 U.S.C. 201. The only exception is if there is an express agreement otherwise. There are different laws from state to state covering employee ownership of their creations. Rosen at 20-22 (discussing works made for hire). The underlying idea is not subject to copyright, only the expression of it. Rosen at 15-17 (discussing he difference between copyright and patent law). Thus, the phrase “April is the cruelest month” is subject to copyright, but not the idea that April is a particularly cruel month, more so than the rest. Similarly, a particular computer function is not copyrightable, only the particular program that expresses it. As a copyright is a type of intellectual property and hence can be sold, the original author is not always the owner of a particular copyright. Rosen at 28-30. Source: 17 U.S.C. § 102; Rosen at 13-39 (discussing copyright law). I.e., copyright protects expressions. Examples of copyrightable material include “literary works; pictorial, graphic, and sculptural works, motion pictures and other audiovisual works; sound recordings; and architectural work.” Rosen at 19. If a work is made for hire, the copyright is owned by the person that paid for the work to be done, even if there is no written contract. 17 U.S.C. 201. The only exception is if there is an express agreement otherwise. There are different laws from state to state covering employee ownership of their creations. Rosen at 20-22 (discussing works made for hire). The underlying idea is not subject to copyright, only the expression of it. Rosen at 15-17 (discussing he difference between copyright and patent law). Thus, the phrase “April is the cruelest month” is subject to copyright, but not the idea that April is a particularly cruel month, more so than the rest. Similarly, a particular computer function is not copyrightable, only the particular program that expresses it. As a copyright is a type of intellectual property and hence can be sold, the original author is not always the owner of a particular copyright. Rosen at 28-30.

9. How does a work become copyrighted? As soon as a work is fixed in a tangible medium, copyright subsists. Source: Rosen at 17-19 (discussing how a work becomes copyrighted). To say that copyright subsists is just a fancy way of saying that the work becomes subject to copyright law. While formalities are not required, they can help. Rosen at 16. An original work should be marked as © Copyright <year> <author>. Id. An author can also register his or her copyright with the Library of Congress by filling out a form and paying a small fee. Id. Registration is not required to be protected by copyright, but it is required to initiate copyright litigation. Id. Source: Rosen at 17-19 (discussing how a work becomes copyrighted). To say that copyright subsists is just a fancy way of saying that the work becomes subject to copyright law. While formalities are not required, they can help. Rosen at 16. An original work should be marked as © Copyright <year> <author>. Id. An author can also register his or her copyright with the Library of Congress by filling out a form and paying a small fee. Id. Registration is not required to be protected by copyright, but it is required to initiate copyright litigation. Id.

10. Source: 17 U.S.C. § 106; Rosen at 22-24 (explaining the basic rights of copyright holders). The laws of most other countries provide similar rights to those provided by the United States. Rosen p. 23. Following this list are several slides discussing important concepts from copyright law with a brief explanation of them. These concepts will be important in understanding open source. Source: 17 U.S.C. § 106; Rosen at 22-24 (explaining the basic rights of copyright holders). The laws of most other countries provide similar rights to those provided by the United States. Rosen p. 23. Following this list are several slides discussing important concepts from copyright law with a brief explanation of them. These concepts will be important in understanding open source.

11. Copies The original is the first copy Any duplicate is a copy All instances of a software program are copies All open source licenses grant the right to make copies There is no limitation on the means made to make a copy Source: Rosen at 24-25 (explaining copies). Source: Rosen at 24-25 (explaining copies).

12. Derivative Works “[A] work based upon one or more preexisting works, such as a translation . . . or any other form in which a work may be recast, transformed, or adapted.” 17 U.S.C. § 101. Source: 17 U.S.C. § 101; Rosen at 26-28 (explaining derivative works under U.S. copyright law). There are many different types of derivative works; more than can be listed here. Examples include “translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted.” 17 U.S.C. 101. A successor version of a software program would be an example of a derivative work of software. Rosen at 28. Source: 17 U.S.C. § 101; Rosen at 26-28 (explaining derivative works under U.S. copyright law). There are many different types of derivative works; more than can be listed here. Examples include “translation, musical arrangement, dramatization, fictionalization, motion picture version, sound recording, art reproduction, abridgment, condensation, or any other form in which a work may be recast, transformed, or adapted.” 17 U.S.C. 101. A successor version of a software program would be an example of a derivative work of software. Rosen at 28.

13. Collective Works “A work . . . in which a number of contributions, constituting separate and independent works in themselves, are assembled into a collective whole.” 17 U.S.C. § 101. Source: 17 U.S.C. § 101; Rosen at 27 (discussing collective works). An example of a collective work would be an anthology or encyclopedia. Rosen at 27. While the compiler would hold a copyright on the arrangement, the authors (or other owners of the copyright) would retain their copyright in the original piece. Id. “In the software context, a collective work is usually an aggregation of separately written software that is distributed as a single package or on one disk,” such as an office productivity suite. Id. “The copyright in a collective work is a reflection of the originality of the collection and its organizational structure rather than of the individual components.” Id. Most software constitutes a collective work. Id. Source: 17 U.S.C. § 101; Rosen at 27 (discussing collective works). An example of a collective work would be an anthology or encyclopedia. Rosen at 27. While the compiler would hold a copyright on the arrangement, the authors (or other owners of the copyright) would retain their copyright in the original piece. Id. “In the software context, a collective work is usually an aggregation of separately written software that is distributed as a single package or on one disk,” such as an office productivity suite. Id. “The copyright in a collective work is a reflection of the originality of the collection and its organizational structure rather than of the individual components.” Id. Most software constitutes a collective work. Id.

14. Joint Works “A ‘joint work’ is a work prepared by two or more authors with the intention that their contributions be merged into inseparable or interdependent parts of a unitary whole.” 17 U.S.C. § 101. Source: 17 U.S.C. § 101; Rosen at 32-33 (discussing joint works). This is different from a collective work. In a collective work each author is the owner of each part independently, whereas a joint owner owns the entire work and can license it, but depending on local law may have to account to the other owners for his or her profits. Rosen at 32-33 (explaining joint works). Source: 17 U.S.C. § 101; Rosen at 32-33 (discussing joint works). This is different from a collective work. In a collective work each author is the owner of each part independently, whereas a joint owner owns the entire work and can license it, but depending on local law may have to account to the other owners for his or her profits. Rosen at 32-33 (explaining joint works).

15. Copyright Chain of Title “The copyright in a compilation or derivative work extends only to the material contributed by the author of such work, and does not imply any exclusive right in the preexisting material. The copyright in such work is independent of, and does not affect or enlarge the scope, duration, ownership, or subsistence of, any copyright protection in the existing material. 17 U.S.C. § 103. Source: 17 U.S.C. § 103; Rosen at 28-30 (discussing chain of title for copyright) Open source software projects may have many different contributors, and thus many different copyright owners. The different parts may be subject to different licenses. Given the terms of most open source licenses, license incompatibility generally is not a problem. See Rosen at 28-30 (explaining chain of title for copyright). Source: 17 U.S.C. § 103; Rosen at 28-30 (discussing chain of title for copyright) Open source software projects may have many different contributors, and thus many different copyright owners. The different parts may be subject to different licenses. Given the terms of most open source licenses, license incompatibility generally is not a problem. See Rosen at 28-30 (explaining chain of title for copyright).

16. Copyright Exceptions for Software The owner of a copy has a right to make a copy; would otherwise be useless The owner of a copy has a right to make a copy for archival purposes. Source: Rosen at 25-26. Source: Rosen at 25-26.

18. Source: U.S. Const. Art. 1 § 8 Cl. 8; 35 U.S.C. §§ 1 et seq. The text of U.S. Const. Art. 1 sec. 8 cl. 8 is provided in an earlier slide. The text of the U.S. Patent Act can be found for free online at http://www.law.cornell.edu/uscode/usc_sup_01_35_10_I_20_1.html. Source: U.S. Const. Art. 1 § 8 Cl. 8; 35 U.S.C. §§ 1 et seq. The text of U.S. Const. Art. 1 sec. 8 cl. 8 is provided in an earlier slide. The text of the U.S. Patent Act can be found for free online at http://www.law.cornell.edu/uscode/usc_sup_01_35_10_I_20_1.html.

19. What is patentable? “[A]ny new and useful process, machine, manufacture, composition of matter, or any new and useful improvement thereof.” 17 U.S.C. § 101 Must be novel, useful, and non obvious and be patentable subject matter. Source: 17 U.S.C. § 101; Patentability, http://en.wikipedia.org/wiki/Patentability Source: 17 U.S.C. § 101; Patentability, http://en.wikipedia.org/wiki/Patentability

20. Source: Rosen at 18 (discussing the difficulty of obtaining patents). Source: Rosen at 18 (discussing the difficulty of obtaining patents).

21. Source: Rosen at 22-24 (discussing protections that patent law provides); 35 U.S.C. § 154 (listing the protections that patent law provides). This is slightly different from the protections that copyright law provides. Copyright law provides the owner of the copyright with the exclusive right to do certain things, whereas a patent only gives a patent holder the right to exclude others from doing certain things. Thus, a patent holder does not have an affirmative right to do anything with the patented invention, because the patented invention may make use of another patented invention. Rosen at 22-24. The distinction between the protections that patent law and copyright law provide is important for open source software licenses. In the copyright grant, the copyright holder gives the licensee all the rights that the copyright holder has. The patent grant grants the licensee the right to “practice patents necessary to make, use, sell or offer for sale, or import the software, but only to the extent of patent claims actually owned or controlled by the licensor.” Rosen at 24. Patents held by third parties may present problems; as the licensor does not own the patents, he or she has no power to grant a license to use them. Rosen at 22-24. Source: Rosen at 22-24 (discussing protections that patent law provides); 35 U.S.C. § 154 (listing the protections that patent law provides). This is slightly different from the protections that copyright law provides. Copyright law provides the owner of the copyright with the exclusive right to do certain things, whereas a patent only gives a patent holder the right to exclude others from doing certain things. Thus, a patent holder does not have an affirmative right to do anything with the patented invention, because the patented invention may make use of another patented invention. Rosen at 22-24. The distinction between the protections that patent law and copyright law provide is important for open source software licenses. In the copyright grant, the copyright holder gives the licensee all the rights that the copyright holder has. The patent grant grants the licensee the right to “practice patents necessary to make, use, sell or offer for sale, or import the software, but only to the extent of patent claims actually owned or controlled by the licensor.” Rosen at 24. Patents held by third parties may present problems; as the licensor does not own the patents, he or she has no power to grant a license to use them. Rosen at 22-24.

22. Copyright Exceptions for Software Owner of a copy has a right to make a copy; would otherwise be useless Owner of a copy has a right to make a copy for archival purposes. See Rosen at 25-26 Source: Rosen at 25-26. Source: Rosen at 25-26.

23. Patent Chain of Title Only one patent owner for any work There is no open source definition for patent licenses Source: Rosen at 32-34 (discussing chain of title for patents). To determine if a potential software project infringes a patent, one would have to do a search of all applicable patents. Doing a patent search is time consuming and costly. Thus, most software companies, open source and proprietary, eschew the process. Rosen at 30-32. Whether that is a good idea is open to question. Source: Rosen at 32-34 (discussing chain of title for patents). To determine if a potential software project infringes a patent, one would have to do a search of all applicable patents. Doing a patent search is time consuming and costly. Thus, most software companies, open source and proprietary, eschew the process. Rosen at 30-32. Whether that is a good idea is open to question.

24. Assigning Ownership Transferring ownership of a copyright, patent or trademark itself, not merely rights associated with it Not usually helpful for open source; an open source license generally provides the same protections that an assignment of ownership would. Source: Rosen at 34-36 (discussing assignment of ownership in the open source context). Assigning ownership means that the copyright or patent holder gives someone else the title to the patent or copyright, rather than some of the rights associated with it. In the open source software context, assigning ownership would be relevant for contributors to a project. In this model, contributors would assign ownership of their copyrights to the manager of the project, rather than license the contribution under an open source license. Id. Source: Rosen at 34-36 (discussing assignment of ownership in the open source context). Assigning ownership means that the copyright or patent holder gives someone else the title to the patent or copyright, rather than some of the rights associated with it. In the open source software context, assigning ownership would be relevant for contributors to a project. In this model, contributors would assign ownership of their copyrights to the manager of the project, rather than license the contribution under an open source license. Id.

25. Unique commercial identifiers are the third type of intellectual property. They are protected by trademark law. Unique commercial identifiers are the third type of intellectual property. They are protected by trademark law.

26. The common law viewed trademark infringement as a form of unfair competition. Trademark infringement at common law was called passing off, as in one merchant passing off his or her goods as those of another. Trademark, http://en.wikipedia.org/wiki/Trademark. The common law viewed trademark infringement as a form of unfair competition. Trademark infringement at common law was called passing off, as in one merchant passing off his or her goods as those of another. Trademark, http://en.wikipedia.org/wiki/Trademark.

27. Source: United States Patent and Trademark Office, What is a trademark?, http://www.uspto.gov/go/tac/doc/basic/trade_defin.htm Source: United States Patent and Trademark Office, What is a trademark?, http://www.uspto.gov/go/tac/doc/basic/trade_defin.htm

28. Source: Rosen at 37-38 (discussing trademarks). In light of the open source principle that work must retain an attribution to its original author, no open source licenses contain a trademark grant. In fact, some open source licenses provide an express reservation of trademark rights. A trademark is important to a merchant, in that customers often buy product based on the trademark of a product, due to the merchant’s reputation for high-quality goods and services. Rosen at 37-38. Such brand name reputation is important way for open source software organizations to make money. Though there may be free software on the market, some of it may be of questionable quality. People are more likely to use software with a well established brand name, such as Red Hat, in order to ensure quality. Id. Source: Rosen at 37-38 (discussing trademarks). In light of the open source principle that work must retain an attribution to its original author, no open source licenses contain a trademark grant. In fact, some open source licenses provide an express reservation of trademark rights. A trademark is important to a merchant, in that customers often buy product based on the trademark of a product, due to the merchant’s reputation for high-quality goods and services. Rosen at 37-38. Such brand name reputation is important way for open source software organizations to make money. Though there may be free software on the market, some of it may be of questionable quality. People are more likely to use software with a well established brand name, such as Red Hat, in order to ensure quality. Id.

30. Source: David Drooz, Open Source Licenses – Basic Information and Examples (2002) Source: David Drooz, Open Source Licenses – Basic Information and Examples (2002)

31. Contracts Must have three things: - Offer - Acceptance - Consideration Source: Common knowledge. The law of contracts requires that three elements be present for a valid contract. There must be an offer, acceptance, and consideration. Consideration means that both parties must exchange something, a quid pro quo. Conditions are not consideration. Source: Common knowledge. The law of contracts requires that three elements be present for a valid contract. There must be an offer, acceptance, and consideration. Consideration means that both parties must exchange something, a quid pro quo. Conditions are not consideration.

33. Software “[A] general term used to describe a collection of computer programs, procedure and documentation that perform some tasks on a computer system.” Wikipedia. Source, Wikipedia, “Computer Software,” http://en.wikipediar.org/wiki/Software Source, Wikipedia, “Computer Software,” http://en.wikipediar.org/wiki/Software

34. Hardware The physical parts of a computer, as opposed to software, which exists inside the computer Source: Wikipedia, “Computer Hardware,” http://en.wikipedia.org/wiki/Computer_hardware Source: Wikipedia, “Computer Hardware,” http://en.wikipedia.org/wiki/Computer_hardware

35. Source: Dennis M. Kennedy, A Primer on Open Source Licensing Legal Issues: Copyright, Copyleft and Copyfuture (2001), available at http://www.denniskennedy.com/opensourcedmk.pdf [hereinafter Kennedy]. There are two types of code that computer programmers use, object code and source code. This distinction is important for an understanding of the open source movement. As later slides will explain, one of the main differences between open source software and traditional proprietary software is the code that accompanies the programs upon distribution. See Kennedy at 2-3. Source: Dennis M. Kennedy, A Primer on Open Source Licensing Legal Issues: Copyright, Copyleft and Copyfuture (2001), available at http://www.denniskennedy.com/opensourcedmk.pdf [hereinafter Kennedy]. There are two types of code that computer programmers use, object code and source code. This distinction is important for an understanding of the open source movement. As later slides will explain, one of the main differences between open source software and traditional proprietary software is the code that accompanies the programs upon distribution. See Kennedy at 2-3.

36. Source Code “Programming statements created by a programmer.” Kennedy at 2 In human readable form Easy to modify Most license agreements do not allow for access to source code Programmers use a compiler to turn it into object code Source: Kennedy at 2. Source code is the form that human computer programmers write code in. It is in human readable form, and may contain notes by the programmer. Source code is easily modifiable. Most distributors of proprietary software do not allow their customers access to source code. After a programmer writes code in source code form, he or she uses a compiler to turn it into object code, which is discussed on the next slide. See Kennedy at 2 (explaining source code); see also http://searchio-midmarket.techtarget.com/sDefinition/0,,sid183_gci539287,00.html (discussing source code and object code and the differences between the two). Source: Kennedy at 2. Source code is the form that human computer programmers write code in. It is in human readable form, and may contain notes by the programmer. Source code is easily modifiable. Most distributors of proprietary software do not allow their customers access to source code. After a programmer writes code in source code form, he or she uses a compiler to turn it into object code, which is discussed on the next slide. See Kennedy at 2 (explaining source code); see also http://searchio-midmarket.techtarget.com/sDefinition/0,,sid183_gci539287,00.html (discussing source code and object code and the differences between the two).

37. Object Code Also called executable code “The instruction sequence for the computer processor.” Kennedy at 2. Not human readable Most software is distributed in object code form Source: Kennedy at 2. As the previous slide explained, there are two types of code that computer programmers use, source code and object code. The first type is object code, which is often called executable code. The term executable code refers to the fact that this type of code is what a computer processor reads to carry out a program. It is typically expressed in binary form, a series of 1s and 0s, and is not readable by humans. When a programmer writes code, he or she writes it in source code form, and uses a compiler to turn it into object code form for the computer to run. The majority of software is distributed in object code form, because distributors do not wish for customers to modify the code. See Kennedy at 2 (discussing object code); see also http://searchio-midmarket.techtarget.com/sDefinition/0,,sid183_gci539287,00.html (discussing source code and object code and the differences between the two). Source: Kennedy at 2. As the previous slide explained, there are two types of code that computer programmers use, source code and object code. The first type is object code, which is often called executable code. The term executable code refers to the fact that this type of code is what a computer processor reads to carry out a program. It is typically expressed in binary form, a series of 1s and 0s, and is not readable by humans. When a programmer writes code, he or she writes it in source code form, and uses a compiler to turn it into object code form for the computer to run. The majority of software is distributed in object code form, because distributors do not wish for customers to modify the code. See Kennedy at 2 (discussing object code); see also http://searchio-midmarket.techtarget.com/sDefinition/0,,sid183_gci539287,00.html (discussing source code and object code and the differences between the two).

38. 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. 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.

39. 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. 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.

40. Is it the same as free software? Generally yes Free software was the original name Open source began being used to allay the concerns of proprietary software companies that were thinking of utilizing or developing free software 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). 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).

41. Prominent Open Source Programs Apache Web Server Mozilla and Firefox web browsers Linux BIND MySQL Source: Kennedy at 1; Rosen at 38. Source: Kennedy at 1; Rosen at 38.

42. Prominent Open Source Vendors IBM Red Hat Sun Microsystems Source: Rosen at 38 Source: Rosen at 38

43. The History of Open Source Richard Stallman, the GNU operating System, the Free Software Foundation, and the General Public License (GPL) Bill Joy, UNIX and the Berkeley Software Distribution License (BSD) Open source comes of age – Linux, Mozilla, Apache et al., and the corporate licenses The Open Source Initiative 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. 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.

44. What are the OSI and the OSD? The Open Source Initiative (OSI) is the de facto standards body for open source software. It determines what open source means, and approves licenses as being open source The Open Source Definition (OSD) is a set of criteria that a license must conform to to be considered open source. The OSI maintains the definition and changes it from time to time. 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 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

45. The Open Source Definition 1. Free Redistribution. “The license shall not restrict any party from selling or giving away the software as a component of an aggregate software distribution containing programs from several different sources, The license shall not require royalty or other fee for such sale.” 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. 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.

46. 2. Source Code. “The program must include source code, and must allow distribution in source code as well as compiled form. Where some form of a product is not distributed with source code, there must be a well publicized means of obtaining the source code for no more than a reasonable reproduction cost, preferably, downloading via the Internet without charge. The source code must be the preferred form in which a programmer would modify the program. Deliberately obfuscated source code is not allowed. Intermediate forms such as the output of a preprocessor or translator are not allowed.” 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]. 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].

47. 3. Derived Works. “The license must allow modifications and derived works, and must allow them to be distributed under the same terms as the license of the original software.” 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. 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.

48. 4. Integrity of the Author’s Source Code. “The license may restrict source-code from being distributed in modified form only if the license allows the distribution of ‘patch files’ with the 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.” 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. 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.

49. 5. No Discrimination Against Persons or Groups. “The license must not discriminate against any person or group of persons.” 6. No Discrimination Against Fields of Endeavor. “The license must not restrict anyone from making use of the program in a specific field of endeavor. For example, it may not restrict the program from being used in a business, or from being used in genetic research” 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.”) 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.”)

50. 7. 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.” 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. 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.

51. 8. 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. If the program is extracted from that distribution and used or distributed within the terms of the program’s license, 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.” 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. 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.

52. 9. License Must Not Contaminate 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 must be open-source software.” 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. 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.

53. 10. License Must Be Technology Neutral. “No provision of the license may be predicated on any individual technology or style of interface.” 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. 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.

54. 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. 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.

55. 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. 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.

56. The GPL family of licenses Basic rights under the GPL – access to source code, right to make derivative works “Copyleft” The Library or Lesser General Public License 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. 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.

57. The BSD family of licenses Same basic rights as GPL No copyleft provisions, i.e. licensees can take software licensed under the BSD private Can re-release software under a different license 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. 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.

58. Mozilla/corporate licenses More expertly drafted Serve as a model for later commercial licenses Different provisions on relicensing No copyleft 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. 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.

59. Other Open Source Licenses There are over fifty (50) other open source licenses The IBM Common Public License, the MIT X license, and the Artistic License are examples The open source community discourages writing one’s own license in order to prevent license proliferation 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). 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).

60. Shareware/Freeware May be free or may not Licensor does not provide the right to make derivative works or give access to source code 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. 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.

61. Public Domain Author retains no copyright rights if software is in the public domain Open source software authors retain copyright rights Open source licenses contain restrictions, just different ones than licensees may be used to The restrictions in open source licenses are based on copyright law and depend on it for their effectiveness. 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). 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).

62. 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. 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.

63. 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. 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.

64. Problems with the GPL Linking to GPL programs No explicit patent grant Does no discuss trademark rights Does not discuss duration Silent on sublicensing Relies exclusively on license law, not contract 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. 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.

65. The Library or Lesser General Public License (LGPL) Written to deal with the linking problem in the GPL discussed above Provides that programs that merely link to a program in a library are not subject to copyleft If licensee makes a derivative work of the library, copyleft applies 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. 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.

66. The Berkeley Software Distribution License (BSD) No copyleft/reciprocity provision Does not mention patents 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. 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.

67. Other BSD type academic licenses MIT Apache Artistic License 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). 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).

68. The Mozilla Public License (MPL) Professionally written Includes an explicit patent grant, including a reciprocal grant for contributors Includes many specific provisions that are absent in the GPL and BSD but which are often in licenses. 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). 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).

69. The Common Public License (CPL) Developed and owned by IBM Includes a limited patent license Contains a reciprocity provision Contains a patent defense provision Indemnity provision 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). 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).

70. The Open Source License and the Academic Free License Mirror images of each other, except the AFL does not include reciprocity provisions and the OSL does Addresses aspects of copyright left out by other licenses, such as scope and duration Grants a patent license Retains name and trademark of licensor 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. 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.

71. Multiple Licensing and other strategies Microsoft’s Shared Source License Public Source Multiple Licensing Licensing in phases 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). 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).

73. 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]. 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].

74. Benefits Increased user base Longer useful life Increased stability Security Scalability Innovation Cost Adaptability 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) . 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) .

75. How do licensors make money with open source software? Usually by providing other services, such as: Support Training Customization Integration Certification Offering warranties source: http://en.wikipedia.org/wiki/Free_software; Eric S. Raymond, The Magic Cauldron, available at http://www.catb.org/~esr/writings/magic-cauldron/ source: http://en.wikipedia.org/wiki/Free_software; Eric S. Raymond, The Magic Cauldron, available at http://www.catb.org/~esr/writings/magic-cauldron/

77. 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. 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.

78. Creative Commons Creative Commons Licenses Baseline rights Various Licenses Creative Commons International 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 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

79. Other Open Content Organizations Creative Commons International http://creativecommons,org/international/ Science Commons (a Creative Commons Project) http://sceincecommons.org Open Educational Resources Commons (OER) http://www.oercommons.org/ Open Content (http://www.opencontent.org/ For more see the Google Directory, http://www.google.com/Top/Computers/Open_Source/Open_Content/ (providing a list of websites dedicated to open source)

80. Other open content licenses include: GNU Free Documentation License Open Content License Free Art License Open Game License October Open Game License Source: http://www.google.com/Top/Computers/Open_Source/Open_Content/Licenses/Source: http://www.google.com/Top/Computers/Open_Source/Open_Content/Licenses/

81. Considerations before licensing with Creative Commons or other open content license Make sure you understand what rights you are retaining and which ones you are giving up Make sure you own the copyright Make sure your work is subject to copyright law “Be specific about what you are licensing” (creative commons FAQs) The source of this slide is the Creative Commons FAQs http://creativecommons.org/FAQThe source of this slide is the Creative Commons FAQs http://creativecommons.org/FAQ

84. On the business issues: Eric S. Raymond, The Magic Cauldron, available at http://www.catb.org/~esr/writings/magic-cauldron/magic-cauldron.html/, (discussing how to make money on open source) 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 and discussing the benefits of open source versus proprietary software)

85. Lists of open source projects http://freshmeat.net http://sourceforge.net

86. On open source software generally Eric S. Raymond, The Cathedral and the Bazaar: Musings on Linux and Open Source by an Accidental Revolutionary (O’Reilly Media 2001), available at http://www.catb.org/~esr/writings/cathedral-bazaar/ The book that inspired Netscape to release its Mozilla web browser as an open source project. The book that inspired Netscape to release its Mozilla web browser as an open source project.

88. Like anything else, open source has both risks and benefits (for licensors and licensees) They are neither an unmitigated good, nor particularly dangerous. Before using them, either to license your work or accepting work subject to them, you should evaluate your own situation and make an individual determination. General information cannot take into account your particular circumstances

89. And on a similar note, remember . . . This presentation is not legal advice. Legal advice can only be provided with regards to specific factual circumstances in the context of an attorney-client relationship. This presentation does not establish an attorney-client relationship. If you have any further questions that you are unable to answer yourself after reasonable efforts, contact the Department of Legal Affairs, 304 Holladay Hall, 515-3071