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.

This question is very close to asking a legal opinion on the interaction between Git Submodules and copyright law. Legal opinions can only be given by lawyers and are thus off-topic here.
– Bart van Ingen SchenauMay 20 '14 at 16:46

1

I disagree: It could have been more prominent, but the question says "I'm more interested in hearing the precedents and norms surrounding this issue than discussing our own interpretations of copyright law"
– BrendanMay 20 '14 at 17:54

1

I think maybe this question needs to be restructured. Git really doesn't have anything to do with licensing of code nor any affect on it. The question could perhaps be phrased "Does distributing my software with links to download GPL licensed modules still make my software subject to those modules licensing requirements"? The distribution tool is irrelevant. I think the heart of it comes back to, does your software compile/run independent of the GPL modules.
– jb510Jul 16 '14 at 22:24

I agree that Git is not really a part of the core question, but I used the phrase "Git submodules" as a concise analogue for "distributing software with a built-in means for automatically downloading dependencies" - I think a good proportion OSS programmers use Git, and I wanted to keep the title short. I'll consider changing it though.
– BrendanJul 17 '14 at 14:50

2 Answers
2

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:

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

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

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:

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:

The combination of packages has been approved through Debian's process.

We have only downloaded software -- we haven't modified or redistributed the software. Under GPL, that's a significant distinction.

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.)

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.