> If I run a public-facing, auth-requiring RethinkDB server, am I obligated to make source available to anyone who connects to it?
Yes, that is precisely what the AGPL means. If you have some proprietary web application that is the user of RethinkDB that your users connect to instead, then no, since the modifications are only used internally by you.
The goal here is to prevent SaaS-ification of AGPL'ed applications, if you host an application under the license and make it available to others you can't hide your changes just because the users aren't directly installing the binaries.
> If my build system sucks (and most build systems do suck), am I legally liable for not providing a working build script that a third party can use, even if every patch I have is in a public bugtracker?
The A/GPL does require you provide the neccesary tooling or instructions to build the source, so, yes.
> In the same way, it's entirely reasonable for organizations to determine that for a specific use case, both simple permissive licenses and GPL-style licenses are fine, but AGPL-style ones aren't.
If you're trying to make money off the backs of GPL'ed software by making modifications to it and then throwing it behind a service so you don't technically have to redistribute your changes then, yes, you should be wary of the AGPL. You should also feel ashamed of yourself.
That being said, there's some projects licensed under the AGPL that have given me pause, like GhostScript. I've had to yank that out of projects, because even though they are used internally-only, we are linking to the code which means the project as a whole becomes AGPL licensed. Things like MongoDB/RethinkDB are non-issues since they are only being accessed over the network, the client can be licensed under whatever they damn well want.
> if you host an application under the license and make it available to others you can't hide your changes just because the users aren't directly installing the binaries.
For the auth-requiring RethinkDB server, am I obligated to provide source to the entire internet because everyone can connect to it?
> The A/GPL does require you provide the neccesary tooling or instructions to build the source, so, yes.
The GPL does not require me to provide build tooling / instructions to people who merely use the product, only recipients of the built code. If I don't distribute it, I'm not obligated to do a good job with my build tooling.
If I port RethinkDB to some proprietary OS where I'm not allowed to redistribute the build tooling, am I effectively forbidden from running it in a public-facing way?
Does that conflict with "the freedom to run the program as you wish, for any purpose"?
I'm fine with being ashamed. None of the four freedoms, none of the requirements of the open source definition, require me not to be ashamed. I'm fine with assuaging my shame by donating money or resources as needed. But the AGPL seems to be constraining my technical decision-making by saying that I either have to put non-AGPL layers in front of AGPL code or I have to use a good-quality, free software build toolchain.
> For the auth-requiring RethinkDB server, am I obligated to provide source to the entire internet because everyone can connect to it?
Anyone who can use it must be granted the source. Whether the ability to open a socket connection counts or not is up for debate. Note, the GPL doesn't require you provide the sources gratis, you can charge reasonable cost of distribution so you aren't eating the bandwidth bill. You could also just provide a link to your github repository.
> The GPL does not require me to provide build tooling / instructions to people who merely use the product, only recipients of the built code. If I don't distribute it, I'm not obligated to do a good job with my build tooling.
>
> If I port RethinkDB to some proprietary OS where I'm not allowed to redistribute the build tooling, am I effectively forbidden from running it in a public-facing way?
With the AGPL users are effectively recipients of the built code. So, yes, if you are unable to provide your build scripts (note, the tools you call to build do not have to be open source, but the instructions/scripts used to build must be) then you are forbidden from using the product.
> Does that conflict with "the freedom to run the program as you wish, for any purpose"?
The A/GPL is designed to protect the freedoms of users, the AGPL changes the definition of user from "the person executing the binary" to "the person interacting with the software". The change of this definition doesn't conflict with that, it clarifies the intent of this freedom when a project chooses the AGPL over the traditional GPL license.
So I think that, if that's how the AGPL defines "user", had RethinkDB continued to be AGPL, I'd be disincentivized from setting up and sysadminning a multi-tenant RethinkDB instance and more incentivized to provide scripts for people to run their own instance.
There are reasons that's good (in theory, users will have more control over their own computing), but also reasons that's bad (you don't get economies of scale, you don't get someone dealing with security updates for you, you probably have to pay more, etc.).
And it seems to me that if we want to encourage designing systems a certain way, a legal document is probably not the tool for it. I think it'd be much better for free software if we spent time building tooling for non-AGPL software to serve its own complete corresponding source by default.
> So I think that, if that's how the AGPL defines "user", had RethinkDB continued to be AGPL, I'd be disincentivized from setting up and sysadminning a multi-tenant RethinkDB instance and more incentivized to provide scripts for people to run their own instance.
Why would it? The AGPL isn't designed to disincentive people from providing hosted services based on a particular piece of software, but to ensure those that do it can't make proprietary modifications that break the spirit of the GPL while technically being in compliance.
You aren't asked to do anything beyond what the GPL already requires, it just defines that users accessing the covered software over the network have the same freedoms as those who instally it locally do.
> There are reasons that's good (in theory, users will have more control over their own computing), but also reasons that's bad (you don't get economies of scale, you don't get someone dealing with security updates for you, you probably have to pay more, etc.).
Again, the AGPL doesn't impair any of these. The only addition to the GPL is you can't turn a GPL'ed program or binary into a "service" and bypass the spirit of the GPL while still being in technical compliance.
Sure, if what you want your differentiation to be is proprietary value-added features then you're going to be in a sore spot - but again, that's breaking the spirit of the license.
> And it seems to me that if we want to encourage designing systems a certain way, a legal document is probably not the tool for it. I think it'd be much better for free software if we spent time building tooling for non-AGPL software to serve its own complete corresponding source by default.
Put it up on github and link to it, it's as simple as that. The GPL and the AGPL don't have overly strict requirements on how the source code is distributed, only that you must make it available. Most AGPL'ed web applications I've seen provide a link in their footer to the source code, if you modify the source you must provide your users a way to gain access to your modifications.
As a note: I'm not some cultist that blindly follows the FSF. I usually prefer BSD/MIT licenses in anything I work on, but as someone who is looking at starting some projects that could potentially be SaaS-ified the AGPL is a very appealing choice in some ways - applications and libraries have different licensing requirements in my eyes, when it comes to a library I just want people to be able to not re-invent the wheel, when it comes to applications I want users of the software and the community around it to not be at risk of a proprietary vendor destroying the community.
It also discourages people from providing hosted services based on a particular piece of software if they are in fact complying with the spirit of the GPL, but just suck at build infrastructure.
In particular, if I have custom patches to RethinkDB, I submit them all upstream, and I'm using some awful in-house build system because that's how everything is required to work at my company, I'm obligated to release the build system, even if any discrepancy between my awful in-house build system and the upstream one is a bug on my end. The one that's actually live is the corresponding source.
In theory this is good, because it means that if my awful in-house build system is, say, picking up some patched high-performance library, I'm obligated to distribute that library too.
In practice, that's much less likely to happen than just not having a great build system that does the same thing as the upstream build process, just worse. A legal obligation to have good build tooling is a weird barrier.
Nobody said it had to be good build tooling, just functional.
You use a 1000 line shell script to do a bunch of shit, that's fine, there's no requirement in the GPL that it has to be "./configure && make && make install" - just that you provide the accompanying scripts used to build the software.
This shouldn't be hard, you shouldn't make it hard on yourself or developers working on your project to create a local build. I honestly don't even see the issue.
Releasing this script would involve releasing a ton of metadata about everything anyone at the company works on.
I have my differences of opinions with our build infrastructure rather frequently, as it happens, but I think it makes it easier to create a local build; you don't have to learn n different build systems for n different upstream projects. But it's a local build designed for developers who are my co-workers, not for the general public.
If you want one script that can build a whole stack then fine, but that doesn't mean you can't keep the tooling separate enough to build each component individually. You use RethinkDB with a bunch of patches? Keep that part in it's own script that gets called by your big one, problem solved.
Yes, that is precisely what the AGPL means. If you have some proprietary web application that is the user of RethinkDB that your users connect to instead, then no, since the modifications are only used internally by you.
The goal here is to prevent SaaS-ification of AGPL'ed applications, if you host an application under the license and make it available to others you can't hide your changes just because the users aren't directly installing the binaries.
> If my build system sucks (and most build systems do suck), am I legally liable for not providing a working build script that a third party can use, even if every patch I have is in a public bugtracker?
The A/GPL does require you provide the neccesary tooling or instructions to build the source, so, yes.
> In the same way, it's entirely reasonable for organizations to determine that for a specific use case, both simple permissive licenses and GPL-style licenses are fine, but AGPL-style ones aren't.
If you're trying to make money off the backs of GPL'ed software by making modifications to it and then throwing it behind a service so you don't technically have to redistribute your changes then, yes, you should be wary of the AGPL. You should also feel ashamed of yourself.
That being said, there's some projects licensed under the AGPL that have given me pause, like GhostScript. I've had to yank that out of projects, because even though they are used internally-only, we are linking to the code which means the project as a whole becomes AGPL licensed. Things like MongoDB/RethinkDB are non-issues since they are only being accessed over the network, the client can be licensed under whatever they damn well want.