7

So we have been discussing the implications of the GNU AGPL/GPL 3.0 license on our distributed code. I will make things, extremely simple. I hope. We will use AGPL in this example.

We will write code. Our main application we will call -A-. -A- will be built with Docker via a Dockerfile (code will be copied into the image) and then the image will be run to create a running container. The code in -A- will try and connect to a broker on ip x.x.x.x port xxxx.

Our Dockerfile will be built on Debian.

We will now use a Docker image which has the license GNU AGPL 3.0. This is the broker that -A- will try and connect to. We will call this broker -Broker-.

We will have a docker-compose file in the code as well. Which will run the -Broker- image to create a running container, and then of course, run the -A- image to create a container which will then connect to the -Broker-. So everything consists of two images (-A- and the -Broker-) and some helper files (docker-compose and some scripts and docker-engine) to get those two images running. We will call all of this together our -Product-.

I hope I am very clear so far. We have only made code adjustments to -A- and the helper files. The only line specifying any relation to the -Broker- image is the following, which lies in the helper file code:

docker run --name broker the-agpl-licensed-image /bin/bash

1) Would the above line cause the entire -Product- to be licensed under GNU AGPL 3.0?

We would like to DISTRIBUTE our -Product-, which consists of the -A- image TOGETHER with the -Broker- image and the helper files in a tar file and sell this commercially. So the customer will not be downloading the -Broker- image, it will be included in the tar file they will receive.

2) Would the above inclusion of the -Broker- image file in the tar cause the entire -Product- to be licensed under GNU AGPL 3.0?

3) If instead of including the actual -Broker- file in the tar, and instead let the customer download it (when executing the docker run command in the helper files), would this cause the entire -Product- to be licensed under GNU AGPL 3.0?

We wish to sell this commercially and not have to disclose the source code to the customer. I hope you understand how everything relates to each other in our product. I find everything revolving around copyleft to be confusing!

1 Answer 1

3

In your scenario, the AGPL is unlikely to have substantial effect. (1) The AGPLv3 is identical to the GPLv3 except for a clause about remote network interaction. (2) Container images are usually an aggregate of different softwares. It is more useful to analyse the licensing those softwares themselves rather than as the combined image.

The AGPL is basically just the GPL

The AGPLv3 is exactly the same as the GPLv3, except for the section about remote network interaction. The section about remote network interaction only triggers if:

  • you modified the AGPLv3-covered software; and
  • users interact with the modified software over a network

Here, the section does not seem to trigger because you have not modified the Broker software.

Therefore: in the context of this question, the AGPLv3 behaves exactly the same as the GPLv3.

Even if this weren't the case, the AGPLv3's remote network interaction section does not change to which software the AGPLv3 would apply. The A/GPLv3 only applies to derived works of the A/GPLv3-covered software, and not to other software that connects to it or is distributed alongside in an “aggregate”. (By the way, no open source license would restrict such other software, see also OSD #9. Any attempts to create a microservice-copyleft are flawed because copyright simply doesn't have that kind of power.)

If you are merely connecting to the Broker via its unmodified network interface, and are not using any A/GPLv3-licensed connector in your software, then I don't see how the AGPLv3 could apply to your proprietary software. They are clearly separate programs. Your software is in no way derived from the broker.

Images are just archive files

It is misleading to look at container images as a pre-linked program. It is more correct to view the container image as a file system image plus a bunch of metadata. Such a file system image is not fundamentally different from a TAR or ZIP archive. I therefore think it is better to talk about the individual licenses of the software in an image rather than about a singular image license. (Furthermore, an image may be an aggregate of incompatibly-licensed software, such as Apache 2 and GPLv2, or CDDL and GPL – then, no single image license could exist.)

As hinted at above, the A/GPLv3 allows you to distribute A/GPLv3 covered software alongside other software, without the A/GPLv3 affecting the license of this software. They are completely separate softwares, they just happen to be stored on the same filesystem.

You do however have to comply with the licenses of all the software in your images and TAR files. In the case of A/GPLv3 covered software, this means:

  • you must not limit the recipient's rights regarding the A/GPLv3 covered software. For example: you may sell the A/GPLv3 software, but you must not prohibit modification or resale of the A/GPLv3 covered components.
  • you must keep any legal notices intact and provide a copy of the license
  • you must provide the source code for the A/GPLv3 covered components

Similar requirements exist for all other licenses in the GPL license family as well. The Apache 2 and BSD licenses may trigger notice requirements. Note that a Debian system contains lots of such software, but that Debian has a built-in system to manage licenses, notices, and source code. Your compliance requirements are therefore limited mainly to the software that you add to an image.

Conclusion

Your planned distribution model seems fine, provided that you otherwise comply with the licenses.

(1), (2) Would your entire product fall under the AGPLv3?

No, your product consists of multiple separate programs, of which one is AGPLv3-covered. The mere use of AGPLv3-covered software is not sufficient to make your entire product derived of that software.

(3) Would having the user download the AGPLv3 software be easier than bundling it?

No, your compliance requirements are the same either way. Whether you bundle the AGPLv3-covered software or have the user download it from you, your software either is derivative of A/GPL covered software, or it isn't.

4
  • 2
    +1 for "It is more correct to view the container image as a file system image". +10, if I could, for "you do however have to comply with the licenses of all the software in your images"; yet another reason why containers aren't a good way to ship software.
    – MadHatter
    Jul 11, 2019 at 10:38
  • Also, who wrote the original Dockerfiles? While the image itself is just a file system image as you say, the source for those images is the Dockerfile.
    – oxr463
    Jul 11, 2019 at 12:22
  • Exactly, @oxr463 has a important point in there, I believe that if you just copy and paste or create a derived Dockerfile content from another you found on the internet, you need to check under what license the code for that file was using. (it may depend on what the license used views as derivative work, but you'll probably need to check that in any case)
    – Arruda
    Feb 6 at 9:10
  • 1
    @Arruda I've written another answer that takes Dockerfiles into account over here: opensource.stackexchange.com/a/7015
    – amon
    Feb 6 at 17:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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