RFC: jenkins pipeline (containers and license compliance)

This is merely a historical archive of years 2008-2021, before the migration to mailman3.

A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/OpenBSC@lists.osmocom.org/.

Harald Welte laforge at gnumonks.org
Thu Mar 9 20:18:39 UTC 2017


On Thu, Mar 09, 2017 at 10:58:08AM +0300, Alexander Chemeris wrote:
> Could you elaborate what kind of license infringement does Docker have and
> what license issues might arise from publishing eg Osmocom images at some
> repository?

The issue is not with docker itself.  The issue is that people are
likely distributing large sets of pre-compiled binaries, which typically
has all kinds of obligations under copyleft licenses.

Distributing source is always easy.  As soon as you distribute binaries,
you need to either include the complete and corresponding source code
(under GPL/LGPL/AGPL), or you need to provide a written offer as to how
the exact corresponding source code for that particular software can be
obtained.

So doing something like a "Ubuntu Live derivative" or something like a
VM image, container or other image means you have to provude the *exact*
corresponding source code, up to three years later, for that given
image.  And if you update the image once per month, you have to keep a
record of all those source bases.

Passing on a written offer (like saying: Go to Ubuntu/Debian/... and
download the source there) is permitted in non-commercial distribution,
and relies on the fact that nobody else will distribute such an image in
acommercial context, ...  Also, can you guarantee that this third party
(UBuntu, Debian, whoever) will have those exact source versions around
for yeasr into the future?  What if not?

> I was confident it's ok and we did publish some code to create Docker
> containers in the past. I would like to understand potential issues with
> this.

Code to create docker images (or VM images) is perfectly fine.  That's
not distributing actual binaries of programs.

> Eg what's wrong with images built from publicly available sources without
> any binary blobs? 

see above, the fact that source is available (at the time of build?)
somewhere else is insufficient for compliance with LGPL, GPL and AGPL,
at least as soon as you ever distribute such an image in a commercial
context.

> And are the issues with Docker itself?

not that I'm aware of.  I just have some preconception about people who
work a lot with containers without having properly solved their copyleft
license compliance first.  And it might be that there now are solutions
for this - I just happen to hear horrors about public websites /
repositories full of binary images without any of them providing the
complete and corresponding source code to all the programs they have
packaged...

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)



More information about the OpenBSC mailing list