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

Re: Q to all candidates: dropping SC §5



Hi,

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


As underlined by algernon, there is also some useful documentation in
non-free. If you have a look at non-free's content, you will notice that there not many packages (~0,01% compared to main's size). I don't expect
this to change in a near future because the community is also not so
interested in non-free stuff and generally seeks "free" alternatives. The list of packaged non-free projects from _ten_ years ago counts (approx.)
a hundred less packages. ~60 of them are for mbrola (a multilingual
software speech synthesizer) and mgltools (Molecular Graphics Laboratory). So not only their number is ridiculous, but given their variety, it doesn't
seem easy at all to give an criteria.

I think that naturally we are leaning towards keeping only firmware
and software for which we don't have a good "free" alternative yet...
which doesn't seem all bad. So, restricting non-free to hardware stuff
doesn't seem necessary. It would also require a lot of efforts, but for no
much gain (IMHO). The consequence of doing so might be the creation of
some debian-nonfree.com which will deliver today's non-free content, with possibly more non-free software. This will make the situation even worse. Does this remind you of some story? Yes, debian-multimedia and we've seen
the bad consequences of such initiatives.

Not entirely related but, we've also seen cases of software moving from
non-free to main. In many cases, upstream was convinced that their license
doesn't bring any good or that the restrictions put in place are not
effective.

A better proposal would be to create sub-suites in non-free as explained
in #781365. I wouldn't create many sub-categories though as this would
not be stable over time. I'd suggest creating only needed ones, where
"needed" needs to be defined. Before doing so, we should reach on consensus
over what to enable and how from the installer.

This is also related to Paul's point:

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.

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

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


Depends on what do you mean by "by default" :-) I don't want a non-free
repository to be added without an explicit approval by the user, and
after been explained the consequences.

--
Mehdi


Reply to: