Re: Binary-only firmware covered by the GPL?

Re: Binary-only firmware covered by the GPL?

[Humberto Massa]

Oh, man, it seems that I *must* repeat myself one more time, at least
to see if I'm not in everyone's killfile :-)

@ 30/03/2004 11:19 : wrote Pavel Machek :

> Hi!
Hi!
> 
> 
>>> #include <hallo.h> * David Schwartz [Thu, Mar 25 2004,
>>> 04:41:23PM]:
>>>>> IMHO code that can be compiled would probably be the
>>>>> preferred form of the work.
>>>> You are seriously arguing that the obfuscated binary of the 
>>>> firmware is the preferred form of the firmware for the
>>>> purpose of making modifications to it?!
I don't know if that's what /he/ is arguing, but *I* am arguing that 
in the cases I've seen here and in debian-legal, we have the following 
circumstances (the qla2xxx/ql2100_fw.c canonical example):
* the file in question (and its brothers and cousins) have the 
following structure IIRC:
	+ GPL license comment-header
	+ some includes?
	+ the firmware in c-blob format or unsigned char fw[] = ....
	+ nothing else.
* as the file is clearly marked by the copyright holder as being 
_distributed under the terms of the GPL_ and no other format is given 
to modify the fw[], at least *legally* is MHO that any 
recipient/redistributor of the file _can_ and _must_ consider the file 
in *that* format as the preferred form for modification (pf4m) *and*, 
considering it the source code, follow the directions of the GPL in 
respect to modification and redistribution.
* the /status quo/ obtained by observation of the previous item 
prevails _until somebody proves_ that the fw[] = {} is *not* the 
source code; this, usually, can be proven only by confession, i.e., 
the original copyright holder *comes out and says:* "hmmm, this is not 
the source code". Notice that the copyright holder maintaining silence 
is _not_ confession.
* in this case (copyright holder confesses it's not the source code) 
applied to the examples in casu, i.e., firmware, the kernel people 
cannot distribute the binary blob *inside the kernel tree*, but can do 
it separately _if the copyright holder grants a license_ to.
* even so, Debian could not distribute it.

>>> Yes, the driver authors PREFERS to make the changes on the C
>>> source code, he never has to modify the firmware. Exactly what
>>> the GPL requests, where is your problem?
>> 
>> But the firmware didn't appear out of thin air - someone wrote it
>>  somehow. If that's using a hex editor or inside the C code
>> doesn't matter, but most likely they used some other language
>> like either C or assembly (no, not all firmware is written using
>> assembly), and there are cases where some are in fact written
>> using a hex editor but I can't remember any that has been for the
>> last 30 or so years but I'm sure there has been cases where there
>> hasn't been a working assembler.

But there are cases, even if you don't know of them. And this is the 
case that has to be taken in account when we start *presuming* things, 
at least legally, IMHO.
> If my code contains picture of human, do I have to provide his DNA,
> too? Pavel
> 
> (runs away)


-- 
best regards,M

Re: Binary-only firmware covered by the GPL?

[Henning Makholm]

Scripsit Humberto Massa <humberto.massa@almg.gov.br>

> to modify the fw[], at least *legally* is MHO that any
> recipient/redistributor of the file _can_ and _must_ consider the file
> in *that* format as the preferred form for modification (pf4m) *and*,
> considering it the source code, follow the directions of the GPL in
> respect to modification and redistribution.

No, law does not work that way. The phrase "preferred form for
modification" has a clear enough, if somewhat fuzzy, literal meaning,
and one cannot *implicitly* make it mean something that directly
contrast to the literal meaning. If nobody *actually* prefers the
binary blob for modification, then the binary blob is *not* the
preferred form for modification. That's irrespective of whether the
copyright holder behaves inconsistently.

> * the /status quo/ obtained by observation of the previous item
> prevails _until somebody proves_ that the fw[] = {} is *not* the
> source code;

And Debian's approach to software freedom doesn't work that way
either. We treat software as non-free and non-distributable unless and
until we see good and self-consistent evidence that it is actually
free and distributable. The "burden of proof", to the extent that
expression applies, is always on the side that claims that the
software in question is OK for Debian to distribute.

-- 
Henning Makholm                "Nu kommer han. Kan du ikke høre knallerten?"
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Binary-only firmware covered by the GPL?

[Adrian Bunk]

There's another issue with these files:

>From drivers/scsi/qla2xxx/ql2100_fw.c in kernel 2.6:

<--  snip  -->

/******************************************************************************
 *                  QLOGIC LINUX SOFTWARE
 *
 * QLogic ISP2x00 device driver for Linux 2.6.x
 * Copyright (C) 2003-2004 QLogic Corporation
 * (www.qlogic.com)
 *
 * 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; either version 2, or (at your option) any
 * later version.
 *
 * This program is distributed in the hope that it will be useful, but
 * WITHOUT ANY WARRANTY; without even the implied warranty of
 * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 * General Public License for more details.
 *
 
*************************************************************************/

/*
 *      Firmware Version 1.19.24 (14:02 Jul 16, 2002)
 */

...

#ifdef UNIQUE_FW_NAME
unsigned short fw2100tp_code01[] = { 
#else
unsigned short risc_code01[] = { 
#endif
        0x0078, 0x102d, 0x0000, 0x95f1, 0x0000, 0x0001, 0x0013, 0x0018,
        0x0017, 0x2043, 0x4f50, 0x5952, 0x4947, 0x4854, 0x2032, 0x3030,
        0x3120, 0x514c, 0x4f47, 0x4943, 0x2043, 0x4f52, 0x504f, 0x5241,
        0x5449, 0x4f4e, 0x2049, 0x5350, 0x3231, 0x3030, 0x2046, 0x6972,
...

<--  snip  -->


The GPL says that you must give someone receiving a binary the source 
code, and it says:
  The source code for a work means the preferred form of the work for
  making modifications to it.


This is perhaps a bit besides the main firmware discussion and IANAL, 
but is this file really covered by the GPL?


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: Binary-only firmware covered by the GPL?

[Jeff Garzik]

Well IANAL, but it seems not so cut-n-dried, at least.

Firmware is a program that executes on another processor, so no linking 
is taking place at all.  It is analagous to shipping a binary-only 
program in your initrd, IMO.

Re: Binary-only firmware covered by the GPL?

[Adrian Bunk]

On Thu, Mar 25, 2004 at 05:31:53PM -0500, Jeff Garzik wrote:
> 
> Well IANAL, but it seems not so cut-n-dried, at least.
> 
> Firmware is a program that executes on another processor, so no linking 
> is taking place at all.  It is analagous to shipping a binary-only 
> program in your initrd, IMO.

My point in this mail was a bit "besides the main firmware discussion":

I was not asking whether it's OK to ship this file in the kernel 
sources, I was asking whether the contents of the file is really under 
the GPL as stated in the header of this file if it contains this binary 
code.

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

Bug#239952: Binary-only firmware covered by the GPL?

[Stefan Smietanowski]

Jeff Garzik wrote:

> 
> Well IANAL, but it seems not so cut-n-dried, at least.
> 
> Firmware is a program that executes on another processor, so no linking 
> is taking place at all.  It is analagous to shipping a binary-only 
> program in your initrd, IMO.

Except the firmware itself is GPL in this case.

// Stefan

Re: Binary-only firmware covered by the GPL?

[John Hasler]

Stefan writes:
> Except the firmware itself is GPL in this case.

So the problem is not GPL compatibility: it's GPL code being distributed
without source.  Can we get written permission from the manufacturer?
Without either source or written permission to do without we cannot
redistribute.

Note that the GPL does not require that the firmware build from source on
Linux.  We are not obligated (by the GPL) to supply a compiler.
-- 
John Hasler               You may treat this work as if it 
john@dhh.gt.org           were in the public domain.
Dancing Horse Hill        I waive all rights.
Elmwood, Wisconsin

Re: Binary-only firmware covered by the GPL?

[David Woodhouse]

On Thu, 2004-03-25 at 17:31 -0500, Jeff Garzik wrote:
> Firmware is a program that executes on another processor, so no linking 
> is taking place at all.  It is analagous to shipping a binary-only 
> program in your initrd, IMO.

You seem to be thinking of this:

  These requirements apply to the modified work as a whole.  If
  identifiable sections of that work are not derived from the Program,
  and can be reasonably considered independent and separate works in
  themselves, then this License, and its terms, do not apply to those
  sections... 

But you seem to ignore the fact that the sentence ends thus:

        ...WHEN YOU DISTRIBUTE THEM AS SEPARATE WORKS.

And indeed that the subsequent sentence reads as follows:

                                                        But when you
  distribute the same sections as part of a whole which is a work based
  on the Program, the distribution of the whole must be on the terms of
  this License, whose permissions for other licensees extend to the
  entire whole, and thus to each and every part regardless of who wrote
  it.

You also seem to be ignoring the next paragraph where it mentions
COLLECTIVE works:

  Thus, it is not the intent of this section to claim rights or contest
  your rights to work written entirely by you; rather, the intent is to
  exercise the right to control the distribution of derivative OR
  COLLECTIVE WORKS based on the Program.

------

The firmware blob in question can be reasonably considered to be an
independent and separate work in itself. The GPL doesn't apply to it
when it is distributed as a SEPARATE work. But when you distribute it as
part of a whole which is a work based on other parts of the kernel, by
including it in the kernel source in such a manner, the distribution of
the whole must be on the terms of the GPL, whose permissions for other
licensees extend to the entire whole, and thus to each and every part.

It's not the intent of the GPL to claim rights to firmware written
independently for such hardware; rather, the intent is to exercise the
right to control the distribution of _COLLECTIVE_ works based on the
indisputably GPL'd parts of the kernel.

-- 
dwmw2

Re: Binary-only firmware covered by the GPL?

[John Hasler]

David Woodhouse writes:
> The firmware blob in question can be reasonably considered to be an
> independent and separate work in itself. The GPL doesn't apply to it when
> it is distributed as a SEPARATE work. But when you distribute it as part
> of a whole which is a work based on other parts of the kernel, by
> including it in the kernel source...

So don't.  Put it in a seperate file and load it at boot time.
-- 
John Hasler               You may treat this work as if it 
john@dhh.gt.org           were in the public domain.
Dancing Horse Hill        I waive all rights.
Elmwood, Wisconsin

Re: Binary-only firmware covered by the GPL?

[Stefan Smietanowski]

Hi David.

> The firmware blob in question can be reasonably considered to be an
> independent and separate work in itself. The GPL doesn't apply to it
> when it is distributed as a SEPARATE work. But when you distribute it as
> part of a whole which is a work based on other parts of the kernel, by
> including it in the kernel source in such a manner, the distribution of
> the whole must be on the terms of the GPL, whose permissions for other
> licensees extend to the entire whole, and thus to each and every part.
> 
> It's not the intent of the GPL to claim rights to firmware written
> independently for such hardware; rather, the intent is to exercise the
> right to control the distribution of _COLLECTIVE_ works based on the
> indisputably GPL'd parts of the kernel.
> 

But the firmware comes after a GPL statement thereby leading to the
conclusion that it is their INTENTION to GPL the firmware.

If we have a source:

--

/*
     This file is under the GPL, yada yada
*/
#include "things.h"

void some_func(void)
{
   does_something();
}

char firmware[]={0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07};

void upload_firmware(void)
{
   do_upload(firmware);
}

--

Then it seems clear to me that the firmware is under the GPL because it
is PART of the GPL'd file. If not, then I don't see how any statement
can ever be true to similar effect, even for some_func().

// Stefan

Bug#239952: Binary-only firmware covered by the GPL?

[Dumitru Ciobarcianu]

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

On Fri, 2004-03-26 at 09:50 +0100, Stefan Smietanowski wrote:
> /*
>      This file is under the GPL, yada yada
> */
> #include "things.h"
> 
> void some_func(void)
> {
>    does_something();
> }
> 
> char firmware[]={0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07};
> 
> void upload_firmware(void)
> {
>    do_upload(firmware);
> }
> 
> --
> 
> Then it seems clear to me that the firmware is under the GPL because it
> is PART of the GPL'd file.


If you're right, then the "binary" of the firmware it's GPL, not the
source of the firmware, because that's what you have in this case :)

You can have that ? GPL the binary but not the source ? :)

-- 
Cioby

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

Re: Binary-only firmware covered by the GPL?

[Stefan Smietanowski]

Hi Dumitru.

>>/*
>>     This file is under the GPL, yada yada
>>*/
>>#include "things.h"
>>
>>void some_func(void)
>>{
>>   does_something();
>>}
>>
>>char firmware[]={0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07};
>>
>>void upload_firmware(void)
>>{
>>   do_upload(firmware);
>>}
>>
>>--
>>
>>Then it seems clear to me that the firmware is under the GPL because it
>>is PART of the GPL'd file.
> 
> 
> 
> If you're right, then the "binary" of the firmware it's GPL, not the
> source of the firmware, because that's what you have in this case :)
> 
> You can have that ? GPL the binary but not the source ? :)

Not as far as I know, you can't put the resulting binary under a
different license than the source, but hey, IANAL :)

That would make all sorts of nasty implications if it was possible.

// Stefan

Bug#239952: Binary-only firmware covered by the GPL?

[Matthew Wilcox]

On Thu, Mar 25, 2004 at 05:31:53PM -0500, Jeff Garzik wrote:
> 
> Well IANAL, but it seems not so cut-n-dried, at least.
> 
> Firmware is a program that executes on another processor, so no linking 
> is taking place at all.  It is analagous to shipping a binary-only 
> program in your initrd, IMO.

Linking isn't the issue.  I went and read the original bug on this a
while back.  The issue is that it's a program that's distributed in
binary form without source code.  That's forbidden from being in main
by the terms of the Debian Social Contract.

I realise there's a grey area between "magic data you write to a device"
and "a program that is executed on a different processor".  For example,
palette data for a frame buffer.  But nobody's arguing for that grey
area here -- it's clearly a program without source code that Debian
can't distribute.

I think this is a terribly unfortunate state of affairs and I'm not happy
about how it's been handled or communicated.  I'd really appreciate it
if someone managed to think of a good solution to this.

-- 
"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: Binary-only firmware covered by the GPL?

[GOTO Masanori]

At Fri, 26 Mar 2004 00:33:39 +0000,
Matthew Wilcox wrote:
> I realise there's a grey area between "magic data you write to a device"
> and "a program that is executed on a different processor".  For example,
> palette data for a frame buffer.  But nobody's arguing for that grey
> area here -- it's clearly a program without source code that Debian
> can't distribute.

Well, I also think this is grey area.

But think about: why can we distribute assembler only code in linux
kernel?  It's near to binary form (objdump -d is your friend).

If they insist this source code is GPL, then I think this code is
covered under GPL at least for this case.  If it's GPL, then we can
derive the newer firmware code from this original ql2100_fw.c freely.

Regards,
-- gotom

Re: Binary-only firmware covered by the GPL?

[John Hasler]

GOTO Masanori writes:
> But think about: why can we distribute assembler only code in linux
> kernel?

Was it not written in assembler?  If so, there is no problem.

> If they insist this source code is GPL, then I think this code is covered
> under GPL at least for this case.  If it's GPL, then we can derive the
> newer firmware code from this original ql2100_fw.c freely.

I don't follow you.  What source code?
-- 
John Hasler
john@dhh.gt.org (John Hasler)
Dancing Horse Hill
Elmwood, WI

RE: Binary-only firmware covered by the GPL?

[David Schwartz]

> At Fri, 26 Mar 2004 00:33:39 +0000,

> Matthew Wilcox wrote:

> > I realise there's a grey area between "magic data you write to a device"
> > and "a program that is executed on a different processor".  For example,
> > palette data for a frame buffer.  But nobody's arguing for that grey
> > area here -- it's clearly a program without source code that Debian
> > can't distribute.

> Well, I also think this is grey area.

	On what basis? How is this file different from an executable?

	The gray area cases are where the code, as orginally written, is obscure.
Perhaps because it uses 'magic numbers' from data sheets rather than
symbolic constants. However, the GPL doesn't require you to add comments or
to write clear code. It simply prohibits deliberate obfuscation by one
particular means, namely having two forms of the code, one that you
distribute and one that you use to make modifications. (Other forms of
obfuscation are the gray areas.)

	But this case is squarely where the GPL says "no". In this case, there is
one form of the firmware for the purposes of making modifications to it and
there is another form that's distributed, ostensibly under the GPL.

> But think about: why can we distribute assembler only code in linux
> kernel?  It's near to binary form (objdump -d is your friend).

	We can distribute binaries if we want. The issue is that we cannot
distribute in any form and withhold the preferred form of the code for the
purpose of making modifications to it. How easy or hard it is to modify is
not the issue, one just can't take active steps to make it harder by
withholding the 'real source'.

> If they insist this source code is GPL, then I think this code is
> covered under GPL at least for this case.  If it's GPL, then we can
> derive the newer firmware code from this original ql2100_fw.c freely.

	I can't figure out what you're trying to say here. The file claims it is
GPL'd. If it is, then whoever receives it has a right to a copy of the
preferred form of that file for the purpose of making modifications to it.
Anyone who cannot distribute that preferred form cannot, according to the
GPL, distribute the other form.

	Bluntly, that file is the preferred form of the firmware for the purpose of
using or executing it. The GPL requires the preferred form for the purpose
of making modifications.

	IMO, the 'whole work' and 'linking' arguments are not important. The issue
is clear just from looking at this one file and what is required to
distribute it itself.

	DS

Re: Binary-only firmware covered by the GPL?

[Chris Cheney]

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

On Thu, Mar 25, 2004 at 06:06:37PM -0800, David Schwartz wrote:
> 
> 
> > At Fri, 26 Mar 2004 00:33:39 +0000,
> 
> > Matthew Wilcox wrote:
> 
> > > I realise there's a grey area between "magic data you write to a device"
> > > and "a program that is executed on a different processor".  For example,
> > > palette data for a frame buffer.  But nobody's arguing for that grey
> > > area here -- it's clearly a program without source code that Debian
> > > can't distribute.
> 
> > Well, I also think this is grey area.
> 
> 	On what basis? How is this file different from an executable?
> 
> 	The gray area cases are where the code, as orginally written, is obscure.
> Perhaps because it uses 'magic numbers' from data sheets rather than
> symbolic constants. However, the GPL doesn't require you to add comments or
> to write clear code. It simply prohibits deliberate obfuscation by one
> particular means, namely having two forms of the code, one that you
> distribute and one that you use to make modifications. (Other forms of
> obfuscation are the gray areas.)
> 
> 	But this case is squarely where the GPL says "no". In this case, there is
> one form of the firmware for the purposes of making modifications to it and
> there is another form that's distributed, ostensibly under the GPL.

So is a reverse engineered driver where there is a binary blob the
preferred form of source? Otherwise the case isn't that binary blobs are
against the GPL, just that if the author knows what generates the binary
blob and doesn't disclose it then it is against the GPL. Of course
reverse engineered drivers with binary blobs in them are probably
copyright infringements anyway...

Chris

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

Re: Binary-only firmware covered by the GPL?

[John Hasler]

Chris writes:
> So is a reverse engineered driver where there is a binary blob the
> preferred form of source?

Where did the blob come from?  If the author wrote it in binary (unlikely),
then it's ok.  If he wrote it in hex (I've done that) he should supply a
hex file from which the blob can be generated.

> Of course reverse engineered drivers with binary blobs in them are
> probably copyright infringements anyway...

If the author ripped the blob out of someone else's closed-source binary
driver it certainly is.  It also is a GPL violation.
-- 
John Hasler               You may treat this work as if it 
john@dhh.gt.org           were in the public domain.
Dancing Horse Hill        I waive all rights.
Elmwood, Wisconsin

Re: Binary-only firmware covered by the GPL?

[Stefan Smietanowski]

Hi GOTO.

> But think about: why can we distribute assembler only code in linux
> kernel?  It's near to binary form (objdump -d is your friend).

It's not. The difference is that we can always insert another asm
statement anywhere (of course changing the way the function works)
and still have it assemble and unless we goofed up it'll still run.
mov ax,ax for instance won't do a thing. We can insert that
anywhere we wish without changing anything. The assembler will take
care of any relative jumps and pointers but with a binary firmware,
try to insert a byte into it (not CHANGE one, INSERT one), even
if you know just insert a NOP somewhere - and see what happens.

// Stefan

Re: Binary-only firmware covered by the GPL?

[John Bradford]

> > But think about: why can we distribute assembler only code in linux
> > kernel?  It's near to binary form (objdump -d is your friend).
> 
> It's not. The difference is that we can always insert another asm
> statement anywhere (of course changing the way the function works)
> and still have it assemble and unless we goofed up it'll still run.
> mov ax,ax for instance won't do a thing. We can insert that
> anywhere we wish without changing anything. The assembler will take
> care of any relative jumps and pointers but with a binary firmware,
> try to insert a byte into it (not CHANGE one, INSERT one), even
> if you know just insert a NOP somewhere - and see what happens.

Then why didn't the original programmer leave a patch space to allow
for such modifications?  Surely that could be considered part of the
'preferred form'.

John.

Re: Binary-only firmware covered by the GPL?

[John Hasler]

John Bradford writes:
> Then why didn't the original programmer leave a patch space to allow for
> such modifications?  Surely that could be considered part of the
> 'preferred form'.

It would be the 'preferred form' if and only if it's the form in which he
wrote it, patch space or no.
-- 
John Hasler
john@dhh.gt.org (John Hasler)
Dancing Horse Hill
Elmwood, WI

Re: Binary-only firmware covered by the GPL?

[John Bradford]

Quote from John Hasler <john@dhh.gt.org>:
> John Bradford writes:
> > Then why didn't the original programmer leave a patch space to allow for
> > such modifications?  Surely that could be considered part of the
> > 'preferred form'.
> 
> It would be the 'preferred form' if and only if it's the form in which he
> wrote it, patch space or no.

But does 'preferred form' == 'the form it was written in' necessarily
apply for things like assembler?  My example about leaving a patch
space wasn't really serious, I was just using it to demonstrate that
point.

John.

Re: Binary-only firmware covered by the GPL?

[Chris Cheney]

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

On Thu, Mar 25, 2004 at 11:08:03PM +0100, Adrian Bunk wrote:
> There's another issue with these files:
> 
<--  snip  -->
> 
> The GPL says that you must give someone receiving a binary the source 
> code, and it says:
>   The source code for a work means the preferred form of the work for
>   making modifications to it.
> 
> 
> This is perhaps a bit besides the main firmware discussion and IANAL, 
> but is this file really covered by the GPL?

IMHO code that can be compiled would probably be the preferred form
of the work. The source to the firmware in many cases and probably even
this one is very unlikely to be able to be compiled under Linux at all.
Also, unless the driver is written by the company producing the hardware
itself even the author will likely not have the source code to the
firmware and will only have a binary form (think reverse engineering).
IMHO a driver for a piece of hardware does not include the software that
the hardware itself is running, just the software that the primary CPU
itself is running. YMMV.

Chris

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

RE: Binary-only firmware covered by the GPL?

[David Schwartz]

> On Thu, Mar 25, 2004 at 11:08:03PM +0100, Adrian Bunk wrote:
> > There's another issue with these files:
> >
> <--  snip  -->
> >
> > The GPL says that you must give someone receiving a binary the source
> > code, and it says:
> >   The source code for a work means the preferred form of the work for
> >   making modifications to it.
> >
> >
> > This is perhaps a bit besides the main firmware discussion and IANAL,
> > but is this file really covered by the GPL?

> IMHO code that can be compiled would probably be the preferred form
> of the work.

	You are seriously arguing that the obfuscated binary of the firmware is the
preferred form of the firmware for the purpose of making modifications to
it?!

> The source to the firmware in many cases and probably even
> this one is very unlikely to be able to be compiled under Linux at all.

	What does it matter what it compiles under? The GPL is not Linux-specific.

> Also, unless the driver is written by the company producing the hardware
> itself even the author will likely not have the source code to the
> firmware and will only have a binary form (think reverse engineering).

	If you don't have the preferred form of something for the purpose of making
modifications to it, then you can't give that to people, so you *CAN'T* GPL
it. If you making an executable that derives from a GPL'd product and, for
example, lose the source code, you MAY NOT distribute the executable. You
must have the preferred form for the purpose of making modifications or you
are not able to GPL.

> IMHO a driver for a piece of hardware does not include the software that
> the hardware itself is running, just the software that the primary CPU
> itself is running. YMMV.

	But it does. This file contains the software that the hardware itself is
running. That's its sole purpose. Please tell me how you make modifications
to this file.

	DS

RE: Binary-only firmware covered by the GPL?

[John Bradford]

> 	What does it matter what it compiles under? The GPL is not Linux-specific.

Actually, it matters quite a lot.  If the firmware was written in
assembler, and assembled with a non-free, proprietary compiler, which
doesn't use standard assembley syntax, then maybe for people who are
familiar with the CPU, and refuse to use proprietrary software, the
machine code is the preferred form.

Note that the GPL refers to the preferred form for making
_modifications_, not the preferred form for writing the code from
scratch.

For example, suppose I made a simple wristwatch based on a Z80.  It's
possible that I might write the original firmware in assembley, and
assemble it on another machine, (although it's probably just as likely
that I'd use a pen and paper, assemble it by hand).  However, if I
found a bug some time later, or wanted to make any simple changes, I'd
probably just disassemble the machine code and patch it manually.

For highly embedded devices, the preferred form for making
modifications doesn't necessarily mean the form it was originally
written in.

> 	If you don't have the preferred form of something for the purpose of making
> modifications to it, then you can't give that to people, so you *CAN'T* GPL
> it.

Err, surely that only applies if your rights to the thing were
already _granted_ to you under the GPL, and the 'preferred form' has
already been established.

For example, if I write a C program, and gives you the source under
the GPL, the source is obviously the preferred form for making
modifications.

If, however, I write a C program, compile it, and put the binary and
source in to the public domain, and years later all copies of the
source have been lost, I don't see why somebody obtaining the binary,
which has been placed in the public domain, couldn't disassemble it,
read and understand it, add comments to the assembler source
explaining how it works, and place the resulting work under the GPL.

Another example - if I code something, the chances are that it won't
have any indenting, and the variable names will either be arbitrary
letters, or one or two letter abbreviations of the things they stand
for.  That is my prefered form of making modifications to my own
code.  If I then placed the code under the GPL, there is no
requirement for me to indent it, just because the majority of
developers would prefer that form for making modifications.

John.

Re: Binary-only firmware covered by the GPL?

[Eduard Bloch]

#include <hallo.h>
* David Schwartz [Thu, Mar 25 2004, 04:41:23PM]:

> > IMHO code that can be compiled would probably be the preferred form
> > of the work.
> 
> 	You are seriously arguing that the obfuscated binary of the firmware is the
> preferred form of the firmware for the purpose of making modifications to
> it?!

Yes, the driver authors PREFERS to make the changes on the C source
code, he never has to modify the firmware. Exactly what the GPL
requests, where is your problem?

Regards,
Eduard.
-- 
Der Krieg ist ein Massaker von Leuten, die sich nicht kennen, zum
Nutzen von Leuten, die sich kennen, aber nicht massakrieren.
		-- Paul Ambroise Valéry
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Binary-only firmware covered by the GPL?

[Stefan Smietanowski]

Eduard Bloch wrote:

> #include <hallo.h>
> * David Schwartz [Thu, Mar 25 2004, 04:41:23PM]:
> 
> 
>>>IMHO code that can be compiled would probably be the preferred form
>>>of the work.
>>
>>	You are seriously arguing that the obfuscated binary of the firmware is the
>>preferred form of the firmware for the purpose of making modifications to
>>it?!
> 
> 
> Yes, the driver authors PREFERS to make the changes on the C source
> code, he never has to modify the firmware. Exactly what the GPL
> requests, where is your problem?

But the firmware didn't appear out of thin air - someone wrote it
somehow. If that's using a hex editor or inside the C code doesn't
matter, but most likely they used some other language like either
C or assembly (no, not all firmware is written using assembly), and
there are cases where some are in fact written using a hex editor but
I can't remember any that has been for the last 30 or so years but
I'm sure there has been cases where there hasn't been a working
assembler.

// Stefan

Re: Binary-only firmware covered by the GPL?

[Eduard Bloch]

#include <hallo.h>
* Stefan Smietanowski [Fri, Mar 26 2004, 03:19:38PM]:

> >Yes, the driver authors PREFERS to make the changes on the C source
> >code, he never has to modify the firmware. Exactly what the GPL
> >requests, where is your problem?
> 
> But the firmware didn't appear out of thin air - someone wrote it
> somehow. If that's using a hex editor or inside the C code doesn't

The GPL does not talk about the code to create things, but code to
_modify_ things. If you never have to modify the firmware file, where is
the point?

I do not see a big difference between firmware data stored in a flash
rom inside of the hardware part and the same data loaded during the
driver initialisation. In contrary, it saves money and makes things more
flexible. You should thank your hardware manufacturer instead of
bitching about bogus things.

Regards,
Eduard.
-- 
Wenn du einen verhungernden Hund aufliest und machst ihn satt, dann
wird er dich nicht beißen. Das ist der Grundunterschied zwischen Hund
und Mensch.
		-- Mark Twain (eigl. Samuel Langhorne Clemens)
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Binary-only firmware covered by the GPL?

[Stefan Smietanowski]

Hi.

>>>Yes, the driver authors PREFERS to make the changes on the C source
>>>code, he never has to modify the firmware. Exactly what the GPL
>>>requests, where is your problem?
>>
>>But the firmware didn't appear out of thin air - someone wrote it
>>somehow. If that's using a hex editor or inside the C code doesn't
> 
> The GPL does not talk about the code to create things, but code to
> _modify_ things. If you never have to modify the firmware file, where is
> the point?

And if I feel like I _want_ to modify it? Then I should be entitled
to the preferred form to make modifications to it as is my right
under the GPL, regardless of if I a) want to b) have a need to
c) give a rat's ass about what the firmware does or does not do.
A binary blob is extremely seldom the preferred form to make
modifications to, even though some such cases do or might exist.

> I do not see a big difference between firmware data stored in a flash
> rom inside of the hardware part and the same data loaded during the
> driver initialisation. In contrary, it saves money and makes things more
> flexible. You should thank your hardware manufacturer instead of
> bitching about bogus things.

You do know that certain TV cards (using the ivtv driver) lack a rom
and needs a firmware initialized during startup just like this example.

Why am I taking this up ? Well they have specifically stated that the
firmware _may not be used without the windows driver_ even though
others have written a fully working driver that _only_ needs the
firmware from the windows driver to function under linux.

Surprised? If they put the firmware on the card (rom/flash/eeprom)
this wouldn't have happened but it did.
How exactly do you believe this makes anything more flexible for me
as an end user when it is not LEGAL for me to use the card with
linux due to the firmware issue.

Yes, some claim there IS a loophole in that the end user MAY extract
the firmware from the windows driver himself and use it together
with the (open) linux driver but IANAL. Ie use but not redistribute.

Now, just to make it perfectly clear - I am not debating wether
firmware should be GPL or not - I couldn't care less to be honest.
I am simply answering some claims that I myself find bogus.

// Stefan

Re: Binary-only firmware covered by the GPL?

[Eduard Bloch]

#include <hallo.h>
* Stefan Smietanowski [Fri, Mar 26 2004, 03:38:41PM]:

> >The GPL does not talk about the code to create things, but code to
> >_modify_ things. If you never have to modify the firmware file, where is
> >the point?
> 
> And if I feel like I _want_ to modify it? Then I should be entitled
> to the preferred form to make modifications to it as is my right
> under the GPL, regardless of if I a) want to b) have a need to
> c) give a rat's ass about what the firmware does or does not do.
> A binary blob is extremely seldom the preferred form to make
> modifications to, even though some such cases do or might exist.

Same with WAV and PNG files distributed with many GPL packages. It is
widely accepted method to distribute files that do not need modification
without their "source" (whatever source is used to create them).

> You do know that certain TV cards (using the ivtv driver) lack a rom
> and needs a firmware initialized during startup just like this example.
> 
> Why am I taking this up ? Well they have specifically stated that the
> firmware _may not be used without the windows driver_ even though
> others have written a fully working driver that _only_ needs the
> firmware from the windows driver to function under linux.

Write a firmware loader that extracts it from the Windows DLLs. Such
things happened in the past and work AFAIK quite good.

> Surprised? If they put the firmware on the card (rom/flash/eeprom)

No.

> this wouldn't have happened but it did.
> How exactly do you believe this makes anything more flexible for me
> as an end user when it is not LEGAL for me to use the card with
> linux due to the firmware issue.

Imagine, there is a bug in the firmware. Normaly, you would have to boot
windows or DOS to run a flash tool to install it into the device. Here
you just replace the DLL.

> Yes, some claim there IS a loophole in that the end user MAY extract
> the firmware from the windows driver himself and use it together
> with the (open) linux driver but IANAL. Ie use but not redistribute.

The user gets the driver CD when he buys the hardware.

Regards,
Eduard.
-- 
Ein Lehrer, Hausvater ärgert sich gerade über die wiederkommenden
Fehler am meisten, da ers als über in der Natur gegründete am
wenigsten sollte.
		-- Jean Paul (eig. Johann Paul Friedrich Richter)
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Binary-only firmware covered by the GPL?

[Stefan Smietanowski]

Hi.

>>>The GPL does not talk about the code to create things, but code to
>>>_modify_ things. If you never have to modify the firmware file, where is
>>>the point?
>>
>>And if I feel like I _want_ to modify it? Then I should be entitled
>>to the preferred form to make modifications to it as is my right
>>under the GPL, regardless of if I a) want to b) have a need to
>>c) give a rat's ass about what the firmware does or does not do.
>>A binary blob is extremely seldom the preferred form to make
>>modifications to, even though some such cases do or might exist.
> 
> Same with WAV and PNG files distributed with many GPL packages. It is
> widely accepted method to distribute files that do not need modification
> without their "source" (whatever source is used to create them).

A WAV file can altered easily using any sound program that will in fact
produce an output that would "work" as would the same apply to a PNG
file. If the result would be pretty or not is a different question
of course :)

To draw a parallel between a WAV or PNG file (a well-known standard)
to a firmware for a specific card (a closed standard) is thin.

Even though I can modify a PNG or WAV file using a hex editor it
is _NOT_ preferred form, and neither is modifying the firmware
using a hex editor, neither to me nor to the people doing the cards.

>>You do know that certain TV cards (using the ivtv driver) lack a rom
>>and needs a firmware initialized during startup just like this example.
>>
>>Why am I taking this up ? Well they have specifically stated that the
>>firmware _may not be used without the windows driver_ even though
>>others have written a fully working driver that _only_ needs the
>>firmware from the windows driver to function under linux.
> 
> Write a firmware loader that extracts it from the Windows DLLs. Such
> things happened in the past and work AFAIK quite good.

Yes, but the legality of it is questionable.

>>Surprised? If they put the firmware on the card (rom/flash/eeprom)
> 
> No.
> 
>>this wouldn't have happened but it did.
>>How exactly do you believe this makes anything more flexible for me
>>as an end user when it is not LEGAL for me to use the card with
>>linux due to the firmware issue.
> 
> Imagine, there is a bug in the firmware. Normaly, you would have to boot
> windows or DOS to run a flash tool to install it into the device. Here
> you just replace the DLL.

You mean get a new DLL and decompile it or otherwise gain access
to said firmware.

>>Yes, some claim there IS a loophole in that the end user MAY extract
>>the firmware from the windows driver himself and use it together
>>with the (open) linux driver but IANAL. Ie use but not redistribute.
> 
> The user gets the driver CD when he buys the hardware.

Some countries might call it illegal to use the contents to other
uses than  issued but a country like germany for instance would
I believe invalidate the license since it was not accepted before
purchase, so the whole thing is very iffy. Again, IANAL.

// Stefan

Re: Binary-only firmware covered by the GPL?

[Matthew Wilcox]

The reason I'm not subscribed to debian-devel is because it's full
of wankers discussing stupid pedantic points about matters they don't
understand.

Please drop linux-scsi and me from any further posts.  Thank you.

-- 
"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: Binary-only firmware covered by the GPL?

[Guy]

Please find a GPL list and continue this topic there.

Thanks.

-----Original Message-----
From: linux-scsi-owner@vger.kernel.org
[mailto:linux-scsi-owner@vger.kernel.org] On Behalf Of Stefan Smietanowski
Sent: Friday, March 26, 2004 10:03 AM
To: Eduard Bloch
Cc: David Schwartz; debian-devel@lists.debian.org;
linux-kernel@vger.kernel.org; linux-scsi@vger.kernel.org
Subject: Re: Binary-only firmware covered by the GPL?

Hi.

>>>The GPL does not talk about the code to create things, but code to
>>>_modify_ things. If you never have to modify the firmware file, where is
>>>the point?
>>
>>And if I feel like I _want_ to modify it? Then I should be entitled
>>to the preferred form to make modifications to it as is my right
>>under the GPL, regardless of if I a) want to b) have a need to
>>c) give a rat's ass about what the firmware does or does not do.
>>A binary blob is extremely seldom the preferred form to make
>>modifications to, even though some such cases do or might exist.
> 
> Same with WAV and PNG files distributed with many GPL packages. It is
> widely accepted method to distribute files that do not need modification
> without their "source" (whatever source is used to create them).

A WAV file can altered easily using any sound program that will in fact
produce an output that would "work" as would the same apply to a PNG
file. If the result would be pretty or not is a different question
of course :)

To draw a parallel between a WAV or PNG file (a well-known standard)
to a firmware for a specific card (a closed standard) is thin.

Even though I can modify a PNG or WAV file using a hex editor it
is _NOT_ preferred form, and neither is modifying the firmware
using a hex editor, neither to me nor to the people doing the cards.

>>You do know that certain TV cards (using the ivtv driver) lack a rom
>>and needs a firmware initialized during startup just like this example.
>>
>>Why am I taking this up ? Well they have specifically stated that the
>>firmware _may not be used without the windows driver_ even though
>>others have written a fully working driver that _only_ needs the
>>firmware from the windows driver to function under linux.
> 
> Write a firmware loader that extracts it from the Windows DLLs. Such
> things happened in the past and work AFAIK quite good.

Yes, but the legality of it is questionable.

>>Surprised? If they put the firmware on the card (rom/flash/eeprom)
> 
> No.
> 
>>this wouldn't have happened but it did.
>>How exactly do you believe this makes anything more flexible for me
>>as an end user when it is not LEGAL for me to use the card with
>>linux due to the firmware issue.
> 
> Imagine, there is a bug in the firmware. Normaly, you would have to boot
> windows or DOS to run a flash tool to install it into the device. Here
> you just replace the DLL.

You mean get a new DLL and decompile it or otherwise gain access
to said firmware.

>>Yes, some claim there IS a loophole in that the end user MAY extract
>>the firmware from the windows driver himself and use it together
>>with the (open) linux driver but IANAL. Ie use but not redistribute.
> 
> The user gets the driver CD when he buys the hardware.

Some countries might call it illegal to use the contents to other
uses than  issued but a country like germany for instance would
I believe invalidate the license since it was not accepted before
purchase, so the whole thing is very iffy. Again, IANAL.

// Stefan
-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Binary-only firmware covered by the GPL?

[Valdis.Kletnieks]

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

On Fri, 26 Mar 2004 15:29:17 +0100, Eduard Bloch said:

> If you never have to modify the firmware file, where is the point?

But if you never modify it...

> In contrary, it saves money and makes things more flexible. 

Why is flexibility a Good Thing?  Personally, I'd prefer it burnt into a ROM
where I can't accidentally muck it up.  Unless of course I see "flash a new
PROM image into it" as a desirable thing to be able to do...


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

Re: Binary-only firmware covered by the GPL?

[Pavel Machek]

Hi!

> >#include <hallo.h>
> >* David Schwartz [Thu, Mar 25 2004, 04:41:23PM]:
> >
> >
> >>>IMHO code that can be compiled would probably be the preferred form
> >>>of the work.
> >>
> >>	You are seriously arguing that the obfuscated binary of the 
> >>	firmware is the
> >>preferred form of the firmware for the purpose of making 
> >>modifications to
> >>it?!
> >
> >
> >Yes, the driver authors PREFERS to make the changes on the C source
> >code, he never has to modify the firmware. Exactly what the GPL
> >requests, where is your problem?
> 
> But the firmware didn't appear out of thin air - someone wrote it
> somehow. If that's using a hex editor or inside the C code doesn't
> matter, but most likely they used some other language like either
> C or assembly (no, not all firmware is written using assembly), and
> there are cases where some are in fact written using a hex editor but
> I can't remember any that has been for the last 30 or so years but
> I'm sure there has been cases where there hasn't been a working
> assembler.

If my code contains picture of human, do I have to provide his DNA, too?
				Pavel

(runs away)
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: Binary-only firmware covered by the GPL?

[Stefan Smietanowski]

Hi Pavel.

>>But the firmware didn't appear out of thin air - someone wrote it
>>somehow. If that's using a hex editor or inside the C code doesn't
>>matter, but most likely they used some other language like either
>>C or assembly (no, not all firmware is written using assembly), and
>>there are cases where some are in fact written using a hex editor but
>>I can't remember any that has been for the last 30 or so years but
>>I'm sure there has been cases where there hasn't been a working
>>assembler.
> 
> 
> If my code contains picture of human, do I have to provide his DNA, too?

No, that's where we come into the whole issue of IP.

If I have a picture of you then you can always LICENSE your IP to me,
but I don't think you NEED to license it to me :)

Unless you consider your IP to be in the public domain.

// Stefan

Re: Binary-only firmware covered by the GPL?

[Goswin von Brederlow]

Pavel Machek <pavel@suse.cz> writes:

> Hi!
> 
> If my code contains picture of human, do I have to provide his DNA, too?
> 				Pavel
> 
> (runs away)

If the picture was made with gimp and you keep an xcf of it around for
changing it (because it keeps the layers) but only ship a png (no more
layers) then your violating the GPL.

Prefered form for you would be the xcf file and not the png.

Of cause its hard to show that you do use an xcf as prefered form
without spying at you working on it so you can get away with an png.


With binary firmware is way easier to argue that the prefered form is
some kind of asm, C , forth or whatever source and not the binary.
That someone is prefering a hex editor is very unlikely.

If the driver+firmware is released as GPL (say as binary driver
containing the firmware) then the _firmware_ would be in violation of
the GPL unless source is provided or a note confirming the 3 years on
request thing is there. Either way the source of the firmware has to
be made available.

So please do get firms to release GPLed drivers with firmware included
as GPL bcause then we can sue them for the firmware source. :)

MfG
        Goswin

Re: Binary-only firmware covered by the GPL?

[Pavel Machek]

Hi!

> > If my code contains picture of human, do I have to provide his DNA, too?
> > 				Pavel
> > 
> > (runs away)
> 
> If the picture was made with gimp and you keep an xcf of it around for
> changing it (because it keeps the layers) but only ship a png (no more
> layers) then your violating the GPL.

xcf is easy, but what if it is really *photo*?

Photos are almost impossible to modify, there's no prefered form. You
can't modify a photo, you can only try to arrange similar photo, and
you need same people to make "modified" photo. This is what I was
trying to say.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]