Please cite as:
Barba, Lorena A. (2017): A short lecture on Open Licensing. figshare.
A lecture as part of the workshop "Essential skills for reproducible research computing," at Universidad Técnica Federico Santa María (January 2017).
Syllabus of the workshop.
In an October-2015 interview by mathematics professor and blogger Robert Talbert, I answer this question … “Why do you advocate so strongly for open-source technology in research and education?” … I start by first clarifying WHAT WE MEAN by “open.”
"Free and open-source software (FOSS) is a human invention of tremendous impact. It poses an alternative to intellectual-property instruments that are limiting and want to control how a creative work is used.
Open-source licenses allow people to coordinate their work freely, within the confines of copyright law, while making access and wide distribution a priority.
I’ve always thought that this is fundamentally aligned with the method of science, where we value academic freedom and wide dissemination of scientific findings. […]
Open licensing gives us freedom—contrary to intellectual-property instruments that want to control how creative works are used.
Freedom is power. In this case, the power of open-source software comes not just from being able to read the source code, but from being able to contribute to and build from it.
For this power to be realized, it's not sufficient to make the source public to read. We must attach a license that allows others to modify and distribute the code.
So let’s be clear about this:
“Open data and content can be freely used, modified, and shared by anyone for any purpose.” (The Open Definition, http://opendefinition.org)
Stanford professor David Donoho and co-workers appear to be the first ones to publicly state that reproducibility depends on open code and data.
They define reproducible computational research as that "in which all details of computations—code and data—are made conveniently available to others."
They took inspiration from geophysics professor Jon Claerbout, who said that in computational science "the actual scholarship is the complete software development environment and the complete set of instructions which generated the figures."
Donoho, D.L. ; Maleki, A. ; Rahman, I.U. ; Shahram, M. ; Stodden, V.
Volume 11 Issue 1 (2009):8–18
Everyone developing software in an academic setting should have working knowledge of software licenses.
Morin, A., J. Urban and P. Sliz (2012) A Quick Guide to Software Licensing for the Scientist-Programmer, PLoS Comput. Biol. 8(7): e1002598
The first thing to understand is that simply making the source code public does not make your project open source.
Software is a creative work, and copyright is automatically attached to it.
Without a license, your software is in a legal limbo where readers don't know how they can use it, if at all: a well-informed reader will opt for not using your software, as the only safe behavior.
The license is a contract between the authors of software and the users. It gives software authors the power to share with users, and to collaborate with other developers.
Always add a license to software you plan to make public.
Free and open-source software is under a license that grants the users freedom: to access, use or modify the software for their purposes.
The most important distinction between the various FOSS licenses is whether they are permissive versus copyleft. These terms are often confused.
A permissive license gives more freedoms: the only restriction of use could be that the original authors receive credit in any distribution of the software or any derivative works. Even commercial uses, or incorporating the software into other proprietary (closed) works, is allowed. Academic software benefit most from permissive licensing. In fact, permissive licenses originated at accademic institutions, including the Berkeley Software Distribution or BSD License, the MIT License and the Apache License.
A copyleft license restricts the use of the software by requiring that any derivative works be also under the license of the original. Another word for this model is "share-alike." Many developers want to ensure open access to their work and all derivatives for all posterity. This may be considered virtuous in some circles, but we should recognize that it is achieved by placing restrictions on the use of software. The typical copyleft license is GPL.
Compatible licenses allow source code from different works to be combined to make new software. Not all licenses are compatible!
Because incompatible terms can arise from subtle wording, the Open Source Initiative (OSI) strongly recommends using an existing OSI-approved license, instead of attempting to craft a custom license.
Note that compatibility is directional: it behaves differently whether a piece of code is built into or from another. (See the illustration below from Morin et al.)
Staff at university or laboratory technology offices may be ignorant of these issues, making it even more important for researchers to be well informed.
Figure 2 of Morin et al. (2012). Illustrates compatibility of licenses: permissive licenses (BSD, MIT) are forward-compatible with any other license, whereas copyleft licenses are only forward-compatible with themselves.
Directional compatibility of licenses is the reason why you should always be aware of the licensing terms of any code that you are reading and hoping to build upon.
For academic and research software, you are likely to want a simple license that is most permissive. For example, you can use the MIT License. Most of the research code in our group has been released under MIT.
Illustrating how subtle language variations matter, we recently decided to change our pick to the BSD 3-clause License. It is very similar to the MIT License, but there is a small difference in the wording about attribution …
This language implies that a user could copy some of an MIT-licensed code (as long as the portion is deemed "not substantial") without attribution. In academia, we always prefer full attribution of any portions of copied works, and BSD 3-clause is more precise in this.
Write into your grant proposals that your research software will be released under an OSI-approved license. If you're lucky to have your grant funded, the condition of open-source code release becomes part of the contract with the university.
This can save you some grief when trying to explain to staff at the tech office why your software needs to be open source. They often just don't understand the field, and want to default to a proprietary license, imagining some commercial value may exist in your research code.
“Essential skills for reproducible
Universidad Técnica Federico Santa María
3–6 January 2017
A Barba-group workshop for graduate students
Lorena A. Barba, The George Washington University
with Barba-group members:
A syllabus for research computing
1. command line utilities in Unix/Linux
2. an open-source scientiﬁc software ecosystem (our favorite is
3. software version control (we advocate the distributed kind:
our favorite is git)
4. good practices for scientiﬁc software development: code
hygiene and testing
5. knowledge of licensing options for sharing software
Universidad Técnica Federico Santa María, Valparaíso
3 January 2017
Prof. Lorena A. Barba
Mechanical and Aerospace Engineering Department
The George Washington University
Why do you advocate so strongly for open-source
technology in research and education?
Free & Open-source Software (FOSS)
An invention of great impact:
‣ an alternative to intellectual-property instruments
‣ OS licenses allow people to
coordinate their work freely
People can coordinate their work freely, within the
conﬁnes of copyright law, while making access and wide
distribution a priority.
It's not suﬃcient to make the source public to
read. We must attach a license that allows others
to modify and distribute the code.
The Open Deﬁnition
“Open data and content can be freely used,
modiﬁed, and shared by anyone for any purpose.”
Open source & Reproducibility
Def.— Reproducible research
Authors provide all the necessary data and the computer
codes to run the analysis again, re-creating the results.
Schwab, M., Karrenbach, N., Claerbout, J. (2000) “Making scientiﬁc computations
reproducible,” Comp. Sci. Eng. Vol. 2(6):61–67
Guide to Licenses
Everyone developing software in an academic
setting should have working knowledge of
Software is a creative work, and copyright is
automatically attached to it.
Always add a license to software you
plan to make public.
Permissive vs. copy-left
‣ Fewest restrictions
‣ Allow use, distribution, modiﬁcation
‣ Only require that code authors be given credit
‣ Best choice for academic use
‣ E.g., Berkeley Software Distribution (BSD), MIT License,
‣ Guarantees perpetual access to the source code
‣ Requires any derivative work be under the same license
‣ A.k.a. “share-alike” licenses
‣ Are considered restrictive
‣ E.g., GPL license
Compatible licenses allow source code from diﬀerent
works to be combined to make new software. Not all
licenses are compatible!
Credit: Morin et al. (2012)
How to choose?
For academic work: simple & permissive is best.
Subtlety: MIT vs. BSD 3-clause
‣ MIT License:
“The above copyright notice and this permission notice shall be
included in all copies or substantial portions of the Software.”
‣ BSD 3-clause:
“Redistributions of source code must retain the above
copyright notice, this list of conditions and the following
Write into your grant proposals that your research
software will be released under an OSI-approved license.