I think it is too wordy though, and for 99% of projects, the MIT vs BSD vs Apache difference is not terribly important, so why weight your project down with a crazy big license?
I prefer MIT. It's a little clearer to me, and is claimed to be GNU GPL compatible.
MIT has a killer failing: it was developed prior to the onset of software patents, and so has no patent release. This dooms it to being appropriate for only trivial projects. It doesn't matter if you think there's nothing patentable in your code: others don't know that. If you want people to use your code in this day and age, a patent release is critically important.
Use Apache. Why be concerned about license length? Include the license once and then refer to it in your source copies. No big deal.
It depends deeply on the project. Some something like, say, an HTTP API wrapper module, MIT/BSD style licenses are quite sufficient. There shouldn't be something patentable there. Apache, unfortunately, isn't compatible with GPL v2.
But if you're building something like node.js, nginx, or Lucene, choosing MIT/BSD is likely a terrible idea. Apache gives huge protections for unforeseen scenarios: automatic property rights assignment for contributions, poison-pill–like protections against patent suits, &c.
The job would have be trivial enough to make it clear to everyone concerned that there was nothing patentable in it, I suppose.
As to GPL compatibility, I've seen this play out with the AFL too (I use the AFL a lot). My take on it is: GPL incompatibility with well-designed, modern licenses like the AFL and Apache is not their fault. It's the fault of the FSF for producing licenses with outstanding flaws. As someone firmly in the BSD camp, I'm not too concerned about the FSF's foibles.
> It's the fault of the FSF for producing licenses with outstanding flaws.
Please, tell that to Linux users. Now, compare the vibrant ecosystem around Linux with the vibrant ecosystem around FreeBSD and try to think why it happens and what's the difference between them.
> GPL incompatibility with well-designed, modern licenses like the AFL and Apache is not their fault. It's the fault of the FSF for producing licenses with outstanding flaws.
That URL provides no support for your claim at all, and OpenBSD isn't even mentioned. Sadly, a moderate amount of Googling has turned up nothing about why OpenBSD doesn't allow the Apache License: all dead ends. The only thing that turns up is "well, we don't like it philosophically". Perhaps you could point to something more concrete.
"Mixing copyright law with patent law", whatever that means, has nothing to do with risk in commercial products. Apache is very well regarded as a BSD-style license in the commercial environment.
I agree that the Apache patent clause is important. In fact if I recall it motivated some of the changes in GPL3 in order to make it compatible with the Apache license
I think it is too wordy though, and for 99% of projects, the MIT vs BSD vs Apache difference is not terribly important, so why weight your project down with a crazy big license?
I prefer MIT. It's a little clearer to me, and is claimed to be GNU GPL compatible.