The future of F/OSS continues to be AGPL
Just came across this post by ParadeDB:
https://blog.paradedb.com/pages/agpl
Just taking time for a victory lap:
https://vadosware.io/post/the-future-of-free-and-open-source-is-agpl
https://blog.paradedb.com/pages/agpl
Just taking time for a victory lap:
https://vadosware.io/post/the-future-of-free-and-open-source-is-agpl
https://katedowninglaw.com/2019/09/08/the-great-open-source-...
as a really great read from a lawyer on the various factors and motivations, and which in particular touches on AGPLs lack of ability to protect what many of these companies are worried about most. Specifically:
> That understanding was the genesis for the GNU Affero General Public License 3 (AGPL 3) published in 2007: it was meant to solve for this exact problem by adding language to the GPL 3 which required companies to provide source code for software that users interacted with via a computer network if the software was modified AGPL 3 code (or a derivative work of such modified AGPL 3 code). But even the AGPL’s obligations can be avoided by simply not modifying the AGPL 3 code, which there is often no reason to do, or by building layers between the AGPL 3 code and proprietary code. That’s why a lot of these middleware companies didn’t choose to relicense to AGPL 3 and why MongoDB, who was already using AGPL 3, chose to revise the AGPL 3 to expand the circumstances under which services running on AGPL’ed code must open source the previously proprietary parts of those services.
The OP paradedb blog states for example:
> Future-Proof: Thanks to the copyleft provision, cloud vendors cannot easily resell our project without our consent. This gives us confidence in our ability to monetize without fear of predatory competition.
IANAL but my understanding of reading the various legal analyses of AGPL (which I've read several) is this part is not true: cloud vendors absolutely could resell their project without their consent, provided those cloud vendors don't modify the code. From an end user perspective and for an OSI OSS advocate those attributes are likely in your best short-term interest: they promote competition. But in the long-term, if the company launching an AGPL product believes it protects them from this, they're going to eventually find out what Mongo did: that it doesn't. And the result of that is that they'll either need to accept that there will be cloud vendors competing with them on the IP they created or relicense. Commercial interests/shareholders being as they are and many of these companies being VC-backed startups, the latter is frankly a more likely scenario.
The AGPL information page clearly states:
"if you run a modified program on a server and let other users communicate with it there, your server must also allow them to download the source code corresponding to the modified version running there."
I'm not the sharpest tool, but I interpret that as all about the code. The license is not a tool I can use to prevent competition.
I've led several product management teams in my career and many engineers, executives, and customers I've talked to have this impression that if they put some bit of software under AGPL, then its nature is such that it's super viral: that potentially the entire product would necessitate becoming AGPL if the AGPL code is used in any fashion in the product. This has been primarily perpetuated from Google's statement on it: https://opensource.google/documentation/reference/using/agpl... and engineers that now there's a lot of lore around AGPL generally causing so much fear in any of big-tech company potentially needing to open source their entire service that it's treated as "companies wouldn't dare include our AGPL software in a competitive offering because then they'd have to open source their entire hosting stack, and nobody is going to be willing to do that."
My understanding that I heard through the grapevine is that this fear was what MongoDB was relying on for so many years and they found out that one of the big tech companies was about to offer a competitive MongoDB-as-a-service, which caused them to make their shift away from AGPL. Other (mostly database) OSS vendors caught wind of it as well through their networks, and that's why various OSS database products didn't go to AGPL but instead to proprietary licenses.
It then becomes a game of can you design your software in such a way that it will never be possible for cloud vendors to host it without modification, for example by keeping some required features closed-source (say a control plane, etc.).
For now, we feel this is good-enough protection and we hope that by doing our work right, we can give as much as possible to the community while still keeping guarded just enough to prevent cloud vendors from eating our lunch.
I think what will really set this in people’s minds is when a company forks and maintains an AGPL clone.
AGPL only works right now because companies are supposedly scared of it (and have blanket policies) but it does not do what some often think it does, in actuality.
Desktop development in the past was locked by widget based GUIs and their limits, they are not classic editable DocUIs, modern WebUIs are the commercially needed answer since they are DocUIs BUT not under user control. Most modern devs simply use WebUIs, even locally, because they can't even imaging an editable DocUI. When some colleagues see rare presentations from me (I talk a lot, but hate slides) in Emacs/EXWM/org-mode/dslide can't even understand what their see. Live rendering of an active markup witch is indeed free form text eventually with executable code (elisp: links or C-x C-e full displayed sexps) is something they can barely understand, having the same language, functions available everywhere is totally alien for most.
Even if we have the code, if the coded software is something unsuitable for personal, SME usage being just a copy of some big tech walled garden, the code alone does not suffice. Having the entire Alphabet infra under AGPL does not fit much any FLOSS purpose. It just allow big tech interoperability witch is their biggest Achilles's heel since having no walled gardens, an OS as a single application in user programmable hands interconnected with other desktops as well, is the strongest FLOSS point no one company can aspire to match no matter their size.
FLOSS need a FLOSS IT paradigm BEFORE the code, we have more than enough code not to care about "OSS Enterprise" models, we miss instead the knowledgeable user base and desktop paradigm.
NotebookUI like Jupyter are modern limited and limiting versions.
I also want an AGPL-ish version of that. If I release a library, I don't need the source to your application that uses it, but I want to get access to modifications you may have made even if you're only using it in a cloud-computing service. I want an ALGPL!
For example, they wrote, "Thanks to the copyleft provision, cloud vendors cannot easily resell our project without our consent", which is nonsense. AGPL blocks proprietary modifications that Amazon tends to make, but it is entirely trivial to "resell their product" without their consent.