Making software available: open source licenses

open source initiative logo

When you are writing some code for your upcoming paper, you may want (or need) to make the code available. Just making it available to see somewhere doesn’t automatically make it open source software though. In this post I will provide you, based on my experience of having to choose a license, a brief introduction on what the difference is, why your code needs a license and what license may be right for your project.

As stated in the introduction, just placing your code somewhere on the internet doesn’t always automatically mean that your code is really open source. That is, open sources as defined for example by the open source initiative. In short, even though people can see your code, it doesn’t mean that they necessarily are allowed to use it in any way. To be considered open source, the software needs to be allowed to be freely used, modified, and shared. This is where licenses come into play.

A license describes what  permission you give others about what they can and cannot do with the software you have written. There are many different (open source) licenses to choose from. This may make it a little bit confusing when you have to choose a license for your (hopefully open source) project. Licensing is a complicated topic, where there are still debates on what some of the terms actually mean. Although you should still look into this topic yourself when you want to adopt an open source license, I hope that this post will help you to more quickly decide what license you need or want. There are some great tools which can help you make a decision on exactly what license you should use for your, but there are two high level considerations which are important:


  1. Are you using other peoples code? If yes, what are the licenses of those codes and what do they permit? This may already restrict your choice quite a bit.
  2. Do you care whether your code and modification of the code will always remain open source or not?


The second question ties into the first one, because some authors of software have decided that they are willing to share they work with the world, under the condition that any version of their software and also in some cases the software which uses that software should follow those rules as well (copyleft). A well known example of such a license is the GPL license. Other authors have decided that they do not care if their code is used and modified inside closed source software, usually as long as there is some form of attribution to the original author (permissive). A well known example of such a license is the MIT license.

This means that if you are using any code in your software which is licensed by for example a GPL license, your license should in most cases also be GPL or equivalent, while if you are using no other code, or only code with for example a MIT license, you are free to choose your own license.

There are two extremes, but there is a lot of space in between here. An example of that is if you want your code and its modifications to always remain open source, but you are fine with it being used in closed source software. This is where LGPL license is in interesting option. Any modification to the LGPL will still need to have the same freedoms as LGPL provides, but there is an exception for sofware just using it. This is only really useful though if you have written software which is designed to be used by other software though.

One last note on this is that you are allowed to distribute your code under as many license as you want for your own code and let a user pick one. A common situation for this is to have both GPLv2 and GPLv3 licenses for a code, so that GPLv2 code can be use in GPLv3 code and visa versa, but there are other common mixes as well.

I hope this very short exploration of licenses will help you in getting a feel of why they are important and what your open source options are for your next project!

Menno is a postdoctoral fellow at UC Davis in the USA. He investigates the interplay between the crust and the mantle through numerical modelling, with a focus on the study of subduction zones. He is a primary developer and maintainer of both the geodynamics code ASPECT and the initial conditions generator code the Geodynamic World Builder. Menno is part of the GD blog team as an editor.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>