I would like to see all major SaaSS projects be AGPLv3. End users still have freedom to user, modify, and distribute the software. Cloud providers must share contributions.
That sounds nice in theory, but the reality is also that a lot of more permissively licensed (BSD / Apache) projects now cannot use (most) parts of Grafana / Loki / Tempo anymore, since realistically they won't be able to or want to switch to the AGPL as well (because of all the pain that would incur on others, in turn). That means that basically the whole free code sharing idea goes out of the window, at least in one direction – Grafana can of course still integrate code from more permissively licensed projects into their codebase.
That's kind of the point. The purpose of MIT/BSD is to enable nonfree derivative works; the purpose of the AGPL is to only allow free derivatives. AGPL maximizes freedom by prohibiting further restriction of it; it's a local maxima of "user freedom" as a function of "developer freedom".
If you want to use AGPL software in your project, you're free to relicense under AGPL.
I agree with the substance of what you said, but I'm going to nitpick a bit of wording: what you call "developer freedom" isn't freedom at all, and is more rightly called power.
That seems like splitting hairs for ideological gain.
You might as well describe freedom of movement as power to take someone else's job in another town, or freedom of speech as power to manipulate masses, or freedom to do an abortion as power over the unborn child. Which way the issues are framed says more about the author than the issue.
Software has leverage (one developer, many users at low marginal cost) built-in, but that doesn't make developing non-(A)GPL or even proprietory software a projection of developer's power. Lack of competition is what lets developer's exert power over users, and while copyleft licenses help with that, they're neither required nor sufficient to prevent abuse of power.
At the same time, copyleft doesn't come free (ha), as developers who need to earn a living will choose to work on problems where they can actually extract some profit to compensate for their effort. Not everyone is keen to work for free, or work as much / as hard for free as they would if they could make a living off it. So yes you might get free-er software, but less of it.
Laws exist ideally to limit freedoms whose exercise comes with externalities that end up reducing the freedom for others. These range from freedoms to cause harm to others (steal, assault, enslave), to freedoms to sell food without disclosing ingredients, to freedoms to run a business without transparently reporting financial information. The idea of greater freedoms depending on lesser restrictions is not novel.
> Lack of competition is what lets developer's exert power over users, and while copyleft licenses help with that, they're neither required nor sufficient to prevent abuse of power.
Copyleft/FLOSS alone is a necessary but insufficient measure; I wrote about other measures in a blog post [0].
TLDR: open platforms/standards-driven and implementation-neutral development, implementation diversity, and simplicity are also necessary. Once all that is accomplished, you have a platform that prevents abuse of power: anyone can use any implementation they want, and implementations are simple enough for community members to fork and maintain. All of this prevents vendors from exerting power over users.
> At the same time, copyleft doesn't come free (ha), as developers who need to earn a living will choose to work on problems where they can actually extract some profit to compensate for their effort. Not everyone is keen to work for free, or work as much / as hard for free as they would if they could make a living off it. So yes you might get free-er software, but less of it.
From the article I linked:
> The key to making money with FLOSS is to make software a commoditized complement of other, more profitable services. [1]
> Examples of such services include selling support, customization, consulting, training, managed hosting, hardware, and certifications. Plenty of companies use this approach instead of building proprietary software: Red Hat, Collabora, System76, Purism, Canonical, SUSE, Hashicorp, Databricks, and Gradle are some names that come to mind.
> Managed hosting isn't a basket worth all your eggs if giants like AWS can do the same at a lower price. Being the developer can give an edge in areas like customization, support, and training; it doesn't offer as obvious an advantage when it comes to hosting.
In other words, developers should be paid for service rather than copies of software. AGPL makes it hard to sell copies of software, but doesn't stop you from offering any number of services. This makes sense, since labor is a scarce resource while copies of software require artificially-imposed scarcity to directly bring revenue.
If developers only get paid for selling auxiliary services, no one actually gets paid to write and improve the software, only to sell services. That's a rotten incentive structure.
Most consumer software doesn't in fact need any auxiliary services. It just needs work put in to actually build it, and that work needs to be paid for.
Props to Red Hat for earning money from enterprise clients. That model only works if you have enterprise customers.
Props to System 76 for selling computers. That model only works if you're selling hardware.
My software doesn't need any services or hardware or other auxiliary bullshit, and I'm not going to invent the need for said bullshit just to satisfy some ideologues.
You're not entitled to tell me what kind of software to write or how to license it. Don't like it, write your own FLOSS version, and outcompete me. Don't want to, or can't sustain yourself that way? Then don't tell me that I should, or that I can. Words are cheap.
no one actually gets paid to write and improve the software, only to sell services. That's a rotten incentive structure.
That incentive structure is universal though. A builder also doesn't get paid directly to maintain his toolset, that cost is included in how he charges for his services. A hospital doesn't charge you for the laundry/cleaning services, it's included in their service bill. If a farmer's combine harvester breaks down, he can't just up the price of his wheat twenty-fold to pay for a new one.
There is a market for selling shrink-wrapped software, see e.g. Microsoft, Nintendo, Apple. Invariably these products are proprietary, because Free Software uses a different paradigm: under the free software/open source model, software is a tool, not a product.
> A builder also doesn't get paid directly to maintain his toolset, that cost is included in how he charges for his services
Of course. That's not a problem, because the toolset isn't the builder's product. Their customers don't care about the toolset, they actually want the service. Conversely, most consumer software users don't want or need your services, they just need the software.
Moreover, that toolset you mentioned belongs to that builder only. It's not a resource shared by all the builders in the world, unlike open source software.
It's not surprising that people pontificating about the morality of copyleft vs proprietary don't even seem to understand the basic economic effects of shared ownership like the tragedy of the commons.
> freedom of movement as power to take someone else's job in another town
Freedom of movement is the power to exchange goods and services with anyone.
> freedom of speech as power to manipulate masses
Freedom of speech is only a freedom if it is accompanied by a potential hearer's freedom to block speech. Modern platforms do not let you choose what or who you want to hear. Freedom of speech without freedom to choose your censor is anarchy.
> Lack of competition is what lets developer's exert power over users, and while copyleft licenses help with that, they're neither required nor sufficient to prevent abuse of power.
You are ignoring the freedom to modify/fork, plus the requirement of free documentation.
Quite a quantum leap there from proprietary licenses to "modern platforms".
You're free not to use Facebook, Twitter, et al, you know. There are other, open, platforms. And other closed ones that are decent. Use any of them if you want more control over what you read.
Don't fucking shame people for earning money writing good software. Most of us aren't building evil monopolies.
How does freedom for the user-who-is-not-a-developer to change the source work, then? The FSF fundamentally assumes the user is a developer. Hell, look at the vast majority of the GNU software. I wouldn't say it's at all targeted at not-developer users.
Arguing over which one is “freedom” is a petty exercise in trying to claim the moral high ground. Instead, it’s more objective and accurate to say that GPL and BSD represent two different ideologies, and that the AGPL is definitely designed to promulgate the “GPL” ideology, so that it’s inability to be incorporated into BSD-licensed software is a feature and not a bug from the perspective of the people who choose to license their code as AGPL.
I think you misunderstand the GPL ideology (to use your words).
The idealogy is that proprietary software is wrong, bad, unethical. Software freedom should be available to all.
The copyleft terms of the GPL are a tactic a means to defending software freedom. And to that extent, all the incompatibility with other free licenses are indeed a bug a downside, a hampering of freedom in practice. That downside is accepted because of (and only when it is) the judgment that it is a net gain for software freedom anyway because it frustrates the development of non-free software.
There does not exist any ideology that wants incompatibility between free software licenses. It is a price that some feel should be paid sometimes in order to be incompatible with non-free licenses which are the actual problem.
> If you want to use AGPL software in your project, you're free to relicense under AGPL.
And this condition is the reason that the answer will be "no" every time to using copyleft. Why would anyone ever choose a piece of software which, however you want to twist words, is actually less free in the sense of what it permits and will have less adoption as a result?
I run some websites without ads used by thousands of people and I never intend to monetize them, but I would still avoid these projects solely due to their licensing.
"Are copyleft licenses more or less free than permissive licenses?" is a pathological nothingburger of an argument because there is no substantial point of disagreement, except on priors, which are never discussed.
Take slavery, or indentured servitude. Nobody seriously argues (any more) that laws against these practices decrease freedom, although they technically restrict the freedom of would-be slave owners. Likewise, if "proprietary software is evil" is table stakes, then copyleft licenses are more free, period. There is no argument.
So, actually what we disagree on is "how unethical is proprietary licensing?" Arguing that permissive licenses are more free is really arguing that proprietary software isn't that bad.
Without having that argument, the other one just goes round and round I circles, like it always does.
Without cost or encumbrance, just like I would expect for a physical free book. The book would not be free if I paid nothing for it and now the author has the right to sleep on my couch legally.
An AGPL license comes with more obligations for the one publishing the code, and for others re-using that code.
Against that are more rights for the users of the final code. GPL is predicated on advocating for users' rights over developers. But that comes at the right of developers to re-use as they want.
Which one is more free is very much a matter of perspective. Claims that GPL is a more free license because it is better for users are therefore subjective, or at least subject to a very specific semantic context.
> An AGPL license comes with more obligations for the one publishing the code, and for others re-using that code.
Right, but if you buy/get a book, you can't even re-publish or re-use the content in the first place.
I'm not comparing the AGPL and the GPL. I'm only talking here about the insinuation that the AGPL is somewhat like a book author requiring readers to let them crash their couches. It's not.
They can, they just don't want to because they want to ensure other people can produce non-free work.
Remove the desire to produce non-free work and you can perfectly legally put copylefted code into weakly-licensed free code. Weak licenses don't forbid this. Copyleft licenses don't forbid this. There's no need for anyone to change the license or copyright to combine weak licenses with copyleft licenses.
Copyleft licenses forbid proprietary code. And proprietary licenses forbid a lot of other things.
AGPL can be combined with GPL and vice versa. GPL does not require open-sourcing if it stays on your computer or the computer of your company and its employees. This makes AGPL a much weaker copyleft when on a server.
I don't understand the distinction you're drawing. It sounds like you're saying that "cannot be combined with code under a different license" is meaningfully different from "can be combined with code under a different license, so long as you immediately relicense that code so it's not under a different license anymore". What am I missing?
Because you're misreading it. It doesn't say you have to relicense the code. It just says (A)GPL terms have to apply to both parts of the code. That's not relicensing. You don't need anyone's permission for weakly-licensed code to do that. Weakly-licensed code already allows it, that's why it's a weak license.
Weakly-licensed code also allows to be covered by a proprietary license. Nobody needs to relicense weakly-licensed code to lock it up in any way and apply further restrictions to it, whether they be "good" restrictions like the (A)GPL, where you forbid further restrictions, or "bad" restrictions like a EULA, where you forbid people to look at your modifications or to do further modifications.
Without a copyright transfer agreement in place, only the original author may relicense the code. The permissively licensed parts of the code will stay permissively licensed, but nevertheless may be distributed in combination with copyleft or proprietary code.
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
This only says that the product of such a combination must be licensed as AGPL. The MIT/BSD licenses (with or without the attribution clause) specifically allow being included in larger works under any license, even proprietary, so what are you arguing exactly?
I have an MIT-licensed project called A, currently at version A1. You have an AGPL-licensed project called B. I take some code from B and incorporate it into version A2 of project A. I want to distribute A2 to A's community.
I don't have to relicense A1 to do this, but I do have to distribute A2, and all subsequent versions of A, under the AGPL, effectively "changing the license" of my project.
I realize this usage is informal - licenses cover code, not projects - but jrv's point upthread was that projects do not want to change their working license, which led me to read jordigh's response as somehow asserting that the AGPL was not viral. It's a non sequitur otherwise.
> but the reality is also that a lot of more permissively licensed (BSD / Apache) projects now cannot use (most) parts of Grafana / Loki / Tempo anymore
Doesn't that depend on how they use it? They're only AGPLing their backends. The tools still follow open protocols, so the client libraries can be permissive. I.e. the rest of their project won't be "infected".
I suggest you read more deeply into the legal interpretations; it is not so clear cut as you put it.
A more permissive license is simply incompatible with this project's ideals - they are willing to sacrifice developer convenience for user freedom and prevent corporate theft and bastardization of the codebase into competing products
To be really strict: AGPL only mandates that contributions be shared with the user. The freedom of users is more important than the freedom of developers.
Of course an upstream maintainer can be a user and get the contributions.
Sure, but there might be out-of-band reasons for users to not do that.
For instance, grsecurity will sell you a security-hardening-patched Linux kernel. You, as the user/customer, have the right to take those GPL patches, and share them publicly. But if you do so, grsecurity will blacklist you as a customer, and you won't be able to get any more patches from them.
This just seems like a blatant violation of the license on grsecuritys part. The license requires them to allow people to share the code.
"Technically you could share the code, and then we'll blacklist you" isn't letting people share the code, "technically" their customers can do anything.
This sounds like the reasoning of a petulant elementary school kid, not a professional security company.
It sounds pretty reasonable to be honest, youre allowed to share the code and theres no legal reprocussions for doing so but the company should be able to just stop sending you stuff if you do?
The GPL states that the company isn't allowed to distribute their modifications with those legal repercussions in the first place:
You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice [..] and give any other recipients of the Program a copy of this License along with the Program.
This is section 1 of the GPLv2 [1]. This plainly states that if The Company is distributing their code under GPLv2, their customers are plainly permitted to "copy and distribute verbatim copies of the Program's source code".
Their whole business model is based on a tortuous reading of this part of section 2:
If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
Their claim is that they are shipping their patch set as a separate work from the Linux kernel, so that they're not bound by the requirement that "the distribution of the whole must be on the terms of this License", and they're free to choose whatever license they want for their patch set. However, since their patch set is in no way a separate work on its own, only a lawyer could make that case without blinking.
Didn't that preaty much out grsecurity into (an even bigger) obscurity as no one sane will touch a logic bomb like this, not to mention build their business on it ?
No, developers are not always users. I might be working on an accounting software for a big company and never use it. In that case the (A)GPL guarantees that the company is in control of their data and processes.
The line between user and developer is blurry, especially in the context of software that exposes its configuration entirely as some part of its core function.
> The freedom of users is more important than the freedom of developers.
What exactly is this "freedom" that users are benefiting from? Is this the part where we invoke some negative right? That's called "control".
You have it backwards. The "control" you're speaking of is actually the thing that the AGPL withholds, so if you care about users having freedom but not control, then it's exactly what you want.
I have a question regarding AGPL, that I couldn't answer by Googling or reading the license.
Let's say that Postgres server is licensed under AGPL, and I modify it to my needs. I have a closed source web application, that is publicly accessible, and uses Postgres for storing data.
a) Do I need to publish source code of my version of Postgres?
b) Does my application (which relies on Postgres, and my patches) need to also be under AGPL, and be available in source code form to all my users/visitors?
I'm going to split hairs the other answers don't: you specify you have modified Postgres. My answer is, it entirely depends if your application is considered a "derivative work" of Postgres. This hinges on a couple of things:
- does your application directly include AGPL postgres code in any form (headers, binary, etc etc) to its own source or its own runtime process?
- keep in mind, in answering the above, that your application probably does have to include a postgresql driver of some kind. Is the driver licensed AGPL too? If yes, your answer to the above is probably yes. This was the problem for years with MySQL, because they licensed their driver code GPL along with the actual database code.
- a final consideration that only comes into play if there is genuine ambiguity on the other points: is your application able to perform its functions if Postgresql is missing or swapped out for another database? To the extent it depends on Postgresql functionality, this will sway a jury towards considering it is in fact a derivative work of Postresql. If you on the other hand support 6 different databases and Postgresql is just one of them - it will be much less likely your application is considered a derivative work of it. As I said, this only comes into play if the other factors can't be decided decisively.
Doesn't it also depend to some degree on how much code sits between the user and AGPL code?
IIRC AGPL was created to bypass a thin wrapper frontend type situation. I make a website that takes PDFs, it lets users extract pages. In the backend I'm just running a modified Ghostscript command line and sending back what it makes. From my discussions with other people, this type of direct coupling automation is what is intended to trigger the AGPL. Is this incorrect? If that doesn't trigger it, the 'users interacting with it remotely' clause is all but useless because firewalls and service chains like this are really easy to construct. Not all AGPL software is able to natively run as a server itself.
And if it does trigger it, a simple ToDo CRUD app that relies on a database is pretty much the same thing in my eyes.
It depends on whether a court considers it to legally be a derivative work or not. Some (but not all) circuits apply the "Abstraction, Filtration, Comparison Test", under which thin wrappers should make no difference. Other courts might have their own ways of deciding. The whole area is murky and untested, mainly because companies haven't really hammered out the cases in court.
How is the court venue decided? Is it based on where the copyright holder is based? That just adds a whole other layer of murky, now I can decide whether or not to infringe based on where the project is headquartered :)
Apparently not, it's "either (1) in the district “where the defendant resides” or (2) in the district “where the defendant has committed acts of infringement and has a regular and established place of business.”" That's US specific of course.
> 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
So note the "interacting with it remotely" language isn't specific to just a network connection. So a reasonable interpretation would absolutely be that your users are "interacting remotely" with the PDF tool in the scenario you describe, no matter how many thin layers you put in between.
So this then goes to the question of how a court would decide the boundary ... clearly the connectivity of the internet means nearly every computer and software on earth is theoretically linked by a network. So that is where they would look at how direct the interaction with the AGPL software was, and how critically and specifically dependent on that interaction your software is. If everything a user does gets transformed into a completely different form by the time it hits the AGPL software then they aren't interacting with it remotely - they are interacting with your software remotely and your software is interacting with the AGPL. Similarly, if you could trivially substitute the AGPL for something equivalent and the end user wouldn't notice, that would also argue they aren't really interacting with the AGPL software specifically.
Of course, nothing is really clear until it goes to court, but this my best understanding of current state.
The postgresql driver might be considered derivative work, and thus required to be AGPL as well, because Postgres does not talk some standard protocol that exists outside of it.
But one can modify Postgres without changing the wire protocol, so the driver may be the plain, original one without custom modifications. The AGPL doesn't mandate that the protocol must be ratified by some standards body, only that a "Standard Interface [exists] for which an implementation is available to the public in source code form".
a) Yes, if Postgres is exposed to users for some reason. Your changes to Postgres are a derivative work of the original, and thus covered under the AGPL.
b) No. Your application is not a derivative work of Postgres, any more than it's a derivative work of whatever OS you're using.
The license does not include the phrase "connect directly". It says 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
"interacting with it remotely through a computer network" may include several hops, the text is unclear at this point. And there is precedent for this interpretation, Microsoft uses the same concept (as "multiplexing") in their SQL Server license terms: https://download.microsoft.com/download/3/D/4/3D42BDC2-6725-... (pdf, from [1], should the document link change in the future).
Actually the GPL has special wording to exclude system libraries and headers from the "derivative work" - since the AGPL does not have something similar (why would it?) one would assume that the derivative work of Postgres includes your app, even if you only communicate with Postgres via http requests going through three levels of indirection
reitanqild seems to misunderstand and the other posters fill in with more information.
If the information in that thread is correct and I read it correctly it is totally fine to use an AGPL server that touches connects to a lot of stuff, it won't affect any of that.
Only if you somehow touches the codebase of the AGPL licensed code by modifying it or creating a combined work then the AGPL will take effect in the same way as today - except that allowing access to a running instance over a network will trigger it too, not only distribution of the binaries or the code.
You've started a really interesting discussion, after reading the thread I am no longer surprised why companies are simply banning AGPL-ed software en block.
Dealing with such issues, the risk of being abused by some AGPL-enforcement troll who would try to sue a company because it uses some software that uses some other software that happened to use a driver that talks to API which is served by AGPL-ed application... Just wow.
The sad outcome of this is that decision makers would say: ehh, better use AWS or some commercial software as open source sucks.
Do you need to release as GPL the code of a program runnning on GNU/Linux? The answer is no. The same applies to software interacting with AGPL Postgres using the postgre protocol. If you are AWS and gives access to customers to modified versions of AGPL Postgresql you AWS must release your patches over Postgresql. IANAL and all that jazz, also I'm not that sure about the typical cloud vendor secret sauce that controls automation etc. Most of it it's probably external enough and not covered by AGPL but there might be some exceptions.
Only partially, this is part of the legal mess that is GPL, because if your program is based around standard apis etc. (and not, let's say, deep linux-only stuff and won't work without that ever) then your program is not derivative work.
That's not a GPL-specific issue, that's a copyright law issue. It applies just as much when writing programs for commercial Unix, or indeed OSX or Windows.
Assuming a client has no direct access to the Postgres server, I'd say you neither need to publish your changes to Postgres, nor put the web application under AGPL. Just because your web application uses Postgres as a storage for data, in a way it could also just use SQLite or MariaDB instead, does not make it a "derivative work". #notalawyer
So he has explicitly created derivative work of Postgres, that's not the question at all. The question is whether the conditions of the AGPL for distributing the source would trigger in his case. I would say yes but IANAL.
Just because I create a derivative work of an (A)GPL project does not immediately require me to publish those changes. Only if I distribute the work, I also need to distribute the changes along with it.
While a derivative work of Postgres is created, it is not "distributed" (in the sense of the AGPL). The web application is, which I do not consider a derivative work of Postgres in the general case.
If you implement a feature in Postgres and have a web application that is practically just a wrapper around this one, new feature, then that could be considered a derivative work. But I'd say that's a far stretch.
The AGPL is a free software license. This implies that guarantees the well-known freedoms. Among them, there is the freedom to modify software for your own use.
As long as you don't exposed this modified version of a hypothetical AGPL-ed Postgres to the end users, it is considered your own use, where you are free to do anything you want, including using it as the data store for a web application.
If you would however expose this modified AGPL-ed Postgres as a DBaaS, in this case you will need to offer as AGPL your changes to the users. But this was not your case.
These are good questions. Regarding the premise, you wrote: <<Let's say that Postgres server is licensed under AGPL, and I modify it to my needs.>>
The last part surprised me. For most projects, they don't need to modify the source code of the database engine. They only need to use the database to create a schema and store data.
Can you share more about what you meant by "modify it to my needs"? It would be helpful if you could provide one specific example.
Postgres is designed to be modified and is highly extensible. Many companies add features or capabilities that are not native to Postgres. Some things you can do using extension interfaces (linking in shared libraries) and others require modifying the source. It can get a bit blurry, it really depends on what you are trying to do.
It is not that uncommon to mod Postgres to do something it can’t do out of the box. I’ve been paid to do it many times for companies that use Postgres to make it do just a bit more. This is a pretty valuable and unique property of Postgres; it has many fundamental limitations but a lot of small limitations can be coded around if you are handy with C.
But if my proprietary SaaS only uses Grafana for monitoring but its key purpose is doing something else entirely, I can no longer use Grafana unless I also publish my SaaS under AGPLv3, right?
What if I release my own SaaS as AGPLv3? Do others, who rely on it, also have to license their software under AGPLv3? I think this kills many business cases.
>I can no longer use Grafana unless I also publish my SaaS under AGPLv3, right?
If you link to it directly from your code then yes, unless you're willing to pay Grafana for a commercial license (assuming they offer one or you can negotiate one with them). If you have Grafana running on your servers but you aren't using the code in your own applications then you're generally fine (the GPL is generally recognized as ending where a process ends). And that's the point of the GPL/AGPL, you get the code for free, with the only expectation being that you pass it on if you make any changes.
If your server runs Linux you don't have to distribute the source code of Linux to the users of the services running on it. If Linux was AGPL you would have to. And yet, you would not have to distribute the source of your closed source software running on the server.
You wouldn't, as system interfaces are specifically excluded as an AGPL enforcement domain. But if the Linux kernel was AGPL, you would have to supply the source code to your NFS clients, since those clients would be served directly by the kernel.
The only difference between GPL3 and AGPL3 is what constitutes distribution. With GPL3 you have to provide source to anyone you provide binaries. With AGPL3 you also have to provide source to anyone who uses the software remotely (eg a web app). Everything else, including the scope of what must be included in the source (modifications, linked software, but not software that talks over IPC, etc), is identical between GPL3 and AGPL3.
More specifically, the only difference between GPL and AGPL is section 13 (and the preamble summary). The rest of the license is word-for-word identical (save for the name).
https://www.gnu.org/licenses/agpl-3.0.en.html#section13
To expand on that, you have to offer to provide the source to "all users interacting with it remotely through a computer network". If you're using Grafana for monitoring your SaaSS app, then your users aren't interacting with Grafana, so you're fine.
If your SaaSS app surfaces a few small things from Grafana to the user, do you only have to open source the glue code, or the entire SaaSS application?
The entire application, to the extent that it's a single work under copyright law. If your app is a "mere aggregation" of e.g. grafana administration and other-service-administration components then maybe not.
If you're only using Grafana for monitoring but not distributing it to your users as part of your product then I don't think you need to make your own product AGPL.
I'm sure if I'm wrong I will find out very quickly, this is HN after all.
Certainly they should share - but must stretches things a little far.
Much in the same way as Amazon should provide their low-tech workers with livable conditions - but unless the law and applicable contracts specify otherwise, there's no must about it.
Cloud providers are doing an end run around the intention of the GPL - but not around its legal constraints.
(And before we consider possibilities otherwise, it might be more pertinent to at least attempt to punish companies in blatant violation - like the multitude of router manufactures routinely shipping GPL derived software without reasonable access to source.)
I view the AGPL as a nonfree license; I think more permissive licenses are better, because I believe in software freedom. Companies are right to avoid the AGPL.
You believe in freedom for who, exactly? Freedom for the users of software? Or freedom for corporations who benefit from denying access to the source code of that software?
The Free Software Foundation exists to protect the former at the expense of the latter.
It seems to me that, to defend users against corporations, the FSF as a side effect is attempting to take a whole lot of freedom away from developers who share the ideals of the FSF.
(That is, any developers who publish under MIT / BSD like licenses)
You are dragging anti-corporate ideology into a very simple matter.
Corporations are sometimes users, and individual people often benefit from denying access to the source code of software that is used to provide a service.
Providing a service is fundamentally different from providing software.
There's nothing anti-corporate about it. The AGPL is motivated by the same thing that motivated the original GPL: making sure that users have access to fix bugs in the software they're using, like in the printer driver anecdote.
The AGPL doesn't require you to provide the source for software that you're using to provide a service - only the source for software where the software is the service. A bug in software I use is equally annoying when I'm using that software over a network connection as it is when I'm using it on my local machine.
That's a very simplistic and, I think inaccurate view of the matter.
My customers, for example, to whom I provide service, are not infringed upon in any way because I use private forks of GPL software in the provision of my services.
> My customers, for example, to whom I provide service, are not infringed upon in any way
The issue is that I—and, more importantly, your customers—must simply take your word for it, since we're unable to confirm or deny it for ourselves if you don't make the source available.
When dealing with large corporations, taking such statements at face value is pretty foolish.
This is an interesting point. The original question was what if my database was AGPL, and it's source code was modified. If this database was used as part of a public (cloud-based) web-app, how could end users ever know there is a custom database? You are right: It seems likely that less ethical orgs would just lie and say they use the database unmodified. Thus avoiding the obligation to publish their database modifications as required by AGPL.
They will be when you go out of business and disappear, and they can't compile that same service to run on their own replacement server because you've withheld the source to your modification.
You might not want to admit to yourself that your business model is based on infringing on the freedoms of these users of GPL software, but that's exactly what it is.
This was never an issue until Google was pinched on it five or six years ago and started a massive campaign to get the OSS movement to disfavor the AGPL. Google uses tons of GPL software that they don't pay for (Linux, Java, etc.) but once it became exterior-facing and the license applied to their software, then rather than pay to license the software, the world's fifth most valuable company decided they'd rather stiff the developers by a campaign to convince other companies of what you just posted.
I understand your concern. After Google started the negative press about AGPL, some companies I worked also followed suit. It felt like blind following, as almost none of my software faces the public -- it's mostly internal. In that case, AGPL is no concern. But internal training made a big point about "avoid AGPL... even Google avoids it!" Truly, it was F.U.D. nonsense.
You also wrote: <<Google uses tons of GPL software that they don't pay for (Linux, Java, etc.)>> While that statement may be true on the surface, it belies the fact that Google is either a major, direct contributor to the Linux kernel (and many of its parts). Or: Google is a major sponsor of open source orgs to pay for developers to work on open source projects -- like the Linux kernel.
Also: Are you aware that the Oracle version of Java requires companies to pay license costs when used in a production settings? I cannot say if Google uses a non-Oracle release. But if they do (sometimes) use the Oracle release, I am sure they pay licensing costs. Before you make a claim like that, you should share a source -- one way or the other. One reason why some companies choose to pay the license for Java (instead of using a non-Oracle pure open source release): They want the support when there is a security issue. Example: If you find a bug in the JVM and you are a major customer, then it will be much easier to get support directly from Oracle to release a fix.
I don't know, but I expect that Google uses the OpenJDK release, which is identical to the Oracle JDK except it does not receive paid support from Oracle. I strongly doubt Google which has been fighting Oracle for years about a Java license would be paying Oracle for support. But stranger things have been known to happen!
I would wager that there’s a corner case in Google somewhere where Google is paying Oracle for Java. (After so many acquisitions, it’s essentially inevitable and not all will be eradicated in post-merger integration, especially if the product wasn’t the main driver of the acquisition.)
> Google uses tons of GPL software that they don't pay for (Linux, Java, etc.) but once it became exterior-facing and the license applied to their software, then rather than pay to license the software, the world's fifth most valuable company decided they'd rather stiff the developers by a campaign to convince other companies of what you just posted.
The free in free software is often cited as being "free as in freedom", but it's important to remember that it's also and simultaneously "free as in beer".
Google, along with everyone else, uses tons of GPL software that they don't pay for - because the point of free software is that you're free to use it. They're not "stiff[ing] the developers" as you claim, because the software is available for all to use for free.
You can't have it both ways: either you're free to use the software for any purpose, or by using the software you owe somebody something. Pick one. I choose the former.
Why do I have to pick one? It's not a binary thing. Why can't developers say it's free to use under these circumstances, but not under others? Isn't that precisely the freedom you are otherwise championing?
The only reason Google opposes the AGPL is financial. Read their explanations. So, while you're right that Google is not 'stiffing' the developers whose software they're using, by their campaign against the one license that can be used by developers to make money, they are making the OSS world weaker--especially for programmers from developing countries who don't have the luxury of large blocks of time to write software on the side unless they can benefit from a license like the AGPL.
I would like to see all major SaaSS projects be AGPLv3. End users still have freedom to user, modify, and distribute the software. Cloud providers must share contributions.
This is how I like it.