From Fedora Project Wiki
m (Uraeus moved page Workstation/Third party software proposal to Workstation/Third party software policies: Rename this to policy as it is now an approved policy)
(general rewrite: clarify the role of the document and its intended audience, update links, remove repetition. generally make it easier to understand)
Line 1: Line 1:
= Revision to Fedora's Software Packaging Policies =
+
= Fedora Third Party Software Packaging Policy =
  
== Goals ==
+
Fedora's [https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/ third party repository policy] makes it possible for Fedora Editions to include software from third parties (ie. not from Fedora). This policy provides additional rules and guidance for using and applying this policy, including FESCo, Fedora Working Groups and SIGs, and the maintainers of third party software and repositories.
  
Fedora is an important participant in the world of free software, but for Fedora to have more impact we need to significantly grow our user base relative to its current size.  By growing our user base we hope to add to the potential contributor base for Fedora and for free software overall.  By making Fedora easier to use, and lowering as much as possible the threshold for users to get the software they need, we can accelerate the growth of the Fedora community. Doing so also ensures we are in the best position possible to spread the values and goals of the Fedora project as widely as possible. Our goal is to lay the groundwork to see even more rapid growth of the Fedora user community. This proposal is motivated by:
+
This policy cover topics such as which software can be included in third party repositories, and how that software should be managed in relation to the software from the official Fedora repositories. They also set out how this software should be presented to users, and the community processes that ought to be in place for decision making.
  
* Recurring topics that tend to come up as negatives when Fedora is reviewed, particularly but not exclusively the Workstation;
+
== Background & goals ==
* Feedback received through other means, such as [https://blogs.gnome.org/uraeus/2015/04/20/fedora-workstation-more-than-the-sum-of-its-parts/ this blog post] asking the community for reasons they have not switched to Fedora
 
* Evidence that a large proportion of our users [https://eischmann.wordpress.com/2015/07/31/most-popular-web-browsers-among-fedora-users/ run third party software] on Fedora
 
  
To achieve this goal, we want to accomplish two goals:
+
Fedora is an important participant in the world of free software, but for Fedora to have more impact we need to significantly grow our user base relative to its current size.  By making Fedora easier to use, and lowering possible the threshold for users to get the software they need, we can accelerate the growth of the Fedora community. Doing so also ensures that we are in the best position possible to spread the values and goals of the Fedora project as widely as possible.
  
* Make software built and provided outside the traditional official Fedora repositories available to our users, and
+
This policy is motivated by:
* Provide Fedora repositories that contain software packaged in ways other than RPM.
 
  
The software might come in a variety of formats and conditions.  This writeup is meant to provide reasoning, policy, and instructions for how this can happen. The desired outcome is to make the widest possible range of software available to Fedora users in a easily consumable format, while ensuring the software has labels and metadata that allows users to decide on the software they install.  We want to ensure Fedora continues to be a strong proponent of open source software.
+
* Recurring negative points when Fedora is reviewed, particularly but not exclusively regarding Fedora Workstation
 +
* Feedback exercises such as [https://blogs.gnome.org/uraeus/2015/04/20/fedora-workstation-more-than-the-sum-of-its-parts/ this blog post], which have asked users why they have not switched to Fedora
 +
* Evidence that a large proportion of our users [https://eischmann.wordpress.com/2015/07/31/most-popular-web-browsers-among-fedora-users/ run third party software] on Fedora
  
This proposal aims to modify the current policies defined here:
+
The policy aims to make the widest possible range of software available to Fedora users in a easily consumable format, while ensuring the software has labels and metadata that allows users to decide on the software they install. It does this by allowing software from outside the traditional official Fedora repositories to be made available to our users, including software that is packaged using formats other than RPM.
* https://fedoraproject.org/wiki/How_to_create_an_RPM_package
 
* https://fedoraproject.org/wiki/Third_Party_Repository_Policy
 
  
This document is not currently worded or enacted as a drop-in replacement for said policies.  However, it contains a basis for editing these and related policies to conform to the new goals and rules outlined in this document.
+
== Software tiers ==
  
== New Fedora Software policy outline ==
+
Under this policy, there are two tiers of software available in Fedora:
  
There will be two tiers of software available in Fedora:
+
* '''Tier one''': software packaged and hosted by the Fedora Project. This is essentially the software today packaged as RPMs and used to build the various Fedora editions. The policy allows tier one software to be packaged using formats other than RPM; in particular, using Moby images and Flatpak images.
  
* '''Tier One''': software packaged and hosted by the Fedora Project. This is essentially the software today packaged as RPMs and used to build the various Fedora editions. The main change to this tier is that we allow software to be packaged in other ways than RPMS, for instance Moby images or Flatpak images.
+
* '''Tier two''': software hosted and packaged outside of Fedora, but discoverable and installable through Fedora software tooling. This software might be hosted elsewhere due to the preference of an upstream maintainer, legal restrictions, or inability to comply with Fedora software policies. An example of software in the second tier is COPRs, which are FOSS and legally unencumbered, but for example may provide alternate builds of software that is included in tier one.
  
* '''Tier Two''': software hosted and packaged elsewhere, but discoverable and installable through Fedora software tooling.  This software might be hosted elsewhere due to simple preference of upstream maintainer, legal restrictions, or inability to comply with Fedora software policies.  An example of software in the second tier is COPRs, which are FOSS and legally unencumbered, but for example may provide alternate builds of software Fedora includes.
+
== Inclusion requirements for third-party software ==
  
This proposal aims to move to a model in which, rather than judging whether software conforms to a predefined set of principles on a project level, users decide what to install via clear labelling of software. For instance, we can label any third party software with a "third party" label using GNOME Software in Fedora Workstation, relying on available metadata, to clarify that the software in question doesn't come from Fedora.  For example, if Firefox was provided by Mozilla directly, it would be marked with a "third party" label to inform users they are installing software not provided by the Fedora community.
+
To be included in Fedora's third party repositories, software must conform to the following requirements.
  
Software not deemed "free" by Fedora standards, for instance Google Chrome, would be labelled both "third party" and "nonfree" for not conforming to Fedora's definition of free.  Over time further labels may be introduced to further inform users. For the Workstation edition, this labelling will be clearly visible in GNOME Software, the primary software installer for the desktop. For other editions and tools, the maintainers of said installers would need to work with FESCo to decide how to provide this labelling information in the relevant tools.
+
=== General requirements ===
  
== Principles ==
+
* Just as with any software hosted by Fedora, third party software must not contain material that poses undue legal risk for the Fedora Project or its sponsors. This includes, but is not limited to, software with known patent issues, copyright issues or software tailored for conducting illegal activities. The Fedora working groups will evaluate if a proposed addition or provider poses a significant risk, and if in doubt confer with Fedora Legal for advice.
 +
* Working groups should ensure that the software included in any third party repository is reliable.  While a formal SLA (Service Level Agreement) may not exist, the repository is expected to be something Fedora can rely upon. Working groups should be informed of changes in ownership of third party repositories.
 +
* Changes should not impact on other Fedora editions or spins. For example, the Workstation will populate the fedora-workstation-repositories package and include it in the Workstation's comps group, but that doesn't mean other editions or spins must do the same.
  
While the inclusion process is one of procurement, meaning the process isn't a total free for all, we want it to be as objective and transparent as possible. The requirements on third party software providers must be easy to understand and applied in a fair and balanced manner. Below is an outline of the technical requirements and process for submitting third party applications, libraries, and tools for Fedora.
+
=== Software packaged as RPMs ===
  
== Legal requirements ==
+
Requirements for software packaged using RPM:
  
Just as with any software hosted by Fedora, third party software must not contain material that poses undue legal risk for the Fedora Project or its sponsors. This includes, but is not limited to, software with known patent issues, copyright issues or software tailored for conducting illegal activities. The Fedora working groups will evaluate if a proposed addition or provider poses a significant risk, and if in doubt confer with Fedora Legal for advice.
+
* Applications that ship as RPMs should conform with [https://fedoraproject.org/wiki/How_to_create_an_RPM_package Fedora's RPM guidelines] as closely as possible. However, while this is best practice, it is not a hard requirement. (This more relaxed approach to RPM packaging is intended to allow software to be included for whom it is difficult to conform to Fedora's packaging guidelines.)
 +
* Software must be included in a DNF repository as described in the [Fedora System Administrators Guide https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/package-management/DNF/]
 +
* Repository can contain multiple applications. However, third parties are strongly recommended to ship their software in single application repositories as it will greatly increase chances of repository being accepted for inclusion. This minimizes the risk of "collateral damage" if one piece of software must be de-listed from Fedora temporarily or permanently for legal or other reasons.  
 +
* Repositories that mix types of software or applications are strongly discouraged. For example, a mixture of desktop and server software.
 +
* RPM packages must not require or recommend packages containing a .desktop file, unless they are add-ons for that package with appropriate AppStream data. Amongst other things, this is intended to prevent application stacks being dragging into the system in a way that confuses users.
 +
* RPM packages in a third party repository must not break dependencies or otherwise replace packages provided by official Fedora repositories.
  
== Other requirements and considerations ==
+
=== Software packaged as Moby (aka Docker) images ===
  
Working Groups proposing a package for a Fedora edition must address the reliability of the proposed third party repository.  While a formal SLA (Service Level Agreement) may not exist for community initiatives, the repository is expected to be something Fedora can rely upon.  If the repository offering changes the owner of the repository must notify the Working Group (see [[#Maintaining your repository]] below).
+
TBD: rules for Moby images will be developed by the Fedora Server and Fedora Cloud working groups.
  
== Non-universal approach ==
+
=== Software packaged as Flatpaks ===
  
An important principle of these changes is that they are implemented in an electable way by each individual working group or special interest group.  So for example, the Fedora Workstation working group may enable a set of third party applications through GNOME Software.  This should be done in a way that does not force, for instance, the desktop oriented spins to adopt the same policy, although they may do so.
+
Requirements for software packaged using Flatpak:
  
For example, the Workstation will populate the fedora-workstation-repositories package and include it in the Workstation's comps group, but that doesn't mean other editions or spins must do the same.
+
* Flatpaks hosted by Fedora (tier one) must be built using the official Fedora Flatpak runtime.
 +
* Third party Flatpaks (tier two) applications are strongly recommended to use the official Fedora Flatpak runtime to avoid unneeded runtime proliferation, and to preserve users' disk space.
  
Working groups or SIGs considering third-party applications must have a documented process which allows for  community input and which produces a traceable history for each decision (e.g., a ticket or other artifact)."
+
=== Software packaged using other formats ===
  
== Technical requirements and Submission guidelines ==
+
The Fedora Project will likely want to offer software in formats beyond those mentioned above in the future.  If those formats have special policy requirements, this policy document will require revision.  However, requirements for these formats may be covered by the rules for registries below.
  
=== Rules for software packaged as RPMs ===
+
=== Software management tools ===
  
All applications that ship as an RPM should conform as closely as possible with the RPM Guidelines found here:
+
Software packages can contain mechanisms or systems for installing further software packages. Examples include Steam, Firefox, Chrome, Moby, Maven, NPM, PyPi, and Rubygems.org. Requirements for these include:
https://fedoraproject.org/wiki/How_to_create_an_RPM_package
 
  
That said, a goal of this proposal is to allow software not already available in Fedora to become available. It is often difficult for that software to fit the current packaging guidelines to be included. So while we recommend following these package guidelines as a matter of best practice, they are not a hard requirement for being made available.
+
* The software they provide must conform to the legal requirements outlined above.
 +
* Their software should not interfere with normal operation of the system. This means that the software should not overwrite parts of the system or cause issues with the core functionality of the system.
 +
* It should be possible for Fedora's main software management tools to track or remove the software that is installed with these third-party tools. For example, GNOME Software should be able to track and remove games installed using Steam.
  
The software must appear in a yum repository as described here:
+
== Procedures and processes ==
https://docs.fedoraproject.org/en-US/Fedora/14/html/Deployment_Guide/sec-Creating_a_Yum_Repository.html
 
  
A yum repository may contain multiple applications.  However, third parties are strongly recommended to ship their software in single application repositories as it will greatly increase chances of repository getting accepted for inlusion.  Also doing this minimizes the risk of "collateral damage" if one piece of software must be de-listed from Fedora temporarily or permanently for legal or other reasons.  A yum repository is a hard requirement for RPM packaged applications to be considered. Repositories that mix applications with different purposes are also strongly discouraged, for instance contains a mixture of desktop and server software. In the end which repositories are acceptable is left to the discretion of the working groups based on an evalution of technical and legal risks posed by a given repository, but as a general rule the easiest path to inclusion is doing single application repositories.
+
General procedures and requirements for those who are using the third party repositories policy, in particular Fedora working groups.
  
RPM packages must not Require or Recommend packages containing a .desktop file, unless they are add-ons for that package with appropriate AppStream data. This will prevent e.g. obscure tools used in build toolchains from dragging application stacks onto the system in a way that confuses users.
+
=== Third party repository packages ===
  
RPM packages in a third party repository must not break dependencies or otherwise replace packages provided by official Fedora repositories.
+
Each edition or spin that wishes to include third party repositories must create a clearly named RPM package to include those repository pointers. An edition or spin is free to include the repository definition of one of the other editions if preferred. There should only be one third party repository package, to minimize the risk of install conflicts. As an example, in the Fedora Workstation edition, this package is called ''fedora-workstation-repositories''.
  
=== Rules for software packaged as Moby (aka Docker) images ===
+
Details on how third party repositories should be configured are included in the [https://docs.fedoraproject.org/en-US/fesco/Third_Party_Repository_Policy/ Fedora third party repository policy].
  
{{admon/note | TBD | Rules for Moby images will be developed by the Fedora Server and Fedora Cloud working groups.}}
+
Guidelines for how to create these repositories can be found [https://fedoraproject.org/wiki/Workstation/Third_party_software_Workstation_Guidelines on this page]
 
 
=== Rules for software packaged as a Flatpak ===
 
 
 
==== Flatpaks hosted by Fedora (Tier One) ====
 
 
 
Any Flatpak hosted by Fedora must be built using the official Fedora Flatpak runtime.
 
 
 
{{admon/note | TBD | The official Flatpak runtime should be referenced here by URL. The Fedora flatpak is
 
still in development. }}
 
 
 
==== Third party Flatpaks (Tier Two) ====
 
 
 
Third party applications are strongly recommended to use the official Fedora Flatpak runtime to avoid unneeded runtime proliferation, and to preserve users' disk space.
 
 
 
=== Rules for software using other formats ===
 
  
The Fedora Project will likely want to offer software in formats beyond those mentioned above in the future.  If those formats have special policy requirements, this policy document will require revision.  However, requirements for these formats may be covered by the rules for registries below.
+
=== Adding repositories ===
  
=== Registries and similar tools ===
+
Working groups or SIGs who approve the inclusion of third party repositories must have a documented process which allows for  community input and which produces a traceable history for each decision (for example, a ticket or other record).
  
A first or third party package might contain mechanisms or systems for installing further applications.  Examples include Steam, Firefox, Chrome, Moby, Maven, NPM, PyPi, and Rubygems.org.  Software made available in such a registry must conform to the legal requirements outlined for third party applications above to be considered for inclusion.  The software they provide must be packaged in a way that does not interfere with normal operation of the system, meaning the included mechanisms must not install their software in a way that overwrites system copies or injects into a system path such that it causes issues for the core functionality of the system.
+
=== Monitoring of third party repositories ===
  
The packager/provider of such registries or tools should make it possible for the main software handling tools we ship to track or remove the applications installed.  So in the example of Steam, GNOME Software should be able to track or remove games installed.
+
A working group must regularly review the repositories included in its third party repository list, in order to identify and correct issues that might arise.
  
 
=== Replacing a different package format ===
 
=== Replacing a different package format ===
  
A package may replace a package of a different format; for instance, an Flatpak may replace an RPM or set of RPMS. If the package provider is the same in both cases, then this can be done at the provider's discretion, as long as a reasonable effort is made to provide a smooth transition for users.
+
A package may replace a package that is provided in a different format. For instance, an Flatpak may replace an RPM or set of RPMS. If the both packages are supplied by the same provider, then this can be done at the provider's discretion, as long as a reasonable effort is made to provide a smooth transition for users.
 
 
If there are different providers who disagree about which package should be the primary offering in Fedora (or a specific Edition), the new package's provider must file a ticket with FESCo asking to replace the previous package.  FESCo will then try to mediate, and if no agreement is reached FESCo must decide which package to use.
 
 
 
The following principles are suggested bases for a FESCo decision in such a case. These are not in strict order, and should be weighed appropriately on a case by case basis.
 
 
 
* A package that more closely fits the policy and goals of Fedora (or a specific Edition) is preferred
 
* Packages created and maintained by the upstream project or company is preferred
 
* Packages from experienced or long term Fedora contributors are preferred
 
* Higher technical quality is preferred
 
  
=== Handling duplicate/similar packages ===
+
If there are different providers who disagree about which package should be the primary offering in Fedora (or a specific Edition), the new package's provider must file a ticket with FESCo asking to replace the previous package. FESCo will then try to mediate, and if no agreement is reached FESCo must decide which package to use.
  
It is possible under some circumstances to offer multiple varieties of the same application. For instance, a package may have a stable and a development version. In general, Fedora prefers not to offer the user a long list of varieties of the same package in software management tools, at least in the case of graphical applications. In the case of graphical applications, any packages or sets of packages beyond the first for a given application must be approved by the relevant Fedora Working Group on a case by case basis. If a package strongly affects multiple working groups, any working group other than the one proposing multiple varieties may ask FESCo to mediate.
+
When deciding between different versions of a software package, it is suggested that preference be given to packages that:
  
It is also desirable in some cases to offer multiple varieties of tools. For instance, a future modularized release scheme may allow Apache 2.2 and 2.4 modules to coexist. We expect working groups will have needs for these multiples, and should develop a method to approve them where appropriate.
+
* are more closely aligned with Fedora the policies and goals (including those of specific editions)
 +
* are from an upstream project or company
 +
* are from experienced or long term Fedora contributors are preferred
 +
* having greater technical quality
  
It may also be helpful in some cases to have the same piece of software available in multiple package formats. For example, both an RPM and a Moby version of Apache may be desirable.
+
=== Adding duplicate packages ===
It is not yet clear how to present this specific case without confusing end-users.  However, some of the confusion may be handled through separate tools that only offer a specific version of the software.  In this example, the Moby tools would not offer an RPM package.
 
  
=== Repository definitions ===
+
In some circumstances, it is possible to offer multiple varieties of the same software, such as to make different versions available, or make the software available in different package formats.
  
Each edition or spin that wishes to include third party repositories must create a clearly named RPM package to include those repository pointers. An edition or spin is free to include the repository definition of one of the other editions if preferred. There should only be one third party repository package, though, to minimize the risk of install conflicts. As an example, for the Workstation edition this package is called ''fedora-workstation-repositories''.
+
In the case of graphical applications, approval must be given by a relevant working group in order for duplicates to be included. (This is in order to prevent the multiplication of versions of the same software.) If a package affects multiple working groups, FESCo can be asked to mediate.
  
3rd party software metadata are NOT to be on the installation media, but they should only be downloaded after the user toggles the switcher ON. The default installed system would be free of the 3d party metadata package. The user would boot it for the first time, go through the initial screens to set up the system and one of the screens would ask about the 3rd party sources. If the user switches it ON, PackageKit on the background downloads and installs e.g. package called 3rd-party-software-metadata which will add repo metadata for DNF/Flatpak. If the user decides not to switch it on, nothing happens and user's systems stays free of it.
+
=== Software labelling and metadata ===
  
== Maintaining your repository ==
+
Users should be able to decide what software to install via clear labelling of that software. In particular, third party and non-free software should be clearly identifiable to users through software management tools, prior to installation. For Fedora Workstation, this requirement applies to GNOME Software, the primary software installer for the desktop. For other editions and tools, the maintainers of the primary software management tools should work with FESCo to decide how to ensure adequate software labelling.
  
You should notify the Fedora project as soon as possible if at any point you decide to stop maintaining your repository.
+
== Maintaining a third-party repository ==
  
If the contents of your repository change, either in terms of licensing or the software offered, please notify Fedora immediately so that we can review the changes. Fedora may define and provide an agreement in order for third party software providers to be listed.
+
Those who are responsible for a repository which is included in a Fedora Edition as a third party repository should notify the Fedora project if:
  
The Fedora Project will also establish review procedures to ensure users are not provided dead or deprecated repositories. Each WG that owns a third party repository list must regularly review those repositories regularly to resolve any issues.
+
* the repository ceases to be maintained, or will cease to be maintained in the future,
 +
* the contents of the repository changes, either in terms of the software included, or how it is licensed
  
== Practical Guidelines ==
+
Fedora may also define agreements, to set out expectations for specific third party software providers.
Guidelines for how to create these repositories can be found [https://fedoraproject.org/wiki/Workstation/Third_party_software_Workstation_Guidelines on this page]
 
we are also working on further documentation to be hosted on the Fedora Developer website.
 

Revision as of 13:55, 4 May 2020

Fedora Third Party Software Packaging Policy

Fedora's third party repository policy makes it possible for Fedora Editions to include software from third parties (ie. not from Fedora). This policy provides additional rules and guidance for using and applying this policy, including FESCo, Fedora Working Groups and SIGs, and the maintainers of third party software and repositories.

This policy cover topics such as which software can be included in third party repositories, and how that software should be managed in relation to the software from the official Fedora repositories. They also set out how this software should be presented to users, and the community processes that ought to be in place for decision making.

Background & goals

Fedora is an important participant in the world of free software, but for Fedora to have more impact we need to significantly grow our user base relative to its current size. By making Fedora easier to use, and lowering possible the threshold for users to get the software they need, we can accelerate the growth of the Fedora community. Doing so also ensures that we are in the best position possible to spread the values and goals of the Fedora project as widely as possible.

This policy is motivated by:

  • Recurring negative points when Fedora is reviewed, particularly but not exclusively regarding Fedora Workstation
  • Feedback exercises such as this blog post, which have asked users why they have not switched to Fedora
  • Evidence that a large proportion of our users run third party software on Fedora

The policy aims to make the widest possible range of software available to Fedora users in a easily consumable format, while ensuring the software has labels and metadata that allows users to decide on the software they install. It does this by allowing software from outside the traditional official Fedora repositories to be made available to our users, including software that is packaged using formats other than RPM.

Software tiers

Under this policy, there are two tiers of software available in Fedora:

  • Tier one: software packaged and hosted by the Fedora Project. This is essentially the software today packaged as RPMs and used to build the various Fedora editions. The policy allows tier one software to be packaged using formats other than RPM; in particular, using Moby images and Flatpak images.
  • Tier two: software hosted and packaged outside of Fedora, but discoverable and installable through Fedora software tooling. This software might be hosted elsewhere due to the preference of an upstream maintainer, legal restrictions, or inability to comply with Fedora software policies. An example of software in the second tier is COPRs, which are FOSS and legally unencumbered, but for example may provide alternate builds of software that is included in tier one.

Inclusion requirements for third-party software

To be included in Fedora's third party repositories, software must conform to the following requirements.

General requirements

  • Just as with any software hosted by Fedora, third party software must not contain material that poses undue legal risk for the Fedora Project or its sponsors. This includes, but is not limited to, software with known patent issues, copyright issues or software tailored for conducting illegal activities. The Fedora working groups will evaluate if a proposed addition or provider poses a significant risk, and if in doubt confer with Fedora Legal for advice.
  • Working groups should ensure that the software included in any third party repository is reliable. While a formal SLA (Service Level Agreement) may not exist, the repository is expected to be something Fedora can rely upon. Working groups should be informed of changes in ownership of third party repositories.
  • Changes should not impact on other Fedora editions or spins. For example, the Workstation will populate the fedora-workstation-repositories package and include it in the Workstation's comps group, but that doesn't mean other editions or spins must do the same.

Software packaged as RPMs

Requirements for software packaged using RPM:

  • Applications that ship as RPMs should conform with Fedora's RPM guidelines as closely as possible. However, while this is best practice, it is not a hard requirement. (This more relaxed approach to RPM packaging is intended to allow software to be included for whom it is difficult to conform to Fedora's packaging guidelines.)
  • Software must be included in a DNF repository as described in the [Fedora System Administrators Guide https://docs.fedoraproject.org/en-US/fedora/rawhide/system-administrators-guide/package-management/DNF/]
  • Repository can contain multiple applications. However, third parties are strongly recommended to ship their software in single application repositories as it will greatly increase chances of repository being accepted for inclusion. This minimizes the risk of "collateral damage" if one piece of software must be de-listed from Fedora temporarily or permanently for legal or other reasons.
  • Repositories that mix types of software or applications are strongly discouraged. For example, a mixture of desktop and server software.
  • RPM packages must not require or recommend packages containing a .desktop file, unless they are add-ons for that package with appropriate AppStream data. Amongst other things, this is intended to prevent application stacks being dragging into the system in a way that confuses users.
  • RPM packages in a third party repository must not break dependencies or otherwise replace packages provided by official Fedora repositories.

Software packaged as Moby (aka Docker) images

TBD: rules for Moby images will be developed by the Fedora Server and Fedora Cloud working groups.

Software packaged as Flatpaks

Requirements for software packaged using Flatpak:

  • Flatpaks hosted by Fedora (tier one) must be built using the official Fedora Flatpak runtime.
  • Third party Flatpaks (tier two) applications are strongly recommended to use the official Fedora Flatpak runtime to avoid unneeded runtime proliferation, and to preserve users' disk space.

Software packaged using other formats

The Fedora Project will likely want to offer software in formats beyond those mentioned above in the future. If those formats have special policy requirements, this policy document will require revision. However, requirements for these formats may be covered by the rules for registries below.

Software management tools

Software packages can contain mechanisms or systems for installing further software packages. Examples include Steam, Firefox, Chrome, Moby, Maven, NPM, PyPi, and Rubygems.org. Requirements for these include:

  • The software they provide must conform to the legal requirements outlined above.
  • Their software should not interfere with normal operation of the system. This means that the software should not overwrite parts of the system or cause issues with the core functionality of the system.
  • It should be possible for Fedora's main software management tools to track or remove the software that is installed with these third-party tools. For example, GNOME Software should be able to track and remove games installed using Steam.

Procedures and processes

General procedures and requirements for those who are using the third party repositories policy, in particular Fedora working groups.

Third party repository packages

Each edition or spin that wishes to include third party repositories must create a clearly named RPM package to include those repository pointers. An edition or spin is free to include the repository definition of one of the other editions if preferred. There should only be one third party repository package, to minimize the risk of install conflicts. As an example, in the Fedora Workstation edition, this package is called fedora-workstation-repositories.

Details on how third party repositories should be configured are included in the Fedora third party repository policy.

Guidelines for how to create these repositories can be found on this page

Adding repositories

Working groups or SIGs who approve the inclusion of third party repositories must have a documented process which allows for community input and which produces a traceable history for each decision (for example, a ticket or other record).

Monitoring of third party repositories

A working group must regularly review the repositories included in its third party repository list, in order to identify and correct issues that might arise.

Replacing a different package format

A package may replace a package that is provided in a different format. For instance, an Flatpak may replace an RPM or set of RPMS. If the both packages are supplied by the same provider, then this can be done at the provider's discretion, as long as a reasonable effort is made to provide a smooth transition for users.

If there are different providers who disagree about which package should be the primary offering in Fedora (or a specific Edition), the new package's provider must file a ticket with FESCo asking to replace the previous package. FESCo will then try to mediate, and if no agreement is reached FESCo must decide which package to use.

When deciding between different versions of a software package, it is suggested that preference be given to packages that:

  • are more closely aligned with Fedora the policies and goals (including those of specific editions)
  • are from an upstream project or company
  • are from experienced or long term Fedora contributors are preferred
  • having greater technical quality

Adding duplicate packages

In some circumstances, it is possible to offer multiple varieties of the same software, such as to make different versions available, or make the software available in different package formats.

In the case of graphical applications, approval must be given by a relevant working group in order for duplicates to be included. (This is in order to prevent the multiplication of versions of the same software.) If a package affects multiple working groups, FESCo can be asked to mediate.

Software labelling and metadata

Users should be able to decide what software to install via clear labelling of that software. In particular, third party and non-free software should be clearly identifiable to users through software management tools, prior to installation. For Fedora Workstation, this requirement applies to GNOME Software, the primary software installer for the desktop. For other editions and tools, the maintainers of the primary software management tools should work with FESCo to decide how to ensure adequate software labelling.

Maintaining a third-party repository

Those who are responsible for a repository which is included in a Fedora Edition as a third party repository should notify the Fedora project if:

  • the repository ceases to be maintained, or will cease to be maintained in the future,
  • the contents of the repository changes, either in terms of the software included, or how it is licensed

Fedora may also define agreements, to set out expectations for specific third party software providers.