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

Re: Bug#353277: ndiswrapper in main



On 29 Mar 2006, Raul Miller spake thusly:

> On 3/28/06, Manoj Srivastava <srivasta@debian.org> wrote:
>> On 28 Mar 2006, Raul Miller spake thusly:
>>> I think the difference has to do with intent, and expected use
>>> patterns
>>> -- not just at the command line, but in overall terms.
>>>
>>> And a related question is: what free software effort would be
>>> harmed by putting ndiswrapper in config?
>
>> Err, wrong question. End users benefit from having this interface
>> to networking drivers around; it gives them more freedom in dealing
>> with hardware they might not have a choice about.
>
> How was that the wrong question?

        Our goal isn't to dump as much stuff out of Debian as possible
 unless some free software effort is impacted. Our goal is to produce
 the best free OS out there, imparting maximal utility to our users.

> Shouldn't we make a distinction between short term benefits and
> long term benefits?

        I do not see a temporal dimension here, really.  There is an
 implementation of a tool chain that allows users to wrap drivers
 written for another OS. The tool chain is licensed under a free
 license.

> Shouldn't we be focusing on development issues here?

        No, we should be trying for balance between development and
 unitlity to end users -- as long as the software under discussion is
 free.

> If the only issue was short-term end-user benefits, everything in
> non-free could go in main.

        Straw man.

>> Helping users make use of hardware they are saddled with adds to
>> the quality of implementation; and since users come high on our
>> list of things to care about, we should not be looking at "is some
>> free software effort damaged if we move things out of debian, even
>> if users selecting just debian (like, CD based users in areas with
>> poor network connectivity) have to jump through hoops"
>
> But what what distinguishes ndiswrapper from anything else in
> contrib?

        Like gcc, it is ready for tyhe user to provide input for it to
 process. Like gcc, it needs input to produce output (wrapped loadable
 kernel module), but does not _depend_ on the input, any more than gcc
 does.

        Basing classification on some nebulous “intent” rather than
 well defined licensing terms should be avoided -- and utility of
 software is also highly subjective. There is a free CIPE driver you
 can test your install of ndiswrapperon. Yup, there are better
 implementations -- native implementations -- of that driver, but the
 sub optimal utility does not prevent us from distributing (*shudder*)
 vi. Or brainfuck.

>> If ndiswrapper is not in my universe, I may never get around
>> to writing fee windows drivers that could also be used on Linux :)
>
> I don't understand this one.
>
> Why wouldn't "Contrib" be in your universe?

        It is not in Debian.

        manoj
-- 
PURGE COMPLETE.
Manoj Srivastava   <srivasta@debian.org>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C



Reply to: