Re: Bug#353277: ndiswrapper in main

[Raul Miller]

Here's my current feelings on the ndiswrapper issue:

(1) ndiswrapper should be made available by us.

(2) the question is: should it be in main or config?

(3) ndiswrapper sometimes needs to be recompiled to be useful
http://lists.debian.org/debian-amd64/2006/04/msg00278.html

(4) the primary reason for the package to be in main is cipe.

(5) cipe has had no development attention for several years.

(6) software being stable is not sufficient reason for it to be
removed from the archive.

(7) ndiswrapper's primary use is  with non-free software (which
suggests it should be available in Contrib)

(8) there are practical problems with Contrib and some people
would be unhappy with ndiswrapper being in Contrib because
of those practical problems.

Since the primary question (should ndiswrapper be in Main or
Contrib) is a social contract issue, the determining factors in
any proposal for resolving this issue should be based on social
contract issues.

Probably the most important such issue is: what is best for
the free software community?

This is a value judgement, so I think that we can only issue
advice.  I think we should avoid making a ruling that is any
stronger than "advice" on this issue.

However, there are other problems here (for example, the
practical problems with Contrib) which perhaps should also
get some attention from us.

* * * * *

That, I think, characterizes the problem, what about solutions?

One crucial issue is cipe.  CIPE is not getting any development
attention and if it were engaging developer interest this issue might
be simpler to resolve.

Possible development efforts:

[a] Port CIPE to a native linux interface.  This eliminates the
conflict and would allow ndiswrapper to go into Contrib.

[b] Upgrade the protocol, providing options which could provide
better security.

Of course non-CIPE development efforts could also occur, for
example

[c] Other free software could be written which uses the ndiswrapper
interface.

I think we should suggest that such development efforts would be
a good thing for the free software community and that the question
of where ndiswrapper goes be tied to such development efforts.

I think that if none of the above occur, if the current state of affairs
continues to persist, that CIPE be orphaned.  If CIPE remains the
only reason for ndiswrapper to be in main, and no one cares to
address any CIPE issues (either maintaining the current interface
or using a different interface) then eventually it will vanish and
eventually ndiswrapper will need to be moved.

If ndiswrapper becomes a hotbed of cross-platform portable free
software, then it should remain in Main.

If the only software development for CIPE winds up removing the
dependence on ndiswrapper (or if it turns out that CIPE has a
hostile author who forbids that kind of porting) then ndiswrapper
does not belong in Main and should be moved to Contrib.

I think this characterizes the range of potential solutions.  Basically, I
think we could just lay out these alternatives and recommend a wait
and see approach.  (Wait and see whether CIPE represents a
real free software effort or whether it is really just a red herring.)

But maybe there's a better approach that takes into account
these possibilities?

Comments?

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 4/5/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> On 5 Apr 2006, Raul Miller stated:
> > Has someone suggested that we should not build or distribute
> > ndiswrapper?
>
> In Debian? Yes, I think that is exactly what we are talking
>  about.

With qualifications, I guess I can agree that that's what
we're talking about.

Here's the qualifications I currently think are appropriate:

(1) That cipe is recognized as orphaned.  This would be accompanied
with a detailed set of reasons for this decision, and would not be
instantaneous.  The reasons include longstanding issues with
the package, and the lack of attention that they have received.

Orphaning the package would involve several steps.  First, we
should file bug reports detailing these issues.  Second, we
would wait for some period of time to see if the bug reports
are enough to bring development on the package active.  If not,
then the cipe package would be removed from main.

(2) Assuming that we establish that there's no free software
development activities keeping ndiswrapper in main, we move
it to contrib.  It would be distributed from there, and thus not
distributed "in Debian Main".

> I hink that the Quality of implementation would suffer if we
>  disallow this DFSG-compliant software from being a part of Debian.

I'm dubious of that assertion.  I feel that, as stated, it's too
vague to mean anything.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Manoj Srivastava]

On 5 Apr 2006, Raul Miller stated:

> On 4/5/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>> And for what benefit? Just like the FSF started by distributing and
>> build software on non-free systems, putting out software that may
>> initially be more heavily used with non-free input/output is still
>> desirable, since it is a beachhead that can then be exploited for
>> free purposes by someone out there, who may never be exposed to the
>> software in question was its distribution to be severely limited.
>
> Has someone suggested that we should not build or distribute
> ndiswrapper?

In Debian? Yes, I think that is exactly what we are talking
 about. 

> We've suggested that we not consider it an integral part of our
> free operating system, but that doesn't seem to be what you're
> talking about.

No one ias asking it to be an integral part of Debian (like,
 Essential: Yes). We are asking to make it an Optional part of
 Debian.

I see this as software that is free (it meets all aspects of
 the DFSG) that improves the quality of implmentation of the OS by
 allowing user to help themselves in their attempts to make the Debian
 OS run on certain hardware with less than stellar free software
 support.


I hink that the Quality of implementation would suffer if we
 disallow this DFSG-compliant software from being a part of Debian.

manoj
-- 
As well look for a needle in a bottle of hay. Miguel de Cervantes
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 4/5/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> And for what benefit? Just like the FSF started by
>  distributing and build software on non-free systems, putting out
>  software that may initially be more heavily used with non-free
>  input/output is still desirable, since it is a beachhead that can
>  then be exploited for free purposes by someone out there, who may
>  never be exposed to the software in question was its distribution to
>  be severely limited.

Has someone suggested that we should not build or distribute
ndiswrapper?

We've suggested that we not consider it an integral part of our
free operating system, but that doesn't seem to be what you're
talking about.

[P.S. despite the fact that my vote on the GFDL issue put
me in an extreme minority, I do not have a problem with the
outcome of that vote.  But that's better discussed on other
lists.]

--
Raul

Re: Bug#353277: ndiswrapper in main

[Manoj Srivastava]

On 3 Apr 2006, Ian Jackson said:

> Manoj Srivastava writes ("Re: Bug#353277: ndiswrapper in main"):
>> Well, yes. Consider the case that I write up a compiler for a
>> new language in C++ or ruby.  Can I put this compiler in main? Even
>> if there is no public repository of code in this new language?
>
> These arguments seemed entirely mystifying to me until I figured out
> what Manoj is trying to do.
>
> Manoj, you're trying to establish or find a rule which depends only
> on the direction of dependency interrelationships and formal
> copyright status, and other things that can be clearly determined
> without regard to actual existence of any software, usual or
> plausible use cases, and intents of packagers and users.  Am I right
> ?

Yes. I think I am fundamentally skeptical of a process that
 depends on the judgement of people, especially when conducted in an
 environment where such diverse views exist as were evinced in the
 GFDL vote. I also think of the effect it would have on people working
 on software and releasing it under a free license, if the wider
 community branded their work as non-0free anyway, through no fault of
 their own.

If I write a free compiler/emulator/virtual machine generator
 (I actually have an unreleased UML/Xen one), but the only examples I
 can provide are seen to be "toy" ones, or "there are better variants
 already around", why should my work not reach a community of users
 out there? Why would things change if third party decides to use my
 work for non-free purposes?

Adding use cases and samples of third party software into the
 mix makes the classification process brittle, irreproducible, and
 controversial, and may end up penalizing authors of free software who
 want to reach the users in the community through Debian, Ubuntu, and
 other derived distributions.

And for what benefit? Just like the FSF started by
 distributing and build software on non-free systems, putting out
 software that may initially be more heavily used with non-free
 input/output is still desirable, since it is a beachhead that can
 then be exploited for free purposes by someone out there, who may
 never be exposed to the software in question was its distribution to
 be severely limited.

manoj
-- 
If you really want pure ASCII, save it as text... or browse it with
your favorite browser... -- Alexandre Maret <[EMAIL PROTECTED]>
Manoj Srivastava   <[EMAIL PROTECTED]>  <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Ian Jackson]

Manoj Srivastava writes ("Re: Bug#353277: ndiswrapper in main"):
> Well, yes. Consider the case that I write up a compiler for a
>  new language in C++ or ruby.  Can I put this compiler in main? Even
>  if there is no public repository of code in this new language?

These arguments seemed entirely mystifying to me until I figured out
what Manoj is trying to do.

Manoj, you're trying to establish or find a rule which depends only on
the direction of dependency interrelationships and formal copyright
status, and other things that can be clearly determined without regard
to actual existence of any software, usual or plausible use cases, and
intents of packagers and users.  Am I right ?

I think this is a mistake.  It's obvious what the real difference is
between these situations.  A compiler is frequently used for learning
about the language, for writing and running programs locally, and
other such things.  While these are possible uses for ndiswrapper
no-one is seriously suggesting that they are _sensible_ uses for
ndiswrapper.

You wouldn't use ndiswrapper to learn about the NDIS interface, even
though that's theoretically possible, and you wouldn't use it for
developing and running network drivers locally.  The reasons for this
are contextual and in many respects in principle subjective - but
no-one is disputing these facts.

Just because an interpretation or a principle requires us to make a
subjective value judgement, or look at the intent behind something, or
look at the surrounding ecology of software, doesn't mean that it's a
bad principle.  After all, trying to make the best judgement when the
situation is subjective and/or unclear is bread and butter for
programmers !

> The only argument I have seen so far seems to imply that I
>  can't package up new emulators  or compilers unless I also provide
>  free source code for these to process, I am not sure I think that
>  expands freedom in any tangible manner.

You can package up new emulators or compilers if it's reasonable to
suppose that the user might install it _to run home-grown `content'_.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/29/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> Does the fact we are boith ignorant mean that the authors and
>  users of ndiswrapper be penalized?

Yes!

...ok, I don't mean exactly that, but I don't reject it either.

Fundamentally, the only thing that keeps me from releasing a GPLed
work-alike for ANY piece of non free-software (let's say Windows
Vesta, if you want a concrete example) is my ignorance of how it works
and what it does.

This issue also holds for supplying the dependencies of software in
Contrib.

> I don't know how to use a large number of interpreters and
> compilers in Debian (scheme, python,  ...). Presumably,
> you, too, are not omniscient (If you are, I do apologize, god).
> If there is an intersection of these sets, should it have a
> bearing on the freeness of the packages that live in that
> intersection?

I'm not asking for omniscience, nor any other signs of god-ness.

The technical issue, I think, is: is the package complete in and of
itself?  If not, does Main contain what the package needs to make it
complete.

If we have libpureschemeeval.0.1.so which implements a complete scheme
interpreter, which only supports the dotted pair data-structure and
requires everything else to be implemented in the calling environment
(parsing, garbage collection, result formatting, ...), that's fine.

If, however, after some number of years, no one is using it (perhaps,
among other reasons, because it doesn't exactly implement the right
semantics), I'd be rather dubious about why we have the package at
all.

If, in addition, there are a number of users of the package, and all
of them use it to wire gcc up to Microsoft's SQL Server, so it runs
under linux, I'd be very very uncomfortable about this package.

I'd feel much better about it if either (a) it was used actively for
some obvious free software purpose, or (b) it was pulled from the
distribution.

Then again, I don't think we (the technical committee) would have the
authority to pull the package.  But I also don't think we should give
this kind of situation unqualified approval.

> > I don't understand why that means it's not in your universe.
>
> Cause I am all fere and pure, dude. Do try to keep up :)

Hmm... let me try again:  I don't think your keyboard and display are
in your universe.  So what I want to know is: who do you get to do
your typing for you?

--
Raul

Re: Bug#353277: ndiswrapper in main

[Manoj Srivastava]

On 29 Mar 2006, Raul Miller said:

> On 3/29/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
>>> 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.
>
> Here's an example of the user providing input for gcc:
>
> $ cat >example.c < #include 
> main() {
>   printf("%g\n", 3.14159*7*7);
> }
> END
> $ gcc example.c -o example; ./example
> 153.938
>
> I don't know how to do something like this with ndiswrapper.
>
> Since I'm ignorant, could you provide an example?

Does the fact we are boith ignorant mean that the authors and
 users of ndiswrapper be penalized? I don't know how to use a large
 number of interpreters and compilers in Debian (scheme, python,
 ...). Presumably, you, too, are not omniscient (If you are, I do
 apologize, god). If there is an intersection of these sets, should it
 have a bearing on the freeness of the packages that live in that
 intersection?


 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.
>
> I don't understand why that means it's not in your universe.

Cause I am all fere and pure, dude. Do try to keep up :)

manoj
-- 
"One man's mate is another man's passion." Jeff Daiell's description
of adultery
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/29/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> > 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.

Here's an example of the user providing input for gcc:

$ cat >example.c <
main() {
printf("%g\n", 3.14159*7*7);
}
END
$ gcc example.c -o example; ./example
153.938

I don't know how to do something like this with ndiswrapper.

Since I'm ignorant, could you provide an example?

> >> 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.

I don't understand why that means it's not in your universe.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Manoj Srivastava]

On 29 Mar 2006, Raul Miller spake thusly:

> On 3/28/06, Manoj Srivastava <[EMAIL PROTECTED]> 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   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/28/06, Manoj Srivastava <[EMAIL PROTECTED]> 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?

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

Shouldn't we be focusing on development issues here?

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

> 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?

> Also, you need to look at how many future efforts you are
>  encouraging -- or discouraging -- by your treetment of this  freely
>  licensed module wrapping tool chain.

I agree on this point.

> 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?

--
Raul

Re: Bug#353277: ndiswrapper in main

[Manoj Srivastava]

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.

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"

Also, you need to look at how many future efforts you are
 encouraging -- or discouraging -- by your treetment of this  freely
 licensed module wrapping tool chain.

If ndiswrapper is not in my universe, I may never get around
 to writing fee windows drivers that could also be used on Linux :)

manoj
 not happy about the quote picking ai
-- 
Every absurdity has a champion who will defend it.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/27/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> On 26 Mar 2006, Raul Miller told this:
> > The ambiguity is in the resolution's interpretation of the quoted
> > policy:
> >
> > ...  must not require a package outside of _main_ for
> > compilation or  execution ...
> >
> > Does no-operation or substandard operation satisfy requirements for
> > execution?
>
> Well, yes. Consider the case that I write up a compiler for a
>  new language in C++ or ruby.  Can I put this compiler in main? Even
>  if there is no public repository of code in this new language?

That seems to me to be different.  The compiler does not require anything
special to be installed to use its full capacity.  It needs content, but the
content would typically be supplied by the person using the computer.

If the primary purpose of the "compiler" were to "compile" some pre-packaged
content from commercial vendors, then that would be a good analogy.  But
I doubt that that's what you meant.

> What if it was not a compiler, but an emulator of a virtual
>  machine?  Until there is code that can run on the virtual machine,
>  there is nothing for the emulator to show.

This is getting closer to the circumstance I think we're dealing
with here.

Note also that we have put a number of virtual machine emulators
in Config for this very reason (game console emulators).

> The only argument I have seen so far seems to imply that I
>  can't package up new emulators  or compilers unless I also provide
>  free source code for these to process, I am not sure I think that
>  expands freedom in any tangible manner.

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?

--
Raul

Re: Bug#353277: ndiswrapper in main

[Manoj Srivastava]

On 26 Mar 2006, Raul Miller told this:

> The ambiguity is in the resolution's interpretation of the quoted
> policy:
>
> ...  must not require a package outside of _main_ for
> compilation or  execution ...
>
> Does no-operation or substandard operation satisfy requirements for
> execution?

Well, yes. Consider the case that I write up a compiler for a
 new language in C++ or ruby.  Can I put this compiler in main? Even
 if there is no public repository of code in this new language?

My sense is yes, a compiler does not need the presence of code
 in order to be free --  as long as the license of the code itself is
 free.

Should this change if I were to put code out there in the new
 language under a non-free license? I think not. Should things change
 again if I put freely licensed code on a web page? If I packaged that
 code for Debian?  In my opinion, no.

What if it was not a compiler, but an emulator of a virtual
 machine?  Until there is code that can run on the virtual machine,
 there is nothing for the emulator to show.

ndiswrapper seems to fall into similar situation: 
 /usr/sbin/ndiswrapper -i filename.inf
 /usr/sbin/ndiswrapper -l 
 /usr/sbin/ndiswrapper -m
 depmod -a 
 modprobe ndiswrapper

Looks very similar to a tool chain invocation: compile, link,
 install.

The only argument I have seen so far seems to imply that I
 can't package up new emulators  or compilers unless I also provide
 free source code for these to process, I am not sure I think that
 expands freedom in any tangible manner.

manoj
-- 
"Language shapes the way we think, and determines what we can think
about." Whorf
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/25/06, Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> On 22 Mar 2006, Anthony Towns stated:
> > On Mon, Mar 13, 2006 at 03:28:50PM -0500, Raul Miller wrote:
> >> On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> >>> Why does contrib exist ?
> >> [essay elided.]
> >
> > So is there an alternate proposal to
> >
> > http://lists.debian.org/debian-ctte/2006/03/msg00037.html
> >
> > so we can have a vote and make a decision? AFAICS we've discussed
> > this pretty thoroughly.
>
> I am going to be out of town for the latter half of next week,
>  so if a vote comes up when I am gone,  I support the resolution in
>  the mail:
> http://lists.debian.org/debian-ctte/2006/03/msg00037.html
>
> I am not sure I see that it is at variance with published
>  policy, nor do I see why it makes contrib ambiguous, really.

The ambiguity is in the resolution's interpretation of the quoted policy:

  ...  must not require a package outside of _main_ for
  compilation or  execution ...

Does no-operation or substandard operation satisfy requirements for
execution?

One argument in favor of the above resolution is that if no operation
is documented as a part of the ABI, that is sufficient for these
requirements.

But this concept is not expressed in policy, and it's just as reasonable
to require normal operation be possible to satisfy requirements for
execution.

Another argument put forward in favor of the above resolution is that
if no software has been packaged, this policy is irrelevant as the
requirements are for non-packaged software.

But this argument seems more dubious than the "no operation is sufficient
for the typical case" concept.

The final, and perhaps most convincing argument in favor of ndiswrapper
is that it allows the use of CIPE.  But CIPE seems flawed, and oddly
enough the most recent in-depth coverage of these issues seems old:
http://lists.grok.org.uk/pipermail/full-disclosure/2003-September/010864.html

The last release of cipe (1.6.0) was in 2004.  The last debian update
to the cipe package (1.5.4) was in 2004.  There's not even an option
to use anything better than a 32 bit checksum for integrity purposes
(which is one of the more egregious security flaws in cipe).

Poking around a bit more, it looks like people have mostly abandoned
cipe for stuff like openvpn (which we also distribute).

I see no evidence that anyone cares enough about the cipe package to
justify it being in main.  If CIPE is the reason we have ndiswrapper in
main, I think we're doing our users a disfavor.

I'm not aware of any other arguments in favor of that resolution which
satisfy this policy.

Is "we should be distributing CIPE in main" really the reason for keeping
ndiswrapper in main?  or is there some better argument?

If there is such an argument, I'd like to understand it before I make a
proposal based on the idea that there are no better arguments in favor
of this resolution.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Manoj Srivastava]

On 22 Mar 2006, Anthony Towns stated:

> On Mon, Mar 13, 2006 at 03:28:50PM -0500, Raul Miller wrote:
>> On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
>>> Why does contrib exist ?
>> [essay elided.]
>
> So is there an alternate proposal to
>
> http://lists.debian.org/debian-ctte/2006/03/msg00037.html
>
> so we can have a vote and make a decision? AFAICS we've discussed
> this pretty thoroughly.

I am going to be out of town for the latter half of next week,
 so if a vote comes up when I am gone,  I support the resolution in
 the mail:
http://lists.debian.org/debian-ctte/2006/03/msg00037.html

I am not sure I see that it is at variance with published
 policy, nor do I see why it makes contrib ambiguous, really.

manoj
-- 
The existence of god implies a violation of causality.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Fri, Mar 24, 2006 at 04:22:32PM -0500, Raul Miller wrote:
> On 3/23/06, Anthony Towns  wrote:
> > On Mon, Mar 13, 2006 at 03:28:50PM -0500, Raul Miller wrote:
> > > On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> > > > Why does contrib exist ?
> > > [essay elided.]
> > So is there an alternate proposal to
> > http://lists.debian.org/debian-ctte/2006/03/msg00037.html
> > so we can have a vote and make a decision? AFAICS we've discussed this
> > pretty thoroughly.
> I think your proposal conflicts with published policy, and with the obvious
> purpose of "Config". 
  ^^  ("Contrib", presumably)

I don't agree with either of those claims, though. It seems to me that
the way to express that disagreement would be for you to have a proposal
you support and to vote for that.

Cheers,
aj


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/23/06, Anthony Towns  wrote:
> On Mon, Mar 13, 2006 at 03:28:50PM -0500, Raul Miller wrote:
> > On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> > > Why does contrib exist ?
> > [essay elided.]
>
> So is there an alternate proposal to
>
> http://lists.debian.org/debian-ctte/2006/03/msg00037.html
>
> so we can have a vote and make a decision? AFAICS we've discussed this
> pretty thoroughly.

I'm not sure what you mean by "pretty thoroughly":

The proposal you cited does not address any of the issues raised in
the essay I elided.

I think your proposal conflicts with published policy, and with the obvious
purpose of "Config". I don't feel so strongly about that that I don't see
your point of view, but I do think that your proposal should be amended
so that it addresses this issue (conflict, ambiguity, whatever) in some
way.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Mon, Mar 13, 2006 at 03:28:50PM -0500, Raul Miller wrote:
> On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> > Why does contrib exist ?
> [essay elided.]

So is there an alternate proposal to

http://lists.debian.org/debian-ctte/2006/03/msg00037.html

so we can have a vote and make a decision? AFAICS we've discussed this
pretty thoroughly.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> Why does contrib exist ?

[essay elided.]

I've been trying to think about this from other points of view, with
the idea of suggesting policy changes that would allow ndiswrapper
to remain in main.

I haven't found any such reasoning which I'm happy with.

Put differently:

(1) I agree with the reasoning you expressed last week.

(2) I think that any dissenting opinion should include
a policy change recommendation (with associated
reasoning).

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raphael Hertzog]

On Thu, 09 Mar 2006, Raul Miller wrote:
> On 3/9/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > Technical arguments why ndiswrapper should be in main:
> >
> > - availability to users with the default sources.list
> > - availability from within the installer
> > - availability from the unmodified Debian CD images
> >
> > Technical arguments why ndiswrapper should be in contrib: ?
> 
> "unmoified Debian CD images"?
> 
> It seems to me that everything in contrib should be distributed
> on CD.  This doesn't match existing practice -- perhaps because
> we've kept useful stuff out of contrib?

AFAIK, if it didn't change since when I was more active with debian-cd,
everything in contrib is on the CD _IF_ the dependencies can be
fullfilled (without non-free of course).

So technically most of contrib is not on CD (because it depends on
unavailable packages).

However I have to agree with Steve, if we want the installer to be able to
hook with ndiswrapper and not be bothered with the need to create
"modified CD images", we should definitely keep ndiswrapper in main simply
because contrib is not an official part of Debian (and since our current
policy is already to *not* have contrib in sources.list by default).

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/9/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> Technical arguments why ndiswrapper should be in main:
>
> - availability to users with the default sources.list
> - availability from within the installer
> - availability from the unmodified Debian CD images
>
> Technical arguments why ndiswrapper should be in contrib: ?

"unmoified Debian CD images"?

It seems to me that everything in contrib should be distributed
on CD.  This doesn't match existing practice -- perhaps because
we've kept useful stuff out of contrib?

--
Raul

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Wed, Mar 08, 2006 at 11:35:23AM +, Ian Jackson wrote:
> Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> > On Tue, Mar 07, 2006 at 07:39:01PM +, Ian Jackson wrote:
> > > Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> > > > [draft resolution]
> > > I'm afraid I think that that's quite out of order.
> > > Constitution s6.3(3):
> > >   3. Public discussion and decision-making.
> > >  Discussion, draft resolutions and amendments, and votes by
> > >  members of the committee, are made public on the Technical
> > >  Committee public discussion list. There is no separate secretary
> > >  for the Committee.
> > The "tweaks" stuff were "draft resolutions" too, though... I don't see how
> > it's feasible to have the rule be we can't do drafting work here, rather
> > than just be "any drafting work we do here has no constitutional meaning".
> Our discussions, which include drafting work, are supposed to be
> public.  The Committee isn't supposed to hide in secret and then come
> out with decisions.  `Discussion  [is] made public ...'.
> The `tweaks' stuff is to do with how the committee operates, and was
> similar enough to the question of appointments (which we can discuss
> in secret) that I let it slide.

Hrm, alright. Then I guess in future I don't think we should let that
slide. And hey, if we're going to have a rotating chair, appointments
don't matter much either and we could drop the -private list entirely :)

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Steve Langasek]

On Tue, Mar 07, 2006 at 11:36:49PM +, Ian Jackson wrote:
> I would like to draft a version of Anthony's answer that makes it a
> recommendation rather than a mandatory decision.  In fact, we probably
> need four versions:

>  * We think it's our decision and we decide (insisting iff 3:1)
>that it should go into main
>  * We think it's our decision and we decide (insisting iff 3:1)
>that it should go into contrib
>  * We think it's not our decision formally but we conclude
>that it should go into main
>  * We think it's not our decision formally but we conclude
>that it should go into contrib

> It will be easier to draft those four alternatives than to have
> everyone write round and say which ones they prefer.

FWIW, I'm not a fan of synthetic ballot options.  Wouldn't it make better
use of people's time in the drafting to limit ourselves to those options
that at least one of the drafters is actually planning to vote above FD?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Steve Langasek]

On Wed, Mar 08, 2006 at 12:49:58AM +, Ian Jackson wrote:
> Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> > WHEREAS

> I'd like to expand somewhat on my `no' vote.  Many of the questions
> here were addressed by my earlier messages and I will try to avoid
> repeating myself.

> > 5.  The technical policy in this matter states that: (debian-policy
> > 3.6.2.2, section 2.2.1)

> As I have said before, this is not `technical policy'.  I don't know
> where you get the phrase `technical policy' from.  Even if the Policy
> Manual is largely technical, that doesn't mean that everything in it
> is technical.

 6.1. Powers

 The Technical Committee may:

   1. Decide on any matter of technical policy.

  This includes the contents of the technical policy manuals,
 developers' reference materials, example packages and the behaviour of
 non-experimental package building tools. (In each case the usual maintainer
 of the relevant software or documentation makes decisions initially,
 however; see 6.3(5).)

I accept that there may be things in the Debian policy manual (i.e., the
"technical policy manual") that you feel don't belong there.  But if you
agree that the distinction between main and contrib belongs in Policy, then
I don't see how you can argue that it's at the same time non-technical; and
if it doesn't belong in Policy, then where does it belong?

> Whether a question is technical or political doesn't just depend on
> the outcome, and it doesn't depend at all on what you call the
> documents (if any) that form the basis for the decision.  It depends
> on the _reasons_ which will govern the decision.

So by this reasoning, any decision in which one or more options are
eliminated from consideration due to the social contract is necessarily
political and therefore not technical?  That doesn't sit right with me; as
long as we're not attempting to change political policies, I don't see any
reason it's out of scope for us to make technical decisions (or I guess you
would say, decisions about technicalities...) that are informed by the
established political policy.

> Can you explain to me why anyone might think that there was a
> _technical_ reason for ndiswrapper to be in either main or contrib ?
> That is, a reason to do with making the system function better, or be
> easier to install, or less buggy, or some such ?  That's what a
> technical reason is, and if there were technical reasons in this
> question then it would be a technical decision (and we would be
> spending our effort establishing the facts, not chopping semantic
> logic).  But there aren't.

Technical arguments why ndiswrapper should be in main:

- availability to users with the default sources.list
- availability from within the installer
- availability from the unmodified Debian CD images

Technical arguments why ndiswrapper should be in contrib: ?

So there certainly is a technical decision to be made; the major question is
whether the social contract *allows* us to make it.  In this way, I think I
agree with you: I don't think it would be appropriate for us to overrule the
maintainer on the grounds that we think the social contract requires the
package to be in contrib, because it's not our place to interpret the social
contract.  But that doesn't mean it's disallowed by the constitution: 6.1.4.
says that the committee may overrule a Developer to force a particular
technical course of action, and it does *not* say that the committee's
motives in doing so must be limited to purely technical considerations.

> One possible view of the situation is that policy states a political
> decision in terms of technical properties of programs, but it's quite
> clear that the part we're relying on trying to interpret is at least
> badly ambiguous or underspecified given that different people think
> that it `clearly' means quite different things !

> > 11. The committee endorses the existing policy on the suitability of 
> > packages
> > for the main and contrib components; and

> Surely the existing policy is vague and definitely needs to be
> clarified.  Otherwise why are we having this conversation at all ?

> If the policy needs to be clarified, and it is within the committee's
> power to clarify it, then the committee should do so !  So, please
> suggest your proposed wording.

Well, I suspect that any wording we would suggest as a replacement would
have its own subtle ambiguities, so I'm not convinced the benefits outweigh
the costs of doing so.  I'm interested to see what AJ thinks here, though,
as the drafter of the resolution that I agree with; perhaps he has some
ideas on improving this wording.  More likely,

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/8/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> Raul Miller writes ("Re: Bug#353277: ndiswrapper in main"):
> > On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> > > In our opinion the relevant principle is that:
> > >
> > >  (i) If the user or administrator who is in charge of the Debian
> > >installation would have to adopt non-free software X to make
> > >sensible use of free software Y, then Y goes in contrib.
> >
> > Existing policy says something similar for free software X which
> > has not been packaged in main, for whatever reason.
>
> Are you saying wine should be in contrib ?  No-one seemed to be
> arguing that it should be until we had this conversation ...

I'm not sure whether it should be there or not.

It seems to me that reasonable readings of section 2.2.1 of
current policy would suggest that WINE belongs in Contrib, and
that reasonable readings of this same policy would suggest that
WINE belongs in Main.

Personally, I'm ambivalent about the subject.  I believe that the
typical user of WINE will already have contrib in /etc/apt/sources.list,
and I see no problems with putting WINE in contrib beyond the
usual "it's a change" issues.

For that matter, last time I looked at WINE, you had to edit
/etc/wine.conf (or .winerc) before it could be used.  This
suggests to me that the wine development folks would look
poorly on the idea that we might want to have debian
packages which provide tools for use inside the wine
environment.  Of course, that could change in the future, but
I'm not sure it's a good idea to make packaging decisions on
what could happen in the future while ignoring the present
state of affairs.

But just as I see no problem with moving WINE to config, and
I see advantages to that, I also see no immediate problems
with leaving WINE in main.

> > For example, some people might think that early versions of
> > PINE are free, but Debian has declined to package them.
> > Despite the text of the license, there is a threat of harassment
> > by the University of Washington, and I think we have a fairly
> > strong consensus that supporting PINE just isn't worth the
> > bother.
>
> Err, probably this just means that no-one can be bothered to be the
> maintainer ?

That, too.

> > We can have other reasons for not including free software in
> > Main.  I believe packages belong in Contrib if they rely on the
> > installation of software we're not likely to package.
>
> You have to say something more subtle if you want to leave wine in
> main.  It seems that our current policy depends on whether the
> non-packaged software is not packaged because of its legal or
> political status, or for some technical reason (eg, consider the free
> Windows accounting suite someone mentioned).

That may indeed be our actual policy.

However, these issues don't seem to be spelled out very clearly
in the policy manual.  And if there's a significant gray area where
it's package maintainer's discretion, then that should be spelled
out as well.

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Andreas Barth]

* Ian Jackson ([EMAIL PROTECTED]) [060308 18:32]:
> You have to say something more subtle if you want to leave wine in
> main.  It seems that our current policy depends on whether the
> non-packaged software is not packaged because of its legal or
> political status, or for some technical reason (eg, consider the free
> Windows accounting suite someone mentioned).

I read our current policy different (at least the release policy): A
package could only be in main if all of its (build-)dependencies can be
fullfiled in main, and if it is free itself. Otherwise, it goes to
contrib (if free) or non-free (if at least distributable).

IOW, there is no difference if a dependency was kicked out from main for
being buggy, or if the dependency sits in non-free.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Ian Jackson]

Raul Miller writes ("Re: Bug#353277: ndiswrapper in main"):
> On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> > In our opinion the relevant principle is that:
> >
> >  (i) If the user or administrator who is in charge of the Debian
> >installation would have to adopt non-free software X to make
> >sensible use of free software Y, then Y goes in contrib.
> 
> Existing policy says something similar for free software X which
> has not been packaged in main, for whatever reason.

Are you saying wine should be in contrib ?  No-one seemed to be
arguing that it should be until we had this conversation ...

> For example, some people might think that early versions of
> PINE are free, but Debian has declined to package them.
> Despite the text of the license, there is a threat of harassment
> by the University of Washington, and I think we have a fairly
> strong consensus that supporting PINE just isn't worth the
> bother.

Err, probably this just means that no-one can be bothered to be the
maintainer ?

> We can have other reasons for not including free software in
> Main.  I believe packages belong in Contrib if they rely on the
> installation of software we're not likely to package.

You have to say something more subtle if you want to leave wine in
main.  It seems that our current policy depends on whether the
non-packaged software is not packaged because of its legal or
political status, or for some technical reason (eg, consider the free
Windows accounting suite someone mentioned).

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> I have overhauled and extended my old draft.  See below, and please
> comment.

I think you've presented the the issues clearly.  However there is
one point that I think warrants more attention:

> In our opinion the relevant principle is that:
>
>  (i) If the user or administrator who is in charge of the Debian
>installation would have to adopt non-free software X to make
>sensible use of free software Y, then Y goes in contrib.

Existing policy says something similar for free software X which
has not been packaged in main, for whatever reason.

For example, some people might think that early versions of
PINE are free, but Debian has declined to package them.
Despite the text of the license, there is a threat of harassment
by the University of Washington, and I think we have a fairly
strong consensus that supporting PINE just isn't worth the
bother.

We can have other reasons for not including free software in
Main.  I believe packages belong in Contrib if they rely on the
installation of software we're not likely to package.

Other than this one issue, I agree with the points you've
expressed in your draft.

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Ian Jackson]

I have overhauled and extended my old draft.  See below, and please
comment.  I'm not formally proposing this just yet.  We should vote on
the alternatives together.

The draft below, broadly speaking:
 * is advisory
 * says `contrib'

Note that I'm going to be away from my email from Saturday the 11th to
Sunday the 19th inclusive, and will have a huge backlog when I get
back.  I'll try to prioritise the committee list and at least read and
vote.

Ian.


BACKGROUND

1. The committee has been asked to rule on the question of whether
   ndiswrapper should be in the `main' or `contrib' component of the
   archive.

2. There are no technical reasons for ndiswrapper to be in main; nor
   any for it to be in contrib.  The Debian system and our own
   development processes will work just as well either way.

3. ndiswrapper's purpose is to allow non-Debian (and typically
   non-free) drivers to be used.

4. While there may be cases where ndiswrapper can be used with a
   DFSG-free driver, these are exceptional and contrived, and none of
   these drivers are available in Debian main.

5. We do not wish to overturn or change what we regard as established
   political policy about the distinction between main and contrib,
   and we do not wish to usurp the political authority of the Project
   Leader or other Developers.

6. In the past, when the Committee has declined to issue an opinion
   and instead simply passed nontechnical decisions to the Project
   Leader and Delegates, no decision at all was forthcoming.

OPINION

7. This is not a technical issue, so does not fall into our explicit
   remit.  However the Project would benefit from a clear statement of
   opinion by a decisionmaking body, even if it is only advisory.

8. Our reading of the current Policy Manual wording is that
   ndiswrapper falls fairly clearly into the area currently defined
   for `contrib'.

9. We are by and large satisfied with the intent behind the language
   in the Policy Manual regarding the distinction between non-free and
   contrib.  However, the language in the Policy Manual is somewhat
   unclear and ambiguous, and by some readings inconsistent.

CONCLUSIONS

10. ndiswrapper belongs in contrib.

11. References to `package outside of main', `packages which are not
   in our archive at all', etc., in the relevant part of the Policy
   Manual, should be changed to refer to `programs' or `software'.

12. The policy manual should be clarified to make it clear that free
   software to talk to non-free software over a network can remain in
   main.  In our opinion the relevant principle is that:

 (i) If the user or administrator who is in charge of the Debian
   installation would have to adopt non-free software X to make
   sensible use of free software Y, then Y goes in contrib.

 (ii) However, if free software Y is used by the user or administrator
   of the Debian system to cope to with someone else's use of non-free
   software X on another system not under their control, then Y goes
   in main.

REQUESTS

13. ftpmasters and the ndiswrapper maintainers should cooperate to move
   nsidwrapper to contrib.

14. The Policy Manual maintainers should take steps to adjust the
   language regarding main and contrib to clarify and improve it.  The
   Maintainers should have regard to any opinions from other
   Developers, in particular the Leader, about the correct effect.

15. This decision is advisory; we are exercising only our power to
   offer advice (Constitution 6.1 clause 5).  However, we strongly
   recommend that all parties concerned follow our advice unless and
   until a contrary statement is issued by the Project Leader or
   Delegate(s) (such as the ftpmaster team).

THANKS

15. Thanks to Robert Millan for raising the issue; to Wouter Verhelst
   and others for their input on the topic; and to Andres Salomon for
   his ongoing efforts in maintaining the ndiswrapper packages.

16. Thanks also to everyone involved in this discussion for the civil,
   clear and constructive manner in which the argument has been
   conducted.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Ian Jackson]

Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> On Tue, Mar 07, 2006 at 07:39:01PM +, Ian Jackson wrote:
> > Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> > > [draft resolution]
> > I'm afraid I think that that's quite out of order.
> > Constitution s6.3(3):
> >   3. Public discussion and decision-making.
> >  Discussion, draft resolutions and amendments, and votes by
> >  members of the committee, are made public on the Technical
> >  Committee public discussion list. There is no separate secretary
> >  for the Committee.
> 
> The "tweaks" stuff were "draft resolutions" too, though... I don't see how
> it's feasible to have the rule be we can't do drafting work here, rather
> than just be "any drafting work we do here has no constitutional meaning".

Our discussions, which include drafting work, are supposed to be
public.  The Committee isn't supposed to hide in secret and then come
out with decisions.  `Discussion  [is] made public ...'.

The `tweaks' stuff is to do with how the committee operates, and was
similar enough to the question of appointments (which we can discuss
in secret) that I let it slide.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Tue, Mar 07, 2006 at 07:39:01PM +, Ian Jackson wrote:
> Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> > [draft resolution]
> I'm afraid I think that that's quite out of order.
> Constitution s6.3(3):
>   3. Public discussion and decision-making.
>  Discussion, draft resolutions and amendments, and votes by
>  members of the committee, are made public on the Technical
>  Committee public discussion list. There is no separate secretary
>  for the Committee.

The "tweaks" stuff were "draft resolutions" too, though... I don't see how
it's feasible to have the rule be we can't do drafting work here, rather
than just be "any drafting work we do here has no constitutional meaning".

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Ian Jackson]

Raul Miller writes ("Re: Bug#353277: ndiswrapper in main"):
> On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> > Here is a version of Anthony's `put it in main' resolution made into a
> > suggestion rather than an instruction.  Below you'll find a diff for
> > your comfort and convenience.
> 
> I vote against this proposal for the same reasons I voted against
> the original.

Err, I wasn't proposing it for voting on.  I should be clearer.

> Alternatively, if we're going to have a proper ballot listing several
> different options, I'll be voting further discussion ahead of both
> this proposal and Aj's original.

Indeed so.

Ina.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Ian Jackson]

Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> WHEREAS

I'd like to expand somewhat on my `no' vote.  Many of the questions
here were addressed by my earlier messages and I will try to avoid
repeating myself.


> 5.  The technical policy in this matter states that: (debian-policy
> 3.6.2.2, section 2.2.1)

As I have said before, this is not `technical policy'.  I don't know
where you get the phrase `technical policy' from.  Even if the Policy
Manual is largely technical, that doesn't mean that everything in it
is technical.

Whether a question is technical or political doesn't just depend on
the outcome, and it doesn't depend at all on what you call the
documents (if any) that form the basis for the decision.  It depends
on the _reasons_ which will govern the decision.

Can you explain to me why anyone might think that there was a
_technical_ reason for ndiswrapper to be in either main or contrib ?
That is, a reason to do with making the system function better, or be
easier to install, or less buggy, or some such ?  That's what a
technical reason is, and if there were technical reasons in this
question then it would be a technical decision (and we would be
spending our effort establishing the facts, not chopping semantic
logic).  But there aren't.


Another way to look at it is this: we are looking narrowly at the text
of the policy manual.  Why are we doing that ?  Normally the committee
doesn't take the policy manual as some kind of handed-down guidance.
The committee is in charge of policy, not vice versa, so that the
policy manual doesn't constrain or bind the committee at all (that's
not to say that we should just overturn it willy-nilly of course!).
So, normally we consider first what the right answer is in the
particular situation and if necessary we will rewrite policy to fit.

The reason we aren't doing this is that we recognise that if we
rewrote the section of policy dealing with main vs contrib we would be
making a political decision.

One possible view of the situation is that policy states a political
decision in terms of technical properties of programs, but it's quite
clear that the part we're relying on trying to interpret is at least
badly ambiguous or underspecified given that different people think
that it `clearly' means quite different things !


> 11. The committee endorses the existing policy on the suitability of packages
> for the main and contrib components; and

Surely the existing policy is vague and definitely needs to be
clarified.  Otherwise why are we having this conversation at all ?

If the policy needs to be clarified, and it is within the committee's
power to clarify it, then the committee should do so !  So, please
suggest your proposed wording.


Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/7/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> Here is a version of Anthony's `put it in main' resolution made into a
> suggestion rather than an instruction.  Below you'll find a diff for
> your comfort and convenience.

I vote against this proposal for the same reasons I voted against
the original.

Alternatively, if we're going to have a proper ballot listing several
different options, I'll be voting further discussion ahead of both
this proposal and Aj's original.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/6/06, Anthony Towns  wrote:
> 3.  The purpose of the ndiswrapper package is to provide an ABI layer
> on top of the Linux kernel that is compatible with the interface for
> Windows NDIS drivers, and that in order to provide this compatability
> layer, no non-free software is required; and

This is a purpose, but not the sole purpose.

This seems clearly established in the proposal:

> 4.  The primary use for this compatability layer is to run non-free
> Windows drivers for hardware not directly supported by Linux, though
> a very limited number of free drivers using the NDIS format also
> exist; and
>
> 5.  The technical policy in this matter states that: (debian-policy
> 3.6.2.2, section 2.2.1)
>
>[...] packages in _main_
>   * must not require a package outside of _main_ for compilation or
> execution

If "execution" means typical execution (as opposed to some kind of
failure condition or something else which would not be acceptable for
a normal user of the package), then I think it's clear that in the
minds of almost everyone who installs ndiswrapper, non-free Windows
drivers are required for execution of ndiswrapper.

> and: (debian-policy 3.6.2.2, section 2.2.2)
>
>Examples of packages which would be included in _contrib_ are:
> * free packages which require _contrib_, _non-free_ packages or
>   packages which are not in our archive at all for compilation or
>   execution, and
> * wrapper packages or other sorts of free accessories for non-free
>   programs.

As the normal use of ndiswrapper requires software which has not been
packaged for main, and as ndiswrapper is primarily to make these non
free drivers useful, I think it's sufficiently close to the above
examples.

> THE COMMITTEE CONCLUDES THAT
>
> 6.  It is appropriate for the committee to consider this request; and
>
> 7.  The current ndiswrapper package does not require any non-free
> software at either compilation time or installation time to fulfill
> its designated purpose; and

Point 7 seems to require we ignore points 4 and 5, and accept point
3 as describing the normal use of ndiswrapper.

> 8.  As such the ndiswrapper package complies with current technical
> policy as regards to its suitability for main; and
>
> 9.  If the ndiswrapper package come to depend on non-free software at
> compilation time or installation time, such as by prompting the user
> for a Windows driver CD, at that time the ndiswrapper package would
> be required to be moved to contrib.

If this a salient point, then 2.2.1 should be changed to read
"must not require a package outside of _main_ for compilation or installation"
instead of the current
"must not require a package outside of _main_ for compilation or execution"

> IN ADDITION
>
> 10. The committee endorses the decisions of the maintainer of ndiswrapper
> and the ftpmaster team in including the package in the main component
> as being in compliance with Debian technical policy; and
>
> 11. The committee endorses the existing policy on the suitability of packages
> for the main and contrib components; and

It seems to me that either

[1] we should be recommending policy be changed (so that it's clear that
execution requirements of nearly all users is not relevant  when
determining whether a package belongs in contrib, and perhaps removing
the reference to "wrapper packages" or perhaps providing a definition
which clearly excludes ndiswrapper), or

[2] we should be recommending a different course of action with
ndiswrapper.

I vote against this proposal.

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Ian Jackson]

Here is a version of Anthony's `put it in main' resolution made into a
suggestion rather than an instruction.  Below you'll find a diff for
your comfort and convenience.

WHEREAS

1.  The committee has been asked by Robert Millan, the submitter of
Bug#353278 and a former developer, to overrule the decision by the
maintainer of the ndiswrapper package, Andres Salomon, to include
that package in the main component of the archive, and for it to be
moved to the contrib component; and

2.  This question is a mixture of political and technical questions
and the Committee's power to decide it is unclear; however, in the
absence of a decision by the committee it is likely that no
decision at all will be made.

3.  The purpose of the ndiswrapper package is to provide an ABI layer
on top of the Linux kernel that is compatible with the interface for
Windows NDIS drivers, and that in order to provide this compatability
layer, no non-free software is required; and

4.  The primary use for this compatability layer is to run non-free
Windows drivers for hardware not directly supported by Linux, though
a very limited number of free drivers using the NDIS format also
exist; and

5.  The policy in this matter states that: (debian-policy
3.6.2.2, section 2.2.1)

   [...] packages in _main_ 
  * must not require a package outside of _main_ for compilation or
execution

and: (debian-policy 3.6.2.2, section 2.2.2)

   Examples of packages which would be included in _contrib_ are:
* free packages which require _contrib_, _non-free_ packages or
  packages which are not in our archive at all for compilation or
  execution, and
* wrapper packages or other sorts of free accessories for non-free
  programs.

THE COMMITTEE CONCLUDES THAT

6.  It is appropriate for the committee to consider this request
but not by itself to overturn established political policy; and

7.  The current ndiswrapper package does not require any non-free
software at either compilation time or installation time to fulfill
its designated purpose; and 

8.  As such the committee believes the ndiswrapper package complies
with current policy as regards to its suitability for main; and

9.  If the ndiswrapper package comes to depend on non-free software at
compilation time or installation time, such as by prompting the user
for a Windows driver CD, at that time the ndiswrapper package would
be required to be moved to contrib.

IN ADDITION

10. The committee notes its approval of the decisions of the
maintainer of ndiswrapper and the ftpmaster team in including the
package in the main component as being in compliance with current
Debian policy; and

11. The committee notes its approval of the existing policy on the
suitability of packages for the main and contrib components; and

12. The committee offers its thanks to Robert Millan for raising the
issue; to Wouter Verhelst and others for their input on the topic;
and to Andres Salomon for his ongoing efforts in maintaining the
ndiswrapper packages.

13. The committee believes this is not a wholly technical issue, and
that the general policy decisions in question are largely
political, so this does not fall into our explicit remit.  This
decision is therefore advisory.  However, we recommend that all
parties concerned follow our advice unless and until a contrary
statement is issued by the Project Leader or an appropriate
Delegate.

Ian.

--- 1   2006-03-08 00:33:30.0 +
+++ 2   2006-03-08 00:33:01.0 +
@@ -6,9 +6,10 @@
 that package in the main component of the archive, and for it to be
 moved to the contrib component; and
 
-2.  The committee is empowered under section 6.1(4) of the constitution to
-overrule a maintainer by a 3:1 majority vote, and empowered under section
-6.1(1) to decide on any matter of technical policy; and
+2.  This question is a mixture of political and technical questions
+and the Committee's power to decide it is unclear; however, in the
+absence of a decision by the committee it is likely that no
+decision at all will be made.
 
 3.  The purpose of the ndiswrapper package is to provide an ABI layer
 on top of the Linux kernel that is compatible with the interface for
@@ -20,7 +21,7 @@
 a very limited number of free drivers using the NDIS format also
 exist; and
 
-5.  The technical policy in this matter states that: (debian-policy
+5.  The policy in this matter states that: (debian-policy
 3.6.2.2, section 2.2.1)
 
[...] packages in _main_ 
@@ -38,30 +39,40 @@
 
 THE COMMITTEE CONCLUDES THAT
 
-6.  It is appropriate for the committee to consider this request; and
+6.  It is appropriate for the committee to consider this request
+but not by itself to overturn established political policy; and
 
 7.  The curre

Re: Bug#353277: ndiswrapper in main

[Ian Jackson]

Steve Langasek writes ("Re: Bug#353277: ndiswrapper in main"):
> Given that the constitution does specify the use of the standard resolution
> procedure, I think the right answer here is to have a single ballot with
> both proposals on it, so that we have an opportunity to rank the options
> in glorious Condorcet fashion. ;)

Quite so.

> I certainly think devotee is overkill, though; with seven eligible voters,
> I'm content to tally the votes by hand.

Indeed.

> Given that there's been no formal call for votes on either Raul's proposal
> or on this one, then, I think we should take another day for any further
> input (additional resolutions, editorial corrections, etc), then put these
> on a ballot and call for votes.

I would like to draft a version of Anthony's answer that makes it a
recommendation rather than a mandatory decision.  In fact, we probably
need four versions:

 * We think it's our decision and we decide (insisting iff 3:1)
   that it should go into main
 * We think it's our decision and we decide (insisting iff 3:1)
   that it should go into contrib
 * We think it's not our decision formally but we conclude
   that it should go into main
 * We think it's not our decision formally but we conclude
   that it should go into contrib

It will be easier to draft those four alternatives than to have
everyone write round and say which ones they prefer.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Ian Jackson]

Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> Either way, I propose the following, call for a vote on it, and vote
> in favour:
> 
> WHEREAS
...
> 6.  It is appropriate for the committee to consider this request; and
...
> 8.  As such the ndiswrapper package complies with current technical
> policy as regards to its suitability for main; and

I vote against this resolution.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Ian Jackson]

Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> [draft resolution]

I'm afraid I think that that's quite out of order.

Constitution s6.3(3):

  3. Public discussion and decision-making.

 Discussion, draft resolutions and amendments, and votes by
 members of the committee, are made public on the Technical
 Committee public discussion list. There is no separate secretary
 for the Committee.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Ian Jackson]

I'd like to try to think about this from another point of view.  I'm
going to go back and say some things that we're all probably aware of
and then develop from there:


Why does contrib exist ?


1. Dependency-completeness for main:

There is one clear technical reason why contrib has to exist: without
it, packages which Depend on or Recommend non-free packages would
either have to be in non-free themselves, or be in main and cause main
to have unsatisfiable dependencies.  (This argument is based on the
already taken political decision to have `non-free', of course.)

Note that using contrib for these packages, rather than non-free, is
in some sense a political decision: putting something in non-free is
making a statement not just about technicalities but also about the
legal and political situation, and the Project feels it inappropriate
to apply the `non-free' label to packages which are not themselves
directly encumbered.  But this political decision seems to have been
clearly taken by the Project as a whole and seems to be undisputed.

2. Assurance of Free-ness to users:

Following on from this, it is clear that if you tell your system not
to offer you non-free software, the software system as a whole should
not just exclude packages that are themselves non-free or that Depend
on non-free packages (1, above), but also packages which, if you
install them, will directly result in the installation and execution
of non-free software on your computer, without significant further
confirmation.  (And any such offer subject to confirmation would
arguably be inapproprite given that the user has already said `no' in
the general case.)

For example, if the package selection and installation system installs
an installer package, or a package which automatically downloads and
installs non-free content, then the computer will have the non-free
stuff on it and the user might not be aware of the status of the code.

For a variety of reasons, both practical (the user needs to know their
legal situation) and political, the Project has decided that these
kinds of programs should be in contrib too.


Additional uses for contrib
---

Some people seem to be arguing, effectively, that the two situations
above are the only reasons for contrib to exist and that no package
not falling under one of those two headings should be in contrib.
However, it seems clear to me that the Project has decided otherwise,
both from close reading of the policy, and from past actions:


Firstly, close reading of the policy for contrib:

 * free packages which require contrib, non-free packages or packages
   which are not in our archive at all for compilation or execution,
   and

 * wrapper packages or other sorts of free accessories for non-free
   programs.

The first of these covers _all_ of my items 1 and 2 above (providing
we read `package' to mean `something packaged and distributed' and not
`Debian format package', which seems most reasonable).  An
interpretation of the second bullet which likewise only covers things
which _have_ to be in contrib for practical reasons would be
completely subsumed by the first bullet.

So, if the second bullet means anything at all it means that some
additional packages, which do not need to be in contrib for the
practical reasons I describe above, are still to be put in contrib.


Secondly, prior practice:

No-one has mentioned the various emulators and game-file runners
recently in this thread, but they provide a very clear example.

In general, the Project has classified into contrib emulators and
executables which require non-free components to be supplied by the
user before they are useful - typically, game engines and certain
hardware emulators.  The program in question generally stayed in
contrib until there was something resembling Free data or code for it
to work with.  In some cases there was originally _one particular_
non-free data file required, but in other cases there were a variety
of different non-free components any one of which would do, and where
the emulator was the program which


Now, we don't have a clear statement of the reasons for this.  But I
can think of only one possible reason:

The Project disapproves, politically, of the non-free status of the
required components.  It expresses this disapproval by relegating the
corresponding emulator into `contrib'.  You might argue that no
opprobrium is involved and that there is no question of status at
issue, but the high feelings on both sides of this debate (and the
amount of time spent arguing over it) give the lie to that suggestion.

(Reasons that don't make sense:  1. We don't want to encourage
copyright infringement by distributing things which require users to
play fast and loose.  This doesn't make sense because there is no
relevant difference between contrib and main.  2. We want to warn the
user about the resulting non-free status and hence lower standards
(lower maintainabili

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/7/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> Given that there's been no formal call for votes on either Raul's proposal
> or on this one, then, I think we should take another day for any further
> input (additional resolutions, editorial corrections, etc), then put these
> on a ballot and call for votes.

Given that I left out paragraph 10 of Ian's proposal, I was
under the impression that it would be withdrawn and reissued.

I had thought Ian was going to do this, but perhaps I should
have done so.

On the other hand, if opinion is strongly in favor of Aj's
proposal, perhaps I should instead try to express why I
feel points 3 and 4 of Aj's proposal are at odds and/or
what I feel should be done to change policy to be consistent
with this proposal.  (I'll try to get to that later today).

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Steve Langasek]

On Tue, Mar 07, 2006 at 01:41:58PM +1000, Anthony Towns wrote:
> Okay, so here's the alternate proposal. I understand Raul at least
> disagrees with paragraph (3) (and obviously the conclusions based on
> that), but I'm not sure we have any good way of noting that difference
> of opinion -- perhaps we should include the previous draft in the vote?
> Courts and parliamentary committees include minority views (and the
> arguments for them) in their final reports; something like that might
> be worth doing here too.

Given that the constitution does specify the use of the standard resolution
procedure, I think the right answer here is to have a single ballot with
both proposals on it, so that we have an opportunity to rank the options
in glorious Condorcet fashion. ;)

I certainly think devotee is overkill, though; with seven eligible voters,
I'm content to tally the votes by hand.

Given that there's been no formal call for votes on either Raul's proposal
or on this one, then, I think we should take another day for any further
input (additional resolutions, editorial corrections, etc), then put these
on a ballot and call for votes.

> Either way, I propose the following, call for a vote on it, and vote
> in favour:

If you agree with the above, I think we should suspend voting on this
proposal alone in the interest of clarity.

Also, FWIW I believe this should be s/compatability/compatibility/g on the
draft.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/

> WHEREAS

> 1.  The committee has been asked by Robert Millan, the submitter of
> Bug#353278 and a former developer, to overrule the decision by the
> maintainer of the ndiswrapper package, Andres Salomon, to include
> that package in the main component of the archive, and for it to be
> moved to the contrib component; and

> 2.  The committee is empowered under section 6.1(4) of the constitution to
> overrule a maintainer by a 3:1 majority vote, and empowered under section
> 6.1(1) to decide on any matter of technical policy; and

> 3.  The purpose of the ndiswrapper package is to provide an ABI layer
> on top of the Linux kernel that is compatible with the interface for
> Windows NDIS drivers, and that in order to provide this compatability
> layer, no non-free software is required; and

> 4.  The primary use for this compatability layer is to run non-free
> Windows drivers for hardware not directly supported by Linux, though
> a very limited number of free drivers using the NDIS format also
> exist; and

> 5.  The technical policy in this matter states that: (debian-policy
> 3.6.2.2, section 2.2.1)
> 
>[...] packages in _main_ 
>   * must not require a package outside of _main_ for compilation or
> execution
> 
> and: (debian-policy 3.6.2.2, section 2.2.2)
> 
>Examples of packages which would be included in _contrib_ are:
> * free packages which require _contrib_, _non-free_ packages or
>   packages which are not in our archive at all for compilation or
>   execution, and
> * wrapper packages or other sorts of free accessories for non-free
>   programs.
> 
> THE COMMITTEE CONCLUDES THAT
> 
> 6.  It is appropriate for the committee to consider this request; and
> 
> 7.  The current ndiswrapper package does not require any non-free
> software at either compilation time or installation time to fulfill
> its designated purpose; and 
> 
> 8.  As such the ndiswrapper package complies with current technical
> policy as regards to its suitability for main; and
> 
> 9.  If the ndiswrapper package come to depend on non-free software at
> compilation time or installation time, such as by prompting the user
> for a Windows driver CD, at that time the ndiswrapper package would
> be required to be moved to contrib.
> 
> IN ADDITION
> 
> 10. The committee endorses the decisions of the maintainer of ndiswrapper
> and the ftpmaster team in including the package in the main component
> as being in compliance with Debian technical policy; and
> 
> 11. The committee endorses the existing policy on the suitability of packages
> for the main and contrib components; and
> 
> 12. The committee offers its thanks to Robert Millan for raising the
> issue; to Wouter Verhelst and others for their input on the topic;
> and to Andres Salomon for his ongoing efforts in maintaining the
> ndiswrapper packages.


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Manoj Srivastava]

On 6 Mar 2006, Anthony Towns said:

> Either way, I propose the following, call for a vote on it, and vote
> in favour:
>
> WHEREAS
>
> 1.  The committee has been asked by Robert Millan, the submitter of
> Bug#353278 and a former developer, to overrule the decision by the
> maintainer of the ndiswrapper package, Andres Salomon, to include
> that package in the main component of the archive, and for it to be
> moved to the contrib component; and
>
> 2.  The committee is empowered under section 6.1(4) of the
> constitution to
> overrule a maintainer by a 3:1 majority vote, and empowered under section
> 6.1(1) to decide on any matter of technical policy; and
>
> 3.  The purpose of the ndiswrapper package is to provide an ABI
> layer
> on top of the Linux kernel that is compatible with the interface for
> Windows NDIS drivers, and that in order to provide this compatability
> layer, no non-free software is required; and
>
> 4.  The primary use for this compatability layer is to run non-free
> Windows drivers for hardware not directly supported by Linux, though
> a very limited number of free drivers using the NDIS format also
> exist; and
>
> 5.  The technical policy in this matter states that: (debian-policy
> 3.6.2.2, section 2.2.1)
>
> [...] packages in _main_ 
> * must not require a package outside of _main_ for compilation or
> execution
>
> and: (debian-policy 3.6.2.2, section 2.2.2)
>
> Examples of packages which would be included in _contrib_ are:
> * free packages which require _contrib_, _non-free_ packages or
> packages which are not in our archive at all for compilation or
> execution, and
> * wrapper packages or other sorts of free accessories for non-free
> programs.
>
> THE COMMITTEE CONCLUDES THAT
>
> 6.  It is appropriate for the committee to consider this request;
> and
>
> 7.  The current ndiswrapper package does not require any non-free
> software at either compilation time or installation time to fulfill
> its designated purpose; and 
>
> 8.  As such the ndiswrapper package complies with current technical
> policy as regards to its suitability for main; and
>
> 9.  If the ndiswrapper package come to depend on non-free software
> at
> compilation time or installation time, such as by prompting the user
> for a Windows driver CD, at that time the ndiswrapper package would
> be required to be moved to contrib.
>
> IN ADDITION
>
> 10. The committee endorses the decisions of the maintainer of
> ndiswrapper
> and the ftpmaster team in including the package in the main component
> as being in compliance with Debian technical policy; and
>
> 11. The committee endorses the existing policy on the suitability of
> packages
> for the main and contrib components; and
>
> 12. The committee offers its thanks to Robert Millan for raising the
> issue; to Wouter Verhelst and others for their input on the topic;
> and to Andres Salomon for his ongoing efforts in maintaining the
> ndiswrapper packages.
>
I vote in favour of this motion.

manoj
-- 
"... all the modern inconveniences ..." Mark Twain
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


pgpfHbp33Tnvq.pgp
Description: PGP signature

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

Okay, so here's the alternate proposal. I understand Raul at least
disagrees with paragraph (3) (and obviously the conclusions based on
that), but I'm not sure we have any good way of noting that difference
of opinion -- perhaps we should include the previous draft in the vote?
Courts and parliamentary committees include minority views (and the
arguments for them) in their final reports; something like that might
be worth doing here too.

Either way, I propose the following, call for a vote on it, and vote
in favour:

WHEREAS

1.  The committee has been asked by Robert Millan, the submitter of
Bug#353278 and a former developer, to overrule the decision by the
maintainer of the ndiswrapper package, Andres Salomon, to include
that package in the main component of the archive, and for it to be
moved to the contrib component; and

2.  The committee is empowered under section 6.1(4) of the constitution to
overrule a maintainer by a 3:1 majority vote, and empowered under section
6.1(1) to decide on any matter of technical policy; and

3.  The purpose of the ndiswrapper package is to provide an ABI layer
on top of the Linux kernel that is compatible with the interface for
Windows NDIS drivers, and that in order to provide this compatability
layer, no non-free software is required; and

4.  The primary use for this compatability layer is to run non-free
Windows drivers for hardware not directly supported by Linux, though
a very limited number of free drivers using the NDIS format also
exist; and

5.  The technical policy in this matter states that: (debian-policy
3.6.2.2, section 2.2.1)

   [...] packages in _main_ 
  * must not require a package outside of _main_ for compilation or
execution

and: (debian-policy 3.6.2.2, section 2.2.2)

   Examples of packages which would be included in _contrib_ are:
* free packages which require _contrib_, _non-free_ packages or
  packages which are not in our archive at all for compilation or
  execution, and
* wrapper packages or other sorts of free accessories for non-free
  programs.

THE COMMITTEE CONCLUDES THAT

6.  It is appropriate for the committee to consider this request; and

7.  The current ndiswrapper package does not require any non-free
software at either compilation time or installation time to fulfill
its designated purpose; and 

8.  As such the ndiswrapper package complies with current technical
policy as regards to its suitability for main; and

9.  If the ndiswrapper package come to depend on non-free software at
compilation time or installation time, such as by prompting the user
for a Windows driver CD, at that time the ndiswrapper package would
be required to be moved to contrib.

IN ADDITION

10. The committee endorses the decisions of the maintainer of ndiswrapper
and the ftpmaster team in including the package in the main component
as being in compliance with Debian technical policy; and

11. The committee endorses the existing policy on the suitability of packages
for the main and contrib components; and

12. The committee offers its thanks to Robert Millan for raising the
issue; to Wouter Verhelst and others for their input on the topic;
and to Andres Salomon for his ongoing efforts in maintaining the
ndiswrapper packages.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Manoj Srivastava]

On 28 Feb 2006, Anthony Towns stated:

> On Tue, Feb 21, 2006 at 02:09:35PM +, Ian Jackson wrote:
>> WHEREAS
>> 1. ndiswrapper's purpose is to allow non-free drivers to be used.
>> THE COMMITTEE CONCLUDES THAT
>> 6. ndiswrapper belongs in contrib.
>> AND THE COMMITTEE THEREFORE REQUESTS AS FOLLOWS
>> 9. ftpmasters and the ndiswrapper maintainers should cooperate to
>>move
>> nsidwrapper to contrib.  [...]
>> 10. The Policy Manual maintainers should take steps to adjust the
>> language regarding main and contrib to clarify and improve it.  [...]
>
> On Thu, Feb 23, 2006 at 08:30:33PM -0500, Raul Miller wrote:
>> WHEREAS
>> 1. ndiswrapper's purpose is to allow non-debian (and typically
>>non-free)
>> drivers to be used.
>> THE COMMITTEE RECOMMENDS THAT
>> 6. ndiswrapper belongs in contrib.
>> AND THE COMMITTEE THEREFORE REQUESTS AS FOLLOWS
>> 9. ftpmasters and the ndiswrapper maintainers should cooperate to move
>> nsidwrapper to contrib.
>
> Okay, so I'll vote against both these.

As do I. 

manoj
-- 
So we follow our wandering paths, and the very darkness acts as our
guide and our doubts serve to reassure us.- Jean-Pierre de Caussade,
eighteenth-century Jesuit priest
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/2/06, Anthony Towns  wrote:
> We're getting into "if a tree fell in a forest..." territory here though.

In that context the question we're trying to resolve is analogous to:
is this a forest, or a parking lot?

Getting back to my own views on this:

I don't think a decision to put ndiswrapper in main or contrib
is going to violate the social contract.  The way I read the social
contract, both can be a valid decision.  I'm more interested in
making the best decision (and the social contract is one of the
things I'm using to judge what "best" means).

And I can be convinced that we should temporarily leave ndiswrapper
in main for hypothetical uses.

I think that the long-term decision about where ndiswrapper
belongs should be consistent with what people do with it.

Contrib is for free software, I don't think moving any free software
to contrib is "bad".  It's just a signal to our users that they are
expected to install non-free software if they want to make good use
of the package. I think it's perfectly reasonable to put dosemu and
wine in contrib for that reason.

I also think it's perfectly reasonable to leave dosemu and wine
in main if many people find them useful without having to install
non-free software.

I do NOT think that this is any sort of alarming issue requiring
immediate action -- I'm far, far more concerned about the long-term
value of these decisions than I am about what things look like next
month.

Does this make sense?

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/3/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > For example, if there's free software being developed against
> > WINE (as a UI, or whatever) then that's sufficient reason right
> > there, to leave it in main.
>
> Counting the toy utilities that are bundled with wine, or only other free
> software?  I don't know of anyone developing free software against wine.
> I've used it to develop *non-*free software; I could *imagine* someone
> developing free software against wine, but I can also *imagine* someone
> developing free software against ndiswrapper.

I think using WINE to develop non-free software could count as
a use for wine sufficient to keep it in main.  We don't require that
our users use packages for free software development, just that
package use doesn't require non-free softwaer.

> > I'm willing to hear reasons why this reasoning is wrong, but if we're
> > going to go that route I think we to think those reasons through and
> > come up with some suggested policy that distinguishes between the WINE
> > case and the cases that belong in Contrib.
>
> Well, I would note that at this point, we seem to no longer be talking about
> confirming existing policy; if we were, I would expect that more weight
> would be given to AJ's proposed criteria, since as an ftpmaster he's pretty
> much the resident authority on what this de facto policy is.

That's fine -- but if we're going to go that route I think we should propose
that the text of existing policy be updated to accurately reflect
these criteria.

> But there's plenty of documentation for writing NDIS drivers, just as there
> is for writing Windows applications.  AFAIK, you can develop NDIS drivers on
> Debian using mingw just as you can develop Windows applications this way.
> Doesn't that leave as the only distinction between wine and ndiswrapper the
> theory that one is interesting to free software developers and the other
> isn't?  Does this mean wine and ndiswrapper belong in the same section, or
> do we then shuffle packages back and forth between contrib and main
> depending on the results of surveys of some kind?

If ndiswrapper is of significant use for people developing windows
applications, I think that's sufficient justification for it to be in main.

But I don't think it belongs in main if the only uses that put it in main
are hypothetical.

If we want to be fully abstract, a piece of software is just a (huge)
integer.  The integer itself is not what matters.  What matters
is what it represents to people.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Steve Langasek]

On Mon, Feb 27, 2006 at 11:26:56AM +, Ian Jackson wrote:
> Steve Langasek writes ("Re: Bug#353277: ndiswrapper in main"):
> > 1+5.  As noted in my follow-up comments to Ian's proposal, I think the
> > rationale is great, but I draw the opposite conclusion from it. :)

> I'm afraid you'll have to elaborate on that :-).

Ah, what I had written before was:

 > 4. The Committee does not wish to overturn or change established
 >political policy about the distinction between main and contrib,
 >and does not wish to usurp the political authority of the Project
 >Leader.

 I agree in principle with what you've written here, but I disagree that it
 supports your conclusion.  The ndiswrapper package is currently in main;
 saying that it belongs in contrib *is* an overturning, both of the package
 maintainer's judgement and of the judgement of the ftpmaster who approved
 it into the archive.  I don't see how we can discern here an "established
 policy" that says ndiswrapper belongs in contrib when it sits in main
 today.

> > I also didn't see that you had called for a vote on this one, just noted
> > that it was "submitted as a votable option", so I was hoping that before
> > voting we could put together a couple of other ballot options representing
> > other points of view that could be voted on as a group, since that's the way
> > that Condorcet works best.

> Right.  It seems that we're not going to just make a quick decision
> here.  But that means we need your opinion written up in resolution
> form.

Well, AJ seems to have had time for this before I did; so more follow-up on
this to his draft resolution.

> Some questions that may help:

> * Do you agree with Raul and my view about the policy manual text in
>   general - ie, paragraphs 3-4, 6(first instance), 7 and 8 of Raul's
>   version and paragraph 10 of mine ?

3-4 & 6, yes.  (The first 6, which I guess is what you mean by "first
instance"; both of you seem to have double-sixes in your resolutions.)
7, no; and consequently 8 is also no, since it's worded as an
exception to 8.  10 I'm pretty indifferent to.

> * What other things are like ndiswrapper that you think we all accept
>   should be in main ?  We might be able to suggest possible
>   distinctions between ndiswrapper and your examples, or between your
>   examples and (say) a package which Depends: on a non-main package.

The packages that seem to be most like ndiswrapper in this regard are wine,
dosemu, ibcs (no longer extant), and mol.  All of these packages are (or
were while they existed) in main; all of them are free software written for
the primary purpose of making it possible to run various non-ported,
non-free software on Linux.  (Hmm, correction; mol is available in main
because it can be used with mol-drivers-linux, but mol-drivers-macosx is in
contrib.  So we're inconsistent after all, hurrah!)  While it is possible
*to* use these packages with free software, that's not the common case by
any means, and not the principal reason that they're interesting to users.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Steve Langasek]

On Thu, Mar 02, 2006 at 07:27:41PM -0500, Raul Miller wrote:
> On 3/2/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > > With that in mind, policy on contrib says that contrib is for
> > > "wrapper packages or other sorts of free accessories for non-free 
> > > programs."
> > > http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib

> > > And I think ndiswrapper is "a sort of free accessory for non-free 
> > > programs."

> > Ok.  Would you say the same thing about a free library that implements an
> > API/ABI which is primarily of interest to users of pre-existing non-free
> > software?  If not, why is one an "accessory" and the other not?

> That's a good question.

> The way I'm currently thinking: If there are debian packages that you
> can use in WINE, or if it has some functionality that makes it useful
> in and of itself, then it belongs in main.  Otherwise it belongs in
> contrib.

So...

$ zcat dists/unstable/main/binary-i386/Packages.gz | grep-dctrl -FDepends 
-sPackage wine
Package: libwine-alsa
Package: libwine-arts
Package: libwine-capi
Package: libwine-cms
Package: libwine-dev
Package: libwine-esd
Package: libwine-gl
Package: libwine-jack
Package: libwine-ldap
Package: libwine-nas
Package: libwine-print
Package: libwine-twain
Package: wine
Package: wine-utils
$

We have zero packages in main that use wine, except for the wine-utils
package itself that contains various free "toy" implementations of common
Windows utilities -- no more useful alone than wine itself is.

By your reasoning, does this mean wine should be moved to contrib?  Or is
there some "in and of itself" usefulness that applies here but not in the
case of ndiswrapper?

> For example, if there's free software being developed against
> WINE (as a UI, or whatever) then that's sufficient reason right
> there, to leave it in main.

Counting the toy utilities that are bundled with wine, or only other free
software?  I don't know of anyone developing free software against wine.
I've used it to develop *non-*free software; I could *imagine* someone
developing free software against wine, but I can also *imagine* someone
developing free software against ndiswrapper.

> I'm willing to hear reasons why this reasoning is wrong, but if we're
> going to go that route I think we to think those reasons through and
> come up with some suggested policy that distinguishes between the WINE
> case and the cases that belong in Contrib.

Well, I would note that at this point, we seem to no longer be talking about
confirming existing policy; if we were, I would expect that more weight
would be given to AJ's proposed criteria, since as an ftpmaster he's pretty
much the resident authority on what this de facto policy is.

> > > Perhaps it could be phrased that ndiswrapper has a need for the presence
> > > of some software which is not available in debian main.

> > If we didn't ship any free software built around the Motif API, would this
> > mean lesstif had a "need for the presence of some software which is not
> > available in Debian main"?

> I've been suggesting that the answers to these questions depend on
> our best understanding of how our users use the software.

> If it's built and deployed for people to develop against, that's one
> thing.

> If it's not documented and supported for development work, and no
> one is developing against it, and it's only being used by people
> who want to install something that's not free, then that's an
> entirely different situation.

But there's plenty of documentation for writing NDIS drivers, just as there
is for writing Windows applications.  AFAIK, you can develop NDIS drivers on
Debian using mingw just as you can develop Windows applications this way.
Doesn't that leave as the only distinction between wine and ndiswrapper the
theory that one is interesting to free software developers and the other
isn't?  Does this mean wine and ndiswrapper belong in the same section, or
do we then shuffle packages back and forth between contrib and main
depending on the results of surveys of some kind?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Thu, Mar 02, 2006 at 09:21:33PM -0500, Raul Miller wrote:
> On 3/2/06, Anthony Towns  wrote:
> > On Thu, Mar 02, 2006 at 07:42:42PM -0500, Raul Miller wrote:
> > > On 3/2/06, Anthony Towns  wrote:
> > > > But it doesn't -- ndiswrapper will sit there quite beningly if the 
> > > > non-free
> > > > driver isn't present. It'll do everything it's supposed to -- link with 
> > > > the
> > > > kernel and provide an ABI for other software -- without any errors.
> > > Ok, but that's not everything it's supposed to do.
> > > If that's all it needed to do then the code implementing the ABI
> > > could do (*0)= "dump core" and that would be fine.
> > Eh? If I found something that claimed to implement the C string library
> > (strcpy, strcmp, strstr, etc) but just dumped core everytime it was
> > invoked, I wouldn't say it implemented the ABI at all. Some ABI's leave
> > some behaviour undefined (such as free(x); free(x);), but none leave
> > all of it undefined.
> For the case you described, it would not dump core.

It wouldn't dump core if I didn't use it; as soon as I did, it would
dump core, which would mean it didn't implement the ABI it claimed to,
whether I was using it or not.

We're getting into "if a tree fell in a forest..." territory here though.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/2/06, Anthony Towns  wrote:
> On Thu, Mar 02, 2006 at 07:42:42PM -0500, Raul Miller wrote:
> > On 3/2/06, Anthony Towns  wrote:
> > > But it doesn't -- ndiswrapper will sit there quite beningly if the 
> > > non-free
> > > driver isn't present. It'll do everything it's supposed to -- link with 
> > > the
> > > kernel and provide an ABI for other software -- without any errors.
> > Ok, but that's not everything it's supposed to do.
> > If that's all it needed to do then the code implementing the ABI
> > could do (*0)= "dump core" and that would be fine.
>
> Eh? If I found something that claimed to implement the C string library
> (strcpy, strcmp, strstr, etc) but just dumped core everytime it was
> invoked, I wouldn't say it implemented the ABI at all. Some ABI's leave
> some behaviour undefined (such as free(x); free(x);), but none leave
> all of it undefined.

For the case you described, it would not dump core.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Thu, Mar 02, 2006 at 07:42:42PM -0500, Raul Miller wrote:
> On 3/2/06, Anthony Towns  wrote:
> > On Wed, Mar 01, 2006 at 10:15:04PM -0500, Raul Miller wrote:
> > > Ok, we should probably find a different word to describe this
> > > relationship.
> > > Perhaps it could be phrased that ndiswrapper has a need for the presence
> > > of some software which is not available in debian main.
> > But it doesn't -- ndiswrapper will sit there quite beningly if the non-free
> > driver isn't present. It'll do everything it's supposed to -- link with the
> > kernel and provide an ABI for other software -- without any errors.
> Ok, but that's not everything it's supposed to do.
> If that's all it needed to do then the code implementing the ABI
> could do (*0)= "dump core" and that would be fine.

Eh? If I found something that claimed to implement the C string library
(strcpy, strcmp, strstr, etc) but just dumped core everytime it was
invoked, I wouldn't say it implemented the ABI at all. Some ABI's leave
some behaviour undefined (such as free(x); free(x);), but none leave
all of it undefined.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/2/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> On Tue, Feb 28, 2006 at 01:35:11PM -0500, Raul Miller wrote:
> > But I think this case -- < > install non-free software, in order to make the package work the way that
> > people typically think of as using it>>... I think this case is on the wrong
> > side of that line.
>
> But by its nature ndiswrapper requires root privs, and this would be true
> even if we were bundling a free driver with it.  So I don't think that's the
> right line here, either...

I said A, B, C

You said A (without B and C).

I don't think these are comparable, even though they use some of
the same words

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/2/06, Anthony Towns  wrote:
> On Wed, Mar 01, 2006 at 10:15:04PM -0500, Raul Miller wrote:
> > Ok, we should probably find a different word to describe this
> > relationship.
> >
> > Perhaps it could be phrased that ndiswrapper has a need for the presence
> > of some software which is not available in debian main.
>
> But it doesn't -- ndiswrapper will sit there quite beningly if the non-free
> driver isn't present. It'll do everything it's supposed to -- link with the
> kernel and provide an ABI for other software -- without any errors.

Ok, but that's not everything it's supposed to do.

If that's all it needed to do then the code implementing the ABI
could do (*0)= "dump core" and that would be fine.

You're right, of course, that it's more precise to say that the user
has this need.

Then again, there have been packages where there were two groups of users,
one who would be better served by a dependency and another who would be
better served without.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/2/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > With that in mind, policy on contrib says that contrib is for
> > "wrapper packages or other sorts of free accessories for non-free programs."
> > http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib
>
> > And I think ndiswrapper is "a sort of free accessory for non-free programs."
>
> Ok.  Would you say the same thing about a free library that implements an
> API/ABI which is primarily of interest to users of pre-existing non-free
> software?  If not, why is one an "accessory" and the other not?

That's a good question.

The way I'm currently thinking: If there are debian packages that you
can use in WINE, or if it has some functionality that makes it useful
in and of itself, then it belongs in main.  Otherwise it belongs in
contrib.

For example, if there's free software being developed against
WINE (as a UI, or whatever) then that's sufficient reason right
there, to leave it in main.

I'm willing to hear reasons why this reasoning is wrong, but if we're
going to go that route I think we to think those reasons through and
come up with some suggested policy that distinguishes between the WINE
case and the cases that belong in Contrib.

> > Perhaps it could be phrased that ndiswrapper has a need for the presence
> > of some software which is not available in debian main.
>
> If we didn't ship any free software built around the Motif API, would this
> mean lesstif had a "need for the presence of some software which is not
> available in Debian main"?

I've been suggesting that the answers to these questions depend on
our best understanding of how our users use the software.

If it's built and deployed for people to develop against, that's one
thing.

If it's not documented and supported for development work, and no
one is developing against it, and it's only being used by people
who want to install something that's not free, then that's an
entirely different situation.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Andreas Barth]

* Anthony Towns (aj@azure.humbug.org.au) [060228 09:44]:
> On Tue, Feb 21, 2006 at 02:09:35PM +, Ian Jackson wrote:
> > WHEREAS
> > 1. ndiswrapper's purpose is to allow non-free drivers to be used.
> > THE COMMITTEE CONCLUDES THAT
> > 6. ndiswrapper belongs in contrib.
> > AND THE COMMITTEE THEREFORE REQUESTS AS FOLLOWS
> > 9. ftpmasters and the ndiswrapper maintainers should cooperate to move
> >nsidwrapper to contrib.  [...]
> > 10. The Policy Manual maintainers should take steps to adjust the
> >language regarding main and contrib to clarify and improve it.  [...]
> 
> On Thu, Feb 23, 2006 at 08:30:33PM -0500, Raul Miller wrote:
> > WHEREAS
> > 1. ndiswrapper's purpose is to allow non-debian (and typically non-free)
> >   drivers to be used.
> > THE COMMITTEE RECOMMENDS THAT
> > 6. ndiswrapper belongs in contrib.
> > AND THE COMMITTEE THEREFORE REQUESTS AS FOLLOWS
> > 9. ftpmasters and the ndiswrapper maintainers should cooperate to move
> >   nsidwrapper to contrib.
> 
> Okay, so I'll vote against both these.

I do the same.

Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Steve Langasek]

On Tue, Feb 28, 2006 at 01:35:11PM -0500, Raul Miller wrote:
> But I think this case -- < install non-free software, in order to make the package work the way that
> people typically think of as using it>>... I think this case is on the wrong
> side of that line.

But by its nature ndiswrapper requires root privs, and this would be true
even if we were bundling a free driver with it.  So I don't think that's the
right line here, either...

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Wed, Mar 01, 2006 at 10:15:04PM -0500, Raul Miller wrote:
> Ok, we should probably find a different word to describe this
> relationship.
> 
> Perhaps it could be phrased that ndiswrapper has a need for the presence
> of some software which is not available in debian main.

But it doesn't -- ndiswrapper will sit there quite beningly if the non-free
driver isn't present. It'll do everything it's supposed to -- link with the
kernel and provide an ABI for other software -- without any errors.

The drivers, on the other hand won't function without ndiswrapper (or Windows).

Similarly, if we could package the windows driver, we would write:

Package: videoXYZ-driver
Section: non-free/drivers
Depends: ndiswrapper

not

Package: ndiswrapper
Depends: videoXYZ-driver | video123-driver | videoBLAH-driver

We already do the relationships this way for USB drivers that access
the USB ports via libusb, eg, which are all packaged and in main so skip
the complications ndiswrapper raises.

Basically, I think it's right to say that the user has a need for the
driver, and the driver has a need for ndiswrapper. It's only because
of the user's need for a driver that anything non-free is involved;
ndiswrapper itself is quite happy without one (or with one of the toy
free ones).

For comparison, installer packages normally have a need for the non-free
software: if they don't have it, they can't install it in the first place.

(And thanks, I do think "has a need" is a helpful way of describing this)

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Steve Langasek]

On Wed, Mar 01, 2006 at 10:15:04PM -0500, Raul Miller wrote:
> On 3/1/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> > The lack of declared dependencies in ndiswrapper isn't a result of trying
> > to do an end-run around policy, it's a result of the fact that ndiswrapper
> > does not *have* a dependency on windows drivers in the sense that can
> > reasonably be represented in the Depends: field -- just as any given library
> > is of limited use on its own, yet it doesn't have an ORed dependency list on
> > all the packages (+ unpackaged software) that can use it.

> Correct.

> I was not disputing the headers of the ndiswrapper package.  I was
> disputing the assertion that we can't assume anything about how
> the software is used.  My assertion was that we must assume things
> about how the software is used in order to populate the Depends:
> header.

Ok, fair enough.

> With that in mind, policy on contrib says that contrib is for
> "wrapper packages or other sorts of free accessories for non-free programs."
> http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib

> And I think ndiswrapper is "a sort of free accessory for non-free programs."

Ok.  Would you say the same thing about a free library that implements an
API/ABI which is primarily of interest to users of pre-existing non-free
software?  If not, why is one an "accessory" and the other not?

> > Given that this is how we understand "dependency" every other time we use it
> > in the project, I think it would be inconsistent to say that ndiswrapper has
> > a "dependency" on an indeterminate but large number of distinct Windows
> > drivers.

> Ok, we should probably find a different word to describe this
> relationship.

> Perhaps it could be phrased that ndiswrapper has a need for the presence
> of some software which is not available in debian main.

If we didn't ship any free software built around the Motif API, would this
mean lesstif had a "need for the presence of some software which is not
available in Debian main"?

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/1/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> The lack of declared dependencies in ndiswrapper isn't a result of trying
> to do an end-run around policy, it's a result of the fact that ndiswrapper
> does not *have* a dependency on windows drivers in the sense that can
> reasonably be represented in the Depends: field -- just as any given library
> is of limited use on its own, yet it doesn't have an ORed dependency list on
> all the packages (+ unpackaged software) that can use it.

Correct.

I was not disputing the headers of the ndiswrapper package.  I was
disputing the assertion that we can't assume anything about how
the software is used.  My assertion was that we must assume things
about how the software is used in order to populate the Depends:
header.

With that in mind, policy on contrib says that contrib is for
"wrapper packages or other sorts of free accessories for non-free programs."
http://www.debian.org/doc/debian-policy/ch-archive.html#s-contrib

And I think ndiswrapper is "a sort of free accessory for non-free programs."

To avoid another tangent: I'll grant that drivers are system programs,
and are not application programs, and that in the typical case they're
not associated with a specific process id.  For more detail on what programs
are, see http://en.wikipedia.org/wiki/Program_(computing)

> Given that this is how we understand "dependency" every other time we use it
> in the project, I think it would be inconsistent to say that ndiswrapper has
> a "dependency" on an indeterminate but large number of distinct Windows
> drivers.

Ok, we should probably find a different word to describe this
relationship.

Perhaps it could be phrased that ndiswrapper has a need for the presence
of some software which is not available in debian main.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Tue, Feb 28, 2006 at 01:35:11PM -0500, Raul Miller wrote:
> > After the discussions so far, I'm inclined towards the following two views
> > of our policy on this:
> > * first, that dependencies are one way -- programs depend on
> >   libraries, but libraries don't depend on the programs that use
> >   them;
> I don't think that can really be true in the general case.  For example,
> we have the "base system" where pretty much everything in base has
> a mutual dependency on pretty much everything else in base.

wget and netcat are in base, but nothing else in the base system depends on
them.

But anyway, as I said to Ian, I'm not trying to deny the existance of
mutual dependencies -- obviously they exist. What I'm getting at is that
not all dependencies are mutual; just because a library isn't "useful"
without some application that uses it (maybe one you write yourself),
that doesn't mean it depends on having some such application installed.

> > * and second, that programs that only operate when interacting with
> >   non-free programs, whether over the net or via data files, aren't
> >   considered to depend on those non-free programs.
> The issue I thought was important in the context of ndiswrapper was: what
> software has to be installed on the debian system for people to use
> ndiswrapper?
> I'm not sure that this general statement really refutes that position.

The above is the other stem I think's necessary to cover programs
suitable for main that wouldn't be useful in a world where all the
non-free software suddenly disappeared.

I don't have any problem with "non-free software must be involved, but needn't
be installed on the system" as a restatement of the second principle
above. It's independent of the first one though, which is the one that
affects ndiswrapper.

> But I think this case -- < install non-free software, in order to make the package work the way that
> people typically think of as using it>>... I think this case is on the wrong
> side of that line.

I don't think whether root has to be used is a good line to draw --
putting an installer package in main that automatically downloads
a separate copy of the non-free software for each user than runs it
wouldn't be right, imo.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Steve Langasek]

On Wed, Mar 01, 2006 at 01:22:22PM -0500, Raul Miller wrote:
> On 3/1/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> > On Wed, 01 Mar 2006, Raul Miller wrote:
> > > Let's grant that any "moving to contrib" will only happing in 
> > > unstable/testing
> > > (and future stable) releases of debian.

> > > Do you see a problem with moving these to contrib?  After all, everything

> > Honestly I don't care enough about either those libs or ndiswrapper to
> > oppose to the move to contrib. But I've given my interpretation of the
> > policy and my rationale why they can/should be kept in main.

> > Now, you use that input how you want and you make up your own opinion.

> Ok, correct me if I'm wrong, here's how I'm understanding what you
> wrote: You feel that the contents of the "contrib" section mentioned in the
> social contract should be mechanically determined by debian package
> headers, and not by a more general concept of dependency?

> If that's not your point, I don't understand your input.

> > > in conjunction with non-free software.  Why do you think these other 
> > > packages
> > > should not go in contrib?

> > Because they are DFSG-free, they have no explicit dependencies on a non-free
> > package and because they're not (installation) wrapper.

> It sounds to me like you're saying that all packages in contrib could
> be moved to main simply by removing the explicit dependencies in
> their package headers?

The lack of declared dependencies in ndiswrapper isn't a result of trying
to do an end-run around policy, it's a result of the fact that ndiswrapper
does not *have* a dependency on windows drivers in the sense that can
reasonably be represented in the Depends: field -- just as any given library
is of limited use on its own, yet it doesn't have an ORed dependency list on
all the packages (+ unpackaged software) that can use it.

Given that this is how we understand "dependency" every other time we use it
in the project, I think it would be inconsistent to say that ndiswrapper has
a "dependency" on an indeterminate but large number of distinct Windows
drivers.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Raphael Hertzog]

On Wed, 01 Mar 2006, Raul Miller wrote:
> > Now, you use that input how you want and you make up your own opinion.
> 
> Ok, correct me if I'm wrong, here's how I'm understanding what you
> wrote: You feel that the contents of the "contrib" section mentioned in the
> social contract should be mechanically determined by debian package
> headers, and not by a more general concept of dependency?

If that was possible, I would say yes but that's not possible since the
lack of header doesn't mean that there's no dependency.

For me contrib has always been: any package that depends (determined by
the header) on non-free stuff with a list of exceptions covering cases
where there's no dependency in the control file but where there should
have been one if the stuff it depended on would have been packaged.

And the only exception I'm currently comfortable with is installation
wrappers.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/1/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> On Wed, 01 Mar 2006, Raul Miller wrote:
> > Let's grant that any "moving to contrib" will only happing in 
> > unstable/testing
> > (and future stable) releases of debian.
> >
> > Do you see a problem with moving these to contrib?  After all, everything
>
> Honestly I don't care enough about either those libs or ndiswrapper to
> oppose to the move to contrib. But I've given my interpretation of the
> policy and my rationale why they can/should be kept in main.
>
> Now, you use that input how you want and you make up your own opinion.

Ok, correct me if I'm wrong, here's how I'm understanding what you
wrote: You feel that the contents of the "contrib" section mentioned in the
social contract should be mechanically determined by debian package
headers, and not by a more general concept of dependency?

If that's not your point, I don't understand your input.

> > in conjunction with non-free software.  Why do you think these other 
> > packages
> > should not go in contrib?
>
> Because they are DFSG-free, they have no explicit dependencies on a non-free
> package and because they're not (installation) wrapper.

It sounds to me like you're saying that all packages in contrib could
be moved to main simply by removing the explicit dependencies in
their package headers?

> > We have to make assumptions about how software is normally
> > used to define reasonable values for dpkg headers like Depends:
>
> We're speaking of software of the user that is not packaged by us. I don't
> see how a dpkg Depends field is relevant here.

I don't see why you think the Depends field is the entire issue when
we're talking about "contrib".

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raphael Hertzog]

On Wed, 01 Mar 2006, Raul Miller wrote:
> Let's grant that any "moving to contrib" will only happing in unstable/testing
> (and future stable) releases of debian.
> 
> Do you see a problem with moving these to contrib?  After all, everything

Honestly I don't care enough about either those libs or ndiswrapper to
oppose to the move to contrib. But I've given my interpretation of the
policy and my rationale why they can/should be kept in main.

Now, you use that input how you want and you make up your own opinion.

> in conjunction with non-free software.  Why do you think these other packages
> should not go in contrib?

Because they are DFSG-free, they have no explicit dependencies on a non-free
package and because they're not (installation) wrapper.

> > Here's the full parallel :
> >
> > The library is free, has no reverse depends in main, is thus only provided
> > for the user to compile and use software coming outside of Debian. We
> > can't assume anything about the software that the user will use.
> 
> I disagree.  We have to make assumptions about how software is normally
> used to define reasonable values for dpkg headers like Depends:

We're speaking of software of the user that is not packaged by us. I don't
see how a dpkg Depends field is relevant here.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/1/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> On Wed, 01 Mar 2006, Raul Miller wrote:
> > > The real question was "What is the difference for a package if it enables
> > > the user to make use of his own software or his own hardware (whether free
> > > or non-fee) ?"
> >
> > I don't think that's the real question in the context of ndiswrapper:
>
> But we do have old libraries whose sole purpose is to support old
> proprietary applications linked against them. Those libs are DFSG-free,
> and we distribute them in main so that our users can make use of their
> apps without too much troubles.
>
> In a way, those libs are like ndiswrapper: they are useful only in
> conjunction with some non-free stuff. But IMO it's not a reason to move
> them in contrib ...

Ok, so you disagree with the idea that these should go in contrib.

Let's grant that any "moving to contrib" will only happing in unstable/testing
(and future stable) releases of debian.

Do you see a problem with moving these to contrib?  After all, everything
in contrib is free software.  Contrib is for free software that's only useful
in conjunction with non-free software.  Why do you think these other packages
should not go in contrib?

> > We've made promises in the social contract about what we will do
> > in the context of making free software depend on other software.
> > We haven't made any promises about making free software
> > depend on hardware.
>
> True. But we're diverging here, the placement of ndiswrapper is more an
> issue of policy than an issue of the social contract.

Except, that policy is based on the social contract.

> > > I think both packages enable the user to use "something he has" (whether
> > > software or hardware) and that it doesn't make much sense to treat them
> > > differently when both are DFSG free.
> >
> > What you said here does not make sense to me.  I have never encountered
> > a piece of hardware which satisfies the Debian Free Software Guidelines.
>
> "Both" refers to "both packages" (library and ndiswrapper). (and not
> software and hardware)
>
> Here's the full parallel :
>
> The library is free, has no reverse depends in main, is thus only provided
> for the user to compile and use software coming outside of Debian. We
> can't assume anything about the software that the user will use.

I disagree.  We have to make assumptions about how software is normally
used to define reasonable values for dpkg headers like Depends:

I don't think it's at all reasonable to claim we can't make assumptions that
we have to make.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raphael Hertzog]

On Wed, 01 Mar 2006, Raul Miller wrote:
> > The real question was "What is the difference for a package if it enables
> > the user to make use of his own software or his own hardware (whether free
> > or non-fee) ?"
> 
> I don't think that's the real question in the context of ndiswrapper:

But we do have old libraries whose sole purpose is to support old
proprietary applications linked against them. Those libs are DFSG-free,
and we distribute them in main so that our users can make use of their
apps without too much troubles.

In a way, those libs are like ndiswrapper: they are useful only in
conjunction with some non-free stuff. But IMO it's not a reason to move
them in contrib ...

> Then again, maybe there's some ambiguity about what you mean
> by "his own software"?  If a person does not own copyright on a
> piece of software, I think that that software is not "his own", though
> the instance -- the copy -- might be.
> 
> This might seem like an overly narrow distinction, but it's exactly
> the sort of distinction that copyright law is based on.  And, since
> we're engaged in making copies of software, and distributing
> those copies, this is a critically important question for us.

By "own software" I meant "local software not distributed by Debian", ie
some software that the user wants to run on his machine but that he's
hasn't installed via Debian.

> We've made promises in the social contract about what we will do
> in the context of making free software depend on other software.
> We haven't made any promises about making free software
> depend on hardware.

True. But we're diverging here, the placement of ndiswrapper is more an
issue of policy than an issue of the social contract.

> > I think both packages enable the user to use "something he has" (whether
> > software or hardware) and that it doesn't make much sense to treat them
> > differently when both are DFSG free.
> 
> What you said here does not make sense to me.  I have never encountered
> a piece of hardware which satisfies the Debian Free Software Guidelines.

"Both" refers to "both packages" (library and ndiswrapper). (and not
software and hardware)

Here's the full parallel :

The library is free, has no reverse depends in main, is thus only provided
for the user to compile and use software coming outside of Debian. We
can't assume anything about the software that the user will use.

Ndiswrapprer is free, has no reverse depends in main, is thus only
provided for the user to make use of some piece of hardware. We can't
assume anything about the hardware and the NDIS driver that the user will
use.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 3/1/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> So you responded to my question out of its context... which was trimmed
> down due to the 2 subsequent answers. :-/

Ok.  And I think a part of the problem has been inexact expression,
where assumptions are important in understanding what a
person meant.

> The real question was "What is the difference for a package if it enables
> the user to make use of his own software or his own hardware (whether free
> or non-fee) ?"

I don't think that's the real question in the context of ndiswrapper:

To my knowledge, no one is writing their own software to use with
ndiswrapper.

Then again, maybe there's some ambiguity about what you mean
by "his own software"?  If a person does not own copyright on a
piece of software, I think that that software is not "his own", though
the instance -- the copy -- might be.

This might seem like an overly narrow distinction, but it's exactly
the sort of distinction that copyright law is based on.  And, since
we're engaged in making copies of software, and distributing
those copies, this is a critically important question for us.

Hardware, on the other hand, is out of scope for us.

We've made promises in the social contract about what we will do
in the context of making free software depend on other software.
We haven't made any promises about making free software
depend on hardware.

Does this make sense to you?

> I think both packages enable the user to use "something he has" (whether
> software or hardware) and that it doesn't make much sense to treat them
> differently when both are DFSG free.

What you said here does not make sense to me.  I have never encountered
a piece of hardware which satisfies the Debian Free Software Guidelines.

So I can't think of any reasonable way to construct a specific example of
the case you're talking about that you say doesn't make much sense.

So I can easily agree that "it doesn't make much sense", but I think you're
trying to suggest something else would make sense, that doesn't make
sense to me either.

> I hope the confusion is solved now. :-)

I'm still not sure if the problem is that I don't understand some relevant
point of yours or if the problem is that you don't understand some
relevant point of mine.

Maybe I should have instead said "We can't distribute any hardware:
in main, contrib, or non-free"?

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raphael Hertzog]

On Tue, 28 Feb 2006, Raul Miller wrote:
> On 2/28/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> > On Tue, 28 Feb 2006, Raul Miller wrote:
> > > On 2/28/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> > > > What's so different between my own non-free program and my own non-free
> > > > card which requires a non-free driver to work with ?
> > >
> > > We can't distribute any hardware in main.
> >
> > We are speaking of something that the user has (and that is not in main
> > obviously)... please think in the context of the replies.
> 
> Huh?
> 
> I'll try again:

I was referring to the context of Ian's mail and Anthony's initial mail 
(3-4 messages backwards in the history) :

Ian responds to Anthony:
---
> (a) libraries that aren't used by any DFSG-free programs are okay
> for main, so packages like libamstd-ruby1.8 that provide a
> library
> that no package happens to use are still fine

I don't follow the argument here at all.  A library can still be
useful even if nothing in Debian depends on it, either because some
older Debian package still depends on it, or because a user's own
software depends on it.

The purpose of a library is not just to run binaries provided by other
people; it is also to allow a user to build and then run their own
programs.
---

I respond to Ian :
---
> I don't follow the argument here at all.  A library can still be
> useful even if nothing in Debian depends on it, either because some
> older Debian package still depends on it, or because a user's own
> software depends on it.

What's so different between my own non-free program and my own non-free
card which requires a non-free driver to work with ?
---

So you responded to my question out of its context... which was trimmed
down due to the 2 subsequent answers. :-/

The real question was "What is the difference for a package if it enables
the user to make use of his own software or his own hardware (whether free
or non-fee) ?"

I think both packages enable the user to use "something he has" (whether
software or hardware) and that it doesn't make much sense to treat them
differently when both are DFSG free.

I hope the confusion is solved now. :-)

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/28/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> On Tue, 28 Feb 2006, Raul Miller wrote:
> > On 2/28/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> > > What's so different between my own non-free program and my own non-free
> > > card which requires a non-free driver to work with ?
> >
> > We can't distribute any hardware in main.
>
> We are speaking of something that the user has (and that is not in main
> obviously)... please think in the context of the replies.

Huh?

I'll try again:

When you ask about the difference between non-free
programs and non-free hardware the difference is:

hardware is not software.

Hardware can not be free in the DFSG sense any more than
Debian Developers can be free in the DFSG sense.  Hardware
is not software any more than developers are software.

Both, obviously, are closely related to software, but
closely related is not "the same as".

We can have hardware that runs free software, and we
can have hardware that runs non-free software, but in
the context of Debian, it's meaningless to talk about
hardware being "free" or "non-free".

I reserve the right to distinguish between hardware
and software contained within that hardware, and
I'll be happy to discuss this issue with you in more
detail, and talk about how I see this relating to
the DFSG and Social Contract, but that is not the
question you posed.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raphael Hertzog]

On Tue, 28 Feb 2006, Raul Miller wrote:
> On 2/28/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> > What's so different between my own non-free program and my own non-free
> > card which requires a non-free driver to work with ?
> 
> We can't distribute any hardware in main.

We are speaking of something that the user has (and that is not in main
obviously)... please think in the context of the replies.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/28/06, Raphael Hertzog <[EMAIL PROTECTED]> wrote:
> What's so different between my own non-free program and my own non-free
> card which requires a non-free driver to work with ?

We can't distribute any hardware in main.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/28/06, Anthony Towns  wrote:
> Okay, so I'll vote against both these.

Understood.

But I'd appreciate it if you could refine your arguments some more:

> After the discussions so far, I'm inclined towards the following two views
> of our policy on this:
>
> * first, that dependencies are one way -- programs depend on
>   libraries, but libraries don't depend on the programs that use
>   them;

I don't think that can really be true in the general case.  For example,
we have the "base system" where pretty much everything in base has
a mutual dependency on pretty much everything else in base.

> * and second, that programs that only operate when interacting with
>   non-free programs, whether over the net or via data files, aren't
>   considered to depend on those non-free programs.

The issue I thought was important in the context of ndiswrapper was: what
software has to be installed on the debian system for people to use
ndiswrapper?

I'm not sure that this general statement really refutes that position.

> That means that:
>
> (a) libraries that aren't used by any DFSG-free programs are okay
> for main, so packages like libamstd-ruby1.8 that provide a library
> that no package happens to use are still fine

If the issue is "what needs to be installed for people to use libamstd-ruby1.8
the way it's typically used" would there be any missing packages?

> (b) ndiswrapper is okay for main (non-free drivers depend on it, and
> there are no free packages that depend on it, but it does not depend
> on anything non-free)

I'm not saying you're wrong here, but I think we should find better examples
where the "what needs to be installed" logic falls down, if we're going to
go this route.

> (c) free viewers/players for proprietary formats (Word documents,
> mp3 players, etc) are okay for main

While this is true, I you're talking about content which can be
fetched by any user on a typical system.  There's no need for
the system administrator to install anything here.

> (d) free clients for proprietary protocols (for which there is no
> free server) are okay for main

Again, in the typical case there's no need for the administrator
to install anything.

> All of which are (ttbomk) existing practice.

I agree, and I think you're drawing the line in an appropriate place,
for the most part.

But I think this case -- <>... I think this case is on the wrong
side of that line.

> It would be consistent to invert either principle; but I don't think it
> would be practical to remove packages that would be classified under
> either (a) or (c) from main, and I think the relationship between (a)
> and (b) and (c) and (d) are pretty strong, to the point I can't really
> see why it would be fair to drop one without also dropping the other.

Could you comment directly on the issue I've <> above?

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raphael Hertzog]

On Tue, 28 Feb 2006, Ian Jackson wrote:
> Raphael Hertzog writes ("Re: Bug#353277: ndiswrapper in main"):
> > What's so different between my own non-free program and my own non-free
> > card which requires a non-free driver to work with ?
> 
> You didn't make the card.

What relevance does it have ?

If I compile the program and thus need the library, it's because I want to
be able to use it. (And I can compile a non-free program that I didn't make)

In both case, the goal of the user is to use something. You were speaking
of relevance of the finality.

> > And we need ndiswrapper because our users can't completely control the
> > drivers that come with the hardware they have received or been given.
> 
> This is an absurd argument.  

Sorry, I don't see why. It's the same kind of constraint for our users.

> In particular, it would suggest that any non-free device driver should
> be allowed.

Yes, our social contract suggest to use non-free for that. However since
ndiswrapper is DFSG-free we don't need to put it there.

Contrib really ought to be used only when the package "depends" (in the
sense of the control field) on something non-free (or should depend on it
if the thing would have been packaged) or for the few installation
wrappers that we have like:
- f-prot-installer
- quake2-data
- msttcorefonts
- flashplugin-nonfree

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Ian Jackson]

Raphael Hertzog writes ("Re: Bug#353277: ndiswrapper in main"):
> What's so different between my own non-free program and my own non-free
> card which requires a non-free driver to work with ?

You didn't make the card.

(Unless you want to argue that ndiswrapper is for helping hardware
developers write their non-free drivers ...)

> And we need ndiswrapper because our users can't completely control the
> drivers that come with the hardware they have received or been given.

This is an absurd argument.  In particular, it would suggest that any
non-free device driver should be allowed.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Tue, Feb 28, 2006 at 11:14:22AM +, Ian Jackson wrote:
> Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> > After the discussions so far, I'm inclined towards the following two views
> > of our policy on this: 
> > * first, that dependencies are one way -- programs depend on
> >   libraries, but libraries don't depend on the programs that use
> >   them;
> What, then, is the intended meaning when the policy manual talks about
> `wrappers' for non-free programs ?  (Feel free to say that the wording
> is suboptimal and shouldn't be read so closely.)

I believe the intended meaning is to cover installer packages -- ie things
that take a given non-free package and install it on your system for you. Those
packages will break if you don't have the non-free package, and that's where
the dependency lies.

There's a nasty line there, in that if ndiswrapper didn't just provide
an interface for drivers, but actually helped you install them it would
belong in contrib by my reading.

> Also, I think this approach is likely to be a hostage to fortune.
> Software systems are becoming ever more complex and `vertical'
> layering is nowadays sometimes absent - sometimes you can't really say
> which piece of software is `above' or `below' (ie, which depends on
> the other).

If they both work without the other, then there's no dependency; if
neither works without the other, then they mutually depend. I don't think
there's a problem there, though I mightn't have been clear enough above.

> > * and second, that programs that only operate when interacting with
> >   non-free programs, whether over the net or via data files, aren't
> >   considered to depend on those non-free programs.
> As I said, I think there is a fundamental distinction between the case
> where the decision to use non-free software is made my the Debian
> user, and where it is made by someone else.  Do you agree or
> disagree ?  Do you think that's not relevant at all ?

I'm not actually sure what you mean here?

> > That means that:
> > (a) libraries that aren't used by any DFSG-free programs are okay
> > for main, so packages like libamstd-ruby1.8 that provide a library
> > that no package happens to use are still fine
> I don't follow the argument here at all.  A library can still be
> useful even if nothing in Debian depends on it, either because some
> older Debian package still depends on it, or because a user's own
> software depends on it.

Right. How about if the user's own software is all non-free though? And
if they're the only developer who uses that library, because they wrote
it themselves, and it's not actually all that great? And they distribute
their software far and wide and it's very famous?

In that example, the library is effectively useless without non-free software;
perhaps there are free toys you can use with it, but otherwise, the only point
to it is to run whatever that non-free app is.

Should it go in main? I think "yes" is the only practical answer.

You could say "no", and then we'd have to remove all the libraries no one
actually uses for free software from main -- and that might be a win in
that it'd mean everything in main was "useful", but would be heaps more
trouble than it was worth.

Or you could say "no, but only if we notice it's being used almost
entirely for non-free stuff, rather than just being used for non-Debian
stuff",  but I don't think that's a good distinction to draw.

> The purpose of a library is not just to run binaries provided by other
> people; it is also to allow a user to build and then run their own
> programs.
> This is quite different from ndiswrapper unless you're going to claim
> that people are using it for driver development.

No -- I'm going to claim the opposite: that people /aren't/ using a bunch of
the libraries we've got in main for application development.

> Are there any other packages which are in a similar state to
> ndiswrapper by _both_ the criteria I set out and by your asymmetric
> dependency criterion ?

I'm not sure -- I don't use much non-free stuff on Debian. I'd guess that
some of the old libraries we keep around might be in a similar state --
not used for development, and not needed for free software. libdb1-compat,
perhaps.

Cheers,
aj



signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Raphael Hertzog]

On Tue, 28 Feb 2006, Ian Jackson wrote:
> What, then, is the intended meaning when the policy manual talks about
> `wrappers' for non-free programs ?  (Feel free to say that the wording
> is suboptimal and shouldn't be read so closely.)

Wrapper like "installation wrappers": free code that downloads a non-free
program from a website to install it on the machine (because we're not
allowed to redistribute the software directly in non-free).

> Software systems are becoming ever more complex and `vertical'
> layering is nowadays sometimes absent - sometimes you can't really say
> which piece of software is `above' or `below' (ie, which depends on
> the other).

I find the other interpretation more difficult to apply consistently.

> I don't follow the argument here at all.  A library can still be
> useful even if nothing in Debian depends on it, either because some
> older Debian package still depends on it, or because a user's own
> software depends on it.

What's so different between my own non-free program and my own non-free
card which requires a non-free driver to work with ?

> > (c) free viewers/players for proprietary formats (Word documents,
> > mp3 players, etc) are okay for main
> > (d) free clients for proprietary protocols (for which there is no
> > free server) are okay for main
> 
> The reason we need to have free players for proprietary formats and
> free clients for proprietary servers is because our users can't
> completely control what formats other people send them and what
> servers they are required to use.

And we need ndiswrapper because our users can't completely control the
drivers that come with the hardware they have received or been given.

Note that I don't use ndiswrapper and I hope I'll never have to use it and
I encourage anyone to request free drivers instead but I still don't see
what we're trying to gain by moving it to contrib.

Cheers,
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Ian Jackson]

Anthony Towns writes ("Re: Bug#353277: ndiswrapper in main"):
> After the discussions so far, I'm inclined towards the following two views
> of our policy on this: 
> 
> * first, that dependencies are one way -- programs depend on
>   libraries, but libraries don't depend on the programs that use
>   them;

What, then, is the intended meaning when the policy manual talks about
`wrappers' for non-free programs ?  (Feel free to say that the wording
is suboptimal and shouldn't be read so closely.)

Also, I think this approach is likely to be a hostage to fortune.
Software systems are becoming ever more complex and `vertical'
layering is nowadays sometimes absent - sometimes you can't really say
which piece of software is `above' or `below' (ie, which depends on
the other).

> * and second, that programs that only operate when interacting with
>   non-free programs, whether over the net or via data files, aren't
>   considered to depend on those non-free programs.

As I said, I think there is a fundamental distinction between the case
where the decision to use non-free software is made my the Debian
user, and where it is made by someone else.  Do you agree or
disagree ?  Do you think that's not relevant at all ?

> That means that:
> 
> (a) libraries that aren't used by any DFSG-free programs are okay
> for main, so packages like libamstd-ruby1.8 that provide a library
> that no package happens to use are still fine

I don't follow the argument here at all.  A library can still be
useful even if nothing in Debian depends on it, either because some
older Debian package still depends on it, or because a user's own
software depends on it.

The purpose of a library is not just to run binaries provided by other
people; it is also to allow a user to build and then run their own
programs.

This is quite different from ndiswrapper unless you're going to claim
that people are using it for driver development.

> (c) free viewers/players for proprietary formats (Word documents,
> mp3 players, etc) are okay for main
> (d) free clients for proprietary protocols (for which there is no
> free server) are okay for main

The reason we need to have free players for proprietary formats and
free clients for proprietary servers is because our users can't
completely control what formats other people send them and what
servers they are required to use.

> (b) ndiswrapper is okay for main (non-free drivers depend on it, and
> there are no free packages that depend on it, but it does not depend
> on anything non-free)
> 
> It would be consistent to invert either principle; but I don't think it
> would be practical to remove packages that would be classified under
> either (a) or (c) from main, and I think the relationship between (a)
> and (b) and (c) and (d) are pretty strong, to the point I can't really
> see why it would be fair to drop one without also dropping the other.

Do you see the distinctions that I am making, here and in my previous
mails ?  If you say it's not fair or consistent to have a different
answer in (say) (a) or (b), I think you should explain why (or at
least state that) the distinctions that I'm using are wrong or
irrelevant.

Are there any other packages which are in a similar state to
ndiswrapper by _both_ the criteria I set out and by your asymmetric
dependency criterion ?

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Anthony Towns]

On Tue, Feb 21, 2006 at 02:09:35PM +, Ian Jackson wrote:
> WHEREAS
> 1. ndiswrapper's purpose is to allow non-free drivers to be used.
> THE COMMITTEE CONCLUDES THAT
> 6. ndiswrapper belongs in contrib.
> AND THE COMMITTEE THEREFORE REQUESTS AS FOLLOWS
> 9. ftpmasters and the ndiswrapper maintainers should cooperate to move
>nsidwrapper to contrib.  [...]
> 10. The Policy Manual maintainers should take steps to adjust the
>language regarding main and contrib to clarify and improve it.  [...]

On Thu, Feb 23, 2006 at 08:30:33PM -0500, Raul Miller wrote:
> WHEREAS
> 1. ndiswrapper's purpose is to allow non-debian (and typically non-free)
>   drivers to be used.
> THE COMMITTEE RECOMMENDS THAT
> 6. ndiswrapper belongs in contrib.
> AND THE COMMITTEE THEREFORE REQUESTS AS FOLLOWS
> 9. ftpmasters and the ndiswrapper maintainers should cooperate to move
>   nsidwrapper to contrib.

Okay, so I'll vote against both these.

After the discussions so far, I'm inclined towards the following two views
of our policy on this: 

* first, that dependencies are one way -- programs depend on
  libraries, but libraries don't depend on the programs that use
  them;

* and second, that programs that only operate when interacting with
  non-free programs, whether over the net or via data files, aren't
  considered to depend on those non-free programs.

That means that:

(a) libraries that aren't used by any DFSG-free programs are okay
for main, so packages like libamstd-ruby1.8 that provide a library
that no package happens to use are still fine

(b) ndiswrapper is okay for main (non-free drivers depend on it, and
there are no free packages that depend on it, but it does not depend
on anything non-free)

(c) free viewers/players for proprietary formats (Word documents,
mp3 players, etc) are okay for main

(d) free clients for proprietary protocols (for which there is no
free server) are okay for main

All of which are (ttbomk) existing practice. 

It would be consistent to invert either principle; but I don't think it
would be practical to remove packages that would be classified under
either (a) or (c) from main, and I think the relationship between (a)
and (b) and (c) and (d) are pretty strong, to the point I can't really
see why it would be fair to drop one without also dropping the other.

Cheers,
aj



signature.asc
Description: Digital signature

Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/27/06, Margarita Manterola <[EMAIL PROTECTED]> wrote:
> On 2/21/06, Raul Miller <[EMAIL PROTECTED]> wrote:
> > 1 "open source" windows driver available (can be used with ndiswrapper)

> Well, I couldn't find any trace of "1" ever happening.  If it ever
> happened, then it's ok.  But as far as I know, the Ralink company went
> directly to 2 (porting there non-free windows driver to linux, and
> then making it free).  Can you provide any evidence that 1 ever
> happened?

You could be right.  I was going on second-hand evidence, and it
may very well be that the open source drivers that were being ported
were really linux drivers for other ralink hardware.

Note that we have a more general problem here -- we should not
have to find the answer to an open-ended question to determine
the suitability of a package for main.

If a package requires something else to be installed before it can be
used, we shouldn't have to figure out whether or not there exists a
suitable free version of that other software -- if it's not in main, we know
that this other software hasn't been packaged, and that should be
sufficient to push package which requires it be installed into contrib.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/27/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> I like your improvement to the first paragraph, so if I may I would
> like to accept that as a change to my original proposal (which has
> been voted down anyway).

No problem -- that fits with my intention.

> I would be happy to place your version over Further Discussion, but I
> still prefer mine (with the modification to para 1.)
>
> JOOI, why did you delete:
>
>  AND THE COMMITTEE THEREFORE REQUESTS AS FOLLOWS
>  ...
>
>  10. The Policy Manual maintainers should take steps to adjust the
> language regarding main and contrib to clarify and improve it.  The
> Maintainers should take our opinion in paragraphs 7 and 8 as
> advisory; they should also have regard to opinions from the Leader
> about the correct effect.
>
> ?

Oops.

That was an artifact of the quoting you used and the
mail client I used.  I had not intended to remove that
paragraph.  if I had been more careful, I would have
noticed its absence and would have included it.

I withdraw my proposal as originally stated, since it was
incomplete.  Please feel free to incorporate its text
in another proposal.

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Ian Jackson]

Steve Langasek writes ("Re: Bug#353277: ndiswrapper in main"):
> 1+5.  As noted in my follow-up comments to Ian's proposal, I think the
> rationale is great, but I draw the opposite conclusion from it. :)

I'm afraid you'll have to elaborate on that :-).

> I also didn't see that you had called for a vote on this one, just noted
> that it was "submitted as a votable option", so I was hoping that before
> voting we could put together a couple of other ballot options representing
> other points of view that could be voted on as a group, since that's the way
> that Condorcet works best.

Right.  It seems that we're not going to just make a quick decision
here.  But that means we need your opinion written up in resolution
form.

Some questions that may help:

* Do you agree with Raul and my view about the policy manual text in
  general - ie, paragraphs 3-4, 6(first instance), 7 and 8 of Raul's
  version and paragraph 10 of mine ?

* What other things are like ndiswrapper that you think we all accept
  should be in main ?  We might be able to suggest possible
  distinctions between ndiswrapper and your examples, or between your
  examples and (say) a package which Depends: on a non-main package.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Ian Jackson]

Raul Miller writes ("Re: Bug#353277: ndiswrapper in main"):
> This is my rephrasing of Ian's proposal.  Changes:
> 
> (*) Emphasize the debian dependency issue.
> (*) Emphasize that this is a recommendation, not a command.
> 
> Basically, I'm repeating what Ian has already said.
> 
> I'm proposing this as a votable option.

I like your improvement to the first paragraph, so if I may I would
like to accept that as a change to my original proposal (which has
been voted down anyway).

I would be happy to place your version over Further Discussion, but I
still prefer mine (with the modification to para 1.)

JOOI, why did you delete:

 AND THE COMMITTEE THEREFORE REQUESTS AS FOLLOWS
 ...

 10. The Policy Manual maintainers should take steps to adjust the
language regarding main and contrib to clarify and improve it.  The
Maintainers should take our opinion in paragraphs 7 and 8 as
advisory; they should also have regard to opinions from the Leader
about the correct effect.

?

That seems necessary to make it clear that we are not trying to
exercise our power to direct the contents of the policy manual.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Steve Langasek]

On Sun, Feb 26, 2006 at 10:22:35AM -0500, Raul Miller wrote:
> Ok... silence.

> This might mean:

> (1) everyone is busy
> (2) people feel they need to think about this further
> (3) the modified version of Ian's proposal that I posted doesn't
> properly address some ndiswrapper issue
> (4) that proposal might cause some problem for other packages
> (5) something else

> If it's (2) or (4) perhaps someone could hint at things that might be
> problem indicators?

1+5.  As noted in my follow-up comments to Ian's proposal, I think the
rationale is great, but I draw the opposite conclusion from it. :)

I also didn't see that you had called for a vote on this one, just noted
that it was "submitted as a votable option", so I was hoping that before
voting we could put together a couple of other ballot options representing
other points of view that could be voted on as a group, since that's the way
that Condorcet works best.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

Ok... silence.

This might mean:

(1) everyone is busy
(2) people feel they need to think about this further
(3) the modified version of Ian's proposal that I posted doesn't
properly address some ndiswrapper issue
(4) that proposal might cause some problem for other packages
(5) something else

If it's (2) or (4) perhaps someone could hint at things that might be
problem indicators?

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

This is my rephrasing of Ian's proposal.  Changes:

(*) Emphasize the debian dependency issue.
(*) Emphasize that this is a recommendation, not a command.

Basically, I'm repeating what Ian has already said.

I'm proposing this as a votable option.

Thanks,

--
Raul




WHEREAS

1. ndiswrapper's purpose is to allow non-debian (and typically non-free)
drivers to be used.

2. While there may be cases where ndiswrapper can be used
  with a DFSG-free driver, these are exceptional, and
  none of these drivers are available in Debian main.

3. The Committee is by and large satisfied with the intent behind the
  language in the Policy Manual regarding the distinction between
  non-free and contrib.

4. The Committee does not wish to overturn or change established
  political policy about the distinction between main and contrib,
  and does not wish to usurp the political authority of the Project
  Leader.

5. The Committee's reading of the current Policy Manual wording is
  that ndiswrapper falls fairly clearly into the area currently
  defined for `contrib'.

6. However, the language in the Policy Manual is somewhat unclear and
  ambiguous, and by some readings inconsistent.

THE COMMITTEE RECOMMENDS THAT

6. ndiswrapper belongs in contrib.

7. References to `package outside of main', `packages which are not in
  our archive at all', etc., in the relevant part of the Policy
  Manual, should be changed to refer to `programs' or `software'.

8. The policy manual should be clarified to make it clear that free
  software to talk to non-free software over a network can remain in
  main.  In our opinion the relevant principle is that:

 (i) If the user or administrator who is in charge of the Debian
  installation would have to adopt non-free software X to make
  sensible use free software Y, then Y goes in contrib.

 (ii) However, if free software Y is used by the user or administrator
  of the Debian system to cope to with someone else's use of non-free
  software X on another system not under their control, then Y goes
  in main.

AND THE COMMITTEE THEREFORE REQUESTS AS FOLLOWS

9. ftpmasters and the ndiswrapper maintainers should cooperate to move
  nsidwrapper to contrib.

-30-

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/23/06, Steve Langasek <[EMAIL PROTECTED]> wrote:
> Up until this evening I was of the opinion that this was the case; then
> Anthony presented an analogous scenario on IRC that I found persuasive.
> Supposing that lesstif had not been written yet today, and there were no
> free packages in Debian that used this API, would lesstif have to be put in
> contrib?  And I think the answer is no; I think writing a new free software
> application to use the motif API would be lame and not worthwhile, but
> that's indeed not a reason to put lesstif in contrib instead of main because
> lesstif doesn't depend on those applications, it merely extends the
> capabilities of the free operating system to include running motif apps.

This has been bothering me, too.  But there's several intertwined
issues here.

One issue is the time-sensitive nature of some of the relationships
between packages.

Another issue is the role of the package in the context of the user
community.

Debian dependencies are designed around "the typical user".  A package
would go into contrib if the typical user would have to install something
which isn't a part of Debian's "main" to use the package in the sense
which most people would mean if they were to talk about using it.

There are undoubtably border cases, and problem cases, but
I don't think the lesstif example is a problem here.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Steve Langasek]

On Tue, Feb 21, 2006 at 02:09:35PM +, Ian Jackson wrote:
> I miswrote `achieved' as `required'.  So I withdraw my previous motion
> and propose the following instead, and call for a vote.

Since you've called for a vote, I vote "no" on this resolution as written.
I do agree that we should render an opinion of some sort on this issue
rather than letting it linger, so if this fails the 3:1 majority I think we
should try to figure out what the consensus position of the committee is and
vote that rather than leaving nothing but a very complex statement that we
*don't* agree with. ;)

Comments interspersed below.

> WHEREAS

> 1. ndiswrapper's purpose is to allow non-free drivers to be used.

> 2. While there may be cases where ndiswrapper can be used
>with a DFSG-free driver, these are exceptional.

> 3. The Committee is by and large satisfied with the intent behind the
>language in the Policy Manual regarding the distinction between
>non-free and contrib.

I agree up to this point.

> 4. The Committee does not wish to overturn or change established
>political policy about the distinction between main and contrib,
>and does not wish to usurp the political authority of the Project
>Leader.

I agree in principle with what you've written here, but I disagree that it
supports your conclusion.  The ndiswrapper package is currently in main;
saying that it belongs in contrib *is* an overturning, both of the package
maintainer's judgement and of the judgement of the ftpmaster who approved it
into the archive.  I don't see how we can discern here an "established
policy" that says ndiswrapper belongs in contrib when it sits in main today.

> 5. The Committee's reading of the current Policy Manual wording is
>that ndiswrapper falls fairly clearly into the area currently
>defined for `contrib'.

Up until this evening I was of the opinion that this was the case; then
Anthony presented an analogous scenario on IRC that I found persuasive.
Supposing that lesstif had not been written yet today, and there were no
free packages in Debian that used this API, would lesstif have to be put in
contrib?  And I think the answer is no; I think writing a new free software
application to use the motif API would be lame and not worthwhile, but
that's indeed not a reason to put lesstif in contrib instead of main because
lesstif doesn't depend on those applications, it merely extends the
capabilities of the free operating system to include running motif apps.

Likewise, ndiswrapper doesn't depend on any particular driver, it just
allows those drivers to be used with Debian; nor did iBCS depend on any
particular SCO Unixware binary, so there was no reason to yank it out of the
kernel and move it to contrib.

It just took looking at an analogous scenario outside a driver context for
me to figure this out.

> 6. However, the language in the Policy Manual is somewhat unclear and
>ambiguous, and by some readings inconsistent.

Certainly a fair statement any which way :)

> THE COMMITTEE CONCLUDES THAT

> 6. ndiswrapper belongs in contrib.

> 7. References to `package outside of main', `packages which are not in
>our archive at all', etc., in the relevant part of the Policy
>Manual, should be changed to refer to `programs' or `software'.

> 8. The policy manual should be clarified to make it clear that free
>software to talk to non-free software over a network can remain in
>main.  In our opinion the relevant principle is that:

>  (i) If the user or administrator who is in charge of the Debian
>installation would have to adopt non-free software X to make
>sensible use free software Y, then Y goes in contrib.

>  (ii) However, if free software Y is used by the user or administrator
>of the Debian system to cope to with someone else's use of non-free
>software X on another system not under their control, then Y goes
>in main.

> AND THE COMMITTEE THEREFORE REQUESTS AS FOLLOWS

> 9. ftpmasters and the ndiswrapper maintainers should cooperate to move
>nsidwrapper to contrib.  (If the required 3:1 supermajority is
>achieved, the ftpmasters and ndiswrapper maintainers are hereby
>required to do so.)

> 10. The Policy Manual maintainers should take steps to adjust the
>language regarding main and contrib to clarify and improve it.  The
>Maintainers should take our opinion in paragraphs 7 and 8 as
>advisory; they should also have regard to opinions from the Leader
>about the correct effect.

Cheers,
-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


signature.asc
Description: Digital signature

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/21/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> If we think they're not technical issues then we should issue an
> opinion anyway, IMO.  In practice in past when we've punted things
> away saying `this is not a technical issue' no-one else has stepped up
> to provide an opinion.  So we could say something like:
>
>   X.  We believe this is not a technical issue, so does not fall into
>   our explicit remit.  This decision is therefore advisory.
>   However, we recommend that all parties concerned follow our
>   advice unless and until a contrary statement is issued by the
>   Project Leader or an appropriate Delegate.

I think this would be a good idea.

> > This language suggests that we're not dealing with technical
> > issues.
>
> My aim here is to restrict ourselves to the narrow technicalities[1]
> and to try to interpret and clarify rather than change or make policy.
> The policy is by and large reasonable from a technical point of view.
>
> [1] Of course `technicalities' != `technical issues'.

Ok.

> > > THE COMMITTEE CONCLUDES THAT
> >
> > If this is outside our jurisdiction (and I suspect that's the case), I
> > think this should be "RECOMMENDS THAT" not "CONCLUDES THAT".
>
> We can `conclude' whatever we like.  To conclude is to complete a
> chain or argument or reasoning, and thus form a conclusion (ie, a
> grounded opinion).

Unfortunately, those are not the primary meanings of the word at
http://answers.com/conclude

> > >  (i) If the user or administrator who is in charge of the Debian
> > >installation would have to adopt non-free software X to make
> > >sensible use free software Y, then Y goes in contrib.
> >
> > Note that in the case of ndiswrapper this issue is a time-sensitive
> > issue.  There appear to have been times when the user could have
> > made sensible use of ndiswrapper installing only free software.
>
> But then the software wasn't available in Debian at all.  contrib
> seems clearly indicated for that.

This reasoning suggests that 8.(i) should read

  (i) If the user or administrator who is in charge of the Debian
  installation would have to adopt software X which is not available
  in main to make sensible use free software Y, then Y goes in contrib.

> > You've put some very good suggestions into your proposal, but I'm
> > not going to vote for it as it stands.
>
> OK.  Well, I'm happy to accept refinements.

I think I've expressed all my ideas.  I'll write up a modified proposal
tomorrow if you've not already done so.

Thanks,

--
Raul

Re: Bug#353277: ndiswrapper in main

[Ian Jackson]

Raul Miller writes ("Re: Bug#353277: ndiswrapper in main"):
> On 2/21/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> > I miswrote `achieved' as `required'.  So I withdraw my previous motion
> > and propose the following instead, and call for a vote.
> >
> > WHEREAS
> >
> > 1. ndiswrapper's purpose is to allow non-free drivers to be used.
> >
> > 2. While there may be cases where ndiswrapper can be used
> >with a DFSG-free driver, these are exceptional.
> 
> Are these technical issues?  I'm on the fence about whether these
> are or are not technical issues,.  If they're not then they're outside
> our jurisdiction.

I think the question of interpreting the existing policy is reasonably
technical, yes - questions like `does this depend on that' and `what
does this general language mean in this specific case'.

If we think they're not technical issues then we should issue an
opinion anyway, IMO.  In practice in past when we've punted things
away saying `this is not a technical issue' no-one else has stepped up
to provide an opinion.  So we could say something like:

  X.  We believe this is not a technical issue, so does not fall into
  our explicit remit.  This decision is therefore advisory.
  However, we recommend that all parties concerned follow our
  advice unless and until a contrary statement is issued by the
  Project Leader or an appropriate Delegate.

> > 3. The Committee is by and large satisfied with the intent behind the
> >language in the Policy Manual regarding the distinction between
> >non-free and contrib.
> >
> > 4. The Committee does not wish to overturn or change established
> >political policy about the distinction between main and contrib,
> >and does not wish to usurp the political authority of the Project
> >Leader.
> 
> This language suggests that we're not dealing with technical
> issues.

My aim here is to restrict ourselves to the narrow technicalities[1]
and to try to interpret and clarify rather than change or make policy.
The policy is by and large reasonable from a technical point of view.

[1] Of course `technicalities' != `technical issues'.

> > THE COMMITTEE CONCLUDES THAT
> 
> If this is outside our jurisdiction (and I suspect that's the case), I
> think this should be "RECOMMENDS THAT" not "CONCLUDES THAT".

We can `conclude' whatever we like.  To conclude is to complete a
chain or argument or reasoning, and thus form a conclusion (ie, a
grounded opinion).

> >  (i) If the user or administrator who is in charge of the Debian
> >installation would have to adopt non-free software X to make
> >sensible use free software Y, then Y goes in contrib.
> 
> Note that in the case of ndiswrapper this issue is a time-sensitive
> issue.  There appear to have been times when the user could have
> made sensible use of ndiswrapper installing only free software.

But then the software wasn't available in Debian at all.  contrib
seems clearly indicated for that.

> You've put some very good suggestions into your proposal, but I'm
> not going to vote for it as it stands.

OK.  Well, I'm happy to accept refinements.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#353277: ndiswrapper in main

[Ian Jackson]

Raul Miller writes ("Bug#353277: ndiswrapper in main"):
> On 2/21/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> > Was the open source windows driver ever available as a Debian
> > package ?  It seems clear to me that anything which requires you to
> > install non-Debian stuff on your machine belongs in contrib, even if
> > the reason for the dependency being non-Debian is not non-freeness.
> 
> I don't believe it was ever available as a Debian package.
> 
> I'll also note that the "require" concept here gets interesting,
> in this context,  as it's different from the concepts expressed in
> our packaging system.

Indeed.  But, an unsatisfiable `Depends' is worse than an undocumented
dependency on a non-Debian package, but only because it's more
annoying during your system management.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/21/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> Raul Miller writes ("Bug#353277: ndiswrapper in main"):
> > It looks to me as if the sequence of events was:
> >
> > 1 "open source" windows driver available (can be used with ndiswrapper)
> > 2 someone ports windows driver to linux
> > 3 linux driver available
> >
> > These events are sequential, and event 3 does not erase event 1.
>
> Was the open source windows driver ever available as a Debian
> package ?  It seems clear to me that anything which requires you to
> install non-Debian stuff on your machine belongs in contrib, even if
> the reason for the dependency being non-Debian is not non-freeness.

I don't believe it was ever available as a Debian package.

I'll also note that the "require" concept here gets interesting,
in this context,  as it's different from the concepts expressed in
our packaging system.

--
Raul

Bug#353277: ndiswrapper in main

[Ian Jackson]

Raul Miller writes ("Bug#353277: ndiswrapper in main"):
> It looks to me as if the sequence of events was:
> 
> 1 "open source" windows driver available (can be used with ndiswrapper)
> 2 someone ports windows driver to linux
> 3 linux driver available
> 
> These events are sequential, and event 3 does not erase event 1.

Was the open source windows driver ever available as a Debian
package ?  It seems clear to me that anything which requires you to
install non-Debian stuff on your machine belongs in contrib, even if
the reason for the dependency being non-Debian is not non-freeness.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/21/06, Ian Jackson <[EMAIL PROTECTED]> wrote:
> I miswrote `achieved' as `required'.  So I withdraw my previous motion
> and propose the following instead, and call for a vote.
>
> WHEREAS
>
> 1. ndiswrapper's purpose is to allow non-free drivers to be used.
>
> 2. While there may be cases where ndiswrapper can be used
>with a DFSG-free driver, these are exceptional.

Are these technical issues?  I'm on the fence about whether these
are or are not technical issues,.  If they're not then they're outside
our jurisdiction.

> 3. The Committee is by and large satisfied with the intent behind the
>language in the Policy Manual regarding the distinction between
>non-free and contrib.
>
> 4. The Committee does not wish to overturn or change established
>political policy about the distinction between main and contrib,
>and does not wish to usurp the political authority of the Project
>Leader.

This language suggests that we're not dealing with technical
issues.

> 5. The Committee's reading of the current Policy Manual wording is
>that ndiswrapper falls fairly clearly into the area currently
>defined for `contrib'.
>
> 6. However, the language in the Policy Manual is somewhat unclear and
>ambiguous, and by some readings inconsistent.

This point also makes me dubious about our jurisdiction on this issue.

> THE COMMITTEE CONCLUDES THAT

If this is outside our jurisdiction (and I suspect that's the case), I
think this should be "RECOMMENDS THAT" not "CONCLUDES THAT".

Also note that this issue (what is the software used with) covers
a lot of ground, and that the general question of interoperability
is something that I think is of fairly broad importance to the free
software communitees.

>  (i) If the user or administrator who is in charge of the Debian
>installation would have to adopt non-free software X to make
>sensible use free software Y, then Y goes in contrib.

Note that in the case of ndiswrapper this issue is a time-sensitive
issue.  There appear to have been times when the user could have
made sensible use of ndiswrapper installing only free software.

Since then, the free software in question has been ported to
linux.  But this concept of "sensible use" seems... flighty.  I think
we need to allow that someone might have made reasonable
decisions in the past.

You've put some very good suggestions into your proposal, but I'm
not going to vote for it as it stands.

Thanks,

--
Raul

Bug#353277: ndiswrapper in main

[Raul Miller]

On 2/21/06, Margarita Manterola <[EMAIL PROTECTED]> wrote:
> On 2/20/06, Raul Miller <[EMAIL PROTECTED]> wrote:
> > As a specific counter example, consider
> > http://rt2x00.serialmonkey.com/wiki/index.php/Main_Page
> > which is a project porting a windows driver to linux.  This port
> > appears to be possible because the windows driver was made
> > available under a free license.
>
> With this particular driver, I think you are making a mistake.  rt2x00
> is available as an independent driver (i.e. without ndiswrapper).

What is my mistake?

It looks to me as if the sequence of events was:

1 "open source" windows driver available (can be used with ndiswrapper)
2 someone ports windows driver to linux
3 linux driver available

These events are sequential, and event 3 does not erase event 1.

> As can be read in the project's history [1], the open-source project
> started because Ralink decided to release the Linux drivers under a
> free license.  There's no mention on the page of a Windows driver.

So the mention is not on that particular page, and is on a different
page.  Why is this a problem?

Note: I'm not saying there is no problem.

But if we're going to change our rules for "acceptable in main" from
"FOO is allowed in main if FOO is free and everything FOO requires
for installation is free" to "FOO is allowed in main if the typical use of
FOO can does not involve any non-free software" then we have a
much bigger issue than ndiswrapper.

And if we're going to tackle this issue properly, we need to define
the problems clearly before we can even begin to come up with a
decent solution.

For example, while we might want to define a "six degrees of separation
free" debian subset, but before we could do that we'd need to have
a good idea of what goes in that subset, how people that use it can be
sure that that's what they're getting, what we're going to do about
people who have come to rely on other software, etc. etc.

--
Raul

Re: Bug#353277: ndiswrapper in main

[Manoj Srivastava]

On 21 Feb 2006, Steve Langasek verbalised:

> On Tue, Feb 21, 2006 at 10:40:06AM +1000, Anthony Towns wrote:
>> On Mon, Feb 20, 2006 at 05:36:13PM +0100, Robert Millan wrote:
>>> I requested that ndiswrapper and ndiswrapper-modules-i386 be moved
>>> to contrib.
>> While I would personally rather see the "contrib" demarkation cover
>> this, emulators, and clients for propietary protocols, I'm
>> disinclined to override both the maintainer and the ftpmaster that
>> accepted it, particularly on this single issue rather than as a
>> global policy change for those issues. I expect I'll either abstain
>> or vote against.
>
> I suspect I disagree with Anthony on where exactly the line should
> be drawn, but it does seem to me that the arguments used to justify
> ndiswrapper's presence in main are rather contrived.  Nobody is
> going to want to run drivers under ndiswrapper in a production
> environment if there is a suitable free equivalent available for
> Linux; the only practical applications I see here are using non-free
> Windows drivers under Linux for otherwise-unsupported hardware, and
> using ndiswrapper as a tool for preliminary testing of drivers being
> written for Windows in an environment that doesn't require booting
> Windows.  The former is what I use it for, and what every user I
> know uses it for, and doesn't justify a claim that ndiswrapper does
> not depend on non-free software.  The latter, IMHO, would be grounds
> for shipping the software in main, but AFAIK this is purely a
> hypothetical at this point.

I think Raul pointed out that there are free windows only
 drivers seen in the wilds out there, in which case  ndiswrapper seems
 to represent an implementation of a protocol that allows windows only
 code to work with the Linux kernel. Whether or not such free code has
 been ported to Linux natively should be immaterial, I would draw the
 line at whether  ndiswrapper falls in the category that "installers"
 do, or in the category that "wine" does.

I think it tends to fall in the latter, since it does not seem
 to be specific to any particular piece of code or driver; and there
 is nothing that precludes a windows only piece of code that works
 with  ndiswrapper to be licensed freely.


> Either way, I do agree with Anthony that one-off overrides of
> maintainers don't seem like the best way for us to be spending our
> time.

While I agree with you both, it is because I thinik that
 ndiswrapper actually belongs in main.

manoj
-- 
If you don't care where you are, then you ain't lost.
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Manoj Srivastava]

On 21 Feb 2006, Ian Jackson verbalised:

> I hereby propose the following motion and call for a vote.

I vote against the motion outlined below.

manoj

>
> WHEREAS
>
> 1. ndiswrapper's purpose is to allow non-free drivers to be used.
>
> 2. While there may be cases where ndiswrapper can be used
> with a DFSG-free driver, these are exceptional.
>
> 3. The Committee is by and large satisfied with the intent behind
>the
> language in the Policy Manual regarding the distinction between
> non-free and contrib.
>
> 4. The Committee does not wish to overturn or change established
> political policy about the distinction between main and contrib,
> and does not wish to usurp the political authority of the Project
> Leader.
>
> 5. The Committee's reading of the current Policy Manual wording is
> that ndiswrapper falls fairly clearly into the area currently
> defined for `contrib'.
>
> 6. However, the language in the Policy Manual is somewhat unclear
>and
> ambiguous, and by some readings inconsistent.
>
> THE COMMITTEE CONCLUDES THAT
>
> 6. ndiswrapper belongs in contrib.
>
> 7. References to `package outside of main', `packages which are not
>in
> our archive at all', etc., in the relevant part of the Policy
> Manual, should be changed to refer to `programs' or `software'.
>
> 8. The policy manual should be clarified to make it clear that free
> software to talk to non-free software over a network can remain in
> main.  In our opinion the relevant principle is that:
>
> (i) If the user or administrator who is in charge of the Debian
> installation would have to adopt non-free software X to make
> sensible use free software Y, then Y goes in contrib.
>
> (ii) However, if free software Y is used by the user or
> administrator of the Debian system to cope to with someone else's
> use of non-free software X on another system not under their
> control, then Y goes in main.
>
> AND THE COMMITTEE THEREFORE REQUESTS AS FOLLOWS
>
> 9. ftpmasters and the ndiswrapper maintainers should cooperate to
>move
> nsidwrapper to contrib.  (If the required 3:1 supermajority is
> required, the ftpmasters and ndiswrapper maintainers are hereby
> required to do so.)
>
> 10. The Policy Manual maintainers should take steps to adjust the
> language regarding main and contrib to clarify and improve it.  The
> Maintainers should take our opinion in paragraphs 7 and 8 as
> advisory; they should also have regard to opinions from the Leader
> about the correct effect.
>
> Ian.
> [

-- 
"Part of the inhumanity of the computer is that, once it is
competently programmed and working smoothly, it is completely honest."
-Isaac Asimov
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Ian Jackson]

I miswrote `achieved' as `required'.  So I withdraw my previous motion
and propose the following instead, and call for a vote.

WHEREAS

1. ndiswrapper's purpose is to allow non-free drivers to be used.

2. While there may be cases where ndiswrapper can be used
   with a DFSG-free driver, these are exceptional.

3. The Committee is by and large satisfied with the intent behind the
   language in the Policy Manual regarding the distinction between
   non-free and contrib.

4. The Committee does not wish to overturn or change established
   political policy about the distinction between main and contrib,
   and does not wish to usurp the political authority of the Project
   Leader.

5. The Committee's reading of the current Policy Manual wording is
   that ndiswrapper falls fairly clearly into the area currently
   defined for `contrib'.

6. However, the language in the Policy Manual is somewhat unclear and
   ambiguous, and by some readings inconsistent.

THE COMMITTEE CONCLUDES THAT

6. ndiswrapper belongs in contrib.

7. References to `package outside of main', `packages which are not in
   our archive at all', etc., in the relevant part of the Policy
   Manual, should be changed to refer to `programs' or `software'.

8. The policy manual should be clarified to make it clear that free
   software to talk to non-free software over a network can remain in
   main.  In our opinion the relevant principle is that:

 (i) If the user or administrator who is in charge of the Debian
   installation would have to adopt non-free software X to make
   sensible use free software Y, then Y goes in contrib.

 (ii) However, if free software Y is used by the user or administrator
   of the Debian system to cope to with someone else's use of non-free
   software X on another system not under their control, then Y goes
   in main.

AND THE COMMITTEE THEREFORE REQUESTS AS FOLLOWS

9. ftpmasters and the ndiswrapper maintainers should cooperate to move
   nsidwrapper to contrib.  (If the required 3:1 supermajority is
   achieved, the ftpmasters and ndiswrapper maintainers are hereby
   required to do so.)

10. The Policy Manual maintainers should take steps to adjust the
   language regarding main and contrib to clarify and improve it.  The
   Maintainers should take our opinion in paragraphs 7 and 8 as
   advisory; they should also have regard to opinions from the Leader
   about the correct effect.

Ian.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#353277: ndiswrapper in main

[Ian Jackson]

I hereby propose the following motion and call for a vote.

WHEREAS

1. ndiswrapper's purpose is to allow non-free drivers to be used.

2. While there may be cases where ndiswrapper can be used
   with a DFSG-free driver, these are exceptional.

3. The Committee is by and large satisfied with the intent behind the
   language in the Policy Manual regarding the distinction between
   non-free and contrib.

4. The Committee does not wish to overturn or change established
   political policy about the distinction between main and contrib,
   and does not wish to usurp the political authority of the Project
   Leader.

5. The Committee's reading of the current Policy Manual wording is
   that ndiswrapper falls fairly clearly into the area currently
   defined for `contrib'.

6. However, the language in the Policy Manual is somewhat unclear and
   ambiguous, and by some readings inconsistent.

THE COMMITTEE CONCLUDES THAT

6. ndiswrapper belongs in contrib.

7. References to `package outside of main', `packages which are not in
   our archive at all', etc., in the relevant part of the Policy
   Manual, should be changed to refer to `programs' or `software'.

8. The policy manual should be clarified to make it clear that free
   software to talk to non-free software over a network can remain in
   main.  In our opinion the relevant principle is that:

 (i) If the user or administrator who is in charge of the Debian
   installation would have to adopt non-free software X to make
   sensible use free software Y, then Y goes in contrib.

 (ii) However, if free software Y is used by the user or administrator
   of the Debian system to cope to with someone else's use of non-free
   software X on another system not under their control, then Y goes
   in main.

AND THE COMMITTEE THEREFORE REQUESTS AS FOLLOWS

9. ftpmasters and the ndiswrapper maintainers should cooperate to move
   nsidwrapper to contrib.  (If the required 3:1 supermajority is
   required, the ftpmasters and ndiswrapper maintainers are hereby
   required to do so.)

10. The Policy Manual maintainers should take steps to adjust the
   language regarding main and contrib to clarify and improve it.  The
   Maintainers should take our opinion in paragraphs 7 and 8 as
   advisory; they should also have regard to opinions from the Leader
   about the correct effect.

Ian.
[


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]