Open Source Licensing
for Technology Transfer Professionals
Open source licenses “are used by software developers, scientists, authors, artists, and educators who want to create collaborative projects and to dedicate their works to the public.” [1] “Without license information, third parties may (and should) assume that the default rules of copyright apply, i.e. that they have no permission to copy, modify, or redistribute the code.” [2]
This report contains a compilation of information about open source licensing and related non-commercial methods of distributing copyrighted works, along with some distinctions between different types of licenses.
Terminology
The core concepts of Open Source may be best communicated by defining some common terms.
“Open Source”
Generally, this term is used to refer to a method of distributing and/or developing software in which the source code (the human-readable form of the program) is published for review and comment by the general public. By contrast, most software is developed in a proprietary environment in which the source code is protected from viewing by the public, and only the object code (the binary/machine-readable form of the program) is distributed. Open source development usually aims to utilize crowd-sourcing to achieve faster, cheaper, and more effective improvements to software that has not yet been developed to commercial-release quality.
A more specific definition is offered by the Open Source Initiative, listing 10 criteria that must be satisfied for a software license to be “open source.” [3] Since its inception in the software development world, however, the term “open source” has been applied in a wide variety of other areas (including biotechnology) [4] to describe a similarly open development environment.
Regardless of the terminology, the actual rights with respect to reproductions, distributions, and derivative works of an open source copyrighted work will be outlined in the license. In general, any common open source license will include: 1) the terms and conditions that the author requires to allow copying, distributing, etc. of the work; and 2) a disclaimer explaining that the author provides no warranty regarding the use of the copyrighted work (i.e., it is provided “as is” and the author can’t be held liable for any damage that it causes).
“Open …”
Several variations of the open source idea have been applied to other areas of research and development. “Open Access” and “Open Transfer” are terms that have been used to refer to methods of distributing information and tools (respectively) among researchers in order to avoid the complications and restrictions of copyrights and patent rights.
Though this concept is most common among independent programmers and academics, the idea has also spread to the corporate world. According to Henry Chesbrough (originator of "open innovation"):
"Open innovation . . . falls directly in that gap between business and academe. Conceptually, it is a more distributed, more participatory, more decentralized approach to innovation, based on the observed fact that useful knowledge today is widely distributed, and no company, no matter how capable or how big, could innovate effectively on its own.
Open innovation is ‘the use of purposive inflows and outflows of knowledge to accelerate internal innovation, and expand the markets for external use of innovation, respectively.’" [5]
Public Domain
It is important to distinguish “open source” from “public domain.” Copyright law vests ownership of copyrights in a work to the author as soon as it is created and fixed in a tangible form of expression. When an author dedicates his work to the public domain (or his copyright expires), he can no longer protect his work from distribution or use by others in any way. Open source licensing, by contrast, has “strings attached” that restrict how a work is used. Those “strings” will vary based on the type of license.
“Copyleft”
This term is used to describe a license that “provid[es] published code for use but require[es] any modifications, amendments, or derivative works resulting from that published code remain publicly available for review and use. To this end, the copyleft license requires that, to the extent that any derivative work is released, that derivative work will be released with the published source code and with the right to use that derivative work for any purpose.” [6]
Viral
A term used to describe the copyleft’s requirement that the same type of license must be attached to any software that uses, incorporates, or is derived from the original software. [7] In this way, the restrictions of the original license can spread out to cover a range of more developed software that may be only minimally related to the original work.
Dual Licensing
This type of licensing allows two different licenses for a single software product. “One license, which imposes open source terms, is available to a certain class of users. A second license, with proprietary terms, is available to others.” [8]
Creative Commons -- Non-Software Applications
The core concepts of open source have been replicated in “Creative Commons” licenses. According to the non-profit organization that created this suite of licensing tools:
“Our free, easy-to-use copyright licenses provide a simple, standardized way to give the public permission to share and use your creative work — on conditions of your choice. CC licenses let you easily change your copyright terms from the default of “all rights reserved” to “some rights reserved.”
Creative Commons licenses are not an alternative to copyright. They work alongside copyright and enable you to modify your copyright terms to best suit your needs.”
Though these licenses could be applied to software, they are generally geared towards creative works such as photos, songs, videos, and academic and literary writing. The Creative Commons organization doesn’t recommend using their licenses for software because they are generally not compatible with other software licenses and don’t include terms specific to the distribution of source code. [9]
For other copyrighted works, however, Creative Commons provides a range of options that allow the copyright owner to restrict modifications, commercial use, and the attachment of other licensing terms to copies or derivatives of the work. Six license variations are offered (see below), and the website provides a tool to help choose which license is right for a particular work: http://creativecommons.org/choose/.
Types of Open Source Licenses
When an author determines that a “standard” open source license is desired, he has many options to choose from. The variety of open source licenses may be split into two categories – “Less Restrictive” and “Copyleft.”
“Less Restrictive” or “Permissive” Licenses
There are two main features of this category of licenses that a copyright owner (especially one that is affiliated with a university or other institution) must be aware of:
“These licenses, as applied to the original licensed code, allow the code to be used in proprietary software and do not require that open source versions of the code be distributed. Projects created under these licenses, or derived from such code, may go closed and [be] released under a proprietary license.” [10]
“Some commonly used less-restrictive licenses contain grants to any patent rights held by the developer and necessary to use the code being distributed. The problem with this clause for a university is quite clear. It can reduce the value of any patents the university owns on inventions that are embodied in the open source code as it freely grants licenses to any party that also takes a license to the software.” [11]
These features tend to make this type of license less attractive for developers in a research or academic setting (where the open source model is being used to enable further research, rather than result in a commercialized product). They may be more appropriate for a developer who wishes to encourage proprietary developers to incorporate his work into a range of other software and/or hardware products. A developer can also use this type of license to improve software that he intends to commercialize himself (especially if there are no associated patent rights to worry about), but he runs the risk of inviting competition from fellow developers.
These are some well-known examples of the “less restrictive” license approach:
Massachusetts Institute of Technology (MIT, X11, or MIT X) License – Perhaps the simplest and least restrictive license commonly used for software, it only requires that any distribution or derivative work includes the original copyright notice and permission statement language of the license.
Apache License – The less restrictive approach allows this to be modified and used to run web servers on a variety of different devices. It is “similar to the MIT License, but also provides an express grant of patent rights from contributors to users.” [12] This makes it preferable to developers who are worried about potential patent infringement related to the use of the software (i.e., subsequent contributors claiming patent rights for related methods and thus preventing free use of the software). Though it is fairly complex (compared to the MIT License), it can be applied to a work with a short boilerplate notice that references the full license available at the www.apache.org website.
Berkeley Software Distribution (BSD) – “The BSD license is a class of extremely simple and very liberal licenses for computer software that was originally developed at the University of California at Berkeley (UCB). It was first used in 1980 for the Berkeley Source Distribution (BSD), also known as BSD UNIX, an enhanced version of the original UNIX operating system.” [13] The most common versions of this license are the “2-Clause” and “3-Clause” versions. Both versions include the basic requirements of the MIT License, but the “3-Clause” version also includes a restriction on the use of the author’s name to “endorse or promote” derivative works.
“Copyleft” Licenses
As described above, copyleft licenses require that any derivative work contains the same “viral” restrictions that the original work contained. Depending on one’s perspective, they may be described as more “liberal” (because they encourage free use and modification of the software) or as more “restrictive” (because they require subsequent developers to comply with more burdensome license terms). This may be a good choice for software that has little commercial potential on its own, but shows promise as a general research tool or as a basis for indirect commercialization (i.e., monetizing the work by offering related products or services). These are the most well-known examples of the “copyleft” license approach:
GNU General Public License (GPL) – This is the most popular license used for free software. Compared to the less restrictive licenses above, it is relatively long and detailed. Its general form has been in use for over two decades, and has undergone revisions over the years to protect its “free software” ideals from exploitation. These ideals are based on free access to the source code, not necessarily price (so they don’t prevent someone from charging a service fee for conveying the software to someone else). The most current version, GPLv3, also includes a patent grant (much like the Apache License) that prevents contributors from enforcing any patent rights related to their contributions (which would effectively make the software proprietary).
Lesser GPL – This version of the GPL reduces the “viral” nature of the license to allow use of the software as part of a “combined work” that may be offered on a proprietary basis. This may be preferable for libraries [14] or other works that are intended to be incorporated into a wide range of other software (or hardware) without requiring those developers to make their own source code open.
Affero GPL – Nearly identical to the GPL, this version includes an extra condition to ensure that people who use the software over a network will be able to get the source code for it.
GNU Free Documentation License (GFDL) – A strong copyleft license for educational works, this license was initially written for software manuals. It includes terms which specifically address common issues that arise when reference or instructional works are distributed or modified.
General Recommendations
The Free Software Foundation (FSF), one of the leading organizations promoting open source software, makes this general recommendation: “For most programs, we recommend that you use the most recent version of the GNU General Public License (GPL) for your project. Its strong copyleft is appropriate for all kinds of software, and includes numerous protections for users' freedom.” [15] However, they note three exceptions:
For small programs (approximately 300 lines of code or less), they recommend the Apache License 2.0 because it avoids the complexities of copyleft (usually unnecessary for a small program), yet provides protection from a “bait and switch” scenario (where a third party distributes the software for free but requires recipients to pay for its use under a patent license).
Libraries are distinguished by the FSF based on their “ethical” objectives. A library author who wishes to provide a free alternative to a proprietary standard (e.g., Ogg Vorbis as a free alternative to the proprietary MP3 audio) is encouraged to use the Apache License 2.0. All other libraries should use the GPL [16] or LGPL, depending on whether or not the features of the library are already available for free elsewhere. [17] The LGPL would permit the library to be used in proprietary software, and would thus be more attractive to commercial developers than other, more restrictive alternatives.
They also make a special recommendation for server software: “If it is likely that others will make improved versions of your program to run on servers and not distribute their versions to anyone else, and you're concerned that this will put your released version at a disadvantage, we recommend the GNU Affero General Public License (AGPL).”
Technology Transfer Perspectives
“The open source development model, whether under less-restrictive licenses, the GPL, or the LGPL, appears to be here to stay, and it may work well for many projects and efforts where a royalty stream is unlikely or unnecessary. However, copyright holders should take care to understand the open source model before embarking on an open source strategy. In particular, universities should evaluate how their community currently uses open source software, whether the advantages of open source software development apply to them, and whether their licensing goals are consistent with the GPL.” [18]
Considerations and Examples of University Open Source Policies
When deciding between open source licenses, the following considerations may be helpful.
“The most important thing is to clearly understand what the goals of the faculty are:
Do they simply want it to be free of charge?
Do they want to distribute executable code or source code?
Do they want to allow derivative works?
Do they want to allow licensees to distribute it further?
Do they want licensee derivative works back?
What is their real goal in making this open source?
Technology managers should discuss all of these issues carefully with faculty prior to releasing software under any open source (or free) license.” [19]
These are examples of the guidance provided by universities and research institutions toward open source licensing:
MIT Technology Licensing Office
"The MIT Technology Licensing Office receives many requests from MIT faculty and staff regarding distributing software via an open source license, without fee or royalty. The TLO supports this approach if the authors of the software feel it is an appropriate distribution method for the software in question, provided that there is not an active sponsored research grant that would prevent such distribution and such distribution has been approved by the head of the relevant department, laboratory, or center."
See http://web.mit.edu/tlo/www/community/software.html
“Generally, the Technology Licensing Office supports those MIT software developers who choose to essentially give their programs away through open source mechanisms, provided MIT retains the right to distribute the program freely and that “open sourcing” is consistent with obligations to third parties, such as sponsors. However, since there are many different varieties of “open sourcing,” it is recommended that you contact the Technology Licensing Office to obtain advice on appropriate notices to put on your open-sourced software.”
See http://web.mit.edu/tlo/www/downloads/pdf/inventors_guide.pdf
University of California, Berkeley Office of Technology Licensing
“There are many different types of licenses that can be used to release software, depending on the form in which the code is being released (source or object), what rights the licensee will have in the software, and whether the software is protected by patent as well as copyright. Options include licenses that allow commercial use, licenses that allow only non-commercial or academic use, open source licenses, and many others. The OTL can work with the authors/inventors to determine the licensing program that best meets your needs.”
See http://ipira.berkeley.edu/frequently-asked-questions
MITRE Corporation (Federal Government R&D Contractors)
“In cases where it is beneficial for our sponsors and stakeholders, MITRE makes its intellectual property available through open source licenses.”
See http://www.mitre.org/research/technology-transfer/open-source-software
Stanford University Office of Technology Licensing
“HOW DO WE DECIDE WHETHER TO COMMERCIALIZE software WITH A TRADITIONAL OR AN “OPEN SOURCE” LICENSE? Creators of copyrighted software can put their works in the public domain as long as doing so does not conflict with Stanford’s contractual obligations and it is in the interest of technology transfer. “Open sourcing” is different from “public domaining”. In order to open source the code, you must be certain you have the right to do so. (All of the contributors must agree to open source the software which must not contain any third party code.)”
“There are many kinds of open source licenses, all of which have strings attached to the license. (See open source licenses at http://www.opensource.org/licenses/). Kinds of licenses range from BSD (mostly a permission to use and requirement to give proper attribution, copyright remains with the University) to GPL (all subsequent users must keep derivative software open sourced.) The University does not make any particular recommendations as to which open source license is preferable.”
See http://otl.stanford.edu/inventors/resources/inventors_opensource.html
See the Inventor’s Guide at http://otl.stanford.edu/documents/OTLinventorsguide.pdf
University of Michigan Tech Transfer Office
“How do we decide whether to commercialize with a traditional or an “open source” license for software? Generally, U-M Tech Transfer supports University software developers who choose to essentially give their programs away through open source mechanisms, provided the University retains the right to distribute the program freely, that open sourcing is consistent with obligations to sponsors, and that each developer’s unit supports the decision. Developers should seek authorization from an appropriate department chair or dean.”
See http://www.techtransfer.umich.edu/resources/inventors/faq.php
University of Illinois Offices of Technology Management
“As with decisions for publication, the faculty or head of the research program makes the recommendation for open source dissemination. Often, the decision to release code into the open source is made early in the software development process: as a condition of the funding, as a requirement of participation in the software community, or as a consequence of incorporating third party code that requires placement in the open source. When software is placed in the Open Source, it is usually through the University of Illinois or NCSA Open Source License. This license places minimal restrictions on use, thereby maximizing flexibility of use and dissemination. The University of Illinois license can be viewed at http://www.opensource.org/licenses/UoI-NCSA.php.
“Even though such transfers and dissemination are not revenue generation to the University, they promote visibility and public use of University research and potentially aid in the University’s mission for public good.”
See http://otm-info.uic.edu/Inventors_Handbook/Technology_Transfer_Process.pdf
University of Texas Office of Technology Commercialization
“OTC suggests the following as appropriate open source or source-available licenses:
GPL, version 2 (note: v2 only)
BSD 3-Clause (“BSD New”)
LGPL (note: v2.1 only)
OTC can assist software creators in selecting the appropriate form of open source license or other method of publication based on:
The goals of the creators
The perceived commercial value of the software
Third-party restrictions applicable to the software”
See http://www.otc.utexas.edu/licensing.jsp#Software
Penn State University Office of Technology Management
“Generally, OTM supports University software developers who choose to essentially give their programs away through open source mechanisms, provided the University retains the right to distribute the program freely, that open sourcing is consistent with obligations to sponsors, and that each developer’s unit supports the decision. Developers should seek authorization from an appropriate department chair or dean.”
University of Colorado Technology Transfer Office
“The primary ways that university research makes impact is through publication in the open literature and training of students. The Creative Commons and open source licensing are legal tools that can be applied to copyrighted works and software to provide clear rights to users and collaborators. CU Tech Transfer is supportive of open source software release, and can provide advice on appropriate tools.”
See https://www.cu.edu/techtransfer/freeware-shareware
Carnegie Mellon University Center for Technology Transfer and Enterprise Creation
“CMU prefers the use of some open source licenses over others. Some issues to consider include:
Do you want the uses to be limited to educational, research or non-commercial?
Do you want the source code to be available?
Do you want to limit distribution rights?
Are users required to provide alterations back to you and/or make them publicly available as well under the same agreement?
Can others charge for products that use the code? (e.g. Redhat)
Are users required to keep an attribution to the original authors?”
See http://www.cmu.edu/cttec/resources/index.html
University of Minnesota Office for Technology Commercialization
“Open source releases are ideal for projects that need additional improvement or maintenance. An open source release can be a bridge to build a community of users that together enhance the impact and value of the software or copyrighted tool. The University engages in two primary strategies for open source commercialization:
Dual Licensing – Source code is freely available for non-commercial groups, and individuals willing to share their contributions back to the open source community. Groups not willing to share their contributions are required to take a different license.
Loss Leader – Core/common source code is freely available, and new/premium addons are sold separately. “
See http://www.research.umn.edu/techcomm/software-information-technology.html#.VQHfFfw7uSr
Additional Considerations for Funded Projects
A license can only provide terms and conditions based on the rights that can validly be granted by the licensor. When software is created within a project funded by outside sources (e.g., grants, federal funding, etc.) or in collaboration with another organization, the ownership of the software (and thus, the ability to grant rights through a license) must first be determined.
If the software is created by a government employee, it may be considered a "Government Work" (in which case, there is no copyright). See http://www.usa.gov/copyright.shtml#What_is_a_U.S._Government_Work?
If the software is created by multiple authors, it may be considered a “joint work,” with each author having ownership. However, “while the Copyright law provides that authors of a joint work are co-owners of the work, the law regarding how much the Government, as a joint author, may own is unsettled and thus open to differing interpretations.” [20]
Software created by independent authors under contract with the government may also have ownership issues. "Unlike works of the U.S. Government, works produced by contractors under government contracts are protected under U.S. Copyright Law. (See Schnapper v. Foley, 667 F.2d 102 (D.C. Cir. 1981), cert. denied, 455 U.S. 948 (1982).) The ownership of the copyright depends on the terms of the contract. Contract terms and conditions vary between civilian agencies or NASA and the military." [21]
If funding is provided by a non-governmental entity, the software could still be considered a "work for hire" (defined here: http://www.copyright.gov/circs/circ09.pdf). In this case, each of the authors' employers would need to agree to the license terms and be acknowledged in the copyright notice attached to it (because the employers would actually be the owners of the copyright).
Tools and Resources
A wide variety of online tools are available to help an author choose an open source license. The following resources provided general information for this report, as well as information specific to university-based software licensing.
Organizations
OSS Watch
“OSS Watch provides unbiased advice and guidance on the use, development, and licensing of free software, open source software, and open source hardware.”
License Differentiator Tool – Based on your answers to 7 questions, this tool provides recommendations on which open source license to use.
See http://oss-watch.ac.uk/apps/licdiff/
Open Source Initiative
“The Open Source Initiative (OSI) is a global non-profit that supports and promotes the open source movement. Among other things, we maintain the Open Source Definition, and a list of licenses that comply with that definition.”
Free Software Foundation
“The FSF provides critical infrastructure and funding for the GNU project, the foundation of the popular GNU/Linux family of free operating systems and the keystone of the Internet. Our Campaigns Team creates educational materials about free software, convenes the yearly Libre Planet conference and goes toe to toe against powerful interests that threaten computer user rights. Our Licensing & Compliance Lab defends freely licensed software from proprietary hoarding, advises on licensing issues, and certifies devices that Respect Your Freedom.”
Compilation of materials provided by the University of Texas
Open Source Toolkit for University Technology Managers (2009)
http://www.otc.utexas.edu/publications/OpenSourceToolkit_Feb2009.pdf
Stanford OTL, Open Source Primer for Stanford Software Creators
http://otl.stanford.edu/inventors/resources/inventors_opensource.html
Software Freedom Law Center, Managing copyright information within a free software project
“The copyright and license information maintained by a free software project is the primary record of the project’s ownership and license structure. By following the guidelines above, projects can improve that record’s usefulness and hopefully save effort down the road, should a license change become necessary or a license dispute arise.”
http://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
Articles
ZDNet, HOWTO: Pick an open source license (2006)
“Let's say you've made the decision to release your code as "open source". What does that mean, what is an open source license, and how do you pick the right one? This question comes up all the time so I thought I'd write up a simple decision tree to try to explain the choices.”
http://www.zdnet.com/article/howto-pick-an-open-source-license-part-1/
http://www.zdnet.com/article/how-to-pick-an-open-source-license-part-2/
Codebender Blog, FLOWCHART: WHICH OPEN SOURCE LICENSE SHOULD I USE?
“There are many resources on the Web that provide comparison of the available licenses. I want to make it simpler by creating a flowchart to guide you to pick the right license for your project. To reduce confusion, I’ll only list the most common open source licenses.”
http://codebender.denniland.com/flowchart-which-open-source-license-should-i-use/
Various articles describing software developers’ perspectives on open source licensing options:
http://www.smashingmagazine.com/2010/03/24/a-short-guide-to-open-source-and-similar-licenses/
http://blog.codinghorror.com/pick-a-license-any-license/
http://haacked.com/archive/2006/01/24/DevelopersGuideToOpenSourceSoftwareLicensing.aspx/
http://nrecursions.blogspot.in/2014/05/a-simplified-reference-to-various.html
https://www.gnu.org/philosophy/license-list.html
Additional articles with license comparison charts:
http://stackoverflow.com/questions/2625167/is-there-an-open-source-licence-matrix
https://blogs.oracle.com/davidleetodd/entry/free_and_open_source_license
References
Bloomberg BNA Report, “Intellectual Property, Software, and Information Licensing: Law and Practice, Supplement to Ch.7 Copyright Licensing” (2006).
http://softwarefreedom.org/resources/2012/ManagingCopyrightInformation.html
Robin Feldman and Kris Nelson, Open Source, Open Access, and Open Transfer: Market Approaches to Research Bottlenecks, 7 Nw. J. Tech. & Intell. Prop. 14 (2008). http://scholarlycommons.law.northwestern.edu/njtip/vol7/iss1/2
AUTM Tech Transfer Practice Manual - Open Source Software Licensing (2010) http://www.autm.net/AM/Template.cfm?Section=Volume_3_TOC&Template=/CM/ContentDisplay.cfm&ContentID=4438
AUTM Tech Transfer Practice Manual - Software Licensing (2010) http://www.autm.net/AM/Template.cfm?Section=Volume_3_TOC&Template=/CM/ContentDisplay.cfm&ContentID=4439
University of Texas - Open Source Toolkit for University Technology Managers http://www.otc.utexas.edu/publications/OpenSourceToolkit_Feb2009.pdf
See reference #6 above – AUTM Tech Transfer Practice Manual.
Id.
BSD License Definition, http://www.linfo.org/bsdlicense.html.
Collections of code or related data that help a program achieve more functionality or automate a standard process. See http://www.techopedia.com/definition/3828/software-library.
“How to choose a license for your own work,” http://www.gnu.org/licenses/license-recommendations.html
“Using the ordinary GPL for a library gives free software developers an advantage over proprietary developers: a library that they can use, while proprietary developers cannot use it,” http://www.gnu.org/licenses/why-not-lgpl.html.
“In that case, the library cannot give free software any particular advantage, so it is better to use the Lesser GPL for that library,” http://www.gnu.org/licenses/why-not-lgpl.html.
See reference #6 above – AUTM Tech Transfer Practice Manual.
See reference #7 above – AUTM Tech Transfer Practice Manual.
CENDI Copyright Working Group, “Frequently Asked Questions About Copyright - ISSUES AFFECTING THE U.S. GOVERNMENT,” http://www.cendi.gov/publications/04-8copyright.pdf (2008).
Id.