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.
Astronomy Computing Today 
What about the MPL? see here for an example: http://www2.law.ed.ac.uk/ahrc/script-ed/docs/opensource.asp
Thanks John. I have no experience with this license, though the statement “.. Under the MPL it is legal for a business to charge a fee to take on liability for the software, and to support it.” might well kill it off in astronomy.
Pingback: Resources for Licensing Your Code | Astronomy Computing Today
Pingback: Licensing your code – ASCL.net
The GPL is, as Balmer put it.. “a cancer”. For some that is an inflammatory statement, but how can it not be accurate to state that it infects derivative works. That is its intent. As they always say on TV, follow the money. Given a purely theoretical environment, where one person creates code, another enhances it, and the enhanced code gets released back in the wild so the original coder can enhance that, or pull out some things to put back in their code, you can start to dream about reaching a hyper progressive positive state. When you break down the reality of the situation things look quite a bit different. For GPL, if the base code dictating that all users of that code use the GPL doesn’t share all of its code, then they can steer the brand of that code and use it to progressively consume all derivative code.
So the insidious nature begins to reveal itself and we see who the real winners are. The people who run a proprietary version of the code that is not shared, whose enhancements may be GPL, but aren’t released to the wild, so others cannot use them. While the majority of derivative authors must relinquish their code to third parties to make it functional, and expose it to being easily scooped into the central code base, or cannibalized by others, making their code irrelevant, or at best only necessary for a tiny niche audience. Never a major profit center or sustainable enterprise.
A better GPL that could truly sustain its moralizing would be one that not only said that you must copyleft your derivative works, but also that you must release them publicly. So that persons rolling them into “services” where GPL code is enhanced and hidden from the original author is not permissible. That all the code derived is necessarily public. In the current environment this is not the case, and any community contribution encouraged by people running massively successful services, that can then consume your ideas and your functionally to easily maintain dominance, is suspect.
Another way to say that is that if you moralize about software freedom you must also moralize about sharing code. If it is moral to copyleft than is it not also necessarily moral to share the subsequent code in all cases. It would be nice to retool the cms market with a truly open product that does not have a commercial brand sitting as a parasite ready to consume all of the customers of the community with “official” branded services.
I’m essentially saying that GPL is not enough to protect software freedom. Or at least if you take a moral stance on software freedom you don’t really have a leg to stand on if the community is not always in possession of all derived code. Services being able to co-opt the code and not remain open by nature negates the community and allows (mostly big business) to callously consume your efforts with nothing returned.
So while GPL’d open source can be a boon to those that aspire to become big business, or be consumed by big business as individuals. It is a plague on independence, because even though you do benefit from the glut of free work, you must necessarily jump into the service market and hide your proprietary code before you can build a truly sustainable growth business model.
I personally find that to be horrible, and believe in the idea of democratization of all things, allowing individuals the freedom to be powerful and self sustaining and free of corporate servitude. Any model that doesn’t support that independence is one that is built upon a requirement of inequality for success, where you must feed off the labors of others without providing real sustenance to them in return.
Thoughts 🙂 ?
Pingback: Software licensing resources – ASCL.net