Summary: I plan to license all future packages under the "BSD-3-Clause OR Apache-2.0" license.
A few weeks ago I calculated that the distribution of Haskell library licenses is approximately:
- BSD-3-Clause: 67%
- MIT: 20%
- Apache-2.0: < 2%
In contrast, Wikipedia suggests for most open-source libraries the Apache-2.0 license beats BSD-3-Clause, and it is the permissive choice of FSF/Google etc. I was curious why it was so rare in the Haskell world, so asked on Twitter. The resulting thread got my thinking about license choices, which changed my view of what license I'd like to use. In this post I'm going to go through my reasoning.
The license I want to use
What I want to say is that anyone is free to use my code for any purpose. If they make changes to my code which would be of general benefit and have a chance of being accepted upstream, they should post those changes publicly. I give my work away freely, and want the version I'm giving away to be the best possible version for everyone. No license matches this intent, none force you to share code that you improve but only use internally, and the legal definition of "general benefit" can only be arbitrated by me. As a result, I'd like people to follow those principles, but chose to release my code with far fewer restrictions, in the hope people will do the right thing and share improvements anyway.
The license I use
When I first started releasing code (around 2004) I originally licensed my code as GPL-2.0, because that was a protective open-source license and I was still dipping my toes in the open source pond. By 2007 I was releasing new libraries as BSD-3-Clause, since that was what everyone in the Haskell community was using and seemed to provide the benefits I wanted (people sent me patches without being legally compelled to, just for the good of the code, which I prefer). It took until 2012 for me to switch my earliest libraries to BSD-3-Clause - one to avoid annoyance at work and another at the request of a commercial company who were linking it to proprietary pieces, and then went on to contribute extensively for the benefit of the project. Currently, all my projects are BSD3 licensed.
The license I will use
But what license should I be using? These questions prompted me to hunt around and I came to the conclusion that the right license for me is:
BSD-3-Clause OR Apache-2.0
Concretely, I plan to license all my future libraries under both the BSD-3-Clause and Apache-2.0 licenses, but a user is able to use it under either. My reasoning is as follows:
Why BSD-3-Clause over MIT?
I debated BSD-3-Clause vs MIT for a long time. They both offer substantially the same freedoms, but BSD-3-Clause also requires you can't use my name to endorse things you build - which seems reasonable. I like MIT because it's less ambiguous as a name, and it makes explicit freedoms that are implicit in the BSD-3-Clause license. The fact that BSD-3-Clause is more commonly used for Haskell libraries and my existing libraries is a point in it's favour. In the end, I picked BSD-3-Clause.
Why Apache-2.0?
The Apache-2.0 license offers a patent grant - I'm promising that if you use my code I'm not going to sue you using my patents. If I gave you code and then later sued you for using it, that would be mean. More importantly (from my side at least) it ensures everyone contributing to my library is following the same basic "don't be mean" principle, so I can continue to use my code free from patent concerns.
Why both?
The OR in the license means that I (and all contributors to my libraries) license all the code under BSD-3-Clause, and entirely separately also license all the code under Apache-2.0. Users are free to use the library under either of the available licenses, making it a user-centric OR. The Apache-2.0 license is incompatible with the GPL-2.0 and LGPL-2.1-only licenses, meaning any library building on my code plus the GTK bindings would be in a license quandary. By licensing under both most users can use Apache-2.0 (it gives you patent protection, so it's in your best interest), and those that would have problems otherwise can stick with BSD-3-Clause.
Next steps
Licensing is a slightly sensitive topic, so I'm declaring my intent, and waiting for feedback. Hopefully this change is positive for everyone, but anyone with concerns should let me know. As to technical detail, Cabal 2.2 supports SPDX license expressions, which is the syntax I've been using throughout this post.
7 comments:
Happy to hear cabal supports SPDX expressions!
Minor remark: both the FSF and OSI use "copyleft license" instead of "restrictive open-source license" (which is clearer: Apache could be considered "restrictive" too compared to MIT). If you didn't mean copyleft, but any rights in general, Mark Webbings suggest the wording "protective open-source license".
Interesting post and solid reasoning: Apache not being compatible with GPLv2 is a fact and unfortunately not all projects can update to GPLv3; offering dual licencing is the pragmatic way to go.
Thanks Francesco, I reworded to protective, since at that time I was more going for additional protection, and copyleft was just the form that happened to take.
Since GPLv2 compatibility is driving the dual licensing, would 'Apache-2.0 OR GPL-2-Or-Later' also serve? I'm not sure it's better than Apache/BSD3, but I'm not sure it's worse, either.
It's also LGPL compatibility, but LGPL-2.0 covers that. The advantage of BSD is that it's a subset of LGPL and probably any other license that might have a problem in future, like a universal donor for blood types.
In my opinion Apache 2.0 is the sanest choice.
It's made by lawyers that understood the complexity of the current landscape, in which software patents are booby traps. It's also very permissive, so it's not a copyleft license.
BSD / MIT are essentially traps, especially when it comes to projects released by big companies, like Facebook or Microsoft.
Such companies started practicing BSD + PATENTS.txt, however the PATENTS.txt is designed to serve and protect the parent company, not other contributors or the users and the existence of that PATENTS.txt is actually worse than not having one at all, because without one in the US there's the concept of the "implicit patents license" that can apply, although I don't think this is battle tested. And the concept isn't necessarily valid elsewhere, like in the EU.
Apache 2.0 is a permissive license done right. Note that it is not compatible with GPL v2.0, but that's because GPL v2.0 is broken due to (1) disallowing other restrictions + (2) not having an explicit patents grant. They fixed that in GPL v3.
Dual licensing is a pain to be honest, but it's better than making the wrong choice.
I started writing all my new code as `BSD-2-Clause OR Apache-2.0` a week or two back as well. (I think as a result of the same twitter licensing discussion.)
I'd already weakened from `BSD-3-Clause` to `BSD-2-Clause` as the extra clause added no real substantive protection anyways.
Due to relicensing headaches, I've yet to go back and do this to anything that already has contributors other than me though.
Awesome! I've now switched my first package over: https://github.com/ndmitchell/record-dot-preprocessor/blob/master/LICENSE. Like you Ed, I'm not planning to do it retrospectively for many packages (only those with nearly no contributions).
Post a Comment