Why we picked AGPL
blog.paradedb.com
blog.paradedb.com
For academic use AGPL compliance is a natural part of life anyway, for non-profits it's a little bit of effort but there's no fundamental objection, and when companies get involved it ensures that either my collaborators and I get a payout for SaaS-ification/proprietarization, or that it only gets used in internal tooling, which means that money gets redistributed to labor (often also to us via consulting fees or custom development arrangements anyway, since we know the code best).
It's a model for software development that I can really get behind.
Best of luck to you!
> Grant of Copyright License. Subject to the terms and conditions of this Agreement, You hereby grant to the Company and to recipients of software distributed by the Company a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
If you are happy to contribute code and then have them take it and sell it under a closed source license; or at a later stage just decide to relicense the whole thing as closed source; go for it. But most external contributors probably wouldn't like this.
Usually the effect that this has is that the OSS contributor community is pretty much exclusively employees of the company involved. I can't imagine third party companies agreeing on working on this or paying their people to work on this. Why would they?
Isn't this a core feature of the "unrestrictive" licenses you're a fan of? If you don't like freeloaders, BSD-/MIT-style licenses are even worse because they allow anyone, not just the maintainers, to sell your contributions in a closed-source product.
But there simply has to be control and restrictions over the use of software for it to be commercially viable (in almost every case).
> But there simply has to be control and restrictions over the use of software for it to be commercially viable (in almost every case).
That's the view of a single company that wants exclusive control, not the view of a company that wants to create a healthy OSS community. Healthy OSS communities tend to have more than one company involved and a diverse group of contributors. That's why OSS licenses exist that protect their mutual rights. It's a necessary compromise to prevent any contributor having that kind of power and allow them to collaborate and share code. This is the opposite; and it cannot create a healthy OSS community.
Which raises the question of what the point is of using this kind of licensing? I don't think it's about soliciting outside contributions as this kind of actively discourages that. And why else would you open source something?
It's nice to know when you're building something on top of other tech that if you need to, you can dig in to the code and fix issues. If the company folds, and you rely on their tech, you can continue to maintain it. If you want to look at their code to see how something works, you can do that. If you want to hire somebody to do a security audit on it, you can do that. If you're picking software to build with, having the source code be open or available is a positive.
And there's no downside to companies doing this. I see this happening frequently: people getting upset at companies that do some kind of sort-of-open-source/source-available thing, because they think the company is just out to get their free labor. If you don't want to give them free labor, then don't.
And besides, they are using AGPL! OSI-approved! What more can you ask for? That the company either dissolve completely, so that their software may become a garden on their grave, tended to by a community of free engineers, or else must remain cloistered and strictly closed? You don't need to celebrate it, but I just don't see the point in pooh-poohing this.
True. But not all software has to be commercially viable, arguably the most useful/critical and yet valuable isn't - currently my list is Linux, git, Postgres, Python, dozens of Python libs (perhaps thousands, if I go down the dependency trees).
Declaring my biases: I'm partial to GPL licenses and believe providing value to users is more important than making life easier/profitable to developers. IMO, the difference between GPL-style and BSD-style licenses is not being "restrictive" or not, but who gets restrictions (end users and developers being on opposing ends).
Those projects aren't inherently commercial, and great software can be built by passionate hobbyists, but often times the two go hand-in-hand
Open source does not necessarily mean open contribution. It may turn you off, but the tradeoff is that you can make the changes you need and run for your purposes. If your purposes is to make closed source software with it, you will need to pay for that privilege.
win-win!
> If you are happy to contribute code and then have them take it and sell it under a closed source license; or at a later stage just decide to relicense the whole thing as closed source; go for it. But most external contributors probably wouldn't like this.
bsd and mit licenses also allow this without a cla (that's the whole reason for using them instead of a strong copyleft like the gpl) and they seem to be very popular
Do you have any insight on this?
This I understand. But it doesn't really address Martin's worry about an accidental modification. Or apparent confusion about what constitutes modification.
> Not true. There is no need to accept the license if you exercise only your statutory rights, which in many jurisdictions includes the right to run the program and to patch it if necessary (e.g., for compatibility with other programs).
They need to pick a license which is salty enough so that big corporations cannot use it, but have to buy a special license from the authors.
Meanwhile they can support and benefit from the open source community without bureaucracy, and get a maximal userbase to create content on the web about this stack, and have a maximal number of people who know this stack and want to use it.
AGPL is perfect for this.
https://www.gnu.org/philosophy/selling-exceptions.html
People have pointed out to me that the above is not quite the same as what happens today with people building proprietary SaaS platforms. So I emailed Stallman to ask about the ethics of it. This was his reply:
> It is my understanding that as the copyright holders
> they have the right to do it without any problems.
> They leverage the AGPLv3 to make it harder for their
> competitors to use the code to compete against them.
I see what you mean. The original developer can engage
in a practice that blocks coopertation.
By contrast, using some other license, such as the ordinary GPL,
would permitt ANY user of the program to engage in that practice.
In a perverse sense that could seem more fair, but I think it is
also more harmful.
On balance, using the AGPL is better.But apparently it’s also used as a filter of who can interact and benefit from it.
But I don’t really understand all of it.
One thing I always wondered about selling separate licenses alongside GPL:
Can the authors (holding the copyright) distribute code under a different license when there were external contributors under GPL?
No, if any contributions were made under the GPL, they'd have to get permission to change the license to AGPL from every contributor or remove their contributions.
Most projects like this require you license your contributions in a way that lets them sell non-AGPL licenses (see their Contributor License Agreement) https://cla-assistant.io/paradedb/paradedb
So basically they can do whatever they want with your contributions.
However, this is typically solved by using a contributor licence agreement (CLA) where all contributors click through a form before submitting a PR where they declare that they own the copyright for the PR and they give a license for the organization to relicense the work and derivatives. Sometimes the whole copyright is transferred to the organization in these agreements.
I didn't check but according to some comments here the CLA in this case is already embedded into the AGPL license.
In principle this scheme guarantees that the original organization always has special rights over all of the open source community, as they can dual license all the derivative works.
This might be a viable licensing scheme for Swiss government contractors now. The federal government requires open source licenses for all software projects as of last year or so.
(A)GPL+CLA might be a good way to ensure the interests of the both the Swiss people and the flexibility or competitiveness of contractors, allowing them to retain proprietary licenses where needed or wanted.
Follow up:
Am I correct in thinking that this might slightly hinder contributions on one hand, but ultimately anyone could still maintain an _independent_ fork?
Or in other words: Would contributions to a fork still require signing the CLA and essentially allow the original authors to dual license any such contributions?
Apple for instance forbade GPLv3 because the anti-Novell clauses, which could be interpreted as "with a lost patent lawsuit, you can't merely license the technology but must secure and license the technology for all parties who may use or create a derivative of the original GPLv3 work". If you thought a court would agree with this interpretation, you'd be crazy to touch the software.
AGPL takes the strictest interpretation of a derivative work that even content created using the AGPLed software internally for an administrative function (such as storing your business data in a database) is a derivative work, and that the output of your software thus has restrictions under it by AGPL. Before AGPL, the only times we would see statements as such was to assure businesses that such an interpretation would not be taken - standard C libraries, compiled output, and java code with classpath exceptions are three popular examples.
I find the AGPL to run counter to the original purpose of the GPL, which I understand to be to protect the communities developing software from having their work superseded by commercial entities not giving back. The lack of examples of AGPL projects where contributors are not required to execute some form of CLA illustrates how it is often not being embraced to foster communities, but to protect against them and even exploit them.
What me and I guess many others wanted was a simple yes/no to the following: if I use Minio in my stack without modifications (as a file server that my other services interact with via an API), do I have to AGPL all the stuff the touches Minio or not? And they do not want to answer this question. I do not understand why is it so hard to answer clearly. I understand that the majority of opinions is that it's fine to use without modifications, but I wanted a clear statement from authors of Minio. Failing that, I then decided to keep the pre-AGPL version for a while and have transitioned away from Minio since then.
The same questions has been asked about how many seconds of TV/radio is fair to copy, for example as stock footage or in reviews. Many people will say something like "3-5 seconds generally accepted", but each creator has to apply their own judgement per case.
What is a derivative work is one of the most debated aspect of copyright law, likely only second to fair use debates. Only a court of law has any real ability to give a clear answer and then only to a specific case.
"This License explicitly affirms your unlimited permission to run the unmodified Program."
In the Basic permissions of the actual content of the license https://github.com/minio/minio/blob/master/LICENSE
It's not that difficult to parse if you actually read it top to bottom instead of skimming.
The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work.
A "covered work" means either the unmodified Program or a work based on the Program.
Fyi... a few Google employees talked about similar ambiguous interpretations of AGPL's terms and clauses by Google's legal team review in a past thread: https://news.ycombinator.com/item?id=23966778
> Perhaps if random engineers stopped calling legal opinion FUD and falsehoods and took a moment to listen to the feedback from lawyers who didn’t write the license, we’d get somewhere with finding a palatable license for all parties. Instead, we get a holy war.
My corollary: an argument is not a document. When I need a strong resolution on an issue, I want in writing and in a single organized voice, not spread across a bunch of comments and commenters, whose goal is often to shout down doubts or to keep the peace between participants.
Besides the internet, I've seen "the-argument-is-the-document" occasionally inside companies and very strongly in a hype-driven programming language.
if someone said 'no, the output from my gpl-licensed compiler is never covered by the gpl', then would-be infringers would have an easy escape from the gpl: just compile the compiler with itself, and its author guarantees that the compiled output isn't covered by the gpl! so that's why the fsf carefully says 'only if the output, given its content, constitutes a covered work'
similarly, emacs or gforth has the ability to dump a memory image after loading up a bunch of source code and compiling it to bytecode; that way it can instantly load the image without taking the time to recompile all that code. this memory image includes all the code that's loaded, including not just your code, but also all the standard library code that comes with the system. but that shouldn't give would-be infringers an easy escape from the gpl for the standard library code
I still don't think it's that confusing. Unlimited running of it is already covered without exception. The next line only refers to the output of the covered work.
If the output of your web server is redistributing minio then you are under AGPL
For a library I'd say that was a definite yes. For a service it is someone's less clear, some provide connective tissue (language bindings or other access modules) under less strict licenses which creates an obvious break in the chain, without that or very definite answers to the question on the post you replied to it is unclear how tightly coupled you need to be to need to use AGPL for your own work and I would err on the side of assuming (because it is GPL based) any coupling would have that effect.
Not that this would put me off using LGPL, but it is just as disconcerting, if not more so, to commercial interests, as the GPL is.
https://github.com/torvalds/linux/blob/master/LICENSES/excep...
[EDIT: after reading the information in the link provided by actionfromafar, I'm pull that back a bit: headers marked appropriately can be used and provided a shield similar to scales via glibc & similar (see below) - but check any headers you do use to make sure that they are in fact thusly marked (and note that this goes back to my "… or very definitely answers the question")]
It has also explicitly been said that making calls to the kernel indirectly by other means does not carry the same requirement, so if you use glibc (to give what is perhaps the most common example) and it causes the kernel to be called, you do not inherit GPL requirements from the kernel. What requirements you inherit depend on the license of the library, in this example LGPL which is glibc's license and that doesn't confer any such requirement from linking or other such coupling.
Whether this indirect call via another library that isn't itself GPL licensed acting as a shield holds generally, or just where explicitly stated as with Linux, I'm not sure off the top of my head. I'd have to reread the licence to refresh myself on the exact details and that isn't something I have the time to do right now, but in the case of Linux it doesn't matter if that is a general property or not because of specific things that have been officially stated.
There is a further exception that allows the making of binary blobs to act as drivers and such writing the kernel. I'm not sure if that is just a refinement of the same shield, or something more specific. Again I'd had to reread to be more sure (I've not gone over the "fine print" here in detail for some years).
> Using background service such as Minio as an unmodified black box for data storage as part of your app is unambiguously not derivative work.
That is certainly the case for LGPL, but by my understanding it isn't for GPL nor by extension AGPL. Minio's maintainers themselves shrug on the matter and suggest you either lawyer up or pay for commercial licensing if your work is not also AGPL and therefore directly compatible (see https://github.com/minio/minio/blob/master/COMPLIANCE.md).
If you don't modify, you have no obligations. Easy.
[Well, not so easy, as this discussion and the likes of Minio saying “get your own lawyer to tell you what our licence says” illustrate – what constitutes a derived work is apparently not objectively well-defined]
Don't believe me? Ask Google and their vast legal team: https://opensource.google/documentation/reference/using/agpl...
https://softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL...
"You have a GPLed program that I'd like to link with my code to build a proprietary program. Does the fact that I link with your program mean I have to GPL my program?"
"Not exactly. It means you must release your program under a license compatible with the GPL (more precisely, compatible with one or more GPL versions accepted by all the rest of the code in the combination that you link). The combination itself is then available under those GPL versions."
[0]: https://min.io/
[1]: https://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
Having said that, the fact that minio's documentation answers the question with a shrug and says "lawyer up" (see https://github.com/minio/minio/blob/master/COMPLIANCE.md) seems quite telling.
The answer to “can I do X with your product?” shouldn't, in a reasonable world, constitute expensive legal advice. It feels rather shifty to me.
"13. Remote Network Interaction; Use with the GNU General Public License.
Notwithstanding any other provision of this License, if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software. This Corresponding Source shall include the Corresponding Source for any work covered by version 3 of the GNU General Public License that is incorporated pursuant to the following paragraph."
Therefore, what I said about linking applies to both.
To be clear, you only have to offer source code if you've modified an AGPLv3 program and you're distributing it publicly or "interacting with it remotely through a computer network (if your version supports such interaction)". Op's scenario neither modifies Minio nor distributes it, so they're under no obligation to offer source.
I really, truly believe the GPLs have revolutionized our society. It's hard to imagine the internet and tech looking as good as they do (they could look way, way worse) without copyleft. Somewhere along the way we adopted this simplistic, hypothetical conception of freedom as "fewer restrictions and obligations", but experience gives us numerous counterpoints. Who is more free, the citizen of a country that protects against robbery, fraud, and violence, or the denizen of a lawless land? Oftentimes restricting one freedom (the freedom to kill, the freedom to close source) unlocks untold other freedoms (freedom to speak or worship without violence, freedom to build Google et al on the back of FOSS software). We've weirdly forgotten this, and I'm doing what I can to remind us.
That Google policy is actually heartening to me. It means that if I build some successful infra app and license it under the AGPLv3, there's zero chance I'll see it show up in GCP. That's a mission accomplished as far as I'm concerned.
Only if the project doesn't have copyright reassignment, of course.
No and it's spelled out very clearly in the license.
In my experience, organizations that use AGPL do so to 1) ward off an active non-paying community with its associated support cost, 2) claim open source to help convince you to buy their software/service, 3) hire skill-vetted programmers, 4) allow third-party security audits, and/or 5) avoid being jaded by someone that can market or host their solution better than they can.
The two paragraphs above what you quoted are:
"However, in many cases you can distribute the GPL-covered software alongside your proprietary system. To do this validly, you must make sure that the free and nonfree programs communicate at arms length, that they are not combined in a way that would make them effectively a single program."
"The difference between this and 'incorporating' the GPL-covered software is partly a matter of substance and partly form. The substantive part is this: if the two programs are combined so that they become effectively two parts of one program, then you can't treat them as two separate programs. So the GPL has to cover the whole thing."
Two programs communicating over a socket aren't incorporated. They're two programs.
I'm not super interested in fielding more thin gotchas based on out of context quotes. There's a big difference between a license that's difficult to understand and a license that somehow summons people from the ether who find endless ways to deliberately misunderstand it.
> Two programs communicating over a socket aren't incorporated. They're two programs.
Aren't they? So, if I want to use a GPL library, all I need to do is write a little wrapper program that does RPC over a socket, and boom, I can use a GPL library in my closed source program? Obviously not.
Yep. This is how MySQL/MariaDB work, for example.
The FAQ also has interesting takes, where depending on the jurisdiction you're in, I'm sure such views would differ:
Q: In an object-oriented language such as Java, if I use a class that is GPLed without modifying, and subclass it, in what way does the GPL affect the larger program? (#OOPLang)
A: Subclassing is creating a derivative work. Therefore, the terms of the GPL affect the whole program where you create a subclass of a GPLed class.
> I'd argue that "subclassing" essentially constitutes just using an interface (in the general sense, not in the Java sense) to some existing software, so in Minio's case, using their API would constitute a similar usage pattern -> my "derivative" work must now be GPL licensed.
No, again the difference is incorporation. In order to subclass something you have to incorporate it into your code.
What are you on about? The explicit purpose of a license is that it's users do not have to worry about anyone else's "explicit intent". A license needs to be unambigious about it's terms, else it's just not a good license, hence see the discussion in this thread about the meaning of derivative works.
It may very well be that the FSF/RMS/GNU Project had some intent on it's use when creating the GPL/AGPL v3, but a court in another jurisdiction will not care. I have no idea how to get a hold of the FSF when I'm being sued for license violations in europe and even if so, I doubt a court would care about the FSF's interpretation, given that they're likely not a party to the proceedings.
I'm surprised that people on an US centric site believe that intent in US jurisprudence matters, because in a legal system largely based on precedence, it really does not.
> No, again the difference is incorporation. In order to subclass something you have to incorporate it into your code.
You have to do the same thing in order to use API's. I'm sorry, unless I don't understand something here, this doesn't make sense.
Even the most carefully written license has ambiguity, and that's for two reasons. First, we want to cover situations without exhaustively enumerating and describing them in great detail. Statutes and the Constitution run into this all the time, but no one's like "don't start a business in the US, their Constitution is ambiguous and courts have to clarify and interpret it all the time" because courts (except for this one, I'll admit) do things like take reliance interests into account when adjudicating cases. It works well enough in contract law that we've built the most advanced economy in history, so I wouldn't poo-poo it.
Second, and I'll echo Dijkstra here [0] our languages aren't precise. They're bad at the thing you want them to do. Your argument argues against all contracts and licenses everywhere, even laws themselves.
Finally, (A)GPLv3 don't refer to derivative works. That's a GPLv2 thing.
> I'm surprised that people on an US centric site believe that intent in US jurisprudence matters, because in a legal system largely based on precedence, it really does not.
Again, happy to read any case law you can find on this.
> You have to do the same thing in order to use API's. I'm sorry, unless I don't understand something here, this doesn't make sense.
I'm starting to believe people here don't know what linking and incorporate mean. Linking is using a linker--like ld--to build an executable or library. It's not some abstract idea of linkage. Incorporate means pulling the source code into your own. It's not some abstract idea of building a larger system. You don't pull the source code to Minio into your code to use its API.
0: https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...
> Combining MinIO software as part of a larger software stack triggers your GNU AGPL v3 obligations. The method of combining does not matter. When MinIO is linked to a larger software stack in any form, including statically, dynamically, pipes, or containerized and invoked remotely, the AGPL v3 applies to your use. What triggers the AGPL v3 obligations is the exchanging data between the larger stack and MinIO.
That version has, unfortunately, not been archived at web.archive.org or such.
Some remnants of the old compliance text are still mentioned: https://github.com/minio/operator/issues/2030
I think you can interact with GPL/AGPL and retain your code propietary by:
- Don't modify the AGPL program.
- Run separatly, using docker container, vm etc
- Interact with CLI, REST API, filesystem, database etc
- Keep the AGPL interaction only to your program, non public consumption, minimum the surface of distirbution the code.
- Keep your code non directly interact, such as avoid use node npm dependencies directly, avoid library linking, use api gateway, use thirdparty module.
> Permissions of this strongest copyleft license are conditioned on making available complete source code of licensed works and modifications, which include larger works using a licensed work, under the same license.
Note the last part: "which include licensed works using a licensed work"
[0]: https://archive.fosdem.org/2021/schedule/event/agplcomplianc...
In the Basic permissions of the actual content of the license https://github.com/minio/minio/blob/master/LICENSE
It's not that difficult to parse if you actually read it top to bottom instead of skimming.
"If the program is expressly designed to accept user requests and send responses over a network, then it meets these criteria. Common examples of programs that would fall into this category include web and mail servers, interactive web-based applications, and servers for games that are played online."
"If a program is not expressly designed to interact with a user through a network, but is being run in an environment where it happens to do so, then it does not fall into this category. For example, an application is not required to provide source merely because the user is running it over SSH, or a remote X session."
[0]: https://www.gnu.org/licenses/gpl-faq.html#AGPLv3InteractingR...
https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html
The only concern then is ethical - will the developer be monetarily compensated if the product makes money? I believe they should be. Other open source developers may disagree.
Note also that for a commercial open source project, a CLA can offer some legal protection - by signing a CLA a developer declares that they own the copyright on the code, which reduces the liability of the commercial venture behind the open source product if someone contributes "pirated" code.
It also gives me similar vibes to the Do-Not-Track HTTP header since both can be enabled by default.
CLA-Assistant is also similarly simple to fill out, so that can't be the difference there...
That's true in the sense that there will always be an AGPL version, but it's not true that "anybody else" can use it to. In many situations you need to acquire a non AGPL license from the original copyright holder to be legally able to use the software in certain environments. That's why CLAs are important so that there is always a copyright holder that can give you a non AGPL version.
It's pretty much perfect. Stallman himself suggests selling exceptions to the GPL as a viable business model for companies, Qt being the number one example. I actually emailed Stallman and asked what he thought about this new AGPLv3 SaaS pattern, here's his reply:
> It is my understanding that as the copyright holders
> they have the right to do it without any problems.
> They leverage the AGPLv3 to make it harder for their
> competitors to use the code to compete against them.
I see what you mean. The original developer can engage
in a practice that blocks coopertation.
By contrast, using some other license, such as the ordinary GPL,
would permitt ANY user of the program to engage in that practice.
In a perverse sense that could seem more fair, but I think it is
also more harmful.
On balance, using the AGPL is better.> In order for us, Retake, Inc. (dba ParadeDB) to accept patches and other contributions from you, you need to adopt our ParadeDB Contributor License Agreement (the "CLA"). The current version of the CLA can be found here.
https://github.com/paradedb/paradedb/blob/6b829681190684f241...
> You hereby grant to the Company and to recipients of software distributed by the Company a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare derivative works of, publicly display, publicly perform, sublicense, and distribute Your Contributions and such derivative works.
My not super-close reading is that this is actually reasonable (but note: I wrote the original GNU blanket assignment back around 1989 or 1990 so you may consider my perspective bogus).
This agreement says that you confirm that you have the right to license your contribution (that what you wrote isn’t actually your employer’s), and that they can use it without restriction, even if there’s something patented in the submission. It doesn’t stop you from using the code for something else. But you can’t come back later and say “hey, yank out these lines of code which I sent you long ago”. It's not even an assignment -- you retain ownership.
If I were doing this, personally, I might add something to the effect of “btw if the company tries to change the license in a way incompatible with the AGPL 3.0 or later versions this license I have you becomes void” but that could implicitly be in there (if explicit, I missed it in my quick read).
But doesn't this CLA in particular (and most CLAs out there generally) assign the company behind it a license to distribute all contributions under any license they wish? Specifically the part that I quoted where contributors give them an "irrevocable copyright license" to "sublicense" their contributions?
As far as I understand, this allows them to unilaterally re-license the project as a whole (to proprietary or non-free open source) without asking contributors for permission.
The only way I'd agree to a CLA is if it included explicit language that ensured that they couldn't do this, e.g. "You hereby grant [...] under the terms of the AGPL v3 license", but I'm not a lawyer.
That's generally how CLAs work, to enable re-licensing. For many commercial AGPL projects that's also needed because the copyright holding entity will sell/provide non AGPL versions to customers that legally cannot use AGPL software.
Yes. CLA requirements for commercial AGPL open-source projects actually highlights an important feature of the AGPL - you need explicit permission from the developers to use their code in a proprietary codebase.
Codebase under a permissive open-source license like BSD, MIT, ZLIB etc. can be used by anyone and even packaged into a closed source codebase (with a proprietary license) even without a CLA. All that such license demand is that you do not deny public attribution to the developers and highlight the original license (here's an example from the old Opera Presto browser which was a proprietary closed browser with open source components in it - https://imgur.com/a/KDavWLd ). On the other hand, an AGPL codebase cannot be packaged into a proprietary codebase because the license requires not only attribution but also the requirement that the all source code, even the non-AGPL parts, has to be compulsorily shared if you link it with an AGPL codebase (i.e. it forces all code to be always open source).
The underlying philosophy of the xGPL license is the right to repair the software you use. And you can only do that if you have access to the source code of the software. Under AGPL it is illegal to close-source an AGPL codebase. But, AGPL also recognizes the rights of a developer on the code they created. It thus doesn't prevent the original developer from re-licensing their own code or even transferring the rights to another. Thus, in some way, AGPL actually forces the CLA requirement (if you want to distribute a software under proprietary license) and let's the developer decide if they want their code to be reused in a proprietary codebase.
"In order for us, Retake, Inc. (dba ParadeDB) to accept patches and other contributions from you, you need..." makes it sound like their hands are tied, you must assign copyright, there's no other option.
In reality, this is a (contributor-hostile) choice they made. They could have made different ones.
And they don’t feel safe including a patch without a license to use it. Not an unreasonable position to take.
The wording is explicit (italics mine):
> You hereby grant to the Company and to recipients of software distributed by the Company a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to…
The CLA means you're giving them an additional license: one that lets them do things that the AGPLv3 wouldn't, like use your code in proprietary software.
This is common for FOSS-maintaining organizations that want to use dual-licensing as part of their revenue strategy. Users (including organizationswho are comfortable publishing any downstream changes they might make under the terms of the copyleft license use the free version. Users who are not can instead choose to purchase a proprietary license, like they would with closed-source software.
Often there's some hope that as users of F/OSS, the developers and users are overlapping groups, and there's enough alignment of interests there to provide some level of assurance that the developers (or publisher, in the case of a corporation or collective entity) won't suddenly make drastic changes without user input. (Often, too, that isn't actually the case.) A CLA can give the developer the ability to make such drastic changes as taking a copyleft project and creating a closed-source fork. In cases where the development work is supplied predominantly by a single commercial entity, that means that they can essentially orphan the project out from under you, leaving the open-source version of their software an unmaintained vestige of a proprietary commercial offering, at any time.
So CLAs involve a lot of trust or a lot of risk. Some companies have set up non-profit foundations to be the official stewards of their dually-licensed software so that the chief/commercial maintainers of the software can leverage the dual-licensing revenue strategy while fostering strong community trust. See, for example, the Free Qt Foundation. When Google wanted a CLA as insurance against patent litigation for Kubernetes, they did a similar thing and set up the Cloud-Native Compute Foundation so that Kubernetes could have a 'trustworthy CLA', so-to-speak.
I hope that clears up both why upstream developers might sometimes want a CLA of this kind and why downstream developers can sometimes be leery of them.
I think we're at a bit of a crossroads here. Enough (smaller) companies have been bitten by the likes of Amazon monetizing their code and crushing the original developers' monetization strategy. So we see some companies turning to non-F/OSS "source available" type licenses instead. This is bad for the open source community as a whole.
IMO, AGPL+commercial is a fine compromise, and companies need to be certain that if they take contributions from the community, that they can still sell commercial licenses for the whole product, including the contributions, without issues in the future. Requiring contributors to assign copyright is one simple way to do that, but I think the path this company has chosen is a lot nicer in letting contributors keep ownership over their contributions.
For a piece of software where the expectation is that the company is going to be doing 90% of the work, and outside contributions will be relatively small, this seems entirely fair to me.
Nobody is forcing anyone to give away their rights. You can always distribute contributions under AGPL in a forked repo.
The alternative is that if you're making meaningful contributions then it's in the company's best interest to hire you full time to do it.
Contributing upstream can benefit the ecosystem around the project, and the money that comes from commercial licensing also benefits it. In some cases the project would die if it didn't have the commercial side. They're not running a charity and if they aren't generating enough revenue they'd likely be working on something else rather than maintaining a FOSS project that doesn't make any money.
But dual-licensing is a tried-and-true strategy and the basic premise is very clear and very fair: share your downstream changes or pay a fee. And a CLA is required to make that work.
Something commenters here seem to miss is that all permissively licensed software is vulnerable to the same kind of maneuver that copyleft+CLA software is. If MIT or Apache don't scare you, neither should GPL+CLA.
Even worse, let's say I am a paid customer for their support and run on their proprietary license. Once they rug pull or jack up the prices or whatever, I cannot fall back to AGPL hosted locally. If it were permissive I would have had other options.
AGPL I fully respect as Free Software. AGPL+CLA, however, is not your friend and is pure deception. If you are a sufficiently large commercial entity, you are probably wise to act as if it is proprietary. In fact, it might be slightly worse as folks are sometimes cavalier in accepting contributions without proper copyright license/assignment and they pass them on to you under their paid license and expose you to some risk.
That part is exactly the same under AGPL, no?
You can fork it and use it in and as free software forever. This is only 'unreasonable' if you're a proprietary software vendor. The complaint of a proprietary software vendor strikes me as somewhat ironic here: what, the same deal that you give to your own customers for your own product is one you simply 'can't' take yourself because it's not 'reasonable'?
> If you are a sufficiently large commercial entity, you are probably wise to act as if it is proprietary.
But right about this. In the scenario you describe, you're a customer under the proprietary license— the kind of dependency your proprietary software product has on the software is the same kind it might have on any other proprietary software. The AGPLv3 version is not a backup option for you.
And it's true that the dual-licensing game the original vendor has set up is one that only they will ever be allowed to play.
If my company were considering purchased dual-licensed AGPLv3 software, I'd give advice like the following:
> It's great for the wider public that there is an open-source version of this exact same software our there. But what we're considering buying here is not that— what we're considering buying is proprietary software. For us, all that the availability of that open-source license means is that this is proprietary software whose source code would be easy for us to inspect, and that upstream might even accept our patches for issues that we encounter. I think both of those things are huge advantages! But if this vendor gets bought out or shuttered, we could potentially be left in the lurch much as we would if the software were exclusively proprietary. That's often an acceptable risk, in my opinion, and it's certainly one that our company has deemed acceptable with many past and present proprietary software purchases. But we should note that on the assessment: if we buy this, we're not buying or depending on open-source software; we're buying and depending on proprietary software.
All that assuming, of course, that the proposition is to use the AGPLv3 software in a user-facing, proprierary web service under the assumption that the copyleft component of the AGPL extends to that web service. If we were evaluating it for use in an internal service, where the end users are our own employees, or an external-facing service that we'd be comfortable releasing under the GPL, or we think that the way we want to use it would not require any license changes for us even if we take thw AGPLv3 version, I'd instead say something like
> Ask the lawyers as always, but I don't foresee any problems. I think this is great and I'd love to use it. If our legal people aren't used to considering copyleft licenses, can we have them consult with the FSF or the SFC or the EFF or something before they make a decision about this? Is that a thing?
Anyway, I agree with you about how being the customer (under the proprietary license) of a company like this is different from being the customer (for support services only) of a company who publishes permissively-licensed free software. I don't agree, though, that the dual-licensing thing is a trick! I think it's totally possible for everyone to go into that kind of arrangement eyes open and be happy with it. I hope and expect that's the goal for companies like that of TFA.
I am not discussing ethics or morality here, just practicality, and yes, from the perspective of a user that is not primarily releasing open source. Note that it's somewhat different and more general than your characterization. I might be in another business, not software, but unwilling to touch AGPL within my infrastructure due to risk of virality. Strictly speaking, I am not a "proprietary software vendor" as I am not even in the software business, primarily. Nevertheless, your general point stands.
I am not arguing it is bad. Simply that I would not characterize AGPL+CLA as "no vendor lock-in because open source." I put it right in the bucket of e.g. Oracle proprietary database. I am not saying it is bad or totally unreasonable. I just don't buy up the marketing koolaid.
The AGPL deception is you brand yourself as community-minded. As long as you don't rely on external contributions that's fair. But what the AGPL startups don't emphasize is they require you to either assign your copyright to them or give them extra privileges to your contributions to be able to relicense it under non AGPL (if they don't they don't know what they are doing).
AGPL is also not considered a very safe license by large organizations even if you want to run it internally unmodified, alongside the rest of your application. Many big companies have blanket bans on AGPL.
Some startups may not know this or knowingly violate this.
No, as long as they either remove the contributed code or distribute it in a way that is compatible with AGPL
There's nothing specific to the AGPL or startups here, it's a common model. The FSF themselves require copyright assignment if you want to contribute to FSF projects.
Secondly, don’t equate the FSF with any other company. The FSF is in the unique position in that the FSF could change the GPL if they wanted to. If you use the GPL/AGPL, the FSF is inherently trustworthy; therefore, it’s completely reasonable to also trust the FSF with a copyright assignment.
The FSF requires copyright assignment for many (possibly no longer all?) of their own projects, e.g. GnuTLS. Of course it's up to an individual project whether it requires it (how could the FSF possibly control what some unrelated project does?), but on those projects that the FSF themselves run (or at least many of them, and traditionally it was all of them), they require it.
> The FSF is in the unique position in that the FSF could change the GPL if they wanted to. If you use the GPL/AGPL, the FSF is inherently trustworthy;
They cannot change the GPL. They can publish new version of it, and recommend that you license your project with a term that permits it to be used under those new versions, but this is not obligatory (and notably e.g. the Linux kernel does not).
The FSF requires nothing of the projects; the FSF leaves the choice of copyright assignment up to the project and its maintainers. Which is what I wrote. The fact that many projects do choose to require copyright assignment does not make you be less wrong when you said that the FSF requires it.
> They cannot change the GPL.
Technically true. But the FSF can publish a new version of the GPL, which all GPL-licensed software using the “or any later version” language, which is most GPL software, will then use. Linux is an oddity here.
And in the case of their own projects, the projects where the FSF is the project/the maintainers, what is it they do? They require copyright assignment.
They can publish new versions of GPL if they want to. They can't retroactively change the terms that users of the software and contributors agreed to.
Just like any code owners who has the complete control of copyright can publish their code under a different license.
So if you license under GPLv2, the FSF can create GPLv5 and add whatever clause they like in it.
The Author can choose to license the Copyrighted Work under various licenses. The common boilerplate that many Authors of GPL software choose to use is a boilerplate that says they are licensing their Work under GPL version X or any later versions supplied by FSF. That boilerplate is Author's declaration of license contract and not the license itself.
Basically the Author is directly saying (not through the GPL text) that "I trust FSF to come up with future licenses and call whatever they want GPL version Y [Y>X] and I'll be willing to license my work under that license sight-unseen also."
No update on the license can retroactively change what I agreed to.
They cannot add anything to it; the new license has to, IIRC, be substantially similar in spirit.
FSF's structure, purpose, history and guardrails against non-hijacking make it distinct from a startup whose purpose is to claim "open source" but preclude Amazon and keep their revenue stream. Nothing against them or their business model; it's their prerogative, of course. So is the community and customer's read on their future actions. To claim you should assume they are the same is preposterous and/or fooling yourself. Criminals and police officers both have guns too. Doesn't make them identical.
A purely F/OSS company could potentially profit way more from your code than you do and still comply with the license. You'd be free to reincorporate their code back into yours, of course. But code isn't money.
This can foster more community than if MIT code were to be taken and locked behind closed doors, for profit and to no benefit for the devs that made it possible.
This is anti the ethos of GPL [1]
And that's fine, you choose a list or rules that fitted with your wants, you don't have to respect A/GPL.
But time and time again we see most people on HN not respecting the A/GPL ethos they clam to follow and not understanding what A/GPL will mean in practice.
> disproportionately profiting
Off Topic to GPL. Corporations have provided more value to the world than any person. Which is almost a tautology since corporations are just groups of people working together. "Disproportionately profiting off of my labor" would mean they are providing amazing resources to people who need them.
You sound like you don't want others to succeed. Which is different to you need to make money to live.
[1] The legal/logical issues we see with AGPL are from trying to get the license to match the ethos. It's commendable they did stick it out.
I think trying to prevent disproportionate profit by big companies is plenty compatible with the ethos. The ethos of GPL is all about the end user, after all.
> would mean they are providing amazing resources
No it doesn't mean that.
If by value you mean: "have increased gini coefficient", then yes, corporations have done that.
"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. ParadeDB just turned one year old, and we’ve already been contacted by four cloud providers who, had we not chosen the AGPL license, may have privately forked and distributed ParadeDB."
Nothing in the license requires cloud vendors from reselling the project. They just need to make the source available?
What am I missing?
But it's a common enough misconception that my personal recommendation tends to be to just steer clear anyway, if you're planning to run a closed-source business. It's better to not get sued at all, than to get sued by someone who's wrong.
But for reference, the only text added to the AGPL in comparison to the GPL is section 13 here:
https://www.gnu.org/licenses/agpl-3.0.en.html
In other words, if you run an AGPL database and modify it, you need to provide your users with the source of your modified version.
Nothing remotely suggesting that the rest of your entire software stack becomes AGPL licensed. (In fact I often wonder how people are imagining that would even work. It would basically imply that you can't, for example, run AGPL software on a Windows server...)
> "Linking a GPL covered work statically or dynamically with other modules is making a combined work based on the GPL covered work. Thus, the terms and conditions of the GNU General Public License cover the whole combination"
> "To prevent unscrupulous distributors from trying to use the System Library exception as a loophole, the GPL says that libraries can only qualify as System Libraries as long as they're not distributed with the program itself. If you distribute the DLLs with the program, they won't be eligible for this exception anymore"Linking in this context refers to a very specific thing: https://en.wikipedia.org/wiki/Linker_(computing)
If you can't use the AGPL version now, you can't use it later either.
And I don't see how it prevents "Cloud Vendors" from using it, but not everybody else as well.
> If you can't use the AGPL version now, you can't use it later either.
Right. But you can use it now and later.
> And I don't see how it prevents "Cloud Vendors" from using it, but not everybody else as well.
Cloud vendors can use it. What they can't do is fork it and start making private changes that they do not release for others to use. Forking it is fine, making incompatible changes is fine, but keeping those changes proprietary is not.
The AGPL defends against competition from a big cloud operator, but not in the way you're thinking. It does not prevent the cloud operator from using or even modifying the software. It does prevent that operator from creating a competitive fork that benefits from starting with the AGPL code but then diverges in a way such that customers will want to pay the cloud operator for their up to date fancy version instead of the original project. I mean, they still could try to get people to pay for that, but the original project will have access to all of their changes so the cloud operator won't have any advantages when selling support or a license with different terms.
Those changes would be under some sort of AGPL and the original project cannot merge it back, while still maintaining their option of a commercial license.
So once the original project merge any of their competitor's changes/forks, their project becomes AGPL only, and lose the ability to charge for a commercial license as a monetization strategy.
So not just small changes, big changes that have a significant value-add, and not easily replicated. It assumes cloud vendors will want to start building a business on top of this critical dependency.
It doesn't sound like a great deal for the cloud vendor.
I assume we are really only talking about Amazon, Microsoft and Google, and the developer hopes to just get bought rather than messing around with licenses.
That, or the cloud vendor does not buy a license and uses it anyway, with or without changes. And existing customers of the originator continue to be their customers, rather than switching to become customers of the cloud vendor instead.
> So not just small changes, big changes that have a significant value-add, and not easily replicated. It assumes cloud vendors will want to start building a business on top of this critical dependency.
It doesn't assume that, it defends against issues caused by that.
> It doesn't sound like a great deal for the cloud vendor.
Exactly! But that's the point.
> I assume we are really only talking about Amazon, Microsoft and Google, and the developer hopes to just get bought rather than messing around with licenses.
The canonical case is where the original author does want to sell licenses and/or support and/or development contracts to various random companies, most of them not giant cloud companies. They do not want to be acquired. Their customers are most likely also customers of some large cloud company, and the original author most of all does not want to compete with the cloud company. The author will want the software to work well in the context of a cloud offering, and will not want their version to work worse than the cloud company's own version. If a big cloud company comes up with a way to make the software work better when using their cloud, then the original author wants to incorporate that improvement, preferably alongside improvements made by or for the other big cloud companies.
But you are correct about the importance of selling something, whether it is a license or support or development services. As a sibling comment to yours mentions, that's where the CLA (contributor license agreement) stuff comes in, where in order to be able to sell a proprietary license, they need to own all the code. This is where it can get ugly. Not everyone wants to hand over ownership of changes they make, so that the originator can make money off of them. And nobody has to. The AGPL only forces people to make their changes available, not to give them away; it's up to the originator to make people want to get their changes upstream.
You can only contribute when you accept the CLA at [1] which gives them the right to license your contributions under said commercial license.
https://github.com/paradedb/paradedb/blob/dev/CONTRIBUTING.m...
Now it's up to you whether to sign that CLA to upstream your changes.
You're welcome to maintain a fully AGPL fork if you don't like that.
If you go with Apache 2.0, you're literally doing free work for cloud vendors.
Here is the rub: free software permits unconditional use.
The GPL without the A, or MIT or BSD licenses are not EULAs; they place restrictions or conditions on redistribution, not on use. (With regard to use, they have only certain liability disclaimer clauses.)
The AGPL restricts use; it is an EULA: end-user license agreement. The antithesis of free software.
I think you're wrong.
> The GPL without the A, or MIT or BSD licenses are not EULAs; they place restrictions or conditions on redistribution, not on use.
The GPL, at least, puts restrictions on use: you can't use the software in certain ways (e.g. use in a binary firmware blob) unless you distribute it in source form to the end users.
> The AGPL restricts use; it is an EULA: end-user license agreement. The antithesis of free software.
The AGPL does exactly the same thing as the GPL, just with a stronger distribution requirement: if you distribute access to end users, you must distribute it in source form to the end users.
The GPL was designed for the binary distribution age of software, the AGPL is the GPL for the SaaS distribution age. The GPL alone cannot satisfy Free Software goals in the new age.
Yes, you can. You can combine a GPLed program with whatever you want; you just can't redistribute the result if the combination runs afoul of the GPL.
redistribution is not use. Use is running the program, reading the program, trying changes and such.
You can combine GNU Bash with proprietary code and let users remotely log in to your box to try it.
> if you distribute access to end users
There is no such thing. Copyright law does not recognize "distributing access". The program is not being redistributed when it executes and exchanges messages with remote stations.
"Distributing access" also reminds me of the idea of someone hearing the sound of your coins jingling, or smelling your cooking: as in from the famous case of Ōoka_Tadasuke that circulates as a popular parable:
There is a lengthy article by RMS "Why programs must not limit the freedom to run them".
https://www.gnu.org/philosophy/programs-must-not-limit-freed...
However, in this article, RMS is cheerfully recommending Affero:
https://www.gnu.org/philosophy/who-does-that-server-really-s...
It seems more or less in the original spirit of GPLv2 but updated for a SaaS driven world. If you consider v3 restrictive then you must also consider v2 restrictive, just in a more narrow way.
The original spirit of the GPL is about identifying people doing bad things we don't like and trying to prevent them. All those bad things have to do with redistribution, not with using the program.
The AGPL is still about identifying people doing bad things we don't like, except now those people are just running the program.
This is no different from Adobe, Apple, Microsoft, ... identifying people using their software in ways they don't like, and crafting their EULA terms to turn those activities into a license violation.
A free software license simply cannot dictate uses, like where and how you run the program, and who can access it from where.
A free software license can only use copyright law, and only be concerned with copying.
EULAs go beyond coypright; they try to connect non-copying activities to copyright by the doctrine that if the user engages in the forbidden activities, their license is terminated (and thus it becomes copyright infringement for them to continue to have a now unlicensed copy of the software).
Its the same "bad thing" as distributing a modified binary without the source. Its a way of denying end users access to the source code.
You can do whatever you like with AGPL code, as long as you make the source available.
it is VERY different from saying "you cannot do this with your software". It is just changing the conditions under which make source available is required to keep up with how people use software has changed.
AGPL is nothing like a EULA. It is a license, not a contract. It is very similar to the GPL
The user of a program is the one who installs it somewhere and runs it.
Outside people interacting with the program are visitors. They don't have the source code because they don't have the program at all in any form. It has not been distributed to them.
The source code to the program doesn't even do them any good. They cannot use that to prevent harms perpetrated by the operators of that application.
> The source code to the program doesn't even do them any good. They cannot use that to prevent harms perpetrated by the operators of that application.
It does. It means they can run their own instance instead of being permanently tied to the operator of the service. It means they can modify and run the software.
> They don't have the source code because they don't have to program at all in any form.
That is sophistry. For the type of software AGPL is designed for the functionality provided is the same as it would if they had their own install. It is called "software as a service" for a reason.
The reason the AGPL exists is because the rise of SAAS has made the distinction you are making meaningless.
> They don't have the source code because they don't have to program at all in any form.
Users of GPL software do not "have to program". The point is they can. The same is true with AGPL.
https://perens.com/2017/05/28/understanding-the-gpl-is-a-con...
But no the same is not true of the user of the AGPL. The GPL user having the source code and being able to program or hire somebody is utterly meaningful. That user controls the installation of the program. They would like the program to do something differently, or not to do something unwanted. With the buildable source code they can achieve that.
The visitor to the AGPL application have access to the source code has no meaning at all. They don't have the administrative access to replace the implementation (and even if they did, that was just create conflict with the other ivisitors).
The ability to set up your own clone instance its completely meaningless. For example suppose that's some government service website is using AGPL software. What do you gain by downloading the software and running your own instance? That's not where your data is; you can't use that cloned instance to communicate with the service agency.
It is the AGPL that's using outdated concepts in a new context where they don't make sense. (Licensing helped us win the open source war in the 1990s and 2000s, so it'll work this time too right?)
You also may be thinking of the software of being something like a photo editor or word processing application that is hosted, but in which the visitor works with only their own files in isolation from other visitors, and from the site operators. I don't think that's the main target for the AGPL. That may be called "strawman AGPL". I tend to agree that the AGPL may be effective in this limited situation. But effective is not the same as free. A "free for personal use" software license is also effective at achieving the aims of its purveyor but isn't free.
Isn't that the whole point?
Nope. It can just be a piece of text you agree with when opening a classic mass-marked app in a shrink-warpped box ("shrink-wrap EULA") or a dialog box with text where you have to click that by using the software, you agree with the licensing terms.
Exactly the same as when you deploy an AGPL program for visitors, you are agreeing to its EULA.
It's an agreement between different parties.
It's not. It's about making sure users can fix the bugs in the software they want or need to use, and share those fixes with others. Rules about redistribution are a means to that end.
The GPL was originally written in an era of mainframes and terminals, the idea of running a program via some intermediate system is not novel. But no-one in that era would have dared try to argue that a program hadn't been distributed to you because it was running on a machine in a different building rather than one under your desk.
> This is no different from Adobe, Apple, Microsoft, ... identifying people using their software in ways they don't like, and crafting their EULA terms to turn those activities into a license violation.
If you make your equivalences broad enough then anything is equivalent to anything else. "This license is written in text, making it no different from that license that is written in text".
> A free software license can only use copyright law, and only be concerned with copying.
You're confusing ends and means. The free software movement was actively opposed to copyright law and wanted software to be uncopyrightable. But that was no reason not to use a copyright license that served their goals.
If software were uncopyrightable, they would still be binaries without source code, which you would have to reverse engineer to find out what harm they perpetrate actively or possibly through their security flaws.
Moreover, if you wrote a piece of free source code, anyone could do anything with it they wish, including removing your name, and not attributing you in any way in the documentation accompanying the compiled code.
Stallman was a control freak who insisted that people modifying his code give back the contributions to the project. In the world without copyrighted programs he would have had no leg to stand on, and he knew that. A world in which programs are not copyrighted would need laws which ban the distribution of binaries without buildable source code, and all the tools needed to build it and their source code.
A program is not distributed to you if someone else installed it on a machine you don't own and you're just borrowing that machine. It doesn't matter if you're physically at the console, we're at a remote dumb terminal or smart client. The program was distributed to your school, company or friend or whoever.
I don't think that even the people who drafted the AGPL believe the nonsense doctrine that the visitors to a server have been distributed the software. That's just something invented by the downstream AGPL apologists. (And of course vendors of proprietary software like the doctrine also. If you buy a program and let 10 people use it via remote access to your machine, they would like the legal system to believe that those people were distributed the program and that you should buy ten more licenses). The doctrine is not required for the AGPL to work. The software distributed to the individual or organization installing it and running it for visitors. The license is concerned with the behavior of that individual or organization, and uses the power of copyright to make their permission to have a copy of the program conditional on their usage behavior. The visitors to the running application are not parties to the license.
The GNU AGPL contains these definitions:
> To "propagate" a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.
> To "convey" a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
True. But reverse engineering could happen openly, and tooling for it would improve. The benefits would outweigh the costs.
> if you wrote a piece of free source code, anyone could do anything with it they wish, including removing your name, and not attributing you in any way in the documentation accompanying the compiled code.
Depends where you are. Many jurisdictions recognise attribution as a "moral right" separate from copyright.
> A program is not distributed to you if someone else installed it on a machine you don't own and you're just borrowing that machine. It doesn't matter if you're physically at the console, we're at a remote dumb terminal or smart client. The program was distributed to your school, company or friend or whoever.
Up to a point. If you pressed the "buy" button, paid the money, and are using it from your machine like a program, then it shouldn't matter where it's metaphysically located. Plenty of software will "phone home" to company servers or even falsely claim to be running computation on the company's machines (SimCity), but that doesn't mean the software hasn't been distributed to you. Just as the courts don't allow you to stream TV from an OTA capture card in a remote datacenter and consider that to be OTA viewing, having a program that you use from your local machine do some of its execution in some remote datacenter (whether through VNC-style remote access, a web UI, or something else) shouldn't make it any less your program that's been distributed to you and that you're using.
The only caveat seems to be making the source code available to users of the software, which is also the case with GPLv2, just under narrower conditions.
I have no dog in this race, nor any particular attachment to any particular license, I'm just trying to better understand what these restrictions are that you're referencing.
No it isn't; under the GPLv2, the source code must be available to those to whom compiled code has been redistributed. Whether they are users doesn't matter.
The restrictions are that if you violate the license, your use of the program is infringing.
> What can I not do with AGPL software?
You cannot change it and run it yourself, without hosting the source code.
You cannot combine an AGPL program with proprietary code and operate it, because you cannot release the proprietary code.
Yes I can. It's only if I let other people use my changed code that they become entitled to a copy.
>You cannot combine an AGPL program with proprietary code and operate it, because you cannot release the proprietary code.
hmm, gotta say that sounds like the proprietary code is the thing infringing on my usage.
Question (IANAL), but isn't it also the case that you can't combine AGPL code with GPLv2 code? Like maybe you write a patch that glues Minio's (AGPL) and Git's (GPLv2) source code (I just picked the two first projects that came up when searching for those licenses).
Maybe your glue patch can be dual-licensed and that specific patch wouldn't have any problems.
But since (1) both licenses are viral and require that everything touched by them is licensed under that exact license; and (2) you are unable to change either project's license; then it seems to me that you would be unable to release your patch since it wouldn't be considered independent.
Or if you can release your patch as a separate project somehow, I think you still wouldn't be able to host this modified version of Minio because you can't satisfy both licenses at the same time.
So, expanding on your message:
>> What can I not do with AGPL software?
> You cannot change it and run it yourself, without hosting the source code.
> You cannot combine an AGPL program with proprietary code and operate it, because you cannot release the proprietary code.
(My addition) "You cannot combine an AGPL program with other open source software, unless their license is compatible with AGPL (e.g. MPL 2.0 or GPLv3)."
My understanding might be wrong though, because IANAL and these licenses are unapproachable to a mere mortal like me, but I just wanted to point out that AGPL also prevents combining with other open source software even if their license is another GNU license.
> You cannot change it and run it yourself, without hosting the source code.
So your point is that people should be free to take whatever they want for free and dont't contribute back? I'm glad there is a license made to put a limit on people like you then
(I've not put anything under even the dubious GPL license in over 15 years, and never will.)
Yes, a free software license must not require people to "contribute back", or anything of the sort.
For instance, a "free for non-commercial use" license is not free. Even the people who came up with the AGPL understand this, and go to great pains to explain it.
I understand the social problem that the AGPL is trying to combat, whereby visitors are held captive by saas applications over which they have no visibility or control.
The AGPL approach is to use the power of a non-free license against the problem which makes it a cure worse than disease, and repugnant to developers of truly free software.
It's almost certainly the case that the saas problem cannot be engaged via software licensing terms, if those terms are to amount to a free software license.
I don't have a better idea, either, but that doesn't change the fact that the AGPL is a non-free license which crosses over into governing use rather than just redistribution.
Also one issue is that the AGPL doesn't actually solve anything. Visitors having the source code to my evil saas platform doesn't solve the problem that they're locked to it. It doesn't solve the problem that I can change the code at any time and they cannot. Or that I can shut it down and wipe out their data, or share it with third parties. An AGPL conforming application also need not provide visitors with any way to export their data.
This was in fact Stallman's original vision for Emacs.
https://www.oreilly.com/openbook/freedom/ch06.html
"It is distributed on a basis of communal sharing, which means that all improvements must be given back to me to be incorporated and distributed."
Please enlight us about how the BSD license do it much better in this area. You first complain that AGPL is restrictive now complain that it should restrict even more? I agree with you, maybe it is time for another version of AGPL that includes data sovereignty. Let's make it more difficult for corporations to profit from FOSS free labor, not more easy.
Hard disagree. You're redistributing the software in a manner for people to easily use it.
If you rip a movie you own, there's no distinction that I'm aware of in copyright law between hosting the .ISO on an FTP server and hosting the .MKV as a stream. They're both redistributing, it's just that one is designed for ephemeral consumption.
Well, yes. While perhaps some metadata is lost, the content that is worth fighting for is captured in both cases. Practically speaking, there is no difference between the original source, an ISO rip, and an MKV rip. At least to the untrained eye, they are in every way equivalent. They both are redistribution, indeed.
That is not the case for SaaS in question. What you download during use can in no way be reconstructed into its original form. You can't use the software for a while and then, from what you've collected, start running the software on your local machine. The artifacts of use are very different from the software itself. To stick with your analogy, watching a movie on Netflix does not give you a copy of their server software. Distribution has not occurred.
Equating the running of a program with broadcasting is the kind of sophistry we might expect from Apple or Adobe or Oracle or their ilk.
Certain portions of a service program may be broadcast, like for instance certain string literals carrying text that appears at the remote end point. The bulk of the software is not transmitted. It transmits and receives messages, which are mostly not that program. The remote end cannot recover a copy of the program from these messages. Some bits of literal data, but none of the code. (There are obvious exceptions, like programs transmitted to web browsers for local execution.)
When you connect to a remote server over a computer and upload data and receive back results produced by the server software you do not receive a copy of the program. You receive a copy of the output that the program produced.
This is not how I see it at all. The ones using it are the users, and if they sit across the network you are distributing it in a very tangible sense.
The idea that the admin running a service is the one doing the "use" and not the users of your service is debatable to say the least.
Among the users, the admin is the one saddled with use restrictions by the license.
Rather, the copyright holder of the AGPLed work is exercising their right to dictate the following:
[Y]our modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version by providing access to the Corresponding Source from a network server at no charge, through some standard or customary means of facilitating copying of software.
Under the AGPL, the visitors to the program need not request the source; it must be prominently available for them to obtain in a self-serve manner. No mention is made that they have any kind of right. They are not parties to the license at all. A copyright license can only grant rights to licensees.
By the way, "all users interacting" could be interpreted to literally mean all users, including users who visit the login page, but do not have an account (and are not authorized to have one due to not belonging to the organization that runs the service).
> if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network [...] an opportunity to receive the Corresponding Source of your version [...]
From the Merriam-Webster dictionary:
> interact, verb: to act upon one another
When distributing a binary from a compiler to a user, the user does not act upon the compiler. So the user is not interacting with the compiler, so you don't need to distribute your modified compiler's code any more than you would with the GPL.
The disputed claim is that users who interact with a remote program are, by that interaction, being distributed the program.
The GNU AGPL itself explicitly disagrees with this; check its definition of "propagate" and "convey".
That being said, I think the AGPL is only appropriate for programs that come with a built-in source redistribution mechanism that ensures that modified versions automatically comply with the source code redistribution requirement.
Even if there were safeguards against such a situation, someone would blow past them.
Those who oppose the GPL are precisely the people it was designed to protect against.
I think we found a good example of your wishes here. You are against the GPL if you have an ulterior motive to make something proprietary and avoid contributing back!
Though I don't favor the GPL for my own code, I would not call it "antithesis of free software". The GPL does not impose any use restrictions, and meets a reasonable definition of a free license in other ways also.
"You are not required to accept this License in order to receive or run a copy of the Program."
There exist obvious circumstances of the program's use with which the license doesn't concern itself, and does not speak to, and so in those circumstances the user is not required to enter into the license.
A redistributor must enter into the license because it's a derivative of the GPL, and so it has requirements related to distribution.
A user who runs the program in such a way that visitors communicate with it from remote stations obviously is required to enter into the license also and comply with its requirements.
The license is applied to programs for which this would be a typical use.
It's in a section whose purpose it is to make it clear that you don't have to accept the license just have a copy of the program, but that if you convey the program your implicitly accepting with the license, that license being the only basis for your permission to redistribute.
Only if the user modifies the program.
The remote network interaction provision of the AGPL is conditional.
That makes hardly any difference.
It is logically obvious that the AGPL is a nonfree license. I have been saying this for some time.
It is a very unpopular thing to say.
> 10. License Must Be Technology-Neutral
> No provision of the license may be predicated on any individual technology or style of interface.
It has provisions that only apply to people who are interacting with the software remotely over a computer network. If they are interacting using some other technology those provisions do not apply.
It does not. You can absolutely host AGPL software as a service, you just have to share any modifications you made with those that use the service.
Or, what do you think usage restrictions are or look like?
If you don't share those modifications then you must not host that software such that it communicates with visitors; that's a restriction.
The modifications that you are required to share cannot be any arbitrary modifications; anything you add has to be AGPL compatible.
If the modifications combine the software with GPL-incompatible pieces, then you cannot share those modifications, which means there is no legal way to host that software for visitors.
The GPL places restrictions on a combination of the modification and distribution aspect, which says that if you modify the software and distribute it, then you must also include source code.
AGPL is more strict and says even if you just want to modify it and use it, you must supply the source code to the people who are using it. The important point here is that this is not triggering on use of the software (as EULA implies). It is only triggered after modification. And modification is something that is covered by copyright.
If you've not modified the software, interested visitors can just get the source code from the same upstream, so why would it be required of you to host it.
However the following situation could arise and I don't see how the license addresses it. You visited a site running some AGPL service which was modified by those site operators. You decide to clone your own instance using their modified code. Since you're not modifying anything yourself you're not required to host that code. Now suppose that original site shuts down and disappears. The upstream for that modified code is no longer available. Are you on the hook for hosting it now? You've not modified anything yourself.
> Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License.
This is a common misconception about Free software. It's not about freedom of its users or authors, it's freedom of the actual code to be available for others.
For example, MIT license allows users to take the code and modify it without releasing modifications. This traps the new version of the software, possibly forever, inside a single organization.
That‘s wrong. Free software is all about freedom for users. Stallman wrote whole essays explaining that.
Of course, back in his time, pretty much every user was also a programmer. But he is still very clear about that point, never writing about programmers when he means users.
It‘s also why people still fight their silly argument whether BSD or GPL is "freer". The BSD camp optimizes for developer freedom, the GPL for user freedom. Both camps think everybody sees the world their way (philosophically), so the other camp must be wrong and stupid.
The original MIT-licensed program continues to exist and be available regardless of the proprietary versions and embeddings.
A copyleft license just asserts, using copyright power, that such things should not exist.
MIT and BSD licenses just allow certain works to legally exist that copyleft advocates think should not exist. The copyleft is concerned with squelching the existence of things, whereas the MIT and BSD licenses mostly promote existence.
(They are concerned with squelching the existence of plagiarism: an author's name and copyright notice removed from the source code work, and possibly replaced with another. Also, squelching the situation where the compiled work is accompanied by documentation which neglect to give attribution to the presence of that BSD-licensed code.)
> A copyleft license just asserts, using copyright power, that such things should not exist.
Well, a copyleft license asserts that proprietary versions and embeddings of the licensed software should not exist. GPL software doesn't assert anything about the existence of BSD-licensed software. Or at least, not unless you link them together into one thing.
It is true that rms would prefer that such works not exist. (Or that's how he felt originally, at least.) But the GPL is silent on the issue, as it has to be. There's no clause saying "the author promises not to release any software with a non-copyleft license, nor to name a child Dorothy, nor to eat the flesh of an aquatic mammal."
> Here is the rub: free software permits unconditional use.
Why are you using the term "free software" here, when it has a well-defined meaning that is very much what you get with copyleft and the GPL and not what you get with BSD/MIT? I think you mean "open source", specifically open source as opposed to free software. Your terminology makes a lot of the conversation here unnecessarily hard to follow.
> The AGPL restricts use; it is an EULA: end-user license agreement. The antithesis of free software.
I don't see the AGPL as the antithesis of OSS at all, even though I agree that it is activated by a condition that pertains to use, not just redistribution. But that's the mechanism, not the goal. Just like the GPL relies on copyright law to have its effect, AGPL relies on what you're calling a EULA. (I don't disagree, and to me a EULA is a contract, but whether it's exactly the right term doesn't seem important.) GPL isn't alone in depending on copyright; the BSD license does just as much.
> Running a program, as a service or not, isn't redistribution. It is use.
Agreed, but "redistribution" vs "use" is a mechanism argument. The intended purpose of the GPL was to allow a developer to write software whose future evolution is freely shared. The redistribution mechanism doesn't even accomplish this 100%: in particular it allows branchless twigs off of the evolutionary tree as long as they are indeed branchless (i.e., not distributed to anyone else who makes further modifications). That goes counter to the goal of free software, but is an acceptable loss because those twigs are irrelevant to the rest of the evolutionary tree.
But there's a loophole here when the GPL is applied to server software: if the software only runs server-side, then the redistribution mechanism no longer works. You could modify your copy, and give that modified copy to someone else who also modifies it. You would have to share your modifications with that person, but not to anyone else. Your twig can grow branches. Neither of you are redistributing the software to anyone else, so you aren't bound by the GPL to make your changes available to anyone else, and certainly not to the original authors.
The AGPL attempts to plug that hole using an extra mechanism: adding a restriction saying that you have to make your changes available not only if you're redistributing the software, but also if users are talking to the running code[1].
> This is no different from Adobe, Apple, Microsoft, ... identifying people using their software in ways they don't like, and crafting their EULA terms to turn those activities into a license violation.
Sure. Those same companies depend on copyright law as well. But the purpose of the AGPL has nothing to do with people using the software in ways that the license chooser doesn't like; its purpose is wholly concerned with the evolution of the software and therefore the changes being made to it. That purpose is achieved via the mechanism of adding conditions based on usage.
> suppose that some government service website is using AGPL software. What do you gain by downloading the software and running your own instance? That's not where your data is; you can't use that cloned instance to communicate with the service agency.
That is correct. AGPL does not solve this problem. If you're locked into a service, then having the full version of the AGPLed code does you very little good. That is described as "Service as a Software Substitute (SaaSS)" in the AGPL explainer at https://www.gnu.org/licenses/why-affero-gpl.html
The free software folks had to punt on that problem. They "solve" it by saying: don't use those services. Which is hardly a satisfying answer, but nothing else is currently possible. Any solution would require regulation and legislation (eg data portability laws).
> I understand the social problem that the AGPL is trying to combat, whereby visitors are held captive by saas applications over which they have no visibility or control.
Incorrect (see above). Though I think some AGPL supporters did (and probably still do) think that the AGPL helps with that. I guess it does, in trivial cases.
> Also one issue is that the AGPL doesn't actually solve anything. Visitors having the source code to my evil saas platform doesn't solve the problem that they're locked to it. It doesn't solve the problem that I can change the code at any time and they cannot. Or that I can shut it down and wipe out their data, or share it with third parties. An AGPL conforming application also need not provide visitors with any way to export their data.
This is all correct. Well, except the first sentence, because the AGPL does solve one thing: it ensures that the evolution of a piece of software is freely accessible.
Or maybe two things, though the second was not part of the original intention afaik: the ElasticSearch/OpenSearch situation. The original author develops something that their business depends on and does not want to end up competing with their own code. AGPL ensures that nobody can take their code, add some features to it, and then win their customers with the enhanced proprietary version. The original author will at least have access to all of the modifications that anybody makes, so competition will need to be on a different basis.
[1] It seems like it would have been more straightforward to keep the AGPL conditions based on redistribution, and say that you have to release your changes to everyone if you distribute your version to anyone. Would that even work? You'd have a transaction from A->B that induces a requirement on A->the world. But it would have avoided making conditions based on use rather than just redistribution. I dunno, IANAL. It would still allow someone to change the version that they're running without releasing the changes, unlike the current AGPL, but that's no worse than the situation with GPL'd client-side software and doesn't seem like a problem worth solving.
https://www.gnu.org/philosophy/free-sw.html#four-freedoms
Straight from the gnu's mouth!
"The freedom to run the program as you wish, for any purpose (freedom 0)."
> But the purpose of the AGPL has nothing to do with people using the software in ways that the license chooser doesn't like
Yes it is. If you wrote a network program, and you specifically don't like the idea that someone can modify it and then host that modified version for users without letting them have the source code, then the AGPL is a tool that nicely expresses your intent.
Licenses don't care about their intent. People analyze what they do and use them accordingly.
For instance, the GPL has turned out to very nicely suit corporate interests. The copyright holder of a GPLed software component has a competitive edge over the licensees. They have to abide by the license and release all their changes, which you can help yourself to; meanwhile, you can have a proprietary version in parallel.
That gnu's mouth spoke 3 other clauses, and finished up with:
> A program is free software if it gives users adequately *all* of these freedoms. [emphasis mine]
>> But the purpose of the AGPL has nothing to do with people using the software in ways that the license chooser doesn't like > > Yes it is. If you wrote a network program, and you specifically don't like the idea that someone can modify it and then host that modified version for users without letting them have the source code, then the AGPL is a tool that nicely expresses your intent.
Ok, let's stick with "The freedom to run the program as you wish, for any purpose". We're talking about running the software here, not modifying it or hosting it. You can run the program as you wish. For any purpose -- what purpose are you claiming is disallowed? "For the purpose of running it on my server without giving out my changes" is not about running it, that's about something incurred as a result of running it. Which is unfortunate, I agree; it would be nicer if all obligations were only incurred when distributing it. But that still doesn't restrict the running part.
But never mind, this is too much of a semantic argument at this point. I was trying to understand why the AGPL bothers you more than the GPL. I get the argument that it triggers a condition based on usage rather than distribution, but given that the condition does not restrict the usage, I'm not sure why you care. Is it a principle? I agree that it feels a little messy, but given my understanding of the core goal of copyleft licenses, it actually feels to me to be pretty close to a minimal encroachment beyond the GPL that still satisfies the original goal of the GPL for server-side software.
> For instance, the GPL has turned out to very nicely suit corporate interests. The copyright holder of a GPLed software component has a competitive edge over the licensees. They have to abide by the license and release all their changes, which you can help yourself to; meanwhile, you can have a proprietary version in parallel.
Yeah, and my previous message didn't adequately cover this part. AGPL+CLA has a purpose and expresses an intent beyond the intent behind GPL. I'm personally more concerned with the evolution of the software I and others release, even if I find this corporate usage of the AGPL somewhat fascinating. If I understand correctly, your philosophical objections to the AGPL aren't based on this corporate scenario either, though?
You care about restrictions on usage and want as few restrictions as possible, so a corporation building upon BSD code internally without releasing changes doesn't bother you. But AGPL does bother you, because that corporation (or any other user) would need to consider the requirements of running that code. Do I have that right? (Or strictly speaking, running and modifying the code, since there are no requirements placed upon just running it if you haven't changed anything.)
On their website, they have a list of nonfree licenses, for which they give reasons.
Several are identified as nonfree because redistributors may not sell the code. Guess what: GNU Affero says you must make the modified code available free of charge. Thus, it should be listed in the nonfree license section for that reasons.
Several are identified as nonfree because they restrict use, such as that the software may not be used for human rights abuses. Oops, GNU Affero has use restrictions.
> For the purpose of running it on my server without giving out my changes" is not about running it, that's about something incurred as a result of running it.
"My changes" could mean making minor changes to integrate it with 500,000 lines of my company's existing proprietary code, as well as third party proprietary code. Oops, that all has to be AGPLed if the combined program has network users. Which is a nonstarter, so such an integration shall not be made.
A GPLed program can be so combined and run for network users; nothing needs to be put under the GPL unless it is redistributed. How on earth can that be wrong, if the GPL allows it?
This is in accordance with Freedom 0.
I have no problem with the GNU Affero license existing, and people deciding that it's the best choice for their project. The problem is it being promoted and encouraged as a free license. People believe it. How could it not be free? Everyone says so, and it's from GNU/FSF.
I think the Mozilla Public License represents another category and should always be evaluated as well. (or the Eclipse Public License or CDDL are similar)
They are less permissive than Apache in that they require contributing back (as in open sourcing changes under same license), but more permissive than AGPL in that you can statically link an MPL licensed library into your project without having to open source your project.
What MPL is missing AFAIK that AGPL does have is requiring making source/changes available when providing the software as a network service.
And re network service, I don't see the MPL tying the requirement to making changes available to a method of distribution.
If you statically link against an LGPLed library, you must also provide your application in an object (not necessarily source) format, so that a user has the opportunity to modify the library and relink the application.
So, relinkability is the key. For some platforms and toolchains that may be impractical but for others not so much.
Many programming languages don't even have the concept of dynamic linking or object files that can be shared.
Without horizontal scaling it's more like a hosted/queryable Lucene.
API compatibility message I can run simple for small setups and scalable for large ones. That's nice and something I strive for in software I build.
That said, we may one day add ES API compatibility if we can :)
It gives the original author the right to relicense your contributions at a moment's notice, to a license you might not agree with. It effectively means that you cannot contribute to the project under fair terms.
A CLA is similar to a EULA in the sense that most people don't care about it and blindly click "Agree", and as such are unaware of the potential consequences. Look at what happened when HashiCorp relicensed its projects. People were outraged. They agreed to the CLA, so they must have known that this could happen. But did they really take the time to understand what they were signing?
As a contributor, you should never agree to a CLA. As the original author, requiring your contributors to sign a CLA sets an extremely bad precedent.
Most code has no real value beyond the time it saves you and its software developer contributors so it should be as liberally licensed as possible. You want to encourage contributions from the widest possible user base which includes developers of closed source software. They are already incentivised into upstreaming their changes to you on a liberal basis.
I had read a lot of conversations, and to be honest it's quite confusing for me the risk acceptance to have AGPL code in my codebase.
If your company has anything to lose, I'm sure it'll have a lawyer and you'll want to consult them on what their risk tolerance is. It's confusing because the license is actually ambiguous, most tech companies aren't willing to accept this ambiguity.
[1] See this opinion by a Google lawyer: https://news.ycombinator.com/item?id=23968783
- Postgres: similar to MIT and BSD license
- Tantivy (via pg_search): MIT
- pgvector: Postgres license, similar to MIT
- DuckDB (via pg_analytics): MIT
- CloudNativePG: Apache-2.0
- pg_cron: Postgres license, similar to MIT
- pg_ivm: Postgres license, similar to MIT
> 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.
it seems they don't realize how ironic that stance is; they themselves are using all this software without paying for it.
When you talk about traction I wonder how many external contributors are you getting ?
That said, we measure traction in terms of users of the product rather than in terms of contributors to the project. We welcome contributions but understand that this is primarily a project led by our company and don't expect any external contribution.
Many developers don’t like to have their freedom to steal to be restricted by such strong terms as those imposed by the AGPL. And that’s a good thing for you, my fellow maintainers. It’s also a great thing for you, dear end-users.
Obviously.
As an analogy it's as if someone was selling you a new car, but neglected to tell you that it doesn't come with a steering wheel or tires.
Be transparent and tell the whole story, don't be sneaky.
TL;DR: Data-plane Apache 2.0, control-plane BSL.
Being such a core component, we want developers to be completely comfortable integrating and deploying the Spice runtime in their applications and services, as well as running Spice in their own infrastructure.
In addition, Spice OSS is built on other great open-source projects like DataFusion and Arrow, both Apache 2.0, and DuckDB (MIT), so being permissively licensed aligns with the fundamental technologies and communities it's built upon.
We expect to release specific enterprise control-plane services, such as our Kubernetes Operator under a license such as BSL.
After reading the rational for v2 for the Linux kernel, Ive always found v3 a bit off putting.
The AGPL's extension just increases any modified code's availability. It's extending the principles behind v2 to networked devices. You gotta share your changes and you can't cleverly avoid it by doing a SaaS instead of selling software/hardware
It doesn't extend the v3 principles (which increase end user's rights). That would be to force companies to allow users to modify and run modified code on the networked device/server (which would be the networked equivalent of a anti-tivoization).
So the AGPL's idea pairs more naturally with v2 in my opinion
(I also disagree with your feelings about the GPLv3, and think you should be using the normal AGPLv3.)
If you need to patch anything due to local requirements like the auth system you need to publish it which doesn't make sense at all.
If you modify an AGPL'd piece of software, but never distribute it outside your org, then your changes don't need to be released outside your org.