> All of us have direct experience with both OSI and FSF license processes. We have no desire to deal with them again.

As a more casual person looking to use a license, this is basically the opposite of what I want to read.

As a non-lawyer, I have little chance of vetting a license myself. As a person with life experience, I have full appreciation for the delicacy of these kinds of licenses and legal issues.

If a license has consensus from OSI, FSF, Debian, maybe a FANG company or two, etc., then I have some trust that a kind of validation and peer review has occurred. I fear that using a license for which this has not occurred puts the users of my software at risk, or at least shifts the burden of future validation on to them.

TLDR: everybody knows what MIT, BSD, Apache, and the various GPL licenses imply. I think other bespoke licenses have a pretty high bar to clear before they become truly useful.

I've written a bit on my experiences with OSI review in particular, and also the list of licenses it has approved. See, e.g., https://writing.kemitchell.com/2019/05/05/Rely-on-OSI.html. In a nutshell: people think there's a team of lawyers back there, counting angels on the heads of fine legal pins. But it's actually a highly politicized mailman list where activist-types do most of the talking.

I put energy into cofounding Blue Oak Council to publish rigorous resources, like our permissive license list, https://blueoakcouncil.org/list, in large part out of disappointment and dread, pulling back the curtain on the institutional processes for license review. As lawyers, we need functional resources like that license list, to incorporate by reference into contracts and policies. Fundamentally political artifacts, like OSI or FSF or Debian whitelists, are type errors in those contexts.

> everybody knows what MIT, BSD, Apache, and the various GPL licenses imply

I'm afraid that's not true. I would say there is broad agreement on many of the core aspects. And in many situations, practically, the specific license terms don't matter nearly as much as widely help expectations. But key concepts affecting fairly common situations remain unclear, and those details come out when there's money or strategic leverage on the line. See, e.g. the list Heather Meeker keeps at https://heathermeeker.com/open-source-faq/what-are-the-most-... See also the whole debate on permissive licenses and standards-essential patents: https://writing.kemitchell.com/2019/10/03/Open-Standards.htm....

Thanks for chipping in on this thread, you’re expressing things nice and clearly, now I have a few more links for describing this unhappy situation in open-source licensing.

Any chance you could change the slug on that first link from Rely-on-OSI to Dont-Rely-on-OSI-Approval or similar? The current URL suggests the opposite of the article’s content. Hopefully adding a redirect isn’t too onerous.

Point taken on page URL. Alas, it's been up a while and I don't have a ready redirect mechanism in place.

From the license text:

> You must ensure that everyone who gets a copy of any part of this software from you, with or without changes, also gets the text of this license or a link to https://blueoakcouncil.org/license/1.0.0.

To me this sounds like a viral public domain, so in a sense less permissive than MIT & co. If I modify the work but still have to put the text of this license when publishing it, the modified/derivative will be licensed under this license as well. Is this a fair assessment or am I missing something? I don't see how someone could take the work and use it in a proprietary software for example.

> If I modify the work but still have to put the text of this license when publishing it, the modified/derivative will be licensed under this license as well.

How does that follow? Compare:

MIT:

> The above copyright notice and this permission notice (including the next paragraph) shall be included in all copies or substantial portions of the Software.

BSD: > 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. > > 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

I'm not sure the reason for bringing up that clause, when the same clause exists in the MIT license:

"Permission is hereby granted [to do so-and-so] subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software."

If you're shipping MIT-licensed software (or anything derived from MIT-licensed software) without also shipping a copy of the license, then you're not in compliance with the license.