Open source software licences explained

If you are planning to publish some software as open source code, you need to include a licence so that other people will know what they can do with it.

(Even if you don't care what people do with it, you should make that clear through a licence. The default copyright regime in most countries won't permit anyone to make any legal use of your source code otherwise.)

Putting a licence with your code is easy, typically just involving adding a single file in your source code project or a few lines at the top of each source file.

Reviewing the options

There are three classes of licence widely used for open source software.

Follow the links to read about the pros and cons of each, about what they mean to you if you are building on someone else's code, and about how to apply them to your own software:

Although the one-line descriptions above give some flavour of each, you'll have to read the fuller descriptions to get a clearer idea of what they actually permit. All three of them allow people who receive your source code to use, modify, and redistribute it without a fee; the main difference is in what sort of reuse (in terms of incorporating the code into another piece of software) is permitted.

How should I decide what licence to use?

First, review your code!

Have you incorporated any other code that you might not have permission to distribute under any or all of these licences? (For instance, are you using GPL code from someone else—in which case you need to follow the GPL as well, or else replace that code?)

Or are you reusing code that you don't have permission to distribute at all? Find out before you go any further!

Make sure you know who owns the copyright in your work; whether your institution or funding body has any specific policies about publication and licensing; and whether you have permission to apply particular licences to your software.

After all that, here are our guidelines. Which of these applies to you?

Why? If you want your code to be referred to by other researchers; it's not a complete application; and you don't intend to explicitly maintain or support it yourself, the BSD option makes for the simplest possible legal landscape. The idea is to eliminate obstacles to other people doing research in the future.

Consider, for example, that you will not always be around to ask for permission to use your code, or that the technical environment may change and make less permissive licence requirements unexpectedly hard to comply with. BSD terms are also the simplest for people who wish to cite or quote your work.

Why? The LGPL aims to strike a balance between the free-for-all of BSD and the tighter line associated with the GPL, and it can work well for libraries that will be actively maintained by their authors.

Why? The GPL is often appropriate if you are more interested in making your application available to end-users than in permitting other developers to reuse the code itself. But take care if you are planning to distribute through a channel that doesn't permit using the GPL, such as one of the Apple App Stores.

"I'm uncertain (or my institution is) about the idea of publishing source code at all"In this case, you might find the GPL provides more reassurance than a more permissive licence. For example, if you are in the position of having to persuade your supervisor that your code should be released, it may be worth mentioning the GPL's protection against certain sorts of commercial exploitation.

"I'm writing code to work with an existing framework"Then check whether it has a licence policy already. For example, Python code contributed to SciPy should be under a BSD licence (see reference).

Remember, too, that the licence is something that the copyright holder provides and people who receive the code need to comply with. It doesn't bind the copyright holder. You can always provide your own code under more than one licence, or change the licence later on, although you can't retract any licensed code that has already been published.

Disclaimer: The author is an experienced developer of open source software who has read and used all of the licences described here, but who has no legal training. These are informal suggestions, not legal advice. If you become aware of any errors, please let us know.

Recent notes

Announcing the winners of the MLSP 2014 and SoundSoftware.ac.uk Prizes for Reproducibility in Signal Processing, organised by SoundSoftware.ac.uk in conjuction with the IEEE Signal Processing Society for the 2014 IEEE International Workshop on Machine Learning for Signal Processing.

The SoundSoftware 2014 workshop, our third annual workshop on software and data in audio and music research, was just as enjoyable as the previous two. Because so much research in this field ends up being expressed through software, a software workshop turns out to be all about the means by which research becomes useful and relevant to people other than the original researchers—fertile ground for interesting and thought-provoking talks.

Our third annual one-day workshop on Software and Data for Audio and Music Research takes place on the 8th of July 2014 at Queen Mary, University of London. The workshop includes talks on issues such as robust software development for audio and music research, reproducible research in general, management of research data, and open access. Read more here, clear your calendar, and register now!