AGPL - passwords in code

Question

I'm looking at putting up a fan site for an author using code released under the AGPL. Under the AGPL, as I understand it, I would need to publish my code modifications. This is entirely fine.

However, the website is in django. I will probably be deploying with Docker, and forking the project to do so. If I want to automate deployment I will probably need to write code that at least sets some passwords as environment variables or something.

Is the AGPL "contagious"? If so, how do I get around a requirement to make available for download code that contains the private database passwords and such?

Answer 1

Never ever commit secrets to source control. And by extension, never build a container image that includes secrets. Instead, secrets should be provided during deployment, e.g. as environment variables. If you are using some cloud provider, they probably have special tooling to manage keys and other secrets.

If you need to store secrets during development, perhaps use a config file but never commit these files. Instead, explicitly .gitignore them.

Now that you aren't version-controlling any secrets, your repository is already in a publishable state, and complying with the AGPL is easy. The (A)GPL does not force you to make any passwords, API keys, or other secrets publicly available, except under the very limited circumstances that you are embedding (A)GPLv3 software into an embedded device, and such secrets are necessary for installing modified versions on that device.

Recommended reading: The twelve-factor app, a short guide to web app architecture and deployment. Especially consider their definition of configuration and their distinction between build, release, and run phases.

• Arseni Mourzenko: While your answer is technically correct, I'm not fond of the formulation of the first paragraph. There is nothing wrong in committing secrets to source control if those secrets are kept inside a dedicated repository with tight access control. This makes it possible, for instance, to revert to a previous version after a change of a secret broke the deployment. Committing secrets side-by-side with the source code in a public repository is a different subject—I couldn't agree more that this is a very bad idea.
• amon: @ArseniMourzenko You do have a point there – and it is always dangerous to deal in absolutes. But TBH specifically git repositories are really bad credential storage systems. They are so easy to share, you can't really erase old versions, and you can't compartmentalize access within the repository. I think some VCS like Perforce did have better access controls, but who still uses that?
• OrgnlDave: But if I write code that depends on it, it's under the AGPL and I need to release it, even if it has secrets, no?
• OrgnlDave: Or does code that deploys it not count?
• Robert Harvey: @OrgnlDave: In addition, common sense prevails here. The purpose of licenses like the AGPL (broadly speaking) is to encourage code sharing; your private passwords are of no interest to anyone else except bad actors like hackers.