User:Toshio/Bundling relaxation

This page is a draft only
It is still under construction and content may change. Do not rely on the information on this page.

There are a few proposals for new criteria for allowing bundling of code.

Note -- in the meeting it was mentioned that we wouldn't want some of these criteria to be seen as being sufficient. The current guidelines have this to say about all of the criteria that we list:

 Some reasons you might be granted an exception
 This section lists some reasons that might convince FPC that you have a
 valid reason to be granted an exception. Exceptions are granted on a case
 by case basis and satisfying the rationale here is not a guarantee of an
 exception but it's a place to start building your case for why the package
 you work on is exceptional. 

Active upstream Security Team

One thing that the FPC would consider would be whether the:

1. Project is actively developed and has a responsive upstream, with new releases occurring at least yearly. Rationale: a) if a security issue does arise, we don't want to be left on our own; b) where projects have bundled code but are not fast-moving, the reward/work ratio of unbunding the code is higher.

AND

1. Project has an active security response team of its own and has demonstrated both the ability and the will to release timely security updates when issues are discovered in bundled code. Rationale: this reduces the burden on our security team, and does not put Fedora maintainers in the position of creating or carrying our own patches.

AND

1. The upstream project is actively working on unbundling.

Like most of the possible criteria, this rationale may not be sufficient in and of itself but it may be one thing that we'd take into consideration. Note that the criteria for upstream to be working on unbundling means that we'd be granting a temporary exception and would want to see that progress has been made when we hit the date for reviewing whether the package still needs an exception.

Too Big to Fail

Although it is a case of last resort that FPC is extremely reluctant to allow, we occasionally consider whether a package is too popular to keep out of the distribution. In a case like this, the package is seen as necessary enough for Fedora's end users that we'll grant a one-off exception for it. Note that this sort of exception is really distasteful to FPC so finding other criteria in addition to this would definitely help your case.

Too small to care

FPC may grant an exception if we deem that a package is niche enough that a vulnerability or unaddressed bug in the package is not a high risk to the vast majority of Fedora users.

Forks of packages which have been granted an exception

Forks of packages that are bundling need to ask FPC for an exception of their own. In some cases we'll be able to use the rationale for bundling of the initial package to justify bundling in the fork but other cases will need to be evaluated on their own merits.

One class of exceptions that we evaluate on their own is when the exception we granted to the initial package depends on something intrinsic to the project creating the package rather than the code. Examples of this are when we grant an exception for code that originates with the same upstream or when we deem that a package is too popular to keep out of the distribution. Forks of these projects often don't fall under the same exception. (A fork of firefox is likely not going to fall under the popularity argument as firefox does. A fork of gdb won't get the "same upstream" exception to bundle the binutils libraries as gdb itself.)

FPC might consider granting an exception for these packages if it's demonstrated that upstream is good about syncing its code with changes from the source it forked from. If this is not the case, FPC is unlikely to grant an exception based on this but may grant one based on other criteria.