I love the AGPL. I can't imagine it becoming popular for generic business functionality in library form, but for highly-specialized libraries (in my case scientific with industrial applications) it was everything I was looking for --- not least because automated license scanners flag it and scare potential parasites away. It's also a great choice for complete pieces of software (such as DBs, as in this case) to offer a free tier for communal benefit, provided you're genuinely willing to let the project develop a life of its own if the open source community finds reason to mobilize around it.
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.
I'm actually not a fan of this restrictive license and the even more restrictive contributor license that is in place here which is what enables them to sell closed source versions of the software and potentially close source entirely (as other companies have done). AGPL without this is not very practical for companies as it makes selling commercial licenses impractical and is a bit of a turnoff for commercial users.
> 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?
> 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.
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.
Yes. I think what makes some people unhappy is the perceived inequality: you can do whatever you want with my contributions, but I can't do whatever I want with the software.
But there simply has to be control and restrictions over the use of software for it to be commercially viable (in almost every case).
If you want a closed source license, use a closed source license. Nothing wrong with that; many companies do that. This particular license combination just creates the illusion of openness without most of the benefits for would be contributors.
> 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.
> But there simply has to be control and restrictions over the use of software for it to be commercially viable (in almost every case).
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).
While I agree with you that these are non-commercial, by now many of them have very big commercial backings. Many Postgres core contributors work at Microsoft, AWS, etc. who make billions of dollars selling Postgres-as-a-Service today.
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.
you can also just not accept code contributions from other people
> 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
I'm a fan of AGPL as well, but there's a point of possible confusion for GNU license variants I personally run in to and maybe others as well. It may be worth specifying which variant of the AGPL you are using, e.g. AGPL-3.0-only or AGPL-3.0-or-later.
That's fair. We use AGPLv3. I haven't seen any AGPL project that wasn't using v3, so we decided to keep it short for readability, but you bring up a very good point.
I have no experience with the AGPL, but I really really like the idea of it. However, I get worried when I read takes like Hector Martin's [1]. In essence, he argues that it becomes very easy for the end-user to make even the most trivial of modifications to AGPL code or stuff associated to it and accidentally violate the license's quine requirement.
The best way to avoid any such issue is to contribute changes to the upstream project, which is our goal with the choice of license. We're hoping for a centralized ParadeDB project from which everyone can benefit.
> The best way to avoid any such issue is to contribute changes to the upstream project, which is our goal with the choice of license.
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).
Hector built up a strawman in that bug, and not a very good one. I'm surprised the Gentoo devs were as patient with him as they were, given he kept trying to argue his personal interpretations which are not in line with how the AGPL is generally understood by Gentoo and other distributions. And some of the things he claims are just plain wrong.
Could you elaborate a bit with specifics? I feel both sides are just opining, and I'd love to know where to stand on a license, the main idea of which I love.
The point of an OSS license in these kinds of situations is pretty simple:
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.
Absolutely. As the copyright owners, the authors of the software can always sell permissions to corporations. This allows software to become free. Stallman himself has suggested this to corporations:
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.
> 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.
By default the contributors also hold copyright and need to consent to the separate licensing.
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?
Contributions to a fork could be done under just the AGPL, without any CLAs (also to the original repo, but those won't be accepted). Then the entire fork is effectively AGPL only.
I don't think any original CLAs would apply to the fork, unless the fork owner is the same legal entity/successor as defined in there.
Same goes for the original authors, they'd need CLAs from all fork contributors.
Spreading copyright among as many entities as possible to make relicensing more difficult is not a problem you should "solve". It's a feature of the license. A CLA ensures that contributors will be treated unfairly, and I hope it deters many potential contributors.
Where there is a will, there is a way. Big corporations could use the license and stick to its terms, but no, they don't want to. Better in their view to just take take take and never give. What they don't see however, and what is on no ones quarterly number sheet, is all the talent they don't attract.
The most significant reason there is that the license must be taken under the strictest interpretation without a more specific business level agreement between the two.
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.
No, that's a gross mischaracterization based on ignorance. It only applies to AGPL because it prevents SaaS services. And because it can't be proven that an AGPL app isn't required as part of a SaaS service to function, then it can't be used anywhere in a MAANG shop.
I don't know about ParadeDB, but this was very off-putting for me in case of Minio when they switched to AGPL. If you check their answers to various license questions, they are essentially this: if you use Minio in your stack/product (for profit), then we recommend our commercial license or consult with a lawyer if your use case is covered by AGPL or not.
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.
This feels like dealing with government agencies where you go out of your way to get clarification to make sure you are doing everything correctly, but they refuse to give a clear answer to they can bother you about it later.
Copyright does not have clear answers. Teachers has always wanted a clear answer to "how many pages can I copy from a book", and they usually get the same answer. There is no cleanly defined number of pages, but fair use do exist so they have to apply they own judgement in each case.
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.
The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work.
So, what is 'covered work'? The license says this:
A "covered work" means either the unmodified Program or a work based on the Program.
Do you still think it's clearly written license? To me it's dubious enough that I wanted an explicit answer from the authors of Minio. Failing to get it, I decided to move away from Minio.
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.
this is basically talking about compilers and things like dumping a memory image from gforth or emacs
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
If the output of your program is an copy of minio then it is also covered by AGPL is what that means. I think it's just covering the case where you are redistributing minio in a way such as decompressing and producing the output.
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
The question isn't about modifications to the library/service itself, but whether with other code linking to it in any way is what you have considered a derivative work that should also be covered by the 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.
The "any coupling" logic would also make anything running on Linux GPL, which is definitely not the case. Using background service such as Minio as an unmodified black box for data storage as part of your app is unambiguously not derivative work. If you were to write something like a management UI for Minio and offer it with your hosted Minio service, then I can at least see the argument, although it still doesn't count under my reading of the AGPL.
The "or very definite answers to the question" is important there. Linus has explicitly answered the question, and if you use any of the Linux headers then yes you should release that software under the GPL. Under this circumstance your "which is definitely not the case" is incorrect.
[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).
Nope. That is LGPL. Under (A)GPL if you make a derivative work you have obligations even if you do not modify. 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]
Well that's not Op's question. They're asking "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?" (Minio is basically a FOSS S3) [0]. You're asking about linking, which is covered in the FAQ [1]:
"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."
I'm not sure that interpretation is correct. I don't read the intention that way (but I'd have to reread the licenses on detail to refresh myself before speaking more definitively).
I mean, they have a strong incentive to get you to buy a commercial license. I'm not surprised they're uninterested in giving you free legal advice in service of not paying them.
If you diff them, you'll see the AGPLv3 is essentially the GPLv3 with this extra clause added:
"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.
If connecting over the network doesn't constitute linking in a way that imposes AGPL obligations, then Google's position, or the reason they state for it, (https://opensource.google/documentation/reference/using/agpl...) is simply wrong. No offence, but I'm going to believe their expensive legal team not being able to find a way around this means that your interpretation is not correct.
Ha well, as a lover of spirited conversation I am not at all offended. I'm not telling you you have to use (A)GPL code, I'm just trying to dispel various rumor.
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.
IANAL, but I'd also be worried that even if the project answers your question, maybe any one individual contributor to the project could sue you if they disagree.
Only if the project doesn't have copyright reassignment, of course.
> 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
No and it's spelled out very clearly in the license.
I think the length of this HN discussion is evidence enough that AGPL isn't clear.
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.
It can also be evidence that HN posters have a poor understanding of GPL licenses. Pretty much all these questions are answered in the FAQ [0]. Your guess is as good as mine as to why people continually post random, uninformed, needlessly conservative takes on them instead of just doing a small amount of reading.
The FAQ is not at all clear about this question. #GPLInProprietarySystem says that you unconditionally cannot "incorporate GPL-covered software in a proprietary system", although it might be OK to ship a proprietary system that integrates with and depends on GPL software so long as "the two programs remain well separated". How do I know whether a particular API usage qualifies as well separated or not? The only standard described is "like the compiler and the kernel, or like an editor and a shell".
> How do I know whether a particular API usage qualifies as well separated or not?
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.
Again, the FAQ says otherwise. #MereAggregation says that this is "normally" the case, but "if the semantics of the communication are intimate enough" two binaries communicating over a socket may still be one program. Whether they are one program is explicitly left as a question for judges to decide.
Here's how that section starts: "An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media.". Are you distributing a lot of apps on CD-ROMs? Have you heard of Linux distributions? Seems like things are fine!
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.
Sorry but what does "arms length" mean? My software doesn't have arms. Using metaphors full of imagery is cute but essentially meaningless.
> 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.
> 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?
What about when running a wasm component in an AGPL host? Can the compiled wasm file be proprietary? They share the same memory space, but the wasm component is not compiled with the host.
That's the GNU project's interpretation of the license. I don't see how a court couldn't reach a different agreement on what the often discussed "derivative works" section means.
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.
Thats... a really weird and technically inept take on an issue that is not broadly applicable to all object oriented languges, but going with this argument, 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.
I know a lot of this stuff is legally pretty new (though AGPLv3 is almost 17 years old now) and there's not a huge body of case law around it. But--and I'm earnestly asking here--is there case law where courts reach in and modify licenses separate from the authors' explicit intent? It's hard for me to imagine a court doing that, especially with all the reliance interests involved (I use AGPLv3 with the understanding that subclassing requires release, court says no, now my business model is toast).
> 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.
> is there case law where courts reach in and modify licenses separate from the authors' explicit intent
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.
> 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.
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.
Only after people badgered them to remove their claim that anything communicating with Minio gets infected by AGPL immediately. Their compliance page used to claim:
> 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.
https://www.gnu.org/licenses/gpl-faq.en.html
"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."
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.
Github may have it wrong then? Their summary says:
> 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"
At least in the EU there's some precedent where AGPLv3+ won out, though it was through settlement and not judgement (and it's not super clear how contentious the parties were anyway) [0]
"In AGPLv3, what counts as 'interacting with [the software] remotely through a computer network?'"
"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."
No it is not clearly spelled out. So I am wondering why you think it is clear. Perhaps you are misunderstanding the problem that is being raised? I’m not sure.
Note that they can't "take it away" completely. The AGPL ensures that the community AGPL licensed code will always have to be open source, and that anybody else can use it too. So a developer who has contributed to an AGPL codebase cannot be denied access to it. Due to the AGPL license, any code will always be open source and thus the CLA cannot claim exclusivity over the contributed code and prevent its (re)use by the developer in any manner.
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.
Is this actually legally binding? What would be the difference w.r.t. informed consent, between DCOs and the "I have read and accept the terms and conditions" checkboxes from most websites?
It also gives me similar vibes to the Do-Not-Track HTTP header since both can be enabled by default.
DCO is something like "Signed-of-by: me myself <me@example.com>" you have to actively add to your contributions, which is usually a conscious and willful act that is far more complex than blindly ticking a box (or even leaving a pre-ticked box ticked). Since that bar is higher, I think the legal weight should be higher.
CLA-Assistant is also similarly simple to fill out, so that can't be the difference there...
We've looked into the DCO before. It turns out CLAs are more common and easier to deal with, thanks to a tool like cla-assistant.io. We ended up opting for it for the sake of simplicity.
> The AGPL ensures that the community AGPL licensed code will always have to be open source, and that anybody else can use it too.
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.
If your business depends on some form of closed-source codebase, than yes, an AGPL codebase will not suit your need. But from an opensource developer perspective it doesn't matter. For example, if you release your source code under the more freer license (like BSD, MIT or Apache), you can indeed close source your code. But so can others. I can use your source code, add more features to it, and close source it. I would be under no obligation to share my code with you, while also having the right to use your code as I please. This is not so with the AGPL. An AGPL + CLA makes this explicit - a developer has to voluntarily give away this right with a CLA. (And this gives developers some additional leverage).
Unless you define Open Source developer as Hobby only licenses matter. I’m an Open Source developer and I want to be able to use software no matter the situation.
And as a result free software was released to the world which everyone can freely use and modify under the AGPLv3 terms. And unlike permissive open source licenses, only the copyright owners have the right to sell proprietary versions. They maximized freedom and secured a business model in one fell swoop. People are only required to transfer copyright if they want to upstream their code, they can always keep their copyrights by maintaining a fork instead.
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.
Their github repo just says AGPL 3.0. Can you point me to the other constraining terms are? This would be quite interesting (like the "Open Core" people). And when I say "interesting" I don't mean a positive feature.
The project is licensed under AGPL, but outside contributors have to sign away their rights with CLA if they wish to contribute to the main project. It's in CONTRIBUTING.md [1]
> 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.
> 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.
TL;DR: my quick read is that they are trying to do the right thing.
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).
Interesting. I think concerns about legality of contributions are completely understandable.
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.
> 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.
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.
> 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?
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.
But you aren’t assigning copyright, you’re getting a license to bundle the contribution with the rest of the package.
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…
When you contribute code to an AGPLv3 project without a CLA, you are also giving them a license to use your code. The name of that very license is... 'APGLv3'!
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.
Honestly I think this is fine, especially how they've done it. Most CLAs seem to require copyright assignment, but theirs does not. Outside contributors keep their copyright, but grant the company a license to (more or less) do whatever they want with it.
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.
In practice, projects that take this approach do the majority of development in house, and external contributions are small. It makes sense that a company that may have spent several years developing a product can sell commercial licensing. The only alternative way to monetize AGPL works is to provide services and support.
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.
I love single-license-per-project F/OSS companies like Red Hat, but they're rare. I'm attracted to companies who are so committed to F/OSS as a practice that their software is copyleft and they don't require a CLA.
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.
There are clear differences. [Let's say I am not a competitor and Amazonifying them] I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates. I cannot fork AGPL and use it commercially in any reasonable manner.
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.
> I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates.
Strictly speaking you are correct. I concede that from an individual licensee perspective. The scenario I had in my head is under permissive, if the community forks, they would be on par with the original author. Under AGPL+CLA, if the community forks, the original author can sell "usable" licenses but the fork community will be stuck to developing an AGPL-only solution, which is a practical hinderance for the new community gaining any ground at all.
> I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates. I cannot fork AGPL and use it commercially in any reasonable manner.
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.
> 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'?
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.
What happens if you (the contributor) fork the project, make a really great feature in your own fork, make it available as the license requires, then the startup integrates changes from the fork back into their own project. Does this then prevent them from ever changing the license away from AGPL?
Yes. If they do it they will be able to license the form back as AGPL but that wouldn't let them license the new thing under their commercial license (effectively useless commercially). At that point they are a peer with you.
Some startups may not know this or knowingly violate this.
> 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).
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.
Firstly, you are wrong. The FSF does not require copyright assignment. It is up to the individual software projects to decide if they require them or not.
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.
> Firstly, you are wrong. The FSF does not require copyright assignment. It is up to the individual software projects to decide if they require them or not.
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 copyright assignment for many (possibly no longer all?) of their own projects
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.
> The FSF requires nothing of the projects; the FSF leaves the choice of copyright assignment up to the project and its maintainers.
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.
Many GNU projects are maintained directly by the FSF/GNU (the same entity; their own statements acknowledge that they share personnel and have no clear boundary between them). And for many more projects they hold the copyright and provide the funding/hosting/etc. and the named maintainer is either a member or affiliated with the FSF/GNU, which suggests they exercise some control over it (e.g. the published hosting requirements for Savannah say that projects they host "should" follow the GNU hosting standards, which include requiring copyright assignment to the FSF if the FSF holds the copyright).
Well, requiring copyright assignment (not just a CLA) is in their published rules for using Savannah, and something almost all major GNU/FSF projects did in the past. Even if it's now something they merely encourage rather than require (and I'd be interested to see a public confirmation of this) my point stands.
Importantly, GPL does not include such line. That line is not part of the GPL. Critical software such as Linux famously do not have that and are not GPLv3 for example.
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."
If I accept their license on 2024-08-14 to use their software, they can do whatever they want to the license after that, but they won't be able to revoke my license to use the code as of 2024-08-14 under the license present to me on 2024-08-14.
No update on the license can retroactively change what I agreed to.
The model is equivalent. Everything else is different.
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.
Organisations that start by claiming to be open-source and rug-pulling are something to be wary of. But neither AGPL nor CLAs are a particular red flag for that. Plenty of well-behaved organisations use CLAs or copyright assignments, and plenty of badly-behaved organisations use licenses other than the AGPL (e.g. Redis had a 3-clause BSD-style license but still did the same thing).
Can’t really refute a hypothetical. Is there a polymarket bet for that? I will categorically take the under on your position for any company doing CLA with AGPL. The intent is so glaringly obvious.
Every so often I run through the common set of licenses to double-check which one I want to personally use for my projects (both commercial and for fun), and I always end up back at AGPL. For me, it just strikes the right balance between open-source and restricting corporations from disproportionately profiting off of my labor.
> For me, it just strikes the right balance between open-source and restricting corporations from disproportionately profiting off of my labor.
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.
That sounds proportionate to me. They get to make profits, and I get to use their improvements if they also benefit me.
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.
A gift freely given doesn’t care what the recipient does with the gift. This idea that corporations aren’t legitimate users of GPL software is simply anti-capitalist bitterness. The ability to run a service with GPL software is a feature, not a bug (or “loophole”).
> and restricting corporations from disproportionately profiting off of my labor.
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.
"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?
Nothing. There is no need for consent. Just fork it and respect the agpl. You can do what you want as long as you respect the AGPL. So reselling is allowed.
This is a common misconception. Nothing in the text of the AGPL requires this whatsoever.
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:
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...)
I spent some time reading about static linking and dynamic linking. From the FAQ
> "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"
If I had to guess, if you installed each application in your stack separately, and they simply interacted with each other through API calls, you could consider them "System Libraries" and therefore would not dragged into the AGPL. Example, The OS itself, Node, Postgres, and any other 3rd party applications. As long as you are not distributing them, I think they would count as System Libraries.
> "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"
The System Library exception isn't even needed. The key word in what you've quoted is "linking". If you aren't linking, then you aren't creating a combined derivative work at all.
If true, this license does nothing to mitigate the risk that a user may get locked into contracts they don't like, or the ability to continue to use the software if the developer goes bankrupt or is bought by a competitor.
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.
Even if the (CLA-owning) organization changes the license, the last version available under the AGPL will always be available under the AGPL.
> 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.
> 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 I guess what you are saying is that the business model is that cloud vendors will buy a license, but only if they they want to make changes to the code, but not release those changes.
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.
> So I guess what you are saying is that the business model is that cloud vendors will buy a license, but only if they they want to make changes to the code, but not release those changes.
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.
> The AGPL license permits free use, modification, and distribution of software, provided that distributed, derivative works of the software are released under the same license.
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.
> Here is the rub: free software permits unconditional use.
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.
> can't use the software in certain ways (e.g. use in a binary firmware blob)
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:
Honestly, I'm getting the impression you're too being too rigid with definitions: anchoring too strongly in the incidental specifics of GPL as being "free software" while ignoring its goals.
Nowhere does RMS say that, oh, if the user modified the program, it's okay to limit their freedom to run it in some ways, as long as it's via a license blessed by the GNU project and the FSF, the ultimate arbiters of what is free who can change their minds at any time.
However, in this article, RMS is cheerfully recommending Affero:
Genuine question, how does AGPL restrict use? From my reading of it, it is only ensuring that any modifications to the source code must be made available if you "distribute" the software, where distribution now includes hosting it as a service.
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.
Running a program, as a service or not, isn't redistribution. It is use.
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).
> The AGPL is still about identifying people doing bad things we don't like, except now those people are just running the program.
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.
A EULA needs to be a contract. THe AGPL is clearly not a contract nor does it meet the basic requirements for an enforceable contract in common law countries. Can you show me where I am wrong about this?
> 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.
> A EULA needs to be a contract. THe AGPL is clearly not a contract nor does it meet the basic requirements for an enforceable contract in common law countries. Can you show me where I am wrong about this?
Sorry that was a typo we should have said "do not have the program" (corrected).
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.
It helps in strawman cases when users have the data, and the platform doesn't have social features. For instance, oh, an online photo editor used by the user in isolation, on either local files or easily downloadable files. User doesn't like that instance, so they find the AGPLed source code and run their own, bringing all their files.
(Why, in that situation, would the user be entitled to the custom modifications in that instance they are abandoning? If you don't like that instance for whatever reason, but like the features, tough luck. Code your own.)
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.
Regardless, it can't be the case that the GNU Affero GPL is not a contract, whereas some Microsoft EULA is, or vice versa. They are an instance of exactly the same category.
> 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.
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.
The GPL is not simply about fixing bugs. It's about preventing the existence of versions of the program in which you cannot easily find or fix bugs, and the underlying ideology that they should be no such programs. And not only bugs but deliberate undesirable or malicious behavior. The problem with closed source proprietary software is that you don't know what's hiding in the binaries.
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.
> 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.
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.
I'm still not following - you're talking about restrictions on use, but what restrictions on use does AGPL apply? What can I not do with AGPL software? What are the forbidden activities you reference?
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.
Depending on the license of the proprietary software and who is creating the software derived from both of them, that derivative work could easily be in violation of both licenses. lol
> You cannot combine an AGPL program with proprietary code and operate it, because you cannot release the proprietary code.
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 spent thousands of hours writing code which is under the BSD license. Nice try trying to make the argument about me.
(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.
> 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.
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.
> Running a program, as a service or not, isn't redistribution. It is use.
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.
That's broadcasting. The recipient of a stream can capture the film to create their own .MKV they can further stream or pass on.
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.)
That analogy does not work because in all the cases you describe a copy of the movie ends up with the viewer.
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.
That is false; the license doesn't speak about any such right.
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.
That's not what is in question. Of course if you someone has reason to comply with section 13 of the license, then users who download the code are having the code distributed to them.
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".
Depending on the license of the compiler, yes, the binary is related to the compiler in some way. In practice it literally contains code from the compiler.
The AGPL does not restrict running the program. Only if you run modified versions, things get complicated.
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.
You realize that would create a problem for some organization whose idiot employee combined proprietary code with the AGPLed program and the thing automatically redistributed the whole infringing mess to the world.
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.
I would say that's an unhelpfully misleading statement in the license.
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.
>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.
Only if the user modifies the program.
The remote network interaction provision of the AGPL is conditional.
It also seems to violate criteria #10 of the OSI's Open Source Definition:
> 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.
Agreed. In other words, the terms restrict what you can do when you modify not when you run. It is also not directed at end users (the "EU" of "EULA") but at the developer or sysadmin.
Sure, and you can absolutely use Photoshop, if you paid for it, and promise not to reverse engineer anything.
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.
Copyright covers four rights. The right to copy, the right to modify, the right to distribute, and the right to perform publicly.
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.
It's triggered on use of the modified software. Not just any use but use in such a way that network visitors interact with the software. If you don't use the software that way, the requirement doesn't apply even if you modified it.
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.
Right, but suppose you disappear. The third parties are using code with your modification. Do they have to host anything? They did not modify anything themselves, but there is no upstream any more for the exact code they are using.
> The AGPL restricts use; it is an EULA: end-user license agreement. The antithesis of free software.
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.
> 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.
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.
Firstly, GPLed programs with proprietary modifications can easily be trapped inside single organizations.
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.)
> 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.
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."
It's my understanding that the MIT license has no such restriction on publishing modifications. The only restriction is that existing code must stay MIT licensed.
I think you're 90% right in what you say here and in following comments, but I think you're skewing things in a way where I end up disagreeing with your conclusions.
> 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.
"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.
> Straight from the gnu's mouth!
>
> "The freedom to run the program as you wish, for any purpose (freedom 0)."
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.)
The main problem is the hypocrisy: the FSF promulgating a non-free license as a free license.
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 totally get this. I recently changed the license on my project from MIT to AGPL after getting a dm from someone interested in buying the project. I make absolutely no money at the moment, if anything I'm paying out of pocket for the domain, and don't think will any time soon. My only goal was to protect the project from getting commercialized by someone else. I've gotten questions about it and have been questioning whether I got too scared that someone might monetize what I worked so hard on.
They looked at 4 licenses (Apache, Business Source License, AGPL, Elastic License) representing different categories.
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.
No, LGPL has specific requirements for static linking. When your product is usually a Go binary that you can publish as is, using an LGPL library makes it tricky.
And re network service, I don't see the MPL tying the requirement to making changes available to a method of distribution.
Static linking with LGPL is possible for proprietary software; the requirements are sometimes misunderstood:
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.
The LGPL is great for software libraries written in C, but doesn't really work for any other programming language. It uses concepts like object files and linking that assumes C. Even in C++ which is closely related you get issues with templates (users can't easily replace that code by their own since it is inlined in the binaries)
Many programming languages don't even have the concept of dynamic linking or object files that can be shared.
We have some API-compatibility in faceted search. But yes, we are not (today) a drop-in replacement for ES. We have many migrations from ES/OpenSearch and users find that converting their code over is well worth the savings in maintenance, no-ETL and increased uptime, though.
That said, we may one day add ES API compatibility if we can :)
is there a place where I can read about what ParadeDB actually does? Surely you do more than just pre-install the extensions? Do you also develop the extensions yourself? Do you support RAG? The last question may not make sense as I am new to this space.
Blog author here. That's fair! We'll add horizontal scaling eventually, but for now, our customers (including some large brands!) have not needed it. Turns you single nodes are remarkably powerful nowadays
Q: What's wrong in having a CLA?
A: It allows you to re-license your project in future.
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.
You have just listed the benefits of having a CLA. This post is about why projects should pick a license not how contributors should prioritise what they spend their time on. If you are trying to build something commercial and be open-source this is a good recommendation.
In short, if you want to appear like a corporation who acts in bad faith, aims to abuse their contributors and only cares about FOSS for the free labor they get from the people who are gullible enough to contribute, a CLA is a great choice for your product!
I’ve been pretty involved in open source projects most of my career. The license you choose should reflect the community you are trying to create. But it probably only makes sense to protect application level code with a copyleft license.
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.
Honest question: For the people not intending to "build a business on top of an open source library" but only intending to do something like "I just need this library to solve an issue in my work job" it's not simple to not touch it at all?
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.
Most major tech companies will ban it for any use because the virality of it isn't clearly bounded and legally it's untested [1]. The stakes are high at large tech companies with valuable IP, so downside is huge. For whatever reason, AGPL has never laid exclusive claim to particularly valuable projects (even in this project's case, it seems like they dual license so you can avoid the AGPL), so the upside isn't that high. So high downside + low upside means major players will just err on the side of "no".
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.
Software products they are using as part their AGPL product are all more permissive, but somehow they consider themselves worthy of monetizing all of this:
That's the point of permissive licences. To allow monetization and redistribution under more restrictive terms, usually proprietary, but also copyleft licenses like AGPL.
And when ParadeDB is harshly criticizing companies that would have otherwise perhaps used their software without paying them:
> 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.
We've had 35 contributors in total on ParadeDB thus far, with 5 of them being core team members.
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.
The AGPL is great, even for business. I make a living from AGPL software. Lots of people generally don't like it, because AGPL was not written to please the largest number of developers, but rather to protect the basic software freedoms of end-users. In a sense, the AGPL guarantees more freedoms, is more free, than other licenses such as MIT/BSD for end-users. But depends on the point of view.
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.
I am not going to debate whether it's "fine", but it's certainly not stealing. If I make someone a beautiful necklace and they sell it in an auction, I might wish they hadn't done that with my gift - but they haven't stolen anything either.
The fact that they aren't mentioning their CLA which gives them extra rights that everyone in the community doesn't get means they're disingenuous in writing this article...
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.
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.
The "Tivo-isation" clause? You'd want AGPL but without that bit? That would be strange. I doubt Linus likes AGPL either because, unfortunately, his relationship with the FSF is always going to be sour. He's one of most stubborn people on earth (for better or worse).
As I say in the neighboring comment, I think the two compliment each other a lot more than v3. Linus would get even more code contributions .. I think he'd be happy
What rationale would that be? I doubt the FSF would write a version of the AGPL designed to let you use DRM to end-run around it if that's what you're getting at (you can always write such a license yourself, but, why?)
I mean ... Not to rehash all the v2 VS v3 arguments ... But essentially you only care about the source code being shared and you don't care about tivoization and forcing additional hardware requirements or requirements that "used code" is changeable by endusers.
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 love the AGPL. I can't imagine it becoming popular for generic business functionality in library form, but for highly-specialized libraries (in my case scientific with industrial applications) it was everything I was looking for --- not least because automated license scanners flag it and scare potential parasites away. It's also a great choice for complete pieces of software (such as DBs, as in this case) to offer a free tier for communal benefit, provided you're genuinely willing to let the project develop a life of its own if the open source community finds reason to mobilize around it.
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!
I'm actually not a fan of this restrictive license and the even more restrictive contributor license that is in place here which is what enables them to sell closed source versions of the software and potentially close source entirely (as other companies have done). AGPL without this is not very practical for companies as it makes selling commercial licenses impractical and is a bit of a turnoff for commercial users.
> 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?
> 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.
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.
Yes. I think what makes some people unhappy is the perceived inequality: you can do whatever you want with my contributions, but I can't do whatever I want with the software.
But there simply has to be control and restrictions over the use of software for it to be commercially viable (in almost every case).
If you want a closed source license, use a closed source license. Nothing wrong with that; many companies do that. This particular license combination just creates the illusion of openness without most of the benefits for would be contributors.
> 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?
> 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.
> But there simply has to be control and restrictions over the use of software for it to be commercially viable (in almost every case).
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).
While I agree with you that these are non-commercial, by now many of them have very big commercial backings. Many Postgres core contributors work at Microsoft, AWS, etc. who make billions of dollars selling Postgres-as-a-Service today.
Those projects aren't inherently commercial, and great software can be built by passionate hobbyists, but often times the two go hand-in-hand
If you need something else, you pay for it.
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!
you can also just not accept code contributions from other people
> 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
Blog author here. I couldn't agree more. Thank you for your kind words and for sharing the academic perspective of using the AGPL - super interesting!
I'm a fan of AGPL as well, but there's a point of possible confusion for GNU license variants I personally run in to and maybe others as well. It may be worth specifying which variant of the AGPL you are using, e.g. AGPL-3.0-only or AGPL-3.0-or-later.
That's fair. We use AGPLv3. I haven't seen any AGPL project that wasn't using v3, so we decided to keep it short for readability, but you bring up a very good point.
AGPL is great; CLAs are not.
I have no experience with the AGPL, but I really really like the idea of it. However, I get worried when I read takes like Hector Martin's [1]. In essence, he argues that it becomes very easy for the end-user to make even the most trivial of modifications to AGPL code or stuff associated to it and accidentally violate the license's quine requirement.
Do you have any insight on this?
[1] https://bugs.gentoo.org/737708
The best way to avoid any such issue is to contribute changes to the upstream project, which is our goal with the choice of license. We're hoping for a centralized ParadeDB project from which everyone can benefit.
> The best way to avoid any such issue is to contribute changes to the upstream project, which is our goal with the choice of license.
This I understand. But it doesn't really address Martin's worry about an accidental modification. Or apparent confusion about what constitutes modification.
There's no accidental 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).
Interesting. Do you have any clarification about which these "many" jurisdictions are? Like, can we expect this to be the case in most of the world?
Hector built up a strawman in that bug, and not a very good one. I'm surprised the Gentoo devs were as patient with him as they were, given he kept trying to argue his personal interpretations which are not in line with how the AGPL is generally understood by Gentoo and other distributions. And some of the things he claims are just plain wrong.
Could you elaborate a bit with specifics? I feel both sides are just opining, and I'd love to know where to stand on a license, the main idea of which I love.
The point of an OSS license in these kinds of situations is pretty simple:
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.
Absolutely. As the copyright owners, the authors of the software can always sell permissions to corporations. This allows software to become free. Stallman himself has suggested this to corporations:
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:
That's so cool that he responded! Thank you for sharing
I thought the point of copyleft was mainly to protect the freedoms of users.
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?
> 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.
By default the contributors also hold copyright and need to consent to the separate licensing.
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.
Thank you!
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?
Contributions to a fork could be done under just the AGPL, without any CLAs (also to the original repo, but those won't be accepted). Then the entire fork is effectively AGPL only. I don't think any original CLAs would apply to the fork, unless the fork owner is the same legal entity/successor as defined in there. Same goes for the original authors, they'd need CLAs from all fork contributors.
Spreading copyright among as many entities as possible to make relicensing more difficult is not a problem you should "solve". It's a feature of the license. A CLA ensures that contributors will be treated unfairly, and I hope it deters many potential contributors.
Where there is a will, there is a way. Big corporations could use the license and stick to its terms, but no, they don't want to. Better in their view to just take take take and never give. What they don't see however, and what is on no ones quarterly number sheet, is all the talent they don't attract.
Which is funny, as enterprise customers have no issue in buying closed source software, but the moment they see a GPL, they lose their mind.
The most significant reason there is that the license must be taken under the strictest interpretation without a more specific business level agreement between the two.
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.
No, that's a gross mischaracterization based on ignorance. It only applies to AGPL because it prevents SaaS services. And because it can't be proven that an AGPL app isn't required as part of a SaaS service to function, then it can't be used anywhere in a MAANG shop.
I don't know about ParadeDB, but this was very off-putting for me in case of Minio when they switched to AGPL. If you check their answers to various license questions, they are essentially this: if you use Minio in your stack/product (for profit), then we recommend our commercial license or consult with a lawyer if your use case is covered by AGPL or not.
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.
This feels like dealing with government agencies where you go out of your way to get clarification to make sure you are doing everything correctly, but they refuse to give a clear answer to they can bother you about it later.
Copyright does not have clear answers. Teachers has always wanted a clear answer to "how many pages can I copy from a book", and they usually get the same answer. There is no cleanly defined number of pages, but fair use do exist so they have to apply they own judgement in each case.
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.
A hilarious sentiment. If it's true, then these companies marketing their OSS creds are merely disguising their desire to be the next Oracle.
Copying reply to a child comment:
"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.
But you forgot to cite the next sentence:
So, what is 'covered work'? The license says this: Do you still think it's clearly written license? To me it's dubious enough that I wanted an explicit answer from the authors of Minio. Failing to get it, I decided to move away from Minio.>Do you still think it's clearly written license?
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
Nice link. One of the key quotes:
> 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.
this is basically talking about compilers and things like dumping a memory image from gforth or emacs
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
If the output of your program is an copy of minio then it is also covered by AGPL is what that means. I think it's just covering the case where you are redistributing minio in a way such as decompressing and producing the output.
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
No, the whole idea of the AGPL is to make you release modifications even if you're not distributing (i.e. a web app). No modifications, no release.
The question isn't about modifications to the library/service itself, but whether with other code linking to it in any way is what you have considered a derivative work that should also be covered by the 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.
The "any coupling" logic would also make anything running on Linux GPL, which is definitely not the case. Using background service such as Minio as an unmodified black box for data storage as part of your app is unambiguously not derivative work. If you were to write something like a management UI for Minio and offer it with your hosted Minio service, then I can at least see the argument, although it still doesn't count under my reading of the AGPL.
The Linux GPL license has an explicit excemption for binaries running under Linux. So it's not a great example.
https://github.com/torvalds/linux/blob/master/LICENSES/excep...
The "or very definite answers to the question" is important there. Linus has explicitly answered the question, and if you use any of the Linux headers then yes you should release that software under the GPL. Under this circumstance your "which is definitely not the case" is incorrect.
[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).
> That is certainly the case for LGPL, but by my understanding it isn't for GPL nor by extension AGPL.
If you don't modify, you have no obligations. Easy.
Nope. That is LGPL. Under (A)GPL if you make a derivative work you have obligations even if you do not modify. 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...
Neither the AGPLv3 nor your link reference "derivative works". It's a GPLv2 concept they jettisoned for (A)GPLv3.
https://softwarefreedom.org/resources/2014/SFLC-Guide_to_GPL...
Well that's not Op's question. They're asking "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?" (Minio is basically a FOSS S3) [0]. You're asking about linking, which is covered in the FAQ [1]:
"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
I'm not sure that interpretation is correct. I don't read the intention that way (but I'd have to reread the licenses on detail to refresh myself before speaking more definitively).
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.
I mean, they have a strong incentive to get you to buy a commercial license. I'm not surprised they're uninterested in giving you free legal advice in service of not paying them.
That isn't what they say though. Their statement reads as “we don't actually fully know how the licence we have chosen works”.
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.
Maybe, but that's more a comment about Minio than AGPLv3.
That's GPL, not AGPL. The AGPL license implies that communicating with it over the network is sufficiently to count as a violation.
If you diff them, you'll see the AGPLv3 is essentially the GPLv3 with this extra clause added:
"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.
If connecting over the network doesn't constitute linking in a way that imposes AGPL obligations, then Google's position, or the reason they state for it, (https://opensource.google/documentation/reference/using/agpl...) is simply wrong. No offence, but I'm going to believe their expensive legal team not being able to find a way around this means that your interpretation is not correct.
Ha well, as a lover of spirited conversation I am not at all offended. I'm not telling you you have to use (A)GPL code, I'm just trying to dispel various rumor.
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.
IANAL, but I'd also be worried that even if the project answers your question, maybe any one individual contributor to the project could sue you if they disagree.
Only if the project doesn't have copyright reassignment, of course.
> 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
No and it's spelled out very clearly in the license.
I think the length of this HN discussion is evidence enough that AGPL isn't clear.
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.
It can also be evidence that HN posters have a poor understanding of GPL licenses. Pretty much all these questions are answered in the FAQ [0]. Your guess is as good as mine as to why people continually post random, uninformed, needlessly conservative takes on them instead of just doing a small amount of reading.
[0]: https://www.gnu.org/licenses/gpl-faq.html
The FAQ is not at all clear about this question. #GPLInProprietarySystem says that you unconditionally cannot "incorporate GPL-covered software in a proprietary system", although it might be OK to ship a proprietary system that integrates with and depends on GPL software so long as "the two programs remain well separated". How do I know whether a particular API usage qualifies as well separated or not? The only standard described is "like the compiler and the kernel, or like an editor and a shell".
> How do I know whether a particular API usage qualifies as well separated or not?
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.
Again, the FAQ says otherwise. #MereAggregation says that this is "normally" the case, but "if the semantics of the communication are intimate enough" two binaries communicating over a socket may still be one program. Whether they are one program is explicitly left as a question for judges to decide.
Here's how that section starts: "An “aggregate” consists of a number of separate programs, distributed together on the same CD-ROM or other media.". Are you distributing a lot of apps on CD-ROMs? Have you heard of Linux distributions? Seems like things are fine!
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.
Sorry but what does "arms length" mean? My software doesn't have arms. Using metaphors full of imagery is cute but essentially meaningless.
> 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.
> 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?
Yep. This is how MySQL/MariaDB work, for example.
What about when running a wasm component in an AGPL host? Can the compiled wasm file be proprietary? They share the same memory space, but the wasm component is not compiled with the host.
Interesting; this sounds to me like linking, but I'd email licensing@fsf.org to be sure.
That's the GNU project's interpretation of the license. I don't see how a court couldn't reach a different agreement on what the often discussed "derivative works" section means.
The FAQ also has interesting takes, where depending on the jurisdiction you're in, I'm sure such views would differ:
Thats... a really weird and technically inept take on an issue that is not broadly applicable to all object oriented languges, but going with this argument, 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.I know a lot of this stuff is legally pretty new (though AGPLv3 is almost 17 years old now) and there's not a huge body of case law around it. But--and I'm earnestly asking here--is there case law where courts reach in and modify licenses separate from the authors' explicit intent? It's hard for me to imagine a court doing that, especially with all the reliance interests involved (I use AGPLv3 with the understanding that subclassing requires release, court says no, now my business model is toast).
> 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.
> is there case law where courts reach in and modify licenses separate from the authors' explicit intent
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.
> 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.
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...
That FAQ covers the GPL, not the AGPL.
If you ctrl-f for AGPL you'll see it's for all of it.
Only after people badgered them to remove their claim that anything communicating with Minio gets infected by AGPL immediately. Their compliance page used to claim:
> 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
https://www.gnu.org/licenses/gpl-faq.en.html "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."
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.
Github may have it wrong then? Their summary says:
> 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"
No, GitHub has it exactly right. Ultimately this sort of thing has to be settled in court.
At least in the EU there's some precedent where AGPLv3+ won out, though it was through settlement and not judgement (and it's not super clear how contentious the parties were anyway) [0]
[0]: https://archive.fosdem.org/2021/schedule/event/agplcomplianc...
Yeah I wouldn't rely on their editorializing. It's best to just refer to the FAQ [0], which covers these questions.
[0]: https://www.gnu.org/licenses/gpl-faq.html
"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.
You linked a more general FAQ for the GPL. Would you have a more specific quote or link for interactions with AGPL code?
"In AGPLv3, what counts as 'interacting with [the software] remotely through a computer network?'"
"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...
Thank you!
AFAIK, the difference between AGPL is GPL is on what constitutes "distribution"; what constitutes a "derivative" is still the same.
https://drewdevault.com/2020/07/27/Anti-AGPL-propaganda.html
Thank you!
No it is not clearly spelled out. So I am wondering why you think it is clear. Perhaps you are misunderstanding the problem that is being raised? I’m not sure.
Is it? Doesn't it depend on whether your stack depends on it to function, or if it is standalone that your stack can connect to but doesn't rely on?
Correction: they chose AGPL with a poison pill (CLA) so they can benefit from it and take it away whenever they want more.
Note that they can't "take it away" completely. The AGPL ensures that the community AGPL licensed code will always have to be open source, and that anybody else can use it too. So a developer who has contributed to an AGPL codebase cannot be denied access to it. Due to the AGPL license, any code will always be open source and thus the CLA cannot claim exclusivity over the contributed code and prevent its (re)use by the developer in any manner.
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.
You don't need CLA for legal protection, Developer certificate of origin is enough. https://en.m.wikipedia.org/wiki/Developer_Certificate_of_Ori...
Is this actually legally binding? What would be the difference w.r.t. informed consent, between DCOs and the "I have read and accept the terms and conditions" checkboxes from most websites?
It also gives me similar vibes to the Do-Not-Track HTTP header since both can be enabled by default.
DCO is something like "Signed-of-by: me myself <me@example.com>" you have to actively add to your contributions, which is usually a conscious and willful act that is far more complex than blindly ticking a box (or even leaving a pre-ticked box ticked). Since that bar is higher, I think the legal weight should be higher.
CLA-Assistant is also similarly simple to fill out, so that can't be the difference there...
The linux kernel relies upon one, so I can't imagine it wouldn't be.
We've looked into the DCO before. It turns out CLAs are more common and easier to deal with, thanks to a tool like cla-assistant.io. We ended up opting for it for the sake of simplicity.
It's not a good argument, smoking was once very common and still is common in many parts of the world.
https://drewdevault.com/2018/10/05/Dont-sign-a-CLA.html
You can use DCO legal text with CLA Assistant though!
> The AGPL ensures that the community AGPL licensed code will always have to be open source, and that anybody else can use it too.
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.
If your business depends on some form of closed-source codebase, than yes, an AGPL codebase will not suit your need. But from an opensource developer perspective it doesn't matter. For example, if you release your source code under the more freer license (like BSD, MIT or Apache), you can indeed close source your code. But so can others. I can use your source code, add more features to it, and close source it. I would be under no obligation to share my code with you, while also having the right to use your code as I please. This is not so with the AGPL. An AGPL + CLA makes this explicit - a developer has to voluntarily give away this right with a CLA. (And this gives developers some additional leverage).
Unless you define Open Source developer as Hobby only licenses matter. I’m an Open Source developer and I want to be able to use software no matter the situation.
And as a result free software was released to the world which everyone can freely use and modify under the AGPLv3 terms. And unlike permissive open source licenses, only the copyright owners have the right to sell proprietary versions. They maximized freedom and secured a business model in one fell swoop. People are only required to transfer copyright if they want to upstream their code, they can always keep their copyrights by maintaining a fork instead.
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:
Their github repo just says AGPL 3.0. Can you point me to the other constraining terms are? This would be quite interesting (like the "Open Core" people). And when I say "interesting" I don't mean a positive feature.
The project is licensed under AGPL, but outside contributors have to sign away their rights with CLA if they wish to contribute to the main project. It's in CONTRIBUTING.md [1]
> 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.
https://cla-assistant.io/paradedb/paradedb
TL;DR: my quick read is that they are trying to do the right thing.
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).
Interesting. I think concerns about legality of contributions are completely understandable.
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.
> 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.
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.
> 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?
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.
The duplicitous language is a bit slimy here.
"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.
But you aren’t assigning copyright, you’re getting a license to bundle the contribution with the rest of the package.
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…
When you contribute code to an AGPLv3 project without a CLA, you are also giving them a license to use your code. The name of that very license is... 'APGLv3'!
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.
Yes, the CLA says that you give them a license for them to in turn sublicense your code to others in any way they want.
[flagged]
Not requiring a CLA and only requiring a DCO. (IANAL fwiw)
Honestly I think this is fine, especially how they've done it. Most CLAs seem to require copyright assignment, but theirs does not. Outside contributors keep their copyright, but grant the company a license to (more or less) do whatever they want with it.
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.
They can always pay you to sign the CLA… works both ways.
In practice, projects that take this approach do the majority of development in house, and external contributions are small. It makes sense that a company that may have spent several years developing a product can sell commercial licensing. The only alternative way to monetize AGPL works is to provide services and support.
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.
I love single-license-per-project F/OSS companies like Red Hat, but they're rare. I'm attracted to companies who are so committed to F/OSS as a practice that their software is copyleft and they don't require a CLA.
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.
There are clear differences. [Let's say I am not a competitor and Amazonifying them] I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates. I cannot fork AGPL and use it commercially in any reasonable manner.
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.
> I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates.
That part is exactly the same under AGPL, no?
Strictly speaking you are correct. I concede that from an individual licensee perspective. The scenario I had in my head is under permissive, if the community forks, they would be on par with the original author. Under AGPL+CLA, if the community forks, the original author can sell "usable" licenses but the fork community will be stuck to developing an AGPL-only solution, which is a practical hinderance for the new community gaining any ground at all.
> I can keep using a permissively licensed software or a fork of it at the moment they pull the rug and keep using it in the same manner; I just don't get future updates. I cannot fork AGPL and use it commercially in any reasonable manner.
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.
> 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'?
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.
Blog author here -- I couldn't have said it better. If you'd like to meaningfully contribute to the project, we're hiring :)
This.
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.
There is no deception. You are perfectly free to use, modify and redistribute AGPL stuff. You can publish your changes without signing the CLA.
What happens if you (the contributor) fork the project, make a really great feature in your own fork, make it available as the license requires, then the startup integrates changes from the fork back into their own project. Does this then prevent them from ever changing the license away from AGPL?
Yes. If they do it they will be able to license the form back as AGPL but that wouldn't let them license the new thing under their commercial license (effectively useless commercially). At that point they are a peer with you.
Some startups may not know this or knowingly violate this.
> Does this then prevent them from ever changing the license away from AGPL?
No, as long as they either remove the contributed code or distribute it in a way that is compatible with AGPL
> 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).
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.
Firstly, you are wrong. The FSF does not require copyright assignment. It is up to the individual software projects to decide if they require them or not.
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.
> Firstly, you are wrong. The FSF does not require copyright assignment. It is up to the individual software projects to decide if they require them or not.
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 copyright assignment for many (possibly no longer all?) of their own projects
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.
> The FSF requires nothing of the projects; the FSF leaves the choice of copyright assignment up to the project and its maintainers.
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.
What are you talking about? The FSF is not the direct maintainer for any projects, as far as I know. The project maintainers are people.
Many GNU projects are maintained directly by the FSF/GNU (the same entity; their own statements acknowledge that they share personnel and have no clear boundary between them). And for many more projects they hold the copyright and provide the funding/hosting/etc. and the named maintainer is either a member or affiliated with the FSF/GNU, which suggests they exercise some control over it (e.g. the published hosting requirements for Savannah say that projects they host "should" follow the GNU hosting standards, which include requiring copyright assignment to the FSF if the FSF holds the copyright).
And the named maintainer has the right to not require CLA:s for their project. The FSF does not require the maintainer to require CLA:s.
Well, requiring copyright assignment (not just a CLA) is in their published rules for using Savannah, and something almost all major GNU/FSF projects did in the past. Even if it's now something they merely encourage rather than require (and I'd be interested to see a public confirmation of this) my point stands.
> The FSF is in the unique position in that the FSF could change the GPL if they wanted to.
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.
GPL includes a line which allows it to be used under any future version of the GPL.
So if you license under GPLv2, the FSF can create GPLv5 and add whatever clause they like in it.
Importantly, GPL does not include such line. That line is not part of the GPL. Critical software such as Linux famously do not have that and are not GPLv3 for example.
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."
If I accept their license on 2024-08-14 to use their software, they can do whatever they want to the license after that, but they won't be able to revoke my license to use the code as of 2024-08-14 under the license present to me on 2024-08-14.
No update on the license can retroactively change what I agreed to.
> the FSF can create GPLv5 and add whatever clause they like in it.
They cannot add anything to it; the new license has to, IIRC, be substantially similar in spirit.
That is only if the license of that software says they can use later versions of GPL; it is not automatic.
The model is equivalent. Everything else is different.
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.
Organisations that start by claiming to be open-source and rug-pulling are something to be wary of. But neither AGPL nor CLAs are a particular red flag for that. Plenty of well-behaved organisations use CLAs or copyright assignments, and plenty of badly-behaved organisations use licenses other than the AGPL (e.g. Redis had a 3-clause BSD-style license but still did the same thing).
Can’t really refute a hypothetical. Is there a polymarket bet for that? I will categorically take the under on your position for any company doing CLA with AGPL. The intent is so glaringly obvious.
Every so often I run through the common set of licenses to double-check which one I want to personally use for my projects (both commercial and for fun), and I always end up back at AGPL. For me, it just strikes the right balance between open-source and restricting corporations from disproportionately profiting off of my labor.
> For me, it just strikes the right balance between open-source and restricting corporations from disproportionately profiting off of my labor.
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.
That sounds proportionate to me. They get to make profits, and I get to use their improvements if they also benefit me.
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.
Do you intend for companies to use your software, just not resell it? Or do you not even want them to use it?
A gift freely given doesn’t care what the recipient does with the gift. This idea that corporations aren’t legitimate users of GPL software is simply anti-capitalist bitterness. The ability to run a service with GPL software is a feature, not a bug (or “loophole”).
> and restricting corporations from disproportionately profiting off of my labor.
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.
It can't be anti and off topic at the same time.
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.
> Corporations have provided more value to the world than any person
If by value you mean: "have increased gini coefficient", then yes, corporations have done that.
I don't understand why they say
"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?
Nothing. There is no need for consent. Just fork it and respect the agpl. You can do what you want as long as you respect the AGPL. So reselling is allowed.
I think AGPL requires the whole cloud stack that's used by a deployment of this SW to be AGPLed as well.
This is a common misconception. Nothing in the text of the AGPL requires this whatsoever.
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...)
I spent some time reading about static linking and dynamic linking. From the FAQ
If I had to guess, if you installed each application in your stack separately, and they simply interacted with each other through API calls, you could consider them "System Libraries" and therefore would not dragged into the AGPL. Example, The OS itself, Node, Postgres, and any other 3rd party applications. As long as you are not distributing them, I think they would count as System Libraries.The System Library exception isn't even needed. The key word in what you've quoted is "linking". If you aren't linking, then you aren't creating a combined derivative work at all.
Linking in this context refers to a very specific thing: https://en.wikipedia.org/wiki/Linker_(computing)
If true, this license does nothing to mitigate the risk that a user may get locked into contracts they don't like, or the ability to continue to use the software if the developer goes bankrupt or is bought by a competitor.
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.
Even if the (CLA-owning) organization changes the license, the last version available under the AGPL will always be available under the AGPL.
> 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.
> 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 I guess what you are saying is that the business model is that cloud vendors will buy a license, but only if they they want to make changes to the code, but not release those changes.
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.
> So I guess what you are saying is that the business model is that cloud vendors will buy a license, but only if they they want to make changes to the code, but not release those changes.
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.
Correct title would be „Why we picked dual licensing with AGPL and a commercial license“, IMHO.
You can only contribute when you accept the CLA at [1] which gives them the right to license your contributions under said commercial license.
[1] https://cla-assistant.io/paradedb/paradedb
you can fork it tho. this way you don't need to accept the CLA, you're just obligated to publish your mods if need be.
It's AGPL for you but arbitrary relicensing at will for them:
https://github.com/paradedb/paradedb/blob/dev/CONTRIBUTING.m...
They put in the effort to create the product. It's their choice how to license it.
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.
ParadeDB seems to be thin glue over preexisting Postgres extensions and C / Rust libraries.
They are free to license that glue however they please, within the legal limits.
I fully support ParadeDB's decision. For an open-source software company, AGPLv3 + Dual License is the most sensible choice.
If you go with Apache 2.0, you're literally doing free work for cloud vendors.
> The AGPL license permits free use, modification, and distribution of software, provided that distributed, derivative works of the software are released under the same license.
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.
> Here is the rub: free software permits unconditional use.
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.
> can't use the software in certain ways (e.g. use in a binary firmware blob)
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:
https://en.wikipedia.org/wiki/Ōoka_Tadasuke#Famous_cases
Honestly, I'm getting the impression you're too being too rigid with definitions: anchoring too strongly in the incidental specifics of GPL as being "free software" while ignoring its goals.
The GPL promotes the four essential freedoms posted on the GNU/FSF website. They are not incidental.
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...
Nowhere does RMS say that, oh, if the user modified the program, it's okay to limit their freedom to run it in some ways, as long as it's via a license blessed by the GNU project and the FSF, the ultimate arbiters of what is free who can change their minds at any time.
However, in this article, RMS is cheerfully recommending Affero:
https://www.gnu.org/philosophy/who-does-that-server-really-s...
Genuine question, how does AGPL restrict use? From my reading of it, it is only ensuring that any modifications to the source code must be made available if you "distribute" the software, where distribution now includes hosting it as a service.
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.
Running a program, as a service or not, isn't redistribution. It is use.
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).
> The AGPL is still about identifying people doing bad things we don't like, except now those people are just running the program.
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 AGPL is absolutely a EULA.
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.
A EULA needs to be a contract. THe AGPL is clearly not a contract nor does it meet the basic requirements for an enforceable contract in common law countries. Can you show me where I am wrong about this?
> 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.
> A EULA needs to be a contract. THe AGPL is clearly not a contract nor does it meet the basic requirements for an enforceable contract in common law countries. Can you show me where I am wrong about this?
https://perens.com/2017/05/28/understanding-the-gpl-is-a-con...
Sorry that was a typo we should have said "do not have the program" (corrected).
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.
> The ability to set up your own clone instance its completely meaningless
Isn't that the whole point?
Yes. But that point doesn't help the users since they don't have the data.
It helps in strawman cases when users have the data, and the platform doesn't have social features. For instance, oh, an online photo editor used by the user in isolation, on either local files or easily downloadable files. User doesn't like that instance, so they find the AGPLed source code and run their own, bringing all their files.
(Why, in that situation, would the user be entitled to the custom modifications in that instance they are abandoning? If you don't like that instance for whatever reason, but like the features, tough luck. Code your own.)
Why would the user be entitled to the commercial SAAS platform's custom modifications?
Because the platform provider didn't pay for the database's commercial license.
> A EULA needs to be a contract.
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.
which is exactly what a contract is.
It's an agreement between different parties.
Regardless, it can't be the case that the GNU Affero GPL is not a contract, whereas some Microsoft EULA is, or vice versa. They are an instance of exactly the same category.
It might be a ULA, but it's hardly an EULA. The party hosting a web service is not an end user. The end user is that party's customer.
> 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.
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.
The GPL is not simply about fixing bugs. It's about preventing the existence of versions of the program in which you cannot easily find or fix bugs, and the underlying ideology that they should be no such programs. And not only bugs but deliberate undesirable or malicious behavior. The problem with closed source proprietary software is that you don't know what's hiding in the binaries.
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.
> 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.
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.
I'm still not following - you're talking about restrictions on use, but what restrictions on use does AGPL apply? What can I not do with AGPL software? What are the forbidden activities you reference?
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.
> which is also the case with GPLv2
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.
>You cannot change it and run it yourself, without hosting the source 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.
Well no, someone combining the proprietary code with the AGPL code infringes if they run that code such that it is exposed to visitors.
Depending on the license of the proprietary software and who is creating the software derived from both of them, that derivative work could easily be in violation of both licenses. lol
> You cannot combine an AGPL program with proprietary code and operate it, because you cannot release the proprietary code.
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.
>> What can I not do with AGPL software?
> 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 spent thousands of hours writing code which is under the BSD license. Nice try trying to make the argument about me.
(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.
> Yes, a free software license must not require people to "contribute back", or anything of the sort.
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."
> 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.
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.
> Please enlight us about how the BSD license do it much better in this area.
It doesn't, but it's a starkly free license which lets you do almost anything you want, short of plagiarism.
> should restrict even more
Nope; I'm explaining that it's ineffective against the key harms that may be perpetrated by SaaS. No license is; licensing is the wrong tool.
> Running a program, as a service or not, isn't redistribution. It is use.
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.
> They're both redistributing
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.
That's broadcasting. The recipient of a stream can capture the film to create their own .MKV they can further stream or pass on.
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.)
That analogy does not work because in all the cases you describe a copy of the movie ends up with the viewer.
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.
> Running a program, as a service or not, isn't redistribution. It is use.
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.
The admin uses the software, regardless of who else is regarded as a user.
Among the users, the admin is the one saddled with use restrictions by the license.
The users of the software (not just the admin who is serving the software over a network) has the right under AGPL to request for the source.
That is false; the license doesn't speak about any such right.
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).
So when you compile a program and distribute over the network as a binary, you are also distributing the compiler that created the binary?
From section 13 of the license (https://www.gnu.org/licenses/agpl-3.0.en.html):
> 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.
That's not what is in question. Of course if you someone has reason to comply with section 13 of the license, then users who download the code are having the code distributed to them.
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".
Depending on the license of the compiler, yes, the binary is related to the compiler in some way. In practice it literally contains code from the compiler.
The AGPL does not restrict running the program. Only if you run modified versions, things get complicated.
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.
You realize that would create a problem for some organization whose idiot employee combined proprietary code with the AGPLed program and the thing automatically redistributed the whole infringing mess to the world.
Even if there were safeguards against such a situation, someone would blow past them.
> The antithesis of free software.
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!
My comment was about the AGPL, not about the GPL.
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.
AGPL doesn't restrict use:
"You are not required to accept this License in order to receive or run a copy of the Program."
I would say that's an unhelpfully misleading statement in the license.
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.
I looked at the context of this.
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.
>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.
Only if the user modifies the program.
The remote network interaction provision of the AGPL is conditional.
Clause 13 could as well require the provider to offer the code to the network visitors even if the code is not modified.
That makes hardly any difference.
Thank you for pointing this out.
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.
And others.
https://news.ycombinator.com/item?id=24861043
It also seems to violate criteria #10 of the OSI's Open Source Definition:
> 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.
> The AGPL restricts use; it is an EULA
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.
Agreed. In other words, the terms restrict what you can do when you modify not when you run. It is also not directed at end users (the "EU" of "EULA") but at the developer or sysadmin.
Sure, and you can absolutely use Photoshop, if you paid for it, and promise not to reverse engineer anything.
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.
Copyright covers four rights. The right to copy, the right to modify, the right to distribute, and the right to perform publicly.
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.
It's triggered on use of the modified software. Not just any use but use in such a way that network visitors interact with the software. If you don't use the software that way, the requirement doesn't apply even if you modified it.
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.
Nope. Section 10:
> 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.
Right, but suppose you disappear. The third parties are using code with your modification. Do they have to host anything? They did not modify anything themselves, but there is no upstream any more for the exact code they are using.
> The AGPL restricts use; it is an EULA: end-user license agreement. The antithesis of free software.
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.
> 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.
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.
Firstly, GPLed programs with proprietary modifications can easily be trapped inside single organizations.
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.)
> 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.
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."
It's my understanding that the MIT license has no such restriction on publishing modifications. The only restriction is that existing code must stay MIT licensed.
Code lacks agency. It's not a person.
I think you're 90% right in what you say here and in following comments, but I think you're skewing things in a way where I end up disagreeing with your conclusions.
> 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.
When I'm using the term "free software", I mean this:
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.
> Straight from the gnu's mouth! > > "The freedom to run the program as you wish, for any purpose (freedom 0)."
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.)
The main problem is the hypocrisy: the FSF promulgating a non-free license as a free license.
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 totally get this. I recently changed the license on my project from MIT to AGPL after getting a dm from someone interested in buying the project. I make absolutely no money at the moment, if anything I'm paying out of pocket for the domain, and don't think will any time soon. My only goal was to protect the project from getting commercialized by someone else. I've gotten questions about it and have been questioning whether I got too scared that someone might monetize what I worked so hard on.
“protect”? What harm is done by more people using your software?
None. I made it for people to use and open sourced for people to see and contribute. I just don't want someone else to sell it. That's it.
They looked at 4 licenses (Apache, Business Source License, AGPL, Elastic License) representing different categories.
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.
LGPL also allows that.
What MPL is missing AFAIK that AGPL does have is requiring making source/changes available when providing the software as a network service.
No, LGPL has specific requirements for static linking. When your product is usually a Go binary that you can publish as is, using an LGPL library makes it tricky.
And re network service, I don't see the MPL tying the requirement to making changes available to a method of distribution.
Static linking with LGPL is possible for proprietary software; the requirements are sometimes misunderstood:
https://www.gnu.org/licenses/gpl-faq.html#LGPLStaticVsDynami...So, relinkability is the key. For some platforms and toolchains that may be impractical but for others not so much.
The LGPL is great for software libraries written in C, but doesn't really work for any other programming language. It uses concepts like object files and linking that assumes C. Even in C++ which is closely related you get issues with templates (users can't easily replace that code by their own since it is inlined in the binaries)
Many programming languages don't even have the concept of dynamic linking or object files that can be shared.
Good point. I am used to thinking in terms of thinks that are dynamically linked.
> Elasticsearch alternative built on Postgres
Without horizontal scaling it's more like a hosted/queryable Lucene.
A key issue for me is API compatibility. It's nice to do simple and scalable, but you can't have both at once.
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.
doesn't look like the case here as they don't even have an API (to be drop-in replacement for ES)
We have some API-compatibility in faceted search. But yes, we are not (today) a drop-in replacement for ES. We have many migrations from ES/OpenSearch and users find that converting their code over is well worth the savings in maintenance, no-ETL and increased uptime, though.
That said, we may one day add ES API compatibility if we can :)
is there a place where I can read about what ParadeDB actually does? Surely you do more than just pre-install the extensions? Do you also develop the extensions yourself? Do you support RAG? The last question may not make sense as I am new to this space.
Blog author here. That's fair! We'll add horizontal scaling eventually, but for now, our customers (including some large brands!) have not needed it. Turns you single nodes are remarkably powerful nowadays
This resonated with us as well, we have also chosen AGPL as license for our open source project - https://github.com/patched-codes/patchwork
Please do not use the AGPL as a marketing point when you have a CLA.
What's wrong in having a CLA? It allows you to re-license your project in future.
Q: What's wrong in having a CLA? A: It allows you to re-license your project in future.
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.
You have just listed the benefits of having a CLA. This post is about why projects should pick a license not how contributors should prioritise what they spend their time on. If you are trying to build something commercial and be open-source this is a good recommendation.
In short, if you want to appear like a corporation who acts in bad faith, aims to abuse their contributors and only cares about FOSS for the free labor they get from the people who are gullible enough to contribute, a CLA is a great choice for your product!
I’ve been pretty involved in open source projects most of my career. The license you choose should reflect the community you are trying to create. But it probably only makes sense to protect application level code with a copyleft license.
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.
Honest question: For the people not intending to "build a business on top of an open source library" but only intending to do something like "I just need this library to solve an issue in my work job" it's not simple to not touch it at all?
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.
Most major tech companies will ban it for any use because the virality of it isn't clearly bounded and legally it's untested [1]. The stakes are high at large tech companies with valuable IP, so downside is huge. For whatever reason, AGPL has never laid exclusive claim to particularly valuable projects (even in this project's case, it seems like they dual license so you can avoid the AGPL), so the upside isn't that high. So high downside + low upside means major players will just err on the side of "no".
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
Software products they are using as part their AGPL product are all more permissive, but somehow they consider themselves worthy of monetizing all of this:
- 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
That's the point of permissive licences. To allow monetization and redistribution under more restrictive terms, usually proprietary, but also copyleft licenses like AGPL.
And when ParadeDB is harshly criticizing companies that would have otherwise perhaps used their software without paying them:
> 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.
First title is a bit misleading. ParadeDB is Open Core, which uses AGPL for Open Source version.
When you talk about traction I wonder how many external contributors are you getting ?
We've had 35 contributors in total on ParadeDB thus far, with 5 of them being core team members.
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.
The AGPL is great, even for business. I make a living from AGPL software. Lots of people generally don't like it, because AGPL was not written to please the largest number of developers, but rather to protect the basic software freedoms of end-users. In a sense, the AGPL guarantees more freedoms, is more free, than other licenses such as MIT/BSD for end-users. But depends on the point of view.
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.
Using a gift freely given isn’t stealing. Just as all other forms of copying data are not stealing.
Obviously.
"freedom to steal"?
Steal from the users of the software, yes. It's not about developers, it was never really about developers if we're talking copyleft licenses.
MIT/BSD and similar ones.
I don't know what you mean.
BSD/MIT allows you to take code without any obligation to contribute back.
Using code that is freely given is not in any sense stealing.
Only if you think taking the work of others and profiting from it without contributing anything back is fine.
The people who did the work obviously think it's fine, otherwise they wouldn't have licensed it under such a permissive licence.
Certainly. MIT/BSD more or less says: steal away (but retain this license notice). In some cases that's desirable.
Is it stealing if somebody gives you a present and you accept it?
I am not going to debate whether it's "fine", but it's certainly not stealing. If I make someone a beautiful necklace and they sell it in an auction, I might wish they hadn't done that with my gift - but they haven't stolen anything either.
The fact that they aren't mentioning their CLA which gives them extra rights that everyone in the community doesn't get means they're disingenuous in writing this article...
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.
The analogy is a bit strong. You make it sound like the CLA is a limitation to the product. But the CLA doesn't't limit the product in any way.
We chose Apache 2.0 for the Spice OSS runtime.
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.
[1] https://github.com/spiceai/spiceai
Is there some AGPL equivalent on top of GPLv2 instead of GPLv3
After reading the rational for v2 for the Linux kernel, Ive always found v3 a bit off putting.
The "Tivo-isation" clause? You'd want AGPL but without that bit? That would be strange. I doubt Linus likes AGPL either because, unfortunately, his relationship with the FSF is always going to be sour. He's one of most stubborn people on earth (for better or worse).
As I say in the neighboring comment, I think the two compliment each other a lot more than v3. Linus would get even more code contributions .. I think he'd be happy
What rationale would that be? I doubt the FSF would write a version of the AGPL designed to let you use DRM to end-run around it if that's what you're getting at (you can always write such a license yourself, but, why?)
I mean ... Not to rehash all the v2 VS v3 arguments ... But essentially you only care about the source code being shared and you don't care about tivoization and forcing additional hardware requirements or requirements that "used code" is changeable by endusers.
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
The AGPL is based on the ”Affero GPL”. The Affero GPL v1 (AGPLv1) was based on GPLv2.
(I also disagree with your feelings about the GPLv3, and think you should be using the normal AGPLv3.)
It's a shitty license.
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.
You only need to share those changes with anyone that has access to your modified version.
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.
[dead]