Is licensing an issue for Git Submodules?

Question

For example: an MIT-licensed project wishes to simplify the build process for its users by including part of the GNU toolchain (which is of course GPL) as a Submodule.

• Could that be interpreted as making the MIT project a "derived work" of the GNU toolchain?
• Does including a project as a Git Submodule (or some similar mechanism - maybe even just a Bash script that downloads it) count as "redistributing" that project?
• What about if the Makefile also built the sub-project?

In my opinion (and probably most peoples') the answer to those questions is a clear "no". I'm more interested in hearing the precedents and norms surrounding this issue than discussing our own interpretations of copyright law. Do you know of any open-source projects that have Submodules under incompatible licenses? Do you know of anyone who has deliberately avoided them, and why they did that?

---

Just to clarify for non-Git-people: Submodules don't cause the actual content to be included, they're like "pointers" to a different repo. In the example I gave, when you cloned the MIT project and ran git submodule init, Git would automatically download the GNU code from a GNU repo.

Answer 1

I doubt you're going to find significant legal materials on git-submodules per se. One angle would be to make an analogy to another system with a bigger community / longer history / more precedents. To that end, let's define "git submodules" -- it is, in fact, two things:

1. A file-format (".gitmodules") which lists the names/addresses of other software packages. (For brevity, let's call these files "manifest.")
2. A tool which reads the file format and downloads software.

Now, let's pick another project which meets these criteria -- for example, Debian's package manager provides both:

1. A file-format which lists the names/addresses of other software packages. (For brevity, let's call these files "manifests".)
2. A tool which reads the file format and downloads software.

(For performance reasons, the file-format for Debian's package manager is much more complex/nuanced. This is because a typical Debian deployment works with thousands of packages distributed across thousands of servers -- whereas a typical git-submodules deployment works with maybe a dozen packages and a handful of servers. If you review the early history of dpkg/apt, you'll find that performance was a central design issue and a significant achievement. However, on a general "informational" level, the formats are similar.)

The Debian project is a particularly useful example because -- within the FOSS community -- debian-legal has a particularly long history / strong reputation for evaluating licensing issues that arise from mixing software.

So: if we look at the Debian project, do we find they publish manifests which reference packages that have incompatible licenses? Yes. For example, PHP4 was licensed under the "PHP License" which the FSF judges to be incompatible with GPL (https://www.gnu.org/licenses/license-list.html). Here is the manifest:

http://archive.debian.org/debian/pool/main/p/php4/php4_4.0.3pl1-0potato3.dsc

Observe that this has "Build-depends" on "bison". Bison is a tool licensed by FSF under GPL.

If a user types "apt-build install php4", then the consequence will be that he downloads "php4" and "bison", loading both on the same computer/filesystem. Have we violated the GPL? No. Why not? Any of these points should be individually persuasive:

1. The combination of packages has been approved through Debian's process.
2. We have only downloaded software -- we haven't modified or redistributed the software. Under GPL, that's a significant distinction.
3. The GPL specifically distinguishes modification/derivation from mere aggregation and disclaims virality under mere aggregation.
4. The manifest shows bison as a "Build-depends" and not a "Depends" -- to wit, bison is a build-tool that helps to process php4 (like a text-editor does); php4 does not include (or even link) the bison code; at runtime, you can execute php4 without executing bison.

If you swapped Debian's package manager with git-submodules here, would it suddenly change from "OK" to "violation"? No, that's silly -- it's the same mix of codes with the same mix of licenses and the same compilation steps. All that's changed is the download tool.

(Note: None of this is to say that your specific usage of git-submodules with its specific dependencies is acceptable or unacceptable. In our example from Debian, several key factors were specific to the particular licenses and packages -- and so it goes with anything.)

Answer 2

The Android Open Source Project almost exactly mirrors the case I used in my example: the bulk of the source is under the Apache license, but they use a mechanism equivalent to Git submodules to deliver the GNU toolchain.