Choosing a license for your next project

Not so long ago I started working on a new project which I wanted to release under an open source license. But when I went over to the Open Source Initiative I was amazed by the dozens of licences they have for software. Nevertheless I decided to dive into the matter and came up with some guidelines. The text below is written from a webdeveloper perspective, not by an attorney. This should in no case be regarded as legal advice.

Reciprocity and Restrictiveness

Open source licenses all vary in how much they require reciprocity and how restrictive they are on how you can redistribute or modify the work. There are however four general groups:

  • Unrestricted
    Several licenses, most notably MIT and BSD (and in some countries, public domain), place no restrictions on redistribution other than no warranty and a requirement to keep the license text. This allows, among other things, distribution in binary-only form and bundling with proprietary or differently-licensed software.
  • File-based
    The Mozilla license requires any modifications to the application files themselves to be open sourced (and available as source) but allows bundling with proprietary software.
  • Open source all derivatives
    The GPL version 2 requires any “derivative work” to be open source and under the GPL itself. The definition of derivative work varies according to whom you ask, but it’s generally accepted that you can’t bundle GPL code with non-GPL code in the same packages, nor place any additional requirements on the GPL code (i.e. no fees for access to source code).
  • 100% Open source all the time
    The Affero GPL, and to a lesser degree, the GPLv3, place a number of strong restrictions designed to curb various ways of getting around the requirements of modifications of GPL code being open source. This includes open source requirements for SaaS applications, hardware, and closed-box applications.

Generally speaking, the more you care about having as many people as possible use your source code, the less restrictive license you should choose. The more you care about preventing non-contributing commercial users “stealing” your source code, the more restrictive license you should choose.

Popularity

The more popular the open source license you choose, the easier it is to combine with other open source software and thus the less likely it is that your license will be an obstacle to adoption. The most popular licenses are probably the GPLv2, GPLv3, BSD, MIT, Artistic and Apache licenses. Choosing an obscure or legacy license means that your license may cause users to shy away from using your software.

Specific Restrictions

Sometimes you want to place a specific obligation on redistributors of your work. This requires spending a lot of time reading the license text themselves and probably a trip to a lawyer. Examples of restrictions people like are patent retaliation clauses (CDDL, GPLv3), and advertising clauses (Artistic).

Business Model

Finally, if you want to make money on your software, you should choose a license which is compatible with your business model. Permissive licenses generally work well with services and value-add business models, while restrictive licenses work better with dual-license and support business models.

Summary

You should certainly spend some time choosing the license that is right for you. If you’re not sure on which to settle, ask your lawyer for advice! If you don’t want to figure this all out by yourself you can always use John Cowan’s excellent license selection wizard. However, this is somewhat restricted to older licences.

11 thoughts on “Choosing a license for your next project”

  1. And maybe you want to release the “content” of your project under another more content specific license like Creative Commons

    Content like in images, documentation, templates

  2. Generally speaking, the more you care about having as many people as possible use your software, the less restrictive license you should choose.

    I would substitute “software” with “source code”. Because true Free Software should not limit the usage software, and it only places terms on (re)use of the source code.

    1. True, I’ve corrected this but I also found the following for version 2.0 of the Apache license.

      ” [...] Unless explicitly stated otherwise, any contributions submitted by a licensee to a licensor will be under the terms of the license without any terms and conditions [...] ”

      So if your licensees contribute or modify your source those contributions and alterations have to be under the same license as the original.

      1. “contributes” in this context means gives back to the original project.

        Say you provide a patch to Apache’s httpd then that patch must be under the Apache license in order to be acceptable as a contribution.

        I addition “unless explicitly stated otherwise” gives you any freedom to change the licensing terms if you are providing a combined work.

  3. “The definition of derivative work varies according to whom you ask, but it’s generally accepted that you can’t bundle GPL code with non-GPL code in the same packages, nor place any additional requirements on the GPL code (i.e. no fees for access to source code).”

    Indeed, the Dutch Copyright Act (“Auteurswet”) does not speak of “derivative work”, and thus it is not clear what has to be understood by such a term (although we know the term “bewerking”, the meaning is not the same). Thus, within the Netherlands one should determine what meaning the parties* to the contract gave to that term and what they have and could expect from each other. It may be argued that also the meaning of the OSS-community is very important for defining “derivative work”.

    Moreover, I would like to introduce a nuance to your remark that it is ‘generally accepted that you can’t bundle GPL code with non-GPL code in the same package, since this depend on whether the created work is a derivative work, a compilation or collection of works, or even separate works. All of this depends on the degree of intimacy between the codes. Is the work linked dynamically or statically? And in what technical manner? These are all very important factors, which can even result in the code NOT being ‘infected’ by the viral effect of the GPL. Thus…..

    “If you’re not sure on which to settle, ask your lawyer for advice!”

    ;-)

  4. Well written. Thank you for this :) I’ve been having difficulty in deciding how to release modifications to my fork of the IdealistViewer for OpenSim. I want to use several open source libraries, but a few of them conflict.

    In the end I may end up continuing the BSD licence that IdealistViewer currently has and writing my own libraries instead of using others’. It’s just a bit frustrating since Open Source really should work better together.

Comments are closed.