Re: non-free firmware: driver in main or contrib?
On Tue, Oct 26, 2004 at 06:46:34PM -0400, Michael Poole wrote:
> How many significant free examples of DVD content are there?
I have Debian main (sarge) on DVD, so there's at least one example.
If you're talking about audio-visual materials, I imagine that the right
way to find such materials would focus on academic projects and other such
activities which are likely to generate the relevant kinds of content.
Personally, I don't watch dvds (or tv), so I'm not the right person to
ask for details.
> To the best of my knowledge, all of the DVDs I own contain CSS-encrypted
> content and are compressed using patent-encumbered formats. The CSS
> decryption library that libdvdread3 can use is not part of Debian, but
> MPEG-2 decompressors seem to be in main. It's also not very hard to
> find cases where the MPEG LA has filed patent infringement lawsuits
> based on those patents (against Compaq, Dell, Sagem S.A., effectively
> Apex Digital, and others).
We only very rarely treat software patents as an issue that makes
software non-free.
There's good reasons for this, but that's tangential to this discussion.
Finally, to tie this back to the current discussion, I doubt I'd need
to load different firmware into my dvd drivers if I wanted to deal with
audio/visual content.
> Apart from that, I do not think it is the same situation as a media
> player; the "dependency" is one remove further than for media players.
> If we declare that software depends on programmable bits on the other
> side of a well-defined interface (not one based on function calls), we
> have lots of problems. To pick just one example, evolution-exchange
> would need to move into contrib.
I think you're being overly general here.
For example, interfaces to shared libraries can (and typically are)
well defined interfaces.
That said, it might very well be that evolution-exchange should be in
contrib. I don't know enough about evolution implementations to say
for sure.
> > And, if the driver won't work without the loader, then the driver has
> > a dependency on the loader.
>
> I was not aware that any of these drivers used a non-free loader. Can
> you give an example?
Well... that's not what I was saying, but I have seen hardware where
you had to use some version of MS Windows to load the firmware.
But my point was that packages which depend on contrib need to be in
contrib. [There are, of course, other reasons for being in contrib,
but this reason is rather illustrative.]
> > Is it really too much to ask that there be some free firmware examples
> > before we deal with that class of firmware?
>
> We have linux-2.6.x/drivers/usb/serial/keyspan_pda.S and xircom_pgs.S,
> which I alluded in my previous mail. For each driver that can load
> firmware, do you want Debian to be responsible for tracking down
> whether free firmware exists anywhere in the world?
Ideally, we should be distributing that free firmware. Maybe we don't
automatically use it -- making things automatic can cause problems for
our users.
However, unless the firmware is useless, it seems like we should be
distributing it just as much as we should be distributing the drivers.
> I think that illustrates both the practical and logical flaws in
> claiming that the driver depends on the firmware.
I'll grant that practical issues -- such as an explosion of hardware
implementations -- might keep us from distributing free firmware.
But practical issues which limit our support are not the same as logical
issues which would prevent us from ever offering support.
> > If you expect me to limit my questions to addressing only you have
> > said and to ignore issues raised by others, maybe we shouldn't be
> > having this discussion on a public list.
>
> I expect you to not raise strawman arguments. Your last two questions
> go beyond anything I have seen suggested in this discussion. I also
> do not see the pertinence; Debian disclaims responsibility for the
> performance and behavior of everything it distributes. Case in point:
> the fairly recent -project discussion along the lines of "Reflections
> on Trusting Trust" and whether it applied to Debian's toolchain.
It's kinda hard for an argument to be a strawman when the argument fits
within the scope of the previous arguments which had been discussed.
And the scope of this argument has been very broad (up to, and including
people claiming that hardware components should comply with our free
software guidelines).
It's true that the questions I asked were not issues which you had
raised -- I had raised them. The pertinence was simply that I was
trying to understand what your point of view was. I think I have a
better understanding now, and will try to limit my discussion to issues
which seem pertinent to the view point you are interested in discussing.
About responsibility: we do try and make sure our system works right.
And, I'm not specifically sure what thread you're referring to. Perhaps
you're referring to "Unofficial buildd network has been shut down"
which took place on debian-devel last month?
Finally, if you're saying that for practical reasons a driver or loader
which requires non-free software to be loaded could slip into main --
I agree. But this should be treated as a bug, and we should allow people
with the energy to fix that problem to do so.
Thanks,
--
Raul
Reply to: