From: "David Schwartz" <davids@webmaster.com>
To: Matthew Wilcox <willy@debian.org>
Cc: Jeff Garzik <jgarzik@pobox.com>, Adrian Bunk <bunk@fs.tum.de>,
239952@bugs.debian.org, debian-devel@lists.debian.org,
linux-kernel@vger.kernel.org, linux-scsi@vger.kernel.org
Subject: RE: Binary-only firmware covered by the GPL?
Date: Thu, 25 Mar 2004 18:06:37 -0800 [thread overview]
Message-ID: <MDEHLPKNGKAHNMBLJOLKAEFILEAA.davids@webmaster.com> (raw)
In-Reply-To: <81ptb0wh45.wl@omega.webmasters.gr.jp>
> 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
next prev parent reply other threads:[~2004-03-26 2:07 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1B6Izr-0002Ai-00@r063144.stusta.swh.mhn.de>
[not found] ` <20040325082949.GA3376@gondor.apana.org.au>
2004-03-25 22:08 ` Binary-only firmware covered by the GPL? Adrian Bunk
2004-03-25 22:31 ` Jeff Garzik
2004-03-25 22:47 ` Adrian Bunk
2004-03-25 22:53 ` Bug#239952: " Stefan Smietanowski
2004-03-26 0:33 ` John Hasler
2004-03-26 0:17 ` David Woodhouse
2004-03-26 1:30 ` John Hasler
2004-03-26 8:50 ` Stefan Smietanowski
2004-03-26 9:43 ` Bug#239952: " Dumitru Ciobarcianu
2004-03-26 10:14 ` Stefan Smietanowski
2004-03-26 0:33 ` Bug#239952: " Matthew Wilcox
2004-03-26 1:07 ` GOTO Masanori
2004-03-26 1:39 ` John Hasler
2004-03-26 2:06 ` David Schwartz [this message]
2004-03-26 2:59 ` Chris Cheney
2004-03-26 3:23 ` John Hasler
2004-03-26 8:53 ` Stefan Smietanowski
2004-03-26 9:12 ` John Bradford
2004-03-26 13:59 ` John Hasler
2004-03-27 9:19 ` John Bradford
2004-03-25 22:54 ` Chris Cheney
2004-03-26 0:41 ` David Schwartz
2004-03-26 9:09 ` John Bradford
2004-03-26 13:16 ` Eduard Bloch
2004-03-26 14:19 ` Stefan Smietanowski
2004-03-26 14:29 ` Eduard Bloch
2004-03-26 14:38 ` Stefan Smietanowski
2004-03-26 14:55 ` Eduard Bloch
2004-03-26 15:03 ` Stefan Smietanowski
2004-03-26 15:10 ` Matthew Wilcox
2004-03-26 15:22 ` Guy
2004-03-26 21:57 ` Valdis.Kletnieks
2004-03-30 11:39 ` Pavel Machek
2004-03-30 14:02 ` Stefan Smietanowski
2004-03-30 18:11 ` Goswin von Brederlow
2004-04-02 20:53 ` Pavel Machek
[not found] <8RnZwD.A.91B.qHYaAB@murphy>
2004-03-30 14:57 ` Humberto Massa
2004-03-30 16:51 ` Henning Makholm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=MDEHLPKNGKAHNMBLJOLKAEFILEAA.davids@webmaster.com \
--to=davids@webmaster.com \
--cc=239952@bugs.debian.org \
--cc=bunk@fs.tum.de \
--cc=debian-devel@lists.debian.org \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=willy@debian.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox