Third-Party Repository Policy

A third-party repository is any software repository that the Fedora Project does not officially maintain, including Copr repositories, as well as repositories that are hosted outside of the Fedora Project.

This policy sets out the conditions under which Fedora editions and spins can include repository definitions that make the contents from those third party repositories available to users. It applies to repository definitions integrated with the usual package installation mechanisms like dnf or GNOME Software. Unless such integration exists, this policy does not cover the packaging of:

  • Language-specific tools (pip, maven, cargo, go, …).

  • Tools that primarily exist to access external software packaging ecosystems (snap, apt, pacman, …).

  • Tools that provide images of other systems (docker, podman, machinectl, …).

These tools can use third-party repositories without the restrictions described below.

This policy is intended to ensure quality and legal protections for the most critical and visible software mechanisms used by Fedora, while allowing special-purpose software management tools to function as expected. The policy also aims to ensure that software provided under its terms is clearly labeled, so users are fully informed about the origin of the software they are installing.

Software from third-party repositories cannot be used when creating Fedora images.

Third-party repository distribution

Third-party repositories should be distributed in descriptively named rpm packages. Each third-party repository should be defined once through a separate (binary) package.

Traditionally, definitions for multiple repositories were combined into one package (for example, Fedora Workstation edition installs a package called fedora-workstation-repositories), but this is discouraged and should not be done in new cases.

Repositories can be configured with either enabled_metadata=0 or enabled_metadata=1 (or equivalent), at the discretion of the relevant working group or SIG.

If they fulfill the requirements set out in this policy, a Fedora edition or spin install media can include third party repository definitions.

The third-party nature of the repository must be apparent to the user when they enable it, as should the non-free status of its content, if such. To ensure this, repository files must initially include the enabled=0 (or equivalent) setting, and the user must explicitly enable third-party repositories to install from them. FESCo may grant an exception to waive this requirement.

Reuse of repository definitions among editions or spins is encouraged.

Key requirements for third-party repositories

Third-party repositories must be approved by an active Fedora working group or SIG, or by FESCo. Groups who approve the inclusion of third party repositories must have a documented process which allows for community input, which produces a traceable history for each decision (for example, a ticket or other record).

Additionally, repositories included in an edition or spin’s third-party repository list must conform to the following requirements:

  • Just as with any software hosted by Fedora, third party repositories must not contain material that poses an undue legal risk for the Fedora Project or its sponsors. This risk includes, but is not limited to, software with known patent issues, copyright issues, or software tailored for conducting illegal activities. Fedora working groups should evaluate if a proposed addition or provider poses a significant risk, and if in doubt, confer with Fedora Legal for advice.

  • Changes made by one Edition or spin should not impact other Fedora editions or spins.

  • Working groups and SIGs should maintain oversight over the software that is made available through third-party repositories, to prevent unvetted software being made available to Fedora users. As part of this, third-party repositories should allow easy auditing by Fedora Legal. This requirement implies that third-party repositories should limit themselves to a small number of packages, or that measures should be put in place to define which packages are made available from a particular repository by default.

Software labeling and metadata

Third-party and non-free software should be identifiable to users through software management tools before installation. In general, this requirement applies to the primary software management tools used in a given edition or spin. For Fedora Workstation, this is GNOME Software, the primary software installer for the desktop.

Third-party software requirements

Software included in each third-party repository must conform to the following requirements.

Software packaged as RPMs

Requirements for software packaged as RPMs:

  • Applications that ship as RPMs should conform with Fedora’s RPM guidelines. However, while this is the best practice, it is not a hard requirement. (This more relaxed approach to RPM packaging allows the inclusion of software for which it is difficult to conform to Fedora’s packaging guidelines.)

  • Software must be included in an RPM repository as described in the Fedora System Administrators Guide.

  • RPM packages in a third-party repository must not replace packages provided by official Fedora repositories, nor break dependencies between those packages.

Software packaged using other formats

  • Applications in other packaging formats should conform with guidelines and best practices appropriate for those formats.

Duplicates and replacements

Third-party repositories can supplement official Fedora software. In limited cases, they can be used to replace software included in the official Fedora repositories. Such situations require FESCo approval.

Maintaining a third-party repository

Those responsible for a repository included as a third party repository should notify the Fedora project if:

  • repository maintenance ends or will end in the future

  • the contents of the repository changes, either in terms of the software included or its licensing

Fedora working groups or FESCo may also define agreements with third-party maintainers.