Re: ndiswrapper
On 9/21/06, Steve Langasek <vorlon@debian.org> wrote:
I thought it was established up-thread that UAE isn't useful (in the
maintainer's opinion) without a specific non-free ROM?
By "that" do you mean "(in the maintainer's opinion)" or do you mean
"isn't useful"?
It seems to me that ndiswrapper is just as useful without a non-free
binary image as uae is without a non-free binary image.
Both are theoretically useful without such images. However, if we
exclude hypothetical cases and focus on what people do for real,
neither are actually used without such images.
If anything since there's kickstart emulation for uae that partially
works and which is apparently in further development, if the
criteria is "useful for free software development", it seems to me
that there is more evidence that uae is suitable for main than
evidence that ndiswrapper is suitable for main. [To be fair,
this point of view is contradicted, in some contexts, by the fact that
uae needs to emulate a 68k family cpu with a clock speed of
7.14MHz.]
So AFAICS, this term ("UAE requires a specific non-free ROM to
be useful") dominates, making contrib clearly the correct place for
UAE and also rendering UAE useless as a precedent for software
that doesn't have the same constraint of needing a specific piece
of non-free software to be useful.
Nit: there are several different kickstart rom images which can
be used with uae. [But I don't think that's the issue.]
On the other hand, ndiswrapper requires at least one of several
specific pieces of non-free software to be useful.
You can run free software with ndiswrapper. You can run free
software with uae. As you've indicated above, the issue seems
to be usefulness.
I can find many counterexamples in unstable of libraries that don't have
significant communities of free software available written for them, but are
still in main. Where they are excluded, they are excluded based on the
principle that it's not worth supporting an unused library in a stable
release, not on the principle that they don't belong in main because they
"depend" on software we don't include in main.
Maybe we don't need some of those? On the other hand, while we
have contrib for cases such as emulation of non-free system, I
don't think contrib would be a suitable location for all of those libraries.
This last doesn't surprise me in the least; I don't believe that ndiswrapper
even provides an SDK for developers to use in building new NDIS drivers
directly against ndiswrapper. (oh hmm, lightbulb, maybe *this* is the real
difference?)
Eh? I thought it did?
That said, I haven't tried to develop such a driver so I don't know how
suitable the "SDK" is (I think it's mostly some headers and the ability
to inspect ndiswrapper source).
> But on the other hand "free software C depends on free software A"
> does not seem to be sufficient reason to put A in main (there seem
> to be a number of examples involving UAE that illustrate this case).
Written as "free software A does not depend on any non-free software
and free software C depends on A", I'm inclined to believe that this *is*
sufficient reason to not exclude A from main.
Then the mere existence of the free (albeit, limited functionality)
kickstart emulator is sufficient reason to include uae in main?
Or does the software have to be "useful", as we've hinted at, above?
Put differently, if free software "C" does not have to be useful, it would
seem that creating some trivial (but free) stub that depends on some
piece of software in contrib would be sufficient cause to move anything
from contrib to main. I guess, if we got widespread agreement, I could
see going that route. But I'm somewhat dubious of my ability to
convince people that this makes sense.
--
Raul
Reply to: