Re: Bug#285518: misdn-utils includes a firmware loader

[Glenn Maynard]

On Fri, Dec 17, 2004 at 09:39:46AM +, Matthew Garrett wrote:
> Glenn Maynard <[EMAIL PROTECTED]> wrote:
> > On Fri, Dec 17, 2004 at 02:37:45AM +, Matthew Garrett wrote:
> >> Glenn Maynard <[EMAIL PROTECTED]> wrote:
> >> 
> >> > No, there's a very concrete reason: given an installation of Debian
> >> > main, the driver works.  Drivers that require non-free firmware don't
> >> > work out of the box; 
> >> 
> >> The vast, vast majority of drivers require non-free firmware.
> > 
> > Hmm.  A few places to draw the "dependency from driver to firmware"
> > line seem to be:
> 
> No, that's not what you said. There's some room to quibble over whether
> a dependency exists - there's no room to quibble over whether a
> requirement exists. Almost all modern hardware either contains firmware
> or requires firmware to be uploaded. Therefore, almost all drivers
> require firmware, since otherwise the hardware they drive would not
> exist. 
> 
> Please, let's be honest about what requirements software has.

Sorry, but I don't see a distinction between the word "depend" and
"require" in this context, and I don't see any reason to draw one.
I see a clear difference between a driver that needs (expects, requires,
depends on, you pick) its own copy of a firmware to be copied around--
subjecting users and developers to its copyright restrictions, and
imposing a limitation on the ability of that driver to work out of the
box--and one that does not.

-- 
Glenn Maynard

Re: Bug#285518: misdn-utils includes a firmware loader

[Jonathan McDowell]

On Thu, Dec 16, 2004 at 06:29:46PM -0500, Glenn Maynard wrote:
> On Thu, Dec 16, 2004 at 12:02:30AM +, Jonathan McDowell wrote:
> > If we refuse to handle non-free firmware being loaded onto devices and
> > require they come with it already inside then we get to play the "I
> > can't see it, it doesn't matter" game, which gives the purists a warm
> > fuzzy feeling, knowing no dirty non-free 0s and 1s live on their hard
> > disc.
> > 
> > This improves the experience for our users - they get to have the warm
> > fuzzy feeling too, knowing that in sacrificing the ability to use many
> > modern toys and gadgets they are purer of mind and body. Even better is
> > the fact that they doubley can't use the hardware because we're too busy
> > arguing about the firmware to make a release!
> No, there's a very concrete reason: given an installation of Debian
> main, the driver works.  Drivers that require non-free firmware don't
> work out of the box; they say "sorry, for [legal|philosophical][1]
> reasons, we can include this driver but we can't completely the
> installation automatically like everything else; go hunt down the
> firmware and come back".  Any other software doing that would go
> straight to contrib, but people want to make an exception for drivers.

If you're trying to install the distro and your ADSL modem/wireless
card/SCSI controller needs some firmware to work at all, then going and
hunting down the firmware could prove a bit tricky.

> Your sarcasm and condescension make me wonder why you're here at all,
> though; you appear to regard Debian's founding principles with contempt.

No, I'm just aware of the fact that the Social Contract contains more
than Clause 1. I accept Free Software is a very important part of
Debian, but I'm also able to work out that if our users can't even
install our free software then we're not really doing much for the
promotion of Free Software nor are we managing to serve our users.

J.

-- 
  "For the Limit, I will forgive|   Black Cat Networks Ltd
   all." -- David Damerell, afw.| http://www.blackcatnetworks.co.uk/
|  UK Web, domain and email hosting

Re: Bug#285518: misdn-utils includes a firmware loader

[Matthew Garrett]

Glenn Maynard <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 17, 2004 at 02:37:45AM +, Matthew Garrett wrote:
>> Glenn Maynard <[EMAIL PROTECTED]> wrote:
>> 
>> > No, there's a very concrete reason: given an installation of Debian
>> > main, the driver works.  Drivers that require non-free firmware don't
>> > work out of the box; 
>> 
>> The vast, vast majority of drivers require non-free firmware.
> 
> Hmm.  A few places to draw the "dependency from driver to firmware"
> line seem to be:

No, that's not what you said. There's some room to quibble over whether
a dependency exists - there's no room to quibble over whether a
requirement exists. Almost all modern hardware either contains firmware
or requires firmware to be uploaded. Therefore, almost all drivers
require firmware, since otherwise the hardware they drive would not
exist. 

Please, let's be honest about what requirements software has.

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: Bug#285518: misdn-utils includes a firmware loader

[Frank Küster]

Glenn Maynard <[EMAIL PROTECTED]> wrote:

> On Thu, Dec 16, 2004 at 10:51:39AM +0100, Frank Küster wrote:
>> When the issue of binary blobs in the kernel was first discussed here,
>> if I'm not mistaken the proposed solution was to rewrite the respective
>> drivers to be able to load the blob at runtime from "somewhere", and
>> that somewhere would then be populated from non-free or an external
>> source. And it was said that if the hardware device generally works
>> without firmware loading, just with worse performance, or if most
>> devices supported by the driver worked without, and just a minority
>> depended upon it, then the driver (the kernel module or monolitic
>> kernel) would be Free. 
>
> Just to be a little clearer: drivers that require non-free firmware,
> but are under a Free license, are Free.
>
> Software which is not Free always goes in non-free.  Software that
> is Free goes in either main or contrib.
>
> The active question, here, is not whether these drivers are Free; we're
> assuming they're Free, and asking whether they should go in main or
> contrib due to the firmware being non-free.

Thanks, I really wasn't clear about that. But the question is still the
same: If the procedure described above was regarded as sufficient to
keep distributing the kernel in main, why must a userland tool that does
essentially the same (AFAICT) go to contrib?

Regards, Frank
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Bug#285518: misdn-utils includes a firmware loader

[Peter Van Eynde]

Glenn Maynard wrote:
Hmm.  A few places to draw the "dependency from driver to firmware"
line seem to be:
1: a dependency exists if the driver needs access to a copy of the firmware
(for devices that need the firmware uploaded on every boot);
2: a dependency exists if the hardware needs firmware at all;
There is no way to determine if a device that needs a initialisation 
sequence is in the first or in the second part. The sequence might just be 
a safeguard against accidental activation, or it might patch the firmware. 
For instance if you start an wifi device it has to know your country. Is 
this just used to configure the device or is it used to patch the firmware 
so it does not have to do lookups all the time?

We cannot know.
Groetjes, Peter

Re: Bug#285518: misdn-utils includes a firmware loader

[Glenn Maynard]

On Fri, Dec 17, 2004 at 02:37:45AM +, Matthew Garrett wrote:
> Glenn Maynard <[EMAIL PROTECTED]> wrote:
> 
> > No, there's a very concrete reason: given an installation of Debian
> > main, the driver works.  Drivers that require non-free firmware don't
> > work out of the box; 
> 
> The vast, vast majority of drivers require non-free firmware.

Hmm.  A few places to draw the "dependency from driver to firmware"
line seem to be:

1: a dependency exists if the driver needs access to a copy of the firmware
(for devices that need the firmware uploaded on every boot);

2: a dependency exists if the hardware needs firmware at all;

3: a dependency never exists.

My "don't work out of the box" statement is based on #1: hardware that
requires non-free firmware to be uploaded every time will not work
out of the box in Debian (unless the installer is smart enough to pull
non-free firmware packages from non-free, which, in my opinion, would be a
good thing to do when possible, regardless of where the drivers end up).

Your "vast majority" seems to be based on #2: most hardware does employ
firmware, but (at least among the hardware that I've used) does not require
it to be uploaded every time the device is initialized.  (I don't have
any hardware in #1, except possibly my nVidia hardware--I have no idea
what those drivers are doing.)

-- 
Glenn Maynard

Re: Bug#285518: misdn-utils includes a firmware loader

[Matthew Garrett]

Glenn Maynard <[EMAIL PROTECTED]> wrote:

> No, there's a very concrete reason: given an installation of Debian
> main, the driver works.  Drivers that require non-free firmware don't
> work out of the box; 

The vast, vast majority of drivers require non-free firmware.

> Your sarcasm and condescension make me wonder why you're here at all,
> though; you appear to regard Debian's founding principles with contempt.

Jonathan believes (as I do) that you're choosing the wrong place to draw
an arbitrary line. He has chosen to express this opinion via humour.
Given all that he's done for Debian at various points, suggesting that
he shouldn't be here is really going too far.

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: Bug#285518: misdn-utils includes a firmware loader

[Glenn Maynard]

On Thu, Dec 16, 2004 at 10:51:39AM +0100, Frank Küster wrote:
> When the issue of binary blobs in the kernel was first discussed here,
> if I'm not mistaken the proposed solution was to rewrite the respective
> drivers to be able to load the blob at runtime from "somewhere", and
> that somewhere would then be populated from non-free or an external
> source. And it was said that if the hardware device generally works
> without firmware loading, just with worse performance, or if most
> devices supported by the driver worked without, and just a minority
> depended upon it, then the driver (the kernel module or monolitic
> kernel) would be Free. 

Just to be a little clearer: drivers that require non-free firmware,
but are under a Free license, are Free.

Software which is not Free always goes in non-free.  Software that
is Free goes in either main or contrib.

The active question, here, is not whether these drivers are Free; we're
assuming they're Free, and asking whether they should go in main or
contrib due to the firmware being non-free.

-- 
Glenn Maynard

Re: Bug#285518: misdn-utils includes a firmware loader

[Glenn Maynard]

On Thu, Dec 16, 2004 at 12:02:30AM +, Jonathan McDowell wrote:
> If we refuse to handle non-free firmware being loaded onto devices and
> require they come with it already inside then we get to play the "I
> can't see it, it doesn't matter" game, which gives the purists a warm
> fuzzy feeling, knowing no dirty non-free 0s and 1s live on their hard
> disc.
> 
> This improves the experience for our users - they get to have the warm
> fuzzy feeling too, knowing that in sacrificing the ability to use many
> modern toys and gadgets they are purer of mind and body. Even better is
> the fact that they doubley can't use the hardware because we're too busy
> arguing about the firmware to make a release!

No, there's a very concrete reason: given an installation of Debian
main, the driver works.  Drivers that require non-free firmware don't
work out of the box; they say "sorry, for [legal|philosophical][1]
reasons, we can include this driver but we can't completely the
installation automatically like everything else; go hunt down the
firmware and come back".  Any other software doing that would go
straight to contrib, but people want to make an exception for drivers.

Your sarcasm and condescension make me wonder why you're here at all,
though; you appear to regard Debian's founding principles with contempt.


[1] depending on whether we're allowed to distribute the firmware at all:
if the firmware isn't even in non-free, then it's a legal issue and philosophy
doesn't enter into it.

-- 
Glenn Maynard

Re: Bug#285518: misdn-utils includes a firmware loader

[Frank Küster]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:

> On Tue, 14 Dec 2004 14:21:54 +0100, Simon Richter <[EMAIL PROTECTED]> said: 
>
>> Hi,
>>> It's fine for software in main to be able to do stuff with non-free
>>> data; that's not the issue.  The question is whether there *exists*
>>> any free data that it works with, and if not, whether that's a
>>> problem.
>
>> I don't believe that is a problem. We don't ship the non-free data,
>> we just allow its use. I can see your point, however, that it is
>> useless to ship an utility that cannot be used at present without
>> having non-free data installed.
>
>   Well, if you need the non-free component to be on the file
>  system, why is this different from contrib?  

When the issue of binary blobs in the kernel was first discussed here,
if I'm not mistaken the proposed solution was to rewrite the respective
drivers to be able to load the blob at runtime from "somewhere", and
that somewhere would then be populated from non-free or an external
source. And it was said that if the hardware device generally works
without firmware loading, just with worse performance, or if most
devices supported by the driver worked without, and just a minority
depended upon it, then the driver (the kernel module or monolitic
kernel) would be Free. 

Is this right? If yes, I don't see why this firmware loading software
isn't free. Surely, for the kernel, the firmware loading code shouldn't
be written dozens of times for dozens of drivers, but rather once in an
external source file that is included by all those drivers to do the
actual loading. And if the kernel can be freed by this procedure, this
firmware loading code must be free. Why should analogous code, just in
userland, be non-free? Or why isn't a firmware loading application
analogous to kernel firmware loading code?

Thanks in advance, Frank


-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Bug#285518: misdn-utils includes a firmware loader

[Jonathan McDowell]

On Wed, Dec 15, 2004 at 11:33:30PM +, Matthew Garrett wrote:
> Manoj Srivastava <[EMAIL PROTECTED]> wrote:
> > Well, if you need the non-free component to be on the file
> >  system, why is this different from contrib?  Why can't say of
> >  everything in contrib that well, if the non-free jvm were to
> >  magically appear on the file system this java code would work? Or any
> >  other non-free stuff that needs to be on the fs?
> The requirement for the non-free component exists, even if it isn't on
> the filesystem. What philosophical benefit is there to distinguishing
> between non-free code in a chip on a device and non-free code that
> exists on the filesystem but is executed on that device? How is the
> cause of free software advanced? How is the experience of our users
> improved?
 
Look Matthew, you're an intelligent fellow, but you really don't seem to
get the whole firmware argument.

If we refuse to handle non-free firmware being loaded onto devices and
require they come with it already inside then we get to play the "I
can't see it, it doesn't matter" game, which gives the purists a warm
fuzzy feeling, knowing no dirty non-free 0s and 1s live on their hard
disc.

This improves the experience for our users - they get to have the warm
fuzzy feeling too, knowing that in sacrificing the ability to use many
modern toys and gadgets they are purer of mind and body. Even better is
the fact that they doubley can't use the hardware because we're too busy
arguing about the firmware to make a release!

To be sure, to be sure -- no bread's a lot betther than half a loaf.

J.

-- 
101 things you can't have too much of : 44 - Fame.

Re: Bug#285518: misdn-utils includes a firmware loader

[Matthew Garrett]

Manoj Srivastava <[EMAIL PROTECTED]> wrote:

>   Well, if you need the non-free component to be on the file
>  system, why is this different from contrib?  Why can't say of
>  everything in contrib that well, if the non-free jvm were to
>  magically appear on the file system this java code would work? Or any
>  other non-free stuff that needs to be on the fs?

The requirement for the non-free component exists, even if it isn't on
the filesystem. What philosophical benefit is there to distinguishing
between non-free code in a chip on a device and non-free code that
exists on the filesystem but is executed on that device? How is the
cause of free software advanced? How is the experience of our users
improved?

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: Bug#285518: misdn-utils includes a firmware loader

[Manoj Srivastava]

On Tue, 14 Dec 2004 14:21:54 +0100, Simon Richter <[EMAIL PROTECTED]> said: 

> Hi,
>> It's fine for software in main to be able to do stuff with non-free
>> data; that's not the issue.  The question is whether there *exists*
>> any free data that it works with, and if not, whether that's a
>> problem.

> I don't believe that is a problem. We don't ship the non-free data,
> we just allow its use. I can see your point, however, that it is
> useless to ship an utility that cannot be used at present without
> having non-free data installed.

Well, if you need the non-free component to be on the file
 system, why is this different from contrib?  Why can't say of
 everything in contrib that well, if the non-free jvm were to
 magically appear on the file system this java code would work? Or any
 other non-free stuff that needs to be on the fs?

manoj
-- 
Boy, that crayon sure did hurt!
Manoj Srivastava   <[EMAIL PROTECTED]>  
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C

Re: Bug#285518: misdn-utils includes a firmware loader

[Simon Richter]

Hi,
It's fine for software in main to be able to do stuff with non-free
data; that's not the issue.  The question is whether there *exists* any free
data that it works with, and if not, whether that's a problem.
I don't believe that is a problem. We don't ship the non-free data, we 
just allow its use. I can see your point, however, that it is useless to 
ship an utility that cannot be used at present without having non-free 
data installed.

This case is similar to the Quake one, I think, but I'm not sure it is 
really warranted to make a separate package for a single utility just to 
move it into contrib. The case was clearly different IMO if core 
functionality was affected, but in fact we are discussing about 100 
lines of code within an ISDN stack. :-)

   Simon (who never thought he'd be on the "pragmatic" side)


signature.asc
Description: OpenPGP digital signature

Re: Bug#285518: misdn-utils includes a firmware loader

[Matthew Garrett]

Frank Küster <[EMAIL PROTECTED]> wrote:

> P.S. Shouldn't this be moved to -legal?

No. -legal is useful for determining whether a given piece of code meets
the DFSG or not. It doesn't make policy decisions. -project is a better
place for non-technical discussion of this sort of thing.

-- 
Matthew Garrett | [EMAIL PROTECTED]

Re: Bug#285518: misdn-utils includes a firmware loader

[Glenn Maynard]

On Tue, Dec 14, 2004 at 10:58:52AM +0100, Tollef Fog Heen wrote:
> * Simon Richter 
> 
> | > (If the firmware used by this tool really is Free Software, my
> | > apologies.  However, in that case, the firmware still does not appear to
> | > be available in Debian.)
> | 
> | The tool is generic, hence I cannot make any assumptions on the
> | freeness of any firmware that may be loaded with it once the mISDN
> | stack reaches a non-beta state.

It's fine for software in main to be able to do stuff with non-free
data; that's not the issue.  The question is whether there *exists* any free
data that it works with, and if not, whether that's a problem.

> You might also want to look into the ruling from tech-ctte on 119517
> (referenced in the bug logs) wrt "dependency" when it's a minor part
> on a package's purpose.

That's an issue of "Depends:", not of the Social Contract's "never make
the system depend on an item of non-free software", which I believe is
the issue.  (My understanding--which may well be wrong, of course--is that
the tech-ctte's authority does not extend to the Social Contract or the
DFSG.)

-- 
Glenn Maynard

Re: Bug#285518: misdn-utils includes a firmware loader

[Frank Küster]

Simon Richter <[EMAIL PROTECTED]> wrote:

> Hi,
>
[quoting Josh Triplett]

>> Package: misdn-utils
>> Version: 0.0.0+cvs20041018-4
>> Severity: serious
>
>> misdn-utils contains a utility "loadfirm", for loading firmware onto
>> ISDN devices.  Unless this firmware is Free Software with source, which
>> did not appear to be the case after a large amount of searching, this
>> utility should not be in Debian main.

In what respect is a utility to upload data (which are probably
non-free) to a hardware device different from, for example,
pybliographer?  Pybliographer contains functionality to download data
from PubMed, a free-as-in-beer literature database? What about a program
that is designed to do uploads to the PDB, a free-as-in-beer scientific
database of protein structures? All the data handled by these programs
are non-free (because modification of scientific information is
generally not acceptable, and usage is often restricted).

By the way, what about ftp, a program designed to upload arbitrary data
- often non-free files - to a hardware device via a protocol based on
TCP/IP? 

Regards, Frank

P.S. Shouldn't this be moved to -legal?
-- 
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer

Re: Bug#285518: misdn-utils includes a firmware loader

[Tollef Fog Heen]

* Simon Richter 

| > (If the firmware used by this tool really is Free Software, my
| > apologies.  However, in that case, the firmware still does not appear to
| > be available in Debian.)
| 
| The tool is generic, hence I cannot make any assumptions on the
| freeness of any firmware that may be loaded with it once the mISDN
| stack reaches a non-beta state.

You might also want to look into the ruling from tech-ctte on 119517
(referenced in the bug logs) wrt "dependency" when it's a minor part
on a package's purpose.

-- 
Tollef Fog Heen,''`.
UNIX is user friendly, it's just picky about who its friends are  : :' :
  `. `' 
`-  

Re: Bug#285518: misdn-utils includes a firmware loader

[Simon Richter]

Hi,
Package: misdn-utils
Version: 0.0.0+cvs20041018-4
Severity: serious

misdn-utils contains a utility "loadfirm", for loading firmware onto
ISDN devices.  Unless this firmware is Free Software with source, which
did not appear to be the case after a large amount of searching, this
utility should not be in Debian main.
This is a difficult case, which is why I CCed -devel. Basically, I don't 
see any point in removing it, as it would hurt users who need to upload 
firmware at no gain (since the tool and the kernel module it interfaces 
to are GPLed). You may argue about its uselessness as much as you like, 
it is basically packaged for completeness (the mISDN stack is heavily in 
flux, which is why there are no shared libraries and only few things 
based on it).

If, as the description states,
users are highly unlikely to need the package, then this issue could be
fixed simply by removing the misdn-utils binary package and removing the
loadfirm source from the .orig.tar.gz .  If users really do need the
package, then it should be removed from the misdn-user .orig.tar.gz  and
 placed in a separate source package targetted at contrib.
No. There is no reason to remove DFSG-free stuff from an .orig.tar.gz 
claiming DFSG reasons.

(If the firmware used by this tool really is Free Software, my
apologies.  However, in that case, the firmware still does not appear to
be available in Debian.)
The tool is generic, hence I cannot make any assumptions on the freeness 
of any firmware that may be loaded with it once the mISDN stack reaches 
a non-beta state.

   Simon


signature.asc
Description: OpenPGP digital signature