Choosing a license
April 17, 2014 9:31 am community, freesoftwareOne in a series of indeterminate length I am calling “mostly unimportant questions which take an inordinate amount of time to resolve when releasing a project as free software”. For the next topic, I’m hesitating between “naming”, “logo/icon/mascot design” and “mailing lists or forums”.
Choosing a license
Free software projects need licenses. But choosing a license is such a pain that most github projects don’t even bother (resulting in an initiative by Github to rectify this). And when taking a closed source project and making it free software, the topic of license choice will take a huge amount of time and effort.
I have found the following questions accelerate things nicely.
- Does the project exist as part of a greater ecosystem (eg. Apache, Eclipse, GNOME, Perl, Ruby)?
- If so, is there a predominant license in that ecosystem (eg EPL for Eclipse, MPL for Mozilla, MIT for Ruby gems, BSD for *BSD)? Then use that license.
- Does your business model depend on you having total control of the project for the foreseeable future? (Aside: If so, consider changing your business model) Consider GPL v3+/proprietary dual license
- Do you want to grow a vibrant developer community around your project? If not, why not? Avoid dual license, copyright assignment
- Do you want to grow a vibrant service partner/extensions ecosystem, including proprietary extensions, around your project? Avoid GPL v2+ or v3+ – prefer MPL v2 or Apache v2
- Do you have any dependencies whose licenses you must comply with (eg. GPL v2 hard dependency)? Ensure you can distribute result under a compliant license
- Do you have concerns about the patent portfolios of potential project contributors? Choose from GPL v3, MPL v2, Apache v2 for stronger patent protection for contributors – avoid MIT or BSD
- Do you believe that all contributors to the project, including extensions, should be subject to the same rules? Choose GPL v3
- Do you believe that the source code is free, and people should do whatever they want with it as long as they give you credit? Choose MIT or Apache v2
- After answering these questions, are you considering a license outside of (L)GPL v3, MPL v2, Apache v2 or MIT/BSD? Don’t.
After all of this, there are still situations which can lead to different outcomes – perhaps you want to join a specific non-profit later, and your license choice will be influenced by that. Perhaps you have a dependency currently which you plan to work around later, and you might dual license source code contributions under multiple free software licenses to allow relicensing easily (as OpenOffice.org and Mozilla have done). But the answers to the 10 questions above will at least reduce the scope of your search to one or two licenses.
Any considerations I have missed? Comments welcome!
April 17th, 2014 at 9:16 pm
[…] Choosing a license […]
April 18th, 2014 at 9:43 am
And what do you when 2 & 10 are in conflict?
April 18th, 2014 at 10:06 am
Col: 2 comes first. An Eclipse project should choose EPL, even if I think MPL v2 is a better EPL-like license.
April 18th, 2014 at 3:29 pm
Is it to me or the MIT license is the new BSD license?
April 18th, 2014 at 3:52 pm
MIT and BSD are very similar licenses – MIT is more widely used in areas like Github, the Ruby community, PHP… The BSD license is not widely used outside of BSD. If you have to choose, and neither is an obvious choice, I’d go with MIT and be done with it.
April 18th, 2014 at 4:21 pm
I would distinguish between ‘foundation ecosystems’ and ‘language ecosystems’. The foundations that have fairly strict licensing standards (ASF, Eclipse) take care of that issue.
With language ecosystems I think the issue is more complex. You might say that the MIT license is a good choice for Rubygems because it is already popular for Rubygems (though there’s a kind of political conservatism built into that viewpoint, which I share, that bothers me). But there are language ecosystems where what we see is libraries under some license (often noncopyleft) and most applications are proprietary. (I am indebted to Chris Webber for helping me understand this.) The fact that license X is popular for libraries doesn’t mean it’s appropriate for applications in the same language, and the tendency for such applications to be proprietary kind of underscores that point.
April 19th, 2014 at 9:36 am
I really like your arguments, but what I’m missing is the AGPLv3. Today where more and more software is used as SaaS this is a important option, which people should really consider if they chose a license.
April 19th, 2014 at 5:01 pm
Avoid the GPL entirely.
It’s only useful if you assume that running the software server-side and piping the result over the network will remain infeasible forever. Hint: it already isn’t.
Use the AGPL instead.
April 21st, 2014 at 8:55 pm
“7. Do you have concerns about the patent portfolios of potential project contributors?”
Every project with potential contributors residing in a country with broken patent laws (like the United States) should answer yes to this question.
April 22nd, 2014 at 7:59 am
Phil: I disagree. Many project developers do not care (nor should they) about patent infringement, and don’t let it get in the way of them doing stuff. All the projects who choose MIT, Artistic, BSD or even GPL v2 do not explicitly get patent grants from project contributors, and nevertheless they have no major issues.