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:
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.
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.
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.
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).
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.
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.