Binary firmware in the kernel - licensing issues.

I'm currently working on the drivers for Atmel PCMCIA and PCI wireless adaptors with the aim of getting up to snuff for inclusion in the mainline kernel.

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.

BUT. These things need firmware loaded, at least the ones without built-in flash. The Atmel drivers come with binary firmware as header files full of hex, with the following notice.

------------------------------------------------------------------
Copyright (c) 1999-2000 by Atmel Corporation

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.

This Copyright notice may not be removed or modified without prior written consent of Atmel Corporation.

Atmel Corporation, Inc. reserves the right to modify this software without notice.

Atmel Corporation.
2325 Orchard Parkway [email protected]
San Jose, CA 95131 http://www.atmel.com
------------------------------------------------------------------

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?

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?

Cheers,

Simon.

So you can't distribute it at all unless there is other paperwork involved.

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.

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

The hotplug interface can be used to handle this.

.....

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.

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.

/Matti Aarnio

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."

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.

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

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.

Maybe this is the sort of thing I need:

http://www.keyspan.com/support/linux/

[about half way down, under "Driver Information".

Simon.

Unless the firmware itself includes full source code under the GPL yes. There are rumblings in other places about doing the same because the licensing issues are not clear otherwise.

For the setup its a case of the existing hotplug scripts being updated which isnt hard and for 2.5 this is currently being kicked around for the general cases.

Try a lawyer, a good one with lots of experience in intellectual property law in the US and EU. linux-kernel only thinks its qualified as a lawyer 8)

Alan

It's not Atmel whose permission you need to do this, it's the other kernel developers whose permission you need. By releasing their code under the GPL, the people who hold copyright on all the other kernel code have essentially given you permission to modify and redistribute their code as long as you make source available for the resulting work.

The question is whether adding this binary blob to the linux kernel violates the license that the kernel developers gave you. I can't see how Amtel saying it's OK would make it so.

--Bruce Fields

There are two issues. Atmel don't currently give me permission to
distribute their firmware so I need them to fix that. The keyspan wording is one way to do it.

Then, as you say, I need to know if the kernel developers have given permission to distribute a work which combines Atmel's blob with their source.[1]

If this was code which was linked into the kernel the answer would clearly be no. Since it is not linked to the kernel, and doesn't even run on the same processor as the kernel, the answer is not clear, at least to me.

Maybe we need Linus to pronounce, or RMS. Existing practice has several drivers with firmware blobs[2]. What is the status of those? Am I asking Questions Which Should Not Be Asked?

Simon.

[1] and though I'm not (yet) a holder of copyright on part of the Linux kernel source, I do distribute other software under the GPL so these are my rights we're talking about, too.

[2] Acenic, Advansys, Typhoon, Dgrs etc etc

I don't see anybody sending the contents of the PALs, ASICs, and other components on your motherboard. Modern machines have all those bits loaded upon power-up. Before the power is applied, the components aren't even connected. The same is true for many disk drive boards, screen-card boards, etc. The manufacturer will supply a bucket of bits, plus instructions on how to load them into the hardware. I don't see how this violates either the wording or the spirit of GPL. The manufacturer certainly isn't going to supply the "source", which is the output of a graphical program where the Engineers spent the last year designing the board. If this kind of BS continues, Linux will go the way of the Hippie culture.

Cheers,
Dick Johnson
Penguin : Linux version 2.4.20 on an i686 machine (797.90 BogoMips). Why is the government concerned about the lunatic fringe? Think about it.

Those aren't shipped as part of the OS and that seems to be the big question if you talk to legally qualified people about this matter

Either the GPL does or it doesn't.

Na.. firmware stuff needs sorting out, but from the conversations I've seem so far that involved people with a knowledge of law thats by putting the firmware out of the kernel entirely

<snip>

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. If he pronounces firmware blobs OK and doesn't get sued by a significant number of the other copyright
holders then the decision is set. Similary it's unlikely that anyone
else would risk it if Linus says it is not OK.

Same procedure as that which caused Linus's "Binary-only modules can link to the kernel without voilating the GPL" pronouncement.

Linus?

Cheers,

Simon

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

"Perhaps Debian is concerned more about technical excellence rather than
 ease of use by breaking software. In the former we may excel. In the
 latter we have to concede the field to Microsoft. Guess where I want
 to go today?"
	-- Manoj Srivastava

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.

It's been pointed out repeatedly that there are a few which disagree with this; they just did not feel compelled (yet?) into action over it.

But there is an important difference in binary modules vs binary firmware blobs.

In the modules case, it's the binary modules provider which exposes himself to legal issues.
In the firmware case, you are exposing the kernel itself to IP liability issues. Do you really want that? (Think SCO)

Regards,

Filip

"There is a 90% chance that this message was written when the author's been
 up longer than he should have. Please disregard any senseless drivel."
	-- Chris Armstrong

For the avoidance of doubt and in the particular case of the Atmel drivers which started this discussion, I have absolutely _no_ intention of exposing the kernel to outside IP liability issues. I have already contacted Atmel and I am talking to them about changing their licence to explicily allow redistribution as part of Linux; if
I do not get a satifactory outcome from the those discussions I will not include firmware with the driver.

I don't however anticipate getting Atmel to release the _source_ to their firmware so this still leaves the issue of the source-distribution clause in the GPL and if it applies in this case. The consequences of making a wrong call on that are to violate the GPL license conditions of each contribution to the kernel and therefore the copyright of each copyright holder on a portion of the Linux kernel.

Briefly, the arguments that binary firmware which is copied into the hardware by the kernel is OK are these.

1) The GPL is unclear on this point.
2) The firmware is not linked with the kernel code and not executed by the same processor as the kernel.
3) Not allowing binary firmware leads to technical decisions which would not be made in the absence of prohibition.
4) The same hardware and firmware is unambiguously OK if the firmware is held in flash rather than initialised by the host.
5) There are current examples in the kernel of drivers with source-free binary firmware blobs going back at least to version 1.3. This means that someone might have considered this before and OKed it. It also means that anyone who added code to the kernel since 1.3 had evidence that for Linux the interpration of this GPL grey area was to allow binary firmware. It is difficult to a contributor to turn around now and claim copyright infrigement by distributing their work with binary firmware when the kernel already had binary firmware in it when their contribution was first made.
6) AFAIK nobody has claimed that the existing firmware blobs in Linux violate their copyright on GPL-licensed kernel contributions and fairly certainly nobody has pressed this in law. (Since if they had it would be well-known.)

The arguments against allowing binary firmware are these.

1) The GPL is unclear on this point.
2) The intention of the GPL is to allow redistribution only with source.
3) Some contributors to the kernel might want their work distributed only with all source, including firmware source. These people would contend that their copyright had been violated and would feel aggrieved or sue for lots of money.

Anybody want to write a better summary?

Simon.

After some thoughts, this appears to be related to NDA processor documentation not included in the kernel source.

For the kernel or the main CPU, the driver firmware is just data. The same, as the magic 0x12345678ul that gets written to some register because [can't tell, NDA]. In both cases, magic data gets written somewhere and afterwards, things just work.

So binary code that doesn't get executed on the main CPU *should* be ok, but whether the lawyers would agree, I have no idea.

Jörn

"Translations are and will always be problematic. They inflict violence 
upon two languages." (translation from German)

That actually makes a difference because of who shipped it and how it was shipped I am told

4) Debian and in future some other vendors may well rip out all binary firmware files.