1

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?

Improve this question

1 Answer 1

Reset to default
5

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.

Improve this answer
6
  • 1
    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. Commented Aug 13, 2018 at 18:40
  • @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? Commented Aug 13, 2018 at 19:03
  • 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? Commented Aug 13, 2018 at 19:33
  • Or does code that deploys it not count? Commented Aug 13, 2018 at 19:35
  • 3
    @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. Commented Aug 13, 2018 at 19:53

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.