So let's get the licensing bit out of the way first. I am 100% confident that you're wrong on this. The GPL is a copyright license and like all copyright licenses, it applies to the work and your rights to copy it. If you choose to copy the contents of a GPL project's code into your own project, the license dictates that you must license your project under the GPL. For example, if you were to build a new kernel for your own special operating system and copy out significant portions of the Linux kernel to do it, your new kernel will be covered by the GPL.

You may be confusing the GPL with the LGPL here, which specifically has an exemption for linking. Under that license, you can link to a GPL project (it's not clear if a Python import would qualify as this was originally written for external modules in C projects) without your project being covered by the GPL.

You're also misunderstanding "distribution" here. While it's true that there's a distinction between the GPL and AGPL in how this word is defined, it does not affect how the license applies. To use another example, the fuzzywuzzy project is GPL-licensed, so if you were to use it in your Django project, it would necessarily make your Django project GPL. However, as "distribution" under the GPL applies only to sharing copies of the project with others and not to services provided over the web, your project will be GPL, but you'll be under no obligation to share the source with anyone unless you were to copy the project onto someone's laptop. So long as your project is just a webserver sending HTML to the user, you're under no obligation to share the source code for your server.

The AGPL on the other hand includes accessing the software over a network under its definition of "distribution" and so if fuzzywuzzy were AGPL licensed, this would require you to publish your Django project's source publicly.

Source: I too have been reading heavily on this front for about 23 years, so much so that I married a copyright lawyer. We talk about this stuff a lot.

Regarding the secrets in-repo, I'm not going to fight you on this. In my experience it's a Great Big Pain In The Ass to manage these things and I think you may be overlooking just how many of the devs on your team may need the rights to read/write production values.

As for the making the distinction between settings and configuration, again I think you're going to live to regret this as every company I've started at that employs this pattern has. You simply can't have your development, testing, and production environments running different middleware classes (as your example suggests) and not be due for a surprise in production. No, your settings should be as close to production in all environments as possible, and breaking your settings up like this is just begging for deviation.

As for the claim that only 99% of problems in production are data-related, that too is not my experience with such systems. If you're talking to S3 in production and local folders in development, or SQS in production and synchronous execution in development, you will have problems, and you won't be able to detect them, let alone debug and fix them in an environment that doesn't match the place you're deploying to.