It isn't an issue of "clean"; GPL/AGPL aren't "legally murky". (Though if a customer is willing to pay you because they think otherwise, by all means.) But if they're "rejected by customer legal teams", that's an opportunity to sell an alternative license or exception. I've collaborated with the legal teams at various companies that review both inbound and outbound FOSS. Inbound, there's no open legal question with GPL-family licenses; they're only "rejected" in cases where they're functioning as intended and that isn't desired. (That includes companies that systematically reject AGPL; they're concerned about the license working as intended.) Outbound, the pressure to not use GPL-family licenses when a choice is available doesn't come from the legal department; it comes from product teams who don't seriously consider copyleft and what benefit they might gain from using it, because all the other teams they see are using Apache or MIT or BSD. And then those same teams become shocked when their own code is used to compete with them.
There's a strong tendency towards "do what other people are doing", and there are a lot of companies releasing permissively licensed code. This seems self-defeating.
Yes and no. I'd agree that, in general, they're legally safe and clear, but when you're talking to the legal department of a company, it is not about whether they're clearly defined. The actual worry is whether a patent troll or a more litigious competitor can sue the s out of your company and extract millions upon millions of either legal costs or settlements. Yes, you _might_ win, but it will still cost you and courts are known to not always be deterministic in their decisions. So once your out of the "thrown out without a second thought"-cleanliness, corporate legal will not be happy.
Is there a reason that is more of a risk with GPL/AGPL than with other ("permissive") open source licenses though?
That's still not "legally murky"; that's the GPL working as designed. If the component has enough value, that's an opportunity to sell an alternate license.
Of course, if your primary value proposition is something other than the library (such as a paid service that the library helps programs integrate with), by all means use a permissive license.
The GPL is one of the cleanest licenses out there. Use the code in your project, give the source of your project to anyone you give the binaries to, job done.
Putting it on github (or a zip file on your website) is less of a hassle.
Their compiler was technically GPL, but they sold it for thousands of dollars to businesses, with the implied threat that they would let the phone ring for a while when a customer who distributed the sources had a problem.
Since their customers are using it for safety- and mission-critical software, noone would ever dare to cross them.
This is true if you use a CLA, but that's going to reduce external contributions. In some cases you may not care about that.
In particular Google's strong anti-AGPL stance has caused a chilling effect for adoption of AGPL projects at companies, hence why commercial licensing is frequently an option.
Finally, you can believe whatever you want, but ultimately it's the lawyers who decide, and your ass (assuming you're an IC) isn't the one on the line when shit hits the fan. Lawyers don't like GPLv3 and they don't like AGPL.
Whose lawyers? Why would the lawyers at your company object that your choice of license for the free software that you publish is the AGPL or the GPL?
Google's legal department is the problem: https://opensource.google/docs/using/agpl-policy/
There's likely nothing your sales or marketing team can when Google, and companies that cargo cult Google's legal, decide not to allow your product gain a foot in the door because of its license.
> In some cases, we may have alternative licenses available for AGPL licensed code.
Large companies pay, others don't need to.
I'd encourage you to read the GOLs and some of the legal commentary about them, if you haven't already. "Clean" is a value judgment, but as one who routinely handles both open source and commercial license agreements, I'd never refer to GPL as particularly "clean", and I doubt I have any colleagues who would.
The summary you give is not complete, overall. And it omits a lot of details that can prove important.
We abandoned GPL for the BSL for this reason. The GPL is in many ways better but there are a ton of companies that won’t touch it or anything that comes near it... though they tend to grandfather in Linux.
There are obviously lots of open source projects that find a way to navigate this world via dual licensing, and I’m neither a lawyer nor an expert on the subject, but those projects don’t really fit my own personal definition of “open” (as I derive it from the Unix philosophy instead of the GNU is Not Unix philosophy).
In a way, dual licensing is essentially proprietary software, with a for free version that you hope will satisfy as few users as possible. A bit like the old shareware days.
Dual licensing also creates the perverse incentive of trying to scare your potential customers how horrible copyleft licensing is. So if you motivation is to increase the amount of FOSS through copyleft licensing, you're shooting yourself in the foot.
See https://sfconservancy.org/blog/2020/jan/06/copyleft-equality...
If the license is straightforward enough, or comes from a neutral organization that publishes trustworthy lay summaries, as Creative Commons does, there's less room for sales incentives to run wild. The usual conflicts of interest in other business models, like holding back code or doc, making the software hard to use, and so on break down, because there's just one product. Customers pay to use the product.
No.
So there have been attempts to deal with this issue, but there's a lack of consensus on what the "right thing to do" is in such scenarios.