you'll be surprised that, because copyright doesn't reserve the right to run programs exclusively to the copyright holder, copyright licensing (= granting permissions) cannot withhold or delimit that right. there are some clueless license writers fooling themselves and others purporting to have copyleft-like licenses that do this, but all this shows is that they understand neither copyright nor copyleft

the other fundamental problem is that the entire notion of software freedom is that the developers/authors/copyright holders should not have power over users. controlling others through the software they use, even if for a good cause, amounts to unjust power, and such power shouldn't be available. (it also divides the community on what should be ruled out, which is a great way to weaken a social movement)

now, I understand and share the wish to promote socially just causes, and to stop injustice. the way to achieve justice is not to take it on your own hands, imposing your wish onto others by whatever means you can manage. that leads to absolute rule by the most powerful, and I'm sure you're not going to enjoy that. the way to promote social change and achieve justice is by democratically instituted and enforced prohibitions of antisocial unjust behaviors

@zkat what if the control poin is not in the license but in the access? Access to OSS source code can be restricted. The 4 freedom are about what you can do once you get the code, they don't grant you a blanket right to access the code. I would be happy to contribute to code that restricts access to individuals or companies that subscribe to some standards. The 4 freedom could still be valid, but within the boundaries of a community with shared values. Losing access to the community means you lose access to future code changes. Not just not opening issues/prs. The cost in this regard is forcing a hard fork, which is way more expensive than a shallow fork with minimal patches. There are discoverability trade offs and tooling trade offs. But I see some benefits and there would be way less confusion than with licensing.

@zkat I've long felt that, just like we have a plethora of standard licenses to pick from, we should also have more named and documented governance models, because these two are separate dimensions that tell you something about the "openness" of a project.

You can be closed source but with community (led or involved) governance, you can be (corporate) open source without any community involvement at all, and many shades between. This wouldn't be captured in the license, but in some kind of governance contract with the community.

"MIT/BSD poison"?

I think we have radically different world views.

Good luck with that.

@zkat It may be adjacent to your core thinking here, but I wrote about "ethical licensing", and the FOSS licensing ecosystem, a year or so ago, after getting a few questons about them:

https://decoded.legal/blog/2024/02/an_introduction_to_ethical_licensing/

With apologies if this isn't quite on point.