Hacker News Reader

Comment by watermelon0 | Hacker News Reader

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?

View on HN

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.

The key part of the AGPL is phrased:

> 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".

The driver would be derived work of Postgres, thus AGPL, and already problematic in use because of that.

IANAL, but as I understand it:

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.

a) is wrong: users are not connecting directly to PG

Why the silent downvotes. If users do not directly use PG it's not an issue.

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).

[1] https://www.microsoft.com/en-us/licensing/learn-more/volume-...

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

I've tried really hard to understand this a few times and yesterday or early today or something I found an interesting thread here: https://news.ycombinator.com/item?id=11354475

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.

Would an extension like citus or timescaledb or opengis be considered a combined work for AGPL purposes?

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.

> Do you need to release as GPL the code of a program runnning on GNU/Linux? The answer is no.

Only because Linux (and perhaps more relevantly glibc) specifically exempts the relevant protocols from the GPL.

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

And you don't read what he wrote:

"... 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.

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.

A) Only if, as part of your service, your users can directly connect to Postgres, side-stepping your app.

B) Nope

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.

So the answer is clearly NO to both questions.

IANAL

a) postgres is not user facing, so no

b) there is no linking (as in compiler linking) between your application and postgres, so no

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.

This article tries to answer that question. https://medium.com/swlh/understanding-the-agpl-the-most-misu...

1) Yes 2) Nope

Reply on news.ycombinator.com