Is the ISC license suitable as a MIT or Simplified BSD license replacement?
What are the pros and cons of ISC compared to MIT or BSD?
bsd licenselicensingmit-license
Is the ISC license suitable as a MIT or Simplified BSD license replacement?
What are the pros and cons of ISC compared to MIT or BSD?
What's wrong with gaining some notoriety if someone makes a well-known piece of software using your code?
(The issue is not with someone using your code. The issue is with someone using your name or your product's name as an endorsement for their code or actions ... and giving you or your code a bad reputation as a result.)
I can think of a number things that could be wrong with that kind of notoriety:
Also, wouldn't dictating what users can and cannot do with your given name fall outside the domain of intellectual property?
The "domain of intellectual property" is not a concept that has any significance to the enforceability of the terms of a license.
What matters is whether people who want to use the licensed material are prepared to accept the license conditions that you have set. As the owner of the IP, you are entitled to place any conditions on its use that you want to*. Other people can then choose to use the material subject to the conditions, or not use it at all.
* - Actually, there probably are limits on what conditions you can set. A condition requiring someone to perform an illegal act is probably illegal, and definitely unenforceable. Also, legal but "unconscionable" conditions are likely to fail a challenge in a lawsuit. IANAL - talk to one if you need legal advice.
My understanding is that:
- MIT-licensed projects can be used/redistributed in BSD-licensed projects.
True (but unless there are modifications, the users can get it from the sources also.
- BSD-licensed projects can be used/redistributed in MIT-licensed projects.
False MIT license allows for distribution without contribution credits; BSD doesn't.
- The MIT and the BSD 2-clause licenses are essentially identical.
False See above.
- BSD 3-clause = BSD 2-clause + the "no endorsement" clause
True.
- Issuing a dual license allows users to choose from those licenses—not be bound to both.
True.
Similarly, since the MIT and BSD licenses are both "GPL-compatible" and can be redistributed in GPL-licensed projects, then dual-licensing MIT/GPL also seems redundant.
No. Here is a major difference. MIT license and Apache License only requires that you give credit to original copyright holders. If you choose, you can redistribute source; but if you choose you can keep your new derived product without opening code. Hence, it is possible to use code developed under MIT and Apache—under a commercial license.
If you ever use code with GPL-based license and happen to modify it, you must distribute your modified code as well under GPL. In other words, once any GPL codebase is used under a project, and if you want to publish that as a product, it has to be published with the source code and it has to be published under GPL. It cannot ever be a commercial license or closed source, and it cannot be any other license which is less strict than GPL.
An example can take MIT, Apache or BSD license code, modified and distributed under GPL. Once a codebase is distributed as GPL, its further derived versions cannot be distributed under MIT, Apache or BSD license but must be GPL only.
An example case of dual license: Suppose Nice Office is released under dual license—MIT and GPL. It has two possibilities. Some people can create NicePro Office, which can be commercial and sell. Whereas some other open source community creates a fork NiceOpen Office. In this case, it can enforce upon GPL distribution (of the original Nice Office as well as NiceOpen Office version) hence if you start with NiceOpen Office, you must comply to GPL only and not MIT license.
The point is in case of dual license the first person who derives a license has a choice. He can choose either way - however, the second person needs to adhere to the choice the first person made. He/She cannot override the original rights of either generation and cannot in any way reduce the obligation of the applicable license.
Adding an interesting read - GPL and MPL Licenses has a serious conflict. Read this.
Best Answer
"It's okay." Removing the now redundant language due to the effects of the Berne convention is good.
FSF has this to say:
Which basically means that the terminology is just vague enough that people might shy away from using your software. The problem is that the license doesn't explicitly grant the right to distribute modified versions of the software.
If you decide to use this license, you'll need to expressly indicate your intent on whether users are allowed to distribute the modified version of the code. Even then, people will still shy away as that intent is not explicitly spelled out in the license.
Honestly, I'd recommend a different license. FSF recommends FreeBSD or Expat (aka MIT) over OpenBSD / ISC. This is the Wikipedia article comparing Open Source licenses.
In general, stick with the bigger, better known licenses. Why, you might ask? The less work people have to invest in order to understand your license then the more likely they are to consider using your software. If you use an obscure license, they'll simply move on to the next project or roll their own so they don't have to worry about potential legal issues.