Best permissive license for a utility library?

Question

I have a small utility library of useful stuff written in Java that I plan on releasing open source. I've been wavering on what license to use. I quite like the BSD license, which is short and easy to understand, but I don't want/need the clause about including the disclaimer in their product's documentation. Considering just dropping that bit out.

Would the MIT license suit me better, then? It doesn't have the endorsement prohibition clause like the BSD one does, which is something I like about BSD's. Also, does MIT's clause about keeping the copyright notice on substantial portions of the software just refer to the source code, and not binary form or any documentation they produce?

From surveying other SO questions on the topic, I've seen a few people recommend the Apache license. Having a quick scan though it, it actually might do most of what I want really well, although even that amount of legalese makes my head hurt (particularly at 2:30AM when I should be in bed instead of on SO.) Thoughts?

Basically I want something that is:

• easy to understand,
• says you can use the code as you like, but keep my copyright and permission notice on the source code,
• you don't need to put the name of me or my product or copyright notice etc. in any documentation, manuals, etc. that you produce,
• don't try and use me or my product as a selling point for your product (not that my endorsement would count for much anyway!)
• and covers my butt in a reasonable manner. :-)

EDIT: Wow, 30 minutes and already some good responses! In response:

I'd prefer not to "mix and match" if I can help it, and produce yet another open source license. Using a standard license makes it easier for all of us.

The butt covering comment is a bit tongue in cheek. The warranty disclaimer that all the licenses mentioned include is really all I'm talking about.

EDIT: Reading through the Wikipedia page on the MIT License, I discovered that ncurses uses a modified version that has been approved by the FSF, that adds a non-endorsement paragraph. I figure if it is good enough for them, it is good enough for me.

I was considering the Apache license, however compatibility problems with GPLv2 would be an issue I didn't want to introduce.

Answer 1

Write your own. Or have a look at the CC-licenses: Wikipedia

And don't even think about "covering" your butt. If you get sued, because someone wants to blame you, the biggest hurdle will be to finance the legal shit. Not to be covered from any angle.

Unless you are Novell ;)

Answer 2

You could always add a prohibition clause to the MIT license. I've seen some versions of the license include it immediately after the existing clause. As for the copyright notice, the MIT license defines "the Software" as "this software and associated documentation files". That definitely includes documentation, and I'd argue it includes the binary form of the program, as well.

Answer 3

I use the Apache Licence for my projects. It seems to be the default licence choice in the Open Source Java world (thanks mostly to the early work of the Jakarta projects). It's less hassle to combine different libraries in one project if they all have the same licence.

Answer 4

• Does MIT's clause about keeping the copyright notice on substantial portions of the software just refer to the source code, and not binary form or any documentation they produce?

My interpretation of the license is that you only need to have the copyright notice on the Software (which is defined in the first sentence as the license). This would refer only to the source code and documentation - binary form wouldn't contain the license, a compiler is going to throw out all the comments anyways. No to mention it's not human readable.

Feel free to add this clause to the MIT License (you are allowed to mix and match):

Neither the name of the nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.

The Apache license is more liability resistant, but to a programmer all the "legalese" will probably scare them away from using it. In my opinion (which is not legal advice), modifying the MIT license to contain the endorsement prohibition is the best way to go. Easiest to understand and the warranty waiver is going to cover any direct or indirect claims that come at you.

Edit to Author's Edit: If you don't want to mix and match licenses then go with the Apache license. It does everything you want and more (including some nice patent clauses). The license block for your code is simplistic because it will link to a website and it is well documented.

Answer 5

The boost license looks like what you want, doesn't it?