People who use GPLv3 want the code to stay open/libre under any circumstances. If this is the goal, why not use the AGPL instead, even for applications which are not served over a network?
This takes away the possibility that people integrate parts of your program into a proprietary network application, even if this seems improbable. There’s nothing to loose with using this license, but potentially some gain.
Only reason I can think of is that AGPL is less known and trusted which may harm adoption.
Unless it’s open source and you have any contributions without a rug pull contributor agreement. Also you don’t have any AGPL dependencies.
We had that relicense convo with the desktop tool maker and they were hogtied by both. Corporate policy dudes had to be harassed into even looking into it. Then maybe 3 months of back and forth championed by motivated tool users later they said to hell with it and banned it.
So if you plan for the AGPL rug pull for your contributors or you have no contributors and none of your dependencies are AGPL in a viral way, go ahead.
Totally agree
Your contributors must attribute copyright or agree to any reason license if you choose this. (This seems so obvious to me that I didn’t mention it)
But it’s still strictly superior to MIT licensing, which has the same requirement (since that’s part of copyright law, not party is the license itself), while still preventing commercial adoption under a different license.
I think we’re in violent agreement. The problem is you need someone in licensing/legal to take a risk at this point to even use AGPL on a corp machine. Figure out the law and the license, then make judgement calls on some slightly fuzzy parts. They’re just not going to do it. Maybe in a few years if someone tests “the right” model, whatever that is in court and prevails. Meaning the dev gets paid and the user retains intellectual property that is either tangential to the product or provides enough value to be it’s own product that’s still sellable in the same way as before the suit.