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

Rahul Sundaram metherid at
Wed Jan 22 03:37:35 UTC 2014


On Tue, Jan 21, 2014 at 9:52 AM, Christian Schaller <cschalle at>wrote:

> The software will come with a warning in the installer that this is not
> software provided by the Fedora project and that users need to contact
> the relevant upstream for support. We will also make it clear that this is
> not free software and users will be presented with a need to 'opt-in'
> to use said non-free software for that reason.

[I am not sure I agree with the overall goal but setting that aside for the

Others have covered the idealogically side of the argument very well so let
me focus on a more practical problem:

It is good that you are willing to clearly differentiate free/non-free
software on user searches and make a statement about support but if we are
enabling easy access, I think, the user experience isn't going to be much
better if the user updates the kernel (as Fedora updates to the upstream
kernel often) and breaks the Nvidia driver (which seems plausible atleast,
if not pretty likely) and we say hey, we told you that stuff is
unsupported.  The user will be mightily pissed by this attitude.  If we
enable access to non-free software, we will be on the hook to atleast try
and make that combination work but we can't do that without fairly deep
changes on how we have structured our project.  Enabling easy access is
only a small part of it.  The real problem will be QA especially given our
fairly aggressive set of updates  (do we change our kernel update policy?
have the resources to backport fixes instead?) but even otherwise, this is
a problem

To take a real life example,

There is no good way for a Fedora user to know that installing something
seemingly unrelated can cause this problem and I ran into just a day
before.  If we know about this problem before a release and we are enabling
access to Google Talk which I think your proposal will do, do we say, not
our problem?  We will not test it and we will not care about it even if
somebody reports it? Do we enable the workaround that makes Eclipse not
crash but degrades the experience by default just in case Google Talk is
installed by the user?  I would like your proposal to address such issues.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the advisory-board mailing list