A Quick Guide to Licensing for the Scientist-Programmer

The Harvard community has made this article openly available. Please share how this access benefits you. Your story matters

Citation Morin, Andrew, Jennifer Urban, and Piotr Sliz. 2012. A quick guide to software licensing for the scientist-programmer. PLoS Computational Biology 8(7): e1002598.

Published Version doi:10.1371/journal.pcbi.1002598

Citable link http://nrs.harvard.edu/urn-3:HUL.InstRepos:10445641

Terms of Use This article was downloaded from Harvard University’s DASH repository, and is made available under the terms and conditions applicable to Other Posted Material, as set forth at http:// nrs.harvard.edu/urn-3:HUL.InstRepos:dash.current.terms-of- use#LAA Education A Quick Guide to Software Licensing for the Scientist- Programmer

Andrew Morin1, Jennifer Urban2, Piotr Sliz1* 1 Department of Biological Chemistry and Molecular Pharmacology, Harvard Medical School, Boston, Massachusetts, United States of America, 2 Samuelson Law, Technology & Public Policy Clinic, School of Law, University of California Berkeley, Berkeley, California, United States of America

Computing is ubiquitous in every institutional TTO when choosing soft- intellectual property (IP) rights. Under domain of scientific research. Software is ware licenses. the policies of most academic and the means by which scientists harness the research institutions, researchers who power of computers, and much scientific Why Software Licenses Are have created a piece of software are computing relies on software conceived Important unlikely to own full rights to their works. and developed by other practicing re- Instead, the institution generally holds or searchers. The task of creating scientific Licenses are important tools for setting shares legal right to developed software. software, however, does not end with the specific terms on which software may be Institutions’ policies on IP ownership publication of computed results. Making used, modified, or distributed. Based on vary, but in most cases your institution the developed software available for in- the copyright protection automatically will be the legal ‘‘rights owner,’’ and will spection and use by other scientists is granted to all original works, a software be the entity that actually grants the essential to reproducibility, peer-review, license—essentially, a set of formal per- license you choose for your software. and the ability to build upon others’ work missions from the copyright holder—may Although many types of licenses, espe- [1,2]. In fulfilling expectations to distribute include specific ‘‘conditions’’ of use, and cially of the ‘‘free and ’’ and disseminate their software, scientist- are an important part of the legally variety, are simple enough for the non- programmers are required to be not only binding contract between program author legal expert to understand and apply proficient scientists and coders, but also (or rights owner) and end-user. (Figure 1), it is generally necessary to knowledgeable in legal strategies for li- Without a license agreement, software consult your institutions’ TTO before censing their software. Navigating the may be left in a state of legal uncertainty in imposing a license. See below for more often complex legal landscape of software which potential users may not know which information about working with your licensing can be overwhelming, even for limitations owners may want to enforce, institution in applying a license. sophisticated programmers. Institutional and owners may leave themselves vulner- technology transfer offices (TTOs) exist able to legal claims or have difficulty Types of Software Licenses to help address this need, but due to controlling how their work is used. This is mismatches in expectations or specific equally true for software that is commer- Colloquially speaking, the spectrum of domain knowledge, interactions between cialized and offered for a fee, and software software licensing strategies can be divided scientists and TTO staff can result in that is made available without cost to into three categories: ‘‘proprietary,’’ ‘‘free suboptimal outcomes. others. While end-users often balk at overly and open source,’’ or a hybrid of the two. As practitioners in the scientific com- restrictive software licenses, the uncertainty puting and technology law fields, we caused when no license is given can also Proprietary Licensing have witnessed firsthand the confusion discourage those wishing to make use of a This strategy is familiar from the ‘‘click- and difficulties associated with licensing piece of code. It is important to note that thru’’ agreements that govern commercial scientifically generated software. SBGri- licenses can be used to facilitate access to software packages. The primary purpose d.org is a consortium of scientific software as well as restrict it. of a proprietary is to limit software developers and users in hun- the use of software according to the rights dreds of biomedical research laborato- Software Licensing in Academic owner’s business strategy. As a result, ries worldwide. As facilitator and mid- and Research Environments proprietary licenses are often very restric- dleman between developers and end- tive for end-users. They typically allow use users, we commonly assist in the dissem- Foralicensetobevaliditmustbe of the software only for its stated purpose, ination and use of scientifically generat- granted by the owner of the work’s often only on a single computer, forbid ed software. Through research and advocacy, the Samuelson Law, Technol- Citation: Morin A, Urban J, Sliz P (2012) A Quick Guide to Software Licensing for the Scientist- ogy and Public Policy Clinic works with Programmer. PLoS Comput Biol 8(7): e1002598. doi:10.1371/journal.pcbi.1002598 software developers and other creators Editor: Fran Lewitter, Whitehead Institute, United States of America on licensing issues, particularly issues Published July 26, 2012 related to facilitating ‘‘open access’’ to Copyright: ß 2012 Morin et al. This is an open-access article distributed under the terms of the Creative scientific, technical, or creative materi- Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, als. Together, we offer a primer on provided the original author and source are credited. software licensing with a focus on the Funding: The work was supported by the National Science Foundation grant 0639193 (PS). The funders had particular needs of the scientist software no role in the preparation of the manuscript. developer. The aim of this guide is to Competing interests: The authors have declared that no competing interests exist. help scientists better engage with their * E-mail: [email protected]

PLoS Computational Biology | www.ploscompbiol.org 1 July 2012 | Volume 8 | Issue 7 | e1002598 Figure 1. Example of FOSS license with ‘‘academic’’ style copyright statement. The example shown is the entirety of a 2-Clause BSD [8] license with copyright statement (at top, within quotes). The text of the license is in black. Red highlighted text is where the copyright holder applying the license inserts their specific information. Application of this and many FOSS licenses simply require that the text of the license be included (usually as ‘‘License.txt’’) in the directory containing the distributed program binary and or . doi:10.1371/journal.pcbi.1002598.g001 users from copying, redistributing, or common misconception is that FOSS is called dual- or multi-licensing) approach- altering the work, and specifically prohibit synonymous with ‘‘noncommercial.’’ In es—combining a FOSS license with a the creation of derivatives using parts of fact, as described by the two most proprietary ‘‘closed’’ license—are some- the work. Importantly, programs under influential definitions of FOSS [3,4], times used. Under this strategy, the rights proprietary licenses are typically distribut- ‘‘non-discriminatory’’ means that no cate- owner chooses which license to apply on a ed only in binary form and forbid gory of user or distributor can be prohib- case-by-case basis. When ownership and examination of the program code or ited, including for-profit commercial enti- licensing rights are clear, these licensing reverse engineering of any part of the ties. As such, FOSS-licensed software can schemes can maintain some of the benefits program. In academic settings, proprietary be, and regularly is, commercially exploit- of FOSS while also permitting creators to software may occasionally release source ed. Some cited benefits of a FOSS strategy employ multiple business models [6]. The code ‘‘for inspection purposes only’’ due to include widespread adoption, user contri- downside can be a significant added scientific publishing and peer-review re- butions, and ease of collaboration [5]. burden for the rights owner in applying, quirements (Table 1). Additionally, because of their open and administering, and enforcing multiple non-discriminatory nature, FOSS licenses licenses. This has generally limited the Free and Open Source Software can simplify continued development and adoption of hybrid license models to large (FOSS) Licensing collaboration when researchers switch software development initiatives. Free and open source software (FOSS) institutions, and when they collaborate represents a fundamentally different ap- across institutions. FOSS can also help to Terms, Concepts, and Examples extend the useful lifetime of a piece of proach to software licensing. The primary Useful in Understanding software beyond the direct involvement of intent of FOSS is to maximize openness Software Licenses and minimize barriers to software use, the creators. We discuss some important dissemination, and follow-on innovation. differences in FOSS licenses below. Open Source versus Closed Source There are a wide variety of popular FOSS Source code is the human readable form licenses [3], each of which vary in some Hybrid Software Licensing of a computer programming language. important ways, but all grant free (as in Some software developers find that their ‘‘Open source’’ refers to licenses that freedom), open, and non-discriminatory needs are not well met by using either require the source code be available to access and rights to modify licensed proprietary or FOSS licensing models users, and that users be able to reuse, software and associated source code. A exclusively. In these cases, ‘‘hybrid’’ (also modify, and distribute the code [3]. Without

PLoS Computational Biology | www.ploscompbiol.org 2 July 2012 | Volume 8 | Issue 7 | e1002598 Table 1. Summary of select attributes of cited licenses types.

Permitsb Patent Code Name Latest Version Granta Linking Used byc

FOSS BSD 2-Clause No No Yes Gabedit, Chemkit, SciPy MIT 1.0 No No Yes Weblogo, APBS ECL 2.0 No Yes Yes RCrane, Sakai Project Apache 2.0 No Yes Yes Imagemagick, Autodock Vina, GenMAPP MPL 2.0 Partial Yes Yes , Thunderbird LGPL 3.0 Weak Yes Yes ClustalW/X, IMP, BioJava, Taverna Workbench GPL 3.0 Strong Yes No R Project, , Coot, OpenBabel, GROMACS Proprietary Traditional ‘‘bespoke’’d No Varies Varies Majority of scientist-created software ‘‘Inspection only’’e No Varies Varies Satisfies minimum publishing & peer-review requirement Commercial No No No MS Windows, iTunes, Acrobat Hybrid Any combination Varies Varies Varies Pymol, MySQL, BDB, Phenix

Note that the values assigned in the table are only a general summary of each license attribute and may not fully reflect the specific details of each license. aLicense text explicitly describes the treatment of patents related to the software. bAllows the linking of computer code under different licenses. cSelect examples of popular software employing these licenses. dRefers to a range of custom-tailored licenses traditionally used by academic and research institutions. eTraditional ‘‘bespoke’’ license that also makes source code available for inspection purposes only. doi:10.1371/journal.pcbi.1002598.t001 access to source code, researchers cannot origins in, and frequent use by, academic copyleft licenses are considered ‘‘restrictive’’ effectively inspect, understand, or manipu- institutions [7]. licenses, though these restrictions guarantee late the inner workings of a program. Examples of popular permissive FOSS perpetual open access. Source code availability is of increased licenses include the Berkeley Software Examples of popular copyleft FOSS importance in the context of scientific Distribution (BSD) [8], MIT [9], Apache licenses include the GNU General Public research, where peer review, reproducibil- [10], and Educational Community Li- License (GPL) [12], GNU Lesser General ity, and building upon prior work are cense (ECL) [11] licenses. The BSD and Public License (LGPL) [13], and the integral to the advancement of science. MIT licenses are often mentioned inter- Public License (MPL) [14]. The Source code access helps researchers quick- changeably due to very similar language GNU Licenses are the most well known of ly identify and remedy bugs that might lead and terms that accomplish largely identical all the FOSS licenses and have a strong to spurious results and adapt programs or goals. The primary intent of these licenses community of supporters and advocates. pieces of code to suit individual needs, and is to allow the use, distribution, and Of these, the GPL has the strongest allows expert users to contribute to code modification of your code for any purpose, reciprocity requirements and is considered development on an informal basis. An while making sure that you as the creator a ‘‘strong’’ copyleft license. The LGPL (the active open source user community partic- receive credit for your work (see Figure 1 ‘‘Lesser GPL,’’ denoting its weaker copyleft ipating in maintaining and improving the for an example of an FOSS license with an requirements) is very similar to the GPL code base can free the original developer to academic style attribution/citation copy- from which it is derived, but allows for concentrate on major enhancements or right statement). The Apache and ECL linking to proprietary code under certain move on to other projects without sacrific- licenses are similar in effect to the BSD/ circumstances. Similarly, the MPL allows ing continued utility of the software. MIT, but include a license for patents copyleft to be applied to some parts of the related to the software (this can be code and not others. The LGPL and MPL Permissive versus Copyleft desirable or not, depending on the situa- are considered a compromise between the ‘‘Permissive’’ and ‘‘copyleft’’ are terms tion—see below). The ECL differs from strong copyleft of GPL and permissive used to compare legal philosophies and Apache in a slightly weakened patent licenses such as the BSD/MIT. attributes of FOSS licenses to traditional grant to accommodate the often complex proprietary licenses. IP environments of academic institutions. Compatibility, Proliferation, Permissive licenses are those that place the For developers who want to guarantee Fragmentation, and Directionality fewest restrictions on users and adopters, perpetual open source access to their work, A fundamental goal of FOSS is to often only requiring that the original some licenses employ the concept of copyleft,a promote the free exchange of ideas and creators be attributed in any distribution punning reference to ‘‘copyright.’’ Copyleft technology without fear of infringing the or derivative of the software or source uses copyright’s legal framework to guaran- rights of others. Ideally, code licensed code. For example, permissively licensed tee continued open access to a software and under like-minded FOSS terms should be software may be incorporated into its source code. This is done by requiring, as freely combinable to create new products. ‘‘closed’’ proprietary programs with no a condition of the license, that any derivative Compatibility is the attribute of software requirement that the source code be works also be distributed under the same licenses that allows combining of program disclosed if the combined software is licensing terms as the original. These copyleft code. To be compatible, license terms distributed. Permissive open source licens- licensing terms are also sometimes referred to must be free of contradictory or mutually es are also sometimes called ‘‘research’’ or as reciprocity or ‘‘share-alike’’ provisions. exclusive requirements. Alas, some FOSS ‘‘academic’’ style licenses because of their Because of these reciprocity requirements, licenses contain terms ‘‘incompatible’’

PLoS Computational Biology | www.ploscompbiol.org 3 July 2012 | Volume 8 | Issue 7 | e1002598 maximizes and min- imizes the cost of administering and understanding the terms of a given license. Conversely, bespoke licenses are custom- tailored for each individual project. Tai- lored licenses allow for greater control, but require more resources to develop and administer and are highly likely to be incompatible with other licensing schemes. Nearly all proprietary licenses are bespoke.

Hybrid and Multi-Licensed Software These license schemes differ from single licensing in allowing rights owners to choose which licenses best serve their needs on a case-by-case basis. One form of multi-licensing permits users and con- tributors to select among multiple licenses offered by the rights owner. Another example is when owners enter into separate ‘‘side’’ agreements not to enforce certain provisions of FOSS licenses, often for a fee. Limiting the reach of FOSS licenses in this manner is controversial within the open source community due to the partial circumvention of share-alike principles. MySQL [17] and Oracle Berkeley DB Figure 2. Schematic representation of license directionality. In general, permissively [18] (BDB) are two well-known examples licensed code is forward compatible with any other license type. However, only permissive of multi-licensed software and are both licenses, such as the BSD and MIT, can feed into other permissive licenses. Restrictive licenses like made freely available for use, distribution, the GPL are backward compatible with themselves and permissive licenses, but must adopt the and modification under open source restrictive license from then on. Proprietary licenses can incorporate upstream permissively licensed code, but by definition are incompatible with any other downstream license. Grey licenses. However, each of these programs represents actions that are not permitted without negotiating a separate license agreement with is additionally offered for a fee under the rights owner. alternative licenses more amenable to doi:10.1371/journal.pcbi.1002598.g002 proprietary business strategies. with other FOSS licenses, thereby diluting of it (downstream, or forward-compatible) FOSS Licenses and the ability to easily combine code. (Figure 2). For example, a permissive Commercialization license like the BSD is forward-compatible This unfortunate situation has been It is a common misconception that with nearly any other kind of license, but exacerbated by the proliferation of incom- FOSS licensing strategies preclude com- backward-compatible only with other per- patible FOSS licenses, many of which mercialization. In fact, OSI-approved [3] missive licenses. Likewise, a copyleft license differ in only trivial ways. The Open FOSS licenses cannot discriminate against like the GPL can incorporate (upstream) Source Initiative (OSI) [15] was created in commercial use. (This is one reason why both permissive and other GPL’d code, but part to reduce the fragmentation of the institutional TTOs have sometimes pre- the resulting software may only be licensed FOSS license space cause by incompatible ferred a bespoke ‘‘non-profit-use-only’’ (downstream) under the GPL. and redundant licenses. OSI thus strongly license.) Though FOSS licenses preclude encourages using an existing FOSS license Directionality is an important reason charging for the license rights themselves, why, if you’re trying to integrate code instead of creating a new, ‘‘bespoke’’ developers are free to charge a fee for written by others with your own, you’ll license, and offers a categorization of additional services such as technical sup- want to be aware of what license the code licenses to help developers avoid redun- port, priority feature development, consul- dancy [16]. you are incorporating carries. When tation, etc. Hybrid licensing schemes (see attempting to combine code from multiple In general, the more restrictive the above) offer further avenues for FOSS projects each under different license types, license, the less compatible it is with other commercialization. licenses. Proprietary licensed software, by issues of compatibility can become very complex. design, cannot be incorporated into other Choosing a Software License codebases absent a separately negotiated licensing agreement. ‘‘Form’’ versus ‘‘Bespoke’’ Licenses Determining which license will work best License compatibility is further compli- FOSS license are generally form licenses, for you can require some thought, and cated, however, in that it is directional. meaning that their terms are standardized depends not only on specific attributes of License directionality refers to how a license and a developer need only apply them your software, but also on your particular behaves differently with code feeding into it (Figure 1). This standardization is critical goals. While both FOSS and proprietary (upstream, or backward-compatible) or out to the success of FOSS strategies because it licenses generally require attribution and

PLoS Computational Biology | www.ploscompbiol.org 4 July 2012 | Volume 8 | Issue 7 | e1002598 include standard protections such as dis- with them and a desire to preserve what is creator of a work. Knowing what you claimers of warranty, they differ in key perceived (sometimes inaccurately) as the want and why you want it should go far in aspects both philosophical and practical. maximum potential for commercial exploi- making the licensing process as painless as If you want… tation. Institutions receiving public funds possible. …the widest possible distribution and adoption, will typically license to fewest restrictions on users, open and transparent other academic or non-profit users at no The Complication of Software source code, peer review, community contributions charge but require a fee for licensing to for- Patents to the codebase, and easy incorporation of your code profit and industry users. by others… then a permissive FOSS An additional reason to contact your license such as the BSD/MIT, Apache, Applying a License to Your TTO before applying a license is software or ECL licenses may work well. Because of Software patents. Modern TTOs arose following the few requirements on users, these the Bayh-Dole Act of 1980, which allows licenses are amongst the easiest to apply Once you have chosen a license strategy US research institutions to patent inven- and administer, and promote unfettered for your software, the usual first step in tions developed using public funds and to incorporation of your code into other applying it is to contact your institutional license those patents [19,20]. Because the software—including copyleft or commer- TTO. Although many FOSS licenses are vast majority of academic and research cial software. Despite their general per- easy to apply even by the non-legal-expert, inventions are unlikely to have significant missiveness, they do assure continued as researchers and academics it is unlikely commercial value, most are never patented, author attribution in any and all redistri- you personally own all of the rights to your but institutions typically require the disclo- butions or derivative works. work. Instead, these rights typically belong sure of any patentable invention to the …to assure the benefits and openness of FOSS to, or are at least shared with, your TTO. Many FOSS licenses (like the BSD in all future derivatives of your work, open and institution. Therefore it is usually neces- or MIT licenses) are agnostic regarding transparent source code, peer review, community sary to work with your institution when patents, while some explicitly include contributions to the codebase, and the potential applying a license. patent grants in the license text (like the incorporation of your code into other copyleft- TTOs exist to help you make and Apache or GPL licenses) (Table 1). Soft- licensed works… then you should consider a execute these types of decisions. Nonethe- ware patents are highly complex and copyleft FOSS license like the GPL, less, coming with a clear idea of what kinds generally outside the scope of this guide, LGPL, or MPL. These licenses, by of licenses are available, which one you but be aware that your TTO will want to requiring anyone who distributes the want, and why, will likely be both discuss patent strategy, as well as copyright. unmodified or modified code to do so appreciated by your TTO staff and result under the same license, guarantee perpet- in a more favorable outcome for you. Software Licensing and the ual open source of your work. Some Once you’ve contacted your TTO, the Open Culture of Science copyleft licenses, such as the GPL, have process generally begins by helping the particularly strong developer communi- staff understand the ‘‘who, what, why, The needs and obligations of academic ties, encouraging community contribu- where, and how’’ of your work: how it and publically funded research create tions to your software. The copyleft works, who would be interested in it, what unique considerations for scientist-pro- requirements of these licenses can some- the innovation is, why you made it, where grammers choosing a software license. times, however, dissuade others from the funding came from, and other similar Unlike in the software industry, where adopting or incorporating your code. facts. Once TTO staff have this general licensing strategy is primarily a matter of …the ability to separately pursue proprietary understanding, they will discuss with you business strategy, it can be highly beneficial models while leveraging the wide distribution, possible IP schemes—everything from for scientists to publish, disseminate, and adoption, community contributions, and other placing the work in the to share the fruits of their work as widely as benefits of open source software… then a hybrid creating a company to commercialize it. possible, independent of commercial po- or multi-license scheme may be ap- Most of the time, some form of license tential. In addition, academic ethics en- propriate. Hybrid or multi-licensing can arrangement will be preferred. Be pre- courage the wide sharing of research achieve the benefits of both open source pared, however. Some institutions’ philos- materials and information, including code. and proprietary software licenses. Howev- ophies on protecting and exploiting IP are For programmers, this generally means er, as in everything, there is no free lunch. more aggressive than others. You may sharing not just the binary executable, but The legal, administrative, and organiza- need to explain, for example, why using a also the source code so that others may use, tional complexity of managing multiple FOSS license does not preclude commer- validate, reproduce, and extend the work. licenses, as well as other administrative cialization (see above), why you think FOSS licenses such as those listed above costs, often limits multi-license schemes to commercialization is not the most appro- are consistent with the open culture and large software projects whose anticipated priate goal for your work, or why broad obligations of scientific research, as well as revenue stream justify the cost of dedicated dissemination is an important goal for you. the attribution and citation benefits academ- licensing personnel. As noted above, this If you wish to propose a license that limits icshavecometorelyon.Permissivelicenses strategy is sometimes also controversial or forgoes the potential for generating may be preferred due to their ease of within FOSS developer communities. revenue, you may first have to convince application and universal downstream com- …protect the confidentiality of your source code, your TTO staff that your work lacks patibility. Copyleft licenses may be useful in reserve maximum control over the distribution and commercial value. While the process can accommodating upstream encumbered use of your software, and derive licensing revenue… sometimes be a bit of a negotiation, most code or preferred by researchers seeking to then you should consider a proprietary institutions care a great deal about the assure perpetual open access, but their license. Institutional TTOs sometimes scientific and societal impact of their IP, reciprocity requirements can limit down- default towards applying proprietary and we find that it is rare for an institution stream options. Hybrid licensing schemes, licenses due to staff’s greater familiarity to act contrary to the express wishes of the due to their added complexity, are more

PLoS Computational Biology | www.ploscompbiol.org 5 July 2012 | Volume 8 | Issue 7 | e1002598 Editorial Comment Andreas Prlic´, Hilmar Lapp, Software Editors PLoS Computational Biology

Scientists are ‘‘dwarfs, standing on the shoulders of giants’’ (Bernard of Chartres). That is, in their pursuit to acquire new knowledge, they are building on the work of others. For this to be possible, already established scientific information must be widely accessible and reusable. This need for access to information is in conflict with a desire, the one to protect the value of intellectual innovation.

Copyright laws have been created with the goal of protecting the rights of copyright holders for a certain amount of time. In fact, in our software-dependent information age, few laws are influencing our professional (and personal) pursuits more than these. For example, at the time of writing this article, the two software giants Oracle and Google are facing each other in court over the question of whether Google’s use of the Java programming language’s application programming interface (API) infringed on Oracle’s copyright. The outcome of the trial could have an impact on the freedom of software developers to use APIs and thus potentially hinder software interoperability.

Clearly, when developing software, choosing the terms under which the software can be reused, distributed, and built upon is an important consideration. Yet, many scientists and scientific developers have little training in or knowledge of the consequences of the choices they can make. Depending on how licenses are used they can either protect individuals’ ability to capitalize on their creative works or ensure the public’s ability to reuse. Licenses differ where in this spectrum they are positioned. This article, the ‘‘Quick Guide to Software Licensing for the Scientist-Programmer,’’ provides a summary of a variety of licenses and discusses their benefits and disadvantages. We hope that this guide helps in illuminating the seemingly complex jungle of licensing choices and their consequences, and that it serves as counsel to scientists and developers for what license is best suited in a particular situation.

PLoS Computational Biology supports open and unrestricted access to scientific publication and software. To foster a culture of open exchange and reuse of software, we have recently created a new category of Software Articles. For a manuscript to be published under this category in PLoS Computational Biology, we require that all software uses a license that is approved as open source by the (OSI). The approval criteria (http://www.opensource.org/docs/osd) set forth by OSI emphasize that the distribution terms must allow the software to be freely re-used, re-distributed, or modified. These requirements ensure transparency and reproducibility and, if applied to scientific software, push science forward by allowing researchers to build on existing work. limited in their utility, but if appropriate, can of the reputational benefits and increased detrimental to the validation and accep- offer many of the benefits of both proprie- influence that come with the wide adop- tance of scientific results derived using tary and open source models. tion and dissemination open licensing the software. Although some traditional Due to their closed and restrictive models encourage. ‘‘bespoke’’ academic licenses attempt to nature, proprietary software licensing More broadly, especially in the context mitigate the negative effects of proprie- schemes should probably be avoided of scientific openness, collaboration, and tary licensing by offering software ‘‘free whenever possible. As with other restric- peer review, the lack of available source for non-profit use’’ or by publishing tive license models, the administrative code is a substantial drawback. In source code ‘‘for inspection only’’, this burden of managing compliance and contrast to open source code, closed- nullifies the many significant benefits of collecting revenues can be significant. source programs are essentially ‘‘black community contribution, collaboration, For this reason, if anticipated total reve- boxes’’ in the research workflow [21], and increased adoption that come with nues are not high, it can often be more opaque to both reviewers and users. The open source licensing. beneficial for scientists to take advantage failure to release source code can be

References 1. Peng RD (2011) Reproducible research in 6. Hecker F (1999) Setting up shop: the business of 12. Foundation (FSF) (n.d.) The GNU computational science. Science 334: 1226–1227. open-source software. IEEE Softw 16: 45–51. doi: general public license (GPL) v3.0. Available: doi:10.1126/science.1213847. 10.1109/52.744568 http://www.gnu.org/licenses/gpl.html. Accessed 2. Stodden V (2009) The legal framework for 7. Bretthauer D (2001) Open source software: a 12 December 2011. reproducible scientific research: licensing and history. UConn Libraries Published Works. Paper 13. (FSF) (n.d.) GNU lesser copyright. Comput Sci Eng 11: 35–40. 7: 1–22. Available: http://digitalcommons. general public license (LGPL) v3.0. Available: doi:10.1109/MCSE.2009.19. uconn.edu/libr_pubs/7. Accessed 22 June 2012. http://www.gnu.org/licenses/lgpl.html. Ac- 3. Open Source Initiative (n.d.) Open Source 8.TheBSDLicense(n.d.)TheBSDlicense. cessed 12 December 2011. Initiative. Available: http://www.opensource. Available: http://www.opensource.org/licenses/ 14. Mozilla (n.d.) , version 2.0. org/. Accessed 10 November 2011. bsd-license.. Accessed 12 December 2011. Available: http://www.mozilla.org/MPL/2.0/. 4. Free Software Foundation (n.d.) Free Software 9. The MIT License (n.d.) The MIT license. Accessed 5 January 2012. Foundation website. Available: http://www.fsf. Available: http://www.opensource.org/licenses/ 15. Open Source Initiative (n.d.) Open Source org/. Accessed 5 January 2012. MIT. Accessed 12 December 2011. Initiative website. Available: http://www. 5. Scacchi W (2007) Free/open source software 10. , version 2.0 (n.d.) Apache license, opensource.org. Accessed 10 November 2011. development: recent research results and emerg- version 2.0. Available: http://opensource.org/ 16. Open Source Initiative (n.d.) Open source licenses ing opportunities. Proceedings of the 6th Joint licenses/apache2.0. Accessed 12 December by category. Available: http://www.opensource. Meeting of the European Software Engineering 2011. org/licenses/category. Accessed 2 April 2012. Conference and the ACM SIGSOFT Symposium 11. Educational Community License, version 2.0 17. MySQL (n.d.) MySQL licensing policy. Available: on the Foundations of Software Engineering; 3–7 (ECL-2.0) (n.d.) Educational Community License, http://www.mysql.com/about/legal/licensing/ September 2007; Dubrovnik, Croatia. New York: version 2.0 (ECL-2.0). Available: http:// index.html. Accessed 12 December 2011. ACM Press. pp. 459–468. doi:10.1145/ opensource.org/licenses/ECL-2.0. Accessed 12 18. Oracle (n.d.) Oracle Berkeley DB licensing informa- 1287624.1287689. December 2011. tion. Available: http://www.oracle.com/

PLoS Computational Biology | www.ploscompbiol.org 6 July 2012 | Volume 8 | Issue 7 | e1002598 technetwork/database/berkeleydb/downloads/ uscode.house.gov/download/pls/35C18.txt. Ac- 21. Morin A, Urban JM, Adams PD, Foster I, Sali A, licensing-098979.html. Accessed 12 December 2011. cessed 29 May 2012. et al. (2012) Shining light into black boxes. 19. US House of Representatives (1980) Bayh-Dole 20. Sampat BN (2010) Lessons from Bayh-Dole. Science 336: 155–156. doi:10.1126/sci- Act, 35 U.S.C. 1 200–212. Available: http:// Nature 468: 755–756. doi:10.1038/468755a. ence.1218263.

PLoS Computational Biology | www.ploscompbiol.org 7 July 2012 | Volume 8 | Issue 7 | e1002598