[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Q to all candidates: dropping SC §5



>>>>> "Bas" == Bas Wijnen <wijnen@debian.org> writes:

    Bas> Everyone seems to mention firmware; I don't hear anyone saying we really
    Bas> need to support games with non-free game data, or shareware programs.
    Bas> And I agree.

    Bas> So to the candidates: can you please let us know whether you would be in
    Bas> favor of restricting non-free, so that it will only contain things that
    Bas> are required for making hardware work, and for which there is no fully
    Bas> functional free alternative?  If not, do you think restricting it on
    Bas> other grounds is a good idea?  If so, which criteria would you
    Bas> suggest?

We also have documentation in non-free. Documentation of Free
Software. I don't think it would be a good idea to keep non-free
firmware for closed hardware, but throw out documentation for free
software, even it if fails to meet the DFSG.

Having sub-categories on the other hand...

    Bas> This is also related to Paul's point:

    Bas> On Tue, Mar 17, 2015 at 02:16:09PM +0800, Paul Wise wrote:
    >> Add an extra component that d-i could add to sources.list when
    >> non-free firmware is needed, instead of adding all of non-free.
    >> 
    >> Likewise for drivers, GNU documentation, the web, tools for external
    >> APIs and other common categories of non-free things.

    Bas> (Aside: I like all the ideas in Paul's mail, but this one is relevant
    Bas> here.)

    Bas> Would you be in favor of such categories of non-free, where we can
    Bas> perhaps include some of them (firmware) by default on installation
    Bas> media?

This would be useful, but I still wouldn't enable any such category by
default. D-i could tell the user they may need some of those
repositories, but in the end, adding them should be a conscious choice
From the user's part.

But that - again - wouldn't bring us any closer to dropping SC §5, yet,
would complicate a number of things, for - in my opinion - little
gain. I'd support such an initiative, if the relevant parties are all
for it, but I wouldn't actively push for an implementation.

-- 
|8]

Attachment: signature.asc
Description: PGP signature


Reply to: