IANAL either*), and indeed it is worth talking to a few lawyers that know at least about the difference between common and civil law, and the peculiarities of the variations of the former.
First of all, thank you for this initiative, and the only additional comment I have is “what took you so long”.
Now with respect to which license to choose, there is indeed a small selection of reasonable ones, and some effort should be spent choosing the right one.
The important questions here are:
1) what is good for the licensee, and
2) what is the onus on the licensor (in addition to giving the copyright away, which is the point).
Let’s look at the two relevant groups here, MIT/BSD, and Apache 2.0.
There is no single “BSD license”; there is a 3-clause and a 4-clause one, and we certainly want to avoid the toxic 4-clause one (with the advertisement clause). There is also a non-attribution clause, which is not really very useful — once you take that out, you essentially get the MIT license, which is indeed currently the leading permissive license for open-source projects.
The language is now simple enough that there is essentially zero onus on the licensor. As the numbers on github show, people already have voted with their feet here.
The Apache 2.0 license was written for the Apache foundation, and you can argue it was written in the interests of the foundation. It trades additional onus for the licensor for a better position of the licensee, making it more attractive for the licensee to use the software governed by the foundation. That is great if you have a foundation that already has traction. But the additional onus on the licensor may be a problem. The Apache 2.0 license not only signs over the copyright, but also grants patent rights. You need to understand the difference between these two to understand why this is a mountain of a problem. Copyright is well-understood; unless you set out “stealing” stuff, it is relatively hard to create a problem with copyright (SCO has shown you still can, in the US legal system, but that is a problem with that legal system).
Patent rights, however, are a legal cesspool. Not only does nobody really ever know what patent rights they have or are subject to**), the act of communicating about these (or thinking about these in a form that may later be retrieved by legal discovery) is toxic (i.e., greatly damages any legal position that the company may have). No company executive in their right mind wants to touch patent rights unless absolutely necessary, even if lawyers can make a ton of money in the process.
A lawyer that is asked to sign off on a source code release that grants patent rights would need to do all of the above. (How do you even find out which of your patent rights are touched by the code?) To me, it seems a license that requires signing away patent rights is a recipe to talk deciders out of making source code releases, in particular for larger companies that have powerful patent departments. Of course, some very large companies have established processes that can handle the Apache 2.0 license, so it may not be completely black and white. Companies that already have formed a consortium will have formed an opinion on this (Broadcom’s recent sudden exit from OIC serves as a warning light, though), so the Apache 2.0 license is less inappropriate for a consortium.
TL;DR: Go for the MIT license***).
Grüße, Carsten
*) But I have wasted too much of my life talking to them, and second-guessing some of their bone-headed moves.
**) If you think otherwise, you have no idea. Really.
***) (And if you must go for Apache 2.0, do so after talking to people who have real-world experience with getting source-code releases out of non-trivial organizations.)
))