Proposal: Revision of policy surrounding 3rd party and non-free software

Michael Scherer misc at
Tue Jan 21 17:35:22 UTC 2014

Le mardi 21 janvier 2014 à 10:42 -0500, Eric H. Christensen a écrit :
> On Tue, Jan 21, 2014 at 09:52:04AM -0500, Christian Schaller wrote:
> > So to summarize the proposal.
> > 
> > * Fedora will continue to not ship non-free software and as part of that will continue to only default to free software.
> This is a must.
> > * We will add the needed metadata to the Software installer to give our users the freedom to choose to install legally cleared 3rd party software
> From a desire to push FOSS solutions I don't like making it easy to use non-free solutions where free solutions 
> are available.  It would seem that we are endorsing these non-FOSS solutions which could also be a problem.  How
>  does a project get into your non-free solution?  Why would one be rejected from being included?  We'd need to 
> publish the rules of engagement and I'd want to see those rules before checking off on this.

Also, another question is "how much breakage are we willing to tolerate
on those outside packages"

Let's take Virtualbox. If a kernel update break it, would we consider
the kernel update to be problematic and so should people give -1 until
the issue is resolved ?

Same for nvidia and X11, for example, and this already occurred in the
past, with X11 being rebased.

Also, would the traditional packaging policy apply on those ?
Again, in the case of nvidia/vbox, the policy of "no kernel module", for
example. Or no bundling. 

Last part, I know that some companies are less suspicious than RH and
Fedora when it comes to patents. For example, I stumbled during $dayjob
on some company who provided us a binary tool who bundle openssl with
some ciphers enabled that were seen as problematic by RH Legal
( ). Traditionally,
even linking to some 3rd party repos in the doc was forbidden so I am
not really sure this is gonna fly, especially with something like Chrome
that update every 6 weeks and that bundle stuff quite heavily, so that
could requires lots of audits.

Michael Scherer

More information about the advisory-board mailing list