public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Chris Cheney <ccheney@cheney.cx>
To: David Schwartz <davids@webmaster.com>
Cc: Matthew Wilcox <willy@debian.org>,
	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 20:59:09 -0600	[thread overview]
Message-ID: <20040326025909.GY9248@cheney.cx> (raw)
In-Reply-To: <MDEHLPKNGKAHNMBLJOLKAEFILEAA.davids@webmaster.com>

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

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

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

Chris

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

  reply	other threads:[~2004-03-26  3:00 UTC|newest]

Thread overview: 45+ 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       ` 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           ` Dumitru Ciobarcianu
2004-03-26 10:14             ` Stefan Smietanowski
2004-03-26  0:33       ` Matthew Wilcox
2004-03-26  1:07         ` GOTO Masanori
2004-03-26  1:39           ` John Hasler
2004-03-26  2:06           ` David Schwartz
2004-03-26  2:59             ` Chris Cheney [this message]
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-26  0:41       ` David Schwartz
2004-03-26 11:20         ` Giuliano Pochini
2004-03-26 11:55           ` Stefan Smietanowski
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 15:53                     ` Gabor Gombas
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
2004-03-26 15:04 Matt Reuther
2004-03-26 15:20 ` Matthew Garrett
2004-03-26 22:10   ` David Schwartz
     [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=20040326025909.GY9248@cheney.cx \
    --to=ccheney@cheney.cx \
    --cc=239952@bugs.debian.org \
    --cc=bunk@fs.tum.de \
    --cc=davids@webmaster.com \
    --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