Workstation/Third party software policies

Proposal for Revision to Fedora's Software Packaging Policies

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page. This is a work in progress. Until this notice is removed, don't rely on this document being an accurate reflection of the ideas inside.

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 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:

• Recurring topics that tend to come up as negatives when Fedora is reviewed, particularly but not exclusively the Workstation;
• Feedback received through other means, such as this blog post asking the community for reasons they have not switched to Fedora
• Evidence that a large proportion of our users run third party software on Fedora

To achieve this goal, we want to accomplish two goals:

• Make software built and provided outside the traditional official Fedora repositories available to our users, and
• 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.

This proposal aims to modify the current policies defined here:

• 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.

New Fedora Software policy outline

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 main change to this tier is that we allow software to be packaged in other ways than RPMS, for instance Docker images or xdg-app images.

• 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.

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. So for instance we can label any third party software with a "third party" label using GNOME Software in the Fedora Workstation, relying on available metadata, to clarify that the software in question doesn't come from Fedora. For instance, 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.

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 improve information to 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.

pfrields: Need to check implementation of rulesets, so there is support for different rules of acceptability/labeling

The screenshot below demonstrates current implementation in GNOME Software.

Principles

While the inclusion process is one of procurement, meaning it is not a total free for all process, we want it to be as objective and transparent as possible. The requirements we put 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 and its editions.

Legal requirements

Just like with any software hosted by Fedora any third party software considered for inclusion must not contain material that pose an undue legal risk for the Fedora Project or its sponsors. This includes software with known patent issues or software tailored for conducting illegal activities. The Fedora working groups will evaluate if any proposed addition or provider poses a significant risk and if in doubt confer with Fedora Legal for advice.

Non-universal approach

An important principle we want to push as part of these changes is that they are to be implemented in way which makes them electable by each individual working group or special interest group. So for example the Fedora Workstation Working group will work to enable a set of 3rd party applications to be available through GNOME Software, but it should be done in a way that allows for instance the desktop oriented spins to not be forced to adopt the same policy. For example the Workstation will be populating the fedora-workstation-repositories package and including in its comps group, but that doesn t mean other editions or spins need to do the same.

Technical requirements and Submission guidelines

Rules for software packaged as RPMs

All applications that comes shipping as an RPM should conform as closely as possible with the RPM Guidelines found here: https://fedoraproject.org/wiki/How_to_create_an_RPM_package

That said, part of the goal of this proposal is to allow software not already available in Fedora to become available, and difficulties fitting the current packaging guidelines can be a reason for the current state of non-inclusion, 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 also need to set up a Yum repository as described here: https://docs.fedoraproject.org/en-US/Fedora/14/html/Deployment_Guide/sec-Creating_a_Yum_Repository.html

A Yum repository might contain multiple applications, but we do generally advise 3rd parties to ship their software in single application repositories to minimize the risk of collateral damage if one piece of software has to be de-listed from Fedora temporarily or permanently for legal or other reasons. Having a yum repository set up is a hard requirement for RPM packaged applications to be considered. Repositories that mix applications with different purposes are not permitted.

jboyer: SLA for third party repos doesn t currently exist; this may reflect on Fedora.

mcatanzaro: 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.

Rules for software packaged as Docker images

Rules for Docker images will be developed by the Fedora Server and Fedora Cloud working groups.

Rules for software packaged as a XDG-app

All XDG-apps to be hosted by Fedora needs to be built using the official XDG-app runtime as published here: FIXME: Add URL

For 3rd party applications we strongly recommend using the official XDG-app runtime to avoid unneeded runtime proliferation and preserving users disk space.

Rules for software using other formats

Fedora is likely to want to offer software in other formats beyond those mentioned above in the future, if they have special policy requirements revisions of this policy document would need to be made. Many of them though they should be covered by the rules for registries.

Registries and similar tools

A 1st or 3rd party package might contain mechanisms or systems for installing further applications, examples here include Steam, Firefox, Chrome, Docker, Maven, NPM, PyPi, Rubygems.org. The software made available in such a registry will need to conform to the legal requirements outlined for 3rd party applications above, in order for the application/tool making them available to be considered for inclusion. The software they provide must be packaged in a way that doesn t interfere with the normal operation of the system. What we mean by this is that they can not install their software in a way that overwrites system copies or injects themselves in a system Path in a way that can cause issues for the core functionality of the system.

We do request that the packager/provider of such registries or tools do make it possible for the main software handling tools we ship to track the applications installed and also de-install the software. So for instance in the example of Steam we wish that GNOME Software can keep track of games installed and also de-install the individual games.

Replacing a different package format

It is fine for a package to replace another package that is using the different packaging format, for instance a xdg-app can replace a RPM or set of RPMS. If the person or entity creating both packages are the same then this can be done at the discretion of the packager as long as a reasonable effort has been done to make the transition smooth for the users.

If there are different people behind the two packages and they are in disagreement about which package should be the primary one made available in Fedora or a specific edition of Fedora the proposer of the new package will have to file a ticket with FESCo asking to be allowed to replace the previous package. FESCo will then try to mediate. If no agreement can be reached FESCo will decide on which package to use.

The following set of principles are suggestions on how FESCo could base these decisions. These are not in a strict order, and should be weighed appropriately for the case in discussion.

• Which package fits the policy and goals of Fedora the most or the goals of the edition it targets the most.
• Packages created and maintained by the upstream project or company will get preference
• Packages from experienced or long term Fedora contributors will get preference
• Technical quality of the two options

Handling duplicate/similar packages

It is possible under certain circumstances to offer multiple varieties of the same application. For instance there could be a stable and a development version of a package. In general Fedora does not want to offer the user a long list of different varieties of the same package in our main software management tools, at least in the case of graphical applications. In the case of graphical applications, any packages or set of packages beyond the first for a given application will need to be approved by the relevant Fedora Working Group on a case by case basis. If a package strongly affects multiple working groups, then any other working group than the one originally handling the proposal can ask FeSCO to mediate.

In some cases, it is desirable to offer multiple varieties of tools, such as in a future modularized release scheme where both an Apache 2.2 and 2.4 module coexist. We expect working groups will have needs for these multiples, and should develop a method to approve them where appropriate.

There are also cases where having the same piece of software available in multiple package formats is the wanted solution, for example both a RPM and a Docker version of Apache. We don t have a clear idea on how we present that in a non-confusing and relatable fashion, although some of the confusion will be handled by separate tools that only offer a specific version of the software, i.e. no RPM package offered by the Docker tools.

Repository definitions

[Concept is to have WGs and SIGs able to vary these according to their need or tolerance for different software. This is probably not to be solved through e.g. the global fedora-release package.]

Extra Technical requirements Fedora Workstation

These technical requirements only apply to the Fedora Workstation. Other editions or spins are free to adopt them if they wish, but they are not meant to be Fedora wide.

Definition of Desktop application

A GUI application is an application that is meant to be run on a graphical desktop with a launcher in the GNOME Shell. While there might be desktop applications which don t fit under this description, like a desktop-centric command line tool, they should for now just aim at following the generic 3rd party applications rule.

Keywords, metadata

The Fedora Workstation Working Group will publish further guidelines for how keywords and metadata need to be set beyond the formal requirements of the Appstream and desktop file specifications. The goal of the metadata is to allow AppStream compliant software managers like GNOME Software to properly inform Fedora users about the software they are installing as shown in screenshot below, to help them make decisions in accordance with the values and goals of Fedora and to ensure that users a duly aware of who they need to contact with questions or support in case they have problems with their applications.

Appstream Data - Applies to Desktop Applications

All applications available needs to come with metadata conforming to the Freedesktop appstream standard. Details can be found here: http://www.freedesktop.org/software/appstream/docs/

Desktop file - Applies to Desktop Applications

All applications available needs to ship with a .desktop file. This is the file that determines how the application is presented in the Fedora Desktop shell: http://standards.freedesktop.org/desktop-entry-spec/latest/

Guide for 3rd Party developers

This guide is meant as a writeup for 3rd party developers on how they can get their software made available in a Fedora edition.

Principles

While the inclusion process is one of procurement, meaning it is not a total free for all process, we want it to be as objective and transparent as possible, so that the requirements we put on 3rd party software providers are easy to understand and applied in a fair and balanced manner.

Before submitting an application please review the technical requirements for 3rd party applications, libraries and tools for Fedora. Also make sure to read any specific extra requirements for the Fedora edition you are targeting.

Be aware that the submission process is edition based, so acceptance into the Fedora Workstation for instance doesn t guarantee that your software will be as easily available in another Fedora Edition or in one of the spins. It is up to each working group or special interest groups how to make available any software in their system.

Submitting the application for consideration

Once your are fairly certain your 3rd party application conforms with the rules for such applications you can submit it for consideration by filing a ticket in the Fedora bugzilla. The component is called fedora-3rd-party applications.

The relevant Fedora Working Group will then review your submission as quickly as possible.

Maintaining your repository

We do ask that all 3rd parties notify the Fedora project as soon as possible if they at any point decide to stop maintaining their repository. If the contents of your repository change either in terms of licensing or what software is offered the repository owner must notify Fedora immediately so that we can review the changes. Fedora might define and provide an SLA that all 3rd party software providers must adhere to be to listed.

jboyer: Need automation here, perhaps leveraging anitya?

The Fedora Project will also try to establish various review procedures to ensure we don t provide dead or deprecated repositories to our users.