public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Simon Kelley <simon@thekelleys.org.uk>
To: Filip Van Raemdonck <mechanix@debian.org>
Cc: Simon Kelley <srk@thekelleys.org.uk>,
	Alan Cox <alan@lxorguk.ukuu.org.uk>,
	"J. Bruce Fields" <bfields@fieldses.org>,
	linux-kernel@vger.kernel.org, torvalds@transmeta.com
Subject: Re: Binary firmware in the kernel - licensing issues.
Date: Wed, 07 May 2003 10:54:33 +0100	[thread overview]
Message-ID: <3EB8D7D9.7070304@thekelleys.org.uk> (raw)
In-Reply-To: <20030507090700.GD25251@debian>

Filip Van Raemdonck wrote:
> On Wed, May 07, 2003 at 07:52:49AM +0100, Simon Kelley wrote:

>>
>>Either the GPL allows this or it doesn't or maybe it is just not clear.
>>If it is in fact silent or ambiguous on the issue then Linus is a much 
>>more useful resource than Lawyers.
> 
> 
> No he isn't.
> 
> Others are (re)distributing his kernels, whether heavily patched or not.
> When he OKs it while lawyers say it's not, it's getting close to or
> completely impossible for those others to include the drivers in the
> kernel they redistribute without putting themselves at legal risk.
> Effectively making it impossible for those people or organizations to
> support running the kernels they distribute on the hardware which needs
> that firmware.
> 
> While I agree that it is these others own responsibility to make sure
> they are not doing anything illegal, Linus' approval contrary to legal
> advise would create a situation where there is hardware which has drivers,
> but noone can legally redistribute them. This is just as bad as having no
> drivers at all.
> (Actually, it's worse. Think about the amount of bitching that happens
> about distributions not including Nvidia drivers, decss libraries or mp3
> players. And you go try explain to aunt Tillie why RH can't include driver
> XYZ for her fizzie-whizzie USB gadget while Linus does)
> 
> Sure, Linus will also be putting himself at risk in the above situation,
> but that's his own call to make. Question yourself whether it's more
> likely for Linus to get sued over it or, say, RedHat to get sued.
> (Hmm, I wonder about the liability in the above case of kernel.org
> mirrors)
> 
> 
> Regards,
> 
> Filip
> 

I think you are reading more into my invocation if Linus than I 
intended. I am _not_ saying that Linus can bless inclusion of any IP
into the linux kernel and make it legally all-right. The situation I am
considering is the inclusion of binary firmware in a driver: the problem
is that the kernel has many copyright holders, all of who gave 
permission for the creation of derivative works under the conditions set
forth in the GPL. It may be that the GPL is silent or inconclusive about
wether binary firmware is permissable, so we don't know if those
copyright holders gave permission for binary firmware blobs or not.

Now Linus could say "I consider that the kernel copyright holders 
did/didn't give permission to combine  their work with firmware blobs" 
and I contend that practically all the copyright holders would go along
with that judgement, just as they went along with Linus's judgement
about linking binary-only modules with their work.

Of course it is up to Linus to decide if the GPL really is ambiguous
and if he wants to be arbiter in this case and if he wants to expend 
some of his extensive brownie point collection setting policy and if
the answer if "binary firmware OK" or "binary firmware not OK".

I don't think the community has a right for Linus to decide, but I do
think it can ask him if he would. (and since Linus makes
decisions on what goes into the kernel, he is forced to decide in
the end when he receives patches.)

Simon.



  reply	other threads:[~2003-05-07  9:42 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-06 11:38 Binary firmware in the kernel - licensing issues Simon Kelley
2003-05-06 11:15 ` Alan Cox
2003-05-06 13:28   ` Simon Kelley
2003-05-06 12:44     ` Alan Cox
2003-05-06 13:42   ` Simon Kelley
2003-05-06 12:19 ` Matti Aarnio
2003-05-06 15:16   ` J. Bruce Fields
2003-05-06 15:42     ` Simon Kelley
2003-05-06 15:21       ` Alan Cox
2003-05-07  6:52         ` Simon Kelley
2003-05-07  9:07           ` Filip Van Raemdonck
2003-05-07  9:54             ` Simon Kelley [this message]
2003-05-08  8:01               ` Filip Van Raemdonck
2003-05-08  9:44                 ` Simon Kelley
2003-05-08 10:56                   ` Alan Cox
2003-05-06 15:48     ` Richard B. Johnson
2003-05-06 15:19       ` Alan Cox
2003-05-08 10:20 ` Jörn Engel
  -- strict thread matches above, loose matches on Subject: below --
2003-05-06 12:54 Downing, Thomas
2003-05-06 12:46 ` Alan Cox
2003-05-06 15:04 Adam J. Richter
2003-05-07 11:59 Adam J. Richter
2003-05-07 14:08 ` Simon Kelley
2003-05-07 17:14 Adam J. Richter
2003-05-08 13:20 Downing, Thomas
2003-05-08 15:59 Adam J. Richter
2003-05-08 16:09 ` Jörn Engel
2003-05-08 16:35 Adam J. Richter
2003-05-08 18:26 ` root
2003-05-08 22:19   ` Alan Cox
2003-05-08 16:51 Adam J. Richter
2003-05-08 23:36 Adam J. Richter

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=3EB8D7D9.7070304@thekelleys.org.uk \
    --to=simon@thekelleys.org.uk \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=bfields@fieldses.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mechanix@debian.org \
    --cc=srk@thekelleys.org.uk \
    --cc=torvalds@transmeta.com \
    /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