Open source software licences explained

in

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.

We also answer some common questions about other options such as academic-use only licences.


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?

  • "I'm publishing an implementation of a method associated with a paper"
    — Consider a BSD-style licence.
    — Read more about BSD-style licences.
    — Here's how to apply a BSD licence to your code.

    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.
  • "I'm publishing a self-contained library, and I intend to maintain it"
    — Consider using the LGPL.
    — Read more about the LGPL.
    — Here's how to apply the LGPL to your code.

    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.
  • "I'm writing a complete application"
    — Consider using the GPL.
    — Read more about the GPL.
    — Here's how to apply the GPL to your code.

    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.


Further reading