Licensing Your Code: GPL, BSD and Edvard Munch’s “The Scream”

I have for some time considered changing to a more permissive license (with Caltech’s approval) for the Montage image mosaic engine, as the the current license forbids modification and redistribution of the code. My first attempt at navigating the many licenses available led me to believe that the subject of Edvard Munch’s “The Scream” was not oppressed by society but simply trying to find the best license for his software.

The license, of course, specifies the terms and conditions under which the software may be used, distributed and modified, and distinctions between licenses are important. Trouble is, there are so many of them. The Wikipedia page on Comparison of Free and Open Source Licenses licenses lists over 40 such licenses, each with varying degrees of approval from the free software community. The tangled relationship between software and licensing is shown in this figure from Wikipedia (image credit):

The Open Source Initiative web page describes licenses in detail and how to apply them – this is the best resource on licenses that I have found. Bangerth and Heister (2013) in their paper “What makes computational open source software libraries successful?” did, however, explain in broad terms that the choice of license is important in  assuring successful use of the software:

• The license governs how much control authors retain over their software.
• Changing a license later on can be a difficult and time-consuming.

Considerable clarity on the issue of choosing a license is provided by an article by Matthew Turk on the yt project blog. His post describes why, after getting approval from all contributors,  he re-licensed the volumetric visualization and anlaysis package yt from GPL v3 to BSD (acronyms will be explained in a minute).  GPL and BSD licenses (and their variants) are the dominant licenses currently used, but there are very important differences between them.  As explained by John Hunter, the GNU general public license, GPL, requires that any code derived from GPL code also uses a GPL license, and that any code that is statically or dynamically linked to GPL code has a GPL-compatible license; it is said to have a “copyleft” restriction. (For more details, visit http://en.wikipedia.org/wiki/GNU_General_Public_License and http://www.gnu.org/licenses/gpl-faq.html). Linux, gcc and emacs are all released under the GPL. By contrast, the  Berkeley software distribution license (BSD) family is permissive, in that it allows you to modify and use the code without requiring that you use the same license. It allows you to distribute closed-source binaries as well – there is  no obligation to release code. The BSD operating system and Python released under BSD licenses.

Many astronomical and scientific packages are released under BSD licenses. Turk quotes the following: VisIt, ParaView, MayaVi, NumPy, Matplotlib, IPython, Python itself, mpi4py, h5py, SymPy, SciPy, most of the scikits, scikits-learn, NetworkX. And this is why the GPL license was impeding the development of yt: it could not be integrated with other projects unless they too were released under a GPL license (this why GPL licenses are said to be “viral.”). The yt project’s collaborations were one-way under GPL. Now, yt uses a BSD 3-clause license.

Turk and Hunter recommend  BSD as the “license of choice” for scientific software – but do pick your license carefully.  BSD and BSD-like licenses (such as MIT) were also recommended as the license of choice at the recent Code Sharing Session at the 223rd AAS meeting.  There were discussions too about holding a licensing workshop at a future meeting – most astronomers are not versed in licensing. I believe there are plans for an Astrobetter post on licensing, which I look forward to reading. Finally, if anyone knows of a paper comparing real-world impacts of the various Open Source Licenses – along the lines of Turk’s article – please let me know.