linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Kelley <simon@thekelleys.org.uk>
To: "Adam J. Richter" <adam@yggdrasil.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Binary firmware in the kernel - licensing issues.
Date: Wed, 07 May 2003 15:08:58 +0100	[thread overview]
Message-ID: <3EB9137A.8050806@thekelleys.org.uk> (raw)
In-Reply-To: <200305071159.h47BxBe04974@adam.yggdrasil.com>

Adam J. Richter wrote:
> Simon Kelley wrote:
> 
>>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.
> 
> 
> 	I am not a lawyer.  So, please do not rely on this as legal advice.
> 
> 	I think you are confusing people having a strong distaste
> for suing their fellow developers with people agreeing to something.
> Also, your theory would require explicit unanimous agreement of the
> contributors of GPL'ed kernel code if you actually want to guarantee
> anything.
> 

If many copyright holders don't agree then clearly firmware blobs
shouldn't go into the kernel. It is difficult to argue that just one is
enough for a veto, especially since at least one driver (Advansys) has
been there, complete with its "bucket of bits" since 1.3.x days at 
least. Any contributor to the kernel since then who cared could have 
been aware of that as evidence of a de-facto interpretation of the GPL
source clause as not applying to firmware in Linux.

> 	By the way, there are some additional advantages to not compiling
> in the firmware that perhaps you might not have contemplated.  Reducing
> people's perceived legal exposure would most likely help adoption of
> your driver.  Separate firmware loading also offers more upgradability
> and, therefore, maintainability and perhaps extensibility if people
> want to try firmware improvements (for example the WiFi frequencies
> available for use are different in different countries and there may
> also be different power limits or other requirements).  Finally, you
> would avoid the need to keep a copy of the firmware in unswappable
> kernel memory if your driver supports hot plugging (since a device
> could be plugged in at any time, not just at driver initialization).
> 

The technical advantages you give are not compelling for the Atmel 
driver. The driver has international roaming support built-in and the
firmware size is than 20k. In general though they may be good points.

I suggest that having a driver which "just works" without needing
extra files and configuration steps would trump minmizing legal
exposure to the Linux copyright holders, for most people in the real
world.

Cheers

Simon.






  reply	other threads:[~2003-05-07 13:56 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-05-07 11:59 Binary firmware in the kernel - licensing issues Adam J. Richter
2003-05-07 14:08 ` Simon Kelley [this message]
  -- strict thread matches above, loose matches on Subject: below --
2003-05-08 23:36 Adam J. Richter
2003-05-08 16:51 Adam J. Richter
2003-05-08 16:35 Adam J. Richter
2003-05-08 18:26 ` root
2003-05-08 22:19   ` Alan Cox
2003-05-08 15:59 Adam J. Richter
2003-05-08 16:09 ` Jörn Engel
2003-05-08 13:20 Downing, Thomas
2003-05-07 17:14 Adam J. Richter
2003-05-06 15:04 Adam J. Richter
2003-05-06 12:54 Downing, Thomas
2003-05-06 12:46 ` Alan Cox
2003-05-06 11:38 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
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

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=3EB9137A.8050806@thekelleys.org.uk \
    --to=simon@thekelleys.org.uk \
    --cc=adam@yggdrasil.com \
    --cc=linux-kernel@vger.kernel.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;
as well as URLs for NNTP newsgroup(s).