$30 off During Our Annual Pro Sale. View Details »

A short lecture on Open Licensing

A short lecture on Open Licensing

Please cite as:
Barba, Lorena A. (2017): A short lecture on Open Licensing. figshare.
https://dx.doi.org/10.6084/m9.figshare.4516892.v1

A lecture as part of the workshop "Essential skills for reproducible research computing," at Universidad Técnica Federico Santa María (January 2017).
https://barbagroup.github.io/essential_skills_RRC/

[slide 3]
Syllabus of the workshop.

[slide 5]
http://rtalbert.org/blog/2015/interview-lorena-barba
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.”

[slide 6]
"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. […]

[slide 7]
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.

[slide 9]
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)

[slide 12]
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
http://dx.doi.org/10.1109/MCSE.2009.15

[slide 13]
Everyone developing software in an academic setting should have working knowledge of software licenses.

[slide 14]
Screenshot of
Morin, A., J. Urban and P. Sliz (2012) A Quick Guide to Software Licensing for the Scientist-Programmer, PLoS Comput. Biol. 8(7): e1002598
http://dx.doi.org/10.1371/journal.pcbi.1002598

[slide 15]
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.

[slide 16]
Always add a license to software you plan to make public.

[slide 17]
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.

[slide 18]
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.

[slide 19]
http://choosealicense.com/licenses/mit/

[slide 20]
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.

[slide 21]
http://choosealicense.com/licenses/gpl-3.0/

[slide 22]
License compatibility
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.

[slide 23]
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.

[slide 24]
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.

[slide 25]
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.

[slide 26]
Bonus advice:
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.

Lorena A. Barba

January 04, 2017
Tweet

More Decks by Lorena A. Barba

Other Decks in Education

Transcript

  1. “Essential skills for reproducible research computing” Universidad Técnica Federico Santa

    María 3–6 January 2017 A Barba-group workshop for graduate students https://barbagroup.github.io/essential_skills_RRC/ Lorena A. Barba, The George Washington University
  2. A syllabus for research computing 1. command line utilities in

    Unix/Linux 2. an open-source scientific software ecosystem (our favorite is Python's) 3. software version control (we advocate the distributed kind: our favorite is git) 4. good practices for scientific software development: code hygiene and testing 5. knowledge of licensing options for sharing software https://barbagroup.github.io/essential_skills_RRC/
  3. Universidad Técnica Federico Santa María, Valparaíso 3 January 2017 Open

    Licensing Prof. Lorena A. Barba Mechanical and Aerospace Engineering Department
 The George Washington University @LorenaABarba
  4. 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
  5. Open-source licenses: People can coordinate their work freely, within the

    confines of copyright law, while making access and wide distribution a priority.
  6. Open source 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.
  7. The Open Definition “Open data and content can be freely

    used, modified, and shared by anyone for any purpose.” http://opendefinition.org
  8. 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 scientific computations reproducible,” Comp. Sci. Eng. Vol. 2(6):61–67
  9. Guide to Licenses Everyone developing software in an academic setting

    should have working knowledge of software licenses.
  10. Permissive licenses ‣ Fewest restrictions ‣ Allow use, distribution, modification

    ‣ Only require that code authors be given credit ‣ Best choice for academic use ‣ E.g., Berkeley Software Distribution (BSD), MIT License, Apache License
  11. Copy-left licenses ‣ 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
  12. License compatibility Compatible licenses allow source code from different works

    to be combined to make new software. Not all licenses are compatible!
  13. 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 disclaimer.”
  14. Bonus advice: Write into your grant proposals that your research

    software will be released under an OSI-approved license.