Software licenses demystified

Almost all scientists use computers on a daily basis. While some of the software they use will be proprietary, other software are conceived and developed by researchers themselves. In line with the current push for open and reproducible science, making scientific software available for inspection and use by other researchers is an important step in the research process. Furthermore, making computer code available allows others to benefit, which reduces the number of wheels that need to be re-invented.
Because an increasing number of scientists are making their code available, it is important that researchers have a basic understanding of software licenses. These documents outline how software may be used, modified, and distributed. The topic of software licenses can get quite complex. Fortunately, Morin et al. (2012) have written a non-expert’s guide to software licensing for the scientist-programmer.
A brief overview
Who owns the rights to your software?
Because research generally occurs in the context of a University or research institution, researchers should be aware that depending on the policies in place, they may not own the full rights to their own works. Often, the institution holds or shares the legal right to developed software.
Types of software licenses.
- Proprietary: These licenses are often very restrictive to end users. You have likely clicked on “I agree” and accepted the terms and conditions of many such licences. Software distributed with proprietary licenses are typically distributed in binary form, making it impossible to review the computer code.
- Free and Open Source Software (FOSS) licenses: These licenses aim to maximize openness and minimize barriers to software use, dissemination and follow-on innovation. Such licenses are not synonymous with non-commercial. This type of license allows other users to use the code easily as well as contribute to improving the code, and so makes collaborations between users easy. Furthermore, they simplify continued development and collaboration when researchers switch institutions and when collaborating across institutions.
Examples.
- If you want the widest possible distribution and adoption, fewest restrictions on users, open and transparent source code, peer reviews, community contributions to the codebase, and easy incorporation of your code by others, then a permissive FOSS license such as the BSD/MIT, Apache or ECL licenses would be appropriate.
- If you want to assure the benefits and openness of FOSS in all future derivatives of your work, open and transparent source code, peer review, community contribution to your codebase, and the potential incorporation of your code into other copyleft licensed works, then you should consider a copyleft FOSS license like the GPL, LGPL, or MPL.
- If you want to ability to separately pursue proprietary models while leveraging the wide distribution, adoption, community contributions, and other benefits of open source software, then a hybrid or multi-license scheme may be appropriate.
- If you want to protect the confidentiality of your source code, reserve maximum control over the distribution and use of your software, and derive licensing revenue, then you should consider a proprietary license.
Permissive licenses.
These licenses place the fewest restrictions on users and adopters, often only requiring that the original creators be attributed in any distribution of derivative of the software or source code.Copyleft licenses.
These licenses guarantee perpetual open source access to software and its source code.
Summary
You may not need to think of software licenses at the moment, but it is a good idea to know that such things exist and that there is a wide range of options available. Happy coding!
Reference
Morin A, Urban J, Sliz P (2012). A quick guide to software licensing for the scientist-programmer. PLoS Comput Biol. 8:e1002598.