One thing I mention to folks that seem to think AGPL "protects you" against a major corporation incorporating your product into a SaaS product: it mostly doesn't.
It isn't written about often, but it's the reason many "open core" companies moved away from AGPL to protect their revenue from larger SaaS/IaaS/PaaS players from eating their lunch.
Law does not run on a CPU with certainty. There is risk analysis going on: there are many jurisdictions at play. When you are big enough, something that has fundamentally viral characteristics by design can have catastrophic impact even if reading of the license as linked would be almost certainly accepted as correct and likely. Therefore, especially for a company like Google that has a unified codebase, that treatment is justified. So goes for other big companies who would be at least wary of just taking AGPL.
It kinda does have that effect, because large companies are allergic to AGPL by policy, even if they otherwise have processes to get GPL software into use. The very companies that have the pocketbook to pay for your software, are also structurally incapable of using it as FOSS. Smaller ones that are more agile about how they incorporate it, have less willingness to pay for a different license.
Sure, but there's a case I'm particularly aware of where one of the major cloud infrastructure providers was about to host a significant AGPL-licensed project without modifications because their lawyers had reviewed it and determined it would have been OK. The particular VC-backed open-core company then got word of it and changed their license off of AGPL. IYKYK
Every damn time. The debate used to be idea vs. implementation. Today, it's all about implementation vs. audience/distribution. You can have 50 different people sell the exact same thing with wildly different outcomes. You can get people to pay to dig a hole in the ground for no reason.
This is what Tailwind should’ve done. It’s a shame to see hard work contribute countless millions of dollars to publicly traded companies and highly capitalized startups, and OSS creators not getting their due.
Some things may be obvious to a lot of readers, but I want to spell things out explicitly because sometimes "OSS" etc have a lot of conflations.
A license in the software sense is effectively the legal terms and conditions for using the software in any way. A license can define anything your legal mind can dream up: "only usable when you wear a red shirt," "only usable on the third Tuesday of the month," etc. You can multi-license things: "License A is that you can only use this software when you wear a red shirt. License B is that you can only use it on the third Tuesday of the month. This software is dual licensed under A and B: you can choose which license you want to use, but you must use one of them if you want to use the software legally, because those are the legal conditions I've laid out in using the software." If you use the software on Wednesday wearing a blue shirt, you're operating it against the terms and effectively are in breach of the license. This is (part of) why putting source code out on the internet isn't the same as "open source" and why downloading and using source code you find without reviewing the actual license terms may end you up in hot water. It's why standardized licenses are so helpful to legal teams that review these sorts of things at corporations.
These are obviously facetious examples, but most for-profit entities might choose a dual licensing structure where "if you want to run it for free, you choose something in the realm of open source licenses and if you don't like the terms of those licenses, you pay us for a license that gives you something else." In cases like the blog author's here: you say "option A is AGPL" and "option B is you pay us for a license to remove AGPL and which gives you different rights." You hope enough companies are scared by AGPL to want to pay you for the non-AGPL version and the distribution/OSS-friendly nature of AGPL helps you build a user-base enough that by the time it gets to a legal team to approve/deny, that the legal team denies and is willing to pay to make the problem go away.
One thing I mention to folks that seem to think AGPL "protects you" against a major corporation incorporating your product into a SaaS product: it mostly doesn't.
It isn't written about often, but it's the reason many "open core" companies moved away from AGPL to protect their revenue from larger SaaS/IaaS/PaaS players from eating their lunch.
Some writings are:
- https://writing.kemitchell.com/2021/01/24/Reading-AGPL
- https://katedowninglaw.com/2019/09/08/the-great-open-source-...
- https://drewdevault.com/blog/Anti-AGPL-propaganda/
Law does not run on a CPU with certainty. There is risk analysis going on: there are many jurisdictions at play. When you are big enough, something that has fundamentally viral characteristics by design can have catastrophic impact even if reading of the license as linked would be almost certainly accepted as correct and likely. Therefore, especially for a company like Google that has a unified codebase, that treatment is justified. So goes for other big companies who would be at least wary of just taking AGPL.
It kinda does have that effect, because large companies are allergic to AGPL by policy, even if they otherwise have processes to get GPL software into use. The very companies that have the pocketbook to pay for your software, are also structurally incapable of using it as FOSS. Smaller ones that are more agile about how they incorporate it, have less willingness to pay for a different license.
Sure, but there's a case I'm particularly aware of where one of the major cloud infrastructure providers was about to host a significant AGPL-licensed project without modifications because their lawyers had reviewed it and determined it would have been OK. The particular VC-backed open-core company then got word of it and changed their license off of AGPL. IYKYK
> Full disclosure: I’m a co-founder of Kelviq.
So this is an ad. Fine, but that ought to have been disclosed at the beginning.
Not just an ad, but its pretty much content free.
It doesn't really explain anything about the business model other than talking about how dual licensing is a thing you can do.
Dual licensing isn't exactly some exciting new thing, Qt has been dual licensed since like 1998.
You probably made that money because you sell some other product on side and bundled the library license in.
Every damn time. The debate used to be idea vs. implementation. Today, it's all about implementation vs. audience/distribution. You can have 50 different people sell the exact same thing with wildly different outcomes. You can get people to pay to dig a hole in the ground for no reason.
This is what Tailwind should’ve done. It’s a shame to see hard work contribute countless millions of dollars to publicly traded companies and highly capitalized startups, and OSS creators not getting their due.
What’s dual licensing i’m kinda interested
Some things may be obvious to a lot of readers, but I want to spell things out explicitly because sometimes "OSS" etc have a lot of conflations.
A license in the software sense is effectively the legal terms and conditions for using the software in any way. A license can define anything your legal mind can dream up: "only usable when you wear a red shirt," "only usable on the third Tuesday of the month," etc. You can multi-license things: "License A is that you can only use this software when you wear a red shirt. License B is that you can only use it on the third Tuesday of the month. This software is dual licensed under A and B: you can choose which license you want to use, but you must use one of them if you want to use the software legally, because those are the legal conditions I've laid out in using the software." If you use the software on Wednesday wearing a blue shirt, you're operating it against the terms and effectively are in breach of the license. This is (part of) why putting source code out on the internet isn't the same as "open source" and why downloading and using source code you find without reviewing the actual license terms may end you up in hot water. It's why standardized licenses are so helpful to legal teams that review these sorts of things at corporations.
These are obviously facetious examples, but most for-profit entities might choose a dual licensing structure where "if you want to run it for free, you choose something in the realm of open source licenses and if you don't like the terms of those licenses, you pay us for a license that gives you something else." In cases like the blog author's here: you say "option A is AGPL" and "option B is you pay us for a license to remove AGPL and which gives you different rights." You hope enough companies are scared by AGPL to want to pay you for the non-AGPL version and the distribution/OSS-friendly nature of AGPL helps you build a user-base enough that by the time it gets to a legal team to approve/deny, that the legal team denies and is willing to pay to make the problem go away.
Thanks for sharing!
[dead]