I love single-license-per-project F/OSS companies like Red Hat, but they're rare. I'm attracted to companies who are so committed to F/OSS as a practice that their software is copyleft and they don't require a CLA.
But dual-licensing is a tried-and-true strategy and the basic premise is very clear and very fair: share your downstream changes or pay a fee. And a CLA is required to make that work.
Something commenters here seem to miss is that all permissively licensed software is vulnerable to the same kind of maneuver that copyleft+CLA software is. If MIT or Apache don't scare you, neither should GPL+CLA.
There are clear differences. [Let's say I am not a competitor and Amazonifying them] I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates. I cannot fork AGPL and use it commercially in any reasonable manner.
Even worse, let's say I am a paid customer for their support and run on their proprietary license. Once they rug pull or jack up the prices or whatever, I cannot fall back to AGPL hosted locally. If it were permissive I would have had other options.
AGPL I fully respect as Free Software. AGPL+CLA, however, is not your friend and is pure deception. If you are a sufficiently large commercial entity, you are probably wise to act as if it is proprietary. In fact, it might be slightly worse as folks are sometimes cavalier in accepting contributions without proper copyright license/assignment and they pass them on to you under their paid license and expose you to some risk.
> I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates.
Strictly speaking you are correct. I concede that from an individual licensee perspective. The scenario I had in my head is under permissive, if the community forks, they would be on par with the original author. Under AGPL+CLA, if the community forks, the original author can sell "usable" licenses but the fork community will be stuck to developing an AGPL-only solution, which is a practical hinderance for the new community gaining any ground at all.
> I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates. I cannot fork AGPL and use it commercially in any reasonable manner.
You can fork it and use it in and as free software forever. This is only 'unreasonable' if you're a proprietary software vendor. The complaint of a proprietary software vendor strikes me as somewhat ironic here: what, the same deal that you give to your own customers for your own product is one you simply 'can't' take yourself because it's not 'reasonable'?
> If you are a sufficiently large commercial entity, you are probably wise to act as if it is proprietary.
But right about this. In the scenario you describe, you're a customer under the proprietary license— the kind of dependency your proprietary software product has on the software is the same kind it might have on any other proprietary software. The AGPLv3 version is not a backup option for you.
And it's true that the dual-licensing game the original vendor has set up is one that only they will ever be allowed to play.
If my company were considering purchased dual-licensed AGPLv3 software, I'd give advice like the following:
> It's great for the wider public that there is an open-source version of this exact same software our there. But what we're considering buying here is not that— what we're considering buying is proprietary software. For us, all that the availability of that open-source license means is that this is proprietary software whose source code would be easy for us to inspect, and that upstream might even accept our patches for issues that we encounter. I think both of those things are huge advantages! But if this vendor gets bought out or shuttered, we could potentially be left in the lurch much as we would if the software were exclusively proprietary. That's often an acceptable risk, in my opinion, and it's certainly one that our company has deemed acceptable with many past and present proprietary software purchases. But we should note that on the assessment: if we buy this, we're not buying or depending on open-source software; we're buying and depending on proprietary software.
All that assuming, of course, that the proposition is to use the AGPLv3 software in a user-facing, proprierary web service under the assumption that the copyleft component of the AGPL extends to that web service. If we were evaluating it for use in an internal service, where the end users are our own employees, or an external-facing service that we'd be comfortable releasing under the GPL, or we think that the way we want to use it would not require any license changes for us even if we take thw AGPLv3 version, I'd instead say something like
> Ask the lawyers as always, but I don't foresee any problems. I think this is great and I'd love to use it. If our legal people aren't used to considering copyleft licenses, can we have them consult with the FSF or the SFC or the EFF or something before they make a decision about this? Is that a thing?
Anyway, I agree with you about how being the customer (under the proprietary license) of a company like this is different from being the customer (for support services only) of a company who publishes permissively-licensed free software. I don't agree, though, that the dual-licensing thing is a trick! I think it's totally possible for everyone to go into that kind of arrangement eyes open and be happy with it. I hope and expect that's the goal for companies like that of TFA.
> You can fork it and use it in and as free software forever. This is only 'unreasonable' if you're a proprietary software vendor. The complaint of a proprietary software vendor strikes me as somewhat ironic here: what, the same deal that you give to your own customers for your own product is one you simply 'can't' take yourself because it's not 'reasonable'?
I am not discussing ethics or morality here, just practicality, and yes, from the perspective of a user that is not primarily releasing open source. Note that it's somewhat different and more general than your characterization. I might be in another business, not software, but unwilling to touch AGPL within my infrastructure due to risk of virality. Strictly speaking, I am not a "proprietary software vendor" as I am not even in the software business, primarily. Nevertheless, your general point stands.
I am not arguing it is bad. Simply that I would not characterize AGPL+CLA as "no vendor lock-in because open source." I put it right in the bucket of e.g. Oracle proprietary database. I am not saying it is bad or totally unreasonable. I just don't buy up the marketing koolaid.
But dual-licensing is a tried-and-true strategy and the basic premise is very clear and very fair: share your downstream changes or pay a fee. And a CLA is required to make that work.
Something commenters here seem to miss is that all permissively licensed software is vulnerable to the same kind of maneuver that copyleft+CLA software is. If MIT or Apache don't scare you, neither should GPL+CLA.