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.

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.

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

Bundling by projects which are forks of other products that have been granted an exception

In some cases we grant an exception to one package that 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.