Fedora bootc images are not ideal for derived builds #125

Open
opened 2026-08-29 01:38:55 +00:00 by gordonmessmer · 10 comments

When any software not provided by Fedora is included (I suspect this policy probably applies to any content not provided by Fedora), policy requires that the derived build follow trademark guidelines, including replacing fedora-logos, fedora-release, and fedora-release-notes:

https://fedoraproject.org/wiki/Remix#Including_other_software

(e.g. codeberg.org/project-resistor/ai-developer-desktop@e73f6b69a9 )

This requirement is frequently not observed.

It might be helpful to create images that are specifically intended for derived builds, which include the generic-logos, generic-release, and generic-release-notes packages.

When any software not provided by Fedora is included (I suspect this policy probably applies to any content not provided by Fedora), policy requires that the derived build follow trademark guidelines, including replacing fedora-logos, fedora-release, and fedora-release-notes: https://fedoraproject.org/wiki/Remix#Including_other_software (e.g. https://codeberg.org/project-resistor/ai-developer-desktop/commit/e73f6b69a98da05dcfb18d90c5c983eeab76d8af ) This requirement is frequently not observed. It might be helpful to create images that are specifically intended for derived builds, which include the generic-logos, generic-release, and generic-release-notes packages.
Owner

One issue per ticket please. Let's keep this one for the logos, release and release notes packages and please open another one for the /usr/local and /opt discussion.

One issue per ticket please. Let's keep this one for the logos, release and release notes packages and please open another one for the /usr/local and /opt discussion.
Owner

So for the logos etc. part, multiple changes are in progress to make this easier:

For the release package, the presets have been split into distinct packages (redhat-presets or something like that) so that replacing the release package is easier, but this requires building your own package, which is not ideal. Maybe creating a generic Fedora remix release package that follows the lifecycle of Fedora would help here.

For the logos, I've asked the design team to create Fedora Remix logos ready to be used as a replacement for the fedora-logos ones: design/tickets#37. Now we need to turn https://src.fedoraproject.org/rpms/fedora-remix-logos into a full replacement for the fedora-logos package.

For the release notes, we could create an empty one. I don't even know what it's used for.

So for the logos etc. part, multiple changes are in progress to make this easier: For the release package, the presets have been split into distinct packages (redhat-presets or something like that) so that replacing the release package is easier, but this requires building your own package, which is not ideal. Maybe creating a generic Fedora remix release package that follows the lifecycle of Fedora would help here. For the logos, I've asked the design team to create Fedora Remix logos ready to be used as a replacement for the fedora-logos ones: https://forge.fedoraproject.org/design/tickets/issues/37. Now we need to turn https://src.fedoraproject.org/rpms/fedora-remix-logos into a full replacement for the fedora-logos package. For the release notes, we could create an empty one. I don't even know what it's used for.
Owner

Note that this is not specific to the Atomic Desktops and impacts all bootc images so we should discuss that in the bootc tracker as well: https://forge.fedoraproject.org/atomic/tracker/issues

Note that this is not specific to the Atomic Desktops and impacts all bootc images so we should discuss that in the bootc tracker as well: https://forge.fedoraproject.org/atomic/tracker/issues
Author

Improving the packages is a good step, but most of the people I've spoken to who are building derived systems seem to be unaware of the requirement. Documentation might help, but I think that producing an image meant specifically for derived systems and doing the steps necessary for trademark compliance there seems like a more reliable approach.

Improving the packages is a good step, but most of the people I've spoken to who are building derived systems seem to be unaware of the requirement. Documentation might help, but I think that producing an image meant specifically for derived systems and doing the steps necessary for trademark compliance there seems like a more reliable approach.
Member

Note that this is not specific to the Atomic Desktops and impacts all bootc images so we should discuss that in the bootc tracker as well: https://forge.fedoraproject.org/atomic/tracker/issues

Yes and a root problem here is because of this split, I assume Gordon was unaware we actually do have docs for this on the base bootc/atomic images:

https://docs.fedoraproject.org/en-US/bootc/os-release-and-versions/

Which could for sure be improved, and there's definitely an argument that we should use generic-release by default, but that has a lot of implications.

> Note that this is not specific to the Atomic Desktops and impacts all bootc images so we should discuss that in the bootc tracker as well: https://forge.fedoraproject.org/atomic/tracker/issues Yes and a root problem here is because of this split, I assume Gordon was unaware we actually do have docs for this on the base bootc/atomic images: https://docs.fedoraproject.org/en-US/bootc/os-release-and-versions/ Which could for sure be improved, and there's definitely an argument that we should use generic-release by default, but that has *a lot* of implications.
Member

Briefly but: my understanding of this is the guidance we need to give on this diverges heavily depending on whether or not one plans to publish the images outside ones' own organization.

For RHEL cases where customers derive from the image and aren't publishing it, every instinct I have says it would likely be fairly catastrophic for 3rd party tools to suddenly see generic-release content and not redhat-release for example. But OTOH some today are rebranding at a higher level (which makes sense!) so we do need both.

Briefly but: my understanding of this is the guidance we need to give on this diverges heavily depending on whether or not one plans to publish the images outside ones' own organization. For RHEL cases where customers derive from the image and aren't publishing it, every instinct I have says it would likely be fairly catastrophic for 3rd party tools to suddenly see generic-release content and not redhat-release for example. But OTOH some today are rebranding at a higher level (which makes sense!) so we do need both.
Author

a root problem here is because of this split, I assume Gordon was unaware we actually do have docs for this on the base bootc/atomic images

I had not seen that doc, true. But the issue is not that I'm not aware of that doc, it's that prominent Fedora Remixes are not aware of it, and are not following trademark guidelines. Also, the bootc document says that derived builds "can" replace the packages, but the trademark guidelines say they must replace those packages when non-Fedora software is added to the image.

> a root problem here is because of this split, I assume Gordon was unaware we actually do have docs for this on the base bootc/atomic images I had not seen that doc, true. But the issue is not that I'm not aware of that doc, it's that prominent Fedora Remixes are not aware of it, and are not following trademark guidelines. Also, the bootc document says that derived builds "can" replace the packages, but the trademark guidelines say they *must* replace those packages when non-Fedora software is added to the image.
Member
Moving this to https://discussion.fedoraproject.org/t/clarify-trademark-guidelines-within-an-organization/200797
Member

I would strongly emphasize here though that this thread conceptually has nothing to do with atomic/bootc other than that we make it easier and more obvious to do this. If we were to apply any changes here, it should also apply to quay.io/fedora/fedora i.e. the app base image for example.

I would strongly emphasize here though that this thread conceptually has nothing to do with atomic/bootc other than that we make it easier and more obvious to do this. If we were to apply any changes here, it should *also* apply to `quay.io/fedora/fedora` i.e. the app base image for example.
Owner

We can not use the generic packages for the Atomic Desktops images as we need the Fedora branding.

I don't think building alternative Remix images with Remix branding built-in is worth it right now. I think we should focus on making the rebranding experience as simple as possible (ideally only a few package swap and a sed line for the os-release) and properly document it.

We don't really have docs right now for the parts specific to the bootable container versions of the Atomic Desktops.

We can not use the generic packages for the Atomic Desktops images as we need the Fedora branding. I don't think building alternative Remix images with Remix branding built-in is worth it right now. I think we should focus on making the rebranding experience as simple as possible (ideally only a few package swap and a sed line for the os-release) and properly document it. We don't really have docs right now for the parts specific to the bootable container versions of the Atomic Desktops.
Sign in to join this conversation.
No description provided.