12

I would like to learn more about satisfying GPL3 object code distribution requirements with a hopefully simple enough example.

I download a docker image for e.g. Debian from hub.docker.com with

docker pull debian

This will transfer among other things the executable command line program "ls" from their server to my computer, which is part of the GNU coreutils, a software package which is licensed under the GPL3.

I'm now trying to understand how whoever runs the download server is complying with section 6 of the GPL3, which regulates access to the corresponding source code of coreutils:

You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:

It goes on to list 5 different ways, a) to e).

a) and b) only apply when a physical device is transferred, therefore, a) and b) cannot apply here.

c) requires the transfer of "a copy of the written offer to provide the Corresponding Source". There is no paper physical paper slip, and no text file in /usr/share/doc/coreutils inside the image has such a written offer. The "license" section from the docker image description at https://hub.docker.com/_/debian has also no such written offer.

e) involves peer-to-peer transmission, which I understand as something like bittorrent, which also does not apply here.

So by elimination, d) must apply. It reads:

d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.

I do not think that whoever runs the docker hub image download server provides the source code (for any and all distributed GPL3 software in object form) on the same server, so the "different server (operated by you or a third party)" clause must apply. Could it be they rely on the debian project distributing the source for GPL 3 software contained in debian on the debian servers, at least as long as debian functions? If so, then I am still missing how the part "provided you maintain clear directions next to the object code saying where to find the Corresponding Source" is fulfilled.

At this point I would like to ask for your input. The reason that I ask is that I want to distribute Docker images and SD card images for Raspberries myself and want to comply with all the licenses of all contained software. One way would be to include all the sources inside the images that I distribute, but Docker seems to have found an easier way, and I want to understand how they comply with the contained licenses, here GPL3.

  • 2
    I agree that Docker image licensing is an absolute nightmare. But Debian base images are comparatively good, since Debian contains licensing information in /usr/share/doc/*/copyright and makes it convenient to download sources for packages via the apt-get source tool. – amon Jan 23 at 8:34
  • 1
    I'm not here to point fingers. I just want to do it right myself. I have the same not-quite-understanding-how-this-fulfills-the-license e.g. with the Raspberry Pi foundation distributing an SD card image of Raspbian, the Armbian project, Bitnami distributing virtual machine images, virtually every vendor of an ARM-based board who distributes a linux image for that board. Also I am not interested in Image licensing - the images are assemblies, nothing unclear there. I want to learn about options to fulfill the licenses of the components: How is the "clear directions" part fulfilled? – Ludwig Schulze Jan 23 at 9:33
8

The short answer is that, for my money, it's not.

I agree with you that for GNU Coreutils, this is a s6d conveyance. I haven't followed the links that start at Docker Hub and flow through GitHub all the way, but I've already found a bunch of build tools, and I suspect they do end up pointing to the actual sources. Whether this chain of frangible links satisfies GPLv3's requirement to "maintain clear directions next to the object code saying where to find the Corresponding Source" is open to argument; I don't think it does. Nevertheless, I suspect the source is available, with enough digging.

Amon's comment above about Debian making sources readily available is a good one, and the point applies equally to other grown-up distros (eg Fedora) as well. However, I don't think that satisfies s6d conveyancing requirements either.

The bigger problem is that even if this particular distributor of container images is doing the right thing, albeit not very well, distribution via container image is no guarantee of correctness. Copyleft licence fulfilment has no salience in the containerised image world, it seems to me.

There are lots of good reasons, at least from a sysadmin standpoint, to dislike container images as a general-purpose software distribution method; this is another one. I'd advise you to avoid it.

Bootable images for specific hardware are a somewhat different case; there are good technical reasons to distribute them. If you want to be in the best-possible standing about your GPL obligations, start from a well-known bootable image from a project that makes modifying its images easy, and which also does satisfy its licence obligations. Then you can point to the same place they point to and satisfy nearly all of your obligations in one go (at least, for as long as that project lasts). You will need to make specific arrangements only in respect of the licence requirements for changes you make and additional software you include in your images.

| improve this answer | |
  • Thanks for the opinion. It seems one can interpret compliance by relying on benevolent interpretations of the terms "clear" and "next to". I do not see a difference between docker and sd card images in terms of licensing. The advice on starting from a clearly compliant base image may be good if there were any candidates. I think I will just add a post-build step that downloads any source packages provided by debian for the .deb packages in my images and provide them for Download together with my SD card images. For docker images the safest way seems to be to include these sources in the images – Ludwig Schulze Jan 30 at 8:53
  • 1
    @LudwigSchulze I agree there's no difference between container images and SD images in terms of licensing; the difference is in the justification for their use in the first place. Containers are a very poor format for software distribution to general-purpose computers, and this question beautifully showcases one of the many reasons for that. SD card images, on the other hand, actually have some point to them, such that the very considerable attendant licensing issues are worth confronting. – MadHatter Jan 30 at 9:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.