> If you go with copy-left you automatically disqualify some major institutions from using your software. Especially for a community based project, there may be institutions that want to make proprietary extensions so it can integrate better with their existing infrastructure.
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.
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').
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').