linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Kelley <simon@thekelleys.org.uk>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Binary firmware in the kernel - licensing issues.
Date: Tue, 06 May 2003 14:28:25 +0100	[thread overview]
Message-ID: <3EB7B879.4040405@thekelleys.org.uk> (raw)
In-Reply-To: <1052219735.28796.28.camel@dhcp22.swansea.linux.org.uk>

Alan Cox wrote:
> On Maw, 2003-05-06 at 12:38, Simon Kelley wrote:
> 
>>This software is copyrighted by and is the sole property of Atmel
>>Corporation.  All rights, title, ownership, or other interests
>>in the software remain the property of Atmel Corporation.  This
>>software may only be used in accordance with the corresponding
>>license agreement.  Any un-authorized use, duplication, transmission,
>>distribution, or disclosure of this software is expressly forbidden. 
> 
> 
> So you can't distribute it at all unless there is other paperwork
> involved.

That's what it says, but I don't think it was the intention, given
that the company itself published the source under the GPL  and put them 
up on Sourceforge. What I need is the correct legalese to replace the
above which makes it legal to redistribute (easy) and to combine with
the GPL'd bulk of linux - that's the difficult bit. Once I have
said legalese I'll put it to Atmel with the message "this is what I
think you _meant_ to say."
> 
> 
>>Given the current SCO-IBM situation I don't want to be responsible for
>>introducing any legally questionable IP into the kernel tree.
>>
>>This situation must have come up before, how was it solved then?
> 
> 
> The easiest approach is to do the firmware load from userspace - which
> also keeps the driver size down and makes updating the firmware images
> easier for end users.

That has attractions, especially since there are half a dozen different
firmware images for different hardware variants, and some cards have
flash and don't need loading at all. OTOH one of the my goals is to have 
the driver just there in the kernel, and not to need extra stuff to make
it work.

My current plan is to make separate modules for each firmware image so 
that people only need to compile in/load the one they need.

> 
> (Debian as policy will rip the firmware out anyway regardless of what
> Linus does btw)

Without exception? Time to hit debian-legal, methinks.

> 
> The hotplug interface can be used to handle this.
> 

Bah, more configuration. I want it to just _work_.


So, back to the question: what license for a binary firmware blob is 
GPL-compatible?

Simon.


  reply	other threads:[~2003-05-06 13:15 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 [this message]
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
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=3EB7B879.4040405@thekelleys.org.uk \
    --to=simon@thekelleys.org.uk \
    --cc=alan@lxorguk.ukuu.org.uk \
    --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).