-
Notifications
You must be signed in to change notification settings - Fork 720
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
Comments
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. |
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? |
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. |
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. |
The spec defines the following:
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?The text was updated successfully, but these errors were encountered: