I applaud this decision.
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.
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.
If you want to use AGPL software in your project, you're free to relicense under AGPL.
And "user" freedom is more important because we use tenths of millions of SLOC and do development work on a small fraction.
This can be true for a small program on a microcontroller, but 99.9% of FOSS is deployed as part of a big ecosystem.
For each line of code I deploy on production there's 1000 lines of kernel, libraries, daemons, firmware.
As developers, we are 0.1% developers and 99.9% users.
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.
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.
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.
Such is the way of the FSF.
> 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].
[0]: https://seirdy.one/2021/01/27/whatsapp-and-the-domestication...
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]
[1]: https://www.gwern.net/Complement
> 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
"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.
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.
> 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".
This is misleading. All developers are users as well. Having to use closed source services and tools impacts us a lot.
Obviously. But you are using other FOSS directly or indirectly.
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?
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.
"... and I modify it to my needs ..."
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.
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.
a) postgres is not user facing, so no
b) there is no linking (as in compiler linking) between your application and postgres, so no
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.
"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).
[1] https://www.microsoft.com/en-us/licensing/learn-more/volume-...
Only because Linux (and perhaps more relevantly glibc) specifically exempts the relevant protocols from the GPL.
B) Nope
- 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.
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.
> 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 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.
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.
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.
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.
So the answer is clearly NO to both questions.
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.
Am I missing some key point?
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.
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.
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
I'm sure if I'm wrong I will find out very quickly, this is HN after all.
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.)
The Free Software Foundation exists to protect the former at the expense of the latter.
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.
To the detriment of the users of that service--which are the people that the FSF aims to protect.
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.
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.
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.
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.
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)
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.
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.
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.
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.