Date: Tue, 6 May 2003 15:19:54 +0300
From: Matti Aarnio <matti.aarnio@zmailer.org>
To: Simon Kelley <simon@thekelleys.org.uk>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Binary firmware in the kernel - licensing issues.
Message-ID: <20030506121954.GO24892@mea-ext.zmailer.org>
References: <3EB79ECE.4010709@thekelleys.org.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3EB79ECE.4010709@thekelleys.org.uk>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2691
Lines: 61

On Tue, May 06, 2003 at 12:38:54PM +0100, Simon Kelley wrote:
> I'm working from source drivers released by Atmel themselves last
> year under the GPL so there are no problems with the code - each
> source file from Atmel has a GPL notice at the top.
.....
> It isn't clear what the license agreement referred to in the above
> actually is, but I don't think it's reasonable to just assume it's the
> GPL and shove these files into the kernel as-is.
> 
> I shall contact Atmel for advice and clarification but my question for
> the list is, what should I ask them to do? It's unlikely that they will
> release the source to the firmware and even if they did I wouldn't want
> firmware source  in the kernel tree since the kernel-build toolchain
> won't be enough to build the firmware. What permissions do they have to
> give to make including this stuff legal and compatible with the rest of
> the kernel?

Adding a phrase like:  "This firmware binary block is intended to be
used in BSD/GPL licensed driver"   would definitely clarify it.
Possibly adding:
  "Source code/further explanations for this binary block
   are available at file FFFF.F / are not available."

Being able to understand some binary blob would be nice, but being
able to modify and compile it isn't necessary, IMO.  Most important,
of course, is to be able to use the thing.  CPU type independently
most preferrably.

> 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?

There are drivers with binary-only firmwares, and drivers with
firmware sources.

E.g.:  drivers/scsi/qlogic*_asm.c    vs.   drivers/scsi/aic7xxx/

People can quite freely produce drivers which have magic binary blobs
in them.     Also   drivers/net/e100/e100_ucode.h  contains such.

What Linux coders frown upon is having host CPU executed code in
obfuscated binary blobs (a'la NVIDIA case),  but as more and more
peripherals have processors themselves, and need microcode downloads,
at least I can accept there being binary blobs, if the host code
is all in pure source format.

Sometimes explaining some "why I poke XYZ into ABC register" isn't
all that important, as long as it is well compartementalized, and
things around it in general kernal can be altered to suite new
style of doing some deep things.

> Cheers,
> Simon.

/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/