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
* (http://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
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.
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
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
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
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
[email protected] were in the public domain.
Dancing Horse Hill I waive all rights.
Elmwood, Wisconsin
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
> 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
> 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.
What does linking have to do with anything? Where not asking whether this
file *must* be shipped under the GPL. We're asking, given that is has been
placed under the GPL, what does the GPL require.
As for "another processor", another from what processor? There is just this
one file. We have here a file that is allegedly distributed under the terms
of the GPL. It is, however, obfuscated and not the preferred form for making
modifications.
DS
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
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
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
[email protected] were in the public domain.
Dancing Horse Hill I waive all rights.
Elmwood, Wisconsin
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
[email protected] (John Hasler)
Dancing Horse Hill
Elmwood, WI
> 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
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
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
[email protected] were in the public domain.
Dancing Horse Hill I waive all rights.
Elmwood, Wisconsin
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
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
> 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.
> > 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.
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
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
On 26-Mar-2004 David Schwartz wrote:
> As for "another processor", another from what processor? There is just this
> one file. We have here a file that is allegedly distributed under the terms
> of the GPL. It is, however, obfuscated and not the preferred form for making
> modifications.
It's my turn to make flames grow higher :)
And about binary data which is not executed by any processor ? Some
cards have ASIC chips that must be programmed to make the card do
something other than consuming power. That "code" is *not* a program
and it's always shipped in binary form.
--
Giuliano.
Giuliano Pochini wrote:
> On 26-Mar-2004 David Schwartz wrote:
>
>
>>As for "another processor", another from what processor? There is just this
>>one file. We have here a file that is allegedly distributed under the terms
>>of the GPL. It is, however, obfuscated and not the preferred form for making
>>modifications.
>
>
> It's my turn to make flames grow higher :)
> And about binary data which is not executed by any processor ? Some
> cards have ASIC chips that must be programmed to make the card do
> something other than consuming power. That "code" is *not* a program
> and it's always shipped in binary form.
Shipped - yes, but how is it modified (ie edited) ?
Using a special program? That's fine then. Using a hex editor? That's
also fine. Using a VHDL compiler ? Then they need to give out the VHDL
code to it I believe. But hell, what do I know, when moving over to
hardware it's uncertain how the GPL would apply, at least to me,
and of course IANAL.
// Stefan
#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
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
[email protected] (John Hasler)
Dancing Horse Hill
Elmwood, WI
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
#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)
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
#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)
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
I think the real question is this: if this binary blob is not GPL, then how
can it be in the kernel? It should be pulled out and put in a separate file,
which can be loaded with the firmware mechanism.
If it is firmware, then would it be legal to reverse engineer the assembler,
assuming one can find the instruction set for the chip?
Matt
_________________________________________________________________
Get rid of annoying pop-up ads with the new MSN Toolbar ? FREE!
http://toolbar.msn.com/go/onm00200414ave/direct/01/
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
Matt Reuther wrote:
>I think the real question is this: if this binary blob is not GPL, then how
>can it be in the kernel? It should be pulled out and put in a separate file,
>which can be loaded with the firmware mechanism.
Correct.
>If it is firmware, then would it be legal to reverse engineer the assembler,
>assuming one can find the instruction set for the chip?
That depends on your local jurisdiction.
--
Matthew Garrett | [email protected]
Please find a GPL list and continue this topic there.
Thanks.
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Stefan Smietanowski
Sent: Friday, March 26, 2004 10:03 AM
To: Eduard Bloch
Cc: David Schwartz; [email protected];
[email protected]; [email protected]
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
On Fri, Mar 26, 2004 at 04:03:05PM +0100, Stefan Smietanowski wrote:
> 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 are mixing the preferred form with the editor. If you do not have
the GIMP (or other similar tool) then you _do_ have to edit the PNG file
with a hex editor, but the binary PNG file is still the preferred form
for editing.
If a firmware author uses a proprietary tool that reads the binary
firmware image, let's the user edit it, and again writes out a binary
image, then that binary image _is_ the preferred form simply because no
other form exists. And it is completely irrelevant if the proprietaty
editor represented the firmware image on the screen in a high-level
language or as assembler code or as graphics or as anything else.
So unless you can _prove_ that the author of the firmware image does
indeed use some other form as the source of the image (guessing is not
enough), this whole thread is meaningless.
Gabor
--
---------------------------------------------------------
MTA SZTAKI Computer and Automation Research Institute
Hungarian Academy of Sciences
---------------------------------------------------------
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...
> Matt Reuther wrote:
> >I think the real question is this: if this binary blob is not
> >GPL, then how
> >can it be in the kernel? It should be pulled out and put in a
> >separate file,
> >which can be loaded with the firmware mechanism.
> Correct.
> >If it is firmware, then would it be legal to reverse engineer
> >the assembler,
> >assuming one can find the instruction set for the chip?
> That depends on your local jurisdiction.
IANAL, but I believe you have the absolute right to reverse engineer and
modify it. All of that engineering and modification would be to/from a file
that was placed under the GPL, and the GPL contains no restrictions against
reverse engineering or modification. It specifically prohibits the
imposition of any addional restrictions upon those who receive the file as
far as how they can use, modify, and distribute it.
There might be a question if the reverse engineering exceeds the scope of
the file itself. For example, if you reverse engineer the hardware that the
firmware runs on or if the firmware runs on a custom processor and you have
to reverse engineer the processor itself. But I certainly think you can
reverse engineer the contents of the firmware file (disassemble it) and make
modified versions of that firmware with absolute impunity.
DS
Quote from John Hasler <[email protected]>:
> 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.
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
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
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
Scripsit Humberto Massa <[email protected]>
> 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?"
Pavel Machek <[email protected]> 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
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?]