Skip to content

Proper usage of org.opencontainers.image.licenses #1257

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
anthops opened this issue Apr 12, 2025 · 4 comments
Open

Proper usage of org.opencontainers.image.licenses #1257

anthops opened this issue Apr 12, 2025 · 4 comments

Comments

@anthops
Copy link

anthops commented Apr 12, 2025

The spec defines the following:

org.opencontainers.image.licenses License(s) under which contained software is distributed as an SPDX License Expression.

This clearly states that it needs to list the licenses of all contained software. So for example, if the container just so happens to contain a GPL license it needs to be specified. However, it appears that nobody actually uses this field properly.

Take Microsoft for example, where their developer-platform-website Dockerfile sets the label to just MIT.

Another example is Hashicorp Vault setting vault-k8s' license label to MPL-2.0.

From my understanding, org.opencontainers.image.licenses should have a plethora of different licenses for all the random things inside of them. Containers are aggregations and don't have a license themselves. Why are so many people and even large organisations misinterpreting this and using the field incorrectly?

@sudo-bmitch
Copy link
Contributor

sudo-bmitch commented Apr 13, 2025

This clearly states that it needs to list the licenses of all contained software.

I'd say there's ambiguity of whether it should be "all contained software" or just "the contained software application". Typically container images are built as part of a project with an open source license, and the annotation is a way to efficiently communicate the contents of that project's license file. Given that you've shown most use cases are only for the packaged application and not the rest of the base image software and peripheral tooling, we could consider clarifying that wording to conform with real world behavior.

If your goal is license compliance, I believe using an SBOM generating tool would be a better fit.

@anthops
Copy link
Author

anthops commented Apr 14, 2025

Hmm that's fair enough. I guess that would make sense in most cases. However, what about the case of someone building an image to be used in their CI pipeline, or a simple case of building an Ubuntu image or something like that?

@sudo-bmitch
Copy link
Contributor

what about the case of someone building an image to be used in their CI pipeline, or a simple case of building an Ubuntu image or something like that?

How has that been done today? The repo that performs the base image build would have a license, so I could see that being used. As best I can tell, most aren't even using the annotation, so I wouldn't build any workflows that depend on it.

@cyphar
Copy link
Member

cyphar commented Apr 19, 2025

It should also be noted that distributions themselves have different licenses to their constituent software (quite a few distributions are GPL, I think this is the case for Fedora and openSUSE).

I think that the license annotation only really functions as a poor man's BOM, since just listing a series of licenses is not really that useful since it doesn't specify which subpart is under which license (and this is not sufficient for the notice requirements of most licenses). I would personally (as a non-lawyer) interpret the annotation as being the license for the collection of software rather than the software itself. But that doesn't quite match the specification text.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants