My take on what could be a project template for Django advanced usage, with modern tooling (for Python and UI dependencies, as well as configuration/environment management), but not too opinionated.
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.
Thank you for the clarifications about how the GPL license applies, and what the consequences are.
If I’m following you correctly:
Having a GPL-licensed dependency in my Django project makes my Django project GPL-licensed
But since my Django project is not going to need to run anywhere else than on my servers, I won’t ever need to share a copy of my project to anyone, so the fact that my project is GPL-licensed has no implications whatsoever, it can live in my private Git repository like any proprietary piece of software
So in the case of my Django project template:
The project template is GPL-licensed
This makes any Django project based on it is GPL-licensed
But real-life Django projects being made to run on a server only, in order to offer services through the web, their being GPL-licensed will have no practical implications
Which means that people can safely use my template as it is, with the GPL, without having to worry about it
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.
Thank you for the clarifications about how the GPL license applies, and what the consequences are.
If I’m following you correctly:
So in the case of my Django project template:
Thanks for the discussion, I’ve learned a lot!