[kemitchell]

> All they know about open source is based on this definition.

The Open Source Definition says nothing about source control, patch submission, bug tracking, releases, versioning, dependencies, package repositories, continuous integration, test coverage, style guides, codes of conduct, and so on. There are also articles on the Internet that talk about a "post-Open Source" GitHub generation, and articles that affirmatively reject definitions of open source in terms of license conditions, rather than community. OSI has been controversial since inception, and there's plenty about that, too.

If the OSD were merely a descriptive framework, that would be one thing. "Here is a class of licenses we can describe, and here are benefits we can correlate with them." But OSD gets used far beyond that. It's used prescriptively. It's used to sanction. Those are social functions of a movement, and the crux of a movement is participation, not definition. It matters that people making open source haven't heard of OSD, because they neither participated in its adoption nor consented to its authority. It has no sway over them. The idea that a mailing list could define their community rankles.

I don't consider debate about OSD, DFSG, or "What is free software?" bullying. I do consider peer pressure on maintainers to adopt terms that don't advance their goals, against their stated interests, bullying. I consider unfounded legal FUD to the same effect bullying. Have a look at the Lerna GitHub issues, or Twitter conversation about Commons Clause.

[HumanHater]

> 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.

[kemitchell]

> 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:

https://writing.kemitchell.com/2016/09/21/MIT-License-Line-b...

I've also summarized the License Zero public licenses:

https://guide.licensezero.com/#public-licenses

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.