Practical requirements for a personal/small Fedora Remix

Project Discussion
1

Hi all,

I’m looking for a sanity check on the Fedora Remix and trademark requirements before I decide whether to continue distributing custom installer media.

I’m working on an “opinionated” Fedora setup that I’m pretty much building for myself at this point, mostly for the fun of it. I’m currently the only person working on it. It’s open source, so a couple of friends or anyone else who finds it useful could try it, but it isn’t a community distribution, a commercial product, or an attempt to present something as an official Fedora edition.

It started as a post-install bootstrapper for Fedora. It installs and configures a Niri and Noctalia desktop, manages dotfiles and first-login setup, and offers a catalog of optional applications that I use myself daily. Some packages come from Fedora, while others come from RPM Fusion, COPR, Terra, Flathub, vendor repositories, or upstream installers.

The post-install version is simple: the user installs Fedora themselves, runs the bootstrapper (which starts a Wizard-like TUI built with gum) to reviews the available choices and finally proceed with the installation.

More recently, I wanted to try making my own custom ISO out of it (mostly for convenience), and that worked out better than I expected. This custom ISO is simply the official Fedora Everything netinst ISO modified using mkksiso to add a Kickstart, a product.img, and an Anaconda add-on. The add-on displays the project’s package choices inside Anaconda and runs the same post-install code. It’s essentially Fedora Everything but it runs my bootstrapper in the end while still inside Anaconda.

The ISO does not contain a package mirror or embed RPM Fusion, COPR, Terra, or Flathub packages. The custom content in the ISO is the Kickstart, Anaconda integration, project code, configuration, and catalog. The result is still updated through Fedora’s normal repositories, with additional repositories enabled for the software the user selected.

After reading the Fedora Remix page and the current trademark guidelines, my understanding is that this custom ISO makes my project a Fedora Remix, even though the additional packages are downloaded at installation time rather than embedded in the image. That classification makes sense to me.

Where I’m getting stuck is the practical rebranding requirement.

The guidelines say that a Remix must remove fedora-logos, fedora-release, and fedora-release-notes, replacing them with suitable alternatives. On current Fedora, this is more complicated than those package names suggest:

  • fedora-release itself is effectively a metapackage. The actual identity, /etc/os-release, RPM macros, DNF defaults, systemd presets, CPE/SWID data, and related files live in fedora-release-common and an identity subpackage.
  • fedora-release-notes does not appear to exist on current Fedora releases.
  • fedora-logos supplies much more than a logo file. It owns Anaconda artwork and CSS, the Plymouth spinner watermark, bootloader images, menu icons, GDM assets, and several generic system-logo paths.
  • fedora-remix-logos supplies the authorized Fedora Remix artwork, but it does not provide the system-logos capability needed as a drop-in replacement for fedora-logos.
  • generic-logos does provide that capability and is explicitly described as the replacement, but it would still require custom integration to produce a coherent installer and Plymouth experience.
  • generic-release is mechanically compatible with Fedora repositories, but it identifies the system as “Generic,” contains placeholder identity URLs, and has service presets that differ materially from the current Fedora release package.

A custom release package could preserve Fedora compatibility capabilities such as system-release(44), %fedora, .fc44, ID_LIKE=fedora, and the current service presets while replacing the visible identity. But that creates a new package that must be maintained for every Fedora release. It also changes how third-party tools detect the system, since many check for ID=fedora without considering ID_LIKE.

There is a separate installer problem too. Replacing packages in the target transaction does not remove Fedora branding from the Anaconda environment or early Plymouth boot shown by the original netinst ISO. The product.img can override Anaconda assets, but early boot and bootloader branding may require rebuilding more of the installer image rather than simply using mkksiso.

I understand why Fedora protects its trademarks, and I’m not looking for a loophole or trying to present this as an official Fedora edition. The project has its own (Fedora inspired) logo, and I’m happy to call it something like “X Fedora Remix” or “X, a Fedora Remix,” display a clear non-affiliation notice, link to the official Fedora downloads, and make the project branding more prominent.

What has been discouraging is discovering that doing this properly may require maintaining a downstream release package, duplicating Fedora’s service presets and compatibility metadata, rebuilding or heavily overriding the installer environment, and taking responsibility for release-to-release upgrade behavior. That is a lot of distribution-level maintenance for what is otherwise an online Fedora installer that runs a post-install configuration tool.

I also found Fedora Council ticket #432, where Fedora Asahi Remix received specific permission to use the “Fedora Asahi Remix” name and retain Fedora logos in its images. I understand that was a special exception and that Asahi had close involvement from a Fedora SIG. I’m wondering whether a narrower exception is a realistic path for smaller community projects too, or whether the expectation is that they must fully replace the release and logo packages regardless of how closely they track Fedora.

I’d appreciate clarification on a few points:

  1. Does an online netinst ISO with a custom Anaconda add-on, but no embedded third-party package payload, fall under the full Remix rebranding requirement?
  2. Does removing fedora-release mean replacing the entire current package family, including the common and identity subpackages?
  3. Is generic-release genuinely the recommended production path today, despite its generic identity and differing service presets, or is a Remix expected to maintain its own release RPM?
  4. Is replacing the target packages sufficient, or must all Fedora branding also be removed from the installer runtime, early Plymouth screen, and bootloader?
  5. Is “X Fedora Remix” an acceptable default name without separate permission, provided that “Fedora Remix” remains intact and all other conditions are met?
  6. What criteria would the Council use when considering limited permission to retain Fedora’s release and logo packages in a Remix?
  7. If the custom ISO were dropped and the project remained only a post-install bootstrapper run by users on an official Fedora installation, would it fall outside the Remix requirements?

At this point I’m seriously considering dropping the custom ISO and keeping the project strictly as a post-install tool. That would be disappointing after putting substantial work into the Anaconda integration and release testing, but it may be the only sustainable option if distributing the ISO means effectively maintaining a separate downstream distribution.

I’d be grateful for guidance from anyone familiar with the current policy, especially Council members or people who have maintained a Remix recently.

2

I don’t have all the answers, but thank you for looking into this topic and for coming here to discuss it. These are all good questions.

I am not able to answer to all, but some comments:

Support for Remixing

Generally I believe that easy Remix building is an important feature of the project and if some components are especially hard to rebrand - you should file bugs for them and request changes, additional help and guidance, even just updates the documentation pages.

We do not want Remix-related bugreports to land in the Fedora Bugzilla, but the bugreports regarding remixing capabilities of the Fedora Linux are fair game.

For example, I am the Product Owner of the Installer team and we do have Customization guide as one of the priorities in our roadmap and we will try to help.

The wiki-page and linked docs might be outdated, and I will review them, but in the meantime, I would recommend to look at the new installer WebUI and use it for any new projects.

The rebranding docs are available in upstream Anaconda Customization Guide and it should be as simple as placing 10-line css file in the cockpit/branding/<os_name>/ folder.

Is it even a Remix

In theory, if you package the bootstrapper itself in Fedora, and set it up in a way that user will interactively choose and install software from additional sources through the bootstrapper on the first boot, this would be a Spin, not a Remix:

  1. The installation media would have only Fedora content
  2. Users will make their own decision on installing third-party software on the system.

No rebranding needed.

If you drop the bootstrapper part, and focus on having Niri environment by default, there is quite a lot of interest in the community in a generic Fedora Spin based on Niri and Noctalia. You might consider creating a SIG and a Spin, similar to how Cosmic or other existing Fedora Spins are managed.

Why Remix needs to change so much

This is actually done on purpose. When dealing with the Remixes it is important that the end user is not confused about what system they have installed. The remixed machine should not be shown as Fedora machine by third-party tools either.

Remix should be responsible for its own relationship with its users. It should have its own bugtracker and own support channel, its own commitments to addressing CVEs and such.

One can ask remix-related question in Fedora channels, but for any bugreports they would be asked to reproduce the issue on vanilla Fedora before proceeding.

Also

You can use COPR infrastructure for packages like this.