Do I have to provide the build dependencies listed in a package build script to comply with GPLv2?

Question

Problem description:

For example in the case of alpine linux, there are APKBUILD scripts which reference the source files, the complete source code can be easily fetched with the abuild fetch command from the apline-sdk, this does however not include the dependencies required to build and compile the package.

So far I would include the complete source code referenced in the APKBUILD script, the APKBUILD script itself and the same for all runtime dependencies.

If I understand the following part of the gplv2 (section 3) correctly providing the build and compile dependencies is not necessary if they can be installed through the package manager from the target operating system (Alpine Linux).

[...]The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.[...]

Question:

Do I have to provide the build dependencies listed in a package build script to comply with GPLv2 even if they can be installed through the targeted OS package manager?

Answer 1

To me, there are two issues here. One is the system library exception, and the other is whether one's regular GPL source provisioning obligations can be satisfied by pointing to a third-party repository.

Firstly, regarding the system library exception, GPLv2 s3 does indeed contain the language you quote. GPLv3 s1 contains a similar exception, but it makes it clearer. For GPLv2, note the phrase "normally distributed ... with the major components of the operating system". For a library to avail itself of this exception, it is not enough that the source is already available through the OS's regular installation mechanism; the library in question must be part of the normal installation of the OS. libc, core Windows DLLs, and the like, are system libraries; many other libraries are not. You will have to make the call about the specific libraries you're thinking of.

Secondly, if you decide that the specific build dependencies of your package are not covered by the system library exception, and therefore that you do have source provisioning obligations, then you have asked whether those obligations are fulfilled by pointing to the OS's standard source-distribution tools. I attended, and wrote up for LWN, a very interesting talk addressing that very question at the 2019 Copyleft Conference in Brussels.

To summarise the talk, Intel decided to honour its source-provisioning obligations through the archive servers of an organisation called Software Heritage. Intel's lawyers didn't see a problem with that, and (to my recollection) neither did anyone else at the conference: but with the caveat that pointing to someone else's source repos doesn't magically turn your obligation into theirs. If SWH's servers all go down, the obligations would still apply to Intel, and it would have to find another way to satisfy them; if you decide to point people at source hosted elsewhere, and it stops being so hosted, your obligations remain, and you will have to find another way to honour them.