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.
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.
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.
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/
So this is an ad. Fine, but that ought to have been disclosed at the beginning.
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.
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.