There are alternatives. We can dual license software under a strong copyleft and a proprietary license, so that users (developers) who don't want their derived software to be copyleft can pay the proprietary license fee. IMO this is the approach that everyone should be taking - it rewards the developer rather than them subsidizing your derived works with their free time.
Obviously this has constraints. The developer must have full rights or ownership to redistribute the work under other licenses. This can be obtained from contributors via agreement, where every developer retains ownership of code they write, but grants permission to relicense it for the benefit the project. Ideally, contributors would also be rewarded for their time via bounty systems, contracts or direct employment.
It's possible to make non-derived works which utilize copyleft software. The license's conditions apply only to the derived works, and not directly to your code unless it unquestionably a derived work such as a fork. If your application is written in a way that it can function without dependency on a copyleft software, but can be augmented using copyleft software using a plugin system, then you're able to distribute your software under any license you chose, and only the plugin which uses the copyleft software would be required to be licensed under a compatible license. The "aggregate" would need to be distributed under the copyleft license - but there are also ways around that - simply distribute your software without the dependency on the copyleft work, and have it optionally download the copyleft plugins separately so that they're not part of the "aggregate".
Permissive licensing won't sustain itself unless the developers who depend on it start donating to the maintainers of the permissively licensed works they depend on. In some cases this happens, but mostly it's just the case that you can make money using software other people have given away and continue to maintain for free. What happens if they decide to stop maintaining it? Is your product still viable if you have to take over the task, or employ someone new to maintain it? Would it be viable if you, or your users, had to purchase a proprietary license fee for an alternative dependency?
You need to read the GPL licenses more carefully. Your code gets infected by GPL when you link. The principle difference between GPL 2 and GPL 3 being that the definition of "link" is much more expansive GPL 3. So separately downloaded packages don't really cut it unless the packages in question are LGPL-licensd (GPL with a link exception).
GPL 2.0 and GPL 3.0 (to a much more significant extent) disallow use of plugins. Or well, the do allow plugins, but at the cost of infecting the entirety of your own codebase with GPL 3.0 obligations.
And that's my principle objection to GPL. Linking to GPL code infects my code, requiring me to also license my code via a GPL license.
Permissive license stand a better chance of getting funding because they allow commercial users to use your software, and commercial users are more likely to give sustaining grants to projects they depend on than mere-ordinary users.
The GPL doesn't "infect" any code. You can write code which clearly calls GPL licensed code and license it under a MIT license.
The GPL comes into play when you distribute. If you distribute your MIT licensed code alongside the GPL licensed code, then the aggregate must necessarily be GPL licensed. This doesn't mean your code suddenly becomes GPL code and cannot continue to be licensed under MIT when not distributed as an aggregate. It is perfectly reasonable for someone to take the code, strip out the GPL licensed parts and replace them with MIT licensed alternatives, and license the whole thing as MIT.
Obviously for proprietary software this implies the aggregate must have its source code available in a GPL-compatible form.
But the point here is that you're separating the GPL work from your own code by means of a plugin system. If a plugin depends on GPL code, then the plugin itself must be distributed as GPL - but this does not infect the host program which loads the plugin.
That is, unless it can be reasonably argued that the host program is a derived work of the GPL licensed work. If the program basically does not function without dependency on the GPL licensed work then this might be a reasonable argument - but if the program runs fine, and is only augmented by a GPL licensed plugin, then it is not a derived work.
> GPL 2.0 and GPL 3.0 (to a much more significant extent) disallow use of plugins. Or well, the do allow plugins, but at the cost of infecting the entirety of your own codebase with GPL 3.0 obligations.
> And that's my principle objection to GPL. Linking to GPL code infects my code, requiring me to also license my code via a GPL license.
No. You release a host application with no dependence on GPL code.
The end user loads a plugin that is (or uses) GPL code. The end user doesn't distribute anything.
In very practical terms, what is the enforcement here? Who is gonna sue the end user?
As a developer, my primary concern is what the GPL says about what I as a developer must do. What it requires users to do is an entirely secondary question.
The Free Software Foundation is typically who sues you (or provides legal assistance to 1st parties who wish to enforce their GPL license). They can, and do sue people. And have sued people. And seem to make a fairly reasonable income from suing people.
As in all matters relating to intellectual property, things only become interesting once you have earned enough money to pay. So weekend warriors aren't going to get sued. But anyone who runs a commercially successful company (or plans to) becomes a target. And given that the Free Software Foundation is notoriously litigious, and notoriously unwilling to settle for anything less than complete submission, and a substantial cash payment, this is not a theoretical issue. And as with all matters relating to Intellectual Property, the cost of litigating even the most basic of questions is enormously expensive (some significant fraction of $1m for each party, not including costs for appeals). So it probably doesn't even matter what the GPL actually says.
One of the most significant problems with the GPL licenses is that they are extremely difficult to interpret. A corporate lawyer who reviewed a GPL license for me said: the first mistake in the GPL is on the first line. (Legal contracts cannot be copyrighted). And things rapidly go downhill from there.
Consider my application, in the context of GPL 3. It loads lv2 plugins, using a permissively licensed library. The majority of lv2 plugins are GPL-3 licensed.
According to GPL-3, you incur GPL-3 obligations when you link to GPL-3 code. The GPL-3 license goes to great lengths to explain what "link" means, and defines "linking" in very broad terms. It does grant exceptions for plugins that are loaded through "system apis" (but fails to define what a system api is). And in practice, Linux system APIs are covered by an exception in the Linux GPL license. So in actual practice, there is no exception for plugins. Is the LV2 plugin api a system api? It is not. It does not come pre-installed as part of most distros, and it is not part of the Linux kernel APIs. So the "plugin" exception is purely fantastical. It does not exist.
The GPL-3 also fails to define WHEN linking must occur in order to incur GPL-3 obligations. So. I as a developer, download and install an LV2 plugin. I use my program to load the plugin, while doing testing. Have I "linked", thereby infecting my entire codebase with GPL once I publish it (the 2nd condition required to incur GPL obligations)? I would fantastically hope not, but there is a very plausible interpretation of the GPL-3 text that says I have. It's easy for you as user to say that I have not. But the actual text of the GPL is unclear. And as a developer who writes code for a living, I have a professional responsibility to consider such questions.
You have to make a careful distinction between what one would like a reasonable license to do, and what the GPL actually does. And given that the GPL is extraordinarily poorly written, exceedingly difficult to interpret(according corporate lawyers I have asked to review it), largely untested in American courts (which are no longer entirely dependable these days, anyway), and increasingly aggressive about what "linking" means, this is a problem. Is the GPL a "reasonable" license that places only sensible restrictions on developers? Not at all clear. There's a long list of fantasy clauses one might imagine the GPL should have -- most of which it does not.
And it's also a big problem that the intent of the GPL is clearly stated: to infect as much software as possible with GPL obligations.
Your logic seems to assume that there two disjoint groups of people:
1. Developers who work on the open source project
2. Developers who work on proprietary software based on the open source project
In reality these groups overlap. Developers contribute to the open source project, and they also work on their own software based on the open source project. If you look at the git logs of successful permissive open source projects, you'll see that a lot of the development time comes from developers who work for proprietary software companies.
That's true for some projects, but there are others who have a sole maintainer, receiving no other contributions or donations, who are expected to continue maintaining the work for free.
Obviously this has constraints. The developer must have full rights or ownership to redistribute the work under other licenses. This can be obtained from contributors via agreement, where every developer retains ownership of code they write, but grants permission to relicense it for the benefit the project. Ideally, contributors would also be rewarded for their time via bounty systems, contracts or direct employment.
It's possible to make non-derived works which utilize copyleft software. The license's conditions apply only to the derived works, and not directly to your code unless it unquestionably a derived work such as a fork. If your application is written in a way that it can function without dependency on a copyleft software, but can be augmented using copyleft software using a plugin system, then you're able to distribute your software under any license you chose, and only the plugin which uses the copyleft software would be required to be licensed under a compatible license. The "aggregate" would need to be distributed under the copyleft license - but there are also ways around that - simply distribute your software without the dependency on the copyleft work, and have it optionally download the copyleft plugins separately so that they're not part of the "aggregate".
Permissive licensing won't sustain itself unless the developers who depend on it start donating to the maintainers of the permissively licensed works they depend on. In some cases this happens, but mostly it's just the case that you can make money using software other people have given away and continue to maintain for free. What happens if they decide to stop maintaining it? Is your product still viable if you have to take over the task, or employ someone new to maintain it? Would it be viable if you, or your users, had to purchase a proprietary license fee for an alternative dependency?