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