(Replying to PARENT post)
(Replying to PARENT post)
For what it's worth, I think there's reasoning to consider it on a project-by-project basis. An example might be how XMPP more or less became a bunch of walled-garden forks for various messengers like Google Chat and Facebook. I think Linux thrived with the GPLv2's copyleft being a "sweet spot" for them.
(Replying to PARENT post)
I think you have a real product here and would caution you against releasing the source code.
If you do want to open source it, I highly recommend GPLv2 or 3.
(Replying to PARENT post)
No: it's their choice, and if they choose not to use GPL software it is evidence that they do not care about user and developer software freedom. And that they don't want to contribute back.
Also, "some major institutions" is very unclear. Google is ok with GPLv2 but not with GPLv3. Apple has restrictions on their app store.
Both companies are extremely unlikely to support decentralized communities anyways - they outright compete against them.
(Replying to PARENT post)
This is still possible with GPL (and the AGPL, for that matter) by granting an exemption to the license for third-party extension software that is in the form of a plugin using a specific API.
It is worth noting that depending on the details of your (and the plugin's) implementation, such an exemption may not even be required.
This is probably a good place to start digging in to the topic: https://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins
But before anyone starts down this rabbit hole (the legal, social, and technical details of which I personally find fascinating, but YMMV), a maintainer should instead think about the things they want to allow, the things they want to forbid, and the things they want to be able to charge for. Also, which of the aforementioned things they want to provide strong guarantees for in the event of a change in ownership and/or a fork (eg. MySQL/Oracle, OpenOffice/LibreOffice, etc.).
But whatever the preferences are for a particular project, there almost certainly is a way to set those boundaries using a FLOSS license, and it is probably possible while using the GPL (but if you're leaning toward 'allow individuals and mega corps to do whatever they want', there isn't much sense in using the GPL as a starting point), though it is possible you might need a few additional tools for some scenarios (requiring a Contributor License Agreement or even copyright assignment for contributions, license exemptions for specific APIs, splitting out some shared libraries and releasing those under a different-but-compatible license, dual licensing, separate licensing for non-code assets, a nonprofit foundation, compatibility testing and associated badging & trademarks, etc.).
Anyway, there are a lot of tools available, and most of them can be grabbed when and as they're needed, if they ever are.
So, start with what you want in terms of permissions and boundaries, then ask for advice on enabling/enforcing that structure with a FLOSS license, and it can probably be done without too much complexity (assuming that it isn't incompatible with FLOSS, like 'This software cannot be used by the military or to support the creation of WMDs').
(Replying to PARENT post)
I don't know of any copy left license that prevents you from making JSON API calls from any source you want, so you can integrate something like matrix easily enough.
(Replying to PARENT post)
Generally I think MIT is a good default and you should only use a different license if you have a strong case for why MIT doesn't make sense for your project.