Success in advising these companies on crafting a license does not imply that the project or their choice to embrace this style of license will result in success. If they still call themselves open source, they are lying. The proper term is "source available."
No license guarantees success in any dimension. Not MIT. Not BSD. Not Apache 2 or GPLv3 or WTFPL or any of the PolyForm terms. Most open source projects, as I suspect you define open source, fail. Very little uptake. Very little outside contribution. Net loss, financially speaking, for the developers.
You're free to argue for or against whatever meaning of "open source" you like. But disagreeing with you, or refusing to accept the brand you'd force on them, does not make anyone a liar.
I was quite doctrinaire about the issue myself, for many years. It wasn't until I got beyond reading what the OSI said about itself---parsing the OSD, reading its history, dealing with the mailing list process, seeing the shifts in FSF position, reading up on the "open" buzzwords wars before 1998---that I realized the "right answer" I was so proud of having wasn't so right and rigorous, after all. I regret how badly I treated others, for the sake of my own feeling of "correctness".
We do have organizations that observe the actual usage of words and attempt to capture their use descriptively. Here's a fairly well-regarded source: https://dictionary.cambridge.org/dictionary/english/open-sou...
It is inaccurate to call someone a "liar" for something that falls into the realm of opinion.
Personally, I don't care what OSI says, though I do care very much what some of the individuals involved in it say. My clients occasionally care about OSI approval, but far less than you might expect.
I've also been a part of drafting licenses that I suspect nearly anyone would call "open source". The Blue Oak Model License, for example. I won't be submitting those licenses to OSI or FSF. As far as I know, none of the other folks involved in drafting them care to waste their time on that process, either.
Essentially, it will be an uphill battle for companies using these license to claim they are part of the open source community. Just because you are on GitHub doesn't mean you are COSS. I now consider Microsoft to be the biggest COSS company.
Is CC0 (not OSOI approved) software open source? How about AGPLv3 (approved)? Ethically licensed software (in process)? BSD/MIT (approved) code from standards bodies under separate patent? Adaptive Public License (approved) software that explicitly opts out of patent coverage? NASA's latest license (not approved)? RPL 1.5 (approved by OSI, not by FSF)? Apache 2 (approved) API wrappers that only talk to closed cloud services? WTFPL (not approved)?
I've released noncommercial licenses, avoided calling them "open", had others do so quite despite me, then hear, basically "I know, and I don't care" when I pointed it out. On the other hand, I know people who don't think copyleft counts as open source, or shouldn't any more.
There is a kind of lowest common denominator of sorts around MIT, BSD, Apache 2.0, maybe Artistic 2, assuming no patents. Some would add GPLv2, LGVPLv2.1, and maybe MPLv2 and EPLv2, for copyleft. All of those licenses have well known legal and practical limitations. Some are truly ancient, like MIT and BSD, and wouldn't be considered competently drafted now.
Free as in speech, without bias or contempt of others, will win in the end (I hope). This is why FSF "free" software (strong copyleft) is different from "open source" and they have different governing bodies. We are already seeing a pull back from copyleft and the overreaction the other direction (to non-compete) will both lose out to best in class humanity found in truly "open" source ideas.
Definitions are evolving, people will abuse language for personal gain, and the world goes on.
I am personally hopeful that open source will gain a wider and more pure definition beyond software and licensing. Like GitLab, transparency, and their handbook, or the maker movement and DIY / distributed / local production.
My license choice (of BSD-3) was based on the projects I work most closely with. (Golang / Cuelang)
- Companies are trying this out, like it's the best way forward, but we don't really know. We are seeing push back now. - Corp lawyers are defaulting to "No," one of the big COSS trying this out reverted after their license denial, Amazon open sourced their ES tools - Google and Microsoft have partnered with the big COSS companies to offer their products as a seamless experience (literally right next to Google products in the GCP UI with the vendor logos) - With the increasing ease with which software is being created, and in particular SaaS platforms, the license and interface defenses may quickly be replaced by open source alternatives. (re: Joe Jacks talking about COSS eating SaaS)
So we will see how this plays out. I am personally staying with BDS-3 Clause for our open source code and keeping other parts private.
> PolyForm is not Open source or free software. There are plenty of existing open source licenses. PolyForm is not a substitute for them, but an alternative for those who want to license source code under limited rights.
My opinions still voiced, substituting PolyForm for licenses which are of the offending nature I describe.