Debian Developers - Re: Binary-only firmware covered by the GPL?

Author

Re: Binary-only firmware covered by the GPL?

Chris Cheney

2004-03-25, 6:38 pm

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

Andrew Suffield

2004-03-25, 7:34 pm

On Thu, Mar 25, 2004 at 11:53:54PM +0100, Stefan Smietanowski wrote:
> Jeff Garzik wrote:
>
>
> Except the firmware itself is GPL in this case.

If that is the case, we cannot distribute it at all. No "should we or
shouldn't we" - it's not legal.

You cannot redistribute a binary image that is licensed under the GPL
if you have no way to provide the source for it.

--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |

Evan Prodromou

2004-03-25, 8:38 pm

>>>>> "AB" == Adrian Bunk <bunk@fs.tum.de> writes:

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

Well, is there another preferred format for the firmware? I don't know
what chip it's for, but are you sure there's some other source besides
the machine code? Maybe there just isn't any.

Also, there doesn't seem to be any obligation* on the part of the
licensor to provide source in any particularly readable or
maintainable format. Creators of Modified Versions might be under some
such obligation, but I'm not sure the original author is.

~ESP

* Legal, not moral.

--
Evan Prodromou
evan@debian.org

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

David Schwartz

2004-03-25, 8:38 pm

> On Thu, Mar 25, 2004 at 11:08:03PM +0100, Adrian Bunk wrote:
> <-- snip -->
[color=darkred]
> 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

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

John Bradford

2004-03-26, 11:20 am

> 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.

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Frank Küster

2004-03-26, 11:20 am

John Hasler <john@dhh.gt.org> schrieb:

> Chris writes:
>
> 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.

What about asking QLogic?

Regards, Frank
--=20
Frank K=FCster, Biozentrum der Univ. Basel
Abt. Biophysikalische Chemie

Eduard Bloch

2004-03-26, 11:21 am

Moin Dumitru!
Dumitru Ciobarcianu schrieb am Freitag, den 26. März 2004:

>
>
> 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 ?

IMHO yes. If not, start sueing all upstream authors distribution GPL
source without .xcf for .png files or .mid/.mod/... for .wav files,
etc.pp.

Regards,
Eduard.
--
<maxx> Aqua mach mal man brain....
<Aquariophile> maxx: schon probiert das gibts ned

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Eduard Bloch

2004-03-26, 1:42 pm

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

>
> 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, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Stefan Smietanowski

2004-03-26, 1:42 pm

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 XXX 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

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Eduard Bloch

2004-03-26, 1:42 pm

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

>
> 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 XXX 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, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Stefan Smietanowski

2004-03-26, 1:42 pm

Hi.

>
> 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.

>
> 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.

>
> No.
>
>
> 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.

>
> 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, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Matthew Wilcox

2004-03-26, 1:42 pm

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

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Adrian Bunk

2004-03-26, 1:42 pm

On Thu, Mar 25, 2004 at 07:21:14PM -0500, Evan Prodromou wrote:
>...
> Also, there doesn't seem to be any obligation* on the part of the
> licensor to provide source in any particularly readable or
> maintainable format. Creators of Modified Versions might be under some
> such obligation, but I'm not sure the original author is.

WTF does the header state a file is under the GPL when all it contains
is a binary blob without available source code?

> ~ESP
>
> * Legal, not moral.

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

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Guy

2004-03-26, 1:42 pm

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.

>
> 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.

>
> 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.

>
> No.
>
>
> 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.

>
> 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

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Gabor Gombas

2004-03-26, 1:43 pm

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
---------------------------------------------------------

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

J.D. Hood

2004-03-26, 1:43 pm

This problem affects the mwavem package too. This package contains
firmware for the 3780i DSP chip which implements a modem. (The
chip can be found in some older IBM ThinkPad laptops.) IBM published
both the 3780i driver (named "mwave"), a userspace firmware loader
and the firmware itself all under the GPL.

Let's consider these three bits of code.

The driver alone is published under the GPL, so the combination of
the kernel plus the driver is also distributable under the terms
of the GPL.

The firmware loader is published under the GPL and so can be linked
to GPL code and distributed under the terms of the GPL.

The firmware is published by IBM under the GPL. No DSP assembler
source code is provided -- just the binaries. Assuming IBM is the
original licensor, we are left to infer that the preferred form of
the firmware for making modifications is the binary as it is shipped.
If that is the whole story then the whole kit and kaboodle is GPL
and there is no problem.

Now, suppose it is the case that IBM has assembler source code for
the firmware. Is IBM allowed to refrain from publishing that along
with the binary? Well, of course. IBM can't be compelled by the
terms of its own license. But what about others' licenses? Well,
none are relevant because IBM doesn't distribute any code other than
its own.

But what about Debian? Debian _does_ distribute code other than
IBM's and so does have to abide by those other licenses. OK, which
licenses are relevant here? First, the licenses of works that
gets linked to IBM's code. Well, there aren't any -- we are talking
about self-sufficient DSP code here. Nothing in Debian could be
construed as a work "derived from" the DSP binary through linking.
Second, there are the licenses of works that get distributed along
with IBM's code. But the GPL specifically permits distribution
of non-free code along with GPL code:

In addition, mere aggregation of another work not based
on the Program with the Program (or with a work based
on the Program) on a volume of a storage or distribution
medium does not bring the other work under the scope
of this License. [GPL section 2]

Thus Debian does not violate any GPLs if it distributes the 3780i
firmware.

Distributing such firmware does violate DFSG2, though, so the
firmware really should be kept in non-free. That's where the
mwavem package is now. (I am glad, therefore, that Debian has
voted not to eliminate non-free.)

Now, suppose it is the case that IBM acquired the firmware source
code from a third party and the third party has granted IBM a
license to distribute only binaries compiled from that source code.
What then? Well, the only problem I can think of is that the third
party might have some rights over the firmware binary which would
make it illegal for IBM to distribute the binary under the GPL.
If that is the case then IBM has violated its contract with the
third party. The consequences of that I leave to the members of
the list to think through. I'll just say that if the third party
happens to be SCO then ThinkPad owners shouldn't be surprised to
hear from SCO someday.

--
Thomas Hood

________________________________________
________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Evan Prodromou

2004-03-26, 1:43 pm

>>>>> "AB" == Adrian Bunk <bunk@fs.tum.de> writes:

Me> ... Also, there doesn't seem to be any obligation* on the part
Me> of the licensor to provide source in any particularly readable
Me> or maintainable format. Creators of Modified Versions might be
Me> under some such obligation, but I'm not sure the original
Me> author is.

AB> WTF does the header state a file is under the GPL when all it
AB> contains is a binary blob without available source code?

Are you just going to keep repeating that question, or are you going
to read what anyone else writes?

1) If that's the source code the software creator is offering, how can
you say it's not GPL-able?

2) It's not a binary blob -- it's a C data structure with ASCII
representations of a big binary blob. Technically, it's the source
for the machine code, even if it's mostly unreadable source.

3) You're not sure that there's actually any non-machine code
source. It's entirely possible that they program the chip directly
in machine code -- no assembly, no high-level language.

I'd say: find out if there's some other "source" that should be used
here. If not, that's just going to have to do.

~ESP

--
Evan Prodromou
evan@debian.org

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Nathanael Nerode

2004-03-26, 4:34 pm

John Hasler wrote:

> Dumitru Ciobarcianu writes:
>
> Eduard Bloch writes:
>
> IMHO the term "source code" applies to software and has no useful meaning
> when applied to such things.
No, it has a useful meaning when applied to such software: "preferred form
for modification".

..wav files are often, in fact, the preferred form for modification
(hand-editing waveforms, applying noise reduction, treating the sound,
splicing, sampling, etc.) There are innumerable programs which operate
directly on .wav files.

For contrast, .mp3 files rarely are, if there's a .wav version (you always
want the full-quality .wav file instead).

If a .png image was scanned in, or drawn and saved directly as .png (they
often are) -- that's presumably the preferred form for modification. If
it's a conversion of a vector graphics file, the vector graphics file is
presumably the preferred form for modification.

I feel like I have to state the obvious over and over.

--
Make sure your vote will count.
http://www.verifiedvoting.org/

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Nathanael Nerode

2004-03-26, 4:35 pm

J.D. Hood wrote:

> This problem affects the mwavem package too. This package contains
> firmware for the 3780i DSP chip which implements a modem. (The
> chip can be found in some older IBM ThinkPad laptops.) IBM published
> both the 3780i driver (named "mwave"), a userspace firmware loader
> and the firmware itself all under the GPL.
>
> Let's consider these three bits of code.
>
> The driver alone is published under the GPL, so the combination of
> the kernel plus the driver is also distributable under the terms
> of the GPL.
>
> The firmware loader is published under the GPL and so can be linked
> to GPL code and distributed under the terms of the GPL.
>
> The firmware is published by IBM under the GPL. No DSP assembler
> source code is provided -- just the binaries. Assuming IBM is the
> original licensor, we are left to infer that the preferred form of
> the firmware for making modifications is the binary as it is shipped.
Right -- provided that they aren't, uh, "lying" about it.

Given how incredibly unlikely it is that the binary really is the preferred
form of the people at IBM, and given IBM's reasonable behavior in the past
regarding Open Source projects, someone should ask them about it, and if
they say it isn't really their preferred form, point out the licensing
problem.

> If that is the whole story then the whole kit and kaboodle is GPL
> and there is no problem.
>
> Now, suppose it is the case that IBM has assembler source code for
> the firmware. Is IBM allowed to refrain from publishing that along
> with the binary? Well, of course. IBM can't be compelled by the
> terms of its own license.
If
(1) the assembler source code is the preferred form for modification
(2) IBM doesn't make it available with the binary
Then the GPL doesn't grant *any* rights to distribute the binary, to anyone,
period. :-P So effectively, IBM would not have granted any right to
redistribute the firmware!

This is a worrisome case, because it means that Debian wouldn't legally have
a license to distribute the firmware *at* *all*, even in non-free.

Other than missing this issue, good analysis. :-)

--
Make sure your vote will count.
http://www.verifiedvoting.org/

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Nathanael Nerode

2004-03-26, 4:35 pm

Eduard Bloch wrote:

> Moin Dumitru!
> Dumitru Ciobarcianu schrieb am Freitag, den 26. M=E4rz 2004:
>=20
se it[color=darkred]
[color=darkred]
[color=darkred]
>=20
> IMHO yes. If not, start sueing all upstream authors distribution GPL
> source without .xcf for .png files
Um, many .png files are created directly in editors, not via .xcf.

> or .mid/.mod/... for .wav files,
Many .wav files are recorded directly from microphone input, or from th=
e
line-in jack from some other analog source.

What you say is true *only* if the files really were created
from .xcf/.mid/.mod files.

> etc.pp.
>=20
> Regards,
> Eduard.

--=20
Make sure your vote will count.
http://www.verifiedvoting.org/

Valdis.Kletnieks@vt.edu

2004-03-26, 5:36 pm

J.D. Hood

2004-03-26, 6:36 pm

I wrote:
> Assuming IBM is the
> original licensor, we are left to infer that the preferred form of
> the firmware for making modifications is the binary as it is shipped.

Nathanael Nerode wrote:
> Right -- provided that they aren't, uh, "lying" about it.

I don't see why IBM has to reveal anything about where the binaries
came from. IBM publishes the binaries under the GPL and thereby
tells others that they can distribute derived works under the GPL
provided they include "the" preferred form for modification. What
'the preferred form for modification' means has always been one of
the difficult questions about the GPL, not least because everyone
has his or her own preference. But in the present context I don't
see how it can include any form that IBM possesses but doesn't
publish. IBM can't reasonably require a licensee to furnish something
if that thing belongs to IBM and IBM chooses not to provide it or
even tell anyone that it exists.

Conclusion: Either IBM doesn't require that, or IBM is being silly
in granting permission to distribute under conditions that it causes
to be unfulfillable.

N.N. continued:
> Given how incredibly unlikely it is that the binary really is the preferred
> form of the people at IBM, and given IBM's reasonable behavior in the past
> regarding Open Source projects, someone should ask them about it, and if
> they say it isn't really their preferred form, point out the licensing
> problem.
>
> If
> (1) the assembler source code is the preferred form for modification
> (2) IBM doesn't make it available with the binary
> Then the GPL doesn't grant *any* rights to distribute the binary, to anyone,
> period. :-P So effectively, IBM would not have granted any right to
> redistribute the firmware!

That is the "IBM is being silly" interpretation. I don't think that IBM
is being silly. I think IBM doesn't intend 'preferred form for modification'
to include forms of the code that it doesn't publish.

BTW I have written to IBM a couple of times asking for clarification but
I have never received any reply.

For the reasons given above, though, I don't think it is essential to
get a clarification.

I understand the line of reasoning which leads to the conclusion that IBM
has published the mwave firmware under a license that in fact forbids
redistribution. But I hope you will still grant that the clear intent
of IBM was to allow free distribution of the firmware binary. It would
be totally absurd of IBM to publish the firmware on its website, to
declare it to be licensed under the GPL, and then to turn around and
say that IBM interprets 'preferred form for modification' in such a way
that redistribution is prohibited. If we are right in regarding that as
absurd then we are right in treating IBM's license as a license to
redistribute.

My main qualm right now is that I know absurdity is in the eye of the beholder.
--
Thomas Hood

________________________________________
________________________________
Yahoo! Messenger - Communicate instantly..."Ping"
your friends today! Download Messenger Now
http://uk.messenger.yahoo.com/download/index.html

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Hamish Moffatt

2004-03-27, 9:33 am

On Fri, Mar 26, 2004 at 07:56:41AM -0600, John Hasler wrote:
> IMHO the term "source code" applies to software and has no useful meaning
> when applied to such things.

Actually many pieces of hardware have "source code" these days.
Ultimately that code is compiled to produce ASICs (which are fixed in
operation) or FPGAs (which are typically loaded on every power-up).

FPGAs are a programmable device consisting of lots of little RAMs
and wires that connect them and programmable switches in between.

It's quite possible that some of the device firmware is actually
data to load into an FPGA. That data isn't actually executed (as in the
precise wording of the GPL) though the effect is much the same.
There is actually source code though. Disassembly isn't meaningful
in this case and reverse engineering intractable....

Hamish
--
Hamish Moffatt VK3SB <hamish@debian.org> <hamish@cloud.net.au>

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Nathanael Nerode

2004-03-27, 4:34 pm

J.D. Hood wrote:

> I wrote:
> That is the "IBM is being silly" interpretation. I don't think that IBM
> is being silly. I think IBM doesn't intend 'preferred form for
> modification' to include forms of the code that it doesn't publish.
>
> BTW I have written to IBM a couple of times asking for clarification but
> I have never received any reply.
I think this is evidence that IBM is being silly. ;-)

>
> For the reasons given above, though, I don't think it is essential to
> get a clarification.
>
> I understand the line of reasoning which leads to the conclusion that IBM
> has published the mwave firmware under a license that in fact forbids
> redistribution. But I hope you will still grant that the clear intent
> of IBM was to allow free distribution of the firmware binary.
Yes. I've just gotten very.... cautious. Maybe Debian should have some
official policy about how cautious and lawsuit-averse it is. :-)

> It would
> be totally absurd of IBM to publish the firmware on its website, to
> declare it to be licensed under the GPL, and then to turn around and
> say that IBM interprets 'preferred form for modification' in such a way
> that redistribution is prohibited. If we are right in regarding that as
> absurd then we are right in treating IBM's license as a license to
> redistribute.
>
> My main qualm right now is that I know absurdity is in the eye of the
> beholder. --
Yeah, we've seen copyright holders do absurd things before, so I generally
don't assume that they haven't done absurd things. :-P Perhaps I *should*
assume that they haven't? It just makes me... uncomfortable.

> Thomas Hood

--
Make sure your vote will count.
http://www.verifiedvoting.org/

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Pavel Machek

2004-03-30, 9:42 am

Hi!

>
> 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

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Stefan Smietanowski

2004-03-30, 9:42 am

Hi Pavel.

>
>
> 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

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Humberto Massa

2004-03-30, 10:35 am

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!
>
>
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.
[color=darkred]

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.[color=darkred]
> If my code contains picture of human, do I have to provide his DNA,
> too? Pavel
>
> (runs away)

--
best regards,M

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Henning Makholm

2004-03-30, 12:35 pm

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, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Goswin von Brederlow

2004-03-30, 1:37 pm

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

--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Scott James Remnant

2004-03-31, 5:34 am

On Tue, 2004-03-30 at 12:39, Pavel Machek wrote:

> If my code contains picture of human, do I have to provide his DNA, too?
>
If you did, I'm sure mrvn would be eager to donate some kind of buildd
not long after <g>

Scott
--
Have you ever, ever felt like this?
Had strange things happen? Are you going round the twist?

Tollef Fog Heen

2004-03-31, 6:34 am

* Scott James Remnant=20

| On Tue, 2004-03-30 at 12:39, Pavel Machek wrote:
|=20
| > If my code contains picture of human, do I have to provide his DNA, t=
oo?
|
| If you did, I'm sure mrvn would be eager to donate some kind of buildd
| not long after <g>

But would the buildd produce reprodicble results? How would concepts
like =ABclean environment=BB and such apply?

M-F-T set.

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

Pavel Machek

2004-04-02, 5:34 pm

Hi!

>
> 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?]

--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org