Re: non-free firmware: driver in main or contrib?
Raul Miller writes:
> > > That said, it sounds like the drivers do behave differently depending on
> > > the firmware -- you've asserted that the difference is not of interest
> > > to the driver, but that's not at all the same as asserting that there
> > > is no difference.
>
> On Tue, Oct 26, 2004 at 01:47:06PM -0400, Michael Poole wrote:
> > The drivers really do nothing differently based on the firmware[1].
>
> In the sense that providing a -1 is no different from providing a 0,
> or in the sense that providing a 100k message is no different from
> providing an empty string, sure -- no difference at all.
>
> It's a matter of point of view.
I am quite certain that you have never worked with the drivers I was
describing, and the chance you have worked with any of the boards is
nearly zero. Your assumption that the differences are anything like
you describe is baseless, and your inference that my description is so
wrong is insulting.
> > > If that's clear, but you think that something else makes more sense,
> > > maybe you could talk about what the consequences of your point of view
> > > would be on Debian? Changes which advance our goals are good things.
> >
> > Drivers that talk to firmware-requiring devices would be allowed in
> > main, rather than in kernel modules or patches kept outside Debian
> > proper. The firmware files themselves would have to be provided by
> > the user or in non-free, unless they qualify under the DFSG[2]. I
> > believe this is the direction being taken for the Linux kernel in
> > general (to not contain opaque blobs, but to provide a facility to
> > load them when needed).
>
> And what are the consequences to Debian with this choice?
It depends on whether you assume users can and will use contrib or
non-free. If you assume that, I do not think it has significant
impact, although it is likely to save the kernel packagers lots of
work. If you assume users cannot or will not use contrib or non-free,
it is the difference between users needing to supply firmware or both
driver and firmware (and likely recompiling their kernel).
> In particular, what freedoms do you think it is acceptable for us to
> require of any "opaque blobs" that we would be distributing with main?
My suggestion does not involve distributing "opaque blobs" with main.
To repeat: THE FIRMWARE FILES THEMSELVES WOULD HAVE TO BE PROVIDED BY
THE USER OR IN NON-FREE, UNLESS THEY QUALIFY UNDER THE DFSG. For
example, some firmware blobs in the Linux kernel are the output of an
assembler, and the assembly source is included in Linux. That kind of
firmware blob is not opaque, and could be distributed in main.
> Is it acceptable for us to require that reverse engineering be allowed
> of things we distribute with main?
Certainly, although I think everything in main should have something
like source code, which would make reverse engineering pointless in
most cases.
> Is it acceptable for us to be able to ship updated copies when the changes
> come from someone with no legal approval from the original author of these
> "opaque blobs"?
I am not sure what you mean. The DFSG require that Debian (or third
parties) be able to freely modify anything in main and distribute
those modifications (possibly in the form of patches).
> Is it acceptable for us to distribute "opaque blobs" which can only be
> used in educational settings, or which require registration before they
> can be unlocked?
You are pretty clearly acting trollish here.
> Are you saying that you want us to ship opaque blobs where we take no
> responsibility whatsoever for their character?
I have said nothing of the sort. Would you like to apologize for
being such a boorish insulting troll, or should I just write you off
as someone not worth listening to?
Michael Poole
Reply to: