non-free firmware in kernel modules, aggregation and unclear copyright notice.

non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

Hello,

<quick sumary>
Current linux kernel source hold undistributable non-free firmware blobs, and
to consider them as mere agregation, a clear licence statement from the
copyright holders of said non-free firmware blobls is needed, read below for
details.
</quick sumary>

Please keep everyone in the CC, as not everyone reads debian-legal or LKML.

Some kernel modules present in the kernel sources as distributed from
ftp.kernel.org present some non-free binary only firmware that gets uploaded
in the target chip by the controler. tg3, qla2xxx, acenix and a couple of
others are example of such modules with non-free firmware blobs.

This is no major problem per see, since, as discussed in this thread :

  http://lists.debian.org/debian-legal/2005/03/msg00283.html

It is obvious in this context that the non-free firmware constitute a mere
aggregation and not an act of linking with the rest of the kernel. This is at
least the consensus that debian has reached with input from the debian-legal
lists, and what we will stand by this.

Naturally even if debian has come to the conclusion that these non-free
firmware blobs are not a violation of the rest of the kernel GPL licence, it
still doesn't make these non-free firmware blobs free software, and thus they
and the drivers which contain it will be removed from debian/main, and put
into the non-free section of our archive.

Now, these non-free firmware are distributed in the same file as the rest of
the module which uses it. This is still ok since it constitute agregation on
a same distribution media, where the distribution media is the file in this
case. 

But these files, as seen in the tg3.c case, have no special mention of the
firmware in the file header, nor are they distinguished in any way from the
rest of the content of that file, which places them de facto under the GPL,
since.

Accordying to the GPL, we thus needs the source files for this non-free
firmware, which is not available, and thus makes the files undistributable.
Even if we would consider these firmware as separate and not covered by the
de-facto GPLing of the files in question, we still would have no licence
allowing us to distribute those non-free firmware blobs, and thus we have
again no right to distribute them as part of the kernel.

The clean solution is to have a small notice in the header of those files or
in the toplevel COPYING file, excluding those firmware blobs from the general
GPLing of the files, and have a small comment inside the files to identify the
firmware blobs as such and again excluding them from the GPL, and possibly a
toplevel listing of all the files wich have such problems.

This is an easy fix, and i believe even those who held the above analysis as
non-sense or whatever will agree that this is something that should be done.
The real problem being that nobody except the copyright holder of those
firmware blobs is legally allowed to make said modification, and thus i bring
this issue to everyone's attention, for comment and feedback, before trying to
reach the copyright holders of those individual firmware blobs asking them to
clarify the situation. I believe many of those read this list anyway, so would
be able to fix the issue or comment on it without further proding needed.

In hopes of quick resolution of these murky legalese issues nobody is really
fond of, 

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Arjan van de Ven]

On Mon, 2005-04-04 at 12:09 +0200, Sven Luther wrote:

please take this discussion elsewhere. Also please never cc three such
lists on the same posting, there is absolutely no point in doing that.

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Mon, Apr 04, 2005 at 12:21:05PM +0200, Arjan van de Ven wrote:
> On Mon, 2005-04-04 at 12:09 +0200, Sven Luther wrote:
> 
> please take this discussion elsewhere. Also please never cc three such

Ok, can you please point to me where is the place it should be taken off ? I
suppose you mean LKML ? 

> lists on the same posting, there is absolutely no point in doing that.

We already had this discussion on debian-legal and debian-kernel, so i
included them for documentation purpose, so people there can follow the
discussion even if they don't follow LKML which is rather high volume. As the
discussion already was hold there, i don't believe you will see many comments
from them.

So, i posted to LKML directly, as i believe that it is where this needs to be
solved, as only the copyright holders can fix this licencing problem, and
currently the kernels distributed from ftp.kernel.org are not legally
distributable.

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Jes Sorensen]

>>>>> "Sven" == Sven Luther <sven.luther@wanadoo.fr> writes:

Sven> On Mon, Apr 04, 2005 at 12:21:05PM +0200, Arjan van de Ven
Sven> wrote:
>> On Mon, 2005-04-04 at 12:09 +0200, Sven Luther wrote:
>> 
>> please take this discussion elsewhere. Also please never cc three
>> such

Sven> Ok, can you please point to me where is the place it should be
Sven> taken off ? I suppose you mean LKML ?

Yes please!

>> lists on the same posting, there is absolutely no point in doing
>> that.

Sven> We already had this discussion on debian-legal and
Sven> debian-kernel, so i included them for documentation purpose, so
Sven> people there can follow the discussion even if they don't follow
Sven> LKML which is rather high volume. As the discussion already was
Sven> hold there, i don't believe you will see many comments from
Sven> them.

Sven> So, i posted to LKML directly, as i believe that it is where
Sven> this needs to be solved, as only the copyright holders can fix
Sven> this licencing problem, and currently the kernels distributed
Sven> from ftp.kernel.org are not legally distributable.

Feel free to have your own legal oppinion about whether or not those
kernels can be distributed. However please keep that discussion
elsewhere.

If you want the firmware situation changed, I'd recommend spending
your time on improving the firmware loader interface instead.

Thanks,
Jes

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

Hi Jes, long time without hearing about you :)

On Thu, Apr 07, 2005 at 03:17:33AM -0400, Jes Sorensen wrote:
> Sven> On Mon, Apr 04, 2005 at 12:21:05PM +0200, Arjan van de Ven
> Sven> wrote:
> 
> Sven> Ok, can you please point to me where is the place it should be
> Sven> taken off ? I suppose you mean LKML ?
> 
> Yes please!

Why ? It does concern you all, doesn't it ? or we will be working to get the
actual firmware problem solved, and then people will introduce new problematic
firmware case.

> If you want the firmware situation changed, I'd recommend spending
> your time on improving the firmware loader interface instead.

Which will not help without the copyright licencing issue being solved first
though, as we do not have any right to distribute most of those firmwares.

And no, we are not only bringing this issue and bothering everyone else, we
are also doing the work needed to solve the issue with upstream, see : 

  http://wiki.debian.net/?KernelFirmwareLicensing

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Michael Poole]

Sven Luther writes:

> Hello,
>
> <quick sumary>
> Current linux kernel source hold undistributable non-free firmware blobs, and
> to consider them as mere agregation, a clear licence statement from the
> copyright holders of said non-free firmware blobls is needed, read below for
> details.
> </quick sumary>
>
> Please keep everyone in the CC, as not everyone reads debian-legal or LKML.

This question comes up every four or five months.  You might have even
been the last one to raise this question on one or more of the mailing
lists you cc'ed.  Please, go check the list archives for the previous
(lengthy and multiple) discussions about this topic.

Michael Poole

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Mon, Apr 04, 2005 at 09:26:58AM -0400, Michael Poole wrote:
> Sven Luther writes:
> 
> > Hello,
> >
> > <quick sumary>
> > Current linux kernel source hold undistributable non-free firmware blobs, and
> > to consider them as mere agregation, a clear licence statement from the
> > copyright holders of said non-free firmware blobls is needed, read below for
> > details.
> > </quick sumary>
> >
> > Please keep everyone in the CC, as not everyone reads debian-legal or LKML.
> 
> This question comes up every four or five months.  You might have even
> been the last one to raise this question on one or more of the mailing
> lists you cc'ed.  Please, go check the list archives for the previous
> (lengthy and multiple) discussions about this topic.

Sure, i raised this the last time, and it was discussed on debian-legal and
debian-kernel, and since nobody objected, and many where in accord with my
arguments in that thread i linked in the parent post, i believe consensus was
reached. This is basically the position debian has, and work has already been
started to move some of the affected modules in a separate package, which will
be distributed from non-free.

This is just the followup on said discussion, involving the larger LKML
audience, in order to get this fixed for good. As said, it is just a mere
technicality to get out of the muddy situation, all the people having
contributed source-less firmware blobs, need to give us (us being debian, but
also all the linux kernel community) either the source if they persist in
distributing the code under the GPL, or a clear distribution licence for these
firmware blobs, and clearly identificate them as not covered by the GPL that
the file they come in is.

Discussing legal issues is all cool and nice for those that appreciates such
sport, but it doesn't really make sense if it is not applied to acts later on.

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Greg KH]

On Mon, Apr 04, 2005 at 04:16:47PM +0200, Sven Luther wrote:
> This is just the followup on said discussion, involving the larger LKML
> audience, in order to get this fixed for good. As said, it is just a mere
> technicality to get out of the muddy situation, all the people having
> contributed source-less firmware blobs, need to give us (us being debian, but
> also all the linux kernel community) either the source if they persist in
> distributing the code under the GPL, or a clear distribution licence for these
> firmware blobs, and clearly identificate them as not covered by the GPL that
> the file they come in is.

What if we don't want to do so?  I know I personally posted a solution
for this _5_ years ago in debian-legal, and have yet to receive a
patch...

> Discussing legal issues is all cool and nice for those that appreciates such
> sport, but it doesn't really make sense if it is not applied to acts later on.

Then let's see some acts.  We (lkml) are not the ones with the percieved
problem, or the ones discussing it.

bleah.

greg k-h

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
> On Mon, Apr 04, 2005 at 04:16:47PM +0200, Sven Luther wrote:
> > This is just the followup on said discussion, involving the larger LKML
> > audience, in order to get this fixed for good. As said, it is just a mere
> > technicality to get out of the muddy situation, all the people having
> > contributed source-less firmware blobs, need to give us (us being debian, but
> > also all the linux kernel community) either the source if they persist in
> > distributing the code under the GPL, or a clear distribution licence for these
> > firmware blobs, and clearly identificate them as not covered by the GPL that
> > the file they come in is.
> 
> What if we don't want to do so?

You mean, you as copyright holder are not willing to mark the firmware blobs
as not covered by the GPL, then it is simple, the firmware blob in question is
covered by the GPL, and since it lacks source, the whole lot is
non-distributable, and any contributor to the linux kernel can sue
ftp.kernel.org or whoever else is distributing the kernel code. I don't know
if users are able to sue you under the GPL for failing to provide the source
code though.

Seriously, it is just a couple of lines of comments on top of the file, who in
his right mind would object to fixing this issue ? 

> I know I personally posted a solution for this _5_ years ago in debian-legal,
> and have yet to receive a patch...

Well, maybe, but *I* was not there 5 years ago, indeed i believe i didn't even
was remotely connected to the kernel folks inside debian back then, nor even
heard of debian-legal, so i would much like to hear of your proposal, care to
give me a hint about the name of the thread it was in or something ? 

> > Discussing legal issues is all cool and nice for those that appreciates such
> > sport, but it doesn't really make sense if it is not applied to acts later on.
> 
> Then let's see some acts.  We (lkml) are not the ones with the percieved
> problem, or the ones discussing it.

Well, it is currently a violation of the GPL to distribute those firmware
blobs without clearly saying that they are not covered by the GPL. What is the
harm that comes by doing that ? All the other dubious points have been set
aside by the discussion on the thread you probably didn't read. 

Right now, the licencing information is only present in the toplevel COPYRIGHT
file, which is mostly the GPL (excluding user programs :), and since things
like tg3.c which contain such non-free firmware blobs don't say anything else
about the copyright of them, they de-facto fall under the toplevel COPYRIGHT,
including their firmware blobs which lack sources.

All i am asking is that *the copyright holders* of said firmware blobs put a
little comment on top of the files in question saying, all this driver is
GPLed, except the firmware blobs, and we give redistribution rights to said
firmware blobs.

The mention of acts was for the folk at debian-legal who like speaking a lot
in circle and not bring anything forward, which your mention of patches above
confirms :)

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Ian Campbell]

[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]

On Mon, 2005-04-04 at 20:21 +0200, Sven Luther wrote:
> On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
> > Then let's see some acts.  We (lkml) are not the ones with the percieved
> > problem, or the ones discussing it.

[...]

> All i am asking is that *the copyright holders* of said firmware blobs put a
> little comment on top of the files in question saying, all this driver is
> GPLed, except the firmware blobs, and we give redistribution rights to said
> firmware blobs.

I think what Greg may have meant[0] was that if it bothers you, then you
should act by contacting the copyright holders privately yourself in
each case that you come across and asking them if you may add a little
comment etc, and then submit patches once you have their agreement.

Ian.

[0] if I may be so bold as to put words into his mouth.
-- 
Ian Campbell

Hiccuping & trembling into the WASTE DUMPS of New Jersey like some
drunken CABBAGE PATCH DOLL, coughing in line at FIORUCCI'S!!

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Mon, Apr 04, 2005 at 08:12:48PM +0100, Ian Campbell wrote:
> On Mon, 2005-04-04 at 20:21 +0200, Sven Luther wrote:
> > On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
> > > Then let's see some acts.  We (lkml) are not the ones with the percieved
> > > problem, or the ones discussing it.
> 
> [...]
> 
> > All i am asking is that *the copyright holders* of said firmware blobs put a
> > little comment on top of the files in question saying, all this driver is
> > GPLed, except the firmware blobs, and we give redistribution rights to said
> > firmware blobs.
> 
> I think what Greg may have meant[0] was that if it bothers you, then you
> should act by contacting the copyright holders privately yourself in
> each case that you come across and asking them if you may add a little
> comment etc, and then submit patches once you have their agreement.

Yeah, that is step 3, i mailed LKML, because maybe you would have some useful
coment, or some of you who wrote said code may have contacts or something with
the copyright holders, or some other insight. I also didn't want this to cause
a problem if i blundered in some tense relationship or whatever.

For example, the tg3 driver says : 

 * tg3.c: Broadcom Tigon3 ethernet driver.
 *
 * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (davem@redhat.com)
 * Copyright (C) 2001, 2002, 2003 Jeff Garzik (jgarzik@pobox.com)
 * Copyright (C) 2004 Sun Microsystems Inc.
 *
 * Firmware is:
 *      Copyright (C) 2000-2003 Broadcom Corporation.

There is no contact for either sun or broadcom, but i believe that Jeff or
David may know where this firmware blob may (or not) come from.

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Roland Dreier]

    Ian> I think what Greg may have meant[0] was that if it bothers
    Ian> you, then you should act by contacting the copyright holders
    Ian> privately yourself in each case that you come across and
    Ian> asking them if you may add a little comment etc, and then
    Ian> submit patches once you have their agreement.

Perhaps another solution would be for someone who has received a
supposedly GPLed Linux kernel from, say, SuSE, to contact SuSE and ask
for the source code to things such as

static u32 tg3FwText[(TG3_FW_TEXT_LEN / sizeof(u32)) + 1] = {
	0x00000000, 0x10000003, 0x00000000, 0x0000000d, 0x0000000d, 0x3c1d0800,
	0x37bd3ffc, 0x03a0f021, 0x3c100800, 0x26100000, 0x0e000018, 0x00000000,
	0x0000000d, 0x3c1d0800, 0x37bd3ffc, 0x03a0f021, 0x3c100800, 0x26100034,
	0x0e00021c, 0x00000000, 0x0000000d, 0x00000000, 0x00000000, 0x00000000,
	0x27bdffe0, 0x3c1cc000, 0xafbf0018, 0xaf80680c, 0x0e00004c, 0x241b2105,
	/* ... */

in drivers/net/tg3.c.  (tg3.c does not contain any license information
at all, and therefore falls under the kernel's GPLv2 license, right?)

 - R.

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
> On Mon, Apr 04, 2005 at 04:16:47PM +0200, Sven Luther wrote:
> > This is just the followup on said discussion, involving the larger LKML
> > audience, in order to get this fixed for good. As said, it is just a mere
> > technicality to get out of the muddy situation, all the people having
> > contributed source-less firmware blobs, need to give us (us being debian, but
> > also all the linux kernel community) either the source if they persist in
> > distributing the code under the GPL, or a clear distribution licence for these
> > firmware blobs, and clearly identificate them as not covered by the GPL that
> > the file they come in is.
> 
> What if we don't want to do so?  I know I personally posted a solution
> for this _5_ years ago in debian-legal, and have yet to receive a
> patch...

Mmm, probably that 2001 discussion about the keyspan firmware, right ?

  http://lists.debian.org/debian-legal/2001/04/msg00145.html

Can you summarize the conclusion of the thread, or what you did get from it,
please ? 

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Greg KH]

On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> 
>   http://lists.debian.org/debian-legal/2001/04/msg00145.html
> 
> Can you summarize the conclusion of the thread, or what you did get from it,
> please ? 

That people didn't like the inclusion of firmware, I posted how you can
fix it by moving it outside of the kernel, and asked for patches.

None have come.

So I refuse to listen to talk about this, as obviously, no one cares
enough about this to actually fix the issue.

People drag this up about once a year, so you are just following the
trend...

This is my last reply to this thread, unless it contains code.

greg k-h

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > 
> >   http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > 
> > Can you summarize the conclusion of the thread, or what you did get from it,
> > please ? 
> 
> That people didn't like the inclusion of firmware, I posted how you can
> fix it by moving it outside of the kernel, and asked for patches.

Yeah, that is a solution to it, and i also deplore that none has done the job
to make it loadable from userland. For now, debian is satisfied by moving the
whole modules involved to non-free, and this has already happened in part.

> None have come.
> 
> So I refuse to listen to talk about this, as obviously, no one cares
> enough about this to actually fix the issue.

Well, i disagree with the above analysis. The problem is not so much that the
firmware violate the GPL, as it constitutes mere agregation, but that the
actual copyright statement of the files containing the firmware blobs place
them de-facto under the GPL, which i doubt is what was intented originally,
don't you think.

And *I* do care about this issue, and will follow up this issue with mails to
the individual copyright holders of the file, to clarify the situation.

> People drag this up about once a year, so you are just following the
> trend...

Nope, i am aiming to clarify this issue with regard to the debian kernel, so
that we may be clear with ourselves, and actually ship something which is not
of dubious legal standing, and that we could get sued over for GPL violation.

> This is my last reply to this thread, unless it contains code.

Ok, but i hope that not only code, but patches clarifying the legal situation
will make you happy.

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Adrian Bunk]

On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote:
> On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > > 
> > >   http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > > 
> > > Can you summarize the conclusion of the thread, or what you did get from it,
> > > please ? 
> > 
> > That people didn't like the inclusion of firmware, I posted how you can
> > fix it by moving it outside of the kernel, and asked for patches.
> 
> Yeah, that is a solution to it, and i also deplore that none has done the job
> to make it loadable from userland. For now, debian is satisfied by moving the
> whole modules involved to non-free, and this has already happened in part.


Does this imply your installer will use these non-free modules?

If the driver for the controller your harddisk is behind is not used by 
the installer you could simply remove these modules instead of moving 
them to non-free.


> > None have come.
> > 
> > So I refuse to listen to talk about this, as obviously, no one cares
> > enough about this to actually fix the issue.
> 
> Well, i disagree with the above analysis. The problem is not so much that the
> firmware violate the GPL, as it constitutes mere agregation, but that the
> actual copyright statement of the files containing the firmware blobs place
> them de-facto under the GPL, which i doubt is what was intented originally,
> don't you think.
> 
> And *I* do care about this issue, and will follow up this issue with mails to
> the individual copyright holders of the file, to clarify the situation.
> 
> > People drag this up about once a year, so you are just following the
> > trend...
> 
> Nope, i am aiming to clarify this issue with regard to the debian kernel, so
> that we may be clear with ourselves, and actually ship something which is not
> of dubious legal standing, and that we could get sued over for GPL violation.
>...


If it was a GPL violation, it wasn't enough to contact only the small 
subset of copyright holders that worked on this specific file since 
this file might be compiled statically into the GPL'ed kernel.


> Friendly,
> 
> Sven Luther


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Mon, Apr 04, 2005 at 09:58:30PM +0200, Adrian Bunk wrote:
> On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote:
> > On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> > > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > > > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > > > 
> > > >   http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > > > 
> > > > Can you summarize the conclusion of the thread, or what you did get from it,
> > > > please ? 
> > > 
> > > That people didn't like the inclusion of firmware, I posted how you can
> > > fix it by moving it outside of the kernel, and asked for patches.
> > 
> > Yeah, that is a solution to it, and i also deplore that none has done the job
> > to make it loadable from userland. For now, debian is satisfied by moving the
> > whole modules involved to non-free, and this has already happened in part.
> 
> 
> Does this imply your installer will use these non-free modules?

The installer already has provision for loading additional .udebs from floppy
or net, not sure about other media, and we don't build yet non-free d-i images
with those non-free modules builtin, but it could be arranged. This is
post-sarge issues though, and we still have some time to solve them.

> If the driver for the controller your harddisk is behind is not used by 
> the installer you could simply remove these modules instead of moving 
> them to non-free.

yeah, the problem is a whole bunch of people have tg3 network cards it seem :)

> > Nope, i am aiming to clarify this issue with regard to the debian kernel, so
> > that we may be clear with ourselves, and actually ship something which is not
> > of dubious legal standing, and that we could get sued over for GPL violation.
> >...
> 
> 
> If it was a GPL violation, it wasn't enough to contact only the small 
> subset of copyright holders that worked on this specific file since 
> this file might be compiled statically into the GPL'ed kernel.

That is not a problem, since even if the firmware is built into the same
executable as the rest of the kernel code, it still constitutes only mere
agregation, where the kernel is the distribution media, in the GPL sense.
Please read the mail i linked too in the original mail for detailed
argumentation of this.

The only problem to it constituting mere agregation is that the firmware blob
is not clearly identified as such in the tg3.c file (for example), and that
there is no licencing condition allowing their distribution apart the GPL,
which these firmware blobs where evidently not meant to be put under.

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Adrian Bunk]

On Mon, Apr 04, 2005 at 10:23:08PM +0200, Sven Luther wrote:
> On Mon, Apr 04, 2005 at 09:58:30PM +0200, Adrian Bunk wrote:
> > On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote:
> > > On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> > > > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > > > > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > > > > 
> > > > >   http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > > > > 
> > > > > Can you summarize the conclusion of the thread, or what you did get from it,
> > > > > please ? 
> > > > 
> > > > That people didn't like the inclusion of firmware, I posted how you can
> > > > fix it by moving it outside of the kernel, and asked for patches.
> > > 
> > > Yeah, that is a solution to it, and i also deplore that none has done the job
> > > to make it loadable from userland. For now, debian is satisfied by moving the
> > > whole modules involved to non-free, and this has already happened in part.
> > 
> > 
> > Does this imply your installer will use these non-free modules?
> 
> The installer already has provision for loading additional .udebs from floppy
> or net, not sure about other media, and we don't build yet non-free d-i images
> with those non-free modules builtin, but it could be arranged. This is
> post-sarge issues though, and we still have some time to solve them.
> 
> > If the driver for the controller your harddisk is behind is not used by 
> > the installer you could simply remove these modules instead of moving 
> > them to non-free.
> 
> yeah, the problem is a whole bunch of people have tg3 network cards it seem :)


I was more thinking about SCSI controllers, but tg3 is also interesting.

Additional non-free d-i images will for sure be required, or several 
hardware setups might make installation of Debian impossible without 
bootstrapping through a different OS or distribution.


> > > Nope, i am aiming to clarify this issue with regard to the debian kernel, so
> > > that we may be clear with ourselves, and actually ship something which is not
> > > of dubious legal standing, and that we could get sued over for GPL violation.
> > >...
> > 
> > 
> > If it was a GPL violation, it wasn't enough to contact only the small 
> > subset of copyright holders that worked on this specific file since 
> > this file might be compiled statically into the GPL'ed kernel.
> 
> That is not a problem, since even if the firmware is built into the same
> executable as the rest of the kernel code, it still constitutes only mere
> agregation, where the kernel is the distribution media, in the GPL sense.
> Please read the mail i linked too in the original mail for detailed
> argumentation of this.
> 
> The only problem to it constituting mere agregation is that the firmware blob
> is not clearly identified as such in the tg3.c file (for example), and that
> there is no licencing condition allowing their distribution apart the GPL,
> which these firmware blobs where evidently not meant to be put under.


This is one possible legal interpretation of "mere aggregation".

Whether judges in all jurisdictions of the world follow this 
interpretation or an interpretation of the GPL in one direction or 
another is the more interesting question.


> Friendly,
> 
> Sven Luther

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Mon, Apr 04, 2005 at 11:05:03PM +0200, Adrian Bunk wrote:
> On Mon, Apr 04, 2005 at 10:23:08PM +0200, Sven Luther wrote:
> > On Mon, Apr 04, 2005 at 09:58:30PM +0200, Adrian Bunk wrote:
> > > On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote:
> > > > On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> > > > > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > > > > > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > > > > > 
> > > > > >   http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > > > > > 
> > > > > > Can you summarize the conclusion of the thread, or what you did get from it,
> > > > > > please ? 
> > > > > 
> > > > > That people didn't like the inclusion of firmware, I posted how you can
> > > > > fix it by moving it outside of the kernel, and asked for patches.
> > > > 
> > > > Yeah, that is a solution to it, and i also deplore that none has done the job
> > > > to make it loadable from userland. For now, debian is satisfied by moving the
> > > > whole modules involved to non-free, and this has already happened in part.
> > > 
> > > 
> > > Does this imply your installer will use these non-free modules?
> > 
> > The installer already has provision for loading additional .udebs from floppy
> > or net, not sure about other media, and we don't build yet non-free d-i images
> > with those non-free modules builtin, but it could be arranged. This is
> > post-sarge issues though, and we still have some time to solve them.
> > 
> > > If the driver for the controller your harddisk is behind is not used by 
> > > the installer you could simply remove these modules instead of moving 
> > > them to non-free.
> > 
> > yeah, the problem is a whole bunch of people have tg3 network cards it seem :)
> 
> 
> I was more thinking about SCSI controllers, but tg3 is also interesting.
> 
> Additional non-free d-i images will for sure be required, or several 
> hardware setups might make installation of Debian impossible without 
> bootstrapping through a different OS or distribution.

Well, you only need one free way to get access to external media, non-free d-i
simply add a bunch of non-free .udebs to the initrd.

> > > > Nope, i am aiming to clarify this issue with regard to the debian kernel, so
> > > > that we may be clear with ourselves, and actually ship something which is not
> > > > of dubious legal standing, and that we could get sued over for GPL violation.
> > > >...
> > > 
> > > 
> > > If it was a GPL violation, it wasn't enough to contact only the small 
> > > subset of copyright holders that worked on this specific file since 
> > > this file might be compiled statically into the GPL'ed kernel.
> > 
> > That is not a problem, since even if the firmware is built into the same
> > executable as the rest of the kernel code, it still constitutes only mere
> > agregation, where the kernel is the distribution media, in the GPL sense.
> > Please read the mail i linked too in the original mail for detailed
> > argumentation of this.
> > 
> > The only problem to it constituting mere agregation is that the firmware blob
> > is not clearly identified as such in the tg3.c file (for example), and that
> > there is no licencing condition allowing their distribution apart the GPL,
> > which these firmware blobs where evidently not meant to be put under.
> 
> 
> This is one possible legal interpretation of "mere aggregation".
> 
> Whether judges in all jurisdictions of the world follow this 
> interpretation or an interpretation of the GPL in one direction or 
> another is the more interesting question.

This is also hinted at by the FSF FAQ, and a verbatim interpretation of the
actual GPL text. And you can proof by asburd that it has to be so, or you
start facing no end of troubles :)

The thread i linked, which is rather short, has some more legalese
explanations (not by me :), if you are interested.

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Theodore Ts'o]

On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote:
> 
> Nope, i am aiming to clarify this issue with regard to the debian kernel, so
> that we may be clear with ourselves, and actually ship something which is not
> of dubious legal standing, and that we could get sued over for GPL violation.
> 

You know, the fact that Red Hat, SuSE, Ubuntu, and pretty much all
other commercial distributions have not been worried about getting
sued for this alleged GPL'ed violation makes it a lot harder for me
(and others, I'm sure) take Debian's concerns seriously.

The problem may be that because Debian is purely a non-profit, and so
it can't clearly balance the costs and benefits of trying trying to
avoid every single possible risks where someone might decide to file a
lawsuit.  Anytime you do *anything* you risk the possibility of a
lawsuit, and if you allow the laywers to take over your business
decisions, the natural avoid-risks-all-costs bias of lawyers are such
that it will either drive a company out of business, or drive a
non-profit distribution into irrelevance.....

If Debian wants to be this fanatical, then let those Debian developers
who care do all of the work to make this happen, and stop bothering
LKML.  And if it continues to remain the case that a user will have to
manually edit /etc/apt/sources.lists (using vi!) to include a
reference to non-free in order to install Debian on a system that
requires the tg3 device driver, then I will have to tell users who ask
me that they would be better off using some other distribution which
actually cares about their needs.

						- Ted

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Mon, Apr 04, 2005 at 04:55:27PM -0400, Theodore Ts'o wrote:
> On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote:
> > 
> > Nope, i am aiming to clarify this issue with regard to the debian kernel, so
> > that we may be clear with ourselves, and actually ship something which is not
> > of dubious legal standing, and that we could get sued over for GPL violation.
> > 
> 
> You know, the fact that Red Hat, SuSE, Ubuntu, and pretty much all
> other commercial distributions have not been worried about getting
> sued for this alleged GPL'ed violation makes it a lot harder for me
> (and others, I'm sure) take Debian's concerns seriously.

They probably didn't care :)

> The problem may be that because Debian is purely a non-profit, and so
> it can't clearly balance the costs and benefits of trying trying to
> avoid every single possible risks where someone might decide to file a
> lawsuit.  Anytime you do *anything* you risk the possibility of a
> lawsuit, and if you allow the laywers to take over your business
> decisions, the natural avoid-risks-all-costs bias of lawyers are such
> that it will either drive a company out of business, or drive a
> non-profit distribution into irrelevance.....

Yes, the problem is indeed that we don't have a legal department which can
counter sue, and we are present in a much more widespread area than other
companies you cited above.

And ubuntu has those driver in their non-free equivalent also.

> If Debian wants to be this fanatical, then let those Debian developers
> who care do all of the work to make this happen, and stop bothering
> LKML.  And if it continues to remain the case that a user will have to
> manually edit /etc/apt/sources.lists (using vi!) to include a
> reference to non-free in order to install Debian on a system that
> requires the tg3 device driver, then I will have to tell users who ask
> me that they would be better off using some other distribution which
> actually cares about their needs.

I don't get this, and you threat me as fanatic. I am only saying that the
tg3.c and other file are under the GPL, and that the firmware included in it
is *NOT* intented to be under the GPL, so why not say it explicitly ? 

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Ian Campbell]

On Mon, 2005-04-04 at 23:19 +0200, Sven Luther wrote:

> I am only saying that the tg3.c and other file are under the GPL, and
> that the firmware included in it is *NOT* intented to be under the
> GPL, so why not say it explicitly ? 

I don't think anyone here has disagreed. What almost everyone has said
however is "so go and do it" -- go do the research, contact the
copyright holders directly and get the permission to make patches, then
post them here.

There is really no point in discussing it here, just get on and do it.

Ian.

-- 
Ian Campbell

Cheops' Law:
	Nothing ever gets built on schedule or within budget.

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Tue, Apr 05, 2005 at 09:19:24AM +0100, Ian Campbell wrote:
> On Mon, 2005-04-04 at 23:19 +0200, Sven Luther wrote:
> 
> > I am only saying that the tg3.c and other file are under the GPL, and
> > that the firmware included in it is *NOT* intented to be under the
> > GPL, so why not say it explicitly ? 
> 
> I don't think anyone here has disagreed. What almost everyone has said
> however is "so go and do it" -- go do the research, contact the
> copyright holders directly and get the permission to make patches, then
> post them here.

Ok. I have some doubts about doing the work, and it then being rejected and
i did the work first, which is why i asked. It seemed a reasonable thing to
ask, and my analysis of the problem was sound, so why didn't i get a, yeah, go
ahead, instead of this rejection ?

> There is really no point in discussing it here, just get on and do it.

As i said, some may know things about relationship, or lack thereof, with the
copyright holder, i believe that the people who added those firmware blobs are
all reading this here, and it is from them that i wanted feedback, but it
failed to produce that effect.

/me will investigate bk and how to get the information on who signed those
changes off and commited them :)

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Ian Campbell]

On Tue, 2005-04-05 at 10:32 +0200, Sven Luther wrote:
> On Tue, Apr 05, 2005 at 09:19:24AM +0100, Ian Campbell wrote:
> > On Mon, 2005-04-04 at 23:19 +0200, Sven Luther wrote:
> > 
> > > I am only saying that the tg3.c and other file are under the GPL, and
> > > that the firmware included in it is *NOT* intented to be under the
> > > GPL, so why not say it explicitly ? 
> > 
> > I don't think anyone here has disagreed. What almost everyone has said
> > however is "so go and do it" -- go do the research, contact the
> > copyright holders directly and get the permission to make patches, then
> > post them here.
> 
> Ok. I have some doubts about doing the work, and it then being rejected and
> i did the work first, which is why i asked. It seemed a reasonable thing to
> ask, and my analysis of the problem was sound, so why didn't i get a, yeah, go
> ahead, instead of this rejection ?

I don't think you did get a rejection, a few people said that _they_
weren't going to do it, but if you want to then go ahead. I think people
are just fed up of people bringing up the issue and then failing to do
anything about it -- so prove them wrong ;-)

Ian.

-- 
Ian Campbell

knghtbrd: there may be no spoon, but can you spot the vulnerability in
eye_render_shiny_object.c?
        -- rcw

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Christoph Hellwig]

On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote:
> I don't think you did get a rejection, a few people said that _they_
> weren't going to do it, but if you want to then go ahead. I think people
> are just fed up of people bringing up the issue and then failing to do
> anything about it -- so prove them wrong ;-)

Actually patches to add firmware loader support to tg3 got rejected.

Which is think is very unfortunately as we set the highlevel goal to
move drivers over to it.

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Arjan van de Ven]

On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote:
> On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote:
> > I don't think you did get a rejection, a few people said that _they_
> > weren't going to do it, but if you want to then go ahead. I think people
> > are just fed up of people bringing up the issue and then failing to do
> > anything about it -- so prove them wrong ;-)
> 
> Actually patches to add firmware loader support to tg3 got rejected.

I think they will be accepted if they first introduce a transition
period where tg3 will do request_firmware() and only use the built-in
firmware if that fails. Second step is to make the built-in firmware a
config option and then later on when the infrastructure matures for
firmware loading/providing firmware it can be removed from the driver
entirely.

One of the sticking points will be how people get the firmware; I can
see the point of a kernel-distributable-firmware project related to the
kernel (say on kernel.org) which would provide a nice collection of
distributable firmwares (and is appropriately licensed). Without such
joint infrastructure things will always be a mess and in that context I
can see the point of the driver authors not immediately wanting to
switch exclusively. Simply because they'll get swamped with email about
how the driver doesn't work...

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Christoph Hellwig]

On Tue, Apr 05, 2005 at 11:28:07AM +0200, Arjan van de Ven wrote:
> I think they will be accepted if they first introduce a transition
> period where tg3 will do request_firmware() and only use the built-in
> firmware if that fails.

Fine with me.

> Second step is to make the built-in firmware a
> config option and then later on when the infrastructure matures for
> firmware loading/providing firmware it can be removed from the driver
> entirely.

I think the infrasturcture is quite mature.  We have a lot of drivers
that require it to function.

> One of the sticking points will be how people get the firmware; I can
> see the point of a kernel-distributable-firmware project related to the
> kernel (say on kernel.org) which would provide a nice collection of
> distributable firmwares (and is appropriately licensed). Without such
> joint infrastructure things will always be a mess and in that context I
> can see the point of the driver authors not immediately wanting to
> switch exclusively. Simply because they'll get swamped with email about
> how the driver doesn't work...

I agree.  And that really doesn't need a lot of infrastructure,
basically just a tarball that unpacks to /lib/firmware, maybe a specfile
and debian/ dir in addition.

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Arjan van de Ven]

> > Second step is to make the built-in firmware a
> > config option and then later on when the infrastructure matures for
> > firmware loading/providing firmware it can be removed from the driver
> > entirely.
> 
> I think the infrasturcture is quite mature.  We have a lot of drivers
> that require it to function.

what seems to be currently missing is distro level support for using
firmware for modules needed for booting (and tg3 falls sort of under
that via nfsroot) and widespread easy availability of firmware in
distros and for users.

Both are a bit of a chick-and-egg thing, and this is what a transition
period with a few key drivers in dual-mode would hopefully resolve.

One of the options is to even ship the firmware in the kernel tarbal but
from a separate directory with a clear license clarification text in it.

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Christoph Hellwig]

On Tue, Apr 05, 2005 at 11:36:58AM +0200, Arjan van de Ven wrote:
> One of the options is to even ship the firmware in the kernel tarbal but
> from a separate directory with a clear license clarification text in it.

I think that's what we should do.  I currently don't have any firmware
requiring devices, but I'd volunteer to keep such a tarball for now if
no one else wants to do tiny amount of work.

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Andres Salomon]

On Tue, 05 Apr 2005 11:39:02 +0200, Christoph Hellwig wrote:

> On Tue, Apr 05, 2005 at 11:36:58AM +0200, Arjan van de Ven wrote:
>> One of the options is to even ship the firmware in the kernel tarbal but
>> from a separate directory with a clear license clarification text in it.
> 
> I think that's what we should do.  I currently don't have any firmware
> requiring devices, but I'd volunteer to keep such a tarball for now if
> no one else wants to do tiny amount of work.


FYI, I just created this, it might be useful for all this:
http://wiki.debian.net/?KernelFirmwareLicensing

I'm still adding driver information..

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Tue, Apr 05, 2005 at 11:36:58AM +0200, Arjan van de Ven wrote:
> 
> > > Second step is to make the built-in firmware a
> > > config option and then later on when the infrastructure matures for
> > > firmware loading/providing firmware it can be removed from the driver
> > > entirely.
> > 
> > I think the infrasturcture is quite mature.  We have a lot of drivers
> > that require it to function.
> 
> what seems to be currently missing is distro level support for using
> firmware for modules needed for booting (and tg3 falls sort of under
> that via nfsroot) and widespread easy availability of firmware in
> distros and for users.

Well, apart from the installation case, simply using such kernel is easy
enough, if you use an initrd. The mkinitrd script only has to be aware of
this, and include the needed firmware in the initrd, as it does for the
modules. Initial installation will have to either have the possibility to
build custom initrds with the firmware blobs in it, or a way to easily get
those firmware blobs (from CD, floppy, net, ...), or have support for a second
initrd which would contain the firmware. I don't believe there is already
support for a second ramdisk in todays kernel.

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Jeff Garzik]

Christoph Hellwig wrote:
> On Tue, Apr 05, 2005 at 11:28:07AM +0200, Arjan van de Ven wrote:
>>One of the sticking points will be how people get the firmware; I can
>>see the point of a kernel-distributable-firmware project related to the
>>kernel (say on kernel.org) which would provide a nice collection of
>>distributable firmwares (and is appropriately licensed). Without such
>>joint infrastructure things will always be a mess and in that context I
>>can see the point of the driver authors not immediately wanting to
>>switch exclusively. Simply because they'll get swamped with email about
>>how the driver doesn't work...
> 
> 
> I agree.  And that really doesn't need a lot of infrastructure,
> basically just a tarball that unpacks to /lib/firmware, maybe a specfile
> and debian/ dir in addition.


At the moment there is -zero- infrastructure that would allow my tg3 to 
continue working, when I upgrade to a tg3 driver with external firmware.

The user has to put a file in some location manually.

That's a complete non-starter, from a usability standpoint.

Further, several firmwares, including tg3, are really a collection of 
bits of information:  .text, .bss, and random variables (start addr, 
image size, ...).  The current interface is complete crap for this sort 
of setup.

The firmware loader really needs to be loading -archives- not individual 
files.

We are a -long- way from moving the firmware out of the tg3 source code.

	Jeff

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Arjan van de Ven]

> > I agree.  And that really doesn't need a lot of infrastructure,
> > basically just a tarball that unpacks to /lib/firmware, maybe a specfile
> > and debian/ dir in addition.
> 
> 
> At the moment there is -zero- infrastructure that would allow my tg3 to 
> continue working, when I upgrade to a tg3 driver with external firmware.
> 
> The user has to put a file in some location manually.
> 
> That's a complete non-starter, from a usability standpoint.

but unless we allow the driver to use such things, such infrastructure
won't come into existence either. It's a chicken-and-egg situation...
except that we can for a while make tg3 and others be both the chicken
and egg until the real chicken is there.

> Further, several firmwares, including tg3, are really a collection of 
> bits of information:  .text, .bss, and random variables (start addr, 
> image size, ...).  The current interface is complete crap for this sort 
> of setup.
> 
> The firmware loader really needs to be loading -archives- not individual 
> files.
> 
> We are a -long- way from moving the firmware out of the tg3 source code.

Yet that is no excuse to not at least start addressing the issues. What
you just listed are deficiencies in the kernel infrastructure, not doing
something because we have slightly suboptimal infrastructure isn't the
right thing.

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Eric W. Biederman]

Arjan van de Ven <arjan@infradead.org> writes:

> On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote:
> > On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote:
> > > I don't think you did get a rejection, a few people said that _they_
> > > weren't going to do it, but if you want to then go ahead. I think people
> > > are just fed up of people bringing up the issue and then failing to do
> > > anything about it -- so prove them wrong ;-)
> > 
> > Actually patches to add firmware loader support to tg3 got rejected.
> 
> I think they will be accepted if they first introduce a transition
> period where tg3 will do request_firmware() and only use the built-in
> firmware if that fails. Second step is to make the built-in firmware a
> config option and then later on when the infrastructure matures for
> firmware loading/providing firmware it can be removed from the driver
> entirely.

For tg3 a transition period shouldn't be needed as firmware loading
is only needed on old/buggy hardware which is not the common case.
Or to support advanced features which can be disabled.

I am fairly certain in that case the firmware came from the bcm5701 
broadcom driver for the tg3 which I think is gpl'd.   So the firmware
may legitimately be under the GPL.

Eric

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Jeff Garzik]

Eric W. Biederman wrote:
> Arjan van de Ven <arjan@infradead.org> writes:
> 
> 
>>On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote:
>>
>>>On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote:
>>>
>>>>I don't think you did get a rejection, a few people said that _they_
>>>>weren't going to do it, but if you want to then go ahead. I think people
>>>>are just fed up of people bringing up the issue and then failing to do
>>>>anything about it -- so prove them wrong ;-)
>>>
>>>Actually patches to add firmware loader support to tg3 got rejected.
>>
>>I think they will be accepted if they first introduce a transition
>>period where tg3 will do request_firmware() and only use the built-in
>>firmware if that fails. Second step is to make the built-in firmware a
>>config option and then later on when the infrastructure matures for
>>firmware loading/providing firmware it can be removed from the driver
>>entirely.
> 
> 
> For tg3 a transition period shouldn't be needed as firmware loading
> is only needed on old/buggy hardware which is not the common case.
> Or to support advanced features which can be disabled.

TSO firmware is commonly used these days.


> I am fairly certain in that case the firmware came from the bcm5701 
> broadcom driver for the tg3 which I think is gpl'd.   So the firmware
> may legitimately be under the GPL.

It is.

	Jeff

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Christoph Hellwig]

On Thu, Apr 07, 2005 at 05:34:56AM -0400, Jeff Garzik wrote:
> >For tg3 a transition period shouldn't be needed as firmware loading
> >is only needed on old/buggy hardware which is not the common case.
> >Or to support advanced features which can be disabled.
> 
> TSO firmware is commonly used these days.

Because our TSO support has been totally broken for a long time?

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Wed, Apr 06, 2005 at 01:22:36PM -0600, Eric W. Biederman wrote:
> Arjan van de Ven <arjan@infradead.org> writes:
> 
> > On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote:
> > > On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote:
> > > > I don't think you did get a rejection, a few people said that _they_
> > > > weren't going to do it, but if you want to then go ahead. I think people
> > > > are just fed up of people bringing up the issue and then failing to do
> > > > anything about it -- so prove them wrong ;-)
> > > 
> > > Actually patches to add firmware loader support to tg3 got rejected.
> > 
> > I think they will be accepted if they first introduce a transition
> > period where tg3 will do request_firmware() and only use the built-in
> > firmware if that fails. Second step is to make the built-in firmware a
> > config option and then later on when the infrastructure matures for
> > firmware loading/providing firmware it can be removed from the driver
> > entirely.
> 
> For tg3 a transition period shouldn't be needed as firmware loading
> is only needed on old/buggy hardware which is not the common case.
> Or to support advanced features which can be disabled.
> 
> I am fairly certain in that case the firmware came from the bcm5701 
> broadcom driver for the tg3 which I think is gpl'd.   So the firmware
> may legitimately be under the GPL.

So, where is the source for it ? 

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Eric W. Biederman]

Sven Luther <sven.luther@wanadoo.fr> writes:

> On Wed, Apr 06, 2005 at 01:22:36PM -0600, Eric W. Biederman wrote:
> > For tg3 a transition period shouldn't be needed as firmware loading
> > is only needed on old/buggy hardware which is not the common case.
> > Or to support advanced features which can be disabled.
> > 
> > I am fairly certain in that case the firmware came from the bcm5701 
> > broadcom driver for the tg3 which I think is gpl'd.   So the firmware
> > may legitimately be under the GPL.
> 
> So, where is the source for it ? 

The GPL'd driver that broadcom distributes.  The history of tg3.c
is that broadcom's bcm57xx driver drove the hardware correctly but
not linux so it was rewritten from scratch. 

Beyond that you need to talk to Broadcom.  But if the originator
of the bits  distributes them gpl from a redistribution point the
kernel is fine.  

It sounds like you are now looking at the question of are the
huge string of hex characters the preferred form for making
modifications to firmware.  Personally I would be surprised
but those hunks are small enough it could have been written
in machine code.

So I currently have no reason to believe that anything has been
done improperly with that code.

Eric

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Thu, Apr 07, 2005 at 05:46:27AM -0600, Eric W. Biederman wrote:
> Sven Luther <sven.luther@wanadoo.fr> writes:
> 
> > On Wed, Apr 06, 2005 at 01:22:36PM -0600, Eric W. Biederman wrote:
> > > For tg3 a transition period shouldn't be needed as firmware loading
> > > is only needed on old/buggy hardware which is not the common case.
> > > Or to support advanced features which can be disabled.
> > > 
> > > I am fairly certain in that case the firmware came from the bcm5701 
> > > broadcom driver for the tg3 which I think is gpl'd.   So the firmware
> > > may legitimately be under the GPL.
> > 
> > So, where is the source for it ? 
> 
> The GPL'd driver that broadcom distributes.  The history of tg3.c
> is that broadcom's bcm57xx driver drove the hardware correctly but
> not linux so it was rewritten from scratch. 

Ok, thanks for that clarification.

> Beyond that you need to talk to Broadcom.  But if the originator
> of the bits  distributes them gpl from a redistribution point the
> kernel is fine.  

As you may know, i have contacted Broadcom about this issue, the information
passed from the driver support contact to their linux developers, but i have
not heard from them yet.

> It sounds like you are now looking at the question of are the
> huge string of hex characters the preferred form for making
> modifications to firmware.  Personally I would be surprised
> but those hunks are small enough it could have been written
> in machine code.

Yep, i also think it is in broadcom's best interest to modify the licencing
text accordyingly, since i suppose someone could technicaly come after them
legally to obtain said source code to this firmware. Unprobable though.

> So I currently have no reason to believe that anything has been
> done improperly with that code.

Well, it all depends if you consider this firmware blob as software, which i
feel it is without doubt, or we have not the same definition of software,
i.e., the program which runs on the hardware, or not. We cannot claim this is data,
since there should be at least some kind of executable code in it,
independenlty of the fact that we claim that data is also software.

Thanks for the info, i will add it to the Wiki.

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Eric W. Biederman]

Sven Luther <sven.luther@wanadoo.fr> writes:

> > It sounds like you are now looking at the question of are the
> > huge string of hex characters the preferred form for making
> > modifications to firmware.  Personally I would be surprised
> > but those hunks are small enough it could have been written
> > in machine code.
> 
> Yep, i also think it is in broadcom's best interest to modify the licencing
> text accordyingly, since i suppose someone could technicaly come after them
> legally to obtain said source code to this firmware. Unprobable though.

Possibly.  It sounds like that is what you want to do.
 
> > So I currently have no reason to believe that anything has been
> > done improperly with that code.
> 
> Well, it all depends if you consider this firmware blob as software, which i
> feel it is without doubt, or we have not the same definition of software,
> i.e., the program which runs on the hardware, or not. We cannot claim this is
> data,
> 
> since there should be at least some kind of executable code in it,
> independenlty of the fact that we claim that data is also software.

Do you have any evidence that ``software'' was not written directly in
machine code?   Software is written directly in machine code when a programmer
looks at the instruction set and writes down the binary representation
of the instructions.  I know ISC dhcpd has packet filter code that was written
in that manner, so it is not a lost art.   And it is done often enough when
an assembler will not cooperate, and generate the correct instruction.

Without evidence that we don't have the preferred form of the software
for making modifications I don't see how you can complain.

Eric

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Thu, Apr 07, 2005 at 09:06:58PM -0600, Eric W. Biederman wrote:
> Sven Luther <sven.luther@wanadoo.fr> writes:
> 
> > > It sounds like you are now looking at the question of are the
> > > huge string of hex characters the preferred form for making
> > > modifications to firmware.  Personally I would be surprised
> > > but those hunks are small enough it could have been written
> > > in machine code.
> > 
> > Yep, i also think it is in broadcom's best interest to modify the licencing
> > text accordyingly, since i suppose someone could technicaly come after them
> > legally to obtain said source code to this firmware. Unprobable though.
> 
> Possibly.  It sounds like that is what you want to do.

No, i am making them aware of the possibility, and hoping they fix the issue,
but we will see. If they fail to act on this, i don't understand why though,
since it is just addition of a clarification. It is not as if i am asking for
the release of all their chip specs or something such.

> > since there should be at least some kind of executable code in it,
> > independenlty of the fact that we claim that data is also software.
> 
> Do you have any evidence that ``software'' was not written directly in
> machine code?   Software is written directly in machine code when a programmer

So what, i seriously doubt they where written using an vi in C, as the code
currently stands, so we do need an additional level of source code, being it
only some asm code or something.

> looks at the instruction set and writes down the binary representation
> of the instructions.  I know ISC dhcpd has packet filter code that was written
> in that manner, so it is not a lost art.   And it is done often enough when
> an assembler will not cooperate, and generate the correct instruction.

But again, this is not the common assumption, so if this is so, they should
write it down black on white in the copyright notice, and everyone would be
happy.

> Without evidence that we don't have the preferred form of the software
> for making modifications I don't see how you can complain.

No, it goes the other way around. Without evidence that all is clean, we have
no right to distribute that code, and if what you describe was the case, a
couple of lines telling us that fact would solve the issue, and not even need
the involvement of their legal department. I would be somewhat suspisious
though if all these guys came up and said they just wrote said firmware in
binary directly though.

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Ian Campbell]

On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote:
> On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote:
> > I don't think you did get a rejection, a few people said that _they_
> > weren't going to do it, but if you want to then go ahead. I think people
> > are just fed up of people bringing up the issue and then failing to do
> > anything about it -- so prove them wrong ;-)
> 
> Actually patches to add firmware loader support to tg3 got rejected.
> 
> Which is think is very unfortunately as we set the highlevel goal to
> move drivers over to it.

I didn't know that -- you are right that it is unfortunate.

I thought Sven was talking (at least short term) about adding copyright
statements/exemptions/something to the binary blobs where they are now.

Ian.
-- 
Ian Campbell

It's easier to get forgiveness for being wrong than forgiveness for being 
right.

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Tue, Apr 05, 2005 at 10:30:47AM +0100, Ian Campbell wrote:
> On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote:
> > On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote:
> > > I don't think you did get a rejection, a few people said that _they_
> > > weren't going to do it, but if you want to then go ahead. I think people
> > > are just fed up of people bringing up the issue and then failing to do
> > > anything about it -- so prove them wrong ;-)
> > 
> > Actually patches to add firmware loader support to tg3 got rejected.
> > 
> > Which is think is very unfortunately as we set the highlevel goal to
> > move drivers over to it.
> 
> I didn't know that -- you are right that it is unfortunate.
> 
> I thought Sven was talking (at least short term) about adding copyright
> statements/exemptions/something to the binary blobs where they are now.

Yes, indeed, i am searching for a short-time clarification, but in the long
term the separate firmware solution is indeed better, altough more work and
more involved.

That said, the work to identify the firmware blobs and clarify their
copyright/licencing situation is common for both alternatives.

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Tue, Apr 05, 2005 at 09:19:24AM +0100, Ian Campbell wrote:
> On Mon, 2005-04-04 at 23:19 +0200, Sven Luther wrote:
> 
> > I am only saying that the tg3.c and other file are under the GPL, and
> > that the firmware included in it is *NOT* intented to be under the
> > GPL, so why not say it explicitly ? 
> 
> I don't think anyone here has disagreed. What almost everyone has said
> however is "so go and do it" -- go do the research, contact the
> copyright holders directly and get the permission to make patches, then
> post them here.
> 
> There is really no point in discussing it here, just get on and do it.

Ok, for info, here is the email i just sent to the boradcom driver support :

---

Hello,

I am part of the Debian GNU/Linux kernel team, and recently stumbled about
some legal problems with the tg3.c driver for broadcom gigabit ethernet
controllers. The problem seems to be the same for the bcm570x drivers you
distribute from your web page, and after discussion with the debian-legal
team [1] and airing the issue with the larger linux kernel developers [2],
i now come to you for clarfication of this issue.

The broadcom 570x drivers are placed under the GPL, which is nice, and come
accompanied by sources, but include a few blobs of binary-only firmware to be
uploaded to the controller.

After discussion with debian-legal, we accept that the binary-only firmware
blob does not constitute a derivative work of the rest of the driver, but mere
agregation, so distributing it as binary only as you do is not a problem,
altough getting real sources for this part would be preferable.

Now, the problem is that both in the files included in the mainline kernel, as
well as the sources you distribute yourself, these firmware blobs come in a
file like fw_lso05.h, whose licence text says : 

/******************************************************************************/
/*                                                                            */
/* Broadcom BCM5700 Linux Network Driver, Copyright (c) 2000 - 2003 Broadcom  */
/* Corporation.                                                               */
/* All rights reserved.                                                       */
/*                                                                            */
/* This program is free software; you can redistribute it and/or modify       */
/* it under the terms of the GNU General Public License as published by       */
/* the Free Software Foundation, located in the file LICENSE.                 */
/*                                                                            */
/* (c) COPYRIGHT 2001-2004 Broadcom Corporation, ALL RIGHTS RESERVED.         */
/*                                                                            */
/*  Name: F W _ L S O 0 5. H                                                  */
/*  Author : Kevin Tran                                                       */
/*  Version: 1.2                                                              */
/*                                                                            */
/* Module Description:  This file contains firmware binary code of TCP        */
/* Segmentation firmware (BCM5705).                                           */
/*                                                                            */
/* History:                                                                   */
/*    08/10/02 Kevin Tran       Incarnation.                                  */
/*    02/02/04 Kevin Tran       Added Support for BCM5788.                    */
/******************************************************************************/

The above copyright statement clearly places the firmware blob under the GPL,
and makes the whole file undistributable without providing also the source
code, that is the prefered form of modification, of the firmware code in
question.

There are two solutions to this issue, either you abide by the GPL and provide
also the source code of those firmware binaries (the prefered solution :), or
you modify the copyright statement of these files, to indicate that even
thought the file per se is under the GPL, the firmware binary code is not, and
give us a licence to distribute it. Something akin to :

/******************************************************************************/
/*                                                                            */
/* Broadcom BCM5700 Linux Network Driver, Copyright (c) 2000 - 2003 Broadcom  */
/* Corporation.                                                               */
/* All rights reserved.                                                       */
/*                                                                            */
/* This program, except the firmware binary code,  is free software; you can  */
/* redistribute it and/or modify it under the terms of the GNU General Public */
/* License as published by the Free Software Foundation, located in the file  */
/* LICENSE.                                                                   */
/* Distribution, either as is or modified syntactically to adapt to the       */
/* layout of the surrounding GPLed code is allowed, provided this copyright   */
/* notice is acompanying it                                                   */
/*                                                                            */
/* (c) COPYRIGHT 2001-2004 Broadcom Corporation, ALL RIGHTS RESERVED.         */
/*                                                                            */
/*  Name: F W _ L S O 0 5. H                                                  */
/*  Author : Kevin Tran                                                       */
/*  Version: 1.2                                                              */
/*                                                                            */
/* Module Description:  This file contains firmware binary code of TCP        */
/* Segmentation firmware (BCM5705).                                           */
/*                                                                            */
/* History:                                                                   */
/*    08/10/02 Kevin Tran       Incarnation.                                  */
/*    02/02/04 Kevin Tran       Added Support for BCM5788.                    */
/******************************************************************************/

Or something else such acceptable to your legal department.

In hope of hearing from you soon, and that a quick resolution of this problem
can be achieved,

Friendly,

Sven Luther

[1] -- http://lists.debian.org/debian-legal/2005/03/msg00283.html
[2] -- http://lists.debian.org/debian-legal/2005/04/msg00047.html

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Don Armstrong]

[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]

[MFT set to -legal, as this is becoming legal arcana probably not
particularly interesting to any other list.]

On Tue, 05 Apr 2005, Sven Luther wrote:
> There are two solutions to this issue, either you abide by the GPL
> and provide also the source code of those firmware binaries (the
> prefered solution :), or you modify the copyright statement of these
> files, to indicate that even thought the file per se is under the
> GPL, the firmware binary code is not, and give us a licence to
> distribute it. Something akin to :
> 
> /* This program, except the firmware binary code,  is free software; you can  */
> /* redistribute it and/or modify it under the terms of the GNU General Public */
> /* License as published by the Free Software Foundation, located in the file  */
> /* LICENSE.                                                                   */
> /* Distribution, either as is or modified syntactically to adapt to the       */
> /* layout of the surrounding GPLed code is allowed, provided this copyright   */
> /* notice is acompanying it                                                   */

Just a word of warning: The wording above fails to make it clear what
the second clause is applying to. Additionally it has the following
restrictions that are probably not intended:

   1) Does not specifically allow this firware to be sold as part of an
      aggregate

   2) The range of modifications allowed is rather vague, and implies
      that the firmware can't be extracted

I'd instead suggest applying a pre-existing license like MIT[1] to the
firmware portion of the code file, rather than inventing your own
licensing text that only partially deals with the problem(s) at issue.
(Inventing licensing text is quite often very hazardous to your
health.)


Don Armstrong

1: http://www.opensource.org/licenses/mit-license.php
-- 
Build a fire for a man, an he'll be warm for a day.  Set a man on   
fire, and he'll be warm for the rest of his life.
 -- Jules Bean

http://www.donarmstrong.com              http://rzlab.ucr.edu

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[PATCH 00/04] Load keyspan firmware with hotplug

[Jan Harkes]

On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > 
> >   http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > 
> > Can you summarize the conclusion of the thread, or what you did get from it,
> > please ? 
> 
> That people didn't like the inclusion of firmware, I posted how you can
> fix it by moving it outside of the kernel, and asked for patches.
> 
> None have come.

Didn't know you were waiting for it. How about something like the
following series of patches?

[01/04] - add simple Intel IHEX format parser to the firmware loader.
[02/04] - make the keyspan driver use request_firmware.
[03/04] - converter program used to dump the keyspan headers as IHex files.
[04/04] - result of running the previous program.

This ofcourse doesn't actually solve Debian's distribution issues since
the keyspan firmware can only be distributed as part of 'Linux or other
Open Source operating system kernel'.

> So I refuse to listen to talk about this, as obviously, no one cares
> enough about this to actually fix the issue.

I got tired of always building my own kernels on Debian just to get my
serial dongle to work since their included keyspan.ko driver is so
useless that it isn't even worth having. The only way to use it with a
Debian kernel is to have the dongle in a powered hub and first boot into
Windows or a normal kernel.org kernel to get the thing initialized.
Didn't send the patch earlier since I wanted to split off the
pre-numeration part of the driver so that after intialization we can
unload the unused parts of the driver as well as the the firmware class
module.

Jan

[PATCH 01/04] Load keyspan firmware with hotplug

[Jan Harkes]

Adding firmware_load_ihex, to load IHEX formatted firmware images.

Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>


 drivers/base/firmware_class.c |  151 ++++++++++++++++++++++++++++++++++++++++++
 include/linux/firmware.h      |   26 +++++++
 2 files changed, 177 insertions(+)

Index: linux/include/linux/firmware.h
===================================================================
--- linux.orig/include/linux/firmware.h	2005-03-29 16:32:45.000000000 -0500
+++ linux/include/linux/firmware.h	2005-03-29 16:33:11.000000000 -0500
@@ -1,12 +1,34 @@
+/*
+ * Definitions for hotplug firmware loader
+ *
+ * Copyright (C) 2003 Manuel Estrada Sainz <ranty@debian.org>
+ *
+ *	This program is free software; you can redistribute it and/or
+ *	modify it under the terms of the GNU General Public License version
+ *	2 as published by the Free Software Foundation.
+ *
+ * 2005-03-10  Jan Harkes <jaharkes@cs.cmu.edu>
+ *	Added parser for IHEX formatted firmware files.
+ */
+
 #ifndef _LINUX_FIRMWARE_H
 #define _LINUX_FIRMWARE_H
+
 #include <linux/module.h>
 #include <linux/types.h>
 #define FIRMWARE_NAME_MAX 30 
+
 struct firmware {
 	size_t size;
 	u8 *data;
 };
+
+struct ihex_record {
+	__u32 address;
+	__u8  len;
+	__u8  data[255];
+};
+
 struct device;
 int request_firmware(const struct firmware **fw, const char *name,
 		     struct device *device);
@@ -15,6 +37,10 @@ int request_firmware_nowait(
 	const char *name, struct device *device, void *context,
 	void (*cont)(const struct firmware *fw, void *context));
 
+int firmware_load_ihex(const struct firmware *fw, void *context,
+		       int (*load)(struct ihex_record *record, void *context));
+
 void release_firmware(const struct firmware *fw);
 void register_firmware(const char *name, const u8 *data, size_t size);
+
 #endif
Index: linux/drivers/base/firmware_class.c
===================================================================
--- linux.orig/drivers/base/firmware_class.c	2005-03-29 16:32:45.000000000 -0500
+++ linux/drivers/base/firmware_class.c	2005-03-29 16:33:11.000000000 -0500
@@ -5,6 +5,8 @@
  *
  * Please see Documentation/firmware_class/ for more information.
  *
+ * 2005-03-10 Jan Harkes <jaharkes@cs.cmu.edu>
+ *	Added parser for IHEX formatted firmware files.
  */
 
 #include <linux/device.h>
@@ -553,6 +555,153 @@ request_firmware_nowait(
 	return 0;
 }
 
+#ifdef VERBOSE_MSGS
+#define dbg(msg, ...) printk(KERN_WARNING "%s: line %d: " msg, __FUNCTION__, line, ## __VA_ARGS__)
+#else
+#define dbg(msg, ...) do {} while(0)
+#endif
+
+/**
+ * nibble/hex are little helpers to parse hexadecimal numbers to a byte value
+ **/
+static __u8 nibble(__u8 n)
+{
+	if      (n >= '0' && n <= '9') return n - '0';
+	else if (n >= 'A' && n <= 'F') return n - ('A' - 10);
+	else if (n >= 'a' && n <= 'f') return n - ('a' - 10);
+	return 0;
+}
+static __u8 hex(__u8 *data, __u8 *crc)
+{
+	__u8 val = (nibble(data[0]) << 4) | nibble(data[1]);
+	*crc += val;
+	return val;
+}
+
+/**
+ * firmware_load_ihex:
+ *
+ * Description:
+ *	@fw is expected to contain Intel HEX formatted data.
+ *
+ *	@load will be called for each record that is found in the IHEX data.
+ *
+ *	@context will be passed on to @load.
+ *
+ **/
+int firmware_load_ihex(const struct firmware *fw, void *context,
+		       int (*load)(struct ihex_record *record, void *context))
+{
+	struct ihex_record *record;
+	__u32 offset = 0;
+	__u8 type, crc = 0;
+	int i, j, err = 0;
+	int line = 1;
+
+	record = kmalloc(sizeof(*record), GFP_KERNEL);
+	if (!record) {
+	    dbg("Allocation failed\n");
+	    return -ENOMEM;
+	}
+
+	i = 0;
+next_record:
+	/* search for the start of record character */
+	while (i < fw->size) {
+		if (fw->data[i] == '\n') line++;
+		if (fw->data[i++] == ':') break;
+	}
+
+	/* Minimum record length would be about 10 characters */
+	if (i + 10 > fw->size) {
+		dbg("Can't find valid record\n");
+		err = -EINVAL;
+		goto done;
+	}
+
+	record->len = hex(fw->data + i, &crc);
+	i += 2;
+
+	/* now check if we have enough data to read everything */
+	if (i + 8 + (record->len * 2) > fw->size) {
+		dbg("Not enough data to read complete record\n");
+		err = -EINVAL;
+		goto done;
+	}
+
+	record->address  = hex(fw->data + i, &crc) << 8; i += 2;
+	record->address |= hex(fw->data + i, &crc); i += 2;
+	record->address += offset;
+	type = hex(fw->data + i, &crc); i += 2;
+
+	for (j = 0; j < record->len; j++, i += 2)
+		record->data[j] = hex(fw->data + i, &crc);
+
+	/* check CRC */
+	(void)hex(fw->data + i, &crc); i += 2;
+	if (crc != 0) {
+		dbg("CRC failure\n");
+		err = -EINVAL;
+		goto done;
+	}
+
+	/* Done reading the record */
+	switch (type) {
+	case 0:
+		/* old style EOF record? */
+		if (!record->len)
+			break;
+
+		err = load(record, context);
+		if (err < 0) {
+			dbg("Firmware load failed (err %d)\n", err);
+			break;
+		}
+		goto next_record;
+
+	case 1: /* End-Of-File Record */
+		if (record->address || record->len) {
+		    dbg("Bad EOF record (type 01) format\n");
+		    err = -EINVAL;
+		}
+		break;
+
+	case 2: /* Extended Segment Address Record (HEX86) */
+	case 4: /* Extended Linear Address Record (HEX386) */
+		if (record->address || record->len != 2) {
+			dbg("Bad HEX86/HEX386 record (type %02X)\n", type);
+			err = -EINVAL;
+			break;
+		}
+
+		/* We shouldn't really be using the offset for HEX86 because
+		 * the wraparound case is specified quite differently. */
+		offset = record->data[0] << 8 | record->data[1];
+		offset <<= (type == 2 ? 4 : 16);
+		goto next_record;
+
+	case 3: /* Start Segment Address Record */
+	case 5: /* Start Linear Address Record */
+		if (record->address || record->len != 4) {
+			dbg("Bad Start Address record (type %02X)\n", type);
+			err = -EINVAL;
+			break;
+		}
+
+		/* These records contain the CS/IP or EIP where execution
+		 * starts. Don't really know what to do with them. */
+		goto next_record;
+
+	default:
+		dbg("Unknown record (type %02X)\n", type);
+		err = -EINVAL;
+		break; /* unknown record type */
+	}
+done:
+	kfree(record);
+	return err;
+}
+
 static int __init
 firmware_class_init(void)
 {
@@ -584,3 +733,5 @@ EXPORT_SYMBOL(release_firmware);
 EXPORT_SYMBOL(request_firmware);
 EXPORT_SYMBOL(request_firmware_nowait);
 EXPORT_SYMBOL(register_firmware);
+EXPORT_SYMBOL(firmware_load_ihex);
+

[PATCH 02/04] Load keyspan firmware with hotplug

[Jan Harkes]

Convert the keyspan USB serial driver to use request_firmware and
firmware_load_ihex.

Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>

Index: linux/drivers/usb/serial/keyspan.c
===================================================================
--- linux.orig/drivers/usb/serial/keyspan.c	2005-03-10 16:01:15.000000000 -0500
+++ linux/drivers/usb/serial/keyspan.c	2005-03-10 23:07:21.070790916 -0500
@@ -28,6 +28,9 @@
 
   Change History
 
+    2005mar10	Jan Harkes
+      Use generic request_firmware/firmware_load_ihex functions.
+
     2003sep04	LPM (Keyspan) add support for new single port product USA19HS.
 				Improve setup message handling for all devices.
 
@@ -106,6 +109,7 @@
 #include <linux/tty_flip.h>
 #include <linux/module.h>
 #include <linux/spinlock.h>
+#include <linux/firmware.h>
 #include <asm/uaccess.h>
 #include <linux/usb.h>
 #include "usb-serial.h"
@@ -1165,13 +1169,28 @@
 	port->tty = NULL;
 }
 
+static int keyspan_fw_load(struct ihex_record *record, void *arg)
+{
+	struct usb_serial *serial = (struct usb_serial *)arg;
+	int ret;
+
+	ret = ezusb_writememory(serial, record->address, record->data,
+				record->len, 0xa0);
+	if (ret < 0) {
+		dev_err(&serial->dev->dev,
+			"ezusb_writememory failed for Keyspan"
+			"firmware (%d %08X %p %d)\n",
+			ret, record->address, record->data, record->len);
+	}
+	return ret;
+}
 
 	/* download the firmware to a pre-renumeration device */
 static int keyspan_fake_startup (struct usb_serial *serial)
 {
 	int 				response;
-	const struct ezusb_hex_record 	*record;
-	char				*fw_name;
+	char				*model, fw_name[20];
+	const struct firmware		*fw;
 
 	dbg("Keyspan startup version %04x product %04x",
 	    le16_to_cpu(serial->dev->descriptor.bcdDevice),
@@ -1182,97 +1201,43 @@
 		return(1);
 	}
 
-		/* Select firmware image on the basis of idProduct */
 	switch (le16_to_cpu(serial->dev->descriptor.idProduct)) {
-	case keyspan_usa28_pre_product_id:
-		record = &keyspan_usa28_firmware[0];
-		fw_name = "USA28";
-		break;
-
-	case keyspan_usa28x_pre_product_id:
-		record = &keyspan_usa28x_firmware[0];
-		fw_name = "USA28X";
-		break;
-
-	case keyspan_usa28xa_pre_product_id:
-		record = &keyspan_usa28xa_firmware[0];
-		fw_name = "USA28XA";
-		break;
-
-	case keyspan_usa28xb_pre_product_id:
-		record = &keyspan_usa28xb_firmware[0];
-		fw_name = "USA28XB";
-		break;
-
-	case keyspan_usa19_pre_product_id:
-		record = &keyspan_usa19_firmware[0];
-		fw_name = "USA19";
-		break;
-			     
-	case keyspan_usa19qi_pre_product_id:
-		record = &keyspan_usa19qi_firmware[0];
-		fw_name = "USA19QI";
-		break;
-			     
-	case keyspan_mpr_pre_product_id:
-		record = &keyspan_mpr_firmware[0];
-		fw_name = "MPR";
-		break;
-
-	case keyspan_usa19qw_pre_product_id:
-		record = &keyspan_usa19qw_firmware[0];
-		fw_name = "USA19QI";
-		break;
-			     
-	case keyspan_usa18x_pre_product_id:
-		record = &keyspan_usa18x_firmware[0];
-		fw_name = "USA18X";
-		break;
-			     
-	case keyspan_usa19w_pre_product_id:
-		record = &keyspan_usa19w_firmware[0];
-		fw_name = "USA19W";
-		break;
-		
-	case keyspan_usa49w_pre_product_id:
-		record = &keyspan_usa49w_firmware[0];
-		fw_name = "USA49W";
-		break;
-
-	case keyspan_usa49wlc_pre_product_id:
-		record = &keyspan_usa49wlc_firmware[0];
-		fw_name = "USA49WLC";
-		break;
-
+	case keyspan_usa18x_pre_product_id:   model = "usa18x";   break;
+	case keyspan_usa19_pre_product_id:    model = "usa19";    break;
+	case keyspan_usa19qi_pre_product_id:  model = "usa19qi";  break;
+	case keyspan_mpr_pre_product_id:      model = "mpr";      break;
+	case keyspan_usa19qw_pre_product_id:  model = "usa19qw";  break;
+	case keyspan_usa19w_pre_product_id:   model = "usa19w";   break;
+	case keyspan_usa28_pre_product_id:    model = "usa28";    break;
+	case keyspan_usa28x_pre_product_id:   model = "usa28x";   break;
+	case keyspan_usa28xa_pre_product_id:  model = "usa28xa";  break;
+	case keyspan_usa28xb_pre_product_id:  model = "usa28xb";  break;
+	case keyspan_usa49w_pre_product_id:   model = "usa49w";   break;
+	case keyspan_usa49wlc_pre_product_id: model = "usa49wlc"; break;
 	default:
-		record = NULL;
-		fw_name = "Unknown";
-		break;
+		dev_err(&serial->dev->dev, "Unknown keyspan device (%04x).\n",
+			le16_to_cpu(serial->dev->descriptor.idProduct));
+		return(1);
 	}
 
-	if (record == NULL) {
-		dev_err(&serial->dev->dev, "Required keyspan firmware image (%s) unavailable.\n", fw_name);
+	sprintf(fw_name, "keyspan-%s.fw", model);
+
+	if (request_firmware(&fw, fw_name, &serial->dev->dev) != 0) {
+		dev_err(&serial->dev->dev, "Required firmware image (%s) unavailable.\n", fw_name);
 		return(1);
 	}
 
-	dbg("Uploading Keyspan %s firmware.", fw_name);
+	dbg("Uploading Keyspan %s firmware.", model);
 
 		/* download the firmware image */
 	response = ezusb_set_reset(serial, 1);
 
-	while(record->address != 0xffff) {
-		response = ezusb_writememory(serial, record->address,
-					     (unsigned char *)record->data,
-					     record->data_size, 0xa0);
-		if (response < 0) {
-			dev_err(&serial->dev->dev, "ezusb_writememory failed for Keyspan"
-				"firmware (%d %04X %p %d)\n",
-				response, 
-				record->address, record->data, record->data_size);
-			break;
-		}
-		record++;
-	}
+	if (firmware_load_ihex(fw, serial, keyspan_fw_load))
+		dev_err(&serial->dev->dev, "Firmware %s upload failed\n",
+			fw_name);
+
+	release_firmware(fw);
+
 		/* bring device out of reset. Renumeration will occur in a
 		   moment and the new device will bind to the real driver */
 	response = ezusb_set_reset(serial, 0);
@@ -1418,7 +1383,7 @@
 			(serial, d_details->outcont_endpoints[i], USB_DIR_OUT,
 			 port, p_priv->outcont_buffer, 64,
 			 cback->outcont_callback);
-	}	
+	}
 
 }
 
Index: linux/drivers/usb/serial/keyspan.h
===================================================================
--- linux.orig/drivers/usb/serial/keyspan.h	2005-03-10 15:59:58.000000000 -0500
+++ linux/drivers/usb/serial/keyspan.h	2005-03-10 22:56:15.343354346 -0500
@@ -99,90 +99,6 @@
 					 struct usb_serial_port *port,
 					 int reset_port);
 
-/* Struct used for firmware - increased size of data section
-   to allow Keyspan's 'C' firmware struct to be used unmodified */
-struct ezusb_hex_record {
-	__u16 address;
-	__u8 data_size;
-	__u8 data[64];
-};
-
-/* Conditionally include firmware images, if they aren't
-   included create a null pointer instead.  Current 
-   firmware images aren't optimised to remove duplicate
-   addresses in the image itself. */
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA28
-	#include "keyspan_usa28_fw.h"
-#else
-	static const struct ezusb_hex_record *keyspan_usa28_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA28X
-	#include "keyspan_usa28x_fw.h"
-#else
-	static const struct ezusb_hex_record *keyspan_usa28x_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA28XA
-	#include "keyspan_usa28xa_fw.h"
-#else
-	static const struct ezusb_hex_record *keyspan_usa28xa_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA28XB
-	#include "keyspan_usa28xb_fw.h"
-#else
-	static const struct ezusb_hex_record *keyspan_usa28xb_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA19
-	#include "keyspan_usa19_fw.h"
-#else
-	static const struct ezusb_hex_record *keyspan_usa19_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA19QI
-	#include "keyspan_usa19qi_fw.h"
-#else
-	static const struct ezusb_hex_record *keyspan_usa19qi_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_MPR
-        #include "keyspan_mpr_fw.h"
-#else
-	static const struct ezusb_hex_record *keyspan_mpr_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA19QW
-	#include "keyspan_usa19qw_fw.h"
-#else
-	static const struct ezusb_hex_record *keyspan_usa19qw_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA18X
-	#include "keyspan_usa18x_fw.h"
-#else
-	static const struct ezusb_hex_record *keyspan_usa18x_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA19W
-	#include "keyspan_usa19w_fw.h"
-#else
-	static const struct ezusb_hex_record *keyspan_usa19w_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA49W
-	#include "keyspan_usa49w_fw.h"
-#else
-	static const struct ezusb_hex_record *keyspan_usa49w_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA49WLC
-        #include "keyspan_usa49wlc_fw.h"
-#else
-	static const struct ezusb_hex_record *keyspan_usa49wlc_firmware = NULL;
-#endif
-
 /* Values used for baud rate calculation - device specific */
 #define	KEYSPAN_INVALID_BAUD_RATE		(-1)
 #define	KEYSPAN_BAUD_RATE_OK			(0)
Index: linux/drivers/usb/serial/Kconfig
===================================================================
--- linux.orig/drivers/usb/serial/Kconfig	2005-03-10 16:01:14.000000000 -0500
+++ linux/drivers/usb/serial/Kconfig	2005-03-10 16:18:19.000000000 -0500
@@ -242,92 +242,21 @@
 	---help---
 	  Say Y here if you want to use Keyspan USB to serial converter
 	  devices.  This driver makes use of Keyspan's official firmware
-	  and was developed with their support.  You must also include
-	  firmware to support your particular device(s).
+	  and was developed with their support.  It uses hotplug to load
+	  the required firmware from /usr/lib/hotplug/firmware or
+	  /lib/firmware.
+	  
+	  However there really isn't a good way to get this firmware
+	  since the license only allows it to be distributed as part of
+	  a Linux or other Open Source operating system kernel.  So you
+	  will have to copy the firmware files from the kernel source
+	  tree (drivers/usb/serial/*.fw) to /lib/firmware yourself.
 
 	  See <http://misc.nu/hugh/keyspan.html> for more information.
 
 	  To compile this driver as a module, choose M here: the
 	  module will be called keyspan.
 
-config USB_SERIAL_KEYSPAN_MPR
-	bool "USB Keyspan MPR Firmware"
-	depends on USB_SERIAL_KEYSPAN
-	help
-	  Say Y here to include firmware for the Keyspan MPR converter.
-
-config USB_SERIAL_KEYSPAN_USA28
-	bool "USB Keyspan USA-28 Firmware"
-	depends on USB_SERIAL_KEYSPAN
-	help
-	  Say Y here to include firmware for the USA-28 converter.
-
-config USB_SERIAL_KEYSPAN_USA28X
-	bool "USB Keyspan USA-28X Firmware"
-	depends on USB_SERIAL_KEYSPAN
-	help
-	  Say Y here to include firmware for the USA-28X converter.
-	  Be sure you have a USA-28X, there are also 28XA and 28XB
-	  models, the label underneath has the actual part number.
-
-config USB_SERIAL_KEYSPAN_USA28XA
-	bool "USB Keyspan USA-28XA Firmware"
-	depends on USB_SERIAL_KEYSPAN
-	help
-	  Say Y here to include firmware for the USA-28XA converter.
-	  Be sure you have a USA-28XA, there are also 28X and 28XB
-	  models, the label underneath has the actual part number.
-
-config USB_SERIAL_KEYSPAN_USA28XB
-	bool "USB Keyspan USA-28XB Firmware"
-	depends on USB_SERIAL_KEYSPAN
-	help
-	  Say Y here to include firmware for the USA-28XB converter.
-	  Be sure you have a USA-28XB, there are also 28X and 28XA
-	  models, the label underneath has the actual part number.
-
-config USB_SERIAL_KEYSPAN_USA19
-	bool "USB Keyspan USA-19 Firmware"
-	depends on USB_SERIAL_KEYSPAN
-	help
-	  Say Y here to include firmware for the USA-19 converter.
-
-config USB_SERIAL_KEYSPAN_USA18X
-	bool "USB Keyspan USA-18X Firmware"
-	depends on USB_SERIAL_KEYSPAN
-	help
-	  Say Y here to include firmware for the USA-18X converter.
-
-config USB_SERIAL_KEYSPAN_USA19W
-	bool "USB Keyspan USA-19W Firmware"
-	depends on USB_SERIAL_KEYSPAN
-	help
-	  Say Y here to include firmware for the USA-19W converter.
-
-config USB_SERIAL_KEYSPAN_USA19QW
-	bool "USB Keyspan USA-19QW Firmware"
-	depends on USB_SERIAL_KEYSPAN
-	help
-	  Say Y here to include firmware for the USA-19QW converter.
-
-config USB_SERIAL_KEYSPAN_USA19QI
-	bool "USB Keyspan USA-19QI Firmware"
-	depends on USB_SERIAL_KEYSPAN
-	help
-	  Say Y here to include firmware for the USA-19QI converter.
-
-config USB_SERIAL_KEYSPAN_USA49W
-	bool "USB Keyspan USA-49W Firmware"
-	depends on USB_SERIAL_KEYSPAN
-	help
-	  Say Y here to include firmware for the USA-49W converter.
-
-config USB_SERIAL_KEYSPAN_USA49WLC
-	bool "USB Keyspan USA-49WLC Firmware"
-	depends on USB_SERIAL_KEYSPAN
-	help
-	  Say Y here to include firmware for the USA-49WLC converter.
-
 config USB_SERIAL_KLSI
 	tristate "USB KL5KUSB105 (Palmconnect) Driver (EXPERIMENTAL)"
 	depends on USB_SERIAL && EXPERIMENTAL

[PATCH 03/04] Load keyspan firmware with hotplug

[Jan Harkes]

Simple program to convert the keyspan firmware header files to IHEX
formatted files that can be loaded with hotplug.

This is really only needed once to convert the existing keyspan firmware
headers, which is what the next patch will do.

Signed-off-by: Jan Harkes <jaharkes@cs.cmu.edu>


Index: linux/drivers/usb/serial/dumpfw.c
===================================================================
--- /dev/null	1970-01-01 00:00:00.000000000 +0000
+++ linux/drivers/usb/serial/dumpfw.c	2005-03-10 23:16:37.240765747 -0500
@@ -0,0 +1,98 @@
+/*
+ * Convert keyspan firmware header files to Intel HEX format
+ * cc -I/usr/src/linux/drivers/usb/serial -o dumpfw dumpfw.c
+ */
+#include <stdint.h>
+#include <stdio.h>
+
+//#include "keyspan.h" /* ezusb_hex_record */
+
+struct ezusb_hex_record {
+    uint16_t address;
+    uint8_t  size;
+    uint8_t  data[64];
+};
+
+#include "keyspan_usa28_fw.h"
+#include "keyspan_usa28x_fw.h"
+#include "keyspan_usa28xa_fw.h"
+#include "keyspan_usa28xb_fw.h"
+#include "keyspan_usa19_fw.h"
+#include "keyspan_usa19qi_fw.h"
+#include "keyspan_mpr_fw.h"
+#include "keyspan_usa19qw_fw.h"
+#include "keyspan_usa18x_fw.h"
+#include "keyspan_usa19w_fw.h"
+#include "keyspan_usa49w_fw.h"
+#include "keyspan_usa49wlc_fw.h"
+
+char *boilerplate = "\
+# This firmware for the Keyspan %s USB-to-Serial adapter is\n\
+#\n\
+#    Copyright (C) 1999-2003\n\
+#    Keyspan, A division of InnoSys Incorporated (\"Keyspan\")\n\
+#\n\
+# as an unpublished work. This notice does not imply unrestricted or\n\
+# public access to the source code from which this firmware image is\n\
+# derived.  Except as noted below this firmware image may not be\n\
+# reproduced, used, sold or transferred to any third party without\n\
+# Keyspan's prior written consent.  All Rights Reserved.\n\
+#\n\
+# Permission is hereby granted for the distribution of this firmware\n\
+# image as part of a Linux or other Open Source operating system kernel\n\
+# in text or binary form as required.\n\
+#\n\
+# This firmware may not be modified and may only be used with\n\
+# Keyspan hardware.  Distribution of this firmware, in whole or in\n\
+# part, requires the inclusion of this statement.\n\
+#\n";
+
+void dumpfw(char *name, const struct ezusb_hex_record *record)
+{
+    char fw_name[20];
+    char NAME[10];
+    uint16_t address, i;
+    uint8_t crc;
+    FILE *f;
+
+    for (i = 0; name[i] != '\0'; i++)
+	NAME[i] = toupper(name[i]);
+    NAME[i] = '\0';
+
+    sprintf(fw_name, "keyspan-%s.fw", name);
+    printf("writing %s\n", fw_name);
+
+    f = fopen(fw_name, "w");
+    fprintf(f, boilerplate, NAME);
+
+    while (record->address != 0xffff) {
+	crc = record->size + (record->address >> 8) + record->address;
+	fprintf(f, ":%02X%04X00", record->size, record->address);
+	for (i = 0; i < record->size; i++) {
+	    fprintf(f, "%02X", record->data[i]);
+	    crc += record->data[i];
+	}
+	fprintf(f, "%02X\n", (uint8_t)-crc);
+	record++;
+    }
+    fprintf(f, ":00000001FF\n");
+
+    fclose(f);
+}
+
+int main(int argc, char **argv)
+{
+    dumpfw("mpr",	keyspan_mpr_firmware);
+    dumpfw("usa18x",	keyspan_usa18x_firmware);
+    dumpfw("usa19",	keyspan_usa19_firmware);
+    dumpfw("usa19qi",	keyspan_usa19qi_firmware);
+    dumpfw("usa19qw",	keyspan_usa19qw_firmware);
+    dumpfw("usa19w",	keyspan_usa19w_firmware);
+    dumpfw("usa28",	keyspan_usa28_firmware);
+    dumpfw("usa28x",	keyspan_usa28x_firmware);
+    dumpfw("usa28xa",	keyspan_usa28xa_firmware);
+    dumpfw("usa28xb",	keyspan_usa28xb_firmware);
+    dumpfw("usa49w",	keyspan_usa49w_firmware);
+    dumpfw("usa49wlc",	keyspan_usa49wlc_firmware);
+}
+

Re: [PATCH 00/04] Load keyspan firmware with hotplug

[Dmitry Torokhov]

On Monday 04 April 2005 23:23, Jan Harkes wrote:
> On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > > 
> > >   http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > > 
> > > Can you summarize the conclusion of the thread, or what you did get from it,
> > > please ? 
> > 
> > That people didn't like the inclusion of firmware, I posted how you can
> > fix it by moving it outside of the kernel, and asked for patches.
> > 
> > None have come.
> 
> Didn't know you were waiting for it. How about something like the
> following series of patches?
> 
> [01/04] - add simple Intel IHEX format parser to the firmware loader.

Firmware loader is format-agnostic, I think having IHEX parser in a separate
file would be better...

-- 
Dmitry

Re: [PATCH 00/04] Load keyspan firmware with hotplug

[Kay Sievers]

On Mon, 2005-04-04 at 23:51 -0500, Dmitry Torokhov wrote:
> On Monday 04 April 2005 23:23, Jan Harkes wrote:
> > On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> > > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > > > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > > > 
> > > >   http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > > > 
> > > > Can you summarize the conclusion of the thread, or what you did get from it,
> > > > please ? 
> > > 
> > > That people didn't like the inclusion of firmware, I posted how you can
> > > fix it by moving it outside of the kernel, and asked for patches.
> > > 
> > > None have come.
> > 
> > Didn't know you were waiting for it. How about something like the
> > following series of patches?
> > 
> > [01/04] - add simple Intel IHEX format parser to the firmware loader.
> 
> Firmware loader is format-agnostic, I think having IHEX parser in a separate
> file would be better...

Why should this be in-kernel at all? Convert the firmware into a binary
blob or do it in the userspace request.

Kay

Re: [PATCH 00/04] Load keyspan firmware with hotplug

[Jan Harkes]

On Tue, Apr 05, 2005 at 10:32:38AM +0200, Kay Sievers wrote:
> On Mon, 2005-04-04 at 23:51 -0500, Dmitry Torokhov wrote:
> > Firmware loader is format-agnostic, I think having IHEX parser in a separate
> > file would be better...
> 
> Why should this be in-kernel at all? Convert the firmware into a binary
> blob or do it in the userspace request.

Because the keyspan headers seem to have a specific sequence of
operations, something like 'load these 5 bytes at offset 10, load this
byte at offset 0, etc.' I don't know if there is some magic in that
sequence. Without knowing what is in the firmware, it looks to me like a
little bit of bootstrap code is loaded first.

Jan

Re: [PATCH 00/04] Load keyspan firmware with hotplug

[Marcel Holtmann]

Hi Jan,

> > > > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > > > 
> > > >   http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > > > 
> > > > Can you summarize the conclusion of the thread, or what you did get from it,
> > > > please ? 
> > > 
> > > That people didn't like the inclusion of firmware, I posted how you can
> > > fix it by moving it outside of the kernel, and asked for patches.
> > > 
> > > None have come.
> > 
> > Didn't know you were waiting for it. How about something like the
> > following series of patches?
> > 
> > [01/04] - add simple Intel IHEX format parser to the firmware loader.
> 
> Firmware loader is format-agnostic, I think having IHEX parser in a separate
> file would be better...

I agree with Dmitry on this point. The IHEX parser should not be inside
firmware_class.c. What about using keyspan_ihex.[ch] for it?

Regards

Marcel

Re: [PATCH 00/04] Load keyspan firmware with hotplug

[Jan Harkes]

On Tue, Apr 05, 2005 at 11:22:06AM +0200, Marcel Holtmann wrote:
> I agree with Dmitry on this point. The IHEX parser should not be inside
> firmware_class.c. What about using keyspan_ihex.[ch] for it?

That's what I had originally, actually called firmware_ihex.ko, since
the IHEX format parser is not in any way keyspan specific and there are
several usb-serial converters that seem to use the same IHEX->.h trick
which could trivially be modified to use this loader.

But the compiled parser fairly small (< 2KB) and adding it to the
existing module didn't effectively add any size to the firmware_class
module since things are rounded to a page boundary anyways.

Jan

Re: [PATCH 00/04] Load keyspan firmware with hotplug

[Marcel Holtmann]

Hi Jan,

> > I agree with Dmitry on this point. The IHEX parser should not be inside
> > firmware_class.c. What about using keyspan_ihex.[ch] for it?
> 
> That's what I had originally, actually called firmware_ihex.ko, since
> the IHEX format parser is not in any way keyspan specific and there are
> several usb-serial converters that seem to use the same IHEX->.h trick
> which could trivially be modified to use this loader.
> 
> But the compiled parser fairly small (< 2KB) and adding it to the
> existing module didn't effectively add any size to the firmware_class
> module since things are rounded to a page boundary anyways.

so it seems that this is usb-serial specific at the moment. Then I would
propose to add it to the core of the usb-serial driver. Unless no other
driver in the kernel needs a IHEX parser, I think it is bad idea to mess
it up at the moment. People are also working on a replacement for the
current request_firmware(), because the needs are changing. Try to keep
it close with the usb-serial for now.

Regards

Marcel

Re: [PATCH 00/04] Load keyspan firmware with hotplug

[Dmitry Torokhov]

On Apr 5, 2005 9:36 AM, Marcel Holtmann <marcel@holtmann.org> wrote:

> People are also working on a replacement for the
> current request_firmware(), because the needs are changing. Try to keep
> it close with the usb-serial for now.
> 

Could you elaborate on what do you think is needed? I have some of
patches to firmware loader and wondering if we should coordinate out
efforts. I have

1. convert from using a timer to wait_for_comletion_timeout which
simplifies logic
2. tightening of state transition rules and removing possible memory
leak (very unlikely)
3. converting firmware_priv to fw_class_dev to simplify memory management.
4. removing request_firmware_nowait as noone seems to be using it -
and I doubt one would ever want to request firmware from an interrupt.
5. Creating firmware class in a separate thread to work around selinux
(with prism54 firmware is loaded when interface is configured and thus
firware loader runs in context of /sbin/ip which may not have access
to sysfs. Having separate thread will ensure that firmware loader runs
in kernel context).

And I was thinking about caching firmware (siomething like if you do
"echo 2 > /sys/class/firmware/blah/loading" instead of 0 it will keep
a copy of the firmware in memory. One could see all firmwares in
/sys/class/firmware/loaded/<xxx> and by erase cached firmware by
echoing 0 into it).

What do you think?

-- 
Dmitry

Re: [PATCH 00/04] Load keyspan firmware with hotplug

[Marcel Holtmann]

Hi Dmitry,

> > People are also working on a replacement for the
> > current request_firmware(), because the needs are changing. Try to keep
> > it close with the usb-serial for now.
> > 
> 
> Could you elaborate on what do you think is needed? I have some of
> patches to firmware loader and wondering if we should coordinate out
> efforts. I have
> 
> 1. convert from using a timer to wait_for_comletion_timeout which
> simplifies logic
> 2. tightening of state transition rules and removing possible memory
> leak (very unlikely)
> 3. converting firmware_priv to fw_class_dev to simplify memory management.
> 4. removing request_firmware_nowait as noone seems to be using it -
> and I doubt one would ever want to request firmware from an interrupt.
> 5. Creating firmware class in a separate thread to work around selinux
> (with prism54 firmware is loaded when interface is configured and thus
> firware loader runs in context of /sbin/ip which may not have access
> to sysfs. Having separate thread will ensure that firmware loader runs
> in kernel context).
> 
> And I was thinking about caching firmware (siomething like if you do
> "echo 2 > /sys/class/firmware/blah/loading" instead of 0 it will keep
> a copy of the firmware in memory. One could see all firmwares in
> /sys/class/firmware/loaded/<xxx> and by erase cached firmware by
> echoing 0 into it).
> 
> What do you think?

actually there is a thread about firmware loading rewrite and POST
calling of programs. It must be on LKML or the hotplug mailing list.
However my backlog for the interesting topics of these lists increased
while I was traveling the last 5-6 weeks. I think you should simply
start a new one on LKML.

Regards

Marcel

Re: [PATCH 00/04] Load keyspan firmware with hotplug

[Jan Harkes]

On Tue, Apr 05, 2005 at 04:36:31PM +0200, Marcel Holtmann wrote:
> > > I agree with Dmitry on this point. The IHEX parser should not be inside
> > > firmware_class.c. What about using keyspan_ihex.[ch] for it?
> > 
> > That's what I had originally, actually called firmware_ihex.ko, since
> > the IHEX format parser is not in any way keyspan specific and there are
> > several usb-serial converters that seem to use the same IHEX->.h trick
> > which could trivially be modified to use this loader.
> > 
> > But the compiled parser fairly small (< 2KB) and adding it to the
> > existing module didn't effectively add any size to the firmware_class
> > module since things are rounded to a page boundary anyways.
> 
> so it seems that this is usb-serial specific at the moment. Then I would

I really don't see the point you are trying to argue. I said, sure it is
possible to make it a separate module, that is what my initial
implementation was. Why do you want to pigeon-hole it with anything but
the existing firmware loading code?

It is _not_ usb-serial specific, in fact once the device is initialized
this isn't even needed. And the initialization as far as I can see uses
little or no usb-serial code.

It happens that many usb-serial devices are built around the ezusb
chipset, which in turn seems to be a 8051-based microcontroller. The
compilers for such microcontrollers seem to generate IHEX formatted
output possibly because eprom burners generally support the format.

> it up at the moment. People are also working on a replacement for the
> current request_firmware(), because the needs are changing. Try to keep
> it close with the usb-serial for now.

What? I find the existing request_firmware fairly simple and
straightforward, it has a very KISS-like quality to it, it is nice and
small and even the userspace support is trivial. I only saw a mention
about 'replacing' it in the current thread which mostly involved
complaints but didn't actually see anyone volunteering to start working
on such a replacement.

If a driver wants to load 5 different chunks, just call request_firmware
5 times (i.e. drivers/bluetooth/bcm203x.c). If the data is a single
binary blob, just ask for the single binary blob. In this case there
seems to be some structure to the blob that I wanted to preserve, and
that would either be some custom binary format that contains
[<address><length><data>]... tuples, which ofcourse causes problems for
our big-endian brothers, or a similar ascii format, where the IHEX is
not only pretty much standardized, it is trivial to parse and even adds
checksum information.

The only thing that I see missing right now is a change to the makefiles
to have in-tree firmware files get installed in /lib/modules/`uname
-r`/firmware or some similar place. Ideally people would add a line
like,

    fw-$(CONFIG_FOO) = foo-firmware-blob.fw

And make install could drop it a place where hotplug can find it.

Jan

Re: [PATCH 00/04] Load keyspan firmware with hotplug

[Marcel Holtmann]

Hi Jan,

> > > > I agree with Dmitry on this point. The IHEX parser should not be inside
> > > > firmware_class.c. What about using keyspan_ihex.[ch] for it?
> > > 
> > > That's what I had originally, actually called firmware_ihex.ko, since
> > > the IHEX format parser is not in any way keyspan specific and there are
> > > several usb-serial converters that seem to use the same IHEX->.h trick
> > > which could trivially be modified to use this loader.
> > > 
> > > But the compiled parser fairly small (< 2KB) and adding it to the
> > > existing module didn't effectively add any size to the firmware_class
> > > module since things are rounded to a page boundary anyways.
> > 
> > so it seems that this is usb-serial specific at the moment. Then I would
> 
> I really don't see the point you are trying to argue. I said, sure it is
> possible to make it a separate module, that is what my initial
> implementation was. Why do you want to pigeon-hole it with anything but
> the existing firmware loading code?

the existing request_firmware() has nothing in common with IHEX parser
and such a parser should not belong there. So either make it a separate
module or add it to the module that is using it. In this case this is
the keyspan module or the usb-serial core.

> It is _not_ usb-serial specific, in fact once the device is initialized
> this isn't even needed. And the initialization as far as I can see uses
> little or no usb-serial code.
> 
> It happens that many usb-serial devices are built around the ezusb
> chipset, which in turn seems to be a 8051-based microcontroller. The
> compilers for such microcontrollers seem to generate IHEX formatted
> output possibly because eprom burners generally support the format.

Then make it at separate module.

> > it up at the moment. People are also working on a replacement for the
> > current request_firmware(), because the needs are changing. Try to keep
> > it close with the usb-serial for now.
> 
> What? I find the existing request_firmware fairly simple and
> straightforward, it has a very KISS-like quality to it, it is nice and
> small and even the userspace support is trivial. I only saw a mention
> about 'replacing' it in the current thread which mostly involved
> complaints but didn't actually see anyone volunteering to start working
> on such a replacement.
> 
> If a driver wants to load 5 different chunks, just call request_firmware
> 5 times (i.e. drivers/bluetooth/bcm203x.c). If the data is a single
> binary blob, just ask for the single binary blob. In this case there
> seems to be some structure to the blob that I wanted to preserve, and
> that would either be some custom binary format that contains
> [<address><length><data>]... tuples, which ofcourse causes problems for
> our big-endian brothers, or a similar ascii format, where the IHEX is
> not only pretty much standardized, it is trivial to parse and even adds
> checksum information.

I am not going to repeat the current arguments and it is not about
loading multiple firmware files (btw I wrote the bcm203x). Check the
mailing list archives for the details. I still need to catch up with the
discussion, but there is some ongoing work.

> The only thing that I see missing right now is a change to the makefiles
> to have in-tree firmware files get installed in /lib/modules/`uname
> -r`/firmware or some similar place. Ideally people would add a line
> like,
> 
>     fw-$(CONFIG_FOO) = foo-firmware-blob.fw
> 
> And make install could drop it a place where hotplug can find it.

This is another approach and if you want something like that, then send
a patch for it and let Sam and others comment on it.

Regards

Marcel

Re: [PATCH 00/04] Load keyspan firmware with hotplug

[Dmitry Torokhov]

On Apr 5, 2005 6:45 AM, Jan Harkes <jaharkes@cs.cmu.edu> wrote:
> On Tue, Apr 05, 2005 at 11:22:06AM +0200, Marcel Holtmann wrote:
> > I agree with Dmitry on this point. The IHEX parser should not be inside
> > firmware_class.c. What about using keyspan_ihex.[ch] for it?
> 
> That's what I had originally, actually called firmware_ihex.ko, since
> the IHEX format parser is not in any way keyspan specific and there are
> several usb-serial converters that seem to use the same IHEX->.h trick
> which could trivially be modified to use this loader.
> 
> But the compiled parser fairly small (< 2KB) and adding it to the
> existing module didn't effectively add any size to the firmware_class
> module since things are rounded to a page boundary anyways.
> 

It is not about the size, it is about source separation. Since it has
nothing to do with actualy loading of a BLOB from userspace to kernel
space I'd put it into lib/, like crc functions, etc. It does not
really have to work with "struct firmware *", "void *data, size_t len"
should be just as useable.

-- 
Dmitry

Re: [PATCH 00/04] Load keyspan firmware with hotplug

[Sven Luther]

On Tue, Apr 05, 2005 at 12:23:29AM -0400, Jan Harkes wrote:
> On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > > 
> > >   http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > > 
> > > Can you summarize the conclusion of the thread, or what you did get from it,
> > > please ? 
> > 
> > That people didn't like the inclusion of firmware, I posted how you can
> > fix it by moving it outside of the kernel, and asked for patches.
> > 
> > None have come.
> 
> Didn't know you were waiting for it. How about something like the
> following series of patches?
> 
> [01/04] - add simple Intel IHEX format parser to the firmware loader.
> [02/04] - make the keyspan driver use request_firmware.
> [03/04] - converter program used to dump the keyspan headers as IHex files.
> [04/04] - result of running the previous program.
> 
> This ofcourse doesn't actually solve Debian's distribution issues since
> the keyspan firmware can only be distributed as part of 'Linux or other
> Open Source operating system kernel'.

Well, if this is the case, it can be distributed on the non-free archive.

> > So I refuse to listen to talk about this, as obviously, no one cares
> > enough about this to actually fix the issue.
> 
> I got tired of always building my own kernels on Debian just to get my
> serial dongle to work since their included keyspan.ko driver is so
> useless that it isn't even worth having. The only way to use it with a
> Debian kernel is to have the dongle in a powered hub and first boot into
> Windows or a normal kernel.org kernel to get the thing initialized.

The non-free driver package should solve that for you.

> Didn't send the patch earlier since I wanted to split off the
> pre-numeration part of the driver so that after intialization we can
> unload the unused parts of the driver as well as the the firmware class
> module.

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Matthew Wilcox]

On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
> Then let's see some acts.  We (lkml) are not the ones with the percieved
> problem, or the ones discussing it.

Actually, there are some legitimate problems with some of the files in
the Linux source base.  Last time this came up, the Acenic firmware was
mentioned:

http://lists.debian.org/debian-legal/2004/12/msg00078.html

Seems to me that situation is still not resolved.

-- 
"Next the statesmen will invent cheap lies, putting the blame upon 
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince 
himself that the war is just, and will thank God for the better sleep 
he enjoys after this process of grotesque self-deception." -- Mark Twain

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Jeff Garzik]

Matthew Wilcox wrote:
> On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
> 
>>Then let's see some acts.  We (lkml) are not the ones with the percieved
>>problem, or the ones discussing it.
> 
> 
> Actually, there are some legitimate problems with some of the files in
> the Linux source base.  Last time this came up, the Acenic firmware was
> mentioned:
> 
> http://lists.debian.org/debian-legal/2004/12/msg00078.html
> 
> Seems to me that situation is still not resolved.

And it looks like no one cares enough to make the effort to resolve this...

I would love an open source acenic firmware.

	Jeff

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Mon, Apr 04, 2005 at 03:55:55PM -0400, Jeff Garzik wrote:
> Matthew Wilcox wrote:
> >On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
> >
> >>Then let's see some acts.  We (lkml) are not the ones with the percieved
> >>problem, or the ones discussing it.
> >
> >
> >Actually, there are some legitimate problems with some of the files in
> >the Linux source base.  Last time this came up, the Acenic firmware was
> >mentioned:
> >
> >http://lists.debian.org/debian-legal/2004/12/msg00078.html
> >
> >Seems to me that situation is still not resolved.
> 
> And it looks like no one cares enough to make the effort to resolve this...
> 
> I would love an open source acenic firmware.

Yep, but in the meantime, let's clearly mark said firmware as
not-covered-by-the-GPL. In the acenic case it seems to be even easier, as the
firmware is in a separate acenic_firmware.h file, and it just needs to have
the proper licencing statement added, saying that it is not covered by the
GPL, and then giving the information under what licence it is being
distributed.

Jeff, since your name was found in the tg3.c case, and you seem to care about
this too, what is your take on this proposal ?

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Jeff Garzik]

Sven Luther wrote:
> On Mon, Apr 04, 2005 at 03:55:55PM -0400, Jeff Garzik wrote:
> 
>>Matthew Wilcox wrote:
>>
>>>On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
>>>
>>>
>>>>Then let's see some acts.  We (lkml) are not the ones with the percieved
>>>>problem, or the ones discussing it.
>>>
>>>
>>>Actually, there are some legitimate problems with some of the files in
>>>the Linux source base.  Last time this came up, the Acenic firmware was
>>>mentioned:
>>>
>>>http://lists.debian.org/debian-legal/2004/12/msg00078.html
>>>
>>>Seems to me that situation is still not resolved.
>>
>>And it looks like no one cares enough to make the effort to resolve this...
>>
>>I would love an open source acenic firmware.
> 
> 
> Yep, but in the meantime, let's clearly mark said firmware as
> not-covered-by-the-GPL. In the acenic case it seems to be even easier, as the
> firmware is in a separate acenic_firmware.h file, and it just needs to have
> the proper licencing statement added, saying that it is not covered by the
> GPL, and then giving the information under what licence it is being
> distributed.

Who has meaningfully contacted Alteon (probably "Neterion" now) about 
this?  What is the progress of that request?


> Jeff, since your name was found in the tg3.c case, and you seem to care about
> this too, what is your take on this proposal ?
> 
> Friendly,

Bluntly, Debian is being a pain in the ass ;-)

There will always be non-free firmware to deal with, for key hardware.

	Jeff

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Mon, Apr 04, 2005 at 04:47:36PM -0400, Jeff Garzik wrote:
> Sven Luther wrote:
> >Yep, but in the meantime, let's clearly mark said firmware as
> >not-covered-by-the-GPL. In the acenic case it seems to be even easier, as 
> >the
> >firmware is in a separate acenic_firmware.h file, and it just needs to have
> >the proper licencing statement added, saying that it is not covered by the
> >GPL, and then giving the information under what licence it is being
> >distributed.
> 
> Who has meaningfully contacted Alteon (probably "Neterion" now) about 
> this?  What is the progress of that request?

Nobody yet. I plan to do so as time allows though. But how do you respond
about the firmware blobs being declared as GPL covered in the kernel ? Who put
those firmware blobs there, and form where did they came ? 

> >Jeff, since your name was found in the tg3.c case, and you seem to care 
> >about
> >this too, what is your take on this proposal ?
> >
> >Friendly,
> 
> Bluntly, Debian is being a pain in the ass ;-)

Thanks all the same, in this case, it is just me though, who want a clear
solution to this, and you would too, i guess, especially as it is not much
work to do it in the first place, so why is everyone making a problem of this
? 

> There will always be non-free firmware to deal with, for key hardware.

Sure, but then you don't claim they are covered by the GPL as is currently the
case ? And i thought that the whole SCO affaire teached us to be more careful
about this.

It assuredly can't hurt to add a few lines of comments to tg3.c, and since it
is probably (well, 1/3 chance here) you who added said firmware to the tg3.c
file, i guess you are even well placed to at least exclude it from being
GPLed. Is this not a reasonable request ? Which should get a reasonable
answer, and not claims of being a pain in the ass, and other wild fanatical
accusations ? 

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Mon, Apr 04, 2005 at 11:24:05PM +0200, Sven Luther wrote:
> It assuredly can't hurt to add a few lines of comments to tg3.c, and since it
> is probably (well, 1/3 chance here) you who added said firmware to the tg3.c
> file, i guess you are even well placed to at least exclude it from being
> GPLed. Is this not a reasonable request ? Which should get a reasonable
> answer, and not claims of being a pain in the ass, and other wild fanatical
> accusations ? 

Jeff, please ignore this last sentence, i should not have said it.

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

Hello Jeff, ...

If i can believe what i see in :

  http://linux.bkbits.net:8080/linux-2.6/anno/drivers/net/tg3.c@1.255?nav=index.html|src/|src/drivers|src/drivers/net|related/drivers/net/tg3.c|cset@1.2181.28.39

(which may or may not be correct and complete, since i am not really familiar
with bk and how things where back then), you imported the tg3 firmware in our
bk repo on 2002/03/07 :

2002/03/07 jgarzik            | 	0x00000000, 0x10000003, 0x00000000, 0x0000000d, 0x0000000d, 0x3c1d0800,
2002/03/07 jgarzik            | 	0x37bd3ffc, 0x03a0f021, 0x3c100800, 0x26100000, 0x0e000018, 0x00000000,
2002/03/07 jgarzik            | 	0x0000000d, 0x3c1d0800, 0x37bd3ffc, 0x03a0f021, 0x3c100800, 0x26100034,

The changelog importing them says :

  Merge new tg3 version 0.96 gigabit ethernet driver. 

So i suppose this comes from a pre-bk tree or something, altough the whole
copyright of that file is marked as copyrighted by you and davem.

Where did you get that firmware from and under which licence ? And would you
approve of a patch marking this blob as non-GPLed, and we could add the
licencing text for it that you originally got it under ? Does this make sense ?

Or do you believe i should go ahead and approach broadcom, claiming something
like the following :

  "We have noticed that an unlicenced firmware blob whose copyright you hold
  is present in the linux tg3 driver. In order to clarify this situation, we
  would like to know if it is ok to distribute said binary firmware blob, and
  know under what licence it comes."

BTW, also, i am not entirely sure if such changes can be done only by you, or
need approval of everyone who contributed GPL code to that file since then,
altough i believe that since the firmware blob is an agregation, it should not
matter, and only the original checkin you did is the one we need to account
for.

I understand this is bothersome to everyone, but the code base will be a
cleaner one once we solve this issue, don't you think ? 

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Alan Cox]

On Llu, 2005-04-04 at 21:47, Jeff Garzik wrote:
> Bluntly, Debian is being a pain in the ass ;-)
> 
> There will always be non-free firmware to deal with, for key hardware.

Firmware being seperate does make a lot of sense. It isn't going away
but it doesn't generally belong in kernel now we have initrd and
firmware loaders.

Alan

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Jes Sorensen]

>>>>> "Jeff" == Jeff Garzik <jgarzik@pobox.com> writes:

Jeff> Sven Luther wrote:
>> Yep, but in the meantime, let's clearly mark said firmware as
>> not-covered-by-the-GPL. In the acenic case it seems to be even
>> easier, as the firmware is in a separate acenic_firmware.h file,
>> and it just needs to have the proper licencing statement added,
>> saying that it is not covered by the GPL, and then giving the
>> information under what licence it is being distributed.

Jeff> Who has meaningfully contacted Alteon (probably "Neterion" now)
Jeff> about this?  What is the progress of that request?

Whoever actually owns the rights to the firmware these days is going
to be practically impossible to track down. The rights were sold off
left and right when Alteon sold out to Nortel and Nortel then
imploded. 

The s2io/neterion guys may or may not know, but I doubt anyone is
willing to spend real company manhours trying to track down a legal
trace for a dead product which hasn't been manufactured for years and
nobody really cares about technology wise anymore.

Regards,
Jes

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Jes Sorensen]

>>>>> "Matthew" == Matthew Wilcox <matthew@wil.cx> writes:

Matthew> On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
>> Then let's see some acts.  We (lkml) are not the ones with the
>> percieved problem, or the ones discussing it.

Matthew> Actually, there are some legitimate problems with some of the
Matthew> files in the Linux source base.  Last time this came up, the
Matthew> Acenic firmware was mentioned:

Matthew> http://lists.debian.org/debian-legal/2004/12/msg00078.html

Matthew> Seems to me that situation is still not resolved.

Well whoever wrote that seems to have taken the stand that the
openfirmware package was were the firmware came from. The person
obviously made a lot of statements without bothering checking out the
real source. Well it didn't come from there, I got it from Alteon
under a written agreement stating I could distribute the image under
the GPL. Since the firmware is simply data to Linux, hence keeping it
under the GPL should be just fine.

If someone wishes to post a patch adding a GPL header to the
acenic_firmware.h file, fine with me. But beyond that I consider the
case closed.

Regards,
Jes

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[David Schmitt]

On Thursday 07 April 2005 09:25, Jes Sorensen wrote:
> [snip] I got it from Alteon
> under a written agreement stating I could distribute the image under
> the GPL. Since the firmware is simply data to Linux, hence keeping it
> under the GPL should be just fine.

Then I would like to exercise my right under the GPL to aquire the source code 
for the firmware (and the required compilers, starting with genfw.c which is 
mentioned in acenic_firmware.h) since - as far as I know - firmware is coded 
today in VHDL, C or some assembler and the days of hexcoding are long gone.



Regards, David

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Xavier Bestel]

Le jeudi 07 avril 2005 à 10:04 +0200, David Schmitt a écrit :

> Then I would like to exercise my right under the GPL to aquire the source code 
> for the firmware (and the required compilers, starting with genfw.c which is 
> mentioned in acenic_firmware.h) since - as far as I know - firmware is coded 
> today in VHDL, C or some assembler and the days of hexcoding are long gone.

VHDL is a hardware description language. You don't code firmware in
VHDL.

	Xav

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Olivier Galibert]

On Thu, Apr 07, 2005 at 10:17:15AM +0200, Xavier Bestel wrote:
> Le jeudi 07 avril 2005 à 10:04 +0200, David Schmitt a écrit :
> 
> > Then I would like to exercise my right under the GPL to aquire the source code 
> > for the firmware (and the required compilers, starting with genfw.c which is 
> > mentioned in acenic_firmware.h) since - as far as I know - firmware is coded 
> > today in VHDL, C or some assembler and the days of hexcoding are long gone.
> 
> VHDL is a hardware description language. You don't code firmware in
> VHDL.

If the firmware, or part of it, is uploaded to a fpga you do (or
Verilog instead of VHDL, same difference).

  OG.

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Xavier Bestel]

Le jeudi 07 avril 2005 à 10:32 +0200, Olivier Galibert a écrit :
> On Thu, Apr 07, 2005 at 10:17:15AM +0200, Xavier Bestel wrote:
> > Le jeudi 07 avril 2005 à 10:04 +0200, David Schmitt a écrit :
> > 
> > > Then I would like to exercise my right under the GPL to aquire the source code 
> > > for the firmware (and the required compilers, starting with genfw.c which is 
> > > mentioned in acenic_firmware.h) since - as far as I know - firmware is coded 
> > > today in VHDL, C or some assembler and the days of hexcoding are long gone.
> > 
> > VHDL is a hardware description language. You don't code firmware in
> > VHDL.
> 
> If the firmware, or part of it, is uploaded to a fpga you do (or
> Verilog instead of VHDL, same difference).

Oh yes, I was dense. 

	Xav

RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[David Schwartz]

> Well whoever wrote that seems to have taken the stand that the
> openfirmware package was were the firmware came from. The person
> obviously made a lot of statements without bothering checking out the
> real source. Well it didn't come from there, I got it from Alteon
> under a written agreement stating I could distribute the image under
> the GPL. Since the firmware is simply data to Linux, hence keeping it
> under the GPL should be just fine.

	You cannot distribute anything under the GPL if you cannot also distribute
the source code (the preferred form of the software for the purpose of
making modifications to it). How Linux sees it is irrelevant. For any piece
of software, one can imagine some processor that can only see it as data.
The GPL doesn't distinguish between processors.

	Alteon's written agreement notwithstanding, you cannot distribute the
firmware under the GPL if you cannot provide the preferred form of the
firmware for the purpose of making modifications to it. The firmware does
not run on Linux, so saying "linux sees it as data" is as absurd as saying I
can distribute the x86 Linux kernel without the source because my calculator
can only see it as data.

	You cannot distribute the firmware binary under the GPL. Period.

	Now, if you were trying to say that you could aggregate the firmware with
another work and distribute the result under the GPL, the test would be
whether the final result is "mere aggregation" or not. This is a
fantastically tricky question and I don't think anyone on this list could
give you particularly useful guidance.

	My own opinion is that it's a threshold issue based upon several factors.
For example -- has the firmware been specifically designed to work with the
Linux driver or is it "generic" firmware? If you can't take the thing you're
distributing (the combined binary) and extract two works from it (the
firmware and the work whose source you are offering), I cannot see how you
can claim it's mere aggregation.

	If you believe the linker "merely aggregates" the object code for the
driver with the data for the firmware, I can't see how you can argue that
any linking is anything but mere aggregation. In neither case can you
separate the linked work into the two separate works and in both cases the
linker provides one work direct access to the other.

	If you only distribute the source to the driver and don't put a GPL notice
in the files that contain the firmware data, I think you're okay. I think
you're asking for trouble if you distribute a combined compiled/linked
driver.

	DS

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Raul Miller]

On Thu, Apr 07, 2005 at 01:26:17AM -0700, David Schwartz wrote:
> If you believe the linker "merely aggregates" the object code for the
> driver with the data for the firmware, I can't see how you can argue
> that any linking is anything but mere aggregation. In neither case can
> you separate the linked work into the two separate works and in both
> cases the linker provides one work direct access to the other.

You can indeed separate the firmware and the kernel into two separate
works.  That's what people have been proposing as the solution to this
problem.

Also, "mere aggregation" is a term from the GPL.  You can read what
it says there yourself.  But basically it's there so that people make
a distinction between the program itself and other stuff that isn't
the program.

Without that mere aggregation clause, people might be claiming that
text on a disk has to be GPLed because of emacs, or that postscript
files have to be GPLed because of ghostscript, or more generally that
arbitrary object FOO has to be GPLed because of gpled program BAR.

Put another way, what the linker does or doesn't do isn't really the
issue.

People like to think that the linker is somehow special for copyright,
but it's not.  Either the stuff being linked is protected by copyright
even when it's not linked or it's not protected by copyright after it is
linked.  If the license says something about linking then that matters,
but only for cases where the code was protected by copyright even before
it was linked.  And then linking only matters in the specific way that
that license says it matters.

-- 
Raul

RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[David Schwartz]

> On Thu, Apr 07, 2005 at 01:26:17AM -0700, David Schwartz wrote:

> > If you believe the linker "merely aggregates" the object code for the
> > driver with the data for the firmware, I can't see how you can argue
> > that any linking is anything but mere aggregation. In neither case can
> > you separate the linked work into the two separate works and in both
> > cases the linker provides one work direct access to the other.

> You can indeed separate the firmware and the kernel into two separate
> works.  That's what people have been proposing as the solution to this
> problem.

> Also, "mere aggregation" is a term from the GPL.  You can read what
> it says there yourself.  But basically it's there so that people make
> a distinction between the program itself and other stuff that isn't
> the program.

	It's also there because the GPL can only apply to either works placed under
it by their authors and works that are legally classified as derivative. If
you merely aggregate two works, there is no derivation. The GPL is making
clear that it's not trying to exceed the scope of its authority (which is
copyright law).

> Without that mere aggregation clause, people might be claiming that
> text on a disk has to be GPLed because of emacs, or that postscript
> files have to be GPLed because of ghostscript, or more generally that
> arbitrary object FOO has to be GPLed because of gpled program BAR.

	They could, but they would still be wrong. Because if you "merely
aggregate" two works, the result is still two works that can each be under
their own license. The GPL is only making clear what is outside its
authority, but it does not set the scope of its own authority anyway.

> Put another way, what the linker does or doesn't do isn't really the
> issue.

	Well it is. The question is whether you can link two object files together
and distribute the result under the license of each independent file,
treating it like a disk with two files on it, rather than as a single work.

> People like to think that the linker is somehow special for copyright,
> but it's not.  Either the stuff being linked is protected by copyright
> even when it's not linked or it's not protected by copyright after it is
> linked.  If the license says something about linking then that matters,
> but only for cases where the code was protected by copyright even before
> it was linked.  And then linking only matters in the specific way that
> that license says it matters.

	Regardless of what the GPL says, there is a genuine question of whether
linking together file A and file B results in a file C that contains the two
separate works or is a single work that is derivative of both A and B. This
is important because of aspects of copyright law that the GPL acknowledges
explicitly but does not get to decide.

	DS

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Raul Miller]

> > Also, "mere aggregation" is a term from the GPL.  You can read what
> > it says there yourself.  But basically it's there so that people make
> > a distinction between the program itself and other stuff that isn't
> > the program.

On Thu, Apr 07, 2005 at 04:20:50PM -0700, David Schwartz wrote:
>	It's also there because the GPL can only apply to either works
> placed under it by their authors and works that are legally classified
> as derivative. If you merely aggregate two works, there is no
> derivation. The GPL is making clear that it's not trying to exceed the
> scope of its authority (which is copyright law).

The issue of whether or not the combined work is a derivative under
copyright law is a copyright law issue.  The GPL does concern itself
with that issue, but not in the "mere aggregation" clause.

The "mere aggregation" clause holds regardless of whether or not the
combined work is a derivative under copyright law.

[P.S. I've set the Reply-To: header on this message because I think this
thread has drifted away from kernel issues.]

-- 
Raul

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Thu, Apr 07, 2005 at 11:55:44PM -0400, Raul Miller wrote:
> > > Also, "mere aggregation" is a term from the GPL.  You can read what
> > > it says there yourself.  But basically it's there so that people make
> > > a distinction between the program itself and other stuff that isn't
> > > the program.
> 
> On Thu, Apr 07, 2005 at 04:20:50PM -0700, David Schwartz wrote:
> >	It's also there because the GPL can only apply to either works
> > placed under it by their authors and works that are legally classified
> > as derivative. If you merely aggregate two works, there is no
> > derivation. The GPL is making clear that it's not trying to exceed the
> > scope of its authority (which is copyright law).
> 
> The issue of whether or not the combined work is a derivative under
> copyright law is a copyright law issue.  The GPL does concern itself
> with that issue, but not in the "mere aggregation" clause.
> 
> The "mere aggregation" clause holds regardless of whether or not the
> combined work is a derivative under copyright law.
> 
> [P.S. I've set the Reply-To: header on this message because I think this
> thread has drifted away from kernel issues.]

Thanks.

BTW, have any of you read the analysis i made, where i claim, rooted in the
GPL FAQ and with examples, why i believe that the firmware can be considerated
a non derivative of the linux kernel. The main points is that the firmware is
not aimed to run in the same address space, even not the same cpu, as the rest
of the linux kernel, and that there is a clearly defined communication channel
between the GPLed driver and the target processor running the firmware.

I further argumented that taking any different stance would bring us worlds of
hurt as we would consider the bios as being a derivative work of the kernel
they are running, or the bootloader, or the firmware present in proms on
devices loaded into the system and so on.

I think only the fact that if you consider firmware as being a derivative
work, you should consider it a derivative work also when it is flashed on the
prom of a pci card or what not, is decisive enough to make those firmware
blobs not derivative works of the kernel they are under.

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Raul Miller]

On Fri, Apr 08, 2005 at 09:41:35AM +0200, Sven Luther wrote:
> BTW, have any of you read the analysis i made, where i claim, rooted
> in the GPL FAQ and with examples, why i believe that the firmware can
> be considerated a non derivative of the linux kernel.

I hadn't.  I did just now.  Here's my opinions, after reading it:

[1a] It's pretty long, and some of the redundancy is not really relevant
to the issue at hand.  This might be less of an issue, except

[1b] It has some grammar problems that should be fixed.

[2] The presented arguments all look plausible.  Maybe I should study
it more, but I didn't see any significant logical flaws.

[3] It focuses on debian issues more than kernel issues (though a
dedicated reader could see some issues relevant to the linux-kernel
mailing list).

I agree with both you and the gpl faq writers that "communicates at arms
length" is probably a good measure of whether or not the kernel and the
module are the same program.  I can think of cases where this wouldn't
hold (GPLed documentation, for example), but those kinds of issues don't
seem to be relevant here.

> I further argumented that taking any different stance would bring us worlds of
> hurt as we would consider the bios as being a derivative work of the kernel
> they are running, or the bootloader, or the firmware present in proms on
> devices loaded into the system and so on.

Here, you've confused two issues:  "Are A and B part of the same program?"
and  "Are A and B together part of a derivative work under copyright law?"
Sometimes one is true, sometimes the other is true.  You have a GPL
issue when both are true.

One question has to do with the function of A and B.  The other question
is whether the combination is eligible for copyright protection.
Copyright protection is not granted or denied because of functionality.
The functional issues are relevant only because they're written into
the license.

Of course there can be other GPL issues (e.g. it's bad to put a GPL
notice on something which isn't GPLed).

And, of course, there can be non-GPL issues (pulling the blobs out of
the kernel lets people update their firmware without having to compile
the kernel or a kernel module).

> I think only the fact that if you consider firmware as being a derivative
> work, you should consider it a derivative work also when it is flashed on the
> prom of a pci card or what not, is decisive enough to make those firmware
> blobs not derivative works of the kernel they are under.

Uh... not precisely.  You have your facts straight, but your logic is bad.
This fact alone isn't enough to decide whether or not firmware is a
derivative work.

Fortunately this thought isn't a big deal for the cases we're currently
talking about.

-- 
Raul

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Marco d'Itri]

[-- Attachment #1: Type: text/plain, Size: 282 bytes --]

On Apr 04, Greg KH <greg@kroah.com> wrote:

> What if we don't want to do so?  I know I personally posted a solution
Then probably the extremists in Debian will manage to kill your driver,
like they did with tg3 and others.
This sucks, yes.

-- 
ciao,
Marco (@debian.org)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Greg KH]

On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote:
> On Apr 04, Greg KH <greg@kroah.com> wrote:
> 
> > What if we don't want to do so?  I know I personally posted a solution
> Then probably the extremists in Debian will manage to kill your driver,
> like they did with tg3 and others.

Their loss, not mine.

greg k-h

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Adrian Bunk]

On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote:
> On Apr 04, Greg KH <greg@kroah.com> wrote:
> 
> > What if we don't want to do so?  I know I personally posted a solution
> Then probably the extremists in Debian will manage to kill your driver,
> like they did with tg3 and others.


And as they are doing with e.g. the complete gcc documentation.

No documentation for the C compiler (not even a documentation of the 
options) will be neither fun for the users of Debian nor for the Debian 
maintainers - but it's the future of Debian...

The Debian Social Contract says:
  Our Priorities are Our Users and Free Software

The next "editorial changes" to your social contract might remove the 
"Our Users and"...


Seriously:

There might be real problems with non-distributable firmware, but the 
known extremist position of Debian on such issues produces negative 
emotions if something like this comes from Debian.


> This sucks, yes.


Agreed.


> ciao,
> Marco (@debian.org)

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Josselin Mouette]

Le lundi 04 avril 2005 à 21:32 +0200, Adrian Bunk a écrit :
> On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote:
> > On Apr 04, Greg KH <greg@kroah.com> wrote:
> > 
> > > What if we don't want to do so?  I know I personally posted a solution
> > Then probably the extremists in Debian will manage to kill your driver,
> > like they did with tg3 and others.
> 
> And as they are doing with e.g. the complete gcc documentation.
> 
> No documentation for the C compiler (not even a documentation of the 
> options) will be neither fun for the users of Debian nor for the Debian 
> maintainers - but it's the future of Debian...

You are mixing apples and oranges. The fact that the GFDL sucks has
nothing to do with the firmware issue. With the current situation of
firmwares in the kernel, it is illegal to redistribute binary images of
the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
be willing to distribute such binary images, but it isn't our problem.

Putting the firmwares outside the kernel makes them distributable. Some
distributions will want to include them, some others not. But the
important point is that it makes that redistribution legal.
-- 
 .''`.           Josselin Mouette        /\./\
: :' :           josselin.mouette@ens-lyon.org
`. `'                        joss@debian.org
   `-  Debian GNU/Linux -- The power of freedom

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Tue, Apr 05, 2005 at 04:05:07PM +0200, Josselin Mouette wrote:
> Le lundi 04 avril 2005 à 21:32 +0200, Adrian Bunk a écrit :
> > On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote:
> > > On Apr 04, Greg KH <greg@kroah.com> wrote:
> > > 
> > > > What if we don't want to do so?  I know I personally posted a solution
> > > Then probably the extremists in Debian will manage to kill your driver,
> > > like they did with tg3 and others.
> > 
> > And as they are doing with e.g. the complete gcc documentation.
> > 
> > No documentation for the C compiler (not even a documentation of the 
> > options) will be neither fun for the users of Debian nor for the Debian 
> > maintainers - but it's the future of Debian...
> 
> You are mixing apples and oranges. The fact that the GFDL sucks has
> nothing to do with the firmware issue. With the current situation of
> firmwares in the kernel, it is illegal to redistribute binary images of
> the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
> be willing to distribute such binary images, but it isn't our problem.
> 
> Putting the firmwares outside the kernel makes them distributable. Some
> distributions will want to include them, some others not. But the
> important point is that it makes that redistribution legal.

Nope, in this case, the place where those firmware blobs are found are totally
irelevant, since we reached consensus on debian-legal in marsh that they
constitute mere agregation, where either the file or the elf binary are just
the distribution media.

And those binary blobs currently come under the GPL or are not licenced at
all, so taking them out of the kernel doesn't make them distributable in any
way.

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Adrian Bunk]

On Tue, Apr 05, 2005 at 04:05:07PM +0200, Josselin Mouette wrote:
> Le lundi 04 avril 2005 à 21:32 +0200, Adrian Bunk a écrit :
> > On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote:
> > > On Apr 04, Greg KH <greg@kroah.com> wrote:
> > > 
> > > > What if we don't want to do so?  I know I personally posted a solution
> > > Then probably the extremists in Debian will manage to kill your driver,
> > > like they did with tg3 and others.
> > 
> > And as they are doing with e.g. the complete gcc documentation.
> > 
> > No documentation for the C compiler (not even a documentation of the 
> > options) will be neither fun for the users of Debian nor for the Debian 
> > maintainers - but it's the future of Debian...
> 
> You are mixing apples and oranges. The fact that the GFDL sucks has
> nothing to do with the firmware issue. With the current situation of
> firmwares in the kernel, it is illegal to redistribute binary images of
> the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
> be willing to distribute such binary images, but it isn't our problem.
>...


It's a grey area.

debian-legal did pick one of the possible opinions on this matter.


The similarities between the GFDL and the firmware discussion can be 
described with the following two questions:


Is it true, that the removal of much of the documentation in Debian is 
scheduled soon because it's covered by the GFDL, that this is called an 
"editorial change", and that Debian doesn't actually care that this will 
e.g. remove all documentation about available options of the standard C 
compiler used by and shipped with Debian?

Is it true, that Debian will leave users with hardware affected by the 
firmware problem without a working installer in Debian 3.1?


The point is simply, that Debian does more and more look dogmatic at 
it's definition of "free software" without caring about the effects to 
it's users.


As a contrast, read the discussion between Christoph and Arjan in a part 
of this thread how to move firmware out of kernel drivers without 
problems for the users. This might not happen today, but it's better for 
the users.


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Josselin Mouette]

Le jeudi 07 avril 2005 à 23:07 +0200, Adrian Bunk a écrit :
> > You are mixing apples and oranges. The fact that the GFDL sucks has
> > nothing to do with the firmware issue. With the current situation of
> > firmwares in the kernel, it is illegal to redistribute binary images of
> > the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
> > be willing to distribute such binary images, but it isn't our problem.
> 
> It's a grey area.
> 
> debian-legal did pick one of the possible opinions on this matter.

When there are several possible interpretations, you have to pick up the
more conservative one, as it's not up to us to make the interpretation,
but to a court.

> Is it true, that the removal of much of the documentation in Debian is 
> scheduled soon because it's covered by the GFDL, that this is called an 
> "editorial change", and that Debian doesn't actually care that this will 
> e.g. remove all documentation about available options of the standard C 
> compiler used by and shipped with Debian?

The situation changed only in the mind of the person who was the release
manager at that time. The "old" wording is "Debian will remain 100% free
software", and he understood that as "100% of software in Debian will
remain free". The common interpretation is that this wording doesn't
allow GFDL documentation either. The fact these documents are very
useful is irrelevant: the GFDL is a real piece of crap, only a few fools
at the FSF are really arguing it is a free license.

Instead of babbling, some people have started to discuss this with
upstream, and are trying to come up with a GPLed documentation for GCC.
This is much more constructive than repeating again and again "Bleh,
Debian are a bunch of bigots who don't care of the compiler being
documented."

> Is it true, that Debian will leave users with hardware affected by the 
> firmware problem without a working installer in Debian 3.1?

The case of hardware really needing a firwmare to work *and* needed at
installation time is rare. I've only heard of some tg3-based cards. Most
of them will work without the firmware, and for the few remaining ones,
it only means network installation won't work.

> The point is simply, that Debian does more and more look dogmatic at 
> it's definition of "free software" without caring about the effects to 
> it's users.

Being careless in the definition of "free software" is a real disservice
to users. It makes them rely on e.g. non-free documentation for everyday
use.

> As a contrast, read the discussion between Christoph and Arjan in a part 
> of this thread how to move firmware out of kernel drivers without 
> problems for the users. This might not happen today, but it's better for 
> the users.

Some Debian developers have been writing such patches so that we can
still run Linux on this hardware, long before the topic was raised on
the LKML.
-- 
 .''`.           Josselin Mouette        /\./\
: :' :           josselin.mouette@ens-lyon.org
`. `'                        joss@debian.org
   `-  Debian GNU/Linux -- The power of freedom

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Jörn Engel]

On Fri, 8 April 2005 09:22:00 +0200, Josselin Mouette wrote:
> Le jeudi 07 avril 2005 à 23:07 +0200, Adrian Bunk a écrit :
> 
> > As a contrast, read the discussion between Christoph and Arjan in a part 
> > of this thread how to move firmware out of kernel drivers without 
> > problems for the users. This might not happen today, but it's better for 
> > the users.
> 
> Some Debian developers have been writing such patches so that we can
> still run Linux on this hardware, long before the topic was raised on
> the LKML.

I can point you to dozens of patches I have written that were never
merged.  Not because Linus is a d*ckhead (he's not), but because they
were not good enough then and I didn't spend the time to improve them,
so far.

"Someone's written some patches" is a long way from "we have a good
solution".

Jörn

-- 
You cannot suppose that Moliere ever troubled himself to be original in the
matter of ideas. You cannot suppose that the stories he tells in his plays
have never been told before. They were culled, as you very well know.
-- Andre-Louis Moreau in Scarabouche

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Adrian Bunk]

On Fri, Apr 08, 2005 at 09:22:00AM +0200, Josselin Mouette wrote:
> Le jeudi 07 avril 2005 à 23:07 +0200, Adrian Bunk a écrit :
> > > You are mixing apples and oranges. The fact that the GFDL sucks has
> > > nothing to do with the firmware issue. With the current situation of
> > > firmwares in the kernel, it is illegal to redistribute binary images of
> > > the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
> > > be willing to distribute such binary images, but it isn't our problem.
> > 
> > It's a grey area.
> > 
> > debian-legal did pick one of the possible opinions on this matter.
> 
> When there are several possible interpretations, you have to pick up the
> more conservative one, as it's not up to us to make the interpretation,
> but to a court.


If Debian was at least consistent.

Why has Debian a much more liberal interpretation of MP3 patent issues 
than RedHat?


>...
> Instead of babbling, some people have started to discuss this with
> upstream, and are trying to come up with a GPLed documentation for GCC.
> This is much more constructive than repeating again and again "Bleh,
> Debian are a bunch of bigots who don't care of the compiler being
> documented."


Will the replacement documentation for all affected software be 
available before the GFDL documentation gets removed?

At least theoretically, the users are a priority for Debian equally to 
free software.


> > Is it true, that Debian will leave users with hardware affected by the 
> > firmware problem without a working installer in Debian 3.1?
> 
> The case of hardware really needing a firwmare to work *and* needed at
> installation time is rare. I've only heard of some tg3-based cards. Most
> of them will work without the firmware, and for the few remaining ones,
> it only means network installation won't work.


How do you install Debian on a harddisk behind a SCSI controller who's 
driver was removed from the Debian kernels due to it's firmware?


> > The point is simply, that Debian does more and more look dogmatic at 
> > it's definition of "free software" without caring about the effects to 
> > it's users.
> 
> Being careless in the definition of "free software" is a real disservice
> to users. It makes them rely on e.g. non-free documentation for everyday
> use.
>...


Documentation is "software"?

Non-free documentation is better than no documentation.

Non-free software has several problems, but some of them like the right 
to do modifications are less important for documentation, since e.g. 
fixes for security bugs are not an issue.

Removing the available documentation without an equal replacement is a 
real disserve for your users.


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Josselin Mouette]

[-- Attachment #1: Type: text/plain, Size: 1615 bytes --]

Le vendredi 08 avril 2005 à 19:34 +0200, Adrian Bunk a écrit :
> > When there are several possible interpretations, you have to pick up the
> > more conservative one, as it's not up to us to make the interpretation,
> > but to a court.
> 
> If Debian was at least consistent.
> 
> Why has Debian a much more liberal interpretation of MP3 patent issues 
> than RedHat?

Because we already know that patents on MP3 decoders are not
enforceable. Furthermore, the holders of these patents have repeatedly
stated they won't ask for fees on MP3 decoders.

> How do you install Debian on a harddisk behind a SCSI controller who's 
> driver was removed from the Debian kernels due to it's firmware?

Which SCSI controller are you talking about?

> > Being careless in the definition of "free software" is a real disservice
> > to users. It makes them rely on e.g. non-free documentation for everyday
> > use.
> >...
> 
> Documentation is "software"?

Sure.

> Non-free documentation is better than no documentation.
> 
> Non-free software has several problems, but some of them like the right 
> to do modifications are less important for documentation, since e.g. 
> fixes for security bugs are not an issue.
> 
> Removing the available documentation without an equal replacement is a 
> real disserve for your users.

GFDL documentation will still be available in the non-free archive.
-- 
 .''`.           Josselin Mouette        /\./\
: :' :           josselin.mouette@ens-lyon.org
`. `'                        joss@debian.org
  `-  Debian GNU/Linux -- The power of freedom

[-- Attachment #2: Ceci est une partie de message numériquement signée --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Adrian Bunk]

On Fri, Apr 08, 2005 at 07:42:51PM +0200, Josselin Mouette wrote:
> Le vendredi 08 avril 2005 à 19:34 +0200, Adrian Bunk a écrit :
> > > When there are several possible interpretations, you have to pick up the
> > > more conservative one, as it's not up to us to make the interpretation,
> > > but to a court.
> > 
> > If Debian was at least consistent.
> > 
> > Why has Debian a much more liberal interpretation of MP3 patent issues 
> > than RedHat?
> 
> Because we already know that patents on MP3 decoders are not
> enforceable. Furthermore, the holders of these patents have repeatedly

How do you know the patents aren't enforceable?

> stated they won't ask for fees on MP3 decoders.

  http://www.mp3licensing.com/royalty/index.html

talks about 0.75 Dollar for a decoder.

> > How do you install Debian on a harddisk behind a SCSI controller who's 
> > driver was removed from the Debian kernels due to it's firmware?
> 
> Which SCSI controller are you talking about?

Quoting README.Debian of the Debian kernel sources:

<--  snip  -->

* QLA2XXX firmware, driver disabled:
  . drivers/scsi/qla2xxx/*_fw.c

<--  snip  -->

There are a few other SCSI controllers where even the Debian kernel 
sources still ship both the drivers and the firmware. I do not claim to 
understand the latter...

> > > Being careless in the definition of "free software" is a real disservice
> > > to users. It makes them rely on e.g. non-free documentation for everyday
> > > use.
> > >...
> > 
> > Documentation is "software"?
> 
> Sure.

Every book in my book shelf is software?

That doesn't match how people outside of Debian use the word "software".

> > Non-free documentation is better than no documentation.
> > 
> > Non-free software has several problems, but some of them like the right 
> > to do modifications are less important for documentation, since e.g. 
> > fixes for security bugs are not an issue.
> > 
> > Removing the available documentation without an equal replacement is a 
> > real disserve for your users.
> 
> GFDL documentation will still be available in the non-free archive.

Assuming you have an online connection and a friend told you how to 
manually edit your /etc/apt/sources.list for non-free.

But where's the documentation if you don't have an online connection but 
only the dozen binary CDs of Debian?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Rich Walker]

Adrian Bunk <bunk@stusta.de> writes:

> On Fri, Apr 08, 2005 at 07:42:51PM +0200, Josselin Mouette wrote:
>> Le vendredi 08 avril 2005 à 19:34 +0200, Adrian Bunk a écrit :
>> GFDL documentation will still be available in the non-free archive.
>
> Assuming you have an online connection and a friend told you how to 
> manually edit your /etc/apt/sources.list for non-free.

You *do* know that current versions of the installer ask you if you want
non-free, don't you?


> But where's the documentation if you don't have an online connection but 
> only the dozen binary CDs of Debian?

Clearly, since the judgement is "it can't be legally distributed as part
of a package of Debian CD's", it isn't on a package of Debian CD's.



cheers, Rich.

-- 
rich walker         |  Shadow Robot Company | rw@shadow.org.uk
technical director     251 Liverpool Road   |
need a Hand?           London  N1 1LX       | +UK 20 7700 2487
www.shadow.org.uk/products/newhand.shtml

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Josselin Mouette]

[-- Attachment #1: Type: text/plain, Size: 1808 bytes --]

Le vendredi 08 avril 2005 à 20:01 +0200, Adrian Bunk a écrit :
> > Because we already know that patents on MP3 decoders are not
> > enforceable. Furthermore, the holders of these patents have repeatedly
> 
> How do you know the patents aren't enforceable?

Because decoding a MP3 is a trivial operation.

> > stated they won't ask for fees on MP3 decoders.
> 
>   http://www.mp3licensing.com/royalty/index.html
> 
> talks about 0.75 Dollar for a decoder.

I can't find the reference, but IIRC it was stated later that they don't
want to apply this to free (as in beer) software.

> > > Documentation is "software"?
> > 
> > Sure.
> 
> Every book in my book shelf is software?

If you digitalize it, yes.

> That doesn't match how people outside of Debian use the word "software".

When we tried to define what is "software", the only acceptable
definitions we found were things like "every kind of numeric stuff" or
"everything that can be included in Debian". You can try to come up with
your own, you'll see it's not that easy.

> > GFDL documentation will still be available in the non-free archive.
> 
> Assuming you have an online connection and a friend told you how to 
> manually edit your /etc/apt/sources.list for non-free.
> 
> But where's the documentation if you don't have an online connection but 
> only the dozen binary CDs of Debian?

Without the GFDL documentation, you'll have the right to lock the room
in which you put the CDs. The GFDL forbids that, because you'd be "using
technical measures to obstruct further copying" of the documentations.
-- 
 .''`.           Josselin Mouette        /\./\
: :' :           josselin.mouette@ens-lyon.org
`. `'                        joss@debian.org
  `-  Debian GNU/Linux -- The power of freedom

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Giuseppe Bilotta]

On Fri, 08 Apr 2005 20:42:17 +0200, Josselin Mouette wrote:

>> Every book in my book shelf is software?
> 
> If you digitalize it, yes.

AFAIK software only refers to programs, not to arbitrary sequences of
bytes. An MP3 file isn't "software". Although it surely isn't hardware
either.

-- 
Giuseppe "Oblomov" Bilotta

"E la storia dell'umanità, babbo?"
"Ma niente: prima si fanno delle cazzate,
 poi si studia che cazzate si sono fatte"
(Altan)
("And what about the history of the human race, dad?"
 "Oh, nothing special: first they make some foolish things,
  then you study what foolish things have been made")

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Raul Miller]

On Sun, Apr 10, 2005 at 11:24:10AM +0200, Giuseppe Bilotta wrote:
> AFAIK software only refers to programs, not to arbitrary sequences of
> bytes. An MP3 file isn't "software". Although it surely isn't hardware
> either.

This point is a controversial point.  Different people make different
claims.

For example, http://www.answers.com/software -- the Computer Desktop
Encyclopedia asserts that you are correct, while Wikipedia asserts that
you are incorrect.  The American Heritage Dictionary implies you are
correct, and WordNet implies that you're incorrect.

Usage is still evolving, so who knows where this issue will stand in
five years.

In the context of the linux kernel (which I presume you're talking about,
given the message headers), I don't think it's plausible to suggest that
the occasional use of the term "software" in the license means that the
stuff under Documentation/ isn't covered by the license.

-- 
Raul

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Raul Miller]

On Fri, Apr 08, 2005 at 07:34:00PM +0200, Adrian Bunk wrote:
> If Debian was at least consistent.
> 
> Why has Debian a much more liberal interpretation of MP3 patent issues 
> than RedHat?

It's impossible to treat patents consistently.

The U.S. patent office, at least, has granted patents on natural laws,
on stuff that's already patented, on stuff with clear prior art, on
trivial math operations and so on.  Patents are being granted so quickly
there's no way of even knowing what's patented.

Or were you hoping that Debian would follow Red Hat's lead?

As for this particular patent, I'm not really sure what's being patented.
Trial and error?  Spectral quantization?  The specific data format?
Addition, multiplication, and exponentiation?  In many respects, mp3 is
similar to jpeg.  Does that mean that any use of the techniques used
by jpeg in the domain of audio is covered by this patent?  Does that
mean that jpeg is in violation of this patent?  If I use the same kind
of math with a time dimension, am I violating some other mpeg patents?
What about the other hundreds of thousands of patents?  How many of
them am I violating when I use lossy compression based on spectral
quantization?

-- 
Raul

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Adrian Bunk]

On Fri, Apr 08, 2005 at 08:31:22PM -0400, Raul Miller wrote:
> On Fri, Apr 08, 2005 at 07:34:00PM +0200, Adrian Bunk wrote:
> > If Debian was at least consistent.
> > 
> > Why has Debian a much more liberal interpretation of MP3 patent issues 
> > than RedHat?
> 
> It's impossible to treat patents consistently.
> 
> The U.S. patent office, at least, has granted patents on natural laws,
> on stuff that's already patented, on stuff with clear prior art, on
> trivial math operations and so on.  Patents are being granted so quickly
> there's no way of even knowing what's patented.
> 
> Or were you hoping that Debian would follow Red Hat's lead?


Even RedHat with a stronger financial background than Debian considered 
the MP3 patents being serious enough to remove MP3 support.

Yes, Debian can choose to put a higher risk on their distributors and 
mirrors - there's nothing wrong with this.


Note that this is a respose to Josselin's statement:

<--  snip  -->

When there are several possible interpretations, you have to pick up the
more conservative one, as it's not up to us to make the interpretation,
but to a court.

<--  snip  -->


It's simply silly to be extremely picky on copyright issues while being 
extremely liberal on patent issues - the risk of a Debian distributor 
being sued for patent violations (no matter how the lawsuit might end) 
is definitely present.


> As for this particular patent, I'm not really sure what's being patented.
>...


Which one of the 23 patents they list do you call "this particular 
patent"?


> Raul


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Raul Miller]

> > It's impossible to treat patents consistently.

On Sat, Apr 09, 2005 at 04:38:15PM +0200, Adrian Bunk wrote:
> Even RedHat with a stronger financial background than Debian considered 
> the MP3 patents being serious enough to remove MP3 support.

It's silly to treat financial risk as being a one dimensional quantity.

It could easily be that Red Hat decided that the mp3 patent owners would
be going after people with deep pockets.  If this is the risk model,
Red Hat's risk would be much much higher than Debian's.

> Note that this is a respose to Josselin's statement:
> 
< When there are several possible interpretations, you have to pick up the
< more conservative one, as it's not up to us to make the interpretation,
< but to a court.

Sure, if you have several plausible interpretations, you pick the one
you feel is likely to be the most important, and if all of them seem
likely you pick the one that seems worst.

But, ultimately, you can't treat software patents consistently.
There's no reasonable way to do so.

> It's simply silly to be extremely picky on copyright issues while being 
> extremely liberal on patent issues - the risk of a Debian distributor 
> being sued for patent violations (no matter how the lawsuit might end) 
> is definitely present.

Anything to do with software patents is silly.  Being liberal about
software patents is silly.  Being conservative about software patents
is silly.

Copyright, while far from perfect, can at least be reasoned about.

> > As for this particular patent, I'm not really sure what's being patented.
> >...

> Which one of the 23 patents they list do you call "this particular
> patent"?

What makes you think I'm sure about what's being patented in 22 of
those patents?

I should probably have said "As for patent claims applying to mp3,
...", but the issue is thorny enough that even that might not have been
accurate enough.

But, treating "this particular patent" as a meta-syntactic variable
should be adequate for you to understand what I was saying.

Bottom line, though: softare patents generally make very little sense.

-- 
Raul

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Thu, Apr 07, 2005 at 11:07:23PM +0200, Adrian Bunk wrote:
> On Tue, Apr 05, 2005 at 04:05:07PM +0200, Josselin Mouette wrote:
> > Le lundi 04 avril 2005 à 21:32 +0200, Adrian Bunk a écrit :
> > > On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote:
> > > > On Apr 04, Greg KH <greg@kroah.com> wrote:
> > > > 
> > > > > What if we don't want to do so?  I know I personally posted a solution
> > > > Then probably the extremists in Debian will manage to kill your driver,
> > > > like they did with tg3 and others.
> > > 
> > > And as they are doing with e.g. the complete gcc documentation.
> > > 
> > > No documentation for the C compiler (not even a documentation of the 
> > > options) will be neither fun for the users of Debian nor for the Debian 
> > > maintainers - but it's the future of Debian...
> > 
> > You are mixing apples and oranges. The fact that the GFDL sucks has
> > nothing to do with the firmware issue. With the current situation of
> > firmwares in the kernel, it is illegal to redistribute binary images of
> > the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
> > be willing to distribute such binary images, but it isn't our problem.
> >...
> 
> 
> It's a grey area.
> 
> debian-legal did pick one of the possible opinions on this matter.
> 
> The similarities between the GFDL and the firmware discussion can be 
> described with the following two questions:
> 
> Is it true, that the removal of much of the documentation in Debian is 
> scheduled soon because it's covered by the GFDL, that this is called an 
> "editorial change", and that Debian doesn't actually care that this will 
> e.g. remove all documentation about available options of the standard C 
> compiler used by and shipped with Debian?

Notice though that the GFDL problematic is part of a much older issue between
debian and the FSF on this, and i believe discussions to solve this issues
have been under discussions since more than a year without real progress that
i know of.

> Is it true, that Debian will leave users with hardware affected by the 
> firmware problem without a working installer in Debian 3.1?

Yes, probably. not my fault though, and the current discussion is part of the
plan to fix this, through availability of non-free installer components.

> The point is simply, that Debian does more and more look dogmatic at 
> it's definition of "free software" without caring about the effects to 
> it's users.

I reject this affirmation. 

> As a contrast, read the discussion between Christoph and Arjan in a part 
> of this thread how to move firmware out of kernel drivers without 
> problems for the users. This might not happen today, but it's better for 
> the users.

It is indeed, but it is something that involves kernel development which i
don't really have time to do right now, and even if we where to do that, the
legal problem of the messed licencing situation would remain. The current
short term solution is simply to move the affected drivers to non-free, and
provide mechanisms for the user to load these installer modules with the free
installer, or have a couple of builds of a non-free installer which include
these non-free modules.

Saying that we are dogmatic, without even caring to understand what the
current reality is doesn't strike me at the most reasonable way to discuss
such issues.

Friendly,

Sven Luther

Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.

[Sven Luther]

On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote:
> On Apr 04, Greg KH <greg@kroah.com> wrote:
> 
> > What if we don't want to do so?  I know I personally posted a solution
> Then probably the extremists in Debian will manage to kill your driver,
> like they did with tg3 and others.

Nope, they were simply moved to non-free, as it should. I believe the package
is waiting for NEW processing, but i also believe that the dubious copyright
assignement will not allow the ftp-masters to let it pass into the archive,
since it *IS* a GPL violation, and thus i am doing this in order to solve that
problem.

> This sucks, yes.

Not really. Once the, post-sarge, transition is done, you just will have to
load the non-free .udeb from the non-free d-i archive, or install the module
package from non-free, and you won't even notice.

Sarge kernels are messed beyond recognition in this anyway, but they are
freezed so ...

Friendly,

Sven Luther

Re: [PATCH 00/04] Load keyspan firmware with hotplug

[Humberto Massa]

Sven Luther wrote:

>  On Tue, Apr 05, 2005 at 12:23:29AM -0400, Jan Harkes wrote:
> > This ofcourse doesn't actually solve Debian's distribution issues since
> > the keyspan firmware can only be distributed as part of 'Linux or other
> > Open Source operating system kernel'.
>
>
>  Well, if this is the case, it can be distributed on the non-free
>  archive.

Nope, looks awfully non-distributable for me, unless you put it into a 
kernel-non-free with the entire kernel -- but it says clearly that it's 
undistributable by itself.


HTH,
Massa