Putting Open Source Dynamic Languages through the Licensing Test: A guide to most popular licenses and their implications
•Télécharger en tant que PPT, PDF•
1 j'aime•461 vues
Open source software is becoming increasingly pervasive in the enterprise today. It is easily accessible online and included in products without full visibility into the diverse set of licenses that govern its use and redistribution. Often times, development teams are not fully aware how open source impacts the level of intellectual property (IP) and legal risk exposure. There are many developers who bristle at the very use of the term “intellectual property.” The Free Software Foundation (FSF) places it among “Phrases that are Worth Avoiding”. There are effective solutions to minimize the level of legal exposure stemming from open source software and continue to use it to propel innovation, accelerate time to market and gain a competitive advantage. Join Van Lindberg, acclaimed lawyer from Haynes and Boone LLP and author of the popular book Intellectual Property and Open Source and Bart Copeland, President and CEO of ActiveState, the Dynamic Language Experts to: * Understand the distinction between free software and open source software * Learn about the concepts of copyright, patents, copylefts and trademarks * Discover common open source licenses and their implications in enterprise development * Gain practical knowledge on how to protect your code and avoid IP issues * Get insights into effective commercial solutions to minimize legal exposure
![Putting Open Source Dynamic Languages Through the Licensing Test Van Lindberg Haynes and Boone, LLP [email_address] 972-739-8638 June 16, 2010](https://image.slidesharecdn.com/linbergwebinarforslidesharepolls-100707180845-phpapp01/85/Putting-Open-Source-Dynamic-Languages-through-the-Licensing-Test-A-guide-to-most-popular-licenses-and-their-implications-1-320.jpg)
Recommandé
Contenu connexe
Plus de ActiveState
Plus de ActiveState (20)
Dernier
Dernier (20)
Putting Open Source Dynamic Languages through the Licensing Test: A guide to most popular licenses and their implications
- 1. Putting Open Source Dynamic Languages Through the Licensing Test Van Lindberg Haynes and Boone, LLP [email_address] 972-739-8638 June 16, 2010
- 5. Open source licensing (copyright)
- 6. Licenses: Free, “Free” and Open Source
- 8. Licensed cc-by by veggiefrog: http://www.flickr.com/photos/veggiefrog /
- 22. Questions? Van Lindberg Haynes and Boone, LLP van. [email_address] .com 972-739-8638
Notes de l'éditeur
- A lawyer who specializes in open source will almost always be brought in via the call. Variations of this call exist for almost every branch of law. It goes something like this: Caller: Hello. I am calling to ask about open source software. Lawyer: Great! What can I do for you? Caller: Well, we have a product shipping out next week, and we just found out one of our engineers used open source in our product. We don’t want to release the source code, but we don’t know what to do. Can you help us? What I am going to talk about today is what an open source lawyer actually do after he receives the phone call.
- As they teach you here in law school, the first thing you need to do is frame the issues. What is open source? Most people can’t give a definition of open source, even those who work with open source projects on a day-to-day basis. There are lots of definitions out there, but I think the best definition is that open source is a framework that allows people to share and trade intellectual property. This is different from traditional software licensing, where you typically trade intellectual property for money; with open source licenses you trade code—intellectual property—for other code. How is that different from traditional software licensing? Under traditional software licensing, companies own the copyrights to all the software they distribute. (In some cases, there are portions of the code licensed from somebody else, but to the consumer, it all looks the same—the company owns the code). The source code is usually considered secret, and use of the compiled binaries is tightly controlled by license. Open source projects are owned by their communities, or more precisely, by their contributors. In a typical open source project, each contributor maintains copyright to the code he contributes to the project. By agreeing to share the code, the coder in turn receives the benefit of the code shared by everyone in the project. Open source licenses provide the structure by which all contributors agree to share and cooperate in the development of the code. Use of the compiled binaries is typically unrestricted. Open source software, like other software, is primarily controlled via copyright. Source code is copyrighted as soon as it is created and fixed in a tangible medium – in this case, the computer disc. Copyright holders allow others to use the software by granting a license, which is a specialized contract allowing someone to exercise some of the exclusive rights under copyright in return for consideration. In typical software contracts, the consideration takes the form of money paid to the copyright holder. In open source licenses, the consideration takes the form of restrictions on the modification and distribution of the code.
- What is open source? Most people can’t give a definition of open source, even those who work with open source projects on a day-to-day basis. There are lots of definitions out there, but I think the best definition is that open source is a framework that allows people to share and trade intellectual property. This is different from traditional software licensing, where you typically trade intellectual property for money; with open source licenses you trade code—intellectual property—for other code. How is that different from traditional software licensing? Under traditional software licensing, companies own the copyrights to all the software they distribute. (In some cases, there are portions of the code licensed from somebody else, but to the consumer, it all looks the same—the company owns the code). The source code is usually considered secret, and use of the compiled binaries is tightly controlled by license. Open source projects are owned by their communities, or more precisely, by their contributors. In a typical open source project, each contributor maintains copyright to the code he contributes to the project. By agreeing to share the code, the coder in turn receives the benefit of the code shared by everyone in the project. Open source licenses provide the structure by which all contributors agree to share and cooperate in the development of the code. Use of the compiled binaries is typically unrestricted. Open source software, like other software, is primarily controlled via copyright. Source code is copyrighted as soon as it is created and fixed in a tangible medium – in this case, the computer disc. Copyright holders allow others to use the software by granting a license, which is a specialized contract allowing someone to exercise some of the exclusive rights under copyright in return for consideration. In typical software contracts, the consideration takes the form of money paid to the copyright holder. In open source licenses, the consideration takes the form of restrictions on the modification and distribution of the code.
- The leading case dealing with open source software in the United States is Jacobsen v. Katzer. The Jacobsen court held that an open source license may set conditions limiting the use of copyrighted material, and that a violation of such conditions constitutes an act of copyright infringement.
- The Jacobsen case just settled, and the terms of the settlement are public. For distributing $1,200 worth of infringing product—approximately 20 infringing sales—Katzer agreed to the following settlement: 1. Payment of $100,000 plus costs and attorneys fees. 2. A permanent injunction prohibiting Katzer from reproducing, modifying or distributing “JMRI Materials.” “JMRI Materials” are defined as “any expression made available to the public as part of the JMRI project.” A permanent injunction against using any trademarks or registering any domain names using terms associated with the JMRI project In spite of some limitations, Jacobsen is generally recognized as standing for the general proposition that open source licenses are enforceable under copyright. One area that has not been well explored by the courts, including the Jacobsen court, however, is the scope of derivative works as applied to software. Reciprocal open source licenses rely on the copying and derivative works provisions of copyright law to determine their scope. For example, the GNU General Public License (GPL) applies to “either the Program or any derivative work under copyright law.” The definition of a “derivative work,” however, can be unclear—leading to uncertainty in the scope of some open source licenses.
- The copyright statute states that a collective work (or compilation) is created when a person brings together “preexisting materials or...data...in such a way that the resulting work as a whole constitutes an original work of authorship.” Statute: A “collective work” is a work, such as a periodical issue, anthology, or encyclopedia, in which a number of contributions, constituting separate and independent works in themselves, are assembled into a collective whole. A “compilation” is a work formed by the collection and assembling of preexisting materials or of data that are selected, coordinated, or arranged in such a way that the resulting work as a whole constitutes an original work of authorship. The term “compilation” includes collective works.” In a software context, you can create a collective work when you combine different pieces of software without making changes to the individual pieces. The importance of collective works is that the copyrights on each independent portion of the collection, and on the collection as a whole are all independent. Relative to the GPL, this means that the author of an original program that is subsequently used in a collective work cannot require any other program in the collective work to be licensed under the GPL.
- Statute: A “derivative work” is a work based upon one or more preexisting works…in which a work may be recast, transformed, or adapted. A work consisting of editorial revisions, annotations, elaborations, or other modifications, which, as a whole, represent an original work of authorship, is a “derivative work”. Sometimes, however, a derivative work can be created via “annotations” and “elaborations” on a base work. In other words, a work may be considered a derivative work if it layers additional creative expression on top of an underlying original work, even if there are no changes to the underlying work.