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.
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
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.
> 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.
(Debian as policy will rip the firmware out anyway regardless of what
Linus does btw)
The hotplug interface can be used to handle this.
-----Original Message-----
From: Alan Cox [mailto:[email protected]]
>
> So you can't distribute it at all unless there is other paperwork
> involved.
>
>> 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.
>
> (Debian as policy will rip the firmware out anyway regardless of what
> Linus does btw)
>
> The hotplug interface can be used to handle this.
I am writing a USB driver for a well-known vendor's USB device which
requires firmware download. The vendor is considering allowing me
to publish the driver under GPL. They will _not_ allow me to include
the binary firmware under any conditions.
So I will be loading the firmware from userspace - but the user must
obtain the firmware as a part of a larger application package.
(Complete crap IMO, but what can I do...)
PS: what would be the preferred place to load the firmware
from, if no option giving the firmware pathname is passed to the
module at load time?
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.
On Maw, 2003-05-06 at 14:28, Simon Kelley wrote:
> 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.
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.
> > The hotplug interface can be used to handle this.
> >
>
> Bah, more configuration. I want it to just _work_.
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.
> So, back to the question: what license for a binary firmware blob is
> GPL-compatible?
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
Maybe this is the sort of thing I need:
http://www.keyspan.com/support/linux/
[about half way down, under "Driver Information".
Simon.
On Maw, 2003-05-06 at 13:54, Downing, Thomas wrote:
> PS: what would be the preferred place to load the firmware
> from, if no option giving the firmware pathname is passed to the
> module at load time?
When a device appears the /sbin/hotplug scripts are called. They
could either load the firmware themselves (since the usbdevfs allows
you to talk directly to the device), or could make a call to give
the firmware to the driver (eg ioctl)
Simon Kelley wrote:
>Maybe this is the sort of thing I need:
>
>http://www.keyspan.com/support/linux/
I believe that the keyspan drivers that compile GPL-incompatible
firmware into the kernel or kernel modules are illegal. I tried
being a nice guy about it, to the point of wring a user level
firmware loader could be invoked automatically via hotplug:
http://marc.theaimsgroup.com/?l=linux-usb-devel&m=98758846106843&w=2.
You can look in the linux-usb-devel archives at about that time
for further discussion of the copyright issues.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Miplitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
On Tue, May 06, 2003 at 03:19:54PM +0300, Matti Aarnio wrote:
> On Tue, May 06, 2003 at 12:38:54PM +0100, Simon Kelley wrote:
> > 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."
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
J. Bruce Fields wrote:
> On Tue, May 06, 2003 at 03:19:54PM +0300, Matti Aarnio wrote:
>
>
>
> 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
On Tue, 6 May 2003, J. Bruce Fields wrote:
> On Tue, May 06, 2003 at 03:19:54PM +0300, Matti Aarnio wrote:
> > On Tue, May 06, 2003 at 12:38:54PM +0100, Simon Kelley wrote:
> > > 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."
>
> 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
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.
On Maw, 2003-05-06 at 16:42, Simon Kelley wrote:
> 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]
Either the GPL does or it doesn't.
> 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?
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
On Maw, 2003-05-06 at 16:48, Richard B. Johnson wrote:
> 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,
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
Alan Cox wrote:
> On Maw, 2003-05-06 at 16:42, Simon Kelley wrote:
>
>>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]
>
>
> Either the GPL does or it doesn't.
<snip>
> 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
>
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
On Wed, May 07, 2003 at 07:52:49AM +0100, Simon Kelley wrote:
> Alan Cox wrote:
> >On Maw, 2003-05-06 at 16:42, Simon Kelley wrote:
> >
> >>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]
> >
> >
> >Either the GPL does or it doesn't.
> <snip>
> >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
> >
>
> 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
--
"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
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.
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.
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).
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Miplitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
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.
I am not a lawyer, so please don't rely on this as legal advice.
I'm only explaining my layman's understanding.
Simon Kelley wrote:
>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 [...]
I don't think that should be difficult to argue. Let's see.
One objecting developer is enough for a lawsuit. If a court
find copyright infringement and that developer registered the
copyright (a form TX from the copyright office and a $35 registration
fee, if memory serves), then I believe statutory damages would be
something like $750-30k per copy (see
http://www4.law.cornell.edu/uscode/17/504.html). Theoretically,
there might be the potential for criminal prosecution of
for-profit distributors (see
http://www4.law.cornell.edu/uscode/18/2319.html).
See how easy that was easy to argue?
>, especially since at least one driver (Advansys) has
>been there, complete with its "bucket of bits" since 1.3.x days at
>least.
This is the first I've heard of it. In this case,
it appears that the copyright is GPL compatible, but it does
not appear that the GPL's requirement for the "preferred form of
the work for making modifications to it" has been satisfied
with respect to this binary blob of firmware. If the source is
not included in the kernel, I think that binary blob should be
removed and replaced with some user level facility for loading that
array. I wonder if it really is necessary to load the microcode
at all, as I would assume that there would have to be some
initial firmware loaded for the control to act as a boot
device (or can't it do that?).
>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.
There are all sorts of obscure facts that one "could have
been aware" of, but that doesn't show that one _was_ aware of them
if you're trying to argue that one implicitly agreed to something.
>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.
It's not just the copyright holders who have the legal
exposure. It would be anyone who distributes your driver.
Again, I want to emphasize that I'm not a lawyer, and I
wouldn't want anyone to rely on my incomplete and potentially
quite incorrect layman's understanding as legal advice.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Miplitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
On Wed, May 07, 2003 at 10:54:33AM +0100, 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.
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
Filip Van Raemdonck wrote:
> On Wed, May 07, 2003 at 10:54:33AM +0100, 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.
>
>
> 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)
>
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.
On Tue, 6 May 2003 12:38:54 +0100, Simon Kelley wrote:
>
> 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.
>
> 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.
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)
On Iau, 2003-05-08 at 10:44, Simon Kelley wrote:
> 4) The same hardware and firmware is unambiguously OK if the firmware
> is held in flash rather than initialised by the host.
That actually makes a difference because of who shipped it and how it
was shipped I am told
> 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.
4) Debian and in future some other vendors may well rip out all binary
firmware files.
-----Original Message-----
From: Simon Kelley [mailto:[email protected]]
[snip]
My comments apply _only_ to firmware binaries for which the vendor
has given explicit license for free redistribution with GPL code.
> 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.
These are two separate issues, and both are crucial. Four ways to
handle firmware have been discussed. 1.) firmware as data in the
module image, 2.) firmware as data in userspace image, 3.) firmware
as file loaded by module, 4.) firmware as file loaded by userspace.
The first option might be debatable (non-GPL stuff linked into GPL
module), but I think it parallels 'magic' values written to registers.
Likewise the second option might not fly, though this removes it from
the kernel, it still leaves open the question of distro's that won't
go along.
The third option (and even more so the fourth) seem to have no point at
which the GPL could apply. The firmware is now _clearly_ not linked in
any fashion with any GPL code. It's just data that the kernel or other
moves from A to B at the behest of the user. This again leaves only
the question of distro's that won't go this way.
For such distro makers: if firmware continues to become more prevalent
in devices, and the vendors are ok with redistribution, then those
distro makers lose to some extent, in the long run. To say that distro
X won't do it, so we can't is backwards.
The second half of the original point is crucial - firmware does not run
on the same CPU's 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.
The intention of the GPL is to allow redistribution _of GPL code, or
code linked to GPL code_ with source.
Makes a big difference. Hence the distinctions made above.
> 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.
That position would be a little inconsistent - as long as the code they
personally hold the copyright for was not involved. There are vendors
shipping systems that use Linux, but are shipped with non-GPL
applications. Is anyone aggrieved? (Probably, but hardliners aside...)
> Anybody want to write a better summary?
No, just some maundering nitpicking...
J?rn Engel wrote:
>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.
I think you are confusing "the preferred form of the work
for making modifications to it" (the GPL's definition of "source
code") with "documentation." In the case of poking a few values,
the preferred form for making modifications may be actually editing
the numbers directly in source code. That quite likely is the way
that all developers maintain and modify that code, even if doing so
in an effective manner requires additional documentation.
In comparison, with the binary blobs of firmware, the preferred
form of the work for making modifications is, presumably, to edit
a source file from which the binary blob can be rebuilt using an
assembler or compiler.
I am not a lawyer. Please do not use this as legal advice.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Miplitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
On Thu, 8 May 2003 08:59:52 -0700, Adam J. Richter wrote:
> J?rn Engel wrote:
> >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.
>
> I think you are confusing "the preferred form of the work
> for making modifications to it" (the GPL's definition of "source
> code") with "documentation." In the case of poking a few values,
> the preferred form for making modifications may be actually editing
> the numbers directly in source code. That quite likely is the way
> that all developers maintain and modify that code, even if doing so
> in an effective manner requires additional documentation.
>
> In comparison, with the binary blobs of firmware, the preferred
> form of the work for making modifications is, presumably, to edit
> a source file from which the binary blob can be rebuilt using an
> assembler or compiler.
What's the difference? If the code uses 0x12345670ul, but 0x12345678ul
would be correct, who is going to find the correct change without the
documentation. Maybe someone reverse engineering the meaning of those
bits. But most just accept the fact that one is better than the other
without understanding why.
And one big binary blob is better than the other. Same here.
Anyway, _should be ok_ is not _definitely legal in all countries_, so
we basically both say "see a lawyer".
J?rn
--
"Translations are and will always be problematic. They inflict violence
upon two languages." (translation from German)
Simon Kelley wrote:
>Briefly, the arguments that binary firmware which is copied into the
>hardware by the kernel is OK are these.
[...]
>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.
I don't know who supposedly "OKed" what in the above
sentence.
> 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.
I addressed this previously. The fact that nobody has
litigated this yet, does not mean that everyone accepts in.
>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.)
Just so you can never truthfully make this statment again,
for the record, I believe that the existing "firmware blobs"
in Linux that do not include source infringe Yggdrasil copyrights
on GPL-licensed kernel contributions (just as I believe they
infringe many other authors' GPL-licensed contributions).
>The arguments against allowing binary firmware are these.
Let's be clear: embedding binary firmware into a GPL'ed
work is fine if the firmware contains no additional restriction
beyond the GPL and complete source code for the firmware is
included. I think you understand this much already, but I just
want to be clear about it.
>1) The GPL is unclear on this point.
All three distribution options in section 3 of the version 2
of the GNU General Public License require distribution or arrangments
for distribution "machine-readable source code", and defines
"source code" as "the preferred form of the work for making
modifications to it." That seems pretty clear to me.
By the way, I believe the FSF has already said that
the GPL prohibits these binary blobs without source code, and
I am confident that they would testify or submit a friend of
the court brief to that effect if necessary (and I believe it
would be usable by the court for interpreting a contract under
"the four corners rule").
>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.
A problem with legal grey areas is that they create an
environment where vendors are made to choose between breaking the
law and perhaps being caught years later or going out of business
(because all the customers preferred less and less legal vendors).
So vendors may need to litigate GPL infractions more often and earlier
to avoid the "competition for the most illegal" dilemma, even
nobody in no individually actually feels that "aggrieved" in an
emotional sense.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Miplitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
J?rn Engel wrote:
>On Thu, 8 May 2003 08:59:52 -0700, Adam J. Richter wrote:
>> J?rn Engel wrote:
>> >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.
>>
>> I think you are confusing "the preferred form of the work
>> for making modifications to it" (the GPL's definition of "source
>> code") with "documentation." In the case of poking a few values,
>> the preferred form for making modifications may be actually editing
>> the numbers directly in source code. That quite likely is the way
>> that all developers maintain and modify that code, even if doing so
>> in an effective manner requires additional documentation.
>>
>> In comparison, with the binary blobs of firmware, the preferred
>> form of the work for making modifications is, presumably, to edit
>> a source file from which the binary blob can be rebuilt using an
>> assembler or compiler.
>What's the difference? If the code uses 0x12345670ul, but 0x12345678ul
>would be correct, who is going to find the correct change without the
>documentation. Maybe someone reverse engineering the meaning of those
>bits. But most just accept the fact that one is better than the other
>without understanding why.
I agree that documentation would be extremely useful in this
case and that distributing documentation shares a lot of the social
benefits of distributing source code, but the GPL does not require
shipping all forms of documentation, but it does require shipping
source code. Maybe you think that a future version of the GPL
should require that. The pros and cons of the discussion would
be interesting, but it is irrelevant to the question of what
version 2 (the version we are discussing) of the GNU General Public
License says. GPL v2 only requires distribution of "the preferred
form of the work for making modifications to it." Documentation
of magic numbers is often a separate work, often not even a
machine readable work.
>And one big binary blob is better than the other. Same here.
"better" is a question for what you think the license
should be, not a question of the meaing of the current license.
The current license does not say "you must do whatever is better."
>Anyway, _should be ok_ is not _definitely legal in all countries_, so
>we basically both say "see a lawyer".
Although I've never heard a lawyer tell me anything was
"definitely legal in all countries", I agree with your sentiment.
I am not a lawyer. Please do not rely on this as legal advice.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Miplitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."
<snip>
>
> Let's be clear: embedding binary firmware into a GPL'ed
> work is fine if the firmware contains no additional restriction
> beyond the GPL and complete source code for the firmware is
> included. I think you understand this much already, but I just
> want to be clear about it.
> All three distribution options in section 3 of the version 2
> of the GNU General Public License require distribution or arrangments
> for distribution "machine-readable source code", and defines
> "source code" as "the preferred form of the work for making
> modifications to it." That seems pretty clear to me.
So if you've got a CPU, that you have to load the microcode into before
fully booting, you can't run linux on it natively, unless the CPU maker
provides full microcode source?
Presumably the "preferred form" clause would mean that there must
be hardware documentation too.
And when is a binary a binary, and not a string constant?
On Iau, 2003-05-08 at 19:26, [email protected] wrote:
> So if you've got a CPU, that you have to load the microcode into before
> fully booting, you can't run linux on it natively, unless the CPU maker
> provides full microcode source?
I guess it would depend on the circumstances and how its distributed
> And when is a binary a binary, and not a string constant?
When is a book a collection of words, when is it a collection of ideas,
when is it a collection of bitmaps - same question and copyright law
mostly doesn't care.
>> Let's be clear: embedding binary firmware into a GPL'ed
>> work is fine if the firmware contains no additional restriction
>> beyond the GPL and complete source code for the firmware is
>> included. I think you understand this much already, but I just
>> want to be clear about it.
>> All three distribution options in section 3 of the version 2
>> of the GNU General Public License require distribution or arrangments
>> for distribution "machine-readable source code", and defines
>> "source code" as "the preferred form of the work for making
>> modifications to it." That seems pretty clear to me.
[email protected] wrote:
>So if you've got a CPU, that you have to load the microcode into before
>fully booting, you can't run linux on it natively, unless the CPU maker
>provides full microcode source?
I don't know of any such CPU, but I imagine you could run
Linux on it natively. Just make sure that the microcode is not part
of a GPL'ed work. For example, have the boot loader load the
microcode from a separate file before booting Linux.
If the CPU can start boot Linux far enough to mount
a root file system and run some user space programs manually,
you could even have a separate user space program running under
Linux update the microcode.
>Presumably the "preferred form" clause would mean that there must
>be hardware documentation too.
No. I just expalained the differences in these two
messages:
http://marc.theaimsgroup.com/?l=linux-kernel&m=105240981525737&w=2
http://marc.theaimsgroup.com/?l=linux-kernel&m=105241295329617&w=2
>And when is a binary a binary, and not a string constant?
When the developers create the binary from an assembler
rather calculating numbers manually, then the file that they
feed to the assembler is part of the preferred form of the
work for making modifications to it.
All of the above is "in my humble opinion." Also, remember
that I am not a lawyer, so do not rely on this as legal advice.
Adam J. Richter __ ______________ 575 Oroville Road
[email protected] \ / Miplitas, California 95035
+1 408 309-6081 | g g d r a s i l United States of America
"Free Software For The Rest Of Us."