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.
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
I like the simplicity Creative Commons offers when choosing a specific license. I use it myself for my images.
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.
I edited the text to your suggestions, thanks!
The Apache License doesn’t require modifications to be open sourced at all, it likely belongs into your “unrestricted” category.
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.
“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.
“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!”
😉
(* remark: parties: Who are the parties to an OSS-license?!)
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.