I agree about the ISC, that's why OpenBSD, the most free OS (as in you can do whatever you want with a larger percentage of it than any other OS), prefers using the ISC over the BSD license now.
The FSF's site[1] points out what looks like a serious problem with this license:
> This license does have an unfortunate wording choice: it provides recipients with "Permission to use, copy, modify, and/or distribute this software…" This is roughly the same language from the license of Pine that the University of Washington later claimed prohibited people from distributing modified versions of the software.
To me, it sounds like "modify and/or distribute" means it should be okay to both modify and then distribute the modified version. But I'm not a lawyer, and if the same language has been used to argue you can't distribute modified versions, that's pretty scary. Enough reason to prefer the slightly longer MIT license.
I was under the impression that that website is outdated. The ISC used to just say "and distribute", which is similar to older versions of the Pine license, and had problems. However, the new language is more similar to the MIT license ("and/or ..."), but the FSF does not have an issue with the MIT license.
The FSF quotes the new version with "and/or" in the blurb claiming problems with wording, but that may just be an editing mistake; maybe someone went through and corrected the quotation without realizing it resolved the concern.
Either way, though, the OpenBSD folks didn't change "and" to "and/or" in their template, which ranks high for a search for "ISC license". Someone could easily copy the older, problematic version. Given the MIT license works fine, why take even a small risk?
> To me, it sounds like "modify and/or distribute" means it should be okay to both modify and then distribute the modified version.
In fact, and/or is exactly the way to specify that options can either be used together or separately. The FSF's claimed problem, you'll note, isn't that this language was ever held to restrict distributing modified versions, only that similar language was once argued by a party with a financial interest in the outcome to have that effect.
Which is a pretty flimsy basis to assert a problem. I'm sure you can find passages in the GPL that are "roughly the same" language to something that someone, somewhere, argued in a court case meant something that would be frightening if it was what the similar language in the GPL passage was actually treated as meaning under the law, but the fact that someone once argued that a similar piece of the language means something doesn't mean that the language that they argued about (and even less, the actual license language that it is "roughly the same as") has ever been or would ever be given that effect in court.
Ultimately I care more about avoiding the increased risk of the ISC license than about saving a few lines. It would be silly if trying to make my license statement a few insignificant lines shorter prevented someone from using my open-source code.
My point was that the argument that there is increased risk is based on a flimsy premise which could equally well be applied to just about anything; there's very few pieces of commonly used legal language where someone, somewhere hasn't at one time or another argued that something phrased in "roughly the same" manner means something that you'd want to avoid.
