License compliance with Torizon containers

The question is actually more general than the tags I added.

How do you suggest to do license compliance with Torizon’s containers? In a Yocto build the system creates a list of all the involved source packages with their licenses. Now, how can a client get a similar thing for the containers themselves?

Greetings @lisandropm,

Licensing is certainly something a Yocto-built image will handle better than a container. However there are options. For Debian-based containers like ours you can simply parse the copyright files for each package. In the container if you look in /usr/share/doc/ you should find the copyright files for each package if available. So for example /usr/share/doc/chromium-common/copyright should have the license information for the chromium-common package.

Out of curiosity with regards to licensing what are your goals here?

Best Regards,
Jeremias

Greetings @lisandropm,

Licensing is certainly something a Yocto-built image will handle better than a container. However there are options. For Debian-based containers like ours you can simply parse the copyright files for each package. In the container if you look in /usr/share/doc/ you should find the copyright files for each package if available. So for example /usr/share/doc/chromium-common/copyright should have the license information for the chromium-common package.

I was afraid I was going to receive this reply :slight_smile: Yes, I know, I’m a Debian Developer myself. Problem with copyright files is that it is not mandatory to have them in a machine-parseable formart. While DEP-5 aka “Machine-readable debian/copyright file” is a standard it’s use is optional. Thus not every copyright file will be machine parseable.

Out of curiosity with regards to licensing what are your goals here?

Just as an example: listing of SOUP software for medical devices. But also having a list of all the used FLOSS software in order to properly comply with their licenses.

As an example, as soon as any customer receives a board with any of your containers on it then they are able to ask you for the source code of each package. While normally one could go to the Debian archive for it:

  • I guess some packages are modified by you, so you need to provide source code (I haven’t checked).
  • Depending on the country you might still be in charge of providing the full source code.

Of course if a client uses your boards for a product they will have the very same issue.

Just as an example: listing of SOUP software for medical devices. But also having a list of all the used FLOSS software in order to properly comply with their licenses.

And I was afraid you’d say something like this as well. Yes this is a limitation when it comes to containers, I must admit. See the write-up about the topic here: https://www.linuxfoundation.org/tools/docker-containers-what-are-the-open-source-licensing-considerations/

Given the nature and structure of a container image, it can be actually quite difficult to get a very comprehensive manifest of all licenses for every package in that container image. Perhaps the best you could hope for is creating a Yocto image, then containerizing that Yocto image. You’d then have the usual license manifest via the Yocto build. But then this begs the question of just using Yocto on it’s own without containers.

So in short if you’re looking for license compliance for containers on the same level as Yocto. I’m afraid there’s currently no good answer for this.

Best Regards,
Jeremias