Ask HN: How to be compliant with the AGPL licence?

3 points by movebx101 1 year ago | 1 comment

We’re considering using an AGPL-licensed database tool as part of our saas. AGPL has always felt a bit scary. It’s got a reputation for being “viral” ( in a way that even companies like Google explicitly avoid it in their projects. There’s a lot of FUD and ambiguity around what it means to be compliant — especially for server-side use. I have read about how companies like iText or MinIO that are kind of abusing the licence to get you to pay for a subscription to their services.

Our plan to be compliant is:

Fork the AGPL repo and modify it slightly for our workload

Publish our changes in a public GitHub repo under the same AGPL license (linking the original repo)

Publish that version as an npm package

Use that package in our Node.js server

Add a clear link to the source on our website (in docs or footer)

There’s no private fork — just a clean public repo that exactly matches what we run in production.

Would this be enough to comply with AGPL’s network-use clause? Or do we need to go further, e.g. display the AGPL license explicitly in our app UI, or provide the source in a different way?

Has anyone here dealt with this in production? We want to do the right thing, even if it means to not use the project at all.

pabs3 1 year ago |

If you read the license, it is pretty simple and quite similar to the GPL if you were to ever make your SaaS self-hostable.

You can chose between two options:

1) use the original code unmodified 2) if you modified the code, ensure folks accessing the AGPL software over the network have access to the code for your modified version.

However, different AGPL based vendors might have different license interpretations, so check out their license documentation.

Your plan sounds like it should be compliant though, although you should make sure the link to the source is prominent enough. That said, probably it isn't necessary since database tools generally aren't interacted with by users and thus should not be covered by the network clause: "your modified version must prominently offer all users interacting with it remotely through a computer network (if your version supports such interaction) an opportunity to receive the Corresponding Source of your version".

Also make sure you don't delete any of the commits you deploy, so that users can get access to them no matter how much time has passed.

Also, you might want to consider sending upstream pull requests for the changes you are going to make for your workload, so you can eventually use it unmodified, and just link to the upstream project.

Also, if you have the budget, consider sending upstream donations if they have that option, or otherwise spending employee time on contributing upstream, or both. Also have employees join their community, join their chats/discussions, attend conferences etc.

Also, IANAL, so you probably should get actual legal advice.