It also discourages people from providing hosted services based on a particular piece of software if they are in fact complying with the spirit of the GPL, but just suck at build infrastructure.
In particular, if I have custom patches to RethinkDB, I submit them all upstream, and I'm using some awful in-house build system because that's how everything is required to work at my company, I'm obligated to release the build system, even if any discrepancy between my awful in-house build system and the upstream one is a bug on my end. The one that's actually live is the corresponding source.
In theory this is good, because it means that if my awful in-house build system is, say, picking up some patched high-performance library, I'm obligated to distribute that library too.
In practice, that's much less likely to happen than just not having a great build system that does the same thing as the upstream build process, just worse. A legal obligation to have good build tooling is a weird barrier.
Nobody said it had to be good build tooling, just functional.
You use a 1000 line shell script to do a bunch of shit, that's fine, there's no requirement in the GPL that it has to be "./configure && make && make install" - just that you provide the accompanying scripts used to build the software.
This shouldn't be hard, you shouldn't make it hard on yourself or developers working on your project to create a local build. I honestly don't even see the issue.
Releasing this script would involve releasing a ton of metadata about everything anyone at the company works on.
I have my differences of opinions with our build infrastructure rather frequently, as it happens, but I think it makes it easier to create a local build; you don't have to learn n different build systems for n different upstream projects. But it's a local build designed for developers who are my co-workers, not for the general public.
If you want one script that can build a whole stack then fine, but that doesn't mean you can't keep the tooling separate enough to build each component individually. You use RethinkDB with a bunch of patches? Keep that part in it's own script that gets called by your big one, problem solved.
In particular, if I have custom patches to RethinkDB, I submit them all upstream, and I'm using some awful in-house build system because that's how everything is required to work at my company, I'm obligated to release the build system, even if any discrepancy between my awful in-house build system and the upstream one is a bug on my end. The one that's actually live is the corresponding source.
In theory this is good, because it means that if my awful in-house build system is, say, picking up some patched high-performance library, I'm obligated to distribute that library too.
In practice, that's much less likely to happen than just not having a great build system that does the same thing as the upstream build process, just worse. A legal obligation to have good build tooling is a weird barrier.