My understanding is that it's not the dual-licensing per se that's toxic, but the goal of copyleft-noncompliance legal actions. Rather than, as the FSF and SFC seek: "Our primary goal in GPL enforcement is to bring about GPL compliance." (https://sfconservancy.org/copyleft-compliance/principles.htm...) The businesses of which Kuhn is critical seek instead "to 'convert' those FOSS users into paying customers for proprietary licensing for the same codebase."
Arguably, the failure here might be of the GPL failing to specify what is an acceptable remedy, though if that were defanged to only be "release affected code as <copyleft license>", it might afford too great a latitude to other forms of black-hat actors.
I'm not sure if I agree with Kuhn's assessments or remedies. I think the discussion's worth having, and appreciate your input.
RMS discusses this here:
https://www.gnu.org/philosophy/selling-exceptions.html
"I consider selling exceptions an acceptable thing for a company to do, and I will suggest it where appropriate as a way to get programs freed."
https://writing.kemitchell.com/series/SSPL.html
Kyle is a advocate of dual licensing ("selling exceptions") and has even created License Zero [1] which is attempting to allow the creation of npm libraries which are dual licensed and an automatic command line tool to pay developers.
[1]: https://licensezero.com/ see also https://writing.kemitchell.com/2017/09/12/The-License-Zero-M...
This is still coercive though. It is the big party using their power to get developers to give up their rights.
Notably, by giving up these rights, it becomes possible for the party to go against the FOSS principles that were the reason copy-left was invented.
Sometimes that big party is a single developer, or just a small group. They invest several years into developing a working product, unpaid, and then give it away, with the condition that anybody who wants to use it in a proprietary product must pay up.
Not all CLAs require a developer to "give up their rights." The code authors can retain their copyright, but sign an irrevocable contract which allows for the distributor to re-license their work as they see fit. The original author too, is still able to license it as they see fit.
If, on the other hand, the developers only release their work as AGPL with no separate licensing, all they are doing is ensuring that a subset of companies who might otherwise use their software, definitely wont. There are many companies who simply can't AGPL their own works and if they can't use your software, they'll find an alternative, or develop and alternative in house.
I'm certainly against the idea of coercing companies to pay for licenses by instilling fear, but I think it's only a subset of dual licensing companies which do this. A dual licensing approach isn't inherently coercive. If they're clear about their licensing model up-front then it shouldn't be an issue.
Also consider that at any point, you can take one of these AGPL dual licensed products, fork it, and not sign over any CLA, then you can distribute a fully copy-left variant of it with some additions of your own. You would question why wouldn't everyone contribute to your version rather than the one where they hand over the copyright of their modifications. There's an obvious reason this rarely happens: The bulk of the work and maintenance is being done by the company collecting the license fees, and community contributions are just a small percent. There are cases where the community version gets enough development effort to be able to spin off a successful fork - eg, MariaDB.
"This problem became clear to me in mid-2003 when MySQL AB attempted to hire me as a consultant. I was financially in need of supplementary income so I seriously considered taking the work, but the initial conference call felt surreal and convinced me that MySQL AB was engaging in problematic behavior . Specifically, their goal was to develop scare tactics regarding the GPLv2."
CLAs are frequently coercive, rights depriving and generally a bad move, and I as a FOSS contributor won't sign them.
Yes, occasionally they are used correctly - but more often than not they're used to crowdsource work on what is really a proprietary codebase with crazy potential restrictions if the owning company decides to call them in.
To me the GPL is clear: You can USE the software for anything, but you have legal responsibilities if you redistribute it.
The dual license scheme seems like a good way of letting people buy their way out of the responsibility part, and generating revenue to help maintain the software.
At the heart of Kuhn's argument about "seediness" seems to be CLAs, which is where a third-party developer using software under FOSS terms is asked to sign the rights to their modifications over to the original vendor. If CLAs were coercive, this would indeed be seedy: FOSS developers would be getting baited into contributing to commercial products. But CLAs aren't coercive; the AGPL requires only that you meet the requirements of the license itself, not that you sign away your rights to your own modifications. People sign CLAs because they want their modifications upstreamed, and to avoid maintaining forks, not because they're legally required to do so.
Meanwhile, the kinds of software we talk about when we talk about the AGPL are overwhelmingly things that used to be (and in some cases in large part still are) closed source proprietary products. It's a little hard to imagine a closed source distributed database taking off in 2020; 20-30 years ago, to use Kuhn's framing, the opposite statement would have been more valid.
Fundamentally, software offered under the AGPL is almost always developed under the model of a single commercial vendor doing most of the heavy lifting, and, usually, all of the initial lift in getting a piece of software to the point of viability. It's hard to see how these vendors are taking something from the community by releasing their products under the AGPL when their alternatives would certainly be either a fully closed-source proprietary release, or no release at all. Kuhn writes as if licensing and advocacy decisions determine the economics of software development, but if the last 30 years has been an experiment conclusively demonstrating anything, it's that --- at least for the kinds of serverside code we're talking about --- no matter how you license it, companies paying software developers are what gets software built.
I have strong opinions only about the AGPL; I don't pretend to fully understand the ramifications of MongoDB's SS GPL, nor do I support the SS GPL unreservedly.