I always interpret new licenses through the lens of Debian's Free Software Guidelines.[0] I don't think this would be accepted as it limits usage.

Besides that, the definition of a "small business" is terrible. A company is only eligible to use the software if they meet all of these conditions:

- had fewer than 100 total individuals working as employees and independent contractors at all times during the last tax year

- earned less than 1,000,000 USD (2019) total revenue in the last tax year

- received less than 1,000,000 USD (2019) total debt, equity, and other investment in the last five tax years, counting investment in predecessor companies that reorganized into, merged with, or spun out your company

1M USD in revenue is shockingly easy to cross. It also means that businesses in high cost of living areas will be excluded before ones in cheaper areas, even if they're otherwise identical.

It's an interesting idea, but I think it's a non-starter.

[0] https://people.debian.org/~bap/dfsg-faq.html

I think we need to be much more willing to consider software that's released with source available, but under a license that doesn't comply with the DFSG. (And yes, such software should be called something other than "open source".) Those guidelines aren't sacred, and neither is Stallman's definition of free software.

Ever since I read _Hackers_ by Steven Levy a few years ago, I've been much less sympathetic toward Stallman, and the MIT AI Lab hackers in general. If you've read _Hackers_, recall that Stallman also strenuously opposed passwords. Well, it's absolutely clear now that restricting access to computers with passwords (or something equivalent) is absolutely necessary to defend against bad actors. So we should be open to the possibility that, while widespread sharing of source code is good, some kind of restriction on the usage of that code is necessary to protect the developers from freeloaders. I'm sure we haven't arrived at the best way to do this yet, but we won't get there if we immediately reject all attempts because they don't meet a definition of freedom that's perhaps too absolute for the real world.

> I think we need to be much more willing to consider software that's released with source available, but under a license that doesn't comply with the DFSG.

Hard no. https://en.wikipedia.org/wiki/Focal_point_(game_theory)

Once that line is relaxed, even slightly, more licenses like this will start showing up and running battering rams against all the other parts of that line that prove inconvenient compared to proprietary licenses.

This license is proprietary. I don't care if there's source or not, it's still proprietary. It does not serve the interests of Open Source to compromise on its nature to obtain somewhat more quantity of a far lesser thing.

The unusual foibles and preferences of specific people who are firmly in the history of FOSS are not relevant factors here. The relevant factor is drawing and maintaining a strict definitional line, because if we let that line become even slightly porous, it won't hold up to the resulting assault that would invite.

> some kind of restriction on the usage of that code is necessary to protect the developers from freeloaders

Absolutely. For instance, requirements that others share changes they make under the same license.

There's been a massive push in recent decades towards permissive licenses, driven in large part by a combination of companies who find permissive licensing convenient and individual developers who project a certain counter-counterculture "do whatever you want, I don't want to think about licenses". We're now seeing the net result of that: many large companies actually using those permissive licenses as written, and not necessarily the ethos behind them.

> https://en.wikipedia.org/wiki/Focal_point_(game_theory)

If I understand the synopsis of that article correctly, I don't think that concept applies here. Unless I've got my history wrong, our dominant standard for what's considered free software or open source, the Debian Free Software Guidelines (later repackaged as the Open Source Definition, wasn't the result of some kind of broad consensus among developers, users, and/or distributors. As badsectoracula pointed out [1] [2], source-available licenses with restrictions used to be more common. But Debian was always strongly aligned with the FSF's ideology; if I'm not mistaken, it was originally funded by the FSF, and of course, the full name of the main Debian distro is Debian GNU/Linux.

> The unusual foibles and preferences of specific people who are firmly in the history of FOSS are not relevant factors here. The relevant factor is drawing and maintaining a strict definitional line

My point is that this strict definition reflects nothing more than the MIT AI Lab hackers' elevation of their freedom (even at the expense of others, as in chapter 5 of _Hackers_) to an ethical absolute. Of course, most of those hackers outgrew that, but Stallman didn't, and he successfully spread the idea that all generally useful technical information, including software, should be freely available. And, if I'm not mistaken, that's where the DFSG came from. Since I didn't spell out part of my logic in my original comment, I will here: given that his nearly-forgotten campaign against passwords was obviously hopelessly naive, we should be open to the possibility that the same holds for the idea that software should be free for everyone to use.

> There's been a massive push in recent decades towards permissive licenses

Fair point. And I admit that this has made me stop and think about my choice of license for my own primary open-source project, AccessKit [3]. I was quick to permissively license that project from the beginning, before I considered funding. As it turned out, most of my development on that project so far has been funded by Google, which also specifically requested the Apache license (I went with the Apache/MIT dual license common in the Rust world). But in any case, I think a permissive license is actually the best choice for my goal with this project, which is to encourage and help developers to make as many GUI applications as possible accessible to disabled users. So yes, I want frictionless adoption above all else, but I think it's for a good reason. If a massive company used my project without paying me, I think I would consider it a net positive, because at least more applications would be accessible. But then, it's possible that by choosing a permissive license, I'm further poisoning the well, because I'm making more software available to freeloaders who would otherwise be obligated to pay someone (not necessarily me). FWIW, I'm thinking about developing an AccessKit-based module that has more of a niche use case (a screen reader for platforms or embedded devices that don't already have accessibility support), and for that, I might go with a dual copyleft/commercial licensing scheme.

[1]: https://news.ycombinator.com/item?id=29928956

[2]: https://news.ycombinator.com/item?id=29928945

[3]: https://github.com/AccessKit/accesskit