F44 Change Proposal: ContainerImagesLabels [SelfContained]

ContainerImagesLabels

Wiki

Announced

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Summary :open_book:

The org.opencontainers.image.name and org.opencontainers.image.license labels in Fedora container images get changed to org.opencontainers.image.title and org.opencontainers.image.licenses to more closely align with [The OpenContainers Annotations Spec The OpenContainers Annotations Spec].

Owner :open_book:

Detailed Description :open_book:

Starting with Fedora 40, the Fedora container images contain labels in the org.opencontainers.image namespace:

$ skopeo inspect --config docker://registry.fedoraproject.org/fedora:39 | jq .config.Labels

{

  "license": "MIT",

  "name": "fedora",

  "vendor": "Fedora Project",

  "version": "39"

}

$ skopeo inspect --config docker://registry.fedoraproject.org/fedora:40 | jq .config.Labels

{

  "io.buildah.version": "1.39.2",

  "license": "MIT",

  "name": "fedora",

  "org.opencontainers.image.license": "MIT",

  "org.opencontainers.image.name": "fedora",

  "org.opencontainers.image.url": "https://fedoraproject.org/",

  "org.opencontainers.image.vendor": "Fedora Project",

  "org.opencontainers.image.version": "40",

  "vendor": "Fedora Project",

  "version": "40"

}

They seem to be modeled after [The OpenContainers Annotations Spec The OpenContainers Annotations Spec]. That specification is about image manifest annotations and not about labels per se, yet the similarity is very close.

The specification however does not list org.opencontainers.image.name and org.opencontainers.image.license, instead it mentions org.opencontainers.image.title and org.opencontainers.image.licenses.

The proposal is to change the labels to match the annotation specification to align with the spec’s guidance:

Keys using the org.opencontainers.image namespace are reserved for use in the OCI Image Specification and MUST NOT be used by other specifications and extensions, including other OCI specifications.

Feedback :open_book:

In Making sure you're not a bot!, Neal suggested to add the new (correct) labels but keep the old ones as well. The problem is that the labels get inherited by any layered image which uses Fedora base images. And tools like docker build do not make it easy to remove the labels. You can overwrite them one by one but getting rid of them is not directly supported. So we are forcing maintainers of layered images to deal with (overwrite) labels that shouldn’t even be there to start with. I actually started digging into the issue because I noticed "org.opencontainers.image.name": "fedora" in our FreeIPA container images (GitHub - freeipa/freeipa-container: FreeIPA server in containers — images at https://quay.io/repository/freeipa/freeipa-server?tab=tags).

We can add the correct labels org.opencontainers.image.title and org.opencontainers.image.licenses to Fedora 42 and 43 images before Fedora 44 release, so that any dependency / tooling can adapt and start using them with the released images.

In Making sure you're not a bot!, Neal asked if the non-namespaced legacy labels should be dropped as part of this change. Jan does not have a preference and would welcome other (FESCO) opinions – the legacy labels have been around much longer so chances that something somewhere depends on them is much bigger; on the other hand, the overall move seems to be towards annotations and not labels, so it does not really matter if the legacy labels stay there.

Benefit to Fedora :open_book:

This change makes Fedora better align with existing external specification.

Scope :open_book:

  • Proposal owners:
    ** PR Making sure you're not a bot! should be all that is needed to get this change in.
    ** PRs against Fedora 43 and 42 can be filed to add the correct labels but not remove the .name and .license, so that any setup or tooling can start using them on the released container images, making migration easier.
  • Other developers:
    ** If other developer’s packages or tooling depend on the org.opencontainers.image.name and org.opencontainers.image.license labels in Fedora base container images, they will need to adapt to the new names.
  • Release engineering: [Making sure you're not a bot! #Releng issue number]
    ** IIUIC, no releng work is needed.
  • Policies and guidelines: N/A (not needed for this Change)
  • Trademark approval: N/A (not needed for this Change)
  • Alignment with the Fedora Strategy:
    ** TL;DR

Upgrade/compatibility impact :open_book:

Any setup which relies on the org.opencontainers.image.name and org.opencontainers.image.license container image labels will need to be updated.

Early Testing (Optional) :open_book:

Do you require ā€˜QA Blueprint’ support? No.

How To Test :open_book:

Pull fresh registry.fedoraproject.org/fedora:rawhide image by your podman, docker, docker-compose, or Kubernetes workload and see it working as it did before, even if the two labels have changed.

User Experience :open_book:

No user visible behaviour change.

Dependencies :open_book:

None.

Contingency Plan :open_book:

  • Contingency mechanism: (What to do? Who will do it?) Nothing bad happens if this change is not merged for the release, it just won’t get done.
  • Contingency deadline: N/A
  • Blocks release? No

Documentation :open_book:

N/A

Release Notes :open_book:

\n

Last edited by @alking 2026-01-05T17:04:45Z

Last edited by @alking 2026-01-05T17:04:45Z

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just ā€œ+1ā€. This will make long topics easier to follow.

Please note that this is an advisory ā€œstraw pollā€ meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

Is there any research available on whether any existing tools rely on the old names? It would be useful to know how likely it is that we’ll break someone’s existing workflow if we do this.

I’m +1 towards adding the new labels to be more compliant with modern conventions, but I’m less certain about removing the legacy labels. If we do decide to remove the legacy ones, I’m also in favor of eliminating the non-namespaced ones at the same time, so we only need to make this backwards-incompatible change once.

I haven’t done any such research.

I consider the org.opencontainers.image.name and org.opencontainers.image.license a bug, so the primary motivation for this change is to fix this bug, to make lives of maintainers of layered images easier. I’m not in favour of only adding org.opencontainers.image.title and org.opencontainers.image.licenses and not removing the wrong ones.

I’m leaning slightly towards keeping the non-namespaced labels, simply because they’ve been around much much longer.

I’m with Stephen on this; I know it can be hard to tell (same with say, ISO labels and libosinfo) but it’d be nice if we can do this in a way where we can inform previous users without potentially breaking their workflows.

Would it make any sense to set the old labels to a value that indicates that the new labels now contain the information a tool is looking for (e.g. refer to org.opencontainers.image.title) and keep that for one release (44), dropping them in 45?

Perhaps this is too careful of an approach :slight_smile:

We could make the label values for example ā€œorg.opencontainers.image.name": "fedora (deprecated; use org.opencontainers.image.title)" and ā€œorg.opencontainers.image.license": "MIT (deprecated; use org.opencontainers.image.licenses)".

But if anybody uses those values for anything automated, that thing will break in possibly worse way than if the labels are just gone.

So I frankly would just remove them and be done.

Isn’t a downstream builder a user? These users might notice the change. I think it would make sense to mention this in the release notes.

Throughout the ten+ years I’ve been involved with FreeIPA containerization on Fedora, we’ve noticed and had to handle numerous significant changes to the way the base container images were laid out and how they behaved, often during the lifetime of a release, and often without even going through the changes process. (For example, the fact that the org.opencontainers.image.* got added in Fedora 40 was not handled by the changes process, AFAICS.)

Compared to those changes, this feels extremely trivial and in area which more than anything is a documentation. Effect of almost any change is noticable if you dig deep enough. I don’t mind the release note, I just worry that it would pollute and blur attention from much more important changes.

I was thinking of a short single sentence, but yes, I see your point. I must admit, in our own usage we haven’t bothered much about those labels. We would probably have missed the change without any problems.

We can add the correct labels org.opencontainers.image.title and org.opencontainers.image.licenses to Fedora 42 and 43 images before Fedora 44 release, so that any dependency / tooling can adapt and start using them with the released images.

+1 from me for that approach. Add the new labels to the existing images. Keep only the new labels for the images starting with F44.

Hello @alking, we are currently waiting for the FESCo ticket to be created, is that correct?