> The Open Source Definition says nothing about [very long list]
There is nothing in your list that is different for open-source and proprietary software development. You could as well add countless articles about OOP and functional programming because they mention some open-source tools.
OSD is about answering three simple questions. Should I use some program or library? Should I contribute to its development? Should I release my new program or lib as open-source? OSD makes process of choosing the answer fairly simple and helps developer avoiding all weird legal stuff. He doesn't need to know OSD and read full texts of licenses as long as he uses most adopted like MTI, BSD, GPL. Descriptions of pros and cons of every one of them in layman terms are available on the internet. It's hard to say the same for the ill-conceived licenses you mentioned.
I can't sell some project based on Lerna to [list of companies] ? OK. How am I supposed to check that the company didn't change name? What if I am selling my work to subcontractor? I would probably have to include this list in every contract. What if every open-source project started banning some arbitrary list of companies? Am I supposed to review the last commit to license every time to make sure that my company wasn't included? All that looks, sounds and smells like a lot of headache and any reasonable person would drop the project with first sign of it.
Commons Clause was even worse. It was advertised as "MTI+CC", but nobody would be able to figure out what "CC" part meant for them without a lawyer. And any lawyer would advise to find something else.
> There is nothing in your list that is different for open-source and proprietary software development.
That's not right, even assuming full "Innersource".
My point was that OSD is a set of criteria for licenses, plus a source-availability requirement. Those criteria don't predetermine all the practices that make up open source development right now. Those practices have changed! The OSD largely hasn't.
> OSD makes process of choosing the answer fairly simple and helps developer avoiding all weird legal stuff.
If you've managed to avoid all weird legal stuff so far, I'm glad for you. A good portion of my legal career is addressing weird legal stuff, which crops up even with MIT, BSD, and GPL, to use your list. The GPLs and other copyleft licenses are chock full of weird legal stuff.
> Descriptions of pros and cons of every one of them in layman terms are available on the internet. It's hard to say the same for the ill-conceived licenses you mentioned.
I wrote one of the more popular guides to MIT in layman's terms:
The License Zero licenses are far easier to read, besides. That was part of the point of writing them from scratch.
> What if every open-source project started banning some arbitrary list of companies?
Highly unlikely. And that is not the approach of the License Zero licenses, React, Commons Clause, or most others that I mention.
If somehow this did become popular---again, very hypothetical---I'd go into npm and RubyGems and other package managers, and propose a package metadata field for excluded entities, and perhaps standardized categorical exclusions. This still sounds inconvenient, and I agree that it would be. But to give you a sense of near current practice, some large companies prohibit use of open source from specific competitors, even under permissive licenses, especially when the patent terms of the license are weak or nonexistent. That would include MIT, BSD, and GPLv2.
> And any lawyer would advise to find something else.
Or do a deal with Redis Labs. Which was the point, I think.
There is nothing in your list that is different for open-source and proprietary software development. You could as well add countless articles about OOP and functional programming because they mention some open-source tools.
OSD is about answering three simple questions. Should I use some program or library? Should I contribute to its development? Should I release my new program or lib as open-source? OSD makes process of choosing the answer fairly simple and helps developer avoiding all weird legal stuff. He doesn't need to know OSD and read full texts of licenses as long as he uses most adopted like MTI, BSD, GPL. Descriptions of pros and cons of every one of them in layman terms are available on the internet. It's hard to say the same for the ill-conceived licenses you mentioned.
I can't sell some project based on Lerna to [list of companies] ? OK. How am I supposed to check that the company didn't change name? What if I am selling my work to subcontractor? I would probably have to include this list in every contract. What if every open-source project started banning some arbitrary list of companies? Am I supposed to review the last commit to license every time to make sure that my company wasn't included? All that looks, sounds and smells like a lot of headache and any reasonable person would drop the project with first sign of it.
Commons Clause was even worse. It was advertised as "MTI+CC", but nobody would be able to figure out what "CC" part meant for them without a lawyer. And any lawyer would advise to find something else.