Hello,
<quick sumary>
Current linux kernel source hold undistributable non-free firmware blobs, and
to consider them as mere agregation, a clear licence statement from the
copyright holders of said non-free firmware blobls is needed, read below for
details.
</quick sumary>
Please keep everyone in the CC, as not everyone reads debian-legal or LKML.
Some kernel modules present in the kernel sources as distributed from
ftp.kernel.org present some non-free binary only firmware that gets uploaded
in the target chip by the controler. tg3, qla2xxx, acenix and a couple of
others are example of such modules with non-free firmware blobs.
This is no major problem per see, since, as discussed in this thread :
http://lists.debian.org/debian-legal/2005/03/msg00283.html
It is obvious in this context that the non-free firmware constitute a mere
aggregation and not an act of linking with the rest of the kernel. This is at
least the consensus that debian has reached with input from the debian-legal
lists, and what we will stand by this.
Naturally even if debian has come to the conclusion that these non-free
firmware blobs are not a violation of the rest of the kernel GPL licence, it
still doesn't make these non-free firmware blobs free software, and thus they
and the drivers which contain it will be removed from debian/main, and put
into the non-free section of our archive.
Now, these non-free firmware are distributed in the same file as the rest of
the module which uses it. This is still ok since it constitute agregation on
a same distribution media, where the distribution media is the file in this
case.
But these files, as seen in the tg3.c case, have no special mention of the
firmware in the file header, nor are they distinguished in any way from the
rest of the content of that file, which places them de facto under the GPL,
since.
Accordying to the GPL, we thus needs the source files for this non-free
firmware, which is not available, and thus makes the files undistributable.
Even if we would consider these firmware as separate and not covered by the
de-facto GPLing of the files in question, we still would have no licence
allowing us to distribute those non-free firmware blobs, and thus we have
again no right to distribute them as part of the kernel.
The clean solution is to have a small notice in the header of those files or
in the toplevel COPYING file, excluding those firmware blobs from the general
GPLing of the files, and have a small comment inside the files to identify the
firmware blobs as such and again excluding them from the GPL, and possibly a
toplevel listing of all the files wich have such problems.
This is an easy fix, and i believe even those who held the above analysis as
non-sense or whatever will agree that this is something that should be done.
The real problem being that nobody except the copyright holder of those
firmware blobs is legally allowed to make said modification, and thus i bring
this issue to everyone's attention, for comment and feedback, before trying to
reach the copyright holders of those individual firmware blobs asking them to
clarify the situation. I believe many of those read this list anyway, so would
be able to fix the issue or comment on it without further proding needed.
In hopes of quick resolution of these murky legalese issues nobody is really
fond of,
Friendly,
Sven Luther
On Mon, 2005-04-04 at 12:09 +0200, Sven Luther wrote:
please take this discussion elsewhere. Also please never cc three such
lists on the same posting, there is absolutely no point in doing that.
On Mon, Apr 04, 2005 at 12:21:05PM +0200, Arjan van de Ven wrote:
> On Mon, 2005-04-04 at 12:09 +0200, Sven Luther wrote:
>
> please take this discussion elsewhere. Also please never cc three such
Ok, can you please point to me where is the place it should be taken off ? I
suppose you mean LKML ?
> lists on the same posting, there is absolutely no point in doing that.
We already had this discussion on debian-legal and debian-kernel, so i
included them for documentation purpose, so people there can follow the
discussion even if they don't follow LKML which is rather high volume. As the
discussion already was hold there, i don't believe you will see many comments
from them.
So, i posted to LKML directly, as i believe that it is where this needs to be
solved, as only the copyright holders can fix this licencing problem, and
currently the kernels distributed from ftp.kernel.org are not legally
distributable.
Friendly,
Sven Luther
Sven Luther writes:
> Hello,
>
> <quick sumary>
> Current linux kernel source hold undistributable non-free firmware blobs, and
> to consider them as mere agregation, a clear licence statement from the
> copyright holders of said non-free firmware blobls is needed, read below for
> details.
> </quick sumary>
>
> Please keep everyone in the CC, as not everyone reads debian-legal or LKML.
This question comes up every four or five months. You might have even
been the last one to raise this question on one or more of the mailing
lists you cc'ed. Please, go check the list archives for the previous
(lengthy and multiple) discussions about this topic.
Michael Poole
On Mon, Apr 04, 2005 at 09:26:58AM -0400, Michael Poole wrote:
> Sven Luther writes:
>
> > Hello,
> >
> > <quick sumary>
> > Current linux kernel source hold undistributable non-free firmware blobs, and
> > to consider them as mere agregation, a clear licence statement from the
> > copyright holders of said non-free firmware blobls is needed, read below for
> > details.
> > </quick sumary>
> >
> > Please keep everyone in the CC, as not everyone reads debian-legal or LKML.
>
> This question comes up every four or five months. You might have even
> been the last one to raise this question on one or more of the mailing
> lists you cc'ed. Please, go check the list archives for the previous
> (lengthy and multiple) discussions about this topic.
Sure, i raised this the last time, and it was discussed on debian-legal and
debian-kernel, and since nobody objected, and many where in accord with my
arguments in that thread i linked in the parent post, i believe consensus was
reached. This is basically the position debian has, and work has already been
started to move some of the affected modules in a separate package, which will
be distributed from non-free.
This is just the followup on said discussion, involving the larger LKML
audience, in order to get this fixed for good. As said, it is just a mere
technicality to get out of the muddy situation, all the people having
contributed source-less firmware blobs, need to give us (us being debian, but
also all the linux kernel community) either the source if they persist in
distributing the code under the GPL, or a clear distribution licence for these
firmware blobs, and clearly identificate them as not covered by the GPL that
the file they come in is.
Discussing legal issues is all cool and nice for those that appreciates such
sport, but it doesn't really make sense if it is not applied to acts later on.
Friendly,
Sven Luther
On Mon, Apr 04, 2005 at 04:16:47PM +0200, Sven Luther wrote:
> This is just the followup on said discussion, involving the larger LKML
> audience, in order to get this fixed for good. As said, it is just a mere
> technicality to get out of the muddy situation, all the people having
> contributed source-less firmware blobs, need to give us (us being debian, but
> also all the linux kernel community) either the source if they persist in
> distributing the code under the GPL, or a clear distribution licence for these
> firmware blobs, and clearly identificate them as not covered by the GPL that
> the file they come in is.
What if we don't want to do so? I know I personally posted a solution
for this _5_ years ago in debian-legal, and have yet to receive a
patch...
> Discussing legal issues is all cool and nice for those that appreciates such
> sport, but it doesn't really make sense if it is not applied to acts later on.
Then let's see some acts. We (lkml) are not the ones with the percieved
problem, or the ones discussing it.
bleah.
greg k-h
On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
> On Mon, Apr 04, 2005 at 04:16:47PM +0200, Sven Luther wrote:
> > This is just the followup on said discussion, involving the larger LKML
> > audience, in order to get this fixed for good. As said, it is just a mere
> > technicality to get out of the muddy situation, all the people having
> > contributed source-less firmware blobs, need to give us (us being debian, but
> > also all the linux kernel community) either the source if they persist in
> > distributing the code under the GPL, or a clear distribution licence for these
> > firmware blobs, and clearly identificate them as not covered by the GPL that
> > the file they come in is.
>
> What if we don't want to do so?
You mean, you as copyright holder are not willing to mark the firmware blobs
as not covered by the GPL, then it is simple, the firmware blob in question is
covered by the GPL, and since it lacks source, the whole lot is
non-distributable, and any contributor to the linux kernel can sue
ftp.kernel.org or whoever else is distributing the kernel code. I don't know
if users are able to sue you under the GPL for failing to provide the source
code though.
Seriously, it is just a couple of lines of comments on top of the file, who in
his right mind would object to fixing this issue ?
> I know I personally posted a solution for this _5_ years ago in debian-legal,
> and have yet to receive a patch...
Well, maybe, but *I* was not there 5 years ago, indeed i believe i didn't even
was remotely connected to the kernel folks inside debian back then, nor even
heard of debian-legal, so i would much like to hear of your proposal, care to
give me a hint about the name of the thread it was in or something ?
> > Discussing legal issues is all cool and nice for those that appreciates such
> > sport, but it doesn't really make sense if it is not applied to acts later on.
>
> Then let's see some acts. We (lkml) are not the ones with the percieved
> problem, or the ones discussing it.
Well, it is currently a violation of the GPL to distribute those firmware
blobs without clearly saying that they are not covered by the GPL. What is the
harm that comes by doing that ? All the other dubious points have been set
aside by the discussion on the thread you probably didn't read.
Right now, the licencing information is only present in the toplevel COPYRIGHT
file, which is mostly the GPL (excluding user programs :), and since things
like tg3.c which contain such non-free firmware blobs don't say anything else
about the copyright of them, they de-facto fall under the toplevel COPYRIGHT,
including their firmware blobs which lack sources.
All i am asking is that *the copyright holders* of said firmware blobs put a
little comment on top of the files in question saying, all this driver is
GPLed, except the firmware blobs, and we give redistribution rights to said
firmware blobs.
The mention of acts was for the folk at debian-legal who like speaking a lot
in circle and not bring anything forward, which your mention of patches above
confirms :)
Friendly,
Sven Luther
On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
> On Mon, Apr 04, 2005 at 04:16:47PM +0200, Sven Luther wrote:
> > This is just the followup on said discussion, involving the larger LKML
> > audience, in order to get this fixed for good. As said, it is just a mere
> > technicality to get out of the muddy situation, all the people having
> > contributed source-less firmware blobs, need to give us (us being debian, but
> > also all the linux kernel community) either the source if they persist in
> > distributing the code under the GPL, or a clear distribution licence for these
> > firmware blobs, and clearly identificate them as not covered by the GPL that
> > the file they come in is.
>
> What if we don't want to do so? I know I personally posted a solution
> for this _5_ years ago in debian-legal, and have yet to receive a
> patch...
Mmm, probably that 2001 discussion about the keyspan firmware, right ?
http://lists.debian.org/debian-legal/2001/04/msg00145.html
Can you summarize the conclusion of the thread, or what you did get from it,
please ?
Friendly,
Sven Luther
On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
> Then let's see some acts. We (lkml) are not the ones with the percieved
> problem, or the ones discussing it.
Actually, there are some legitimate problems with some of the files in
the Linux source base. Last time this came up, the Acenic firmware was
mentioned:
http://lists.debian.org/debian-legal/2004/12/msg00078.html
Seems to me that situation is still not resolved.
--
"Next the statesmen will invent cheap lies, putting the blame upon
the nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and refuse
to examine any refutations of them; and thus he will by and by convince
himself that the war is just, and will thank God for the better sleep
he enjoys after this process of grotesque self-deception." -- Mark Twain
On Apr 04, Greg KH <[email protected]> wrote:
> What if we don't want to do so? I know I personally posted a solution
Then probably the extremists in Debian will manage to kill your driver,
like they did with tg3 and others.
This sucks, yes.
--
ciao,
Marco (@debian.org)
On Mon, 2005-04-04 at 20:21 +0200, Sven Luther wrote:
> On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
> > Then let's see some acts. We (lkml) are not the ones with the percieved
> > problem, or the ones discussing it.
[...]
> All i am asking is that *the copyright holders* of said firmware blobs put a
> little comment on top of the files in question saying, all this driver is
> GPLed, except the firmware blobs, and we give redistribution rights to said
> firmware blobs.
I think what Greg may have meant[0] was that if it bothers you, then you
should act by contacting the copyright holders privately yourself in
each case that you come across and asking them if you may add a little
comment etc, and then submit patches once you have their agreement.
Ian.
[0] if I may be so bold as to put words into his mouth.
--
Ian Campbell
Hiccuping & trembling into the WASTE DUMPS of New Jersey like some
drunken CABBAGE PATCH DOLL, coughing in line at FIORUCCI'S!!
On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> Mmm, probably that 2001 discussion about the keyspan firmware, right ?
>
> http://lists.debian.org/debian-legal/2001/04/msg00145.html
>
> Can you summarize the conclusion of the thread, or what you did get from it,
> please ?
That people didn't like the inclusion of firmware, I posted how you can
fix it by moving it outside of the kernel, and asked for patches.
None have come.
So I refuse to listen to talk about this, as obviously, no one cares
enough about this to actually fix the issue.
People drag this up about once a year, so you are just following the
trend...
This is my last reply to this thread, unless it contains code.
greg k-h
On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote:
> On Apr 04, Greg KH <[email protected]> wrote:
>
> > What if we don't want to do so? I know I personally posted a solution
> Then probably the extremists in Debian will manage to kill your driver,
> like they did with tg3 and others.
Their loss, not mine.
greg k-h
On Mon, Apr 04, 2005 at 08:12:48PM +0100, Ian Campbell wrote:
> On Mon, 2005-04-04 at 20:21 +0200, Sven Luther wrote:
> > On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
> > > Then let's see some acts. We (lkml) are not the ones with the percieved
> > > problem, or the ones discussing it.
>
> [...]
>
> > All i am asking is that *the copyright holders* of said firmware blobs put a
> > little comment on top of the files in question saying, all this driver is
> > GPLed, except the firmware blobs, and we give redistribution rights to said
> > firmware blobs.
>
> I think what Greg may have meant[0] was that if it bothers you, then you
> should act by contacting the copyright holders privately yourself in
> each case that you come across and asking them if you may add a little
> comment etc, and then submit patches once you have their agreement.
Yeah, that is step 3, i mailed LKML, because maybe you would have some useful
coment, or some of you who wrote said code may have contacts or something with
the copyright holders, or some other insight. I also didn't want this to cause
a problem if i blundered in some tense relationship or whatever.
For example, the tg3 driver says :
* tg3.c: Broadcom Tigon3 ethernet driver.
*
* Copyright (C) 2001, 2002, 2003, 2004 David S. Miller ([email protected])
* Copyright (C) 2001, 2002, 2003 Jeff Garzik ([email protected])
* Copyright (C) 2004 Sun Microsystems Inc.
*
* Firmware is:
* Copyright (C) 2000-2003 Broadcom Corporation.
There is no contact for either sun or broadcom, but i believe that Jeff or
David may know where this firmware blob may (or not) come from.
Friendly,
Sven Luther
On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote:
> On Apr 04, Greg KH <[email protected]> wrote:
>
> > What if we don't want to do so? I know I personally posted a solution
> Then probably the extremists in Debian will manage to kill your driver,
> like they did with tg3 and others.
And as they are doing with e.g. the complete gcc documentation.
No documentation for the C compiler (not even a documentation of the
options) will be neither fun for the users of Debian nor for the Debian
maintainers - but it's the future of Debian...
The Debian Social Contract says:
Our Priorities are Our Users and Free Software
The next "editorial changes" to your social contract might remove the
"Our Users and"...
Seriously:
There might be real problems with non-distributable firmware, but the
known extremist position of Debian on such issues produces negative
emotions if something like this comes from Debian.
> This sucks, yes.
Agreed.
> ciao,
> Marco (@debian.org)
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> >
> > http://lists.debian.org/debian-legal/2001/04/msg00145.html
> >
> > Can you summarize the conclusion of the thread, or what you did get from it,
> > please ?
>
> That people didn't like the inclusion of firmware, I posted how you can
> fix it by moving it outside of the kernel, and asked for patches.
Yeah, that is a solution to it, and i also deplore that none has done the job
to make it loadable from userland. For now, debian is satisfied by moving the
whole modules involved to non-free, and this has already happened in part.
> None have come.
>
> So I refuse to listen to talk about this, as obviously, no one cares
> enough about this to actually fix the issue.
Well, i disagree with the above analysis. The problem is not so much that the
firmware violate the GPL, as it constitutes mere agregation, but that the
actual copyright statement of the files containing the firmware blobs place
them de-facto under the GPL, which i doubt is what was intented originally,
don't you think.
And *I* do care about this issue, and will follow up this issue with mails to
the individual copyright holders of the file, to clarify the situation.
> People drag this up about once a year, so you are just following the
> trend...
Nope, i am aiming to clarify this issue with regard to the debian kernel, so
that we may be clear with ourselves, and actually ship something which is not
of dubious legal standing, and that we could get sued over for GPL violation.
> This is my last reply to this thread, unless it contains code.
Ok, but i hope that not only code, but patches clarifying the legal situation
will make you happy.
Friendly,
Sven Luther
On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote:
> On Apr 04, Greg KH <[email protected]> wrote:
>
> > What if we don't want to do so? I know I personally posted a solution
> Then probably the extremists in Debian will manage to kill your driver,
> like they did with tg3 and others.
Nope, they were simply moved to non-free, as it should. I believe the package
is waiting for NEW processing, but i also believe that the dubious copyright
assignement will not allow the ftp-masters to let it pass into the archive,
since it *IS* a GPL violation, and thus i am doing this in order to solve that
problem.
> This sucks, yes.
Not really. Once the, post-sarge, transition is done, you just will have to
load the non-free .udeb from the non-free d-i archive, or install the module
package from non-free, and you won't even notice.
Sarge kernels are messed beyond recognition in this anyway, but they are
freezed so ...
Friendly,
Sven Luther
Matthew Wilcox wrote:
> On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
>
>>Then let's see some acts. We (lkml) are not the ones with the percieved
>>problem, or the ones discussing it.
>
>
> Actually, there are some legitimate problems with some of the files in
> the Linux source base. Last time this came up, the Acenic firmware was
> mentioned:
>
> http://lists.debian.org/debian-legal/2004/12/msg00078.html
>
> Seems to me that situation is still not resolved.
And it looks like no one cares enough to make the effort to resolve this...
I would love an open source acenic firmware.
Jeff
On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote:
> On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > >
> > > http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > >
> > > Can you summarize the conclusion of the thread, or what you did get from it,
> > > please ?
> >
> > That people didn't like the inclusion of firmware, I posted how you can
> > fix it by moving it outside of the kernel, and asked for patches.
>
> Yeah, that is a solution to it, and i also deplore that none has done the job
> to make it loadable from userland. For now, debian is satisfied by moving the
> whole modules involved to non-free, and this has already happened in part.
Does this imply your installer will use these non-free modules?
If the driver for the controller your harddisk is behind is not used by
the installer you could simply remove these modules instead of moving
them to non-free.
> > None have come.
> >
> > So I refuse to listen to talk about this, as obviously, no one cares
> > enough about this to actually fix the issue.
>
> Well, i disagree with the above analysis. The problem is not so much that the
> firmware violate the GPL, as it constitutes mere agregation, but that the
> actual copyright statement of the files containing the firmware blobs place
> them de-facto under the GPL, which i doubt is what was intented originally,
> don't you think.
>
> And *I* do care about this issue, and will follow up this issue with mails to
> the individual copyright holders of the file, to clarify the situation.
>
> > People drag this up about once a year, so you are just following the
> > trend...
>
> Nope, i am aiming to clarify this issue with regard to the debian kernel, so
> that we may be clear with ourselves, and actually ship something which is not
> of dubious legal standing, and that we could get sued over for GPL violation.
>...
If it was a GPL violation, it wasn't enough to contact only the small
subset of copyright holders that worked on this specific file since
this file might be compiled statically into the GPL'ed kernel.
> Friendly,
>
> Sven Luther
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Ian> I think what Greg may have meant[0] was that if it bothers
Ian> you, then you should act by contacting the copyright holders
Ian> privately yourself in each case that you come across and
Ian> asking them if you may add a little comment etc, and then
Ian> submit patches once you have their agreement.
Perhaps another solution would be for someone who has received a
supposedly GPLed Linux kernel from, say, SuSE, to contact SuSE and ask
for the source code to things such as
static u32 tg3FwText[(TG3_FW_TEXT_LEN / sizeof(u32)) + 1] = {
0x00000000, 0x10000003, 0x00000000, 0x0000000d, 0x0000000d, 0x3c1d0800,
0x37bd3ffc, 0x03a0f021, 0x3c100800, 0x26100000, 0x0e000018, 0x00000000,
0x0000000d, 0x3c1d0800, 0x37bd3ffc, 0x03a0f021, 0x3c100800, 0x26100034,
0x0e00021c, 0x00000000, 0x0000000d, 0x00000000, 0x00000000, 0x00000000,
0x27bdffe0, 0x3c1cc000, 0xafbf0018, 0xaf80680c, 0x0e00004c, 0x241b2105,
/* ... */
in drivers/net/tg3.c. (tg3.c does not contain any license information
at all, and therefore falls under the kernel's GPLv2 license, right?)
- R.
On Mon, Apr 04, 2005 at 09:58:30PM +0200, Adrian Bunk wrote:
> On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote:
> > On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> > > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > > > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > > >
> > > > http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > > >
> > > > Can you summarize the conclusion of the thread, or what you did get from it,
> > > > please ?
> > >
> > > That people didn't like the inclusion of firmware, I posted how you can
> > > fix it by moving it outside of the kernel, and asked for patches.
> >
> > Yeah, that is a solution to it, and i also deplore that none has done the job
> > to make it loadable from userland. For now, debian is satisfied by moving the
> > whole modules involved to non-free, and this has already happened in part.
>
>
> Does this imply your installer will use these non-free modules?
The installer already has provision for loading additional .udebs from floppy
or net, not sure about other media, and we don't build yet non-free d-i images
with those non-free modules builtin, but it could be arranged. This is
post-sarge issues though, and we still have some time to solve them.
> If the driver for the controller your harddisk is behind is not used by
> the installer you could simply remove these modules instead of moving
> them to non-free.
yeah, the problem is a whole bunch of people have tg3 network cards it seem :)
> > Nope, i am aiming to clarify this issue with regard to the debian kernel, so
> > that we may be clear with ourselves, and actually ship something which is not
> > of dubious legal standing, and that we could get sued over for GPL violation.
> >...
>
>
> If it was a GPL violation, it wasn't enough to contact only the small
> subset of copyright holders that worked on this specific file since
> this file might be compiled statically into the GPL'ed kernel.
That is not a problem, since even if the firmware is built into the same
executable as the rest of the kernel code, it still constitutes only mere
agregation, where the kernel is the distribution media, in the GPL sense.
Please read the mail i linked too in the original mail for detailed
argumentation of this.
The only problem to it constituting mere agregation is that the firmware blob
is not clearly identified as such in the tg3.c file (for example), and that
there is no licencing condition allowing their distribution apart the GPL,
which these firmware blobs where evidently not meant to be put under.
Friendly,
Sven Luther
On Mon, Apr 04, 2005 at 03:55:55PM -0400, Jeff Garzik wrote:
> Matthew Wilcox wrote:
> >On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
> >
> >>Then let's see some acts. We (lkml) are not the ones with the percieved
> >>problem, or the ones discussing it.
> >
> >
> >Actually, there are some legitimate problems with some of the files in
> >the Linux source base. Last time this came up, the Acenic firmware was
> >mentioned:
> >
> >http://lists.debian.org/debian-legal/2004/12/msg00078.html
> >
> >Seems to me that situation is still not resolved.
>
> And it looks like no one cares enough to make the effort to resolve this...
>
> I would love an open source acenic firmware.
Yep, but in the meantime, let's clearly mark said firmware as
not-covered-by-the-GPL. In the acenic case it seems to be even easier, as the
firmware is in a separate acenic_firmware.h file, and it just needs to have
the proper licencing statement added, saying that it is not covered by the
GPL, and then giving the information under what licence it is being
distributed.
Jeff, since your name was found in the tg3.c case, and you seem to care about
this too, what is your take on this proposal ?
Friendly,
Sven Luther
Sven Luther wrote:
> On Mon, Apr 04, 2005 at 03:55:55PM -0400, Jeff Garzik wrote:
>
>>Matthew Wilcox wrote:
>>
>>>On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
>>>
>>>
>>>>Then let's see some acts. We (lkml) are not the ones with the percieved
>>>>problem, or the ones discussing it.
>>>
>>>
>>>Actually, there are some legitimate problems with some of the files in
>>>the Linux source base. Last time this came up, the Acenic firmware was
>>>mentioned:
>>>
>>>http://lists.debian.org/debian-legal/2004/12/msg00078.html
>>>
>>>Seems to me that situation is still not resolved.
>>
>>And it looks like no one cares enough to make the effort to resolve this...
>>
>>I would love an open source acenic firmware.
>
>
> Yep, but in the meantime, let's clearly mark said firmware as
> not-covered-by-the-GPL. In the acenic case it seems to be even easier, as the
> firmware is in a separate acenic_firmware.h file, and it just needs to have
> the proper licencing statement added, saying that it is not covered by the
> GPL, and then giving the information under what licence it is being
> distributed.
Who has meaningfully contacted Alteon (probably "Neterion" now) about
this? What is the progress of that request?
> Jeff, since your name was found in the tg3.c case, and you seem to care about
> this too, what is your take on this proposal ?
>
> Friendly,
Bluntly, Debian is being a pain in the ass ;-)
There will always be non-free firmware to deal with, for key hardware.
Jeff
On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote:
>
> Nope, i am aiming to clarify this issue with regard to the debian kernel, so
> that we may be clear with ourselves, and actually ship something which is not
> of dubious legal standing, and that we could get sued over for GPL violation.
>
You know, the fact that Red Hat, SuSE, Ubuntu, and pretty much all
other commercial distributions have not been worried about getting
sued for this alleged GPL'ed violation makes it a lot harder for me
(and others, I'm sure) take Debian's concerns seriously.
The problem may be that because Debian is purely a non-profit, and so
it can't clearly balance the costs and benefits of trying trying to
avoid every single possible risks where someone might decide to file a
lawsuit. Anytime you do *anything* you risk the possibility of a
lawsuit, and if you allow the laywers to take over your business
decisions, the natural avoid-risks-all-costs bias of lawyers are such
that it will either drive a company out of business, or drive a
non-profit distribution into irrelevance.....
If Debian wants to be this fanatical, then let those Debian developers
who care do all of the work to make this happen, and stop bothering
LKML. And if it continues to remain the case that a user will have to
manually edit /etc/apt/sources.lists (using vi!) to include a
reference to non-free in order to install Debian on a system that
requires the tg3 device driver, then I will have to tell users who ask
me that they would be better off using some other distribution which
actually cares about their needs.
- Ted
On Mon, Apr 04, 2005 at 10:23:08PM +0200, Sven Luther wrote:
> On Mon, Apr 04, 2005 at 09:58:30PM +0200, Adrian Bunk wrote:
> > On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote:
> > > On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> > > > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > > > > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > > > >
> > > > > http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > > > >
> > > > > Can you summarize the conclusion of the thread, or what you did get from it,
> > > > > please ?
> > > >
> > > > That people didn't like the inclusion of firmware, I posted how you can
> > > > fix it by moving it outside of the kernel, and asked for patches.
> > >
> > > Yeah, that is a solution to it, and i also deplore that none has done the job
> > > to make it loadable from userland. For now, debian is satisfied by moving the
> > > whole modules involved to non-free, and this has already happened in part.
> >
> >
> > Does this imply your installer will use these non-free modules?
>
> The installer already has provision for loading additional .udebs from floppy
> or net, not sure about other media, and we don't build yet non-free d-i images
> with those non-free modules builtin, but it could be arranged. This is
> post-sarge issues though, and we still have some time to solve them.
>
> > If the driver for the controller your harddisk is behind is not used by
> > the installer you could simply remove these modules instead of moving
> > them to non-free.
>
> yeah, the problem is a whole bunch of people have tg3 network cards it seem :)
I was more thinking about SCSI controllers, but tg3 is also interesting.
Additional non-free d-i images will for sure be required, or several
hardware setups might make installation of Debian impossible without
bootstrapping through a different OS or distribution.
> > > Nope, i am aiming to clarify this issue with regard to the debian kernel, so
> > > that we may be clear with ourselves, and actually ship something which is not
> > > of dubious legal standing, and that we could get sued over for GPL violation.
> > >...
> >
> >
> > If it was a GPL violation, it wasn't enough to contact only the small
> > subset of copyright holders that worked on this specific file since
> > this file might be compiled statically into the GPL'ed kernel.
>
> That is not a problem, since even if the firmware is built into the same
> executable as the rest of the kernel code, it still constitutes only mere
> agregation, where the kernel is the distribution media, in the GPL sense.
> Please read the mail i linked too in the original mail for detailed
> argumentation of this.
>
> The only problem to it constituting mere agregation is that the firmware blob
> is not clearly identified as such in the tg3.c file (for example), and that
> there is no licencing condition allowing their distribution apart the GPL,
> which these firmware blobs where evidently not meant to be put under.
This is one possible legal interpretation of "mere aggregation".
Whether judges in all jurisdictions of the world follow this
interpretation or an interpretation of the GPL in one direction or
another is the more interesting question.
> Friendly,
>
> Sven Luther
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Mon, Apr 04, 2005 at 11:05:03PM +0200, Adrian Bunk wrote:
> On Mon, Apr 04, 2005 at 10:23:08PM +0200, Sven Luther wrote:
> > On Mon, Apr 04, 2005 at 09:58:30PM +0200, Adrian Bunk wrote:
> > > On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote:
> > > > On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> > > > > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > > > > > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > > > > >
> > > > > > http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > > > > >
> > > > > > Can you summarize the conclusion of the thread, or what you did get from it,
> > > > > > please ?
> > > > >
> > > > > That people didn't like the inclusion of firmware, I posted how you can
> > > > > fix it by moving it outside of the kernel, and asked for patches.
> > > >
> > > > Yeah, that is a solution to it, and i also deplore that none has done the job
> > > > to make it loadable from userland. For now, debian is satisfied by moving the
> > > > whole modules involved to non-free, and this has already happened in part.
> > >
> > >
> > > Does this imply your installer will use these non-free modules?
> >
> > The installer already has provision for loading additional .udebs from floppy
> > or net, not sure about other media, and we don't build yet non-free d-i images
> > with those non-free modules builtin, but it could be arranged. This is
> > post-sarge issues though, and we still have some time to solve them.
> >
> > > If the driver for the controller your harddisk is behind is not used by
> > > the installer you could simply remove these modules instead of moving
> > > them to non-free.
> >
> > yeah, the problem is a whole bunch of people have tg3 network cards it seem :)
>
>
> I was more thinking about SCSI controllers, but tg3 is also interesting.
>
> Additional non-free d-i images will for sure be required, or several
> hardware setups might make installation of Debian impossible without
> bootstrapping through a different OS or distribution.
Well, you only need one free way to get access to external media, non-free d-i
simply add a bunch of non-free .udebs to the initrd.
> > > > Nope, i am aiming to clarify this issue with regard to the debian kernel, so
> > > > that we may be clear with ourselves, and actually ship something which is not
> > > > of dubious legal standing, and that we could get sued over for GPL violation.
> > > >...
> > >
> > >
> > > If it was a GPL violation, it wasn't enough to contact only the small
> > > subset of copyright holders that worked on this specific file since
> > > this file might be compiled statically into the GPL'ed kernel.
> >
> > That is not a problem, since even if the firmware is built into the same
> > executable as the rest of the kernel code, it still constitutes only mere
> > agregation, where the kernel is the distribution media, in the GPL sense.
> > Please read the mail i linked too in the original mail for detailed
> > argumentation of this.
> >
> > The only problem to it constituting mere agregation is that the firmware blob
> > is not clearly identified as such in the tg3.c file (for example), and that
> > there is no licencing condition allowing their distribution apart the GPL,
> > which these firmware blobs where evidently not meant to be put under.
>
>
> This is one possible legal interpretation of "mere aggregation".
>
> Whether judges in all jurisdictions of the world follow this
> interpretation or an interpretation of the GPL in one direction or
> another is the more interesting question.
This is also hinted at by the FSF FAQ, and a verbatim interpretation of the
actual GPL text. And you can proof by asburd that it has to be so, or you
start facing no end of troubles :)
The thread i linked, which is rather short, has some more legalese
explanations (not by me :), if you are interested.
Friendly,
Sven Luther
On Mon, Apr 04, 2005 at 04:55:27PM -0400, Theodore Ts'o wrote:
> On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote:
> >
> > Nope, i am aiming to clarify this issue with regard to the debian kernel, so
> > that we may be clear with ourselves, and actually ship something which is not
> > of dubious legal standing, and that we could get sued over for GPL violation.
> >
>
> You know, the fact that Red Hat, SuSE, Ubuntu, and pretty much all
> other commercial distributions have not been worried about getting
> sued for this alleged GPL'ed violation makes it a lot harder for me
> (and others, I'm sure) take Debian's concerns seriously.
They probably didn't care :)
> The problem may be that because Debian is purely a non-profit, and so
> it can't clearly balance the costs and benefits of trying trying to
> avoid every single possible risks where someone might decide to file a
> lawsuit. Anytime you do *anything* you risk the possibility of a
> lawsuit, and if you allow the laywers to take over your business
> decisions, the natural avoid-risks-all-costs bias of lawyers are such
> that it will either drive a company out of business, or drive a
> non-profit distribution into irrelevance.....
Yes, the problem is indeed that we don't have a legal department which can
counter sue, and we are present in a much more widespread area than other
companies you cited above.
And ubuntu has those driver in their non-free equivalent also.
> If Debian wants to be this fanatical, then let those Debian developers
> who care do all of the work to make this happen, and stop bothering
> LKML. And if it continues to remain the case that a user will have to
> manually edit /etc/apt/sources.lists (using vi!) to include a
> reference to non-free in order to install Debian on a system that
> requires the tg3 device driver, then I will have to tell users who ask
> me that they would be better off using some other distribution which
> actually cares about their needs.
I don't get this, and you threat me as fanatic. I am only saying that the
tg3.c and other file are under the GPL, and that the firmware included in it
is *NOT* intented to be under the GPL, so why not say it explicitly ?
Friendly,
Sven Luther
On Mon, Apr 04, 2005 at 04:47:36PM -0400, Jeff Garzik wrote:
> Sven Luther wrote:
> >Yep, but in the meantime, let's clearly mark said firmware as
> >not-covered-by-the-GPL. In the acenic case it seems to be even easier, as
> >the
> >firmware is in a separate acenic_firmware.h file, and it just needs to have
> >the proper licencing statement added, saying that it is not covered by the
> >GPL, and then giving the information under what licence it is being
> >distributed.
>
> Who has meaningfully contacted Alteon (probably "Neterion" now) about
> this? What is the progress of that request?
Nobody yet. I plan to do so as time allows though. But how do you respond
about the firmware blobs being declared as GPL covered in the kernel ? Who put
those firmware blobs there, and form where did they came ?
> >Jeff, since your name was found in the tg3.c case, and you seem to care
> >about
> >this too, what is your take on this proposal ?
> >
> >Friendly,
>
> Bluntly, Debian is being a pain in the ass ;-)
Thanks all the same, in this case, it is just me though, who want a clear
solution to this, and you would too, i guess, especially as it is not much
work to do it in the first place, so why is everyone making a problem of this
?
> There will always be non-free firmware to deal with, for key hardware.
Sure, but then you don't claim they are covered by the GPL as is currently the
case ? And i thought that the whole SCO affaire teached us to be more careful
about this.
It assuredly can't hurt to add a few lines of comments to tg3.c, and since it
is probably (well, 1/3 chance here) you who added said firmware to the tg3.c
file, i guess you are even well placed to at least exclude it from being
GPLed. Is this not a reasonable request ? Which should get a reasonable
answer, and not claims of being a pain in the ass, and other wild fanatical
accusations ?
Friendly,
Sven Luther
On Mon, Apr 04, 2005 at 11:24:05PM +0200, Sven Luther wrote:
> It assuredly can't hurt to add a few lines of comments to tg3.c, and since it
> is probably (well, 1/3 chance here) you who added said firmware to the tg3.c
> file, i guess you are even well placed to at least exclude it from being
> GPLed. Is this not a reasonable request ? Which should get a reasonable
> answer, and not claims of being a pain in the ass, and other wild fanatical
> accusations ?
Jeff, please ignore this last sentence, i should not have said it.
Friendly,
Sven Luther
On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> >
> > http://lists.debian.org/debian-legal/2001/04/msg00145.html
> >
> > Can you summarize the conclusion of the thread, or what you did get from it,
> > please ?
>
> That people didn't like the inclusion of firmware, I posted how you can
> fix it by moving it outside of the kernel, and asked for patches.
>
> None have come.
Didn't know you were waiting for it. How about something like the
following series of patches?
[01/04] - add simple Intel IHEX format parser to the firmware loader.
[02/04] - make the keyspan driver use request_firmware.
[03/04] - converter program used to dump the keyspan headers as IHex files.
[04/04] - result of running the previous program.
This ofcourse doesn't actually solve Debian's distribution issues since
the keyspan firmware can only be distributed as part of 'Linux or other
Open Source operating system kernel'.
> So I refuse to listen to talk about this, as obviously, no one cares
> enough about this to actually fix the issue.
I got tired of always building my own kernels on Debian just to get my
serial dongle to work since their included keyspan.ko driver is so
useless that it isn't even worth having. The only way to use it with a
Debian kernel is to have the dongle in a powered hub and first boot into
Windows or a normal kernel.org kernel to get the thing initialized.
Didn't send the patch earlier since I wanted to split off the
pre-numeration part of the driver so that after intialization we can
unload the unused parts of the driver as well as the the firmware class
module.
Jan
Adding firmware_load_ihex, to load IHEX formatted firmware images.
Signed-off-by: Jan Harkes <[email protected]>
drivers/base/firmware_class.c | 151 ++++++++++++++++++++++++++++++++++++++++++
include/linux/firmware.h | 26 +++++++
2 files changed, 177 insertions(+)
Index: linux/include/linux/firmware.h
===================================================================
--- linux.orig/include/linux/firmware.h 2005-03-29 16:32:45.000000000 -0500
+++ linux/include/linux/firmware.h 2005-03-29 16:33:11.000000000 -0500
@@ -1,12 +1,34 @@
+/*
+ * Definitions for hotplug firmware loader
+ *
+ * Copyright (C) 2003 Manuel Estrada Sainz <[email protected]>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License version
+ * 2 as published by the Free Software Foundation.
+ *
+ * 2005-03-10 Jan Harkes <[email protected]>
+ * Added parser for IHEX formatted firmware files.
+ */
+
#ifndef _LINUX_FIRMWARE_H
#define _LINUX_FIRMWARE_H
+
#include <linux/module.h>
#include <linux/types.h>
#define FIRMWARE_NAME_MAX 30
+
struct firmware {
size_t size;
u8 *data;
};
+
+struct ihex_record {
+ __u32 address;
+ __u8 len;
+ __u8 data[255];
+};
+
struct device;
int request_firmware(const struct firmware **fw, const char *name,
struct device *device);
@@ -15,6 +37,10 @@ int request_firmware_nowait(
const char *name, struct device *device, void *context,
void (*cont)(const struct firmware *fw, void *context));
+int firmware_load_ihex(const struct firmware *fw, void *context,
+ int (*load)(struct ihex_record *record, void *context));
+
void release_firmware(const struct firmware *fw);
void register_firmware(const char *name, const u8 *data, size_t size);
+
#endif
Index: linux/drivers/base/firmware_class.c
===================================================================
--- linux.orig/drivers/base/firmware_class.c 2005-03-29 16:32:45.000000000 -0500
+++ linux/drivers/base/firmware_class.c 2005-03-29 16:33:11.000000000 -0500
@@ -5,6 +5,8 @@
*
* Please see Documentation/firmware_class/ for more information.
*
+ * 2005-03-10 Jan Harkes <[email protected]>
+ * Added parser for IHEX formatted firmware files.
*/
#include <linux/device.h>
@@ -553,6 +555,153 @@ request_firmware_nowait(
return 0;
}
+#ifdef VERBOSE_MSGS
+#define dbg(msg, ...) printk(KERN_WARNING "%s: line %d: " msg, __FUNCTION__, line, ## __VA_ARGS__)
+#else
+#define dbg(msg, ...) do {} while(0)
+#endif
+
+/**
+ * nibble/hex are little helpers to parse hexadecimal numbers to a byte value
+ **/
+static __u8 nibble(__u8 n)
+{
+ if (n >= '0' && n <= '9') return n - '0';
+ else if (n >= 'A' && n <= 'F') return n - ('A' - 10);
+ else if (n >= 'a' && n <= 'f') return n - ('a' - 10);
+ return 0;
+}
+static __u8 hex(__u8 *data, __u8 *crc)
+{
+ __u8 val = (nibble(data[0]) << 4) | nibble(data[1]);
+ *crc += val;
+ return val;
+}
+
+/**
+ * firmware_load_ihex:
+ *
+ * Description:
+ * @fw is expected to contain Intel HEX formatted data.
+ *
+ * @load will be called for each record that is found in the IHEX data.
+ *
+ * @context will be passed on to @load.
+ *
+ **/
+int firmware_load_ihex(const struct firmware *fw, void *context,
+ int (*load)(struct ihex_record *record, void *context))
+{
+ struct ihex_record *record;
+ __u32 offset = 0;
+ __u8 type, crc = 0;
+ int i, j, err = 0;
+ int line = 1;
+
+ record = kmalloc(sizeof(*record), GFP_KERNEL);
+ if (!record) {
+ dbg("Allocation failed\n");
+ return -ENOMEM;
+ }
+
+ i = 0;
+next_record:
+ /* search for the start of record character */
+ while (i < fw->size) {
+ if (fw->data[i] == '\n') line++;
+ if (fw->data[i++] == ':') break;
+ }
+
+ /* Minimum record length would be about 10 characters */
+ if (i + 10 > fw->size) {
+ dbg("Can't find valid record\n");
+ err = -EINVAL;
+ goto done;
+ }
+
+ record->len = hex(fw->data + i, &crc);
+ i += 2;
+
+ /* now check if we have enough data to read everything */
+ if (i + 8 + (record->len * 2) > fw->size) {
+ dbg("Not enough data to read complete record\n");
+ err = -EINVAL;
+ goto done;
+ }
+
+ record->address = hex(fw->data + i, &crc) << 8; i += 2;
+ record->address |= hex(fw->data + i, &crc); i += 2;
+ record->address += offset;
+ type = hex(fw->data + i, &crc); i += 2;
+
+ for (j = 0; j < record->len; j++, i += 2)
+ record->data[j] = hex(fw->data + i, &crc);
+
+ /* check CRC */
+ (void)hex(fw->data + i, &crc); i += 2;
+ if (crc != 0) {
+ dbg("CRC failure\n");
+ err = -EINVAL;
+ goto done;
+ }
+
+ /* Done reading the record */
+ switch (type) {
+ case 0:
+ /* old style EOF record? */
+ if (!record->len)
+ break;
+
+ err = load(record, context);
+ if (err < 0) {
+ dbg("Firmware load failed (err %d)\n", err);
+ break;
+ }
+ goto next_record;
+
+ case 1: /* End-Of-File Record */
+ if (record->address || record->len) {
+ dbg("Bad EOF record (type 01) format\n");
+ err = -EINVAL;
+ }
+ break;
+
+ case 2: /* Extended Segment Address Record (HEX86) */
+ case 4: /* Extended Linear Address Record (HEX386) */
+ if (record->address || record->len != 2) {
+ dbg("Bad HEX86/HEX386 record (type %02X)\n", type);
+ err = -EINVAL;
+ break;
+ }
+
+ /* We shouldn't really be using the offset for HEX86 because
+ * the wraparound case is specified quite differently. */
+ offset = record->data[0] << 8 | record->data[1];
+ offset <<= (type == 2 ? 4 : 16);
+ goto next_record;
+
+ case 3: /* Start Segment Address Record */
+ case 5: /* Start Linear Address Record */
+ if (record->address || record->len != 4) {
+ dbg("Bad Start Address record (type %02X)\n", type);
+ err = -EINVAL;
+ break;
+ }
+
+ /* These records contain the CS/IP or EIP where execution
+ * starts. Don't really know what to do with them. */
+ goto next_record;
+
+ default:
+ dbg("Unknown record (type %02X)\n", type);
+ err = -EINVAL;
+ break; /* unknown record type */
+ }
+done:
+ kfree(record);
+ return err;
+}
+
static int __init
firmware_class_init(void)
{
@@ -584,3 +733,5 @@ EXPORT_SYMBOL(release_firmware);
EXPORT_SYMBOL(request_firmware);
EXPORT_SYMBOL(request_firmware_nowait);
EXPORT_SYMBOL(register_firmware);
+EXPORT_SYMBOL(firmware_load_ihex);
+
Convert the keyspan USB serial driver to use request_firmware and
firmware_load_ihex.
Signed-off-by: Jan Harkes <[email protected]>
Index: linux/drivers/usb/serial/keyspan.c
===================================================================
--- linux.orig/drivers/usb/serial/keyspan.c 2005-03-10 16:01:15.000000000 -0500
+++ linux/drivers/usb/serial/keyspan.c 2005-03-10 23:07:21.070790916 -0500
@@ -28,6 +28,9 @@
Change History
+ 2005mar10 Jan Harkes
+ Use generic request_firmware/firmware_load_ihex functions.
+
2003sep04 LPM (Keyspan) add support for new single port product USA19HS.
Improve setup message handling for all devices.
@@ -106,6 +109,7 @@
#include <linux/tty_flip.h>
#include <linux/module.h>
#include <linux/spinlock.h>
+#include <linux/firmware.h>
#include <asm/uaccess.h>
#include <linux/usb.h>
#include "usb-serial.h"
@@ -1165,13 +1169,28 @@
port->tty = NULL;
}
+static int keyspan_fw_load(struct ihex_record *record, void *arg)
+{
+ struct usb_serial *serial = (struct usb_serial *)arg;
+ int ret;
+
+ ret = ezusb_writememory(serial, record->address, record->data,
+ record->len, 0xa0);
+ if (ret < 0) {
+ dev_err(&serial->dev->dev,
+ "ezusb_writememory failed for Keyspan"
+ "firmware (%d %08X %p %d)\n",
+ ret, record->address, record->data, record->len);
+ }
+ return ret;
+}
/* download the firmware to a pre-renumeration device */
static int keyspan_fake_startup (struct usb_serial *serial)
{
int response;
- const struct ezusb_hex_record *record;
- char *fw_name;
+ char *model, fw_name[20];
+ const struct firmware *fw;
dbg("Keyspan startup version %04x product %04x",
le16_to_cpu(serial->dev->descriptor.bcdDevice),
@@ -1182,97 +1201,43 @@
return(1);
}
- /* Select firmware image on the basis of idProduct */
switch (le16_to_cpu(serial->dev->descriptor.idProduct)) {
- case keyspan_usa28_pre_product_id:
- record = &keyspan_usa28_firmware[0];
- fw_name = "USA28";
- break;
-
- case keyspan_usa28x_pre_product_id:
- record = &keyspan_usa28x_firmware[0];
- fw_name = "USA28X";
- break;
-
- case keyspan_usa28xa_pre_product_id:
- record = &keyspan_usa28xa_firmware[0];
- fw_name = "USA28XA";
- break;
-
- case keyspan_usa28xb_pre_product_id:
- record = &keyspan_usa28xb_firmware[0];
- fw_name = "USA28XB";
- break;
-
- case keyspan_usa19_pre_product_id:
- record = &keyspan_usa19_firmware[0];
- fw_name = "USA19";
- break;
-
- case keyspan_usa19qi_pre_product_id:
- record = &keyspan_usa19qi_firmware[0];
- fw_name = "USA19QI";
- break;
-
- case keyspan_mpr_pre_product_id:
- record = &keyspan_mpr_firmware[0];
- fw_name = "MPR";
- break;
-
- case keyspan_usa19qw_pre_product_id:
- record = &keyspan_usa19qw_firmware[0];
- fw_name = "USA19QI";
- break;
-
- case keyspan_usa18x_pre_product_id:
- record = &keyspan_usa18x_firmware[0];
- fw_name = "USA18X";
- break;
-
- case keyspan_usa19w_pre_product_id:
- record = &keyspan_usa19w_firmware[0];
- fw_name = "USA19W";
- break;
-
- case keyspan_usa49w_pre_product_id:
- record = &keyspan_usa49w_firmware[0];
- fw_name = "USA49W";
- break;
-
- case keyspan_usa49wlc_pre_product_id:
- record = &keyspan_usa49wlc_firmware[0];
- fw_name = "USA49WLC";
- break;
-
+ case keyspan_usa18x_pre_product_id: model = "usa18x"; break;
+ case keyspan_usa19_pre_product_id: model = "usa19"; break;
+ case keyspan_usa19qi_pre_product_id: model = "usa19qi"; break;
+ case keyspan_mpr_pre_product_id: model = "mpr"; break;
+ case keyspan_usa19qw_pre_product_id: model = "usa19qw"; break;
+ case keyspan_usa19w_pre_product_id: model = "usa19w"; break;
+ case keyspan_usa28_pre_product_id: model = "usa28"; break;
+ case keyspan_usa28x_pre_product_id: model = "usa28x"; break;
+ case keyspan_usa28xa_pre_product_id: model = "usa28xa"; break;
+ case keyspan_usa28xb_pre_product_id: model = "usa28xb"; break;
+ case keyspan_usa49w_pre_product_id: model = "usa49w"; break;
+ case keyspan_usa49wlc_pre_product_id: model = "usa49wlc"; break;
default:
- record = NULL;
- fw_name = "Unknown";
- break;
+ dev_err(&serial->dev->dev, "Unknown keyspan device (%04x).\n",
+ le16_to_cpu(serial->dev->descriptor.idProduct));
+ return(1);
}
- if (record == NULL) {
- dev_err(&serial->dev->dev, "Required keyspan firmware image (%s) unavailable.\n", fw_name);
+ sprintf(fw_name, "keyspan-%s.fw", model);
+
+ if (request_firmware(&fw, fw_name, &serial->dev->dev) != 0) {
+ dev_err(&serial->dev->dev, "Required firmware image (%s) unavailable.\n", fw_name);
return(1);
}
- dbg("Uploading Keyspan %s firmware.", fw_name);
+ dbg("Uploading Keyspan %s firmware.", model);
/* download the firmware image */
response = ezusb_set_reset(serial, 1);
- while(record->address != 0xffff) {
- response = ezusb_writememory(serial, record->address,
- (unsigned char *)record->data,
- record->data_size, 0xa0);
- if (response < 0) {
- dev_err(&serial->dev->dev, "ezusb_writememory failed for Keyspan"
- "firmware (%d %04X %p %d)\n",
- response,
- record->address, record->data, record->data_size);
- break;
- }
- record++;
- }
+ if (firmware_load_ihex(fw, serial, keyspan_fw_load))
+ dev_err(&serial->dev->dev, "Firmware %s upload failed\n",
+ fw_name);
+
+ release_firmware(fw);
+
/* bring device out of reset. Renumeration will occur in a
moment and the new device will bind to the real driver */
response = ezusb_set_reset(serial, 0);
@@ -1418,7 +1383,7 @@
(serial, d_details->outcont_endpoints[i], USB_DIR_OUT,
port, p_priv->outcont_buffer, 64,
cback->outcont_callback);
- }
+ }
}
Index: linux/drivers/usb/serial/keyspan.h
===================================================================
--- linux.orig/drivers/usb/serial/keyspan.h 2005-03-10 15:59:58.000000000 -0500
+++ linux/drivers/usb/serial/keyspan.h 2005-03-10 22:56:15.343354346 -0500
@@ -99,90 +99,6 @@
struct usb_serial_port *port,
int reset_port);
-/* Struct used for firmware - increased size of data section
- to allow Keyspan's 'C' firmware struct to be used unmodified */
-struct ezusb_hex_record {
- __u16 address;
- __u8 data_size;
- __u8 data[64];
-};
-
-/* Conditionally include firmware images, if they aren't
- included create a null pointer instead. Current
- firmware images aren't optimised to remove duplicate
- addresses in the image itself. */
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA28
- #include "keyspan_usa28_fw.h"
-#else
- static const struct ezusb_hex_record *keyspan_usa28_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA28X
- #include "keyspan_usa28x_fw.h"
-#else
- static const struct ezusb_hex_record *keyspan_usa28x_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA28XA
- #include "keyspan_usa28xa_fw.h"
-#else
- static const struct ezusb_hex_record *keyspan_usa28xa_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA28XB
- #include "keyspan_usa28xb_fw.h"
-#else
- static const struct ezusb_hex_record *keyspan_usa28xb_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA19
- #include "keyspan_usa19_fw.h"
-#else
- static const struct ezusb_hex_record *keyspan_usa19_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA19QI
- #include "keyspan_usa19qi_fw.h"
-#else
- static const struct ezusb_hex_record *keyspan_usa19qi_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_MPR
- #include "keyspan_mpr_fw.h"
-#else
- static const struct ezusb_hex_record *keyspan_mpr_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA19QW
- #include "keyspan_usa19qw_fw.h"
-#else
- static const struct ezusb_hex_record *keyspan_usa19qw_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA18X
- #include "keyspan_usa18x_fw.h"
-#else
- static const struct ezusb_hex_record *keyspan_usa18x_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA19W
- #include "keyspan_usa19w_fw.h"
-#else
- static const struct ezusb_hex_record *keyspan_usa19w_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA49W
- #include "keyspan_usa49w_fw.h"
-#else
- static const struct ezusb_hex_record *keyspan_usa49w_firmware = NULL;
-#endif
-
-#ifdef CONFIG_USB_SERIAL_KEYSPAN_USA49WLC
- #include "keyspan_usa49wlc_fw.h"
-#else
- static const struct ezusb_hex_record *keyspan_usa49wlc_firmware = NULL;
-#endif
-
/* Values used for baud rate calculation - device specific */
#define KEYSPAN_INVALID_BAUD_RATE (-1)
#define KEYSPAN_BAUD_RATE_OK (0)
Index: linux/drivers/usb/serial/Kconfig
===================================================================
--- linux.orig/drivers/usb/serial/Kconfig 2005-03-10 16:01:14.000000000 -0500
+++ linux/drivers/usb/serial/Kconfig 2005-03-10 16:18:19.000000000 -0500
@@ -242,92 +242,21 @@
---help---
Say Y here if you want to use Keyspan USB to serial converter
devices. This driver makes use of Keyspan's official firmware
- and was developed with their support. You must also include
- firmware to support your particular device(s).
+ and was developed with their support. It uses hotplug to load
+ the required firmware from /usr/lib/hotplug/firmware or
+ /lib/firmware.
+
+ However there really isn't a good way to get this firmware
+ since the license only allows it to be distributed as part of
+ a Linux or other Open Source operating system kernel. So you
+ will have to copy the firmware files from the kernel source
+ tree (drivers/usb/serial/*.fw) to /lib/firmware yourself.
See <http://misc.nu/hugh/keyspan.html> for more information.
To compile this driver as a module, choose M here: the
module will be called keyspan.
-config USB_SERIAL_KEYSPAN_MPR
- bool "USB Keyspan MPR Firmware"
- depends on USB_SERIAL_KEYSPAN
- help
- Say Y here to include firmware for the Keyspan MPR converter.
-
-config USB_SERIAL_KEYSPAN_USA28
- bool "USB Keyspan USA-28 Firmware"
- depends on USB_SERIAL_KEYSPAN
- help
- Say Y here to include firmware for the USA-28 converter.
-
-config USB_SERIAL_KEYSPAN_USA28X
- bool "USB Keyspan USA-28X Firmware"
- depends on USB_SERIAL_KEYSPAN
- help
- Say Y here to include firmware for the USA-28X converter.
- Be sure you have a USA-28X, there are also 28XA and 28XB
- models, the label underneath has the actual part number.
-
-config USB_SERIAL_KEYSPAN_USA28XA
- bool "USB Keyspan USA-28XA Firmware"
- depends on USB_SERIAL_KEYSPAN
- help
- Say Y here to include firmware for the USA-28XA converter.
- Be sure you have a USA-28XA, there are also 28X and 28XB
- models, the label underneath has the actual part number.
-
-config USB_SERIAL_KEYSPAN_USA28XB
- bool "USB Keyspan USA-28XB Firmware"
- depends on USB_SERIAL_KEYSPAN
- help
- Say Y here to include firmware for the USA-28XB converter.
- Be sure you have a USA-28XB, there are also 28X and 28XA
- models, the label underneath has the actual part number.
-
-config USB_SERIAL_KEYSPAN_USA19
- bool "USB Keyspan USA-19 Firmware"
- depends on USB_SERIAL_KEYSPAN
- help
- Say Y here to include firmware for the USA-19 converter.
-
-config USB_SERIAL_KEYSPAN_USA18X
- bool "USB Keyspan USA-18X Firmware"
- depends on USB_SERIAL_KEYSPAN
- help
- Say Y here to include firmware for the USA-18X converter.
-
-config USB_SERIAL_KEYSPAN_USA19W
- bool "USB Keyspan USA-19W Firmware"
- depends on USB_SERIAL_KEYSPAN
- help
- Say Y here to include firmware for the USA-19W converter.
-
-config USB_SERIAL_KEYSPAN_USA19QW
- bool "USB Keyspan USA-19QW Firmware"
- depends on USB_SERIAL_KEYSPAN
- help
- Say Y here to include firmware for the USA-19QW converter.
-
-config USB_SERIAL_KEYSPAN_USA19QI
- bool "USB Keyspan USA-19QI Firmware"
- depends on USB_SERIAL_KEYSPAN
- help
- Say Y here to include firmware for the USA-19QI converter.
-
-config USB_SERIAL_KEYSPAN_USA49W
- bool "USB Keyspan USA-49W Firmware"
- depends on USB_SERIAL_KEYSPAN
- help
- Say Y here to include firmware for the USA-49W converter.
-
-config USB_SERIAL_KEYSPAN_USA49WLC
- bool "USB Keyspan USA-49WLC Firmware"
- depends on USB_SERIAL_KEYSPAN
- help
- Say Y here to include firmware for the USA-49WLC converter.
-
config USB_SERIAL_KLSI
tristate "USB KL5KUSB105 (Palmconnect) Driver (EXPERIMENTAL)"
depends on USB_SERIAL && EXPERIMENTAL
Simple program to convert the keyspan firmware header files to IHEX
formatted files that can be loaded with hotplug.
This is really only needed once to convert the existing keyspan firmware
headers, which is what the next patch will do.
Signed-off-by: Jan Harkes <[email protected]>
Index: linux/drivers/usb/serial/dumpfw.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux/drivers/usb/serial/dumpfw.c 2005-03-10 23:16:37.240765747 -0500
@@ -0,0 +1,98 @@
+/*
+ * Convert keyspan firmware header files to Intel HEX format
+ * cc -I/usr/src/linux/drivers/usb/serial -o dumpfw dumpfw.c
+ */
+#include <stdint.h>
+#include <stdio.h>
+
+//#include "keyspan.h" /* ezusb_hex_record */
+
+struct ezusb_hex_record {
+ uint16_t address;
+ uint8_t size;
+ uint8_t data[64];
+};
+
+#include "keyspan_usa28_fw.h"
+#include "keyspan_usa28x_fw.h"
+#include "keyspan_usa28xa_fw.h"
+#include "keyspan_usa28xb_fw.h"
+#include "keyspan_usa19_fw.h"
+#include "keyspan_usa19qi_fw.h"
+#include "keyspan_mpr_fw.h"
+#include "keyspan_usa19qw_fw.h"
+#include "keyspan_usa18x_fw.h"
+#include "keyspan_usa19w_fw.h"
+#include "keyspan_usa49w_fw.h"
+#include "keyspan_usa49wlc_fw.h"
+
+char *boilerplate = "\
+# This firmware for the Keyspan %s USB-to-Serial adapter is\n\
+#\n\
+# Copyright (C) 1999-2003\n\
+# Keyspan, A division of InnoSys Incorporated (\"Keyspan\")\n\
+#\n\
+# as an unpublished work. This notice does not imply unrestricted or\n\
+# public access to the source code from which this firmware image is\n\
+# derived. Except as noted below this firmware image may not be\n\
+# reproduced, used, sold or transferred to any third party without\n\
+# Keyspan's prior written consent. All Rights Reserved.\n\
+#\n\
+# Permission is hereby granted for the distribution of this firmware\n\
+# image as part of a Linux or other Open Source operating system kernel\n\
+# in text or binary form as required.\n\
+#\n\
+# This firmware may not be modified and may only be used with\n\
+# Keyspan hardware. Distribution of this firmware, in whole or in\n\
+# part, requires the inclusion of this statement.\n\
+#\n";
+
+void dumpfw(char *name, const struct ezusb_hex_record *record)
+{
+ char fw_name[20];
+ char NAME[10];
+ uint16_t address, i;
+ uint8_t crc;
+ FILE *f;
+
+ for (i = 0; name[i] != '\0'; i++)
+ NAME[i] = toupper(name[i]);
+ NAME[i] = '\0';
+
+ sprintf(fw_name, "keyspan-%s.fw", name);
+ printf("writing %s\n", fw_name);
+
+ f = fopen(fw_name, "w");
+ fprintf(f, boilerplate, NAME);
+
+ while (record->address != 0xffff) {
+ crc = record->size + (record->address >> 8) + record->address;
+ fprintf(f, ":%02X%04X00", record->size, record->address);
+ for (i = 0; i < record->size; i++) {
+ fprintf(f, "%02X", record->data[i]);
+ crc += record->data[i];
+ }
+ fprintf(f, "%02X\n", (uint8_t)-crc);
+ record++;
+ }
+ fprintf(f, ":00000001FF\n");
+
+ fclose(f);
+}
+
+int main(int argc, char **argv)
+{
+ dumpfw("mpr", keyspan_mpr_firmware);
+ dumpfw("usa18x", keyspan_usa18x_firmware);
+ dumpfw("usa19", keyspan_usa19_firmware);
+ dumpfw("usa19qi", keyspan_usa19qi_firmware);
+ dumpfw("usa19qw", keyspan_usa19qw_firmware);
+ dumpfw("usa19w", keyspan_usa19w_firmware);
+ dumpfw("usa28", keyspan_usa28_firmware);
+ dumpfw("usa28x", keyspan_usa28x_firmware);
+ dumpfw("usa28xa", keyspan_usa28xa_firmware);
+ dumpfw("usa28xb", keyspan_usa28xb_firmware);
+ dumpfw("usa49w", keyspan_usa49w_firmware);
+ dumpfw("usa49wlc", keyspan_usa49wlc_firmware);
+}
+
On Monday 04 April 2005 23:23, Jan Harkes wrote:
> On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > >
> > > http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > >
> > > Can you summarize the conclusion of the thread, or what you did get from it,
> > > please ?
> >
> > That people didn't like the inclusion of firmware, I posted how you can
> > fix it by moving it outside of the kernel, and asked for patches.
> >
> > None have come.
>
> Didn't know you were waiting for it. How about something like the
> following series of patches?
>
> [01/04] - add simple Intel IHEX format parser to the firmware loader.
Firmware loader is format-agnostic, I think having IHEX parser in a separate
file would be better...
--
Dmitry
On Tue, Apr 05, 2005 at 12:23:29AM -0400, Jan Harkes wrote:
> On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > >
> > > http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > >
> > > Can you summarize the conclusion of the thread, or what you did get from it,
> > > please ?
> >
> > That people didn't like the inclusion of firmware, I posted how you can
> > fix it by moving it outside of the kernel, and asked for patches.
> >
> > None have come.
>
> Didn't know you were waiting for it. How about something like the
> following series of patches?
>
> [01/04] - add simple Intel IHEX format parser to the firmware loader.
> [02/04] - make the keyspan driver use request_firmware.
> [03/04] - converter program used to dump the keyspan headers as IHex files.
> [04/04] - result of running the previous program.
>
> This ofcourse doesn't actually solve Debian's distribution issues since
> the keyspan firmware can only be distributed as part of 'Linux or other
> Open Source operating system kernel'.
Well, if this is the case, it can be distributed on the non-free archive.
> > So I refuse to listen to talk about this, as obviously, no one cares
> > enough about this to actually fix the issue.
>
> I got tired of always building my own kernels on Debian just to get my
> serial dongle to work since their included keyspan.ko driver is so
> useless that it isn't even worth having. The only way to use it with a
> Debian kernel is to have the dongle in a powered hub and first boot into
> Windows or a normal kernel.org kernel to get the thing initialized.
The non-free driver package should solve that for you.
> Didn't send the patch earlier since I wanted to split off the
> pre-numeration part of the driver so that after intialization we can
> unload the unused parts of the driver as well as the the firmware class
> module.
Friendly,
Sven Luther
On Mon, 2005-04-04 at 23:19 +0200, Sven Luther wrote:
> I am only saying that the tg3.c and other file are under the GPL, and
> that the firmware included in it is *NOT* intented to be under the
> GPL, so why not say it explicitly ?
I don't think anyone here has disagreed. What almost everyone has said
however is "so go and do it" -- go do the research, contact the
copyright holders directly and get the permission to make patches, then
post them here.
There is really no point in discussing it here, just get on and do it.
Ian.
--
Ian Campbell
Cheops' Law:
Nothing ever gets built on schedule or within budget.
On Mon, 2005-04-04 at 23:51 -0500, Dmitry Torokhov wrote:
> On Monday 04 April 2005 23:23, Jan Harkes wrote:
> > On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote:
> > > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote:
> > > > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > > >
> > > > http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > > >
> > > > Can you summarize the conclusion of the thread, or what you did get from it,
> > > > please ?
> > >
> > > That people didn't like the inclusion of firmware, I posted how you can
> > > fix it by moving it outside of the kernel, and asked for patches.
> > >
> > > None have come.
> >
> > Didn't know you were waiting for it. How about something like the
> > following series of patches?
> >
> > [01/04] - add simple Intel IHEX format parser to the firmware loader.
>
> Firmware loader is format-agnostic, I think having IHEX parser in a separate
> file would be better...
Why should this be in-kernel at all? Convert the firmware into a binary
blob or do it in the userspace request.
Kay
On Tue, Apr 05, 2005 at 09:19:24AM +0100, Ian Campbell wrote:
> On Mon, 2005-04-04 at 23:19 +0200, Sven Luther wrote:
>
> > I am only saying that the tg3.c and other file are under the GPL, and
> > that the firmware included in it is *NOT* intented to be under the
> > GPL, so why not say it explicitly ?
>
> I don't think anyone here has disagreed. What almost everyone has said
> however is "so go and do it" -- go do the research, contact the
> copyright holders directly and get the permission to make patches, then
> post them here.
Ok. I have some doubts about doing the work, and it then being rejected and
i did the work first, which is why i asked. It seemed a reasonable thing to
ask, and my analysis of the problem was sound, so why didn't i get a, yeah, go
ahead, instead of this rejection ?
> There is really no point in discussing it here, just get on and do it.
As i said, some may know things about relationship, or lack thereof, with the
copyright holder, i believe that the people who added those firmware blobs are
all reading this here, and it is from them that i wanted feedback, but it
failed to produce that effect.
/me will investigate bk and how to get the information on who signed those
changes off and commited them :)
Friendly,
Sven Luther
On Tue, 2005-04-05 at 10:32 +0200, Sven Luther wrote:
> On Tue, Apr 05, 2005 at 09:19:24AM +0100, Ian Campbell wrote:
> > On Mon, 2005-04-04 at 23:19 +0200, Sven Luther wrote:
> >
> > > I am only saying that the tg3.c and other file are under the GPL, and
> > > that the firmware included in it is *NOT* intented to be under the
> > > GPL, so why not say it explicitly ?
> >
> > I don't think anyone here has disagreed. What almost everyone has said
> > however is "so go and do it" -- go do the research, contact the
> > copyright holders directly and get the permission to make patches, then
> > post them here.
>
> Ok. I have some doubts about doing the work, and it then being rejected and
> i did the work first, which is why i asked. It seemed a reasonable thing to
> ask, and my analysis of the problem was sound, so why didn't i get a, yeah, go
> ahead, instead of this rejection ?
I don't think you did get a rejection, a few people said that _they_
weren't going to do it, but if you want to then go ahead. I think people
are just fed up of people bringing up the issue and then failing to do
anything about it -- so prove them wrong ;-)
Ian.
--
Ian Campbell
knghtbrd: there may be no spoon, but can you spot the vulnerability in
eye_render_shiny_object.c?
-- rcw
On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote:
> I don't think you did get a rejection, a few people said that _they_
> weren't going to do it, but if you want to then go ahead. I think people
> are just fed up of people bringing up the issue and then failing to do
> anything about it -- so prove them wrong ;-)
Actually patches to add firmware loader support to tg3 got rejected.
Which is think is very unfortunately as we set the highlevel goal to
move drivers over to it.
Hi Jan,
> > > > Mmm, probably that 2001 discussion about the keyspan firmware, right ?
> > > >
> > > > http://lists.debian.org/debian-legal/2001/04/msg00145.html
> > > >
> > > > Can you summarize the conclusion of the thread, or what you did get from it,
> > > > please ?
> > >
> > > That people didn't like the inclusion of firmware, I posted how you can
> > > fix it by moving it outside of the kernel, and asked for patches.
> > >
> > > None have come.
> >
> > Didn't know you were waiting for it. How about something like the
> > following series of patches?
> >
> > [01/04] - add simple Intel IHEX format parser to the firmware loader.
>
> Firmware loader is format-agnostic, I think having IHEX parser in a separate
> file would be better...
I agree with Dmitry on this point. The IHEX parser should not be inside
firmware_class.c. What about using keyspan_ihex.[ch] for it?
Regards
Marcel
On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote:
> On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote:
> > I don't think you did get a rejection, a few people said that _they_
> > weren't going to do it, but if you want to then go ahead. I think people
> > are just fed up of people bringing up the issue and then failing to do
> > anything about it -- so prove them wrong ;-)
>
> Actually patches to add firmware loader support to tg3 got rejected.
I think they will be accepted if they first introduce a transition
period where tg3 will do request_firmware() and only use the built-in
firmware if that fails. Second step is to make the built-in firmware a
config option and then later on when the infrastructure matures for
firmware loading/providing firmware it can be removed from the driver
entirely.
One of the sticking points will be how people get the firmware; I can
see the point of a kernel-distributable-firmware project related to the
kernel (say on kernel.org) which would provide a nice collection of
distributable firmwares (and is appropriately licensed). Without such
joint infrastructure things will always be a mess and in that context I
can see the point of the driver authors not immediately wanting to
switch exclusively. Simply because they'll get swamped with email about
how the driver doesn't work...
On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote:
> On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote:
> > I don't think you did get a rejection, a few people said that _they_
> > weren't going to do it, but if you want to then go ahead. I think people
> > are just fed up of people bringing up the issue and then failing to do
> > anything about it -- so prove them wrong ;-)
>
> Actually patches to add firmware loader support to tg3 got rejected.
>
> Which is think is very unfortunately as we set the highlevel goal to
> move drivers over to it.
I didn't know that -- you are right that it is unfortunate.
I thought Sven was talking (at least short term) about adding copyright
statements/exemptions/something to the binary blobs where they are now.
Ian.
--
Ian Campbell
It's easier to get forgiveness for being wrong than forgiveness for being
right.
On Tue, Apr 05, 2005 at 11:28:07AM +0200, Arjan van de Ven wrote:
> I think they will be accepted if they first introduce a transition
> period where tg3 will do request_firmware() and only use the built-in
> firmware if that fails.
Fine with me.
> Second step is to make the built-in firmware a
> config option and then later on when the infrastructure matures for
> firmware loading/providing firmware it can be removed from the driver
> entirely.
I think the infrasturcture is quite mature. We have a lot of drivers
that require it to function.
> One of the sticking points will be how people get the firmware; I can
> see the point of a kernel-distributable-firmware project related to the
> kernel (say on kernel.org) which would provide a nice collection of
> distributable firmwares (and is appropriately licensed). Without such
> joint infrastructure things will always be a mess and in that context I
> can see the point of the driver authors not immediately wanting to
> switch exclusively. Simply because they'll get swamped with email about
> how the driver doesn't work...
I agree. And that really doesn't need a lot of infrastructure,
basically just a tarball that unpacks to /lib/firmware, maybe a specfile
and debian/ dir in addition.
Hello Jeff, ...
If i can believe what i see in :
http://linux.bkbits.net:8080/linux-2.6/anno/drivers/net/[email protected]?nav=index.html|src/|src/drivers|src/drivers/net|related/drivers/net/tg3.c|[email protected]
(which may or may not be correct and complete, since i am not really familiar
with bk and how things where back then), you imported the tg3 firmware in our
bk repo on 2002/03/07 :
2002/03/07 jgarzik | 0x00000000, 0x10000003, 0x00000000, 0x0000000d, 0x0000000d, 0x3c1d0800,
2002/03/07 jgarzik | 0x37bd3ffc, 0x03a0f021, 0x3c100800, 0x26100000, 0x0e000018, 0x00000000,
2002/03/07 jgarzik | 0x0000000d, 0x3c1d0800, 0x37bd3ffc, 0x03a0f021, 0x3c100800, 0x26100034,
The changelog importing them says :
Merge new tg3 version 0.96 gigabit ethernet driver.
So i suppose this comes from a pre-bk tree or something, altough the whole
copyright of that file is marked as copyrighted by you and davem.
Where did you get that firmware from and under which licence ? And would you
approve of a patch marking this blob as non-GPLed, and we could add the
licencing text for it that you originally got it under ? Does this make sense ?
Or do you believe i should go ahead and approach broadcom, claiming something
like the following :
"We have noticed that an unlicenced firmware blob whose copyright you hold
is present in the linux tg3 driver. In order to clarify this situation, we
would like to know if it is ok to distribute said binary firmware blob, and
know under what licence it comes."
BTW, also, i am not entirely sure if such changes can be done only by you, or
need approval of everyone who contributed GPL code to that file since then,
altough i believe that since the firmware blob is an agregation, it should not
matter, and only the original checkin you did is the one we need to account
for.
I understand this is bothersome to everyone, but the code base will be a
cleaner one once we solve this issue, don't you think ?
Friendly,
Sven Luther
On Tue, Apr 05, 2005 at 10:30:47AM +0100, Ian Campbell wrote:
> On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote:
> > On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote:
> > > I don't think you did get a rejection, a few people said that _they_
> > > weren't going to do it, but if you want to then go ahead. I think people
> > > are just fed up of people bringing up the issue and then failing to do
> > > anything about it -- so prove them wrong ;-)
> >
> > Actually patches to add firmware loader support to tg3 got rejected.
> >
> > Which is think is very unfortunately as we set the highlevel goal to
> > move drivers over to it.
>
> I didn't know that -- you are right that it is unfortunate.
>
> I thought Sven was talking (at least short term) about adding copyright
> statements/exemptions/something to the binary blobs where they are now.
Yes, indeed, i am searching for a short-time clarification, but in the long
term the separate firmware solution is indeed better, altough more work and
more involved.
That said, the work to identify the firmware blobs and clarify their
copyright/licencing situation is common for both alternatives.
Friendly,
Sven Luther
> > Second step is to make the built-in firmware a
> > config option and then later on when the infrastructure matures for
> > firmware loading/providing firmware it can be removed from the driver
> > entirely.
>
> I think the infrasturcture is quite mature. We have a lot of drivers
> that require it to function.
what seems to be currently missing is distro level support for using
firmware for modules needed for booting (and tg3 falls sort of under
that via nfsroot) and widespread easy availability of firmware in
distros and for users.
Both are a bit of a chick-and-egg thing, and this is what a transition
period with a few key drivers in dual-mode would hopefully resolve.
One of the options is to even ship the firmware in the kernel tarbal but
from a separate directory with a clear license clarification text in it.
On Tue, Apr 05, 2005 at 11:36:58AM +0200, Arjan van de Ven wrote:
>
> > > Second step is to make the built-in firmware a
> > > config option and then later on when the infrastructure matures for
> > > firmware loading/providing firmware it can be removed from the driver
> > > entirely.
> >
> > I think the infrasturcture is quite mature. We have a lot of drivers
> > that require it to function.
>
> what seems to be currently missing is distro level support for using
> firmware for modules needed for booting (and tg3 falls sort of under
> that via nfsroot) and widespread easy availability of firmware in
> distros and for users.
Well, apart from the installation case, simply using such kernel is easy
enough, if you use an initrd. The mkinitrd script only has to be aware of
this, and include the needed firmware in the initrd, as it does for the
modules. Initial installation will have to either have the possibility to
build custom initrds with the firmware blobs in it, or a way to easily get
those firmware blobs (from CD, floppy, net, ...), or have support for a second
initrd which would contain the firmware. I don't believe there is already
support for a second ramdisk in todays kernel.
Friendly,
Sven Luther
On Tue, Apr 05, 2005 at 11:36:58AM +0200, Arjan van de Ven wrote:
> One of the options is to even ship the firmware in the kernel tarbal but
> from a separate directory with a clear license clarification text in it.
I think that's what we should do. I currently don't have any firmware
requiring devices, but I'd volunteer to keep such a tarball for now if
no one else wants to do tiny amount of work.
On Tue, 05 Apr 2005 11:39:02 +0200, Christoph Hellwig wrote:
> On Tue, Apr 05, 2005 at 11:36:58AM +0200, Arjan van de Ven wrote:
>> One of the options is to even ship the firmware in the kernel tarbal but
>> from a separate directory with a clear license clarification text in it.
>
> I think that's what we should do. I currently don't have any firmware
> requiring devices, but I'd volunteer to keep such a tarball for now if
> no one else wants to do tiny amount of work.
FYI, I just created this, it might be useful for all this:
http://wiki.debian.net/?KernelFirmwareLicensing
I'm still adding driver information..
On Tue, Apr 05, 2005 at 10:32:38AM +0200, Kay Sievers wrote:
> On Mon, 2005-04-04 at 23:51 -0500, Dmitry Torokhov wrote:
> > Firmware loader is format-agnostic, I think having IHEX parser in a separate
> > file would be better...
>
> Why should this be in-kernel at all? Convert the firmware into a binary
> blob or do it in the userspace request.
Because the keyspan headers seem to have a specific sequence of
operations, something like 'load these 5 bytes at offset 10, load this
byte at offset 0, etc.' I don't know if there is some magic in that
sequence. Without knowing what is in the firmware, it looks to me like a
little bit of bootstrap code is loaded first.
Jan
On Tue, Apr 05, 2005 at 11:22:06AM +0200, Marcel Holtmann wrote:
> I agree with Dmitry on this point. The IHEX parser should not be inside
> firmware_class.c. What about using keyspan_ihex.[ch] for it?
That's what I had originally, actually called firmware_ihex.ko, since
the IHEX format parser is not in any way keyspan specific and there are
several usb-serial converters that seem to use the same IHEX->.h trick
which could trivially be modified to use this loader.
But the compiled parser fairly small (< 2KB) and adding it to the
existing module didn't effectively add any size to the firmware_class
module since things are rounded to a page boundary anyways.
Jan
Theodore Ts'o wrote:
> You know, the fact that Red Hat, SuSE, Ubuntu, and pretty much all
> other commercial distributions have not been worried about getting
> sued for this alleged GPL'ed violation makes it a lot harder for me
> (and others, I'm sure) take Debian's concerns seriously.
I said in other e-mail, and I will repeat: it's not their (Debian's)
fault. Their responsibility is greater. Why? Because when RedHat puts
something it shouldn't in their distro it's *their* assets that will
answer for some copyright violation damages. In Debian's case, it's the
assets of: some DDs, the mirror network, derived-distro distributors, CD
vendors, etc... This is just a case of Debian being "fiscally
responsible", i.e., not treating other people's money as trash.
> The problem may be that because Debian is purely a non-profit, and so
> it can't clearly balance the costs and benefits of trying trying to
> avoid every single possible risks where someone might decide to file
> a lawsuit. Anytime you do *anything* you risk the possibility of a
> lawsuit, and if you allow the laywers to take over your business
> decisions, the natural avoid-risks-all-costs bias of lawyers are such
> that it will either drive a company out of business, or drive a
> non-profit distribution into irrelevance.....
>
> If Debian wants to be this fanatical, then let those Debian
> developers who care do all of the work to make this happen, and stop
> bothering LKML. And if it continues to remain the case that a user
> will have to manually edit /etc/apt/sources.lists (using vi!) to
> include a reference to non-free in order to install Debian on a
> system that requires the tg3 device driver, then I will have to tell
> users who ask me that they would be better off using some other
> distribution which actually cares about their needs.
>
> - Ted
In this I agree with you, and Greg KH was singing approximately the same
tune, if I understood correctly: this is a matter to be resolved by
distributors and, if someone solves this in a practical and good way, it
will eventually end in the pristine-blessed-Linus-kernel-tree, to the
benefit of others.
But, the question made here was a subtler one and you are all biting
around the bush: there *are* some misrepresentations of licenses to the
firmware blobs in the kernel (-- ok, *if* you consider that hex dumps
are not source code). What Sven asked was: "Hey, can I state explicitly
the distribution state in the source files, by means of adding some
comments?".
Maybe he should contact each file's maintainer individually, but it
seems (IMHO) that he thought "hey, they all hang around lkml anyway"...
I think even a clarification "this firmware hexdump is considered to be
the source code, and it's GPL'd" would do, but I must put my asbestos
suit everytime I say it. :-)
HTH,
Massa
Christoph Hellwig wrote:
> On Tue, Apr 05, 2005 at 11:28:07AM +0200, Arjan van de Ven wrote:
>>One of the sticking points will be how people get the firmware; I can
>>see the point of a kernel-distributable-firmware project related to the
>>kernel (say on kernel.org) which would provide a nice collection of
>>distributable firmwares (and is appropriately licensed). Without such
>>joint infrastructure things will always be a mess and in that context I
>>can see the point of the driver authors not immediately wanting to
>>switch exclusively. Simply because they'll get swamped with email about
>>how the driver doesn't work...
>
>
> I agree. And that really doesn't need a lot of infrastructure,
> basically just a tarball that unpacks to /lib/firmware, maybe a specfile
> and debian/ dir in addition.
At the moment there is -zero- infrastructure that would allow my tg3 to
continue working, when I upgrade to a tg3 driver with external firmware.
The user has to put a file in some location manually.
That's a complete non-starter, from a usability standpoint.
Further, several firmwares, including tg3, are really a collection of
bits of information: .text, .bss, and random variables (start addr,
image size, ...). The current interface is complete crap for this sort
of setup.
The firmware loader really needs to be loading -archives- not individual
files.
We are a -long- way from moving the firmware out of the tg3 source code.
Jeff
> > I agree. And that really doesn't need a lot of infrastructure,
> > basically just a tarball that unpacks to /lib/firmware, maybe a specfile
> > and debian/ dir in addition.
>
>
> At the moment there is -zero- infrastructure that would allow my tg3 to
> continue working, when I upgrade to a tg3 driver with external firmware.
>
> The user has to put a file in some location manually.
>
> That's a complete non-starter, from a usability standpoint.
but unless we allow the driver to use such things, such infrastructure
won't come into existence either. It's a chicken-and-egg situation...
except that we can for a while make tg3 and others be both the chicken
and egg until the real chicken is there.
> Further, several firmwares, including tg3, are really a collection of
> bits of information: .text, .bss, and random variables (start addr,
> image size, ...). The current interface is complete crap for this sort
> of setup.
>
> The firmware loader really needs to be loading -archives- not individual
> files.
>
> We are a -long- way from moving the firmware out of the tg3 source code.
Yet that is no excuse to not at least start addressing the issues. What
you just listed are deficiencies in the kernel infrastructure, not doing
something because we have slightly suboptimal infrastructure isn't the
right thing.
Humberto Massa wrote:
> But, the question made here was a subtler one and you are all biting
> around the bush: there *are* some misrepresentations of licenses to the
> firmware blobs in the kernel (-- ok, *if* you consider that hex dumps
> are not source code). What Sven asked was: "Hey, can I state explicitly
> the distribution state in the source files, by means of adding some
> comments?".
> I think even a clarification "this firmware hexdump is considered to be
> the source code, and it's GPL'd" would do, but I must put my asbestos
> suit everytime I say it. :-)
We do not add comments to the kernel source code which simply state the
obvious.
Jeff
On Tue, Apr 05, 2005 at 09:03:21AM -0300, Humberto Massa wrote:
> Theodore Ts'o wrote:
>
> > You know, the fact that Red Hat, SuSE, Ubuntu, and pretty much all
> > other commercial distributions have not been worried about getting
> > sued for this alleged GPL'ed violation makes it a lot harder for me
> > (and others, I'm sure) take Debian's concerns seriously.
>
> I said in other e-mail, and I will repeat: it's not their (Debian's)
> fault. Their responsibility is greater. Why? Because when RedHat puts
> something it shouldn't in their distro it's *their* assets that will
> answer for some copyright violation damages. In Debian's case, it's the
> assets of: some DDs, the mirror network, derived-distro distributors, CD
> vendors, etc... This is just a case of Debian being "fiscally
> responsible", i.e., not treating other people's money as trash.
This is where you are wrong, and i believe this is caused because you don't
understand how debian works on this.
The ftp-master are the ones reviewing the licencing problems, and they are the
ones handling the infrastructure, and putting their responsability on the
stake. If they feel that some piece of software has dubious legal issues which
come at a risk of having them personally come on the receiving end of a legal
case, then they will say, no, we don't distribute this software, and that is
the end of it.
The other point is that other entities, like redhat, or suse (which is now
novel and thus ibm) and so have stronger backbones, and can more easily muster
the ressources to fight of a legal case, even one which is a dubious one,
especially given the particularities of the US judicial system, where it is
less important to be right, and more important to have lot of money to throw
at your legal machine. Debian has nothing such, and SPI which would stand for
this, is not really upto it either, so in this case, apart from all ideology
and fanatism, it is for purely pragmatic reasons that they don't distribute
undistributable files from the non-free part of our archive. You would do the
same in their case.
Also, you have to ask yourself what the above mentioned companies where to do
if they where to be made aware of the issue, and ask their lawyers to attend
this. Also you have to consider the case of some of those companies ending in
the arms of a legally predative company and pulling another SCO at us.
Friendly,
Sven Luther
Le lundi 04 avril 2005 ? 21:32 +0200, Adrian Bunk a ?crit :
> On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote:
> > On Apr 04, Greg KH <[email protected]> wrote:
> >
> > > What if we don't want to do so? I know I personally posted a solution
> > Then probably the extremists in Debian will manage to kill your driver,
> > like they did with tg3 and others.
>
> And as they are doing with e.g. the complete gcc documentation.
>
> No documentation for the C compiler (not even a documentation of the
> options) will be neither fun for the users of Debian nor for the Debian
> maintainers - but it's the future of Debian...
You are mixing apples and oranges. The fact that the GFDL sucks has
nothing to do with the firmware issue. With the current situation of
firmwares in the kernel, it is illegal to redistribute binary images of
the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
be willing to distribute such binary images, but it isn't our problem.
Putting the firmwares outside the kernel makes them distributable. Some
distributions will want to include them, some others not. But the
important point is that it makes that redistribution legal.
--
.''`. Josselin Mouette /\./\
: :' : [email protected]
`. `' [email protected]
`- Debian GNU/Linux -- The power of freedom
On Tue, Apr 05, 2005 at 08:16:48AM -0400, Jeff Garzik wrote:
> Humberto Massa wrote:
> >But, the question made here was a subtler one and you are all biting
> >around the bush: there *are* some misrepresentations of licenses to the
> >firmware blobs in the kernel (-- ok, *if* you consider that hex dumps
> >are not source code). What Sven asked was: "Hey, can I state explicitly
> >the distribution state in the source files, by means of adding some
> >comments?".
>
> >I think even a clarification "this firmware hexdump is considered to be
> >the source code, and it's GPL'd" would do, but I must put my asbestos
> >suit everytime I say it. :-)
>
> We do not add comments to the kernel source code which simply state the
> obvious.
The only thing here is that it has to be obvious not only to you, but to the
judge too :)
In this case, it is not comments, but proper copyright attribution, which was
added in the tg3.c case since the first checkin :
/*
* tg3.c: Broadcom Tigon3 ethernet driver.
*
* Copyright (C) 2001, 2002, 2003, 2004 David S. Miller ([email protected])
* Copyright (C) 2001, 2002, 2003 Jeff Garzik ([email protected])
* Copyright (C) 2004 Sun Microsystems Inc.
*
* Firmware is:
* Copyright (C) 2000-2003 Broadcom Corporation.
*/
The firmware part was not present in the original checkin you did in 2002.
Adding something about the licencing status of it would be enough.
Or even adding some comment in the toplevel COPYING file saying that firmware
blobs come under their own licence or something such, and then listing all the
firmware blobs and their licencing condition in a separate toplevel file would
be enough.
Friendly,
Sven Luther
Hi Jan,
> > I agree with Dmitry on this point. The IHEX parser should not be inside
> > firmware_class.c. What about using keyspan_ihex.[ch] for it?
>
> That's what I had originally, actually called firmware_ihex.ko, since
> the IHEX format parser is not in any way keyspan specific and there are
> several usb-serial converters that seem to use the same IHEX->.h trick
> which could trivially be modified to use this loader.
>
> But the compiled parser fairly small (< 2KB) and adding it to the
> existing module didn't effectively add any size to the firmware_class
> module since things are rounded to a page boundary anyways.
so it seems that this is usb-serial specific at the moment. Then I would
propose to add it to the core of the usb-serial driver. Unless no other
driver in the kernel needs a IHEX parser, I think it is bad idea to mess
it up at the moment. People are also working on a replacement for the
current request_firmware(), because the needs are changing. Try to keep
it close with the usb-serial for now.
Regards
Marcel
Jeff Garzik wrote:
>We do not add comments to the kernel source code which simply state the
>obvious.
>
> Jeff
>
>
Whoa, kind of harsh, isn't it? I'm just trying to help.
Anyway, the problem at hand is: people do *not* think there is anything
obvious.
For instance: many, many people do not consider binary hexdumps in .c/.h
files as source code; if you think so, you should state it in writing,
you know, to avoid lawyer attacks.
Another example: if you think it's obvious that the binary hexdump is
another work, aggregated to the GPL'd .c/.h file, then you should state
(again, in writing) which are the licensing terms of said work...
otherwise, no-one has a written license to redistribute it, leading
to... lawyer attacks.
HTH,
Massa
Sven Luther wrote:
>On Tue, Apr 05, 2005 at 09:03:21AM -0300, Humberto Massa wrote:
>
>>Theodore Ts'o wrote:
>>
>>>You know, the fact that Red Hat, SuSE, Ubuntu, and pretty much all
>>>other commercial distributions have not been worried about getting
>>>sued for this alleged GPL'ed violation makes it a lot harder for me
>>>(and others, I'm sure) take Debian's concerns seriously.
>>
>>I said in other e-mail, and I will repeat: it's not their (Debian's)
>>fault. Their responsibility is greater. Why? Because when RedHat puts
>>something it shouldn't in their distro it's *their* assets that will
>>answer for some copyright violation damages. In Debian's case, it's
>>the assets of: some DDs, the mirror network, derived-distro
>>distributors, CD vendors, etc... This is just a case of Debian being
>>"fiscally responsible", i.e., not treating other people's money as
>>trash.
>
>
>This is where you are wrong, and i believe this is caused because you
>don't understand how debian works on this.
I was not commenting on Debian works; I was commenting on civil and
criminal liabilities. If Debian, knowingly or not, distributes a
copyrights-infringing work, the work's package(s) maintainer(s) are
civil and criminally liable, and so are: CD distributors where said work
is distributed in the CD, derived-distro distributors, and the mirror
network members. Why? Because they are all distributing infringing
works.
Let me explain how this works. In 1999, the police went into a
videostore in the city where I worked as a paralegal in the DA's office.
There were a lot of pirated VHS tapes there (without the "not pirated"
holographic seal that our MPAA-equivalent gives to the members to glue
on their tapes/DVDs). The guy from the videostore did not make the
copies, but he distributed (renting is a form of distribution, yes) the
infringing works, so... unless he proves that he had all the good
reasons to think that the works he bought were non-infringing (for
instance, if they all had seals like the "official" one,
undistinguishable by the naked eye), he is liable for the infringement.
And so, the guy got some years of jailtime, plus some hefty fines.
>The ftp-master are the ones reviewing the licencing problems, and they
>are the ones handling the infrastructure, and putting their
>responsability on the stake. If they feel that some piece of software
>has dubious legal issues which come at a risk of having them personally
>come on the receiving end of a legal case, then they will say, no, we
>don't distribute this software, and that is the end of it.
This is not the only thing that is at stake, as I demonstrated /
illustrated by my anecdote above. But yes, probably ftp-master guys are
liable, too.
>The other point is that other entities, like redhat, or suse (which is
>now novel and thus ibm) and so have stronger backbones, and can more
>easily muster the ressources to fight of a legal case, even one which
>is a dubious one, especially given the particularities of the US
>judicial system, where it is less important to be right, and more
>important to have lot of money to throw at your legal machine. Debian
>has nothing such, and SPI which would stand for this, is not really
>upto it either, so in this case, apart from all ideology and fanatism,
>it is for purely pragmatic reasons that they don't distribute
>undistributable files from the non-free part of our archive. You would
>do the same in their case.
>
>Also, you have to ask yourself what the above mentioned companies where
>to do if they where to be made aware of the issue, and ask their
>lawyers to attend this. Also you have to consider the case of some of
>those companies ending in the arms of a legally predative company and
>pulling another SCO at us.
Yes and yes. But their lawyers have an option Debian does not, also:
they can negotiate ($$$) an exclusive license to redistribute. As in:
"Novell can redistribute this work in their Linux distro, at will". This
would not be DFSG-free.
>
>Friendly,
>
>Sven Luther
Friendly, HTH,
Massa
Josselin Mouette wrote:
>You are mixing apples and oranges. The fact that the GFDL sucks has
>nothing to do with the firmware issue. With the current situation of
>firmwares in the kernel, it is illegal to redistribute binary images of
>the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
>be willing to distribute such binary images, but it isn't our problem.
>
>
Yes, GFDL has nothing to do with the main issue. No, it is not
necessarily illegal to redistribute binary images of the kernel as they
are today (see below). The first problem is that they (the complete
w/firmware kernel binary images) are not DFSG-free, anyway. The second
problem is that some firmware blobs don't have explicitly stated in the
kernel tree which exactly are their licensing terms for redistribution
-- those are, in principle, undistributable.
>Putting the firmwares outside the kernel makes them distributable. Some
>distributions will want to include them, some others not. But the
>important point is that it makes that redistribution legal.
>
>
If putting the firmwares outside the kernel makes *them* distributable,
then the binary kernel image is already distributable -- just not
DFSG-free. The important fact WRT Debian, IMHO, is that putting the
firmwares outside the kernel makes the kernel binary image DFSG-free.
HTH,
Massa
Sven Luther wrote:
> On Tue, Apr 05, 2005 at 12:23:29AM -0400, Jan Harkes wrote:
> > This ofcourse doesn't actually solve Debian's distribution issues since
> > the keyspan firmware can only be distributed as part of 'Linux or other
> > Open Source operating system kernel'.
>
>
> Well, if this is the case, it can be distributed on the non-free
> archive.
Nope, looks awfully non-distributable for me, unless you put it into a
kernel-non-free with the entire kernel -- but it says clearly that it's
undistributable by itself.
HTH,
Massa
On Tue, Apr 05, 2005 at 09:19:24AM +0100, Ian Campbell wrote:
> On Mon, 2005-04-04 at 23:19 +0200, Sven Luther wrote:
>
> > I am only saying that the tg3.c and other file are under the GPL, and
> > that the firmware included in it is *NOT* intented to be under the
> > GPL, so why not say it explicitly ?
>
> I don't think anyone here has disagreed. What almost everyone has said
> however is "so go and do it" -- go do the research, contact the
> copyright holders directly and get the permission to make patches, then
> post them here.
>
> There is really no point in discussing it here, just get on and do it.
Ok, for info, here is the email i just sent to the boradcom driver support :
---
Hello,
I am part of the Debian GNU/Linux kernel team, and recently stumbled about
some legal problems with the tg3.c driver for broadcom gigabit ethernet
controllers. The problem seems to be the same for the bcm570x drivers you
distribute from your web page, and after discussion with the debian-legal
team [1] and airing the issue with the larger linux kernel developers [2],
i now come to you for clarfication of this issue.
The broadcom 570x drivers are placed under the GPL, which is nice, and come
accompanied by sources, but include a few blobs of binary-only firmware to be
uploaded to the controller.
After discussion with debian-legal, we accept that the binary-only firmware
blob does not constitute a derivative work of the rest of the driver, but mere
agregation, so distributing it as binary only as you do is not a problem,
altough getting real sources for this part would be preferable.
Now, the problem is that both in the files included in the mainline kernel, as
well as the sources you distribute yourself, these firmware blobs come in a
file like fw_lso05.h, whose licence text says :
/******************************************************************************/
/* */
/* Broadcom BCM5700 Linux Network Driver, Copyright (c) 2000 - 2003 Broadcom */
/* Corporation. */
/* All rights reserved. */
/* */
/* This program is free software; you can redistribute it and/or modify */
/* it under the terms of the GNU General Public License as published by */
/* the Free Software Foundation, located in the file LICENSE. */
/* */
/* (c) COPYRIGHT 2001-2004 Broadcom Corporation, ALL RIGHTS RESERVED. */
/* */
/* Name: F W _ L S O 0 5. H */
/* Author : Kevin Tran */
/* Version: 1.2 */
/* */
/* Module Description: This file contains firmware binary code of TCP */
/* Segmentation firmware (BCM5705). */
/* */
/* History: */
/* 08/10/02 Kevin Tran Incarnation. */
/* 02/02/04 Kevin Tran Added Support for BCM5788. */
/******************************************************************************/
The above copyright statement clearly places the firmware blob under the GPL,
and makes the whole file undistributable without providing also the source
code, that is the prefered form of modification, of the firmware code in
question.
There are two solutions to this issue, either you abide by the GPL and provide
also the source code of those firmware binaries (the prefered solution :), or
you modify the copyright statement of these files, to indicate that even
thought the file per se is under the GPL, the firmware binary code is not, and
give us a licence to distribute it. Something akin to :
/******************************************************************************/
/* */
/* Broadcom BCM5700 Linux Network Driver, Copyright (c) 2000 - 2003 Broadcom */
/* Corporation. */
/* All rights reserved. */
/* */
/* This program, except the firmware binary code, is free software; you can */
/* redistribute it and/or modify it under the terms of the GNU General Public */
/* License as published by the Free Software Foundation, located in the file */
/* LICENSE. */
/* Distribution, either as is or modified syntactically to adapt to the */
/* layout of the surrounding GPLed code is allowed, provided this copyright */
/* notice is acompanying it */
/* */
/* (c) COPYRIGHT 2001-2004 Broadcom Corporation, ALL RIGHTS RESERVED. */
/* */
/* Name: F W _ L S O 0 5. H */
/* Author : Kevin Tran */
/* Version: 1.2 */
/* */
/* Module Description: This file contains firmware binary code of TCP */
/* Segmentation firmware (BCM5705). */
/* */
/* History: */
/* 08/10/02 Kevin Tran Incarnation. */
/* 02/02/04 Kevin Tran Added Support for BCM5788. */
/******************************************************************************/
Or something else such acceptable to your legal department.
In hope of hearing from you soon, and that a quick resolution of this problem
can be achieved,
Friendly,
Sven Luther
[1] -- http://lists.debian.org/debian-legal/2005/03/msg00283.html
[2] -- http://lists.debian.org/debian-legal/2005/04/msg00047.html
On Apr 5, 2005 9:36 AM, Marcel Holtmann <[email protected]> wrote:
> People are also working on a replacement for the
> current request_firmware(), because the needs are changing. Try to keep
> it close with the usb-serial for now.
>
Could you elaborate on what do you think is needed? I have some of
patches to firmware loader and wondering if we should coordinate out
efforts. I have
1. convert from using a timer to wait_for_comletion_timeout which
simplifies logic
2. tightening of state transition rules and removing possible memory
leak (very unlikely)
3. converting firmware_priv to fw_class_dev to simplify memory management.
4. removing request_firmware_nowait as noone seems to be using it -
and I doubt one would ever want to request firmware from an interrupt.
5. Creating firmware class in a separate thread to work around selinux
(with prism54 firmware is loaded when interface is configured and thus
firware loader runs in context of /sbin/ip which may not have access
to sysfs. Having separate thread will ensure that firmware loader runs
in kernel context).
And I was thinking about caching firmware (siomething like if you do
"echo 2 > /sys/class/firmware/blah/loading" instead of 0 it will keep
a copy of the firmware in memory. One could see all firmwares in
/sys/class/firmware/loaded/<xxx> and by erase cached firmware by
echoing 0 into it).
What do you think?
--
Dmitry
On Tue, Apr 05, 2005 at 04:36:31PM +0200, Marcel Holtmann wrote:
> > > I agree with Dmitry on this point. The IHEX parser should not be inside
> > > firmware_class.c. What about using keyspan_ihex.[ch] for it?
> >
> > That's what I had originally, actually called firmware_ihex.ko, since
> > the IHEX format parser is not in any way keyspan specific and there are
> > several usb-serial converters that seem to use the same IHEX->.h trick
> > which could trivially be modified to use this loader.
> >
> > But the compiled parser fairly small (< 2KB) and adding it to the
> > existing module didn't effectively add any size to the firmware_class
> > module since things are rounded to a page boundary anyways.
>
> so it seems that this is usb-serial specific at the moment. Then I would
I really don't see the point you are trying to argue. I said, sure it is
possible to make it a separate module, that is what my initial
implementation was. Why do you want to pigeon-hole it with anything but
the existing firmware loading code?
It is _not_ usb-serial specific, in fact once the device is initialized
this isn't even needed. And the initialization as far as I can see uses
little or no usb-serial code.
It happens that many usb-serial devices are built around the ezusb
chipset, which in turn seems to be a 8051-based microcontroller. The
compilers for such microcontrollers seem to generate IHEX formatted
output possibly because eprom burners generally support the format.
> it up at the moment. People are also working on a replacement for the
> current request_firmware(), because the needs are changing. Try to keep
> it close with the usb-serial for now.
What? I find the existing request_firmware fairly simple and
straightforward, it has a very KISS-like quality to it, it is nice and
small and even the userspace support is trivial. I only saw a mention
about 'replacing' it in the current thread which mostly involved
complaints but didn't actually see anyone volunteering to start working
on such a replacement.
If a driver wants to load 5 different chunks, just call request_firmware
5 times (i.e. drivers/bluetooth/bcm203x.c). If the data is a single
binary blob, just ask for the single binary blob. In this case there
seems to be some structure to the blob that I wanted to preserve, and
that would either be some custom binary format that contains
[<address><length><data>]... tuples, which ofcourse causes problems for
our big-endian brothers, or a similar ascii format, where the IHEX is
not only pretty much standardized, it is trivial to parse and even adds
checksum information.
The only thing that I see missing right now is a change to the makefiles
to have in-tree firmware files get installed in /lib/modules/`uname
-r`/firmware or some similar place. Ideally people would add a line
like,
fw-$(CONFIG_FOO) = foo-firmware-blob.fw
And make install could drop it a place where hotplug can find it.
Jan
Hi Dmitry,
> > People are also working on a replacement for the
> > current request_firmware(), because the needs are changing. Try to keep
> > it close with the usb-serial for now.
> >
>
> Could you elaborate on what do you think is needed? I have some of
> patches to firmware loader and wondering if we should coordinate out
> efforts. I have
>
> 1. convert from using a timer to wait_for_comletion_timeout which
> simplifies logic
> 2. tightening of state transition rules and removing possible memory
> leak (very unlikely)
> 3. converting firmware_priv to fw_class_dev to simplify memory management.
> 4. removing request_firmware_nowait as noone seems to be using it -
> and I doubt one would ever want to request firmware from an interrupt.
> 5. Creating firmware class in a separate thread to work around selinux
> (with prism54 firmware is loaded when interface is configured and thus
> firware loader runs in context of /sbin/ip which may not have access
> to sysfs. Having separate thread will ensure that firmware loader runs
> in kernel context).
>
> And I was thinking about caching firmware (siomething like if you do
> "echo 2 > /sys/class/firmware/blah/loading" instead of 0 it will keep
> a copy of the firmware in memory. One could see all firmwares in
> /sys/class/firmware/loaded/<xxx> and by erase cached firmware by
> echoing 0 into it).
>
> What do you think?
actually there is a thread about firmware loading rewrite and POST
calling of programs. It must be on LKML or the hotplug mailing list.
However my backlog for the interesting topics of these lists increased
while I was traveling the last 5-6 weeks. I think you should simply
start a new one on LKML.
Regards
Marcel
On Tue, Apr 05, 2005 at 04:05:07PM +0200, Josselin Mouette wrote:
> Le lundi 04 avril 2005 ? 21:32 +0200, Adrian Bunk a ?crit :
> > On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote:
> > > On Apr 04, Greg KH <[email protected]> wrote:
> > >
> > > > What if we don't want to do so? I know I personally posted a solution
> > > Then probably the extremists in Debian will manage to kill your driver,
> > > like they did with tg3 and others.
> >
> > And as they are doing with e.g. the complete gcc documentation.
> >
> > No documentation for the C compiler (not even a documentation of the
> > options) will be neither fun for the users of Debian nor for the Debian
> > maintainers - but it's the future of Debian...
>
> You are mixing apples and oranges. The fact that the GFDL sucks has
> nothing to do with the firmware issue. With the current situation of
> firmwares in the kernel, it is illegal to redistribute binary images of
> the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
> be willing to distribute such binary images, but it isn't our problem.
>
> Putting the firmwares outside the kernel makes them distributable. Some
> distributions will want to include them, some others not. But the
> important point is that it makes that redistribution legal.
Nope, in this case, the place where those firmware blobs are found are totally
irelevant, since we reached consensus on debian-legal in marsh that they
constitute mere agregation, where either the file or the elf binary are just
the distribution media.
And those binary blobs currently come under the GPL or are not licenced at
all, so taking them out of the kernel doesn't make them distributable in any
way.
Friendly,
Sven Luther
On Tue, 5 Apr 2005, Humberto Massa wrote:
> Josselin Mouette wrote:
>
>> You are mixing apples and oranges. The fact that the GFDL sucks has
>> nothing to do with the firmware issue. With the current situation of
>> firmwares in the kernel, it is illegal to redistribute binary images of
>> the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
>> be willing to distribute such binary images, but it isn't our problem.
>>
Wrong! It is perfectly legal in the United States, and I'm pretty
sure in your country, to distribute or redistribute copyrighted
works. Otherwise there wouldn't be any bookstores or newspaper
stands.
There is nothing about firmware that is any different than any
other component of a product. If the product was legally obtained
and it requires firmware to run, then there are no special
considerations about how one inserts the firmware into the
product.
If you are a GPL-religious-zealot who believes that you are
supposed to get the technical design (i.e. the software schematics)
of the hardware device for free so you can copy it, then you are
going to have to learn something about intellectual property.
The firmware, in most cases, are the bits generated by a design
program that creates the function of the device. It's what the
manufacturer paid 5-10 engineers over a period of a year or so
to produce. The rest of the design is just some chips you
can get off-the-shelf. Even if the manufacturer said; "Here you
are.... You can have the design....". You don't have the
"compilers" and other stuff necessary to turn this design
into the firmware unless you planned to steal the design.
So, you either accept the firmware component, thanking the
manufacturer for it, or you go cry foul someplace else. This
whole firmware thing is a non-issue, blown way out of
proportion by people who don't have a clue.
Sometimes a manufacturer doesn't have a separate bag-of-bits
to supply competing operating systems. Instead, only one
"driver" for one OS was produced by the manufacturer.
Extracting those bits, from offset-N to offset-M in that
driver likely constitutes fair use as long as the product
wasn't stolen and the driver was distributed with the
product, or was publicly available.
>>
> Yes, GFDL has nothing to do with the main issue. No, it is not
> necessarily illegal to redistribute binary images of the kernel as they
> are today (see below). The first problem is that they (the complete
> w/firmware kernel binary images) are not DFSG-free, anyway. The second
> problem is that some firmware blobs don't have explicitly stated in the
> kernel tree which exactly are their licensing terms for redistribution
> -- those are, in principle, undistributable.
>
>> Putting the firmwares outside the kernel makes them distributable. Some
>> distributions will want to include them, some others not. But the
>> important point is that it makes that redistribution legal.
>>
>>
> If putting the firmwares outside the kernel makes *them* distributable,
> then the binary kernel image is already distributable -- just not
> DFSG-free. The important fact WRT Debian, IMHO, is that putting the
> firmwares outside the kernel makes the kernel binary image DFSG-free.
>
> HTH,
> Massa
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
On Apr 5, 2005 6:45 AM, Jan Harkes <[email protected]> wrote:
> On Tue, Apr 05, 2005 at 11:22:06AM +0200, Marcel Holtmann wrote:
> > I agree with Dmitry on this point. The IHEX parser should not be inside
> > firmware_class.c. What about using keyspan_ihex.[ch] for it?
>
> That's what I had originally, actually called firmware_ihex.ko, since
> the IHEX format parser is not in any way keyspan specific and there are
> several usb-serial converters that seem to use the same IHEX->.h trick
> which could trivially be modified to use this loader.
>
> But the compiled parser fairly small (< 2KB) and adding it to the
> existing module didn't effectively add any size to the firmware_class
> module since things are rounded to a page boundary anyways.
>
It is not about the size, it is about source separation. Since it has
nothing to do with actualy loading of a BLOB from userspace to kernel
space I'd put it into lib/, like crc functions, etc. It does not
really have to work with "struct firmware *", "void *data, size_t len"
should be just as useable.
--
Dmitry
Hi Jan,
> > > > I agree with Dmitry on this point. The IHEX parser should not be inside
> > > > firmware_class.c. What about using keyspan_ihex.[ch] for it?
> > >
> > > That's what I had originally, actually called firmware_ihex.ko, since
> > > the IHEX format parser is not in any way keyspan specific and there are
> > > several usb-serial converters that seem to use the same IHEX->.h trick
> > > which could trivially be modified to use this loader.
> > >
> > > But the compiled parser fairly small (< 2KB) and adding it to the
> > > existing module didn't effectively add any size to the firmware_class
> > > module since things are rounded to a page boundary anyways.
> >
> > so it seems that this is usb-serial specific at the moment. Then I would
>
> I really don't see the point you are trying to argue. I said, sure it is
> possible to make it a separate module, that is what my initial
> implementation was. Why do you want to pigeon-hole it with anything but
> the existing firmware loading code?
the existing request_firmware() has nothing in common with IHEX parser
and such a parser should not belong there. So either make it a separate
module or add it to the module that is using it. In this case this is
the keyspan module or the usb-serial core.
> It is _not_ usb-serial specific, in fact once the device is initialized
> this isn't even needed. And the initialization as far as I can see uses
> little or no usb-serial code.
>
> It happens that many usb-serial devices are built around the ezusb
> chipset, which in turn seems to be a 8051-based microcontroller. The
> compilers for such microcontrollers seem to generate IHEX formatted
> output possibly because eprom burners generally support the format.
Then make it at separate module.
> > it up at the moment. People are also working on a replacement for the
> > current request_firmware(), because the needs are changing. Try to keep
> > it close with the usb-serial for now.
>
> What? I find the existing request_firmware fairly simple and
> straightforward, it has a very KISS-like quality to it, it is nice and
> small and even the userspace support is trivial. I only saw a mention
> about 'replacing' it in the current thread which mostly involved
> complaints but didn't actually see anyone volunteering to start working
> on such a replacement.
>
> If a driver wants to load 5 different chunks, just call request_firmware
> 5 times (i.e. drivers/bluetooth/bcm203x.c). If the data is a single
> binary blob, just ask for the single binary blob. In this case there
> seems to be some structure to the blob that I wanted to preserve, and
> that would either be some custom binary format that contains
> [<address><length><data>]... tuples, which ofcourse causes problems for
> our big-endian brothers, or a similar ascii format, where the IHEX is
> not only pretty much standardized, it is trivial to parse and even adds
> checksum information.
I am not going to repeat the current arguments and it is not about
loading multiple firmware files (btw I wrote the bcm203x). Check the
mailing list archives for the details. I still need to catch up with the
discussion, but there is some ongoing work.
> The only thing that I see missing right now is a change to the makefiles
> to have in-tree firmware files get installed in /lib/modules/`uname
> -r`/firmware or some similar place. Ideally people would add a line
> like,
>
> fw-$(CONFIG_FOO) = foo-firmware-blob.fw
>
> And make install could drop it a place where hotplug can find it.
This is another approach and if you want something like that, then send
a patch for it and let Sam and others comment on it.
Regards
Marcel
Richard B. Johnson wrote:
>On Tue, 5 Apr 2005, Humberto Massa wrote:
>
>>Josselin Mouette wrote:
>>
>>>You are mixing apples and oranges. The fact that the GFDL sucks has
>>>nothing to do with the firmware issue. With the current situation of
>>>firmwares in the kernel, it is illegal to redistribute binary images
>>>of the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may
>>>still be willing to distribute such binary images, but it isn't our
>>>problem.
>
>Wrong! It is perfectly legal in the United States, and I'm pretty sure
>in your country, to distribute or redistribute copyrighted works.
>Otherwise there wouldn't be any bookstores or newspaper stands.
Oops, you are missing important stuff here: the book publishers and the
newspaper/magazine editors have EXPLICIT PERMISSION by the copyright
holders to distribute the copyrighted works.
Now, the bookstores and newspapers stands have IMPLICIT permission to
distribute them because of the Doctrine of First Sale (roughly: if you
buy a legally printed book you can sell the same book; you can sell your
WinXP box with everything you bought inside).
Other than the doctrine of First Sale, and, in the USofA, some cases
covered by Fair Use, copyrighted works can only be distributed by their
authors/owners (*) and by people explicitly authorized to do so.
And, other than the Fair Use rights and similar statutory rights in
other jurisdictions, only the authors/owners of copyrighted works have
the right to create derivative works, too.
(*) owners because copyrights can be transferred.
>There is nothing about firmware that is any different than any other
>component of a product. If the product was legally obtained and it
>requires firmware to run, then there are no special considerations
>about how one inserts the firmware into the product.
Except for the fact that there may be EULA clauses in the firmware that
came with the product, or in the software that came with the product and
is (in that other OS) in charge of loading said firmware.
And the fact that software is covered by different laws in different
countries, too.
>If you are a GPL-religious-zealot who believes that you are supposed to
>get the technical design (i.e. the software schematics) of the hardware
>device for free so you can copy it, then you are going to have to learn
>something about intellectual property.
I am not. And please don't use those words. Copyrights, trademarks,
patents and trade secrets are limited rights, not properties.
>The firmware, in most cases, are the bits generated by a design program
>that creates the function of the device. It's what the manufacturer
>paid 5-10 engineers over a period of a year or so to produce. The rest
>of the design is just some chips you can get off-the-shelf. Even if the
>manufacturer said; "Here you are.... You can have the design....". You
>don't have the "compilers" and other stuff necessary to turn this
>design into the firmware unless you planned to steal the design.
This makes a lot of sense.
>So, you either accept the firmware component, thanking the manufacturer
>for it, or you go cry foul someplace else.
Right on, sister.
>This whole firmware thing is a non-issue, blown way out of proportion
>by people who don't have a clue.
Naah, there is some serious issues here. Read on for more.
>Sometimes a manufacturer doesn't have a separate bag-of-bits to supply
>competing operating systems. Instead, only one "driver" for one OS was
>produced by the manufacturer. Extracting those bits, from offset-N to
>offset-M in that driver likely constitutes fair use as long as the
>product wasn't stolen and the driver was distributed with the product,
>or was publicly available.
You are not 100% right on this. Let's see: first, "fair use" is a
doctrine that is not widespread in non-USofA jurisdictions; second,
extracting those bits constitutes creating a derivative work, which is
not allowed without explicit consent of the copyright owner; and third,
you would have to get a judge to consider this fair use to be on the
safe side, ie -- not really practical.
Even if you were 100% right on this, neither kernel.org nor debian.org
would have the right to redistribute said firmware without explicit
consent of the copyright owner. It would be completely free (even
DFSG-free) if d-i or some other kernel installer asked for the diskette
that came with the user's device and extracted the bits in the moment of
the extraction... but it would not be very practical, would it? It
would be better if your install could be done without such hoops.
Even in the case that the copyright owner gave explicit consent for,
say, kernel.org to redistribute its firmware (or even gave consent for
Debian to redistribute its firmware) the firmware could not be in
debian/main because this would not be DFSG-free.
>>Yes, GFDL has nothing to do with the main issue. No, it is not
>>necessarily illegal to redistribute binary images of the kernel as
>>they are today (see below). The first problem is that they (the
>>complete w/firmware kernel binary images) are not DFSG-free, anyway.
>>The second problem is that some firmware blobs don't have explicitly
>>stated in the kernel tree which exactly are their licensing terms for
>>redistribution -- those are, in principle, undistributable.
>>
>>>Putting the firmwares outside the kernel makes them distributable.
>>>Some distributions will want to include them, some others not. But
>>>the important point is that it makes that redistribution legal.
>>>
>>>
>>If putting the firmwares outside the kernel makes *them*
>>distributable, then the binary kernel image is already distributable
>>-- just not DFSG-free. The important fact WRT Debian, IMHO, is that
>>putting the firmwares outside the kernel makes the kernel binary image
>>DFSG-free.
>>
>>HTH, Massa
>
>
>
>Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine
>(5537.79 BogoMips). Notice : All mail here is now cached for review by
>Dictator Bush. 98.36% of all statistics are fiction.
>
Just so you know I'm not really talking out of my rear end, IANAL, but I
have four years of legal training, and I have worked two years as a
paralegal in a DA's office, and I am married to a DA (married for eight
years, she is a DA for eleven years) whom I ask some legal insight from
time to time. Yes, I know how to do legal research. Ok, my jurisdiction
is not the same as yours [our laws are generally saner :-) even if our
law enforcement is often not].
HTH,
Massa
Sven Luther <[email protected]> said:
> On Tue, Apr 05, 2005 at 08:16:48AM -0400, Jeff Garzik wrote:
> > Humberto Massa wrote:
> > >But, the question made here was a subtler one and you are all biting
> > >around the bush: there *are* some misrepresentations of licenses to the
> > >firmware blobs in the kernel (-- ok, *if* you consider that hex dumps
> > >are not source code). What Sven asked was: "Hey, can I state explicitly
> > >the distribution state in the source files, by means of adding some
> > >comments?".
> >
> > >I think even a clarification "this firmware hexdump is considered to be
> > >the source code, and it's GPL'd" would do, but I must put my asbestos
> > >suit everytime I say it. :-)
> >
> > We do not add comments to the kernel source code which simply state the
> > obvious.
>
> The only thing here is that it has to be obvious not only to you, but to the
> judge too :)
>
> In this case, it is not comments, but proper copyright attribution, which was
> added in the tg3.c case since the first checkin :
>
> /*
> * tg3.c: Broadcom Tigon3 ethernet driver.
> *
> * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller ([email protected])
> * Copyright (C) 2001, 2002, 2003 Jeff Garzik ([email protected])
> * Copyright (C) 2004 Sun Microsystems Inc.
> *
> * Firmware is:
> * Copyright (C) 2000-2003 Broadcom Corporation.
> */
>
> The firmware part was not present in the original checkin you did in 2002.
> Adding something about the licencing status of it would be enough.
>
> Or even adding some comment in the toplevel COPYING file saying that firmware
> blobs come under their own licence or something such, and then listing all the
> firmware blobs and their licencing condition in a separate toplevel file would
> be enough.
>
> Friendly,
>
> Sven Luther
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Le mardi 05 avril 2005 à 11:50 -0400, Richard B. Johnson a écrit :
> >> You are mixing apples and oranges. The fact that the GFDL sucks has
> >> nothing to do with the firmware issue. With the current situation of
> >> firmwares in the kernel, it is illegal to redistribute binary images of
> >> the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
> >> be willing to distribute such binary images, but it isn't our problem.
> >>
>
> Wrong! It is perfectly legal in the United States, and I'm pretty
> sure in your country, to distribute or redistribute copyrighted
> works. Otherwise there wouldn't be any bookstores or newspaper
> stands.
It is not legal to distribute the mix of a GPL software (the Linux
kernel) and a proprietary file (the firmware). I wasn't aware of the
"mere aggregation" interpretation, and I'm probably a bit late to say I
disagree with it - mainly because you'd have a hard time convincing a
court this is the case.
> There is nothing about firmware that is any different than any
> other component of a product. If the product was legally obtained
> and it requires firmware to run, then there are no special
> considerations about how one inserts the firmware into the
> product.
Indeed, but that's not what I'm talking about.
> If you are a GPL-religious-zealot who believes that you are
> supposed to get the technical design (i.e. the software schematics)
> of the hardware device for free so you can copy it, then you are
> going to have to learn something about intellectual property.
Maybe you should try to understand what people are saying before
teaching them anything.
> The firmware, in most cases, are the bits generated by a design
> program that creates the function of the device. It's what the
> manufacturer paid 5-10 engineers over a period of a year or so
> to produce. The rest of the design is just some chips you
> can get off-the-shelf. Even if the manufacturer said; "Here you
> are.... You can have the design....". You don't have the
> "compilers" and other stuff necessary to turn this design
> into the firmware unless you planned to steal the design.
>
> So, you either accept the firmware component, thanking the
> manufacturer for it, or you go cry foul someplace else. This
> whole firmware thing is a non-issue, blown way out of
> proportion by people who don't have a clue.
You are completely missing the point. I don't care whether the firmwares
should be free, or whether they could be free. The fact is they are not
free, and Debian doesn't distribute non-free software in the "main"
archive. The fact is also that mixing them with a GPLed software gives
an result you can't redistribute - although it seems many people
disagree with that assertion now.
Finally, you shouldn't forget that, technically speaking, using hotplug
for uploading the firmware is much more flexible and elegant than
including it in the kernel. Upgrading the firmware and the module should
be two independent operations. People who are advocating the current
situation are refusing technical improvements just because they are
brought by people they find convenient to call "zealots".
--
.''`. Josselin Mouette /\./\
: :' : [email protected]
`. `' [email protected]
`- Debian GNU/Linux -- The power of freedom
Le mardi 05 avril 2005 à 14:17 -0400, Richard B. Johnson a écrit :
> > You are completely missing the point. I don't care whether the firmwares
> > should be free, or whether they could be free. The fact is they are not
> > free, and Debian doesn't distribute non-free software in the "main"
> > archive. The fact is also that mixing them with a GPLed software gives
> > an result you can't redistribute - although it seems many people
> > disagree with that assertion now.
>
> As previously explained, if I buy a screen-card I get a driver
> that will allow it to run under Windows. If I extract the stuff
> from that driver that allows me to run it under Linux, that
> constitutes fair use. Otherwise there are criminal issues like
> restraint-of-trade and similar problems for the manufacturer.
> That firmware is free for use on/in the device you purchased.
You are mixing free beer and free speech. Of course I'm free to use it
in the device I purchased, but it is nevertheless unsuitable for the
Debian main archive, where there is only free software.
> > Finally, you shouldn't forget that, technically speaking, using hotplug
> > for uploading the firmware is much more flexible and elegant than
> > including it in the kernel. Upgrading the firmware and the module should
> > be two independent operations. People who are advocating the current
> > situation are refusing technical improvements just because they are
> > brought by people they find convenient to call "zealots".
>
> Throwing in a bit of truth to a pile of bullshit still leaves
> the bullshit. It isn't relevant to the issue whether or not
> upgrading firmware as a separate function from loading a module
> is "good" or "bad".
Of course it is. If the proposed solution is technically better and
pleases the so-called zealots, why are you discussing it at all?
--
.''`. Josselin Mouette /\./\
: :' : [email protected]
`. `' [email protected]
`- Debian GNU/Linux -- The power of freedom
Josselin Mouette wrote:
> The fact is also that mixing them with a GPLed software gives
> an result you can't redistribute - although it seems many people
> disagree with that assertion now.
This is only true if the result is considered a "derivative work" of the
gpl'd code.
The GPL states "In addition, mere aggregation of another work not based
on the Program with the Program (or with a work based on the Program) on
a volume of a storage or distribution medium does not bring the other
work under the scope of this License."
Since the main cpu does not actually run the binary firmware, the fact
that it lives in main memory with the code that the cpu *does* run is
irrelevent. In this case, the Debian stance is that the kernel proper
and the binary firmware are "merely aggregated" in a volume of storage (
ie. system memory).
Chris
Le mardi 05 avril 2005 à 12:50 -0600, Chris Friesen a écrit :
> Josselin Mouette wrote:
>
> > The fact is also that mixing them with a GPLed software gives
> > an result you can't redistribute - although it seems many people
> > disagree with that assertion now.
>
> This is only true if the result is considered a "derivative work" of the
> gpl'd code.
>
> The GPL states "In addition, mere aggregation of another work not based
> on the Program with the Program (or with a work based on the Program) on
> a volume of a storage or distribution medium does not bring the other
> work under the scope of this License."
>
> Since the main cpu does not actually run the binary firmware, the fact
> that it lives in main memory with the code that the cpu *does* run is
> irrelevent. In this case, the Debian stance is that the kernel proper
> and the binary firmware are "merely aggregated" in a volume of storage (
> ie. system memory).
It merely depends on the definition of "aggregation". I'd say that two
works that are only aggregated can be easily distinguished and
separated. This is not the case for a binary kernel module, from which
you cannot easily extract the firmware and code parts.
--
.''`. Josselin Mouette /\./\
: :' : [email protected]
`. `' [email protected]
`- Debian GNU/Linux -- The power of freedom
Josselin Mouette wrote:
>It merely depends on the definition of "aggregation". I'd say that two
>works that are only aggregated can be easily distinguished and
>separated. This is not the case for a binary kernel module, from which
>you cannot easily extract the firmware and code parts.
>
>
Not really... As a matter of fact, it's quite easy to separate those
parts, at least as easy as it is to separate one story inside a book
that contains an anthology of short stories. And the latter is not
considered a derivative work, either.
Massa
Josselin Mouette wrote:
> Finally, you shouldn't forget that, technically speaking, using hotplug
> for uploading the firmware is much more flexible and elegant than
> including it in the kernel. Upgrading the firmware and the module should
> be two independent operations. People who are advocating the current
> situation are refusing technical improvements just because they are
> brought by people they find convenient to call "zealots".
This is highly amusing, coming from someone who does not maintain a
driver with a firmware.
The current firmware infrastructure is too primitive. Compiling the
firmware into the driver is much easier on the driver maintainers and
users, presently.
Repeating myself,
* Most firmwares are a -collection- of images and data. The firmware
infrastructure should load an -archive- of firmwares and associated data
values.
* The firmware distribution infrastructure is basically non-existent.
There is no standard way to make sure that a firmware separated from the
driver gets to all users.
* The firmware bundling infrastructure is basically non-existent.
(Arjan talked about this) There needs to be a a way to ensure that the
needed firmwares are automatically added to initramfs/initrd.
* There is no chicken-and-egg problem as Arjan mentions. Once the above
technical problems are resolved, its trivial to apply a firmware loading
patch. I believe in hard transitions, not shipping tg3 with firmware
-and- a firmware loading patch.
* Firmwares such as tg3 should be shipped with the kernel tarball.
In short, there are plenty of technical problems to resolve before this
is even a reasonable request. Currently, a user upgrading to a tg3 sans
firmware will simply get tg3 sans firmware.
Jeff
> * The firmware distribution infrastructure is basically non-existent.
> There is no standard way to make sure that a firmware separated from the
> driver gets to all users.
>
> * The firmware bundling infrastructure is basically non-existent.
> (Arjan talked about this) There needs to be a a way to ensure that the
> needed firmwares are automatically added to initramfs/initrd.
>
> * There is no chicken-and-egg problem as Arjan mentions.
actually there is; you just perfectly described it. Until we have
drivers that can use such firmware (and need it in initrds and the like)
infrastructure for that is unlikely to come into existence, and until
there is such infrastructure, driver authors like you are unlikely to
want to transition to loading firmware. Now there is also your other
point about the request_firmware() interface being too primitive, and
that sure sounds valid. So to move forward two things need to happen
1) the infrastructure needs expanding to be useful for more drivers
2) the chicken and egg stalemate needs breaking. One way to do that is
to have dual-mode drivers for a while (eg drivers that request_firmware
() and if that fails, use the built-in firmware) so that the other
outside-the-kernel infrastructure can be developed and deployed.
On Tue, Apr 05, 2005 at 09:40:24PM +0200, Arjan van de Ven wrote:
>
> > * The firmware distribution infrastructure is basically non-existent.
> > There is no standard way to make sure that a firmware separated from the
> > driver gets to all users.
> >
> > * The firmware bundling infrastructure is basically non-existent.
> > (Arjan talked about this) There needs to be a a way to ensure that the
> > needed firmwares are automatically added to initramfs/initrd.
> >
> > * There is no chicken-and-egg problem as Arjan mentions.
>
> actually there is; you just perfectly described it. Until we have
> drivers that can use such firmware (and need it in initrds and the like)
> infrastructure for that is unlikely to come into existence, and until
> there is such infrastructure, driver authors like you are unlikely to
> want to transition to loading firmware. Now there is also your other
> point about the request_firmware() interface being too primitive, and
> that sure sounds valid. So to move forward two things need to happen
>
> 1) the infrastructure needs expanding to be useful for more drivers
>
> 2) the chicken and egg stalemate needs breaking. One way to do that is
> to have dual-mode drivers for a while (eg drivers that request_firmware
> () and if that fails, use the built-in firmware) so that the other
> outside-the-kernel infrastructure can be developed and deployed.
The tg3 firmware should be delivered with the kernel; and any
infrastructure that does not continue to work seamlessly with
firmware-separate-from-tg3 is a non-starter. That's why I say there's
no chicken-and-egg: presumption of such implies half a solution.
Dual mode drivers are only useful for the 1-2 developers working on
firmware loading.
Someone needs to make the effort to create and test a solution, rather
than half measures which -do- imply a c-and-e problem.
Jeff
On Tue, 5 Apr 2005, Josselin Mouette wrote:
> Le mardi 05 avril 2005 ?? 11:50 -0400, Richard B. Johnson a ??crit :
>>>> You are mixing apples and oranges. The fact that the GFDL sucks has
>>>> nothing to do with the firmware issue. With the current situation of
>>>> firmwares in the kernel, it is illegal to redistribute binary images of
>>>> the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
>>>> be willing to distribute such binary images, but it isn't our problem.
>>>>
>>
>> Wrong! It is perfectly legal in the United States, and I'm pretty
>> sure in your country, to distribute or redistribute copyrighted
>> works. Otherwise there wouldn't be any bookstores or newspaper
>> stands.
>
> It is not legal to distribute the mix of a GPL software (the Linux
> kernel) and a proprietary file (the firmware). I wasn't aware of the
> "mere aggregation" interpretation, and I'm probably a bit late to say I
> disagree with it - mainly because you'd have a hard time convincing a
> court this is the case.
>
>> There is nothing about firmware that is any different than any
>> other component of a product. If the product was legally obtained
>> and it requires firmware to run, then there are no special
>> considerations about how one inserts the firmware into the
>> product.
>
> Indeed, but that's not what I'm talking about.
>
>> If you are a GPL-religious-zealot who believes that you are
>> supposed to get the technical design (i.e. the software schematics)
>> of the hardware device for free so you can copy it, then you are
>> going to have to learn something about intellectual property.
>
> Maybe you should try to understand what people are saying before
> teaching them anything.
>
>> The firmware, in most cases, are the bits generated by a design
>> program that creates the function of the device. It's what the
>> manufacturer paid 5-10 engineers over a period of a year or so
>> to produce. The rest of the design is just some chips you
>> can get off-the-shelf. Even if the manufacturer said; "Here you
>> are.... You can have the design....". You don't have the
>> "compilers" and other stuff necessary to turn this design
>> into the firmware unless you planned to steal the design.
>>
>> So, you either accept the firmware component, thanking the
>> manufacturer for it, or you go cry foul someplace else. This
>> whole firmware thing is a non-issue, blown way out of
>> proportion by people who don't have a clue.
>
> You are completely missing the point. I don't care whether the firmwares
> should be free, or whether they could be free. The fact is they are not
> free, and Debian doesn't distribute non-free software in the "main"
> archive. The fact is also that mixing them with a GPLed software gives
> an result you can't redistribute - although it seems many people
> disagree with that assertion now.
>
As previously explained, if I buy a screen-card I get a driver
that will allow it to run under Windows. If I extract the stuff
from that driver that allows me to run it under Linux, that
constitutes fair use. Otherwise there are criminal issues like
restraint-of-trade and similar problems for the manufacturer.
That firmware is free for use on/in the device you purchased.
> Finally, you shouldn't forget that, technically speaking, using hotplug
> for uploading the firmware is much more flexible and elegant than
> including it in the kernel. Upgrading the firmware and the module should
> be two independent operations. People who are advocating the current
> situation are refusing technical improvements just because they are
> brought by people they find convenient to call "zealots".
Throwing in a bit of truth to a pile of bullshit still leaves
the bullshit. It isn't relevant to the issue whether or not
upgrading firmware as a separate function from loading a module
is "good" or "bad".
> --
> .''`. Josselin Mouette /\./\
> : :' : [email protected]
> `. `' [email protected]
> `- Debian GNU/Linux -- The power of freedom
>
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
> > actually there is; you just perfectly described it. Until we have
> > drivers that can use such firmware (and need it in initrds and the like)
> > infrastructure for that is unlikely to come into existence, and until
> > there is such infrastructure, driver authors like you are unlikely to
> > want to transition to loading firmware. Now there is also your other
> > point about the request_firmware() interface being too primitive, and
> > that sure sounds valid. So to move forward two things need to happen
> >
> > 1) the infrastructure needs expanding to be useful for more drivers
> >
> > 2) the chicken and egg stalemate needs breaking. One way to do that is
> > to have dual-mode drivers for a while (eg drivers that request_firmware
> > () and if that fails, use the built-in firmware) so that the other
> > outside-the-kernel infrastructure can be developed and deployed.
>
> The tg3 firmware should be delivered with the kernel; and any
> infrastructure that does not continue to work seamlessly with
> firmware-separate-from-tg3 is a non-starter.
I'm not arguing that
> That's why I say there's
> no chicken-and-egg: presumption of such implies half a solution.
I think you haven't read what I wrote. The part that makes up the
chicken-and-egg problem is the part where there is no infrastructure to
USE such firmware in initrds, to distribute it with the kernel image
etc.
> Dual mode drivers are only useful for the 1-2 developers working on
> firmware loading.
and for the distro people who need to get their distro to do this sort
of thing very smoothly. It also, to put it bluntly, shuts the "fanatics"
up because they have their solution immediately, while others that may
need more time to get their distro ready, have such more time. I don't
have the illusion that any distro will do the infrastructure work if
there are no drivers that are going to use it. Nor do I have the
illusion that driver writers will make a hard switch until such
infrastructure is out there en masse.
Note that I don't even mention anything about not shipping the firmware
in the kernel tarbal. It might be an option in the end, depending on how
the infrastructure developers; but that is not part of the stalemate
that I see. You seem to be focused on only that thing, but to be honest,
for me that is the least interesting/controversial part.
Brian Gerst wrote:
> Jeff Garzik wrote:
>
>> Josselin Mouette wrote:
>>
>>> Finally, you shouldn't forget that, technically speaking, using hotplug
>>> for uploading the firmware is much more flexible and elegant than
>>> including it in the kernel. Upgrading the firmware and the module should
>>> be two independent operations. People who are advocating the current
>>> situation are refusing technical improvements just because they are
>>> brought by people they find convenient to call "zealots".
>>
>>
>>
>> This is highly amusing, coming from someone who does not maintain a
>> driver with a firmware.
>>
>> The current firmware infrastructure is too primitive. Compiling the
>> firmware into the driver is much easier on the driver maintainers and
>> users, presently.
>>
>> Repeating myself,
>>
>> * Most firmwares are a -collection- of images and data. The firmware
>> infrastructure should load an -archive- of firmwares and associated
>> data values.
>
>
> The firmware interface should only be concerned with getting the blob of
> data into kernel space. Once it is in kernel space the driver can parse
> out whatever archive format it is in. Take for example the ihex code
> that was posted recently. Similar code could be written to parse out a
> tarball, cpio archive, etc.
The archive format for firmware data collections must be standardized,
and generic code for loading such collections needs to be written, not
duplicated into each driver.
Obviously the driver-specific data inside the archive is, as the phrase
implies, driver-specific.
Jeff
Jeff Garzik wrote:
> Brian Gerst wrote:
>
>> Jeff Garzik wrote:
>>
>>> Josselin Mouette wrote:
>>>
>>>> Finally, you shouldn't forget that, technically speaking, using hotplug
>>>> for uploading the firmware is much more flexible and elegant than
>>>> including it in the kernel. Upgrading the firmware and the module
>>>> should
>>>> be two independent operations. People who are advocating the current
>>>> situation are refusing technical improvements just because they are
>>>> brought by people they find convenient to call "zealots".
>>>
>>>
>>>
>>>
>>> This is highly amusing, coming from someone who does not maintain a
>>> driver with a firmware.
>>>
>>> The current firmware infrastructure is too primitive. Compiling the
>>> firmware into the driver is much easier on the driver maintainers and
>>> users, presently.
>>>
>>> Repeating myself,
>>>
>>> * Most firmwares are a -collection- of images and data. The firmware
>>> infrastructure should load an -archive- of firmwares and associated
>>> data values.
>>
>>
>>
>> The firmware interface should only be concerned with getting the blob
>> of data into kernel space. Once it is in kernel space the driver can
>> parse out whatever archive format it is in. Take for example the ihex
>> code that was posted recently. Similar code could be written to parse
>> out a tarball, cpio archive, etc.
>
>
> The archive format for firmware data collections must be standardized,
> and generic code for loading such collections needs to be written, not
> duplicated into each driver.
I never said code shouldn't be standardized or shared. I just said that
it is a seperate function from the process of transferring the data from
userspace to kernel space. That said, initramfs already uses cpio, so
that would be a good choice to use.
--
Brian Gerst
[MFT set to -legal, as this is becoming legal arcana probably not
particularly interesting to any other list.]
On Tue, 05 Apr 2005, Sven Luther wrote:
> There are two solutions to this issue, either you abide by the GPL
> and provide also the source code of those firmware binaries (the
> prefered solution :), or you modify the copyright statement of these
> files, to indicate that even thought the file per se is under the
> GPL, the firmware binary code is not, and give us a licence to
> distribute it. Something akin to :
>
> /* This program, except the firmware binary code, is free software; you can */
> /* redistribute it and/or modify it under the terms of the GNU General Public */
> /* License as published by the Free Software Foundation, located in the file */
> /* LICENSE. */
> /* Distribution, either as is or modified syntactically to adapt to the */
> /* layout of the surrounding GPLed code is allowed, provided this copyright */
> /* notice is acompanying it */
Just a word of warning: The wording above fails to make it clear what
the second clause is applying to. Additionally it has the following
restrictions that are probably not intended:
1) Does not specifically allow this firware to be sold as part of an
aggregate
2) The range of modifications allowed is rather vague, and implies
that the firmware can't be extracted
I'd instead suggest applying a pre-existing license like MIT[1] to the
firmware portion of the code file, rather than inventing your own
licensing text that only partially deals with the problem(s) at issue.
(Inventing licensing text is quite often very hazardous to your
health.)
Don Armstrong
1: http://www.opensource.org/licenses/mit-license.php
--
Build a fire for a man, an he'll be warm for a day. Set a man on
fire, and he'll be warm for the rest of his life.
-- Jules Bean
http://www.donarmstrong.com http://rzlab.ucr.edu
Jeff Garzik wrote:
> Josselin Mouette wrote:
>
>> Finally, you shouldn't forget that, technically speaking, using hotplug
>> for uploading the firmware is much more flexible and elegant than
>> including it in the kernel. Upgrading the firmware and the module should
>> be two independent operations. People who are advocating the current
>> situation are refusing technical improvements just because they are
>> brought by people they find convenient to call "zealots".
>
>
> This is highly amusing, coming from someone who does not maintain a
> driver with a firmware.
>
> The current firmware infrastructure is too primitive. Compiling the
> firmware into the driver is much easier on the driver maintainers and
> users, presently.
>
> Repeating myself,
>
> * Most firmwares are a -collection- of images and data. The firmware
> infrastructure should load an -archive- of firmwares and associated data
> values.
The firmware interface should only be concerned with getting the blob of
data into kernel space. Once it is in kernel space the driver can parse
out whatever archive format it is in. Take for example the ihex code
that was posted recently. Similar code could be written to parse out a
tarball, cpio archive, etc.
--
Brian Gerst
On Tue, Apr 05, 2005 at 08:56:09PM +0200, Josselin Mouette wrote:
> Le mardi 05 avril 2005 ? 12:50 -0600, Chris Friesen a ?crit :
> > Josselin Mouette wrote:
> >
> > > The fact is also that mixing them with a GPLed software gives
> > > an result you can't redistribute - although it seems many people
> > > disagree with that assertion now.
> >
> > This is only true if the result is considered a "derivative work" of the
> > gpl'd code.
> >
> > The GPL states "In addition, mere aggregation of another work not based
> > on the Program with the Program (or with a work based on the Program) on
> > a volume of a storage or distribution medium does not bring the other
> > work under the scope of this License."
> >
> > Since the main cpu does not actually run the binary firmware, the fact
> > that it lives in main memory with the code that the cpu *does* run is
> > irrelevent. In this case, the Debian stance is that the kernel proper
> > and the binary firmware are "merely aggregated" in a volume of storage (
> > ie. system memory).
>
> It merely depends on the definition of "aggregation". I'd say that two
> works that are only aggregated can be easily distinguished and
> separated. This is not the case for a binary kernel module, from which
> you cannot easily extract the firmware and code parts.
Josselin, please read the thread i linked to in debian-legal, and as nobody
really gave reason to oppose it, i believe we have consensus that those
firmware blobs constitute mere agregation, provided they are clearly
identified and properly licenced, which they are not always.
Let's take this to debian-legal only if you want to further discuss it.
Friendly,
Sven Luther
Le mercredi 06 avril 2005 ? 02:10 +0200, Sven Luther a ?crit :
> > It merely depends on the definition of "aggregation". I'd say that two
> > works that are only aggregated can be easily distinguished and
> > separated. This is not the case for a binary kernel module, from which
> > you cannot easily extract the firmware and code parts.
>
> Josselin, please read the thread i linked to in debian-legal, and as nobody
> really gave reason to oppose it, i believe we have consensus that those
> firmware blobs constitute mere agregation, provided they are clearly
> identified and properly licenced, which they are not always.
The fact that nobody cared to answer you shouldn't be considered as any
kind of approval for your sayings.
--
.''`. Josselin Mouette /\./\
: :' : [email protected]
`. `' [email protected]
`- Debian GNU/Linux -- The power of freedom
On Wed, Apr 06, 2005 at 09:34:44AM +0200, Josselin Mouette wrote:
> Le mercredi 06 avril 2005 ? 02:10 +0200, Sven Luther a ?crit :
> > > It merely depends on the definition of "aggregation". I'd say that two
> > > works that are only aggregated can be easily distinguished and
> > > separated. This is not the case for a binary kernel module, from which
> > > you cannot easily extract the firmware and code parts.
> >
> > Josselin, please read the thread i linked to in debian-legal, and as nobody
> > really gave reason to oppose it, i believe we have consensus that those
> > firmware blobs constitute mere agregation, provided they are clearly
> > identified and properly licenced, which they are not always.
>
> The fact that nobody cared to answer you shouldn't be considered as any
> kind of approval for your sayings.
There were a couple of replies, but if you are going to argue this, please
read the analysis i made, and reply to it. Read in particular :
http://lists.debian.org/debian-legal/2005/03/msg00288.html
Which contains a more formal analysis from Humberto Massa.
So, given that this thread together with the GPLed firmware flasher thread got
a respectable amount of replies, i believe we can claim consensus, and this is
something the debian-kernel team has been acting upon, and i believe even
aknowledged by the release managers and ftp-masters.
If you have strong evidence that this is not the case, it would really have
been nice to comment on it before the kernel team (not only me which you may
dislike for past dealings or whatever) waste effort on something which is
wrong in the first place, and i commend you to participate in the above thread
asap, voicing your concerns (or remain silent forever thereafter :).
Friendly,
Sven Luther
On Tue, 5 April 2005 15:28:01 -0400, Jeff Garzik wrote:
>
> * Firmwares such as tg3 should be shipped with the kernel tarball.
As in /usr/src/linux/firmware/tg3.tar? Would be a simple patch to add
that one.
J?rn
--
The cost of changing business rules is much more expensive for software
than for a secretaty.
-- unknown
On Tue, Apr 05, 2005 at 03:28:01PM -0400, Jeff Garzik wrote:
> * Most firmwares are a -collection- of images and data. The firmware
> infrastructure should load an -archive- of firmwares and associated data
> values.
Why don't you use multiple firmware loading calls with different
names? Maybe adding a "group" name, or simply adding a '/' in the
name. That way the userspace half will have the choice between using
directories, tar, zip or whatever. The speedtouch driver already
requests multiple files, having them together in one file is a
userspace problem which the kernel can help but shouldn't try to solve.
>
> * The firmware distribution infrastructure is basically non-existent.
> There is no standard way to make sure that a firmware separated from the
> driver gets to all users.
That's the price how having non-gpl compatible firmware though.
> * The firmware bundling infrastructure is basically non-existent.
> (Arjan talked about this) There needs to be a a way to ensure that the
> needed firmwares are automatically added to initramfs/initrd.
Yes. See following too.
> * There is no chicken-and-egg problem as Arjan mentions. Once the above
> technical problems are resolved, its trivial to apply a firmware loading
> patch. I believe in hard transitions, not shipping tg3 with firmware
> -and- a firmware loading patch.
An infrastructure to add a number of files to the kernel image (_not_
the initrd/initramfs) which can be found through internal kernel
calls, firmware loading and probably an export in /proc would be nice.
Unifying DSDT override, config.gz and early firmware could be nice.
> * Firmwares such as tg3 should be shipped with the kernel tarball.
Does it change between kernel versions? How often?
OG.
> Josselin Mouette wrote:
> >It merely depends on the definition of "aggregation". I'd say that two
> >works that are only aggregated can be easily distinguished and
> >separated. This is not the case for a binary kernel module, from which
> >you cannot easily extract the firmware and code parts.
On Tue, Apr 05, 2005 at 04:00:32PM -0300, Humberto Massa wrote:
> Not really... As a matter of fact, it's quite easy to separate those
> parts, at least as easy as it is to separate one story inside a book
> that contains an anthology of short stories. And the latter is not
> considered a derivative work, either.
I'm not sure who it is that doesn't consider anthologies a
derivative work. The u.s. copyright office considers anthologies
and other compilations derivative works except when they involve
insufficient creative work to grant them copyright protection.
http://www.copyright.gov/circs/circ14.pdf
But it's probably not interesting to argue any further about the inner
workings of copyright law. Pretty much everyone seems to agree on what
the right approach is, here. The big issue seems to be stability of
linux during the transition.
The interesting topics, at this point, have to do with the details of
migrating such drivers out of the kernel.
--
Raul
On Llu, 2005-04-04 at 21:47, Jeff Garzik wrote:
> Bluntly, Debian is being a pain in the ass ;-)
>
> There will always be non-free firmware to deal with, for key hardware.
Firmware being seperate does make a lot of sense. It isn't going away
but it doesn't generally belong in kernel now we have initrd and
firmware loaders.
Alan
>>>>> "Sven" == Sven Luther <[email protected]> writes:
Sven> On Mon, Apr 04, 2005 at 12:21:05PM +0200, Arjan van de Ven
Sven> wrote:
>> On Mon, 2005-04-04 at 12:09 +0200, Sven Luther wrote:
>>
>> please take this discussion elsewhere. Also please never cc three
>> such
Sven> Ok, can you please point to me where is the place it should be
Sven> taken off ? I suppose you mean LKML ?
Yes please!
>> lists on the same posting, there is absolutely no point in doing
>> that.
Sven> We already had this discussion on debian-legal and
Sven> debian-kernel, so i included them for documentation purpose, so
Sven> people there can follow the discussion even if they don't follow
Sven> LKML which is rather high volume. As the discussion already was
Sven> hold there, i don't believe you will see many comments from
Sven> them.
Sven> So, i posted to LKML directly, as i believe that it is where
Sven> this needs to be solved, as only the copyright holders can fix
Sven> this licencing problem, and currently the kernels distributed
Sven> from ftp.kernel.org are not legally distributable.
Feel free to have your own legal oppinion about whether or not those
kernels can be distributed. However please keep that discussion
elsewhere.
If you want the firmware situation changed, I'd recommend spending
your time on improving the firmware loader interface instead.
Thanks,
Jes
>>>>> "Matthew" == Matthew Wilcox <[email protected]> writes:
Matthew> On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote:
>> Then let's see some acts. We (lkml) are not the ones with the
>> percieved problem, or the ones discussing it.
Matthew> Actually, there are some legitimate problems with some of the
Matthew> files in the Linux source base. Last time this came up, the
Matthew> Acenic firmware was mentioned:
Matthew> http://lists.debian.org/debian-legal/2004/12/msg00078.html
Matthew> Seems to me that situation is still not resolved.
Well whoever wrote that seems to have taken the stand that the
openfirmware package was were the firmware came from. The person
obviously made a lot of statements without bothering checking out the
real source. Well it didn't come from there, I got it from Alteon
under a written agreement stating I could distribute the image under
the GPL. Since the firmware is simply data to Linux, hence keeping it
under the GPL should be just fine.
If someone wishes to post a patch adding a GPL header to the
acenic_firmware.h file, fine with me. But beyond that I consider the
case closed.
Regards,
Jes
>>>>> "Jeff" == Jeff Garzik <[email protected]> writes:
Jeff> Sven Luther wrote:
>> Yep, but in the meantime, let's clearly mark said firmware as
>> not-covered-by-the-GPL. In the acenic case it seems to be even
>> easier, as the firmware is in a separate acenic_firmware.h file,
>> and it just needs to have the proper licencing statement added,
>> saying that it is not covered by the GPL, and then giving the
>> information under what licence it is being distributed.
Jeff> Who has meaningfully contacted Alteon (probably "Neterion" now)
Jeff> about this? What is the progress of that request?
Whoever actually owns the rights to the firmware these days is going
to be practically impossible to track down. The rights were sold off
left and right when Alteon sold out to Nortel and Nortel then
imploded.
The s2io/neterion guys may or may not know, but I doubt anyone is
willing to spend real company manhours trying to track down a legal
trace for a dead product which hasn't been manufactured for years and
nobody really cares about technology wise anymore.
Regards,
Jes
Arjan van de Ven <[email protected]> writes:
> On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote:
> > On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote:
> > > I don't think you did get a rejection, a few people said that _they_
> > > weren't going to do it, but if you want to then go ahead. I think people
> > > are just fed up of people bringing up the issue and then failing to do
> > > anything about it -- so prove them wrong ;-)
> >
> > Actually patches to add firmware loader support to tg3 got rejected.
>
> I think they will be accepted if they first introduce a transition
> period where tg3 will do request_firmware() and only use the built-in
> firmware if that fails. Second step is to make the built-in firmware a
> config option and then later on when the infrastructure matures for
> firmware loading/providing firmware it can be removed from the driver
> entirely.
For tg3 a transition period shouldn't be needed as firmware loading
is only needed on old/buggy hardware which is not the common case.
Or to support advanced features which can be disabled.
I am fairly certain in that case the firmware came from the bcm5701
broadcom driver for the tg3 which I think is gpl'd. So the firmware
may legitimately be under the GPL.
Eric
On Thursday 07 April 2005 09:25, Jes Sorensen wrote:
> [snip] I got it from Alteon
> under a written agreement stating I could distribute the image under
> the GPL. Since the firmware is simply data to Linux, hence keeping it
> under the GPL should be just fine.
Then I would like to exercise my right under the GPL to aquire the source code
for the firmware (and the required compilers, starting with genfw.c which is
mentioned in acenic_firmware.h) since - as far as I know - firmware is coded
today in VHDL, C or some assembler and the days of hexcoding are long gone.
Regards, David
Le jeudi 07 avril 2005 à 10:04 +0200, David Schmitt a écrit :
> Then I would like to exercise my right under the GPL to aquire the source code
> for the firmware (and the required compilers, starting with genfw.c which is
> mentioned in acenic_firmware.h) since - as far as I know - firmware is coded
> today in VHDL, C or some assembler and the days of hexcoding are long gone.
VHDL is a hardware description language. You don't code firmware in
VHDL.
Xav
> Well whoever wrote that seems to have taken the stand that the
> openfirmware package was were the firmware came from. The person
> obviously made a lot of statements without bothering checking out the
> real source. Well it didn't come from there, I got it from Alteon
> under a written agreement stating I could distribute the image under
> the GPL. Since the firmware is simply data to Linux, hence keeping it
> under the GPL should be just fine.
You cannot distribute anything under the GPL if you cannot also distribute
the source code (the preferred form of the software for the purpose of
making modifications to it). How Linux sees it is irrelevant. For any piece
of software, one can imagine some processor that can only see it as data.
The GPL doesn't distinguish between processors.
Alteon's written agreement notwithstanding, you cannot distribute the
firmware under the GPL if you cannot provide the preferred form of the
firmware for the purpose of making modifications to it. The firmware does
not run on Linux, so saying "linux sees it as data" is as absurd as saying I
can distribute the x86 Linux kernel without the source because my calculator
can only see it as data.
You cannot distribute the firmware binary under the GPL. Period.
Now, if you were trying to say that you could aggregate the firmware with
another work and distribute the result under the GPL, the test would be
whether the final result is "mere aggregation" or not. This is a
fantastically tricky question and I don't think anyone on this list could
give you particularly useful guidance.
My own opinion is that it's a threshold issue based upon several factors.
For example -- has the firmware been specifically designed to work with the
Linux driver or is it "generic" firmware? If you can't take the thing you're
distributing (the combined binary) and extract two works from it (the
firmware and the work whose source you are offering), I cannot see how you
can claim it's mere aggregation.
If you believe the linker "merely aggregates" the object code for the
driver with the data for the firmware, I can't see how you can argue that
any linking is anything but mere aggregation. In neither case can you
separate the linked work into the two separate works and in both cases the
linker provides one work direct access to the other.
If you only distribute the source to the driver and don't put a GPL notice
in the files that contain the firmware data, I think you're okay. I think
you're asking for trouble if you distribute a combined compiled/linked
driver.
DS
On Thu, Apr 07, 2005 at 10:17:15AM +0200, Xavier Bestel wrote:
> Le jeudi 07 avril 2005 ? 10:04 +0200, David Schmitt a ?crit :
>
> > Then I would like to exercise my right under the GPL to aquire the source code
> > for the firmware (and the required compilers, starting with genfw.c which is
> > mentioned in acenic_firmware.h) since - as far as I know - firmware is coded
> > today in VHDL, C or some assembler and the days of hexcoding are long gone.
>
> VHDL is a hardware description language. You don't code firmware in
> VHDL.
If the firmware, or part of it, is uploaded to a fpga you do (or
Verilog instead of VHDL, same difference).
OG.
Le jeudi 07 avril 2005 à 10:32 +0200, Olivier Galibert a écrit :
> On Thu, Apr 07, 2005 at 10:17:15AM +0200, Xavier Bestel wrote:
> > Le jeudi 07 avril 2005 à 10:04 +0200, David Schmitt a écrit :
> >
> > > Then I would like to exercise my right under the GPL to aquire the source code
> > > for the firmware (and the required compilers, starting with genfw.c which is
> > > mentioned in acenic_firmware.h) since - as far as I know - firmware is coded
> > > today in VHDL, C or some assembler and the days of hexcoding are long gone.
> >
> > VHDL is a hardware description language. You don't code firmware in
> > VHDL.
>
> If the firmware, or part of it, is uploaded to a fpga you do (or
> Verilog instead of VHDL, same difference).
Oh yes, I was dense.
Xav
Eric W. Biederman wrote:
> Arjan van de Ven <[email protected]> writes:
>
>
>>On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote:
>>
>>>On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote:
>>>
>>>>I don't think you did get a rejection, a few people said that _they_
>>>>weren't going to do it, but if you want to then go ahead. I think people
>>>>are just fed up of people bringing up the issue and then failing to do
>>>>anything about it -- so prove them wrong ;-)
>>>
>>>Actually patches to add firmware loader support to tg3 got rejected.
>>
>>I think they will be accepted if they first introduce a transition
>>period where tg3 will do request_firmware() and only use the built-in
>>firmware if that fails. Second step is to make the built-in firmware a
>>config option and then later on when the infrastructure matures for
>>firmware loading/providing firmware it can be removed from the driver
>>entirely.
>
>
> For tg3 a transition period shouldn't be needed as firmware loading
> is only needed on old/buggy hardware which is not the common case.
> Or to support advanced features which can be disabled.
TSO firmware is commonly used these days.
> I am fairly certain in that case the firmware came from the bcm5701
> broadcom driver for the tg3 which I think is gpl'd. So the firmware
> may legitimately be under the GPL.
It is.
Jeff
On Thu, Apr 07, 2005 at 05:34:56AM -0400, Jeff Garzik wrote:
> >For tg3 a transition period shouldn't be needed as firmware loading
> >is only needed on old/buggy hardware which is not the common case.
> >Or to support advanced features which can be disabled.
>
> TSO firmware is commonly used these days.
Because our TSO support has been totally broken for a long time?
On Wed, Apr 06, 2005 at 01:22:36PM -0600, Eric W. Biederman wrote:
> Arjan van de Ven <[email protected]> writes:
>
> > On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote:
> > > On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote:
> > > > I don't think you did get a rejection, a few people said that _they_
> > > > weren't going to do it, but if you want to then go ahead. I think people
> > > > are just fed up of people bringing up the issue and then failing to do
> > > > anything about it -- so prove them wrong ;-)
> > >
> > > Actually patches to add firmware loader support to tg3 got rejected.
> >
> > I think they will be accepted if they first introduce a transition
> > period where tg3 will do request_firmware() and only use the built-in
> > firmware if that fails. Second step is to make the built-in firmware a
> > config option and then later on when the infrastructure matures for
> > firmware loading/providing firmware it can be removed from the driver
> > entirely.
>
> For tg3 a transition period shouldn't be needed as firmware loading
> is only needed on old/buggy hardware which is not the common case.
> Or to support advanced features which can be disabled.
>
> I am fairly certain in that case the firmware came from the bcm5701
> broadcom driver for the tg3 which I think is gpl'd. So the firmware
> may legitimately be under the GPL.
So, where is the source for it ?
Friendly,
Sven Luther
Hi Jes, long time without hearing about you :)
On Thu, Apr 07, 2005 at 03:17:33AM -0400, Jes Sorensen wrote:
> Sven> On Mon, Apr 04, 2005 at 12:21:05PM +0200, Arjan van de Ven
> Sven> wrote:
>
> Sven> Ok, can you please point to me where is the place it should be
> Sven> taken off ? I suppose you mean LKML ?
>
> Yes please!
Why ? It does concern you all, doesn't it ? or we will be working to get the
actual firmware problem solved, and then people will introduce new problematic
firmware case.
> If you want the firmware situation changed, I'd recommend spending
> your time on improving the firmware loader interface instead.
Which will not help without the copyright licencing issue being solved first
though, as we do not have any right to distribute most of those firmwares.
And no, we are not only bringing this issue and bothering everyone else, we
are also doing the work needed to solve the issue with upstream, see :
http://wiki.debian.net/?KernelFirmwareLicensing
Friendly,
Sven Luther
David Schwartz wrote:
>>Well whoever wrote that seems to have taken the stand that
>>the openfirmware package was were the firmware came from.
>>The person obviously made a lot of statements without
>>bothering checking out the real source. Well it didn't come
>>from there, I got it from Alteon under a written agreement
>>stating I could distribute the image under the GPL. Since
>>the firmware is simply data to Linux, hence keeping it under
>>the GPL should be just fine.
>
>
>You cannot distribute anything under the GPL if you cannot
>also distribute the source code (the preferred form of the
>software for the purpose of making modifications to it). How
>Linux sees it is irrelevant. For any piece of software, one
>can imagine some processor that can only see it as data. The
>GPL doesn't distinguish between processors.
I think this is undisputed.
>Alteon's written agreement notwithstanding, you cannot
>distribute the firmware under the GPL if you cannot provide
>the preferred form of the firmware for the purpose of making
>modifications to it. The firmware does not run on Linux, so
>saying "linux sees it as data" is as absurd as saying I can
>distribute the x86 Linux kernel without the source because my
>calculator can only see it as data.
>
>You cannot distribute the firmware binary under the GPL.
>Period.
This is where you are wrong IMMHO. All that is needed for you
to distribute the hexdump blob under the GPL is a declaration
from the copyright holder saying "this, to me, is the
preferred form for modification of the firmware and hence the
source code under the GPL."
>Now, if you were trying to say that you could aggregate the
>firmware with another work and distribute the result under
>the GPL, the test would be whether the final result is "mere
>aggregation" or not. This is a fantastically tricky question
>and I don't think anyone on this list could give you
>particularly useful guidance.
After a *lot* of discussion, it was deliberated on d-l that
this is not that tricky at all, and that the "mere
aggregation" clause applies to the combination, for various
reasons, with a great degree of safety. (Safer than that,
only after court) :-)
>My own opinion is that it's a threshold issue based upon
>several factors. For example -- has the firmware been
>specifically designed to work with the Linux driver or is it
>"generic" firmware? If you can't take the thing you're
>distributing (the combined binary) and extract two works from
>it (the firmware and the work whose source you are offering),
>I cannot see how you can claim it's mere aggregation.
Now, if the firmware was specifically designed to work with
the linux driver, than it *is* a derivative work on the kernel
as a whole and the source code should be provided upon
redistribution as per GPL section 3 etc.
*BUT* this does not preclude Broadcom from stating: "our
engineers generated by hand the hex codes that make our
hardware work."
>If you believe the linker "merely aggregates" the object code
>for the driver with the data for the firmware, I can't see
>how you can argue that any linking is anything but mere
>aggregation. In neither case can you separate the linked work
>into the two separate works and in both cases the linker
>provides one work direct access to the other.
No-one is saying that the linker "merely aggregates" object
code for the driver; what *is* being said is: in the case of
firmware, especially if the firmware is neither a derivative
work on the kernel (see above) nor the firmware includes part
of the kernel (duh), it is *fairly* *safe* to consider the
intermixing of firmware bytes with kernel binary image bytes
in an ELF object file as mere aggregation.
>If you only distribute the source to the driver and don't put
>a GPL notice in the files that contain the firmware data, I
>think you're okay. I think you're asking for trouble if you
>distribute a combined compiled/linked driver.
Disagreed.
>DS
HTH,
Massa
David Schmitt wrote:
> On Thursday 07 April 2005 09:25, Jes Sorensen wrote:
>
> > [snip] I got it from Alteon under a written agreement stating I
> > could distribute the image under the GPL. Since the firmware is
> > simply data to Linux, hence keeping it under the GPL should be just
> > fine.
>
>
> Then I would like to exercise my right under the GPL to aquire the
> source code for the firmware (and the required compilers, starting
> with genfw.c which is mentioned in acenic_firmware.h) since - as far
> as I know - firmware is coded today in VHDL, C or some assembler and
> the days of hexcoding are long gone.
First, there is *NOT* any requirement in the GPL at all that requires
making compilers available. Otherwise it would not be possible, for
instance, have a Visual Basic GPL'd application. And yes, it is possible.
Second, up until the present day I have personal experience with
hardware producers that do not have enough money to buy expensive
toolchains and used a lot of hand-work to code hardware parameters. So,
at least for them, hand-hexcoding-days are still going.
HTH,
Massa
On Thu, 7 Apr 2005, Humberto Massa wrote:
> David Schmitt wrote:
>
>> On Thursday 07 April 2005 09:25, Jes Sorensen wrote:
>>
>>> [snip] I got it from Alteon under a written agreement stating I
>>> could distribute the image under the GPL. Since the firmware is
>>> simply data to Linux, hence keeping it under the GPL should be just
>>> fine.
>>
>>
>> Then I would like to exercise my right under the GPL to aquire the
>> source code for the firmware (and the required compilers, starting
>> with genfw.c which is mentioned in acenic_firmware.h) since - as far
>> as I know - firmware is coded today in VHDL, C or some assembler and
>> the days of hexcoding are long gone.
>
> First, there is *NOT* any requirement in the GPL at all that requires
> making compilers available. Otherwise it would not be possible, for
> instance, have a Visual Basic GPL'd application. And yes, it is possible.
>
> Second, up until the present day I have personal experience with
> hardware producers that do not have enough money to buy expensive
> toolchains and used a lot of hand-work to code hardware parameters. So,
> at least for them, hand-hexcoding-days are still going.
>
> HTH,
>
> Massa
Well it doesn't make any difference. If GPL has degenerated to
where one can't upload microcode to a device as part of its
initialization, without having the "source" that generated that
microcode, we are in a lot of hurt. Intel isn't going to give their
designs away.
Last time I checked, GPL was about SOFTware, not FIRMware, and
not MICROcode. If somebody has decided to rename FIRMware to
SOFTware, then they need to complete the task and call it DORKware,
named after themselves.
This whole thread and gotten truly bizarre.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips).
Notice : All mail here is now cached for review by Dictator Bush.
98.36% of all statistics are fiction.
>>>>> "Richard" == Richard B Johnson <[email protected]> writes:
Richard> Last time I checked, GPL was about SOFTware, not FIRMware,
Richard> and not MICROcode.
Oh be real, there's no real difference between them and you know it.
It's all about where the bits are stored and what they tend to do in a
system design that makes the difference.
This entire arguement is meaningless until someone posts the patches
to move firmware out of the kernel, and until I see that, it's not
worth re-hashing. And no, I don't have the time or knowledge to do
this.
John
"Richard B. Johnson" <[email protected]> writes:
> Last time I checked, GPL was about SOFTware, not FIRMware, and
> not MICROcode. If somebody has decided to rename FIRMware to
> SOFTware,
Debian has undertaken to change the meaning of a whole lot of words,
including "software" and "free".
> This whole thread and gotten truly bizarre.
Surprised?
--
M?ns Rullg?rd
[email protected]
Le jeudi 07 avril 2005 ? 09:03 -0400, Richard B. Johnson a ?crit :
> Well it doesn't make any difference. If GPL has degenerated to
> where one can't upload microcode to a device as part of its
> initialization, without having the "source" that generated that
> microcode, we are in a lot of hurt. Intel isn't going to give their
> designs away.
The GPL doesn't forbid that. The GPL forbids to put this microcode
directly in the same binary as the GPL code. Of course, nothing forbids
some GPL'ed code to take a binary elsewhere and to upload it into the
hardware.
At least that's my opinion; AIUI, Sven Luther believes it is possible if
the firmware has a decent (but not necessarily free) license.
--
.''`. Josselin Mouette /\./\
: :' : [email protected]
`. `' [email protected]
`- Debian GNU/Linux -- The power of freedom
Richard B. Johnson wrote:
> Well it doesn't make any difference. If GPL has degenerated to where
> one can't upload microcode to a device as part of its initialization,
> without having the "source" that generated that microcode, we are in
> a lot of hurt. Intel isn't going to give their designs away.
I don't recall anyone asking Intel to give theirs designs away. This
thread is about:
1. (mainly) some firmware hexdumps present in the kernel source tree are
either expicitly marked as being GPL'd or unmarked, in which case one
would assume that they would be GPL'd;
1a. this means that those firmware hexdumps are not legally
distributable by any person besides the firmware copyright holder,
because any other person could not comply with the terms of the Section
3 of the GPL (IOW, a third party cannot give you a source code they
don't have);
1b. [1a], for its turn, means that the current pristine kernel tree is
not legally distributable and that any distributor is an easy prey for
lawyer attacks.
2. (collaterally) some firmware hexdumps present in the kernel source
tree are marked with "(C) Holder All Rights Reserved";
2a. copyright law FORBIDS anyone to distribute such pieces of
information without proper authorization.
3. (corolary) for each of the problematic hexdumps, the following steps
should be taken:
3a. the copyright holder should be asked for the source code to the
firmware -- if they do this, it would be great for a lot of Free
Software reasons;
3b. if the copyright holder declines, it should be asked for a license
to freely redistribute the firmware; and
3c. if the copyright holder declines, the firmware *must* be yanked from
the pristine kernel tree;
3d. furthermore, all of this *should* be properly documented, IMHO, both
in a centralized file, and in the file where the firmware hexdump appears.
> Last time I checked, GPL was about SOFTware, not FIRMware, and not
> MICROcode. If somebody has decided to rename FIRMware to SOFTware,
> then they need to complete the task and call it DORKware, named after
> themselves.
Last time I checked, the GPL was a COPYRIGHT LICENSE and, as such, not
"about" anything in particular. Yes, it was idealized to be used for the
licensing of computer programs and libraries. OTOH, many works of many
other kinds (music, literary works, etc) were licensed under the GPL.
> This whole thread and gotten truly bizarre.
Nah, it has a good reason to exist... With the passing of time, Debian,
that is supposed to be a Free Software OS, is depending more and more of
non-Free components. And yes, as it is today, the pristine kernel tree
is non-free.
Regards,
Massa
Am Donnerstag, 7. April 2005 16:30 schrieb Humberto Massa:
> I don't recall anyone asking Intel to give theirs designs away. This
> thread is about:
>
> 1. (mainly) some firmware hexdumps present in the kernel source tree are
> either expicitly marked as being GPL'd or unmarked, in which case one
> would assume that they would be GPL'd;
>
> 1a. this means that those firmware hexdumps are not legally
> distributable by any person besides the firmware copyright holder,
> because any other person could not comply with the terms of the Section
> 3 of the GPL (IOW, a third party cannot give you a source code they
> don't have);
As this has been discussed numerous times and consensus never achieved
and is unlikely to be achieved, I suggest that you keep this discussion
internal to Debian until at least you have patches which can be evaluated
and discussed. Until then Debian may do to its kernel whatever it pleases
and should be prepared to explain to its users why it removed or altered
drivers.
Regards
Oliver
Oliver Neukum wrote:
>
> As this has been discussed numerous times and consensus never
> achieved and is unlikely to be achieved, I suggest that you keep this
> discussion internal to Debian until at least you have patches which
> can be evaluated and discussed. Until then Debian may do to its
> kernel whatever it pleases and should be prepared to explain to its
> users why it removed or altered drivers.
>
> Regards Oliver
>
Hi, Oliver.
You seemed to answer my e-mail without reading it; what I was explaining
in it was: this is not a matter of patches, but of asking Where are the
copyrights notices, Who are the copyright owners, and Which license are
the firmwares under, and AFTER that, patching what should be patched.
Those three questions (Where, Who, Which) can only be answered by the
kernel maintainers, and this is in *NO* way a Debian-only discussion. As
I mentioned before, kernel.org kernel tree is, as of today, non-free and
undistributable IMHO.
HTH,
Massa
Am Donnerstag, 7. April 2005 17:01 schrieb Humberto Massa:
> Oliver Neukum wrote:
>
> >
> > As this has been discussed numerous times and consensus never
> > achieved and is unlikely to be achieved, I suggest that you keep this
> > discussion internal to Debian until at least you have patches which
> > can be evaluated and discussed. Until then Debian may do to its
> > kernel whatever it pleases and should be prepared to explain to its
> > users why it removed or altered drivers.
> >
> > Regards Oliver
> >
>
> Hi, Oliver.
>
> You seemed to answer my e-mail without reading it; what I was explaining
> in it was: this is not a matter of patches, but of asking Where are the
> copyrights notices, Who are the copyright owners, and Which license are
> the firmwares under, and AFTER that, patching what should be patched.
>
> Those three questions (Where, Who, Which) can only be answered by the
> kernel maintainers, and this is in *NO* way a Debian-only discussion. As
> I mentioned before, kernel.org kernel tree is, as of today, non-free and
> undistributable IMHO.
Those who care got you after the second message at the latest.
Anything more just annoys people. Some even pay for their online time.
Who doesn't care will not start caring. Your oppinion on that matter frankly
is exactly that.
If you care that deeply about it you'll have to track down copyright
holders yourself. Good luck.
Regards
Oliver
Sven Luther <[email protected]> writes:
> On Wed, Apr 06, 2005 at 01:22:36PM -0600, Eric W. Biederman wrote:
> > For tg3 a transition period shouldn't be needed as firmware loading
> > is only needed on old/buggy hardware which is not the common case.
> > Or to support advanced features which can be disabled.
> >
> > I am fairly certain in that case the firmware came from the bcm5701
> > broadcom driver for the tg3 which I think is gpl'd. So the firmware
> > may legitimately be under the GPL.
>
> So, where is the source for it ?
The GPL'd driver that broadcom distributes. The history of tg3.c
is that broadcom's bcm57xx driver drove the hardware correctly but
not linux so it was rewritten from scratch.
Beyond that you need to talk to Broadcom. But if the originator
of the bits distributes them gpl from a redistribution point the
kernel is fine.
It sounds like you are now looking at the question of are the
huge string of hex characters the preferred form for making
modifications to firmware. Personally I would be surprised
but those hunks are small enough it could have been written
in machine code.
So I currently have no reason to believe that anything has been
done improperly with that code.
Eric
On Thu, Apr 07, 2005 at 05:46:27AM -0600, Eric W. Biederman wrote:
> Sven Luther <[email protected]> writes:
>
> > On Wed, Apr 06, 2005 at 01:22:36PM -0600, Eric W. Biederman wrote:
> > > For tg3 a transition period shouldn't be needed as firmware loading
> > > is only needed on old/buggy hardware which is not the common case.
> > > Or to support advanced features which can be disabled.
> > >
> > > I am fairly certain in that case the firmware came from the bcm5701
> > > broadcom driver for the tg3 which I think is gpl'd. So the firmware
> > > may legitimately be under the GPL.
> >
> > So, where is the source for it ?
>
> The GPL'd driver that broadcom distributes. The history of tg3.c
> is that broadcom's bcm57xx driver drove the hardware correctly but
> not linux so it was rewritten from scratch.
Ok, thanks for that clarification.
> Beyond that you need to talk to Broadcom. But if the originator
> of the bits distributes them gpl from a redistribution point the
> kernel is fine.
As you may know, i have contacted Broadcom about this issue, the information
passed from the driver support contact to their linux developers, but i have
not heard from them yet.
> It sounds like you are now looking at the question of are the
> huge string of hex characters the preferred form for making
> modifications to firmware. Personally I would be surprised
> but those hunks are small enough it could have been written
> in machine code.
Yep, i also think it is in broadcom's best interest to modify the licencing
text accordyingly, since i suppose someone could technicaly come after them
legally to obtain said source code to this firmware. Unprobable though.
> So I currently have no reason to believe that anything has been
> done improperly with that code.
Well, it all depends if you consider this firmware blob as software, which i
feel it is without doubt, or we have not the same definition of software,
i.e., the program which runs on the hardware, or not. We cannot claim this is data,
since there should be at least some kind of executable code in it,
independenlty of the fact that we claim that data is also software.
Thanks for the info, i will add it to the Wiki.
Friendly,
Sven Luther
On Thu, Apr 07, 2005 at 01:26:17AM -0700, David Schwartz wrote:
> If you believe the linker "merely aggregates" the object code for the
> driver with the data for the firmware, I can't see how you can argue
> that any linking is anything but mere aggregation. In neither case can
> you separate the linked work into the two separate works and in both
> cases the linker provides one work direct access to the other.
You can indeed separate the firmware and the kernel into two separate
works. That's what people have been proposing as the solution to this
problem.
Also, "mere aggregation" is a term from the GPL. You can read what
it says there yourself. But basically it's there so that people make
a distinction between the program itself and other stuff that isn't
the program.
Without that mere aggregation clause, people might be claiming that
text on a disk has to be GPLed because of emacs, or that postscript
files have to be GPLed because of ghostscript, or more generally that
arbitrary object FOO has to be GPLed because of gpled program BAR.
Put another way, what the linker does or doesn't do isn't really the
issue.
People like to think that the linker is somehow special for copyright,
but it's not. Either the stuff being linked is protected by copyright
even when it's not linked or it's not protected by copyright after it is
linked. If the license says something about linking then that matters,
but only for cases where the code was protected by copyright even before
it was linked. And then linking only matters in the specific way that
that license says it matters.
--
Raul
On Tue, Apr 05, 2005 at 03:57:01PM +0200, Sven Luther wrote:
>...
> The other point is that other entities, like redhat, or suse (which is now
> novel and thus ibm) and so have stronger backbones, and can more easily muster
> the ressources to fight of a legal case, even one which is a dubious one,
> especially given the particularities of the US judicial system, where it is
> less important to be right, and more important to have lot of money to throw
> at your legal machine. Debian has nothing such, and SPI which would stand for
> this, is not really upto it either, so in this case, apart from all ideology
> and fanatism, it is for purely pragmatic reasons that they don't distribute
> undistributable files from the non-free part of our archive. You would do the
> same in their case.
>...
There are many possible legal risks for a Linux distribution.
This thread is about one.
Another one is that RedHat removed MP3 support in their distribution
from programs like xmms ages ago because of the legal risks due to
patents. The Debian distribution still contains software that is capable
of playing MP3's.
I'd say of the two above cases, the MP3 patents are far more likely to
cause a lawsuit.
YMMV.
If your statement was true that Debian must take more care regarding
legal risks than commercial distributions, can you explain why Debian
exposes the legal risks of distributing software capable of decoding
MP3's to all of it's mirrors?
> Friendly,
>
> Sven Luther
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Tue, Apr 05, 2005 at 04:05:07PM +0200, Josselin Mouette wrote:
> Le lundi 04 avril 2005 ? 21:32 +0200, Adrian Bunk a ?crit :
> > On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote:
> > > On Apr 04, Greg KH <[email protected]> wrote:
> > >
> > > > What if we don't want to do so? I know I personally posted a solution
> > > Then probably the extremists in Debian will manage to kill your driver,
> > > like they did with tg3 and others.
> >
> > And as they are doing with e.g. the complete gcc documentation.
> >
> > No documentation for the C compiler (not even a documentation of the
> > options) will be neither fun for the users of Debian nor for the Debian
> > maintainers - but it's the future of Debian...
>
> You are mixing apples and oranges. The fact that the GFDL sucks has
> nothing to do with the firmware issue. With the current situation of
> firmwares in the kernel, it is illegal to redistribute binary images of
> the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
> be willing to distribute such binary images, but it isn't our problem.
>...
It's a grey area.
debian-legal did pick one of the possible opinions on this matter.
The similarities between the GFDL and the firmware discussion can be
described with the following two questions:
Is it true, that the removal of much of the documentation in Debian is
scheduled soon because it's covered by the GFDL, that this is called an
"editorial change", and that Debian doesn't actually care that this will
e.g. remove all documentation about available options of the standard C
compiler used by and shipped with Debian?
Is it true, that Debian will leave users with hardware affected by the
firmware problem without a working installer in Debian 3.1?
The point is simply, that Debian does more and more look dogmatic at
it's definition of "free software" without caring about the effects to
it's users.
As a contrast, read the discussion between Christoph and Arjan in a part
of this thread how to move firmware out of kernel drivers without
problems for the users. This might not happen today, but it's better for
the users.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Thu, Apr 07, 2005 at 10:56:47PM +0200, Adrian Bunk wrote:
> On Tue, Apr 05, 2005 at 03:57:01PM +0200, Sven Luther wrote:
> >...
> > The other point is that other entities, like redhat, or suse (which is now
> > novel and thus ibm) and so have stronger backbones, and can more easily muster
> > the ressources to fight of a legal case, even one which is a dubious one,
> > especially given the particularities of the US judicial system, where it is
> > less important to be right, and more important to have lot of money to throw
> > at your legal machine. Debian has nothing such, and SPI which would stand for
> > this, is not really upto it either, so in this case, apart from all ideology
> > and fanatism, it is for purely pragmatic reasons that they don't distribute
> > undistributable files from the non-free part of our archive. You would do the
> > same in their case.
> >...
>
>
> There are many possible legal risks for a Linux distribution.
>
>
> This thread is about one.
>
> Another one is that RedHat removed MP3 support in their distribution
> from programs like xmms ages ago because of the legal risks due to
> patents. The Debian distribution still contains software that is capable
> of playing MP3's.
>
>
> I'd say of the two above cases, the MP3 patents are far more likely to
> cause a lawsuit.
>
> YMMV.
Yes, possibly, especially in these troubled times.
> If your statement was true that Debian must take more care regarding
> legal risks than commercial distributions, can you explain why Debian
> exposes the legal risks of distributing software capable of decoding
> MP3's to all of it's mirrors?
I don't know and don't really care. I don't maintain any mp3 player (err,
actually i do, i package quark, but use it mostly to play .oggs, maybe i
should think twice about this now that you made me aware of it), but in any
case, i am part of the debian kernel maintainer team, and as such have a
responsability to get those packages uploaded and past the screening of the
ftp-masters. I believe the planned solution is vastly superior to the current
one of simply removing said firmware blobs from the drivers, which caused more
harm than helped, which is why we are set to clarifying this for the
post-sarge kernels.
That said, i was under the understanding that after the SCO disaster,
clarification of licencing issues and copyright attributions was a welcome
thing here, but maybe i misunderstood those whole issues.
Friendly,
Sven Luther
> On Thu, Apr 07, 2005 at 01:26:17AM -0700, David Schwartz wrote:
> > If you believe the linker "merely aggregates" the object code for the
> > driver with the data for the firmware, I can't see how you can argue
> > that any linking is anything but mere aggregation. In neither case can
> > you separate the linked work into the two separate works and in both
> > cases the linker provides one work direct access to the other.
> You can indeed separate the firmware and the kernel into two separate
> works. That's what people have been proposing as the solution to this
> problem.
> Also, "mere aggregation" is a term from the GPL. You can read what
> it says there yourself. But basically it's there so that people make
> a distinction between the program itself and other stuff that isn't
> the program.
It's also there because the GPL can only apply to either works placed under
it by their authors and works that are legally classified as derivative. If
you merely aggregate two works, there is no derivation. The GPL is making
clear that it's not trying to exceed the scope of its authority (which is
copyright law).
> Without that mere aggregation clause, people might be claiming that
> text on a disk has to be GPLed because of emacs, or that postscript
> files have to be GPLed because of ghostscript, or more generally that
> arbitrary object FOO has to be GPLed because of gpled program BAR.
They could, but they would still be wrong. Because if you "merely
aggregate" two works, the result is still two works that can each be under
their own license. The GPL is only making clear what is outside its
authority, but it does not set the scope of its own authority anyway.
> Put another way, what the linker does or doesn't do isn't really the
> issue.
Well it is. The question is whether you can link two object files together
and distribute the result under the license of each independent file,
treating it like a disk with two files on it, rather than as a single work.
> People like to think that the linker is somehow special for copyright,
> but it's not. Either the stuff being linked is protected by copyright
> even when it's not linked or it's not protected by copyright after it is
> linked. If the license says something about linking then that matters,
> but only for cases where the code was protected by copyright even before
> it was linked. And then linking only matters in the specific way that
> that license says it matters.
Regardless of what the GPL says, there is a genuine question of whether
linking together file A and file B results in a file C that contains the two
separate works or is a single work that is derivative of both A and B. This
is important because of aspects of copyright law that the GPL acknowledges
explicitly but does not get to decide.
DS
On Thu, Apr 07, 2005 at 11:05:05PM +0200, Sven Luther wrote:
> On Thu, Apr 07, 2005 at 10:56:47PM +0200, Adrian Bunk wrote:
>...
> > If your statement was true that Debian must take more care regarding
> > legal risks than commercial distributions, can you explain why Debian
> > exposes the legal risks of distributing software capable of decoding
> > MP3's to all of it's mirrors?
>
> I don't know and don't really care. I don't maintain any mp3 player (err,
> actually i do, i package quark, but use it mostly to play .oggs, maybe i
> should think twice about this now that you made me aware of it), but in any
> case, i am part of the debian kernel maintainer team, and as such have a
> responsability to get those packages uploaded and past the screening of the
> ftp-masters. I believe the planned solution is vastly superior to the current
> one of simply removing said firmware blobs from the drivers, which caused more
> harm than helped, which is why we are set to clarifying this for the
> post-sarge kernels.
Debian doesn't seem to care much about the possible legal problems of
patents.
The firmware issues are an urgent real problem?
Debian should define how much legal risk they are willing to impose on
their mirrors and distributors and should act accordingly in all areas.
But ignoring some areas while being more religious than RMS in other
areas is simply silly.
> That said, i was under the understanding that after the SCO disaster,
> clarification of licencing issues and copyright attributions was a welcome
> thing here, but maybe i misunderstood those whole issues.
"SCO disaster"?
It is a disaster for SCO.
> Friendly,
>
> Sven Luther
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Scripsit Humberto Massa <[email protected]>
> After a *lot* of discussion, it was deliberated on d-l that
> this is not that tricky at all, and that the "mere
> aggregation" clause applies to the combination, for various
> reasons, with a great degree of safety.
When was this alleged conclusion reached? I remember nothing like
that.
> No-one is saying that the linker "merely aggregates" object
> code for the driver; what *is* being said is: in the case of
> firmware, especially if the firmware is neither a derivative
> work on the kernel (see above) nor the firmware includes part
> of the kernel (duh), it is *fairly* *safe* to consider the
> intermixing of firmware bytes with kernel binary image bytes
> in an ELF object file as mere aggregation.
No, it is completely wrong to say that the object file is merely an
aggregation. The two components are being coupled much more tightly
than in the situation that the GPL discribes as "mere aggregation".
--
Henning Makholm "H?r, hvad er det egentlig
der ikke kan blive ved med at g??"
> > No-one is saying that the linker "merely aggregates" object
> > code for the driver; what *is* being said is: in the case of
> > firmware, especially if the firmware is neither a derivative
> > work on the kernel (see above) nor the firmware includes part
> > of the kernel (duh), it is *fairly* *safe* to consider the
> > intermixing of firmware bytes with kernel binary image bytes
> > in an ELF object file as mere aggregation.
> No, it is completely wrong to say that the object file is merely an
> aggregation. The two components are being coupled much more tightly
> than in the situation that the GPL discribes as "mere aggregation".
Would you maintain this position even if the firmware is identical
across operating systems and the Linux driver is identical across different
firmware builds for different hardware implementations?
Say, for example, Intel comes out with a new super-smart and
sophisticated network card. They also offer firmware that makes it look just
like an NE2000. They don't create this firmware for Linux, they create it
for any set of operating systems that don't have specific drivers for this
card.
Similarly, the NE2000 driver wasn't specifically designed to use
this firmware. Both the firmware and the driver were independently developed
to implement the same de facto standard.
Now, someone combines the firmware and the driver into a package
that checks what card you are using, and if it has the appropriate firmware
to make the card work with the driver, uploads it.
Note that the issue is not whether the GPL describes this as "mere
aggregation" because the GPL doesn't get to set its own scope. The issue is
whether the resulting binary is a single work (that is derivative of the
GPL'd driver) or whether it's two works with a license boundary between
them.
It would not be obviously unreasonable to argue that the NE2000 API
constitutes a license boundary between the two works, each of which stays on
its own side of that API.
Lacking clear court guidance, I see it as a threshold issue. One
primary issue (I think) is to what extent that firmware and the driver have
been customized for each other. A work that is carefully designed to mesh
tightly with another work is analogous to a sequel, which is a derivative
work.
I think we have a real problem, however, in cases where the source
file that holds only the firmware data contains a GPL notice.
DS
Sven Luther <[email protected]> writes:
> > It sounds like you are now looking at the question of are the
> > huge string of hex characters the preferred form for making
> > modifications to firmware. Personally I would be surprised
> > but those hunks are small enough it could have been written
> > in machine code.
>
> Yep, i also think it is in broadcom's best interest to modify the licencing
> text accordyingly, since i suppose someone could technicaly come after them
> legally to obtain said source code to this firmware. Unprobable though.
Possibly. It sounds like that is what you want to do.
> > So I currently have no reason to believe that anything has been
> > done improperly with that code.
>
> Well, it all depends if you consider this firmware blob as software, which i
> feel it is without doubt, or we have not the same definition of software,
> i.e., the program which runs on the hardware, or not. We cannot claim this is
> data,
>
> since there should be at least some kind of executable code in it,
> independenlty of the fact that we claim that data is also software.
Do you have any evidence that ``software'' was not written directly in
machine code? Software is written directly in machine code when a programmer
looks at the instruction set and writes down the binary representation
of the instructions. I know ISC dhcpd has packet filter code that was written
in that manner, so it is not a lost art. And it is done often enough when
an assembler will not cooperate, and generate the correct instruction.
Without evidence that we don't have the preferred form of the software
for making modifications I don't see how you can complain.
Eric
> > Also, "mere aggregation" is a term from the GPL. You can read what
> > it says there yourself. But basically it's there so that people make
> > a distinction between the program itself and other stuff that isn't
> > the program.
On Thu, Apr 07, 2005 at 04:20:50PM -0700, David Schwartz wrote:
> It's also there because the GPL can only apply to either works
> placed under it by their authors and works that are legally classified
> as derivative. If you merely aggregate two works, there is no
> derivation. The GPL is making clear that it's not trying to exceed the
> scope of its authority (which is copyright law).
The issue of whether or not the combined work is a derivative under
copyright law is a copyright law issue. The GPL does concern itself
with that issue, but not in the "mere aggregation" clause.
The "mere aggregation" clause holds regardless of whether or not the
combined work is a derivative under copyright law.
[P.S. I've set the Reply-To: header on this message because I think this
thread has drifted away from kernel issues.]
--
Raul
Scripsit "David Schwartz" <[email protected]>
[quoting me]
>> No, it is completely wrong to say that the object file is merely an
>> aggregation. The two components are being coupled much more tightly
>> than in the situation that the GPL discribes as "mere aggregation".
> Would you maintain this position even if the firmware is identical
> across operating systems and the Linux driver is identical across different
> firmware builds for different hardware implementations?
Yes I would. Linking forms a tighter coupling than just placing the
two parts side by side on a filesystem designed for general storage of
byte streams. There is more to say about the situation than the naked
fact that that they are aggreated on the same medium; ergo the
sutiation does not constitute *only* aggregation, and the "mere
aggregation" language of the GPL does not apply.
In particular, the end of GPL #2 does not provide a blanket exception
for all forms of aggregation; it specifically speaks about aggregation
"on a volume of a storage or distribution medium".
> Note that the issue is not whether the GPL describes this as "mere
> aggregation" because the GPL doesn't get to set its own scope.
The scope of the copyright of the original work includes situation
where part of that original work is being copied (excluding fair use
and other jurisdiction-specific exceptions). In order to do such
copying, you need permission from the copyright holder of the original
work. If all the permission you have is the GPL, the copyihg you are
doing had better fall into the class of copying that the GPL provides
a permission for.
It *is*, therefore, relevant, whether the GPL's special conditions for
works "that in whole or in part contains the Program" apply to the
linked object files.
> The issue is whether the resulting binary is a single work (that is
> derivative of the GPL'd driver) or whether it's two works with a
> license boundary between them.
A reasonable person can disagree about whether the word "work" in GPL
#2(b) is meant to exclude non-trivial aggregations that do not add
creative choice to that already expressed in the components.
However, I don't think a reasonable person can argue that even if 2(b)
had said "byte stream" instead of "work" it would not have been
legally potent to demand GPL-compatible licensing of the firmware as a
condition for the permission to copy the GPL-covered part of the byte
stream.
> It would not be obviously unreasonable to argue that the NE2000 API
> constitutes a license boundary between the two works, each of which stays on
> its own side of that API.
No, it wouldn't be obviously unreasonable for a license to recognize
such a "license boundary". However, as I see it the GPL happens not to
do this.
> Lacking clear court guidance, I see it as a threshold issue. One
> primary issue (I think) is to what extent that firmware and the driver have
> been customized for each other. A work that is carefully designed to mesh
> tightly with another work is analogous to a sequel, which is a derivative
> work.
I think the "derivative work" angle is a red herring. I do not think
that either of the two parts that are being linked together (i.e. the
driver and the firmware) are derivates of the other. The relevant
point is that distribution of the linked _result_ is nevertheless
subject to the condition in GPL #2, which is in general the only
source we have for a permission to distribute a non-verbatim-source
form of the driver.
--
Henning Makholm "... and that Greek, Thucydides"
On Thu, Apr 07, 2005 at 08:05:31PM -0700, David Schwartz wrote:
> I think we have a real problem, however, in cases where the source
> file that holds only the firmware data contains a GPL notice.
Sure: the GPL notice isn't completely valid. But I think people have
already decided that this is an issue that needs to be fixed. And,
I think most of the approach for fixing these is fairly clear.
That said... perhaps it's worth going over a hierarchy of copyright
issues:
First, there's the issue of whether or not work is protected by copyright.
I think we're talking about stuff that's protected by copyright.
If it is protected by copyright, there's the question of whether the
things being done with that work are regulated by copyright law. I think
we're talking about activities (making copies of linux and distributing
it) which are regulated by copyright law.
If both hold, the next question is whether or not the copyright license
allows this use. As you've indicated, we do have some real issues here.
Finally, if you're dealing with regulated activity and the license
doesn't allow it, it's up to the copyright holder to decide whether or
not to prosecute. So far, the copyright holders haven't said much about
these issues.
We probably have some issues where what we're doing is only by the good
graces of the copyright holder(s). We should fix those things, of course,
but currently there aren't any deadlines we have to meet.
--
Raul
On Thu, Apr 07, 2005 at 09:06:58PM -0600, Eric W. Biederman wrote:
> Sven Luther <[email protected]> writes:
>
> > > It sounds like you are now looking at the question of are the
> > > huge string of hex characters the preferred form for making
> > > modifications to firmware. Personally I would be surprised
> > > but those hunks are small enough it could have been written
> > > in machine code.
> >
> > Yep, i also think it is in broadcom's best interest to modify the licencing
> > text accordyingly, since i suppose someone could technicaly come after them
> > legally to obtain said source code to this firmware. Unprobable though.
>
> Possibly. It sounds like that is what you want to do.
No, i am making them aware of the possibility, and hoping they fix the issue,
but we will see. If they fail to act on this, i don't understand why though,
since it is just addition of a clarification. It is not as if i am asking for
the release of all their chip specs or something such.
> > since there should be at least some kind of executable code in it,
> > independenlty of the fact that we claim that data is also software.
>
> Do you have any evidence that ``software'' was not written directly in
> machine code? Software is written directly in machine code when a programmer
So what, i seriously doubt they where written using an vi in C, as the code
currently stands, so we do need an additional level of source code, being it
only some asm code or something.
> looks at the instruction set and writes down the binary representation
> of the instructions. I know ISC dhcpd has packet filter code that was written
> in that manner, so it is not a lost art. And it is done often enough when
> an assembler will not cooperate, and generate the correct instruction.
But again, this is not the common assumption, so if this is so, they should
write it down black on white in the copyright notice, and everyone would be
happy.
> Without evidence that we don't have the preferred form of the software
> for making modifications I don't see how you can complain.
No, it goes the other way around. Without evidence that all is clean, we have
no right to distribute that code, and if what you describe was the case, a
couple of lines telling us that fact would solve the issue, and not even need
the involvement of their legal department. I would be somewhat suspisious
though if all these guys came up and said they just wrote said firmware in
binary directly though.
Friendly,
Sven Luther
On Fri, Apr 08, 2005 at 02:31:36AM +0200, Adrian Bunk wrote:
> On Thu, Apr 07, 2005 at 11:05:05PM +0200, Sven Luther wrote:
> > On Thu, Apr 07, 2005 at 10:56:47PM +0200, Adrian Bunk wrote:
> >...
> > > If your statement was true that Debian must take more care regarding
> > > legal risks than commercial distributions, can you explain why Debian
> > > exposes the legal risks of distributing software capable of decoding
> > > MP3's to all of it's mirrors?
> >
> > I don't know and don't really care. I don't maintain any mp3 player (err,
> > actually i do, i package quark, but use it mostly to play .oggs, maybe i
> > should think twice about this now that you made me aware of it), but in any
> > case, i am part of the debian kernel maintainer team, and as such have a
> > responsability to get those packages uploaded and past the screening of the
> > ftp-masters. I believe the planned solution is vastly superior to the current
> > one of simply removing said firmware blobs from the drivers, which caused more
> > harm than helped, which is why we are set to clarifying this for the
> > post-sarge kernels.
>
>
> Debian doesn't seem to care much about the possible legal problems of
> patents.
patents are problematic, and upto recently there where no software patents in
europe, so i don't really care. I am not sure about the details of the above
problem you mention, could you provide me some link to the problem at hand. I
also believe that in the larger scheme restriction of this kind, as is the US
restriction on distribution to cuba and everything else, is not-right and even
immoral, and *I* personally would fight back if i was ever sued for such
things, and there may be higher courts involved than just the US judicial
system, which is for sale anyway, where redhat is dependent on. I cannot talk
about the whole of debian on this though, and i feel it is for someone else to
tackle and handle. If you feel strongly about this, you are free to go take it
over with whoever handles this, post to debian-legal and debian-project about
it, and help get the issue solved.
(/me believes such restrictions of the above are a violation of the elemental
human rights to go where one wants and run what operating system on wants).
> The firmware issues are an urgent real problem?
It is a problem that concerns me and the debian kernel team, thus we are out
to fix it. If you have a problem at hand, even if it is not as important as
others, would you sit back and not do anything just because others didn't
solve other problems ?
> Debian should define how much legal risk they are willing to impose on
> their mirrors and distributors and should act accordingly in all areas.
That is for the ftp-masters to decide, i am not in best speaking term with
them, so you are free to go ask the question directly.
> But ignoring some areas while being more religious than RMS in other
> areas is simply silly.
Come on, i am just asking for a damn explicit declaration that the firmware is
not something covered by the GPL, and that we should have explicit
distribution licence for it. We all agree that these are not covered by the
GPL for various reasons, so why not have the copyright holder state it
explicitly ? I don't see how do you jump to "more religious than RMS" from
that, given that my analysis making the firmware aggregate works are a wee bit
different from what they explicitly write in their GPL FAQ.
> > That said, i was under the understanding that after the SCO disaster,
> > clarification of licencing issues and copyright attributions was a welcome
> > thing here, but maybe i misunderstood those whole issues.
>
> "SCO disaster"?
>
> It is a disaster for SCO.
Now, yes. but we did strengthen our admission of patches policy for more
tracability, didn't we, and there where companies who paid SCO for fear of
retribution, and they where project who post-poned their linux adoptions, and
what not. If nothing else, be it only for all the time we all lost following
that story over the past tree years.
Friendly,
Sven Luther
Le jeudi 07 avril 2005 ? 23:07 +0200, Adrian Bunk a ?crit :
> > You are mixing apples and oranges. The fact that the GFDL sucks has
> > nothing to do with the firmware issue. With the current situation of
> > firmwares in the kernel, it is illegal to redistribute binary images of
> > the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
> > be willing to distribute such binary images, but it isn't our problem.
>
> It's a grey area.
>
> debian-legal did pick one of the possible opinions on this matter.
When there are several possible interpretations, you have to pick up the
more conservative one, as it's not up to us to make the interpretation,
but to a court.
> Is it true, that the removal of much of the documentation in Debian is
> scheduled soon because it's covered by the GFDL, that this is called an
> "editorial change", and that Debian doesn't actually care that this will
> e.g. remove all documentation about available options of the standard C
> compiler used by and shipped with Debian?
The situation changed only in the mind of the person who was the release
manager at that time. The "old" wording is "Debian will remain 100% free
software", and he understood that as "100% of software in Debian will
remain free". The common interpretation is that this wording doesn't
allow GFDL documentation either. The fact these documents are very
useful is irrelevant: the GFDL is a real piece of crap, only a few fools
at the FSF are really arguing it is a free license.
Instead of babbling, some people have started to discuss this with
upstream, and are trying to come up with a GPLed documentation for GCC.
This is much more constructive than repeating again and again "Bleh,
Debian are a bunch of bigots who don't care of the compiler being
documented."
> Is it true, that Debian will leave users with hardware affected by the
> firmware problem without a working installer in Debian 3.1?
The case of hardware really needing a firwmare to work *and* needed at
installation time is rare. I've only heard of some tg3-based cards. Most
of them will work without the firmware, and for the few remaining ones,
it only means network installation won't work.
> The point is simply, that Debian does more and more look dogmatic at
> it's definition of "free software" without caring about the effects to
> it's users.
Being careless in the definition of "free software" is a real disservice
to users. It makes them rely on e.g. non-free documentation for everyday
use.
> As a contrast, read the discussion between Christoph and Arjan in a part
> of this thread how to move firmware out of kernel drivers without
> problems for the users. This might not happen today, but it's better for
> the users.
Some Debian developers have been writing such patches so that we can
still run Linux on this hardware, long before the topic was raised on
the LKML.
--
.''`. Josselin Mouette /\./\
: :' : [email protected]
`. `' [email protected]
`- Debian GNU/Linux -- The power of freedom
On Thu, Apr 07, 2005 at 11:55:44PM -0400, Raul Miller wrote:
> > > Also, "mere aggregation" is a term from the GPL. You can read what
> > > it says there yourself. But basically it's there so that people make
> > > a distinction between the program itself and other stuff that isn't
> > > the program.
>
> On Thu, Apr 07, 2005 at 04:20:50PM -0700, David Schwartz wrote:
> > It's also there because the GPL can only apply to either works
> > placed under it by their authors and works that are legally classified
> > as derivative. If you merely aggregate two works, there is no
> > derivation. The GPL is making clear that it's not trying to exceed the
> > scope of its authority (which is copyright law).
>
> The issue of whether or not the combined work is a derivative under
> copyright law is a copyright law issue. The GPL does concern itself
> with that issue, but not in the "mere aggregation" clause.
>
> The "mere aggregation" clause holds regardless of whether or not the
> combined work is a derivative under copyright law.
>
> [P.S. I've set the Reply-To: header on this message because I think this
> thread has drifted away from kernel issues.]
Thanks.
BTW, have any of you read the analysis i made, where i claim, rooted in the
GPL FAQ and with examples, why i believe that the firmware can be considerated
a non derivative of the linux kernel. The main points is that the firmware is
not aimed to run in the same address space, even not the same cpu, as the rest
of the linux kernel, and that there is a clearly defined communication channel
between the GPLed driver and the target processor running the firmware.
I further argumented that taking any different stance would bring us worlds of
hurt as we would consider the bios as being a derivative work of the kernel
they are running, or the bootloader, or the firmware present in proms on
devices loaded into the system and so on.
I think only the fact that if you consider firmware as being a derivative
work, you should consider it a derivative work also when it is flashed on the
prom of a pci card or what not, is decisive enough to make those firmware
blobs not derivative works of the kernel they are under.
Friendly,
Sven Luther
On Tue, Apr 05, 2005 at 11:50:54AM -0400, Richard B. Johnson wrote:
> On Tue, 5 Apr 2005, Humberto Massa wrote:
>
> >Josselin Mouette wrote:
> >
> >>You are mixing apples and oranges. The fact that the GFDL sucks has
> >>nothing to do with the firmware issue. With the current situation of
> >>firmwares in the kernel, it is illegal to redistribute binary images of
> >>the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
> >>be willing to distribute such binary images, but it isn't our problem.
> >>
>
> Wrong! It is perfectly legal in the United States, and I'm pretty
> sure in your country, to distribute or redistribute copyrighted
> works. Otherwise there wouldn't be any bookstores or newspaper
> stands.
Mmm, so you are claiming it is perfectly right to make copies of the windows
installation CD, or for that matter to duplicate music CDs ?
I would be rather interested in knowing how you came to that conclusion :)
Friendly,
Sven Luther
On Fri, Apr 08, 2005 at 03:10:43AM +0100, Henning Makholm wrote:
> Scripsit Humberto Massa <[email protected]>
>
> > After a *lot* of discussion, it was deliberated on d-l that
> > this is not that tricky at all, and that the "mere
> > aggregation" clause applies to the combination, for various
> > reasons, with a great degree of safety.
>
> When was this alleged conclusion reached? I remember nothing like
> that.
http://lists.debian.org/debian-legal/2005/03/msg00273.html
and :
http://lists.debian.org/debian-legal/2005/03/msg00283.html
and the following thread. These where linked from the original mail in this
thread.
> > No-one is saying that the linker "merely aggregates" object
> > code for the driver; what *is* being said is: in the case of
> > firmware, especially if the firmware is neither a derivative
> > work on the kernel (see above) nor the firmware includes part
> > of the kernel (duh), it is *fairly* *safe* to consider the
> > intermixing of firmware bytes with kernel binary image bytes
> > in an ELF object file as mere aggregation.
>
> No, it is completely wrong to say that the object file is merely an
> aggregation. The two components are being coupled much more tightly
> than in the situation that the GPL discribes as "mere aggregation".
So read the analysis and comment on it if you disagree, but let's take it to
debian-legal alone, ok ?
Friendly,
Sven Luther
On Fri, Apr 08, 2005 at 04:56:50AM +0100, Henning Makholm wrote:
> Scripsit "David Schwartz" <[email protected]>
> [quoting me]
>
> >> No, it is completely wrong to say that the object file is merely an
> >> aggregation. The two components are being coupled much more tightly
> >> than in the situation that the GPL discribes as "mere aggregation".
>
> > Would you maintain this position even if the firmware is identical
> > across operating systems and the Linux driver is identical across different
> > firmware builds for different hardware implementations?
>
> Yes I would. Linking forms a tighter coupling than just placing the
> two parts side by side on a filesystem designed for general storage of
> byte streams. There is more to say about the situation than the naked
So, why didn't you say it when i posted my analysis to debian-legal a month
ago and asked for comments ?
> fact that that they are aggreated on the same medium; ergo the
> sutiation does not constitute *only* aggregation, and the "mere
> aggregation" language of the GPL does not apply.
>
> In particular, the end of GPL #2 does not provide a blanket exception
> for all forms of aggregation; it specifically speaks about aggregation
> "on a volume of a storage or distribution medium".
Read my argumentation, comment on it, and be prepared to consider the same
copy of the firmware as a derived work if shipped on a prom on the device
itself.
Friendly,
Sven Luther
On Thu, Apr 07, 2005 at 09:15:07AM -0300, Humberto Massa wrote:
> This is where you are wrong IMMHO. All that is needed for you
> to distribute the hexdump blob under the GPL is a declaration
> from the copyright holder saying "this, to me, is the
> preferred form for modification of the firmware and hence the
> source code under the GPL."
I strongly disagree. This could be an open door to to anyone claiming that
whatever binary is the prefered form of modification.
Friendly,
Sven Luther
On Thu, Apr 07, 2005 at 04:15:45PM +0200, Josselin Mouette wrote:
> Le jeudi 07 avril 2005 ? 09:03 -0400, Richard B. Johnson a ?crit :
> > Well it doesn't make any difference. If GPL has degenerated to
> > where one can't upload microcode to a device as part of its
> > initialization, without having the "source" that generated that
> > microcode, we are in a lot of hurt. Intel isn't going to give their
> > designs away.
>
> The GPL doesn't forbid that. The GPL forbids to put this microcode
> directly in the same binary as the GPL code. Of course, nothing forbids
> some GPL'ed code to take a binary elsewhere and to upload it into the
> hardware.
No, i am arguing, that we can consider here the binary as a media
distribution, in the same way as we would clearly separate the compressor from
the compressed data in a auto-uncompressing executable, or the firmware from
the firmware flasher in a all-in-one firmware upgrade binary.
> At least that's my opinion; AIUI, Sven Luther believes it is possible if
> the firmware has a decent (but not necessarily free) license.
Indeed, the sole problem is that the current copyright and licencing
attributions de-facto sets those firmware blobs under the GPL, which of course
makes them undistributable since the GPL clearly claims that we need source
code for it, and if any condition of the GPL fails, the program becomes
undistributable as a whole.
Friendly,
Sven Luther
On Tue, Apr 05, 2005 at 12:50:14PM -0600, Chris Friesen wrote:
> Josselin Mouette wrote:
>
> >The fact is also that mixing them with a GPLed software gives
> >an result you can't redistribute - although it seems many people
> >disagree with that assertion now.
>
> This is only true if the result is considered a "derivative work" of the
> gpl'd code.
>
> The GPL states "In addition, mere aggregation of another work not based
> on the Program with the Program (or with a work based on the Program) on
> a volume of a storage or distribution medium does not bring the other
> work under the scope of this License."
>
> Since the main cpu does not actually run the binary firmware, the fact
> that it lives in main memory with the code that the cpu *does* run is
> irrelevent. In this case, the Debian stance is that the kernel proper
> and the binary firmware are "merely aggregated" in a volume of storage (
> ie. system memory).
The problem is that you can only argue it is mere agregation, if the copyright
notice doesn't de-facto put said firmware blobs under the GPL, thus making
them undistributable by the selfsame definition of the GPL.
Friendly,
Sven Luther
Hi,
Humberto Massa wrote:
> First, there is *NOT* any requirement in the GPL at all that requires
> making compilers available. Otherwise it would not be possible, for
> instance, have a Visual Basic GPL'd application. And yes, it is
> possible.
>From section 3 of the GNU GPL, version 2:
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
I take that to mean the compiler's exempted if it's the normal one
available on the platform, but if the software distributor had to modify
gcc to produce the binaries it's distributing then you're entitled to
the compiler too.
So a Visual BASIC application uses a standard VB compiler, but that's
not necessarily the case for a Linux kernel running on an embedded box.
Cheers,
Ralph.
On Fri, 8 April 2005 09:22:00 +0200, Josselin Mouette wrote:
> Le jeudi 07 avril 2005 ? 23:07 +0200, Adrian Bunk a ?crit :
>
> > As a contrast, read the discussion between Christoph and Arjan in a part
> > of this thread how to move firmware out of kernel drivers without
> > problems for the users. This might not happen today, but it's better for
> > the users.
>
> Some Debian developers have been writing such patches so that we can
> still run Linux on this hardware, long before the topic was raised on
> the LKML.
I can point you to dozens of patches I have written that were never
merged. Not because Linus is a d*ckhead (he's not), but because they
were not good enough then and I didn't spend the time to improve them,
so far.
"Someone's written some patches" is a long way from "we have a good
solution".
J?rn
--
You cannot suppose that Moliere ever troubled himself to be original in the
matter of ideas. You cannot suppose that the stories he tells in his plays
have never been told before. They were culled, as you very well know.
-- Andre-Louis Moreau in Scarabouche
On Thu, Apr 07, 2005 at 11:07:23PM +0200, Adrian Bunk wrote:
> On Tue, Apr 05, 2005 at 04:05:07PM +0200, Josselin Mouette wrote:
> > Le lundi 04 avril 2005 ? 21:32 +0200, Adrian Bunk a ?crit :
> > > On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote:
> > > > On Apr 04, Greg KH <[email protected]> wrote:
> > > >
> > > > > What if we don't want to do so? I know I personally posted a solution
> > > > Then probably the extremists in Debian will manage to kill your driver,
> > > > like they did with tg3 and others.
> > >
> > > And as they are doing with e.g. the complete gcc documentation.
> > >
> > > No documentation for the C compiler (not even a documentation of the
> > > options) will be neither fun for the users of Debian nor for the Debian
> > > maintainers - but it's the future of Debian...
> >
> > You are mixing apples and oranges. The fact that the GFDL sucks has
> > nothing to do with the firmware issue. With the current situation of
> > firmwares in the kernel, it is illegal to redistribute binary images of
> > the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
> > be willing to distribute such binary images, but it isn't our problem.
> >...
>
>
> It's a grey area.
>
> debian-legal did pick one of the possible opinions on this matter.
>
> The similarities between the GFDL and the firmware discussion can be
> described with the following two questions:
>
> Is it true, that the removal of much of the documentation in Debian is
> scheduled soon because it's covered by the GFDL, that this is called an
> "editorial change", and that Debian doesn't actually care that this will
> e.g. remove all documentation about available options of the standard C
> compiler used by and shipped with Debian?
Notice though that the GFDL problematic is part of a much older issue between
debian and the FSF on this, and i believe discussions to solve this issues
have been under discussions since more than a year without real progress that
i know of.
> Is it true, that Debian will leave users with hardware affected by the
> firmware problem without a working installer in Debian 3.1?
Yes, probably. not my fault though, and the current discussion is part of the
plan to fix this, through availability of non-free installer components.
> The point is simply, that Debian does more and more look dogmatic at
> it's definition of "free software" without caring about the effects to
> it's users.
I reject this affirmation.
> As a contrast, read the discussion between Christoph and Arjan in a part
> of this thread how to move firmware out of kernel drivers without
> problems for the users. This might not happen today, but it's better for
> the users.
It is indeed, but it is something that involves kernel development which i
don't really have time to do right now, and even if we where to do that, the
legal problem of the messed licencing situation would remain. The current
short term solution is simply to move the affected drivers to non-free, and
provide mechanisms for the user to load these installer modules with the free
installer, or have a couple of builds of a non-free installer which include
these non-free modules.
Saying that we are dogmatic, without even caring to understand what the
current reality is doesn't strike me at the most reasonable way to discuss
such issues.
Friendly,
Sven Luther
Adrian Bunk wrote:
>Debian doesn't seem to care much about the possible legal problems of
>patents.
>
>
The possible legal problem of software patents is, up to the present
time, AFAICT, not producing effects yet in Europe, and is a non-problem
in jurisdictions like mine (down here neither business methods nor
software are patentable).
>The firmware issues are an urgent real problem?
>
>
OTOH, the firmware issues *is* a legal real problem (copyright
infringement is even a criminal offense in a lot of juristictions --
down here, 6 months to 2 years of soft jail + fine for non-commercial
and 2 to 4 years of hard-jail + fine for commercial intents).
>Debian should define how much legal risk they are willing to impose on
>their mirrors and distributors and should act accordingly in all areas.
>
>
You are right, but as I told you, the mirrors are really worse when
there is a chance of copyrights infringement than of patents
infringement -- even on those jurisdictions that *have* software
patents, things are more difficult to prosecute in the patent field.
>But ignoring some areas while being more religious than RMS in other
>areas is simply silly.
>
>
Conceded. You are right on this.
HTH,
Massa
On Fri, 2005-04-08 at 09:08 -0300, Humberto Massa wrote:
> Adrian Bunk wrote:
> >Debian doesn't seem to care much about the possible legal problems of
> >patents.
You have lots of "possible legal problems" of any kind. Basically
everyone can sue you for (almost) whatever he wants almost all ofth
time.
> The possible legal problem of software patents is, up to the present
> time, AFAICT, not producing effects yet in Europe, and is a non-problem
It is starting now. Basically the corporations with the masses of
software patents and patent lawyers are probably waiting for the
settling of the discussion and the ratification of the relevant
to-be-accepted laws. And the war is not over yet ...
In fact software patents are real in EUrope and they exist (though
illegally). Up to now it was a question of whether you can succeed in
court with them and which courts to go ....
> in jurisdictions like mine (down here neither business methods nor
> software are patentable).
I suspect that .br is commercially not relevant enough for this ATM. Or
the legislation is already USPTO-conform in place and nobody knows .....
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
On Fri, Apr 08, 2005 at 09:41:35AM +0200, Sven Luther wrote:
> BTW, have any of you read the analysis i made, where i claim, rooted
> in the GPL FAQ and with examples, why i believe that the firmware can
> be considerated a non derivative of the linux kernel.
I hadn't. I did just now. Here's my opinions, after reading it:
[1a] It's pretty long, and some of the redundancy is not really relevant
to the issue at hand. This might be less of an issue, except
[1b] It has some grammar problems that should be fixed.
[2] The presented arguments all look plausible. Maybe I should study
it more, but I didn't see any significant logical flaws.
[3] It focuses on debian issues more than kernel issues (though a
dedicated reader could see some issues relevant to the linux-kernel
mailing list).
I agree with both you and the gpl faq writers that "communicates at arms
length" is probably a good measure of whether or not the kernel and the
module are the same program. I can think of cases where this wouldn't
hold (GPLed documentation, for example), but those kinds of issues don't
seem to be relevant here.
> I further argumented that taking any different stance would bring us worlds of
> hurt as we would consider the bios as being a derivative work of the kernel
> they are running, or the bootloader, or the firmware present in proms on
> devices loaded into the system and so on.
Here, you've confused two issues: "Are A and B part of the same program?"
and "Are A and B together part of a derivative work under copyright law?"
Sometimes one is true, sometimes the other is true. You have a GPL
issue when both are true.
One question has to do with the function of A and B. The other question
is whether the combination is eligible for copyright protection.
Copyright protection is not granted or denied because of functionality.
The functional issues are relevant only because they're written into
the license.
Of course there can be other GPL issues (e.g. it's bad to put a GPL
notice on something which isn't GPLed).
And, of course, there can be non-GPL issues (pulling the blobs out of
the kernel lets people update their firmware without having to compile
the kernel or a kernel module).
> I think only the fact that if you consider firmware as being a derivative
> work, you should consider it a derivative work also when it is flashed on the
> prom of a pci card or what not, is decisive enough to make those firmware
> blobs not derivative works of the kernel they are under.
Uh... not precisely. You have your facts straight, but your logic is bad.
This fact alone isn't enough to decide whether or not firmware is a
derivative work.
Fortunately this thought isn't a big deal for the cases we're currently
talking about.
--
Raul
On Fri, Apr 08, 2005 at 08:54:40AM +0200, Sven Luther wrote:
> On Fri, Apr 08, 2005 at 02:31:36AM +0200, Adrian Bunk wrote:
> > On Thu, Apr 07, 2005 at 11:05:05PM +0200, Sven Luther wrote:
> > > On Thu, Apr 07, 2005 at 10:56:47PM +0200, Adrian Bunk wrote:
> > >...
> > > > If your statement was true that Debian must take more care regarding
> > > > legal risks than commercial distributions, can you explain why Debian
> > > > exposes the legal risks of distributing software capable of decoding
> > > > MP3's to all of it's mirrors?
> > >
> > > I don't know and don't really care. I don't maintain any mp3 player (err,
> > > actually i do, i package quark, but use it mostly to play .oggs, maybe i
> > > should think twice about this now that you made me aware of it), but in any
> > > case, i am part of the debian kernel maintainer team, and as such have a
> > > responsability to get those packages uploaded and past the screening of the
> > > ftp-masters. I believe the planned solution is vastly superior to the current
> > > one of simply removing said firmware blobs from the drivers, which caused more
> > > harm than helped, which is why we are set to clarifying this for the
> > > post-sarge kernels.
> >
> >
> > Debian doesn't seem to care much about the possible legal problems of
> > patents.
>
> patents are problematic, and upto recently there where no software patents in
> europe, so i don't really care. I am not sure about the details of the above
> problem you mention, could you provide me some link to the problem at hand. I
http://www.mp3licensing.com/
The patent problems in the USA alone should impose enough legal risks.
IANAL, but even RedHat considers them to be serious problems.
And note that most of their patents are also valid in the EU. If they
are enforcible is a different question, but it might be enough to become
a legal risk that a lawsuit might be started against e.g. a mirror.
> also believe that in the larger scheme restriction of this kind, as is the US
> restriction on distribution to cuba and everything else, is not-right and even
> immoral, and *I* personally would fight back if i was ever sued for such
> things, and there may be higher courts involved than just the US judicial
> system, which is for sale anyway, where redhat is dependent on. I cannot talk
Which court is "higher ... than just the US judicial system"?
If you are in the USA, there's no legal instance between the US supreme
court and god.
> about the whole of debian on this though, and i feel it is for someone else to
> tackle and handle. If you feel strongly about this, you are free to go take it
> over with whoever handles this, post to debian-legal and debian-project about
> it, and help get the issue solved.
>
> (/me believes such restrictions of the above are a violation of the elemental
> human rights to go where one wants and run what operating system on wants).
>...
Unfortunately, life isn't fair.
It's Debian's choice how cautiously or brave they are regarding legal
risks. But it has to be consistent.
Debian simply needs an overall policy for this.
But if you say that you want to avoid any legal risks in one area while
saying "these are not my packages" about perhaps even more likely legal
risks in other areas doesn't help anyone.
> Friendly,
>
> Sven Luther
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Fri, Apr 08, 2005 at 09:22:00AM +0200, Josselin Mouette wrote:
> Le jeudi 07 avril 2005 ? 23:07 +0200, Adrian Bunk a ?crit :
> > > You are mixing apples and oranges. The fact that the GFDL sucks has
> > > nothing to do with the firmware issue. With the current situation of
> > > firmwares in the kernel, it is illegal to redistribute binary images of
> > > the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still
> > > be willing to distribute such binary images, but it isn't our problem.
> >
> > It's a grey area.
> >
> > debian-legal did pick one of the possible opinions on this matter.
>
> When there are several possible interpretations, you have to pick up the
> more conservative one, as it's not up to us to make the interpretation,
> but to a court.
If Debian was at least consistent.
Why has Debian a much more liberal interpretation of MP3 patent issues
than RedHat?
>...
> Instead of babbling, some people have started to discuss this with
> upstream, and are trying to come up with a GPLed documentation for GCC.
> This is much more constructive than repeating again and again "Bleh,
> Debian are a bunch of bigots who don't care of the compiler being
> documented."
Will the replacement documentation for all affected software be
available before the GFDL documentation gets removed?
At least theoretically, the users are a priority for Debian equally to
free software.
> > Is it true, that Debian will leave users with hardware affected by the
> > firmware problem without a working installer in Debian 3.1?
>
> The case of hardware really needing a firwmare to work *and* needed at
> installation time is rare. I've only heard of some tg3-based cards. Most
> of them will work without the firmware, and for the few remaining ones,
> it only means network installation won't work.
How do you install Debian on a harddisk behind a SCSI controller who's
driver was removed from the Debian kernels due to it's firmware?
> > The point is simply, that Debian does more and more look dogmatic at
> > it's definition of "free software" without caring about the effects to
> > it's users.
>
> Being careless in the definition of "free software" is a real disservice
> to users. It makes them rely on e.g. non-free documentation for everyday
> use.
>...
Documentation is "software"?
Non-free documentation is better than no documentation.
Non-free software has several problems, but some of them like the right
to do modifications are less important for documentation, since e.g.
fixes for security bugs are not an issue.
Removing the available documentation without an equal replacement is a
real disserve for your users.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Le vendredi 08 avril 2005 à 19:34 +0200, Adrian Bunk a écrit :
> > When there are several possible interpretations, you have to pick up the
> > more conservative one, as it's not up to us to make the interpretation,
> > but to a court.
>
> If Debian was at least consistent.
>
> Why has Debian a much more liberal interpretation of MP3 patent issues
> than RedHat?
Because we already know that patents on MP3 decoders are not
enforceable. Furthermore, the holders of these patents have repeatedly
stated they won't ask for fees on MP3 decoders.
> How do you install Debian on a harddisk behind a SCSI controller who's
> driver was removed from the Debian kernels due to it's firmware?
Which SCSI controller are you talking about?
> > Being careless in the definition of "free software" is a real disservice
> > to users. It makes them rely on e.g. non-free documentation for everyday
> > use.
> >...
>
> Documentation is "software"?
Sure.
> Non-free documentation is better than no documentation.
>
> Non-free software has several problems, but some of them like the right
> to do modifications are less important for documentation, since e.g.
> fixes for security bugs are not an issue.
>
> Removing the available documentation without an equal replacement is a
> real disserve for your users.
GFDL documentation will still be available in the non-free archive.
--
.''`. Josselin Mouette /\./\
: :' : [email protected]
`. `' [email protected]
`- Debian GNU/Linux -- The power of freedom
On Fri, Apr 08, 2005 at 07:42:51PM +0200, Josselin Mouette wrote:
> Le vendredi 08 avril 2005 ? 19:34 +0200, Adrian Bunk a ?crit :
> > > When there are several possible interpretations, you have to pick up the
> > > more conservative one, as it's not up to us to make the interpretation,
> > > but to a court.
> >
> > If Debian was at least consistent.
> >
> > Why has Debian a much more liberal interpretation of MP3 patent issues
> > than RedHat?
>
> Because we already know that patents on MP3 decoders are not
> enforceable. Furthermore, the holders of these patents have repeatedly
How do you know the patents aren't enforceable?
> stated they won't ask for fees on MP3 decoders.
http://www.mp3licensing.com/royalty/index.html
talks about 0.75 Dollar for a decoder.
> > How do you install Debian on a harddisk behind a SCSI controller who's
> > driver was removed from the Debian kernels due to it's firmware?
>
> Which SCSI controller are you talking about?
Quoting README.Debian of the Debian kernel sources:
<-- snip -->
* QLA2XXX firmware, driver disabled:
. drivers/scsi/qla2xxx/*_fw.c
<-- snip -->
There are a few other SCSI controllers where even the Debian kernel
sources still ship both the drivers and the firmware. I do not claim to
understand the latter...
> > > Being careless in the definition of "free software" is a real disservice
> > > to users. It makes them rely on e.g. non-free documentation for everyday
> > > use.
> > >...
> >
> > Documentation is "software"?
>
> Sure.
Every book in my book shelf is software?
That doesn't match how people outside of Debian use the word "software".
> > Non-free documentation is better than no documentation.
> >
> > Non-free software has several problems, but some of them like the right
> > to do modifications are less important for documentation, since e.g.
> > fixes for security bugs are not an issue.
> >
> > Removing the available documentation without an equal replacement is a
> > real disserve for your users.
>
> GFDL documentation will still be available in the non-free archive.
Assuming you have an online connection and a friend told you how to
manually edit your /etc/apt/sources.list for non-free.
But where's the documentation if you don't have an online connection but
only the dozen binary CDs of Debian?
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Le vendredi 08 avril 2005 à 20:01 +0200, Adrian Bunk a écrit :
> > Because we already know that patents on MP3 decoders are not
> > enforceable. Furthermore, the holders of these patents have repeatedly
>
> How do you know the patents aren't enforceable?
Because decoding a MP3 is a trivial operation.
> > stated they won't ask for fees on MP3 decoders.
>
> http://www.mp3licensing.com/royalty/index.html
>
> talks about 0.75 Dollar for a decoder.
I can't find the reference, but IIRC it was stated later that they don't
want to apply this to free (as in beer) software.
> > > Documentation is "software"?
> >
> > Sure.
>
> Every book in my book shelf is software?
If you digitalize it, yes.
> That doesn't match how people outside of Debian use the word "software".
When we tried to define what is "software", the only acceptable
definitions we found were things like "every kind of numeric stuff" or
"everything that can be included in Debian". You can try to come up with
your own, you'll see it's not that easy.
> > GFDL documentation will still be available in the non-free archive.
>
> Assuming you have an online connection and a friend told you how to
> manually edit your /etc/apt/sources.list for non-free.
>
> But where's the documentation if you don't have an online connection but
> only the dozen binary CDs of Debian?
Without the GFDL documentation, you'll have the right to lock the room
in which you put the CDs. The GFDL forbids that, because you'd be "using
technical measures to obstruct further copying" of the documentations.
--
.''`. Josselin Mouette /\./\
: :' : [email protected]
`. `' [email protected]
`- Debian GNU/Linux -- The power of freedom
Adrian Bunk <[email protected]> writes:
> On Fri, Apr 08, 2005 at 07:42:51PM +0200, Josselin Mouette wrote:
>> Le vendredi 08 avril 2005 ? 19:34 +0200, Adrian Bunk a ?crit :
>> GFDL documentation will still be available in the non-free archive.
>
> Assuming you have an online connection and a friend told you how to
> manually edit your /etc/apt/sources.list for non-free.
You *do* know that current versions of the installer ask you if you want
non-free, don't you?
> But where's the documentation if you don't have an online connection but
> only the dozen binary CDs of Debian?
Clearly, since the judgement is "it can't be legally distributed as part
of a package of Debian CD's", it isn't on a package of Debian CD's.
cheers, Rich.
--
rich walker | Shadow Robot Company | [email protected]
technical director 251 Liverpool Road |
need a Hand? London N1 1LX | +UK 20 7700 2487
http://www.shadow.org.uk/products/newhand.shtml
> I think the "derivative work" angle is a red herring. I do not think
> that either of the two parts that are being linked together (i.e. the
> driver and the firmware) are derivates of the other. The relevant
> point is that distribution of the linked _result_ is nevertheless
> subject to the condition in GPL #2, which is in general the only
> source we have for a permission to distribute a non-verbatim-source
> form of the driver.
If the thing distributed is not the covered work and not a derivative work,
why does the GPL apply to it at all?
DS
On Fri, Apr 08, 2005 at 07:34:00PM +0200, Adrian Bunk wrote:
> If Debian was at least consistent.
>
> Why has Debian a much more liberal interpretation of MP3 patent issues
> than RedHat?
It's impossible to treat patents consistently.
The U.S. patent office, at least, has granted patents on natural laws,
on stuff that's already patented, on stuff with clear prior art, on
trivial math operations and so on. Patents are being granted so quickly
there's no way of even knowing what's patented.
Or were you hoping that Debian would follow Red Hat's lead?
As for this particular patent, I'm not really sure what's being patented.
Trial and error? Spectral quantization? The specific data format?
Addition, multiplication, and exponentiation? In many respects, mp3 is
similar to jpeg. Does that mean that any use of the techniques used
by jpeg in the domain of audio is covered by this patent? Does that
mean that jpeg is in violation of this patent? If I use the same kind
of math with a time dimension, am I violating some other mpeg patents?
What about the other hundreds of thousands of patents? How many of
them am I violating when I use lossy compression based on spectral
quantization?
--
Raul
Scripsit "David Schwartz" <[email protected]>
>> I think the "derivative work" angle is a red herring. I do not think
>> that either of the two parts that are being linked together (i.e. the
>> driver and the firmware) are derivates of the other. The relevant
>> point is that distribution of the linked _result_ is nevertheless
>> subject to the condition in GPL #2, which is in general the only
>> source we have for a permission to distribute a non-verbatim-source
>> form of the driver.
> If the thing distributed is not the covered work and not a
> derivative work, why does the GPL apply to it at all?
You are free to not apply the GPL to it.
However, then you cannot legally copy it at all, because it contains
part of the original author's copyrightedwork and therefore can only
legally be copied with the permission of the author.
--
Henning Makholm "The great secret, known to internists and
learned early in marriage by internists' wives, but
still hidden from the general public, is that most things get
better by themselves. Most things, in fact, are better by morning."
On Fri, Apr 08, 2005 at 08:31:22PM -0400, Raul Miller wrote:
> On Fri, Apr 08, 2005 at 07:34:00PM +0200, Adrian Bunk wrote:
> > If Debian was at least consistent.
> >
> > Why has Debian a much more liberal interpretation of MP3 patent issues
> > than RedHat?
>
> It's impossible to treat patents consistently.
>
> The U.S. patent office, at least, has granted patents on natural laws,
> on stuff that's already patented, on stuff with clear prior art, on
> trivial math operations and so on. Patents are being granted so quickly
> there's no way of even knowing what's patented.
>
> Or were you hoping that Debian would follow Red Hat's lead?
Even RedHat with a stronger financial background than Debian considered
the MP3 patents being serious enough to remove MP3 support.
Yes, Debian can choose to put a higher risk on their distributors and
mirrors - there's nothing wrong with this.
Note that this is a respose to Josselin's statement:
<-- snip -->
When there are several possible interpretations, you have to pick up the
more conservative one, as it's not up to us to make the interpretation,
but to a court.
<-- snip -->
It's simply silly to be extremely picky on copyright issues while being
extremely liberal on patent issues - the risk of a Debian distributor
being sued for patent violations (no matter how the lawsuit might end)
is definitely present.
> As for this particular patent, I'm not really sure what's being patented.
>...
Which one of the 23 patents they list do you call "this particular
patent"?
> Raul
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
> > It's impossible to treat patents consistently.
On Sat, Apr 09, 2005 at 04:38:15PM +0200, Adrian Bunk wrote:
> Even RedHat with a stronger financial background than Debian considered
> the MP3 patents being serious enough to remove MP3 support.
It's silly to treat financial risk as being a one dimensional quantity.
It could easily be that Red Hat decided that the mp3 patent owners would
be going after people with deep pockets. If this is the risk model,
Red Hat's risk would be much much higher than Debian's.
> Note that this is a respose to Josselin's statement:
>
< When there are several possible interpretations, you have to pick up the
< more conservative one, as it's not up to us to make the interpretation,
< but to a court.
Sure, if you have several plausible interpretations, you pick the one
you feel is likely to be the most important, and if all of them seem
likely you pick the one that seems worst.
But, ultimately, you can't treat software patents consistently.
There's no reasonable way to do so.
> It's simply silly to be extremely picky on copyright issues while being
> extremely liberal on patent issues - the risk of a Debian distributor
> being sued for patent violations (no matter how the lawsuit might end)
> is definitely present.
Anything to do with software patents is silly. Being liberal about
software patents is silly. Being conservative about software patents
is silly.
Copyright, while far from perfect, can at least be reasoned about.
> > As for this particular patent, I'm not really sure what's being patented.
> >...
> Which one of the 23 patents they list do you call "this particular
> patent"?
What makes you think I'm sure about what's being patented in 22 of
those patents?
I should probably have said "As for patent claims applying to mp3,
...", but the issue is thorny enough that even that might not have been
accurate enough.
But, treating "this particular patent" as a meta-syntactic variable
should be adequate for you to understand what I was saying.
Bottom line, though: softare patents generally make very little sense.
--
Raul
> Scripsit "David Schwartz" <[email protected]>
> >> I think the "derivative work" angle is a red herring. I do not think
> >> that either of the two parts that are being linked together (i.e. the
> >> driver and the firmware) are derivates of the other. The relevant
> >> point is that distribution of the linked _result_ is nevertheless
> >> subject to the condition in GPL #2, which is in general the only
> >> source we have for a permission to distribute a non-verbatim-source
> >> form of the driver.
> > If the thing distributed is not the covered work and not a
> > derivative work, why does the GPL apply to it at all?
> You are free to not apply the GPL to it.
> However, then you cannot legally copy it at all, because it contains
> part of the original author's copyrighted work and therefore can only
> legally be copied with the permission of the author.
The way you stop someone from distributing part of your work is by arguing
that the work they are distributing is a derivative work of your work and
they had no right to *make* it in the first place. See, for example, Mulcahy
v. Cheetah Learning.
My point is that the reason the derivative work issue is so important is
because it's the only way (in U.S. law anyway) that the GPL can apply to
anything other than the exact thing the author chose to apply it to. The GPL
applies to distributing a Linux binary I just made even though nobody ever
chose to apply the GPL to the binary I just made only because the binary I
just made is a derivative work of the Linux kernel, and the authors of that
work chose to apply the GPL to it.
DS
(Henning Makholm, I assume; I seem to be missing the actual message and
David's mailer forgot to put a quote header on the original reply):
> > >> I think the "derivative work" angle is a red herring. I do not think
> > >> that either of the two parts that are being linked together (i.e. the
> > >> driver and the firmware) are derivates of the other. The relevant
The two parts are not derivatives of each other, of course; that's
obvious. (If I take your firmware, David's firmware loader, and link
them together, I havn't change either of your works.) The resulting
linked binary, however, is a derivative work of both.
I've heard the claim, several times, that that creating a derivative
work requires creative input, that linking stuff together with "ld" is
completely uncreative, therefore no derivative work is created. (I'm
not sure if you're making (here or elsewhere) that claim, but it seems
like it.) What's the basis for this claim? (If you're not making it,
anybody that does believe this is free to respond.)
The case David referred to[1] says "A derivative work may itself be
copyrighted if it has the requisite originality." This seems to imply
that something can be a derivative work without creative input (though
no new copyright would exist beyond that of the source objects). It
seems that while "creative input" is required for copyright to exist,
it is not required for creating a derivative work.
[1] http://caselaw.lp.findlaw.com/data2/circs/8th/033112p.pdf
On Sat, Apr 09, 2005 at 08:07:03PM -0700, David Schwartz wrote:
> The way you stop someone from distributing part of your work is by arguing
> that the work they are distributing is a derivative work of your work and
> they had no right to *make* it in the first place. See, for example, Mulcahy
> v. Cheetah Learning.
Er, that's one way, but not *the* way. I could grant you permission to
create derivatives of my work, but not to redistribute them. To stop you
from distributing them, I'd argue that you had no right to distribute
them--you *did* have the right to make it in the first place.
The GPL does this. Note GPL #2b: "any work that you distribute or publish".
If you don't distribute or publish the derivative work, the work does not
need to be "licensed ... under the terms of this License." It very carefully
separates the permissions granted for merely creating a derivative work,
and the permissions granted for distributing those works; if you distribute
a linked binary in violation of the GPL, you may very well have had permission
to make it in the first place.
(Of course, if whether the work is a derivative is in question, that would
need to be established--you would, indeed, need to argue that the work they
are distributing is a derivative work--but you wouldn't necessarily further
argue that they had no right to make it in the first place.)
--
Glenn Maynard
On Fri, 08 Apr 2005 20:42:17 +0200, Josselin Mouette wrote:
>> Every book in my book shelf is software?
>
> If you digitalize it, yes.
AFAIK software only refers to programs, not to arbitrary sequences of
bytes. An MP3 file isn't "software". Although it surely isn't hardware
either.
--
Giuseppe "Oblomov" Bilotta
"E la storia dell'umanit?, babbo?"
"Ma niente: prima si fanno delle cazzate,
poi si studia che cazzate si sono fatte"
(Altan)
("And what about the history of the human race, dad?"
"Oh, nothing special: first they make some foolish things,
then you study what foolish things have been made")
> On Sat, Apr 09, 2005 at 08:07:03PM -0700, David Schwartz wrote:
> > The way you stop someone from distributing part of your
> > work is by arguing
> > that the work they are distributing is a derivative work of
> > your work and
> > they had no right to *make* it in the first place. See, for
> > example, Mulcahy
> > v. Cheetah Learning.
> Er, that's one way, but not *the* way. I could grant you permission to
> create derivatives of my work, but not to redistribute them. To stop you
> from distributing them, I'd argue that you had no right to distribute
> them--you *did* have the right to make it in the first place.
You could do that be means of a contract, but I don't think you could it do
by means of a copyright license. The problem is that there is no right to
control the distribution of derivative works for you to withhold from me.
> The GPL does this. Note GPL #2b: "any work that you distribute
> or publish".
> If you don't distribute or publish the derivative work, the work does not
> need to be "licensed ... under the terms of this License." It
> very carefully
> separates the permissions granted for merely creating a derivative work,
> and the permissions granted for distributing those works; if you
> distribute
> a linked binary in violation of the GPL, you may very well have
> had permission
> to make it in the first place.
Yes, but this would be valid if and only if there was a right to restrict
the distribution of derivative works that was recognized under copyright
law. I can find no record of the existence of such a right.
> (Of course, if whether the work is a derivative is in question, that would
> need to be established--you would, indeed, need to argue that the
> work they
> are distributing is a derivative work--but you wouldn't
> necessarily further
> argue that they had no right to make it in the first place.)
Well that's the problem. While copyright law does permit you to restrict
the right to create derivative works, it doesn't permit you to restrict the
distribution of lawfully created derivative works to licensees of the
original work. As far as I know, no law has ever granted this right to
copyright holders and no court has ever recognized this right. And I've
looked. Courts have specifically recognized the absence of this right.
DS
Scripsit "David Schwartz" <[email protected]>
>> However, then you cannot legally copy it at all, because it contains
>> part of the original author's copyrighted work and therefore can only
>> legally be copied with the permission of the author.
> The way you stop someone from distributing part of your work
> is by arguing that the work they are distributing is a derivative
> work of your work and they had no right to *make* it in the first
> place. See, for example, Mulcahy v. Cheetah Learning.
You don't need to argue that the thing being distributed is a
derivative work. It is enough that it _contains_ your copyrighted
work.
> My point is that the reason the derivative work issue is so
> important is because it's the only way (in U.S. law anyway) that the
> GPL can apply to anything other than the exact thing the author
> chose to apply it to.
The taske of the GPL is to _give permission_ when certain conditions
hold. Therefore, if the GPL does not apply yet you still need
permission from the author (beacuse what you're distributing contains
his work), then you do not have that permission and cannot distribute
_at all_.
I'm not sure whether meant instead that the original _copyright_ only
influences things that are derivative works, but that would have even
more bizarre consequences.
> The GPL applies to distributing a Linux binary I just made even
> though nobody ever chose to apply the GPL to the binary I just made
> only because the binary I just made is a derivative work of the
> Linux kernel, and the authors of that work chose to apply the GPL to
> it.
How can the binary be a derivative work when it does *not* contain
firmware, but suddenly cease to be a derivative work if one *does*
add firmware into it?
--
Henning Makholm "Vi skal nok ikke begynde at undervise hinanden i
den store regnekunst her, men jeg vil foresl?, at vi fra
Kulturministeriets side s?rger for at fremsende tallene og ogs?
give en beskrivelse af, hvordan man l?ser tallene. Tak for i dag!"
On Sun, Apr 10, 2005 at 01:18:11PM -0700, David Schwartz wrote:
> Well that's the problem. While copyright law does permit you to restrict
> the right to create derivative works, it doesn't permit you to restrict the
> distribution of lawfully created derivative works to licensees of the
> original work. As far as I know, no law has ever granted this right to
> copyright holders and no court has ever recognized this right. And I've
> looked. Courts have specifically recognized the absence of this right.
The GPL is very clear in its implementation: it grants wider permission
to create derivative works than to distribute them, implementing its
"virality" in terms of restrictions on distribution, not creation. So,
it seems that you're claiming that the GPL is broken or unenforcable in
some aspects. (If you're not, I'd like to know where I'm confused.)
If that's the case, it's a claim I'm not qualified to debate, but would
be interested in hearing the FSF's response.
--
Glenn Maynard
> On Sun, Apr 10, 2005 at 01:18:11PM -0700, David Schwartz wrote:
> > Well that's the problem. While copyright law does permit
> > you to restrict
> > the right to create derivative works, it doesn't permit you to
> > restrict the
> > distribution of lawfully created derivative works to licensees of the
> > original work. As far as I know, no law has ever granted this right to
> > copyright holders and no court has ever recognized this right. And I've
> > looked. Courts have specifically recognized the absence of this right.
> The GPL is very clear in its implementation: it grants wider permission
> to create derivative works than to distribute them, implementing its
> "virality" in terms of restrictions on distribution, not creation.
It doesn't even need to do this. First sale grants the right to use a work
one lawfully possesses. One cannot "use" the Linux kernel source without
compiling it. So one doesn't need the GPL to create at least some derivative
works.
> So,
> it seems that you're claiming that the GPL is broken or unenforcable in
> some aspects. (If you're not, I'd like to know where I'm confused.)
> If that's the case, it's a claim I'm not qualified to debate, but would
> be interested in hearing the FSF's response.
It has always been the FSF's position that you don't need to agree to the
GPL to use the covered work. One cannot use the Linux kernel without
compiling it and linking it. One cannot use a library without creating a
work that uses the library, including the header files, and
compiling/linking to form a result. So you can *create* a broad array of
derivative works without invoking the GPL's restrictions (under first sale
and how source code is ordinarily used).
The argument that you cannot distribute a derived work unless the GPL says
you can *because* you must have agreed to the GPL in order to lawfully
create the derivative work is pure bunk. I don't know that the FSF relies
upon the argument, however, it came up in this thread, which is why I
refuted it (at least four times now). ;)
DS
> > The GPL applies to distributing a Linux binary I just made even
> > though nobody ever chose to apply the GPL to the binary I just made
> > only because the binary I just made is a derivative work of the
> > Linux kernel, and the authors of that work chose to apply the GPL to
> > it.
> How can the binary be a derivative work when it does *not* contain
> firmware, but suddenly cease to be a derivative work if one *does*
> add firmware into it?
Because, the argument would go, the binary with the firmware linked in is
not a work, it is two works that are aggregated because there's a license
boundary between them. The argument would be that the binary with the
firmware is *a* *derivative* *work* of the Linux kernel source. The "a" is a
critical part of the argument that cannot be omitted. Showing that the
linked binary was two works would be sufficient to significantly weaken the
argument that it can't be distributed.
You can't argue that only the GPL gives you the right to distribute the
result, regardless of what it is, because there are other sources of such
rights. These include fair use, first sale, and the fact that the law does
not create a special right to restrict the distribution of lawfully-created
derivative works (to licensees of the original work).
My point is not simply that the question of whether or not linking creates
a single work that is a derivative work of all the things linked is
important to the question of whether you can distribute GPL'd works linked
with non-GPL'd works. And the standard is copyright law, not what the GPL
says. (Though that's also important, because then you would have even more
rights.)
DS
Glenn Maynard wrote:
> I've heard the claim, several times, that that creating a derivative
> work requires creative input, that linking stuff together with "ld" is
> completely uncreative, therefore no derivative work is created. (I'm
> not sure if you're making (here or elsewhere) that claim, but it seems
> like it.) What's the basis for this claim? (If you're not making it,
> anybody that does believe this is free to respond.)
It's based on Title 17 USC, Sec. 101, where "derivative work" is defined:
A “derivative work” is a work based upon one or more preexisting works,
such as a translation, musical arrangement, dramatization,
fictionalization, motion picture version, sound recording, art
reproduction, abridgment, condensation, or any other form in which a
work may be recast, transformed, or adapted. A work consisting of
editorial revisions, annotations, elaborations, or other modifications
which, as a whole, represent an ORIGINAL WORK OF AUTHORSHIP, is a
“derivative work”. (emphasis added)
Adrian Bunk wrote:
>Even RedHat with a stronger financial background than Debian considered
>the MP3 patents being serious enough to remove MP3 support.
>
>
Actually, they did it to spite the patent holders.
[]s
Massa
Giuseppe Bilotta wrote:
>On Fri, 08 Apr 2005 20:42:17 +0200, Josselin Mouette wrote:
>
>
>
>>>Every book in my book shelf is software?
>>>
>>>
>>If you digitalize it, yes.
>>
>>
>
>AFAIK software only refers to programs, not to arbitrary sequences of
>bytes. An MP3 file isn't "software". Although it surely isn't hardware
>either.
>
>
>
AFAIK "software" is just the complementary concept of "hardware".
Hardware is hard, ie, the parts of anything you can touch. Software is
the *information* part of anything. In the case of a table, hardware are
the wood, nails, nuts and bolts that make the table and software is the
design of the table, the recipy of the resin used to coat it, etc. In
the case of a computer, hardware is the boards, case, monitor and
software is all the information used to make the thing work, including
all programs and all data contained in it.
[]
Massa
David Schwartz wrote:
> > On Sat, Apr 09, 2005 at 08:07:03PM -0700, David Schwartz wrote:
>
>
> >> The way you stop someone from distributing part of your work is
> >> by arguing that the work they are distributing is a derivative
> >> work of your work and they had no right to *make* it in the first
> >> place. See, for example, Mulcahy v. Cheetah Learning.
>
>
> > Er, that's one way, but not *the* way. I could grant you
> > permission to create derivatives of my work, but not to
> > redistribute them. To stop you from distributing them, I'd argue
> > that you had no right to distribute them--you *did* have the right
> > to make it in the first place.
>
>
> You could do that be means of a contract, but I don't think you could
> it do by means of a copyright license. The problem is that there is
> no right to control the distribution of derivative works for you to
> withhold from me.
Wrong, sorry. Copyright is a *monopoly* on some activities (copy,
distribution of copies, making *and* distribution of derivative works).
HTH,
Massa
Humberto Massa writes:
> David Schwartz wrote:
>
>> > On Sat, Apr 09, 2005 at 08:07:03PM -0700, David Schwartz wrote:
>>
>>
>> >> The way you stop someone from distributing part of your work is
>> >> by arguing that the work they are distributing is a derivative
>> >> work of your work and they had no right to *make* it in the first
>> >> place. See, for example, Mulcahy v. Cheetah Learning.
>>
>>
>> > Er, that's one way, but not *the* way. I could grant you
>> > permission to create derivatives of my work, but not to
>> > redistribute them. To stop you from distributing them, I'd argue
>> > that you had no right to distribute them--you *did* have the right
>> > to make it in the first place.
>>
>>
>> You could do that be means of a contract, but I don't think you could
>> it do by means of a copyright license. The problem is that there is
>> no right to control the distribution of derivative works for you to
>> withhold from me.
> Wrong, sorry. Copyright is a *monopoly* on some activities (copy,
> distribution of copies, making *and* distribution of derivative works).
Copyright law only _explicitly_ grants a monopoly on preparation of
derivative works. However, it is trivial, and overwhelmingly common,
for a copyright owner to grant a license to create a derivative work
that is conditional on how the licensee agrees to distribute (or not
distribute) the derivative work.
Michael Poole
Michael Poole wrote:
>Copyright law only _explicitly_ grants a monopoly on preparation of
>derivative works. However, it is trivial, and overwhelmingly common,
>for a copyright owner to grant a license to create a derivative work
>that is conditional on how the licensee agrees to distribute (or not
>distribute) the derivative work.
>
>Michael Poole
>
>
Conceded. Altough .br's "computer programs" law explicitly says that you
can reserve, in a license to create derivative works, all the rights
over the derivative works.
Massa
[I'm not subscribed, so this in not a real reply - sorry if it breaks
threading somehow.]
Sven Luther wrote:
> The ftp-master are the ones reviewing the licencing problems, and they
are the
> ones handling the infrastructure, and putting their responsability on the
> stake. If they feel that some piece of software has dubious legal issues which
> come at a risk of having them personally come on the receiving end of a legal
> case, then they will say, no, we don't distribute this software, and that is
> the end of it.
I've been following the whole discussion (including later messages),
but I'm still missing one point. You seem to have investigated a lot
on the subject, so I'll ask you. I don't get what real legal issues
distributors may have.
Let me explain with an example. Lets say:
A - is the Author (or rights owner) of the software (GPL'ed);
B - is an user, who got the a copy of the software from A;
C - is another user, who got a copy indirectly, that is from a
distributor;
D - is the distributor C got the copy from.
Now, IANAL at all. But it seems to me that B has the right to _use_ the
software by means of GPL. As long as A thinks B doesn't break GPL, B is
fine. All B needs to do is to fulfill GPL conditions (as a user, there's
little to do).
C also has the right to use the software, in a very similar way. As long
as A thinks C doesn't break GPL, C is fine.
D has the right to distribute the software, under GPL terms. As long as
A thinks D doesn't break GPL, D is fine.
Now. It seems to me that the relationship between D (distributor) and C
(target of the distribution) is _not_ regulated by GPL at all. GPL is a
license, the _owner_ of the rights (A) and the recipient of some rights
(C, as an user) are the only subjects. D _owns_ no rights on the
software, so can't grant any to C. There's no GPL between D and C.
So, even if C comes to think D is breaking GPL, all C can do is notify
A. The GPL D is supposedly breaking is an agreement between A and D
only. On which basis may C sue D? For breaking what agreement? It's up
to A to sue D for breaking GPL.
What is the risk for D, if D is distributing the source of the software
_exactly_ in the form A publicly provides it? It's not up to D to
produce the source, all D has to do is to provide verbatim copies of
it to anyone D distributes the software to, on request.
Does is really matter if C thinks the source being incomplete,
or missing? C can take the issue up with A (by means of the GPL that
exists between A and C), but not with D, since there's no GPL between
D and C. C is in the same position of B. If the source is incomplete,
they may ask A to comply to the GPL, but not D. D made no promises to
them.
So, as long as they don't modify the source, distributors are safe.
No one can ask them to provide the "right" source, but A. And "right"
means "right for A", of course, when it's A asking, by definition.
What am I missing?
TIA,
.TM.
On Mon, Apr 11, 2005 at 06:12:22PM +0200, Marco Colombo wrote:
> [I'm not subscribed, so this in not a real reply - sorry if it breaks
> threading somehow.]
>
> Sven Luther wrote:
> > The ftp-master are the ones reviewing the licencing problems, and they
> are the
> > ones handling the infrastructure, and putting their responsability on the
> > stake. If they feel that some piece of software has dubious legal issues which
> > come at a risk of having them personally come on the receiving end of a legal
> > case, then they will say, no, we don't distribute this software, and that is
> > the end of it.
>
> I've been following the whole discussion (including later messages),
> but I'm still missing one point. You seem to have investigated a lot
> on the subject, so I'll ask you. I don't get what real legal issues
> distributors may have.
>
> Let me explain with an example. Lets say:
>
> A - is the Author (or rights owner) of the software (GPL'ed);
> B - is an user, who got the a copy of the software from A;
> C - is another user, who got a copy indirectly, that is from a
> distributor;
> D - is the distributor C got the copy from.
>
> Now, IANAL at all. But it seems to me that B has the right to _use_ the
> software by means of GPL. As long as A thinks B doesn't break GPL, B is
> fine. All B needs to do is to fulfill GPL conditions (as a user, there's
> little to do).
>
> C also has the right to use the software, in a very similar way. As long
> as A thinks C doesn't break GPL, C is fine.
>
> D has the right to distribute the software, under GPL terms. As long as
> A thinks D doesn't break GPL, D is fine.
>
> Now. It seems to me that the relationship between D (distributor) and C
> (target of the distribution) is _not_ regulated by GPL at all. GPL is a
> license, the _owner_ of the rights (A) and the recipient of some rights
> (C, as an user) are the only subjects. D _owns_ no rights on the
> software, so can't grant any to C. There's no GPL between D and C.
I think you are missing the point. D get's a licence from A, the GPL, and this
licence includes a licence, not on use, but on redistribution, and the act of
D distributing the copy to C is covered by it. In a sense A allows D to
distribute the software under the GPL to C. Now, D is only allowed to do this
distribution if he also distribute the source code of it, which he can't do
for the firmware.
Notice also the fact that there are so many contributors to the linux kernel
in effect means that there is nobody with the full rights as A, but only a
multitude of people in the D case.
> So, even if C comes to think D is breaking GPL, all C can do is notify
> A. The GPL D is supposedly breaking is an agreement between A and D
> only. On which basis may C sue D? For breaking what agreement? It's up
> to A to sue D for breaking GPL.
This is indeed an interpretation. I am not sure myself if a user receiving
GPLed software in binary only fashion as is the case here can sue either D or
A to get access to that source code.
Now you could argue that any number of authors of GPLed bits of the linux
kernel could sue D for distributing their software as a derived work of the
binary-only bit, and the fact that D doesn't distribute the source code to the
binary bit voids any other right allowed him by the GPL, and thus he has no
right to do the distribution at all. The GPL is very clear on this topic.
> What is the risk for D, if D is distributing the source of the software
> _exactly_ in the form A publicly provides it? It's not up to D to
> produce the source, all D has to do is to provide verbatim copies of
> it to anyone D distributes the software to, on request.
Imagine one of those companies got bought up by some predatory company who
wishes us (linux, debian, redhat/suse, whoever) harm. They would then be able
to sue for damage or prejudice or whatever. And given what i have heard about
the uncertainities of the Alteon ownership, this seems indeed like a plausible
scenario, which could result in a SCO bis case.
This is the scenario i want to avoid by explicitly stating the relationships
of all copyright issues of those firmware blobs.
> Does is really matter if C thinks the source being incomplete,
> or missing? C can take the issue up with A (by means of the GPL that
> exists between A and C), but not with D, since there's no GPL between
> D and C. C is in the same position of B. If the source is incomplete,
> they may ask A to comply to the GPL, but not D. D made no promises to
> them.
/me wonders if C then holds an illegal copy of the software, and can then be
prosecuted for piracy :)
Friendly,
Sven Luther
> > You could do that be means of a contract, but I don't think you could
> > it do by means of a copyright license. The problem is that there is
> > no right to control the distribution of derivative works for you to
> > withhold from me.
> Wrong, sorry. Copyright is a *monopoly* on some activities (copy,
> distribution of copies, making *and* distribution of derivative works).
Perhaps you could cite the law that restricts to the copyright holder the
right to restrict the distribution of derivative works. I can cite the laws
that restrict all those other things and clearly *don't* mention
distribution of derivative works.
[from another post]
>Copyright law only _explicitly_ grants a monopoly on preparation of
>derivative works. However, it is trivial, and overwhelmingly common,
>for a copyright owner to grant a license to create a derivative work
>that is conditional on how the licensee agrees to distribute (or not
>distribute) the derivative work.
This would, of course, only make sense if you *had* to agree to the license
to *create* the derivative work. If you were able to create the derivative
work under first sale or fair use rights, then the restrictions in the
contract would not apply to you.
DS
David Schwartz writes:
>>Copyright law only _explicitly_ grants a monopoly on preparation of
>>derivative works. However, it is trivial, and overwhelmingly common,
>>for a copyright owner to grant a license to create a derivative work
>>that is conditional on how the licensee agrees to distribute (or not
>>distribute) the derivative work.
>
> This would, of course, only make sense if you *had* to agree to the license
> to *create* the derivative work. If you were able to create the derivative
> work under first sale or fair use rights, then the restrictions in the
> contract would not apply to you.
This would, of course, only make sense if fair use or first sale
rights *allow* the creation of derivative works. I have seen nothing
in this thread or in the statutes to suggest that they do.
Do not forget that your copyright interest in a derivative work is
limited to the creative elements which you contributed. Simply having
a license (or right) to create a derivative work does not permit you
to infringe the original work's copyright, which still subsists in the
derivative work insofar as the derivative work contains copyrightable
elements from the original work.
Even if some court agrees with your hypothesis that the compiled
program is a derivative work of the source (which I doubt would
happen), and you find some permission outside of the GPL to prepare
that derivative work, you still need permission to copy it further.
Michael Poole
On Sun, Apr 10, 2005 at 01:18:11PM -0700, David Schwartz wrote:
> You could do that be means of a contract, but I don't think you
> could it do by means of a copyright license. The problem is that there
> is no right to control the distribution of derivative works for you
> to withhold from me.
While you are may be reporting your thoughts accurately, this problem
doesn't seem to be a legal issue.
The GPL explicitly discusses this issue (section 5), and a number of
people have already posted with similar commentary.
Anyways, one thing to keep in mind here is that if copyright law doesn't
allow the GPL's grant of permission to be conditional then copyright
law would not allow other copyright grants to be conditional.
Another way of looking at this is that the GPL is a copyright license --
it represents the terms and conditions under which copyrights are granted,
and it also represents those permissions.
--
Raul
On Mon, Apr 11, 2005 at 12:31:53PM -0700, David Schwartz wrote:
> Perhaps you could cite the law that restricts to the copyright
> holder the right to restrict the distribution of derivative works. I can
> cite the laws that restrict all those other things and clearly *don't*
> mention distribution of derivative works.
17 USC 103
17 USC 106
--
Raul
On Sun, Apr 10, 2005 at 11:24:10AM +0200, Giuseppe Bilotta wrote:
> AFAIK software only refers to programs, not to arbitrary sequences of
> bytes. An MP3 file isn't "software". Although it surely isn't hardware
> either.
This point is a controversial point. Different people make different
claims.
For example, http://www.answers.com/software -- the Computer Desktop
Encyclopedia asserts that you are correct, while Wikipedia asserts that
you are incorrect. The American Heritage Dictionary implies you are
correct, and WordNet implies that you're incorrect.
Usage is still evolving, so who knows where this issue will stand in
five years.
In the context of the linux kernel (which I presume you're talking about,
given the message headers), I don't think it's plausible to suggest that
the occasional use of the term "software" in the license means that the
stuff under Documentation/ isn't covered by the license.
--
Raul
On Mon, 2005-04-11 at 18:25 +0200, Sven Luther wrote:
> On Mon, Apr 11, 2005 at 06:12:22PM +0200, Marco Colombo wrote:
[...]
> > A - is the Author (or rights owner) of the software (GPL'ed);
> > B - is an user, who got the a copy of the software from A;
> > C - is another user, who got a copy indirectly, that is from a
> > distributor;
> > D - is the distributor C got the copy from.
[...]
> > Now. It seems to me that the relationship between D (distributor) and C
> > (target of the distribution) is _not_ regulated by GPL at all. GPL is a
> > license, the _owner_ of the rights (A) and the recipient of some rights
> > (C, as an user) are the only subjects. D _owns_ no rights on the
> > software, so can't grant any to C. There's no GPL between D and C.
>
> I think you are missing the point. D get's a licence from A, the GPL, and this
> licence includes a licence, not on use, but on redistribution, and the act of
> D distributing the copy to C is covered by it. In a sense A allows D to
> distribute the software under the GPL to C. Now, D is only allowed to do this
> distribution if he also distribute the source code of it, which he can't do
> for the firmware.
I think only a lawyer can answer here. What I'm saying is that the
license always comes from the copyright owner, that is A.
Sublicensing is not covered by GPL. Distribution is not sublicensing.
Quoting GPL itself:
6. Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions. ...
The wording is clear, the license is between A and C.
There's no license between D and C. There's no way C can enforce
anything on D (well, not on GPL basis).
> Notice also the fact that there are so many contributors to the linux kernel
> in effect means that there is nobody with the full rights as A, but only a
> multitude of people in the D case.
In this case, A is clearly the author (onwer of rights) of the firmware.
D is fine on respect of the other A's, since their source is actually
(and clearly) there. It's the missing source case we're considering
and the number of A's is quite small, the copyright owners of firmware
images. Those A's are easily identified, and perfectly able to act.
> > So, even if C comes to think D is breaking GPL, all C can do is notify
> > A. The GPL D is supposedly breaking is an agreement between A and D
> > only. On which basis may C sue D? For breaking what agreement? It's up
> > to A to sue D for breaking GPL.
>
> This is indeed an interpretation. I am not sure myself if a user receiving
> GPLed software in binary only fashion as is the case here can sue either D or
> A to get access to that source code.
The point is, if A states (even implicitly) D is distributing the right
source, there's nothing C can do to D. D is not breaking GPL, as long A
says so and it's A granting D the right to distribute. There's no way C
can prevent D from distributing A's software, if A is fine with it.
It's up to A to decide if GPL conditions are met by D.
Maybe mine it's only one interpretation. But I can't see any other.
> Now you could argue that any number of authors of GPLed bits of the linux
> kernel could sue D for distributing their software as a derived work of the
> binary-only bit, and the fact that D doesn't distribute the source code to the
> binary bit voids any other right allowed him by the GPL, and thus he has no
> right to do the distribution at all. The GPL is very clear on this topic.
We're not talking of that case. D _is_ actually distributing the right
source, according to A. It's C that is unsatisfied with it.
> > What is the risk for D, if D is distributing the source of the software
> > _exactly_ in the form A publicly provides it? It's not up to D to
> > produce the source, all D has to do is to provide verbatim copies of
> > it to anyone D distributes the software to, on request.
>
> Imagine one of those companies got bought up by some predatory company who
> wishes us (linux, debian, redhat/suse, whoever) harm. They would then be able
> to sue for damage or prejudice or whatever. And given what i have heard about
> the uncertainities of the Alteon ownership, this seems indeed like a plausible
> scenario, which could result in a SCO bis case.
I'm not following. Are you saying what if A is bought? That is
different. Well GPL is quite clear:
1. You may copy and distribute verbatim copies of the Program's source
code as you receive it, ...
If D is distributing the source as received from A, D is in full
compliance. How could A sue D? If A distributed incomplete source
in the first place, it's not D's fault for sure. Do you really think
the following scenario is likely:
A to D: you must distribute the complete source, or the license will be
terminated!
D to A: gimme the complete source, and I'll distribute it.
A to D: no, I'm not willing to give you the full source of my firmware,
but you must distribute it anyway!
That, in court? Is this really what you're afraid of?
The outcome is, very likely A will be forced to release the full source.
(and D forced to distribute it, but all D's we're talking of here are
very happy with the full disclosure scenario, aren't they?)
> This is the scenario i want to avoid by explicitly stating the relationships
> of all copyright issues of those firmware blobs.
I don't see this scenario nowhere close to likely. Of course, A can
always sue any B, C, or D for whatever reason. It's very unlikely
A will sue anyone in full compliance of GPL, but it's possible.
There's nothing we can do about it. But there's no reason to worry
either.
As for the matter of explicit copyright notices, I can only agree.
They won't harm for sure. From a purist standpoint, you're right. And
I _am_ a purist. B-)
> > Does is really matter if C thinks the source being incomplete,
> > or missing? C can take the issue up with A (by means of the GPL that
> > exists between A and C), but not with D, since there's no GPL between
> > D and C. C is in the same position of B. If the source is incomplete,
> > they may ask A to comply to the GPL, but not D. D made no promises to
> > them.
>
> /me wonders if C then holds an illegal copy of the software, and can then be
> prosecuted for piracy :)
No, because GPL explicitly states that:
4. You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License. Any attempt otherwise
to copy, modify, sublicense or distribute the Program is void, and will
automatically terminate your rights under this License. However, parties
who have received copies, or rights, from you under this License will
not have their licenses terminated so long as such parties remain in
full compliance.
Note also that GPL says nothing about how you get your copy. You can
get it while hanging from the ceiling ala Mission Impossible, but if
the software is GPL'ed, then your license is valid. The action may
still be illegal, but that's another matter: you _can_ use the software
(even if in jail). B-)
>
> Friendly,
>
> Sven Luther
Have a nice day,
.TM.
On Mon, Apr 11, 2005 at 10:54:50PM +0200, Marco Colombo wrote:
> In this case, A is clearly the author (onwer of rights) of the firmware.
> D is fine on respect of the other A's, since their source is actually
> (and clearly) there. It's the missing source case we're considering
> and the number of A's is quite small, the copyright owners of firmware
> images. Those A's are easily identified, and perfectly able to act.
Well, i am not sure with your interpretation, but even if you where right, we
have no guarantee that A will continue being lenient, and no guarantee that A
will not start suing D or whoever for illegally distributing his stuff without
sources.
> > > So, even if C comes to think D is breaking GPL, all C can do is notify
> > > A. The GPL D is supposedly breaking is an agreement between A and D
> > > only. On which basis may C sue D? For breaking what agreement? It's up
> > > to A to sue D for breaking GPL.
> >
> > This is indeed an interpretation. I am not sure myself if a user receiving
> > GPLed software in binary only fashion as is the case here can sue either D or
> > A to get access to that source code.
>
> The point is, if A states (even implicitly) D is distributing the right
> source, there's nothing C can do to D. D is not breaking GPL, as long A
So, i get some random bit of GPLed software, i add a module or some code to
it, i distribute that code in binary format only, and claim that i have used
an hex editor to write it, or simply that it is the 'right' source.
I have some serious doubts that i will not get sued by all the authors of the
original GPLed work if i were to do that, and rightly so.
> says so and it's A granting D the right to distribute. There's no way C
> can prevent D from distributing A's software, if A is fine with it.
> It's up to A to decide if GPL conditions are met by D.
Even in that case, you still need explicit permission of A, and all the other
copyright holders of the rest of the GPLed work, to give you an explicit
exception to link with this non-free bit of code.
> Maybe mine it's only one interpretation. But I can't see any other.
>
> > Now you could argue that any number of authors of GPLed bits of the linux
> > kernel could sue D for distributing their software as a derived work of the
> > binary-only bit, and the fact that D doesn't distribute the source code to the
> > binary bit voids any other right allowed him by the GPL, and thus he has no
> > right to do the distribution at all. The GPL is very clear on this topic.
>
> We're not talking of that case. D _is_ actually distributing the right
> source, according to A. It's C that is unsatisfied with it.
No. The source code is clearly the prefered form of modification, not some
random intermediate state A may be claiming is source.
> > > What is the risk for D, if D is distributing the source of the software
> > > _exactly_ in the form A publicly provides it? It's not up to D to
> > > produce the source, all D has to do is to provide verbatim copies of
> > > it to anyone D distributes the software to, on request.
> >
> > Imagine one of those companies got bought up by some predatory company who
> > wishes us (linux, debian, redhat/suse, whoever) harm. They would then be able
> > to sue for damage or prejudice or whatever. And given what i have heard about
> > the uncertainities of the Alteon ownership, this seems indeed like a plausible
> > scenario, which could result in a SCO bis case.
>
> I'm not following. Are you saying what if A is bought? That is
> different. Well GPL is quite clear:
>
> 1. You may copy and distribute verbatim copies of the Program's source
> code as you receive it, ...
>
> If D is distributing the source as received from A, D is in full
> compliance. How could A sue D? If A distributed incomplete source
> in the first place, it's not D's fault for sure. Do you really think
> the following scenario is likely:
>
> A to D: you must distribute the complete source, or the license will be
> terminated!
> D to A: gimme the complete source, and I'll distribute it.
> A to D: no, I'm not willing to give you the full source of my firmware,
> but you must distribute it anyway!
The result is that the code in question has to be stopped from being
distributed by D. But the case here is different, since A is not the sole
copyright owner, so he doesn't get to set random interpretations of what is
source code.
> That, in court? Is this really what you're afraid of?
> The outcome is, very likely A will be forced to release the full source.
> (and D forced to distribute it, but all D's we're talking of here are
> very happy with the full disclosure scenario, aren't they?)
Imagine A refusing to give away the source code, and D is ordered to remove
the incriminated code it is illegally distributing from all its servers, and
recall all those thousands of CD and DVD isos containing the code it
distributed, and being fined for each day it doesn't do so ?
> > This is the scenario i want to avoid by explicitly stating the relationships
> > of all copyright issues of those firmware blobs.
>
> I don't see this scenario nowhere close to likely. Of course, A can
> always sue any B, C, or D for whatever reason. It's very unlikely
> A will sue anyone in full compliance of GPL, but it's possible.
> There's nothing we can do about it. But there's no reason to worry
> either.
So, we don't take the risk and don't distribute it. If A is not ready to put a
couple of lines of disclaimer on his work explaining the copyright and
licencing issues, then we are better of not distributing its code, which is
what debian will do.
> As for the matter of explicit copyright notices, I can only agree.
> They won't harm for sure. From a purist standpoint, you're right. And
> I _am_ a purist. B-)
:)
> > > Does is really matter if C thinks the source being incomplete,
> > > or missing? C can take the issue up with A (by means of the GPL that
> > > exists between A and C), but not with D, since there's no GPL between
> > > D and C. C is in the same position of B. If the source is incomplete,
> > > they may ask A to comply to the GPL, but not D. D made no promises to
> > > them.
> >
> > /me wonders if C then holds an illegal copy of the software, and can then be
> > prosecuted for piracy :)
>
> No, because GPL explicitly states that:
>
> 4. You may not copy, modify, sublicense, or distribute the Program
> except as expressly provided under this License. Any attempt otherwise
> to copy, modify, sublicense or distribute the Program is void, and will
> automatically terminate your rights under this License. However, parties
> who have received copies, or rights, from you under this License will
> not have their licenses terminated so long as such parties remain in
> full compliance.
Yeah, but who know what mad laws will be passed to repress piracy which will
make this void.
> Note also that GPL says nothing about how you get your copy. You can
> get it while hanging from the ceiling ala Mission Impossible, but if
> the software is GPL'ed, then your license is valid. The action may
> still be illegal, but that's another matter: you _can_ use the software
> (even if in jail). B-)
I am not sure. If i where to get a copy of windows, and manage to install it
without clicking on the "i agree" button, does that make it a legal copy of
windows to use ?
Friendly,
Sven Luther
On Mon, 11 Apr 2005, Sven Luther wrote:
> On Mon, Apr 11, 2005 at 10:54:50PM +0200, Marco Colombo wrote:
>> In this case, A is clearly the author (onwer of rights) of the firmware.
>> D is fine on respect of the other A's, since their source is actually
>> (and clearly) there. It's the missing source case we're considering
>> and the number of A's is quite small, the copyright owners of firmware
>> images. Those A's are easily identified, and perfectly able to act.
>
> Well, i am not sure with your interpretation, but even if you where right, we
> have no guarantee that A will continue being lenient, and no guarantee that A
> will not start suing D or whoever for illegally distributing his stuff without
> sources.
Let's keep things separated. I'm saying that the only one that may
sue D is A, not C. If we agree on this, we may abandon the case of a third
party sueing D.
As for threats coming from A, IMHO D is safe as long as he distributes
what A claims the source is, even if it's a hex string. In no world
A can publicly state "this is the source" and then sue D because
"no, that's not the source" (assuming D is copying it verbatim).
>>>> So, even if C comes to think D is breaking GPL, all C can do is notify
>>>> A. The GPL D is supposedly breaking is an agreement between A and D
>>>> only. On which basis may C sue D? For breaking what agreement? It's up
>>>> to A to sue D for breaking GPL.
>>>
>>> This is indeed an interpretation. I am not sure myself if a user receiving
>>> GPLed software in binary only fashion as is the case here can sue either D or
>>> A to get access to that source code.
>>
>> The point is, if A states (even implicitly) D is distributing the right
>> source, there's nothing C can do to D. D is not breaking GPL, as long A
>
> So, i get some random bit of GPLed software, i add a module or some code to
> it, i distribute that code in binary format only, and claim that i have used
> an hex editor to write it, or simply that it is the 'right' source.
>
> I have some serious doubts that i will not get sued by all the authors of the
> original GPLed work if i were to do that, and rightly so.
No. Please don't throw irrelevant matters in. D is not modifing the
software at all. D is a mere distributor. We're not addressing issues
related to modification, since no one is going to modify the firmware
anyway. This is not a general discussion on GPL. Issues related to
modification do not belong to this thread, which already very close
to off topic on l-k.
Which reminds me. The only reason why this thread belongs here, IMHO,
it's because when it comes to GPL, it really doesn't matter what
FSF's interpretation is, or anyone else's. The authors are choosing
GPL as a license, so _thier_ interpretation is what really matters.
>> says so and it's A granting D the right to distribute. There's no way C
>> can prevent D from distributing A's software, if A is fine with it.
>> It's up to A to decide if GPL conditions are met by D.
>
> Even in that case, you still need explicit permission of A, and all the other
> copyright holders of the rest of the GPLed work, to give you an explicit
> exception to link with this non-free bit of code.
Yes, but it does not apply to our case here. There's no "all other
copyright holders". _You_ stated that the firmware is included by mere
aggregation, so there's no other holders involved. We're talking
about the firmware case. A is one or two well identified subjects.
And A wrote it is GPL'ed. Whether you agree or not, that's the licence
A chose. A placed the copyright notice.
The licence is a matter between A and D. A may sue D and D may (less
likely) sue A, if conditions are not met. I'm not sure at all GPL
is enforceable by D upon A. Let's assume it is, for sake of discussion,
anyway.
>>> Now you could argue that any number of authors of GPLed bits of the linux
>>> kernel could sue D for distributing their software as a derived work of the
>>> binary-only bit, and the fact that D doesn't distribute the source code to the
>>> binary bit voids any other right allowed him by the GPL, and thus he has no
>>> right to do the distribution at all. The GPL is very clear on this topic.
>>
>> We're not talking of that case. D _is_ actually distributing the right
>> source, according to A. It's C that is unsatisfied with it.
>
> No. The source code is clearly the prefered form of modification, not some
> random intermediate state A may be claiming is source.
In this context, it is. Only A may sue D for not distributing the source.
Whatever D distributes, D has to make A happy. If A is happy with D
distributing `dd if=/dev/random count=1` as source, no one can stop D
from doing that. Keep in mind A is the copyright holder. He grants
rights to third parties. No one but A can remove them.
[...]
>> I'm not following. Are you saying what if A is bought? That is
>> different. Well GPL is quite clear:
>>
>> 1. You may copy and distribute verbatim copies of the Program's source
>> code as you receive it, ...
>>
>> If D is distributing the source as received from A, D is in full
>> compliance. How could A sue D? If A distributed incomplete source
>> in the first place, it's not D's fault for sure. Do you really think
>> the following scenario is likely:
>>
>> A to D: you must distribute the complete source, or the license will be
>> terminated!
>> D to A: gimme the complete source, and I'll distribute it.
>> A to D: no, I'm not willing to give you the full source of my firmware,
>> but you must distribute it anyway!
>
> The result is that the code in question has to be stopped from being
> distributed by D. But the case here is different, since A is not the sole
> copyright owner, so he doesn't get to set random interpretations of what is
> source code.
Definitely I'm not following. How can D be ordered to stop distributing
the software if A refuses to give the source? A is in violation. And
even if GPL can't be enforced that way, by no means D is in violation
when it's A that it's preventing D from complying.
The only way this can work the way you say is if A and D had a private
agreement, and no proof can be made by D this agreement ever existed.
But A released the software in public, and GPL'ed it. If A wants to keep
part of the source obscured, he had better to stay well away from any
court.
>> That, in court? Is this really what you're afraid of?
>> The outcome is, very likely A will be forced to release the full source.
>> (and D forced to distribute it, but all D's we're talking of here are
>> very happy with the full disclosure scenario, aren't they?)
>
> Imagine A refusing to give away the source code, and D is ordered to remove
> the incriminated code it is illegally distributing from all its servers, and
> recall all those thousands of CD and DVD isos containing the code it
> distributed, and being fined for each day it doesn't do so ?
Sorry, this is nonsense. D is well willing to distribute the source.
In this case, he _is_ distributing what A publicly stated to be the source.
That's all. You say what if A changed his mind about what the source is?
Well since it's still GPL'ed (we agree A can't chance the licence on the
fly, right?) A is to provide the new, complete version of the source.
Then, if and only if D refuses to distribute _that_ source, D is in
violation. GPL requires D to distribute source _as received by A_.
If A refuses to give the source, the specific requirement is not
enforceable.
>>> This is the scenario i want to avoid by explicitly stating the relationships
>>> of all copyright issues of those firmware blobs.
>>
>> I don't see this scenario nowhere close to likely. Of course, A can
>> always sue any B, C, or D for whatever reason. It's very unlikely
>> A will sue anyone in full compliance of GPL, but it's possible.
>> There's nothing we can do about it. But there's no reason to worry
>> either.
>
> So, we don't take the risk and don't distribute it. If A is not ready to put a
> couple of lines of disclaimer on his work explaining the copyright and
> licencing issues, then we are better of not distributing its code, which is
> what debian will do.
There no such a risk. A already placed a copyright notice on his work.
Is it the wrong one? Who cares? I'd even say that once he released it
under GPL, he can't take it back.
This is a close to impossible scenario, so why worry about it?
Anyone may sue you because he doesn't like your name. Or you logo.
Or the name of your server. The risk is by no means lower than the
case you pictured. Why not stopping being debian at all, then?
[...]
> Yeah, but who know what mad laws will be passed to repress piracy which will
> make this void.
Oh, that's totally another matter. I'm not ever sure GPL is a valid
licence for software here in Italy as regards to our anti-piracy law.
Which is criminal law.
>> Note also that GPL says nothing about how you get your copy. You can
>> get it while hanging from the ceiling ala Mission Impossible, but if
>> the software is GPL'ed, then your license is valid. The action may
>> still be illegal, but that's another matter: you _can_ use the software
>> (even if in jail). B-)
>
> I am not sure. If i where to get a copy of windows, and manage to install it
> without clicking on the "i agree" button, does that make it a legal copy of
> windows to use ?
Come on, please, do not mix things up. I've said GPL'ed software. Last time
I checked, Windows was not GPL'ed (yet). :-)
> Friendly,
>
> Sven Luther
Have a nice day,
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ [email protected]
On Tue, Apr 12, 2005 at 02:40:48AM +0200, Marco Colombo wrote:
> Which reminds me. The only reason why this thread belongs here, IMHO,
> it's because when it comes to GPL, it really doesn't matter what
> FSF's interpretation is, or anyone else's. The authors are choosing
> GPL as a license, so _thier_ interpretation is what really matters.
The main problem is that i feel that those binary firmware copyright holders
may have put it under the GPL, but i doubt they realize that this means they
have to release the source code of said firmware blobs.
Also, i believe you are wrong in the above, the only interpretation that is
important is the one the judge will take in case someone goes to suing.
And finally, if anyone could claim that a binary is the prefered form of
modification, which is most of the time obviously false, then the GPL would be
worthless. And anyway, the GPL states this (first paragraph after subclause c
in clause 3) :
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable.
So, this is not some interpretation of the GPL by the FSF, and since it is
written black on white in the actual GPL text, i don't think there is any
doubt what a judge will decice :
judge : so, to create this piece of work, what do you use to make
modifications ?
A (having sworn on the bible to say the truth and only the truth) : euh,
some C or asm code, and a compiler or assembler to compile it.
judge : and you did voluntarily place said code and distribute it under the
GPL ?
A : yes, it was going into the linux kernel, so ...
judge : so you should distribute the source code to your work also, and
distributing it under GPL is a breach of expectation from whoever you
distribute it to.
Or something such.
If A is going to say that he is the only author, and that he would never sue
because of this breach of the GPL, he could just as well have put it under a
different licence, or put a small disclaimer about it, since we cannot really
act as if we believed that A would never sue us, if he doesn't explicitly say
so.
As an example, i package the unicorn driver for the bewan soft-ADSL pci and
usb modems. These being soft-ADSL modems which use a non-free binary-only ADSL
emulating library, but are otherwise GPL, i discussed the matter with
upstream, and after council from debian-legal, and possibly the FSF people
themselves, we got to use this as GPL exception :
In addition, as a special exception, BeWAN systems gives permission
to link the code of this program with the modem SW library
(modem_ant_PCI.o, modem_ant_USB.o), and distribute linked combinations
including the two. You are also given permission to redistribute the
modem SW library (modem_ant_PCI.o, modem_ant_USB.o) with the rest of the
code.
You must obey the GNU General Public License in all respects for all of
the code used other than the modem SW library.
So, really, i doubt any manufacturer distributing non-free firmware would
really have trouble in adding to their licence something like this :
In addition, <manufacturer>, considers the firmware blob, identified as <...>, as
a non-derivative piece of work, and thus not covered by the GPL of the rest
of it. <manufacturer> gives permission to distribute said firmware blob as
part of the linux kernel module driver for their hardware. The actual syntax
of the inclusion of the code is still covered by the GPL, as is the rest of
the driver code.
If we where to get something as nicely pu as this, provide a patch, asking
the manufacturer to sign it of, then all issues would be void, i believe.
> >>says so and it's A granting D the right to distribute. There's no way C
> >>can prevent D from distributing A's software, if A is fine with it.
> >>It's up to A to decide if GPL conditions are met by D.
> >
> >Even in that case, you still need explicit permission of A, and all the
> >other
> >copyright holders of the rest of the GPLed work, to give you an explicit
> >exception to link with this non-free bit of code.
>
> Yes, but it does not apply to our case here. There's no "all other
> copyright holders". _You_ stated that the firmware is included by mere
> aggregation, so there's no other holders involved. We're talking
> about the firmware case. A is one or two well identified subjects.
> And A wrote it is GPL'ed. Whether you agree or not, that's the licence
> A chose. A placed the copyright notice.
This is where i would need legal counsel, as to whether this means C or
someone else may stop you from distributing unless you provide the source. And
the real problem is that A didn't state anything, so we are only working on
the assumption that this may be the case, and A can change its mind later, and
the costs to defend ourselves in front of a judge, even if your
interpretations are right, are enough prohibitive for debian not to distribute
said files.
> The licence is a matter between A and D. A may sue D and D may (less
> likely) sue A, if conditions are not met. I'm not sure at all GPL
> is enforceable by D upon A. Let's assume it is, for sake of discussion,
> anyway.
Ah, but the licence is transitive, and if D may sue A, then C may also sue D,
since the GPL makes no distinction between who makes the distribution, apart
from the fact that A may relicence its code. But if he distributes it as part
of the GPL ...
> >No. The source code is clearly the prefered form of modification, not some
> >random intermediate state A may be claiming is source.
>
> In this context, it is. Only A may sue D for not distributing the source.
> Whatever D distributes, D has to make A happy. If A is happy with D
> distributing `dd if=/dev/random count=1` as source, no one can stop D
> from doing that. Keep in mind A is the copyright holder. He grants
> rights to third parties. No one but A can remove them.
Yep, so if A was giving us an explicit right to distribute his sources,
everyone would be happy, this not being the case, we have to take the
hypothesis that A will sue us at a later time.
> [...]
> >>I'm not following. Are you saying what if A is bought? That is
> >>different. Well GPL is quite clear:
> >>
> >>1. You may copy and distribute verbatim copies of the Program's source
> >>code as you receive it, ...
> >>
> >>If D is distributing the source as received from A, D is in full
> >>compliance. How could A sue D? If A distributed incomplete source
> >>in the first place, it's not D's fault for sure. Do you really think
> >>the following scenario is likely:
> >>
> >>A to D: you must distribute the complete source, or the license will be
> >> terminated!
> >>D to A: gimme the complete source, and I'll distribute it.
> >>A to D: no, I'm not willing to give you the full source of my firmware,
> >> but you must distribute it anyway!
> >
> >The result is that the code in question has to be stopped from being
> >distributed by D. But the case here is different, since A is not the sole
> >copyright owner, so he doesn't get to set random interpretations of what is
> >source code.
>
> Definitely I'm not following. How can D be ordered to stop distributing
> the software if A refuses to give the source? A is in violation. And
> even if GPL can't be enforced that way, by no means D is in violation
> when it's A that it's preventing D from complying.
The GPL says :
If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all.
The conditions of this licence are clear, the source code is the prefered form
of modification, so, if for "any other reason", you are not able to distribute
the source, then you "may not distribute the Program at all". The copyright
holder can, but there is no redistribution allowed. I will investigate about
if only A can sue over this though.
> The only way this can work the way you say is if A and D had a private
> agreement, and no proof can be made by D this agreement ever existed.
Well, there is no agreement whatsoever about this, and we don't know the
interpretation of A.
> But A released the software in public, and GPL'ed it. If A wants to keep
> part of the source obscured, he had better to stay well away from any
> court.
he could claim, as some did here, that obviously the fimrware was not GPLed,
but mere aggregation, and that he nowhere gave any right to distribute them.
> >>That, in court? Is this really what you're afraid of?
> >>The outcome is, very likely A will be forced to release the full source.
> >>(and D forced to distribute it, but all D's we're talking of here are
> >>very happy with the full disclosure scenario, aren't they?)
> >
> >Imagine A refusing to give away the source code, and D is ordered to remove
> >the incriminated code it is illegally distributing from all its servers,
> >and
> >recall all those thousands of CD and DVD isos containing the code it
> >distributed, and being fined for each day it doesn't do so ?
>
> Sorry, this is nonsense. D is well willing to distribute the source.
> In this case, he _is_ distributing what A publicly stated to be the source.
Yep, apart from the fact that A never did publicly state such issue, but just
passed it under silence.
> That's all. You say what if A changed his mind about what the source is?
> Well since it's still GPL'ed (we agree A can't chance the licence on the
> fly, right?) A is to provide the new, complete version of the source.
> Then, if and only if D refuses to distribute _that_ source, D is in
> violation. GPL requires D to distribute source _as received by A_.
> If A refuses to give the source, the specific requirement is not
> enforceable.
No, the GPL itself voids the distribubtion and redistribution rights if the
specific requirement is not fullfilled. This doesn't make the requirement not
enforceable, but voids the whole GPL licence and makes the work not
distributable.
> >>>This is the scenario i want to avoid by explicitly stating the
> >>>relationships
> >>>of all copyright issues of those firmware blobs.
> >>
> >>I don't see this scenario nowhere close to likely. Of course, A can
> >>always sue any B, C, or D for whatever reason. It's very unlikely
> >>A will sue anyone in full compliance of GPL, but it's possible.
> >>There's nothing we can do about it. But there's no reason to worry
> >>either.
> >
> >So, we don't take the risk and don't distribute it. If A is not ready to
> >put a
> >couple of lines of disclaimer on his work explaining the copyright and
> >licencing issues, then we are better of not distributing its code, which is
> >what debian will do.
>
> There no such a risk. A already placed a copyright notice on his work.
> Is it the wrong one? Who cares? I'd even say that once he released it
> under GPL, he can't take it back.
But the GPL states that we must be able to distribute the sources, clearly
defines what said sources are, and states what happens if you can't fullfill
a clause of the GPL -> no right to distribute at all.
> >
> >I am not sure. If i where to get a copy of windows, and manage to install
> >it
> >without clicking on the "i agree" button, does that make it a legal copy of
> >windows to use ?
>
> Come on, please, do not mix things up. I've said GPL'ed software. Last time
> I checked, Windows was not GPL'ed (yet). :-)
What has the GPL to do with it ?
Friendly,
Sven Luther
David Schwartz wrote:
> This would, of course, only make sense if you *had* to agree to the
> license to *create* the derivative work. If you were able to create
> the derivative work under first sale or fair use rights, then the
> restrictions in the contract would not apply to you.
The only way to *create* a derivative work is with permission of the
copyright owner of the original work. Period. This permission can come
implicitly *if* you agree with licensing terms, but not under first sale
or fair use *limitations*. (First sale / fair use are statutory
limitations on copyrights, not rights).
Massa
On Tue, 12 Apr 2005, Sven Luther wrote:
> On Tue, Apr 12, 2005 at 02:40:48AM +0200, Marco Colombo wrote:
>> Which reminds me. The only reason why this thread belongs here, IMHO,
>> it's because when it comes to GPL, it really doesn't matter what
>> FSF's interpretation is, or anyone else's. The authors are choosing
>> GPL as a license, so _thier_ interpretation is what really matters.
>
> The main problem is that i feel that those binary firmware copyright holders
> may have put it under the GPL, but i doubt they realize that this means they
> have to release the source code of said firmware blobs.
They released it not in object format, but in the C language. An
hexstring, agreed, but still C. The copyright holders can release
their work how they please. If you think GPL can place restrictions on
what they can do, please see below.
> Also, i believe you are wrong in the above, the only interpretation that is
> important is the one the judge will take in case someone goes to suing.
Agreed, let me rephrase then. The only interpretation that is
important _to the judge_ is the one of the parties involved.
In any agreement, the parties express their will. Here, the holders
"wrote" the agreement alone, so _their_ interpretation counts.
That is, their interpretation as it was when they licenced the software.
Not as is it after later thinking (or acquisition by some bad guy).
> And finally, if anyone could claim that a binary is the prefered form of
> modification, which is most of the time obviously false, then the GPL would be
> worthless. And anyway, the GPL states this (first paragraph after subclause c
> in clause 3) :
I don't care about GPL being worthless. This is not the GPL advocacy
list. I'm just saying that if you distribute the source in the form
the author published it, you can't be sued by him for breaking GPL.
That's what any linux distro and its mirrors are doing.
> The source code for a work means the preferred form of the work for
> making modifications to it. For an executable work, complete source
> code means all the source code for all modules it contains, plus any
> associated interface definition files, plus the scripts used to
> control compilation and installation of the executable.
>
> So, this is not some interpretation of the GPL by the FSF, and since it is
> written black on white in the actual GPL text, i don't think there is any
> doubt what a judge will decice :
>
> judge : so, to create this piece of work, what do you use to make
> modifications ?
> A (having sworn on the bible to say the truth and only the truth) : euh,
> some C or asm code, and a compiler or assembler to compile it.
> judge : and you did voluntarily place said code and distribute it under the
> GPL ?
> A : yes, it was going into the linux kernel, so ...
> judge : so you should distribute the source code to your work also, and
> distributing it under GPL is a breach of expectation from whoever you
> distribute it to.
>
> Or something such.
Again, I'm not following. The author release the source under GPL.
You can't release a binary under GPL, it makes no sense. So there's
no "so you should distribute the source code to your work _also_".
You released a software, it the form you claimed to be the source.
You like LISP, you release it in LISP. You like C, you release it
in C. You like hexcode, you release it in hexcode. No one can ask
you to change it.
You seems to keep forgetting what GPL is. It's a licence. The
copyright holders grant some rights to third parties, _if_ they
comply to some conditions. Conditions are all placed on the third
parties, including the source disclosure one (source of _modifications_).
There is no condition the _holders_ have to meet. It'd be a nonsense.
The GPL says: "I grant you a right if you do this." and not:
"I grant you a right if _I_ do this.". GPL doesn't backfire.
Again, IANAL, but I see little room for "interpretation" here.
> If A is going to say that he is the only author, and that he would never sue
> because of this breach of the GPL, he could just as well have put it under a
> different licence, or put a small disclaimer about it, since we cannot really
> act as if we believed that A would never sue us, if he doesn't explicitly say
> so.
No one will ever do that. If you are distributing the software I released
under GPL, be sure I _will_ sue you if you break the licence. What do you
want from me? A promise I won't sue you if you don't? That is implicit
in the existance of the licence.
Are you implying debian will stop distributing _any_ software unless
the all the copyright holders of GPL software "explicitly say" they
won't sue you?
> As an example, i package the unicorn driver for the bewan soft-ADSL pci and
> usb modems. These being soft-ADSL modems which use a non-free binary-only ADSL
> emulating library, but are otherwise GPL, i discussed the matter with
> upstream, and after council from debian-legal, and possibly the FSF people
> themselves, we got to use this as GPL exception :
>
> In addition, as a special exception, BeWAN systems gives permission
> to link the code of this program with the modem SW library
> (modem_ant_PCI.o, modem_ant_USB.o), and distribute linked combinations
> including the two. You are also given permission to redistribute the
> modem SW library (modem_ant_PCI.o, modem_ant_USB.o) with the rest of the
> code.
> You must obey the GNU General Public License in all respects for all of
> the code used other than the modem SW library.
This is different. They are not giving the source at all. The licence
for those object files _has_ to be different. _They_ want it to be
different.
> So, really, i doubt any manufacturer distributing non-free firmware would
> really have trouble in adding to their licence something like this :
>
> In addition, <manufacturer>, considers the firmware blob, identified as <...>, as
> a non-derivative piece of work, and thus not covered by the GPL of the rest
> of it. <manufacturer> gives permission to distribute said firmware blob as
> part of the linux kernel module driver for their hardware. The actual syntax
> of the inclusion of the code is still covered by the GPL, as is the rest of
> the driver code.
This is fine with me. It is the existance of legal threats versus
debian I don't agree upon.
> If we where to get something as nicely pu as this, provide a patch, asking
> the manufacturer to sign it of, then all issues would be void, i believe.
I think they are void even now.
[...]
>> Yes, but it does not apply to our case here. There's no "all other
>> copyright holders". _You_ stated that the firmware is included by mere
>> aggregation, so there's no other holders involved. We're talking
>> about the firmware case. A is one or two well identified subjects.
>> And A wrote it is GPL'ed. Whether you agree or not, that's the licence
>> A chose. A placed the copyright notice.
>
> This is where i would need legal counsel, as to whether this means C or
> someone else may stop you from distributing unless you provide the source. And
> the real problem is that A didn't state anything, so we are only working on
> the assumption that this may be the case, and A can change its mind later, and
> the costs to defend ourselves in front of a judge, even if your
> interpretations are right, are enough prohibitive for debian not to distribute
> said files.
A did put a GPL notice on it. He can't change his mind later.
>> The licence is a matter between A and D. A may sue D and D may (less
>> likely) sue A, if conditions are not met. I'm not sure at all GPL
>> is enforceable by D upon A. Let's assume it is, for sake of discussion,
>> anyway.
>
> Ah, but the licence is transitive, and if D may sue A, then C may also sue D,
> since the GPL makes no distinction between who makes the distribution, apart
> from the fact that A may relicence its code. But if he distributes it as part
> of the GPL ...
Pardon me, I have no idea of what a "transitive" licence could be.
Sublicencing or relicencing is _explicitly_ not covered by GPL anyway.
Also I have no idea of what you mean "GPL makes no distinction between
who makes the distribution". GPL for sure places no restrictions on
how A can distribute his software. A needs no license for exercising
rights on the software. He is the _owner_ of rights. A cannot "break"
the GPL. A needs no GPL to distribute. Are you saying A may sue himself?
>>> No. The source code is clearly the prefered form of modification, not some
>>> random intermediate state A may be claiming is source.
>>
>> In this context, it is. Only A may sue D for not distributing the source.
>> Whatever D distributes, D has to make A happy. If A is happy with D
>> distributing `dd if=/dev/random count=1` as source, no one can stop D
>> from doing that. Keep in mind A is the copyright holder. He grants
>> rights to third parties. No one but A can remove them.
>
> Yep, so if A was giving us an explicit right to distribute his sources,
> everyone would be happy, this not being the case, we have to take the
> hypothesis that A will sue us at a later time.
A placed it under GPL. If that is not "explicit right to distribute his
source", I'm not able to think of anything that could be it.
>> [...]
>>>> I'm not following. Are you saying what if A is bought? That is
>>>> different. Well GPL is quite clear:
>>>>
>>>> 1. You may copy and distribute verbatim copies of the Program's source
>>>> code as you receive it, ...
>>>>
>>>> If D is distributing the source as received from A, D is in full
>>>> compliance. How could A sue D? If A distributed incomplete source
>>>> in the first place, it's not D's fault for sure. Do you really think
>>>> the following scenario is likely:
>>>>
>>>> A to D: you must distribute the complete source, or the license will be
>>>> terminated!
>>>> D to A: gimme the complete source, and I'll distribute it.
>>>> A to D: no, I'm not willing to give you the full source of my firmware,
>>>> but you must distribute it anyway!
>>>
>>> The result is that the code in question has to be stopped from being
>>> distributed by D. But the case here is different, since A is not the sole
>>> copyright owner, so he doesn't get to set random interpretations of what is
>>> source code.
>>
>> Definitely I'm not following. How can D be ordered to stop distributing
>> the software if A refuses to give the source? A is in violation. And
>> even if GPL can't be enforced that way, by no means D is in violation
>> when it's A that it's preventing D from complying.
>
> The GPL says :
>
> If, as a consequence of a court judgment or allegation of patent
> infringement or for any other reason (not limited to patent issues),
> conditions are imposed on you (whether by court order, agreement or
> otherwise) that contradict the conditions of this License, they do not
> excuse you from the conditions of this License. If you cannot
> distribute so as to satisfy simultaneously your obligations under this
> License and any other pertinent obligations, then as a consequence you
> may not distribute the Program at all.
>
> The conditions of this licence are clear, the source code is the prefered form
> of modification, so, if for "any other reason", you are not able to distribute
> the source, then you "may not distribute the Program at all". The copyright
> holder can, but there is no redistribution allowed. I will investigate about
> if only A can sue over this though.
So you seriously think this makes sense?
A: you have to distribute the source, or the licence will be void
D: i am, i'm distributing the source you gave me
A: that is not the source, i was lying about it
D: then give me the right source, and I'll distribute it
A: No. I refuse to give you the right source, but expect you to distribute
it anyway, or i'll terminate the licence.
You seriouly think some judge may rule in favor of A? _If_ A sued D?
Well if you do, we can stop here. You'll never buy me on this.
>> The only way this can work the way you say is if A and D had a private
>> agreement, and no proof can be made by D this agreement ever existed.
>
> Well, there is no agreement whatsoever about this, and we don't know the
> interpretation of A.
>
>> But A released the software in public, and GPL'ed it. If A wants to keep
>> part of the source obscured, he had better to stay well away from any
>> court.
>
> he could claim, as some did here, that obviously the fimrware was not GPLed,
> but mere aggregation, and that he nowhere gave any right to distribute them.
"mere aggregation" refers to an action taken by a distributor. _You_
as debian are distributing the firmware as merely aggregated to the
kernel, assuming your intrepretation is right. That has nothing to do
with .c files.
Moreover, the firmare in not in binary form, but is part of a C source
file.
I think you're going no where. A cannot put a licence statement on
the top of a .c file stating it's GPL'ed, and then say that some part
of it is not covered because it was "merely aggregated". It makes no
sense, and there's nothing in the GPL about mere aggregation of sources.
>>>> That, in court? Is this really what you're afraid of?
>>>> The outcome is, very likely A will be forced to release the full source.
>>>> (and D forced to distribute it, but all D's we're talking of here are
>>>> very happy with the full disclosure scenario, aren't they?)
>>>
>>> Imagine A refusing to give away the source code, and D is ordered to remove
>>> the incriminated code it is illegally distributing from all its servers,
>>> and
>>> recall all those thousands of CD and DVD isos containing the code it
>>> distributed, and being fined for each day it doesn't do so ?
>>
>> Sorry, this is nonsense. D is well willing to distribute the source.
>> In this case, he _is_ distributing what A publicly stated to be the source.
>
> Yep, apart from the fact that A never did publicly state such issue, but just
> passed it under silence.
On the top of a .c file there's a nice copyright notice and licence statement,
isn't there? A placed it there. _You_ think it may be changed. But what
if A is fine with it?
>> That's all. You say what if A changed his mind about what the source is?
>> Well since it's still GPL'ed (we agree A can't chance the licence on the
>> fly, right?) A is to provide the new, complete version of the source.
>> Then, if and only if D refuses to distribute _that_ source, D is in
>> violation. GPL requires D to distribute source _as received by A_.
>> If A refuses to give the source, the specific requirement is not
>> enforceable.
>
> No, the GPL itself voids the distribubtion and redistribution rights if the
> specific requirement is not fullfilled. This doesn't make the requirement not
> enforceable, but voids the whole GPL licence and makes the work not
> distributable.
It makes D not suable. You can't actively prevent someone from doing
something he's supposed to do and the sue him for not doing it at the
same time.
> But the GPL states that we must be able to distribute the sources, clearly
> defines what said sources are, and states what happens if you can't fullfill
> a clause of the GPL -> no right to distribute at all.
No. GPL says you must be _willing_ to distribute the sources, as received
by A. See, GPL covers the source. There's no way you can distribute
the software in binary/executable form, unless you get the source and
complile it. That's what you do here. You compile the hexstring, and
the firmware (in binary form) gets "aggregated" to the kernel binary.
If you distribute the result, you have to distribute the source _as
you received it_. That's all. If you do, you're fine.
>>> I am not sure. If i where to get a copy of windows, and manage to install
>>> it
>>> without clicking on the "i agree" button, does that make it a legal copy of
>>> windows to use ?
>>
>> Come on, please, do not mix things up. I've said GPL'ed software. Last time
>> I checked, Windows was not GPL'ed (yet). :-)
>
> What has the GPL to do with it ?
Nothing. You introduced Windows, not me. My point was that you can
break into Fort Knox, steal a Debian CD, and give it to a friend.
His licence is valid. Your acting may be a crime. GPL says nothing
about how you got your copy. So even if the distributor is breaking
GPL, people who obtained a copy from there are fine.
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ [email protected]
David Schwartz wrote:
>>David Schwartz <[email protected]> wrote: If you buy a
>>W*nd*ws install CD, you can create a derived work, e.g. an
>>image of your installation, under the fair use rights
>>(IANAL). Can you distribute that image freely?
>>
>
> I would say that if not for the EULA, you could
>transfer ownership of the image to someone else. And if you
>legally acquired two copies of Windows, you could install
>both of them and transfer them. Otherwise, you could not sell
>a machine with the Windows OS installed unless you were a
>Microsoft OEM. Does Microsoft take the position that if you
>want to sell your PC, you must wipe the OS? Not that I know
>of.
>
> DS
If you will keep your copy and registration # of windows, yes,
you *must* wipe out the machine before selling it.
The point is moot, anyway, because the image is *not* a
derivative work: It is a copy of the work, made by automated
and automatable processes. It's not a creation of the spirit.
So, no, when you get a WinXP CD from Microsoft, you have
absolutely *no* rights to create derivative works. If a person
creates a derivative work, even if it does not distribute it,
it would be infringing on MS's copyrights and I would not want
to be in said person's shoes, if someone in the legal
department of MS wakes up in the wrong side of the bed.
HTH,
Massa
On Tue, Apr 12, 2005 at 12:01:15PM -0700, David Schwartz wrote:
> Would you agree that compiling and linking a program that uses
> a library creates a derivative work of that library?
No, I would not.
Creating a derivative work requires creativity, and a linker is not
creative.
The copyright issues for the linked program are the copyright issues
for the unlinked program.
Of course, you might have evidence in the form of a linked program where
you don't have evidence in the form of an unlinked program. But that's
a practical issue, not a copyright issue.
> And doesn't first sale give you the right to normal use of a work you
> have legally acquired?
The first sale doctrine (basically, 17 USC 109) doesn't really say that.
> There are many ways you can lawfully create a derivative work without
> explicit permission of the copyright holder. One clear case is when you
> lawfully possess the work, there is no EULA or shrink-wrap agreement, and
> you need to produce a derivative work to use the work in the ordinary
> fashion.
I don't think the words you're using mean what you think they mean.
I'm just going to quote part of 17 USC 106 at you.
"... the owner of copyright ... has the exclusive rights to ...
prepare derivative works ...".
Go look it up yourself if you think the text I've omitted makes it mean
something different.
--
Raul
On Tue, Apr 12, 2005 at 12:05:59PM -0700, David Schwartz wrote:
> Yes, the GPL can give you rights you wouldn't otherwise have. A
> EULA can take away rights you would otherwise have.
What compels you to agree with an EULA?
> In the few court cases that have directly addresses shrink-wrap and
> click-wrap type agreements, I've seen them consistently upheld. However,
> this is not relevent to the GPL issue at all because the GPL can only give
> you rights you wouldn't otherwise have, it cannot take away any rights.
The GPL offers you certain rights if you agree to be bound by certain
conditions.
You are not compelled to agree to those conditions, but those who do
not gain no rights from the GPL.
--
Raul
> David Schwartz wrote:
>
> > This would, of course, only make sense if you *had* to agree to the
> > license to *create* the derivative work. If you were able to create
> > the derivative work under first sale or fair use rights, then the
> > restrictions in the contract would not apply to you.
> The only way to *create* a derivative work is with permission of the
> copyright owner of the original work. Period. This permission can come
> implicitly *if* you agree with licensing terms, but not under first sale
> or fair use *limitations*. (First sale / fair use are statutory
> limitations on copyrights, not rights).
Would you agree that compiling and linking a program that uses a library
creates a derivative work of that library? Wouldn't you agree that this is
the normal form of use of a library? And doesn't first sale give you the
right to normal use of a work you have legally acquired?
There are many ways you can lawfully create a derivative work without
explicit permission of the copyright holder. One clear case is when you
lawfully possess the work, there is no EULA or shrink-wrap agreement, and
you need to produce a derivative work to use the work in the ordinary
fashion.
This is, by the way, the FSF's own position. It's not something I'm making
up or guessing at.
"The license does not require anyone to accept it in order to acquire,
install, use, inspect, or even experimentally modify GPL'd software. All of
those activities are either forbidden or controlled by proprietary software
firms, so they require you to accept a license, including contractual
provisions outside the reach of copyright, before you can use their works.
The free software movement thinks all those activities are rights, which all
users ought to have; we don't even want to cover those activities by
license."
Now we draw different conclusions based on this, but we agree on this. You
do not need to agree to the GPL to create derivative works.
> If you will keep your copy and registration # of windows, yes,
> you *must* wipe out the machine before selling it.
Since there is no copy or registration number of a GPL'd work to keep, this
actually argues the reverse of what I said. If I legally acquire ten copies
of Windows, I can perform normal use on those ten copies and then transfer
those copies to someone else.
> The point is moot, anyway, because the image is *not* a
> derivative work: It is a copy of the work, made by automated
> and automatable processes. It's not a creation of the spirit.
I don't think this makes a difference. If it's a derivative work, it's one
created in the course of ordinary use. In any event, first sale would be the
same either way.
> So, no, when you get a WinXP CD from Microsoft, you have
> absolutely *no* rights to create derivative works. If a person
> creates a derivative work, even if it does not distribute it,
> it would be infringing on MS's copyrights and I would not want
> to be in said person's shoes, if someone in the legal
> department of MS wakes up in the wrong side of the bed.
But you do have the right to create derivative works if such derivative
works are necessarily created in the process of the ordinary use of the
work. I think that if I write software that runs under Windows, an argument
can be made that that software is a derivative work of Windows. That
argument is as strong as the argument that a driver with linked in firmware
is a single work.
DS
On Tue, Apr 12, 2005 at 06:14:17PM +0200, Marco Colombo wrote:
> No one will ever do that. If you are distributing the software I released
> under GPL, be sure I _will_ sue you if you break the licence. What do you
> want from me? A promise I won't sue you if you don't? That is implicit
> in the existance of the licence.
>
> Are you implying debian will stop distributing _any_ software unless
> the all the copyright holders of GPL software "explicitly say" they
> won't sue you?
Well, we won't distribute binaries placed under the GPL, definitively not. And
if there is a dubious case, we ask for clarification of the author.
> >As an example, i package the unicorn driver for the bewan soft-ADSL pci and
> >usb modems. These being soft-ADSL modems which use a non-free binary-only
> >ADSL
> >emulating library, but are otherwise GPL, i discussed the matter with
> >upstream, and after council from debian-legal, and possibly the FSF people
> >themselves, we got to use this as GPL exception :
> >
> > In addition, as a special exception, BeWAN systems gives permission
> > to link the code of this program with the modem SW library
> > (modem_ant_PCI.o, modem_ant_USB.o), and distribute linked combinations
> > including the two. You are also given permission to redistribute the
> > modem SW library (modem_ant_PCI.o, modem_ant_USB.o) with the rest of the
> > code.
> > You must obey the GNU General Public License in all respects for all of
> > the code used other than the modem SW library.
>
> This is different. They are not giving the source at all. The licence
> for those object files _has_ to be different. _They_ want it to be
> different.
Sure, but in this case, the binary firmware blob is also a binary without
sources. If they really did write said firmware directly as it is, then they
should say so, but this is contrary to everyone's expectation, and a dangerous
precedent to set.
> >So, really, i doubt any manufacturer distributing non-free firmware would
> >really have trouble in adding to their licence something like this :
> >
> > In addition, <manufacturer>, considers the firmware blob, identified as
> > <...>, as
> > a non-derivative piece of work, and thus not covered by the GPL of the
> > rest
> > of it. <manufacturer> gives permission to distribute said firmware blob as
> > part of the linux kernel module driver for their hardware. The actual
> > syntax
> > of the inclusion of the code is still covered by the GPL, as is the rest
> > of
> > the driver code.
>
> This is fine with me. It is the existance of legal threats versus
> debian I don't agree upon.
Notice that debian can't afford to be sued even if they are right, so ...
> >>Yes, but it does not apply to our case here. There's no "all other
> >>copyright holders". _You_ stated that the firmware is included by mere
> >>aggregation, so there's no other holders involved. We're talking
> >>about the firmware case. A is one or two well identified subjects.
> >>And A wrote it is GPL'ed. Whether you agree or not, that's the licence
> >>A chose. A placed the copyright notice.
> >
> >This is where i would need legal counsel, as to whether this means C or
> >someone else may stop you from distributing unless you provide the source.
> >And
> >the real problem is that A didn't state anything, so we are only working on
> >the assumption that this may be the case, and A can change its mind later,
> >and
> >the costs to defend ourselves in front of a judge, even if your
> >interpretations are right, are enough prohibitive for debian not to
> >distribute
> >said files.
>
> A did put a GPL notice on it. He can't change his mind later.
Then he should give us the source.
> >>The licence is a matter between A and D. A may sue D and D may (less
> >>likely) sue A, if conditions are not met. I'm not sure at all GPL
> >>is enforceable by D upon A. Let's assume it is, for sake of discussion,
> >>anyway.
> >
> >Ah, but the licence is transitive, and if D may sue A, then C may also sue
> >D,
> >since the GPL makes no distinction between who makes the distribution,
> >apart
> >from the fact that A may relicence its code. But if he distributes it as
> >part
> >of the GPL ...
>
> Pardon me, I have no idea of what a "transitive" licence could be.
> Sublicencing or relicencing is _explicitly_ not covered by GPL anyway.
You give away the source to someone, he has the same rights you had, except
relicencing, this is what i meant by transitive.
> Also I have no idea of what you mean "GPL makes no distinction between
> who makes the distribution". GPL for sure places no restrictions on
> how A can distribute his software. A needs no license for exercising
No, it gives A the choice to distribute its software under the GPL, or under
another licence.
> rights on the software. He is the _owner_ of rights. A cannot "break"
> the GPL. A needs no GPL to distribute. Are you saying A may sue himself?
Yes, he can break the commonly accepted expectation of a GPLed software, which
is what happens here. He is free to distribute the software under any other
licence he sees fit, which is what i am asking here.
> >>>No. The source code is clearly the prefered form of modification, not
> >>>some
> >>>random intermediate state A may be claiming is source.
> >>
> >>In this context, it is. Only A may sue D for not distributing the source.
> >>Whatever D distributes, D has to make A happy. If A is happy with D
> >>distributing `dd if=/dev/random count=1` as source, no one can stop D
> >>from doing that. Keep in mind A is the copyright holder. He grants
> >>rights to third parties. No one but A can remove them.
> >
> >Yep, so if A was giving us an explicit right to distribute his sources,
> >everyone would be happy, this not being the case, we have to take the
> >hypothesis that A will sue us at a later time.
>
> A placed it under GPL. If that is not "explicit right to distribute his
> source", I'm not able to think of anything that could be it.
He is not distributing sources here, he is distributing binaries, my error.
> >The GPL says :
> >
> > If, as a consequence of a court judgment or allegation of patent
> > infringement or for any other reason (not limited to patent issues),
> > conditions are imposed on you (whether by court order, agreement or
> > otherwise) that contradict the conditions of this License, they do not
> > excuse you from the conditions of this License. If you cannot
> > distribute so as to satisfy simultaneously your obligations under this
> > License and any other pertinent obligations, then as a consequence you
> > may not distribute the Program at all.
> >
> >The conditions of this licence are clear, the source code is the prefered
> >form
> >of modification, so, if for "any other reason", you are not able to
> >distribute
> >the source, then you "may not distribute the Program at all". The copyright
> >holder can, but there is no redistribution allowed. I will investigate
> >about
> >if only A can sue over this though.
>
> So you seriously think this makes sense?
>
> A: you have to distribute the source, or the licence will be void
> D: i am, i'm distributing the source you gave me
> A: that is not the source, i was lying about it
> D: then give me the right source, and I'll distribute it
> A: No. I refuse to give you the right source, but expect you to distribute
> it anyway, or i'll terminate the licence.
No, the licence auto-terminate and the software becomes undistributable.
> >he could claim, as some did here, that obviously the fimrware was not
> >GPLed,
> >but mere aggregation, and that he nowhere gave any right to distribute
> >them.
>
> "mere aggregation" refers to an action taken by a distributor. _You_
> as debian are distributing the firmware as merely aggregated to the
> kernel, assuming your intrepretation is right. That has nothing to do
> with .c files.
The fact remains that those firmware blob have no licence, and thus defacto
fall under the GPL.
> Moreover, the firmare in not in binary form, but is part of a C source
> file.
It is in binary form. Disguised binary form maybe but still binary form.
> I think you're going no where. A cannot put a licence statement on
> the top of a .c file stating it's GPL'ed, and then say that some part
> of it is not covered because it was "merely aggregated". It makes no
> sense, and there's nothing in the GPL about mere aggregation of sources.
What i want is that A aknolwedges that he is not distributing the sources of
the firmware, and thus cannot place the binary blob under the GPL but should
chose another licence.
> >>>>That, in court? Is this really what you're afraid of?
> >>>>The outcome is, very likely A will be forced to release the full source.
> >>>>(and D forced to distribute it, but all D's we're talking of here are
> >>>>very happy with the full disclosure scenario, aren't they?)
> >>>
> >>>Imagine A refusing to give away the source code, and D is ordered to
> >>>remove
> >>>the incriminated code it is illegally distributing from all its servers,
> >>>and
> >>>recall all those thousands of CD and DVD isos containing the code it
> >>>distributed, and being fined for each day it doesn't do so ?
> >>
> >>Sorry, this is nonsense. D is well willing to distribute the source.
> >>In this case, he _is_ distributing what A publicly stated to be the
> >>source.
> >
> >Yep, apart from the fact that A never did publicly state such issue, but
> >just
> >passed it under silence.
>
> On the top of a .c file there's a nice copyright notice and licence
> statement,
> isn't there? A placed it there. _You_ think it may be changed. But what
> if A is fine with it?
Not in the tg3.c case, no.
> >But the GPL states that we must be able to distribute the sources, clearly
> >defines what said sources are, and states what happens if you can't
> >fullfill
> >a clause of the GPL -> no right to distribute at all.
>
> No. GPL says you must be _willing_ to distribute the sources, as received
> by A. See, GPL covers the source. There's no way you can distribute
> the software in binary/executable form, unless you get the source and
> complile it. That's what you do here. You compile the hexstring, and
> the firmware (in binary form) gets "aggregated" to the kernel binary.
> If you distribute the result, you have to distribute the source _as
> you received it_. That's all. If you do, you're fine.
And where did those hexstrings come from ?
Friendly,
Sven Luther
David Schwartz wrote:
>>David Schwartz wrote:
>>
>>> This would, of course, only make sense if you *had* to
>>> agree to the license to *create* the derivative work. If
>>> you were able to create the derivative work under first
>>> sale or fair use rights, then the restrictions in the
>>> contract would not apply to you.
>
>
>>The only way to *create* a derivative work is with
>>permission of the copyright owner of the original work.
>>Period. This permission can come implicitly *if* you agree
>>with licensing terms, but not under first sale or fair use
>>*limitations*. (First sale / fair use are statutory
>>limitations on copyrights, not rights).
>
>
>Would you agree that compiling and linking a program that
>uses a library creates a derivative work of that library?
No. Compiling and linking are mechanical,
non-intellectually-novel acts. At most, you have a collective
work where the real intellectually-novel work was to select
what goes into the collective.
>Wouldn't you agree that this is the normal form of use of a
>library? And doesn't first sale give you the right to normal
>use of a work you have legally acquired?
Yes. And yes, if you buy a copy of the library, yes (but
notice: not if you downloaded it for free from the Net).
>
>There are many ways you can lawfully create a derivative work
>without explicit permission of the copyright holder. One
No. The copyright law states that the copyright owner has the
monopolistic right to create derivative works.
>clear case is when you lawfully possess the work, there is no
>EULA or shrink-wrap agreement, and you need to produce a
>derivative work to use the work in the ordinary fashion.
No... Try writing a book with Harry Potter as your main
character and JKR's lawyers will be at your door soon.
>This is, by the way, the FSF's own position. It's not
>something I'm making up or guessing at.
Please send us some pointers to this statements for the FSF.
>"The license does not require anyone to accept it in order to
>acquire, install, use, inspect, or even experimentally modify
>GPL'd software. All of those activities are either forbidden
Wrong again. GPL, section 0, para 1: "Activities other than
copying, distribution, and *modification* are not covered by
this License". Emphasis mine.
>or controlled by proprietary software firms, so they require
>you to accept a license, including contractual provisions
>outside the reach of copyright, before you can use their
>works. The free software movement thinks all those
>activities are rights, which all users ought to have; we
>don't even want to cover those activities by license."
Except for the modification part, which *is* the scope of
regular, Berne-convention-molded copyrights law.
>Now we draw different conclusions based on this, but we agree
>on this. You do not need to agree to the GPL to create
>derivative works.
No, we disagree on this too.
>>If you will keep your copy and registration # of windows,
>>yes, you *must* wipe out the machine before selling it.
>
>
>Since there is no copy or registration number of a GPL'd work
>to keep, this actually argues the reverse of what I said. If
>I legally acquire ten copies of Windows, I can perform normal
>use on those ten copies and then transfer those copies to
>someone else.
This is not the point: you still would have to wipe your ten
computers clean if you want to sell the ten copies you have.
In the GPL'd case, if you disregard the terms of the license,
you can still keep, use, etc. You can *not* copy it,
distribute it, or modify it tough.
>>The point is moot, anyway, because the image is *not* a
>>derivative work: It is a copy of the work, made by automated
>>and automatable processes. It's not a creation of the
>>spirit.
>
>
>I don't think this makes a difference. If it's a derivative
>work, it's one created in the course of ordinary use. In any
>event, first sale would be the same either way.
The point is: it's *not* a derivative work. period. Yes, first
sale would apply to the same extent that it applies to the
original software.
>>So, no, when you get a WinXP CD from Microsoft, you have
>>absolutely *no* rights to create derivative works. If a
>>person creates a derivative work, even if it does not
>>distribute it, it would be infringing on MS's copyrights and
>>I would not want to be in said person's shoes, if someone in
>>the legal department of MS wakes up in the wrong side of the
>>bed.
>
>
>But you do have the right to create derivative works if such
>derivative works are necessarily created in the process of
>the ordinary use of the work.
Ok, let's repeat ourselves:
A derivative work is a novel intellectual creation (of the
spirit) that results from some transformation of another work,
said the "original" work.
There is a similar (identical?) definition on 17 USC, but I am
quoting (bad translation mine) our "Lei 9610/98 -- Lei de
Direitos Autorais" (1998 Brazilian Author's Rights Act), art.
5?, VIII, 'g'.
I can't think of any example where to use a work, you must
create another work transforming the first. If you can, please
enlighten me. Beware: your *spirit* must transform the work,
not your computer. Yes, as when *you* translate a book to
another language, in an non-automatable-non-automated process.
>I think that if I write software that runs under Windows, an
>argument can be made that that software is a derivative work
>of Windows. That
No, no, no, and no. A derivative work is not something that is
"argumentable" :-). There is a clear legal definition, and
there are even tools (the Holy Trinity of Derivation:
Abstraction, Filtration, Comparison) to help us define and
discover what is and what is not a derivative work. And no,
HelloWorld.c is not a derivative work of Windows, even if it
#include<windows.h>
please, google for:
abstraction filtration comparison derivative
-- it will be enlightening.
>argument is as strong as the argument that a driver with
>linked in firmware is a single work.
This would most certainly not prevail in any court at all.
Obviously, IANAL and TINLA applies. But, that said, I have
good credentials :-)
>
>DS
HTH,
Massa
On Tue, 2005-04-12 at 20:45 +0200, Sven Luther wrote:
[snip]
> > A did put a GPL notice on it. He can't change his mind later.
> Then he should give us the source.
[snip]
> The fact remains that those firmware blob have no licence, and thus defacto
> fall under the GPL.
>
> > Moreover, the firmare in not in binary form, but is part of a C source
> > file.
>
> It is in binary form. Disguised binary form maybe but still binary form.
[snip]
> And where did those hexstrings come from ?
It seems to me, that to be consistent with the argument you seem to be
presenting concerning binary data in GPLd code, that you also need to be
demanding the "source" hardware design for binary register values.
Why not consider the binary firmware in the same category as binary
register programming information? You poke these magic bytes into these
memory locations and it works.
Where do you draw the lines between "write this byte to set the input
gate here and the output gate to there" and "write this byte sequence to
send the input byte through this loop, into this buffer, add it to the
last byte entered, and output it over there"?
--
Zan Lynx <[email protected]>
On Tue, 2005-04-12 at 20:45 +0200, Sven Luther wrote:
> On Tue, Apr 12, 2005 at 06:14:17PM +0200, Marco Colombo wrote:
> > No one will ever do that. If you are distributing the software I released
> > under GPL, be sure I _will_ sue you if you break the licence. What do you
> > want from me? A promise I won't sue you if you don't? That is implicit
> > in the existance of the licence.
> >
> > Are you implying debian will stop distributing _any_ software unless
> > the all the copyright holders of GPL software "explicitly say" they
> > won't sue you?
>
> Well, we won't distribute binaries placed under the GPL, definitively not. And
> if there is a dubious case, we ask for clarification of the author.
Your choice, of course.
[...]
> > This is different. They are not giving the source at all. The licence
> > for those object files _has_ to be different. _They_ want it to be
> > different.
>
> Sure, but in this case, the binary firmware blob is also a binary without
> sources. If they really did write said firmware directly as it is, then they
> should say so, but this is contrary to everyone's expectation, and a dangerous
> precedent to set.
You should realize that any author can publish his work in the form he
likes. He's not bound to "everyone's expectation". I see no danger in
that.
> > >So, really, i doubt any manufacturer distributing non-free firmware would
> > >really have trouble in adding to their licence something like this :
> > >
> > > In addition, <manufacturer>, considers the firmware blob, identified as
> > > <...>, as
> > > a non-derivative piece of work, and thus not covered by the GPL of the
> > > rest
> > > of it. <manufacturer> gives permission to distribute said firmware blob as
> > > part of the linux kernel module driver for their hardware. The actual
> > > syntax
> > > of the inclusion of the code is still covered by the GPL, as is the rest
> > > of
> > > the driver code.
> >
> > This is fine with me. It is the existance of legal threats versus
> > debian I don't agree upon.
>
> Notice that debian can't afford to be sued even if they are right, so ...
So what? This is not the point. You can be sued any time by any one,
even if you're right. If debian can't afford it, it can't afford
existance.
> > >>Yes, but it does not apply to our case here. There's no "all other
> > >>copyright holders". _You_ stated that the firmware is included by mere
> > >>aggregation, so there's no other holders involved. We're talking
> > >>about the firmware case. A is one or two well identified subjects.
> > >>And A wrote it is GPL'ed. Whether you agree or not, that's the licence
> > >>A chose. A placed the copyright notice.
> > >
> > >This is where i would need legal counsel, as to whether this means C or
> > >someone else may stop you from distributing unless you provide the source.
> > >And
> > >the real problem is that A didn't state anything, so we are only working on
> > >the assumption that this may be the case, and A can change its mind later,
> > >and
> > >the costs to defend ourselves in front of a judge, even if your
> > >interpretations are right, are enough prohibitive for debian not to
> > >distribute
> > >said files.
> >
> > A did put a GPL notice on it. He can't change his mind later.
>
> Then he should give us the source.
No, why? GPL cannot place restrictions or obligations on the copyright
owner. Let's stop discussing it please, you can't buy me on this
either. I have my own interpretation of what a license it, and it seems
you don't agree with it: to me, it's one way: _you_, the licensee,
get some rights if you fulfill some conditions. Conditions are all
placed on you, none on the copyright holder. In particular, the
one about making source available is placed on distributors,
verbatim copies of the source for binary distribution of the work, or
full source of the modifications for modified versions of the work.
And anyway, this has nothing to do with with legal threats from the
copyright holder. My point being: he cannot sue you for not
distributing the source "as provided by him" if he failed to provide
them in the first place in a different from. That is, he has to give you
the source, if he is trying to force you distributing it.
> > >>The licence is a matter between A and D. A may sue D and D may (less
> > >>likely) sue A, if conditions are not met. I'm not sure at all GPL
> > >>is enforceable by D upon A. Let's assume it is, for sake of discussion,
> > >>anyway.
> > >
> > >Ah, but the licence is transitive, and if D may sue A, then C may also sue
> > >D,
> > >since the GPL makes no distinction between who makes the distribution,
> > >apart
> > >from the fact that A may relicence its code. But if he distributes it as
> > >part
> > >of the GPL ...
> >
> > Pardon me, I have no idea of what a "transitive" licence could be.
> > Sublicencing or relicencing is _explicitly_ not covered by GPL anyway.
>
> You give away the source to someone, he has the same rights you had, except
> relicencing, this is what i meant by transitive.
GPL explicitly says that when you, a distributor, give the source to
someone, he receives a license, another "instance" of GPL so to say,
directly from the copyright holder and not from you. If your license
is GPL, then his license is GPL, too, and yes, he has the same rights
of you. But it's not you granting those rights to him, it's the
copyright holder.
> > Also I have no idea of what you mean "GPL makes no distinction between
> > who makes the distribution". GPL for sure places no restrictions on
> > how A can distribute his software. A needs no license for exercising
>
> No, it gives A the choice to distribute its software under the GPL, or under
> another licence.
I think GPL "gives" nothing to A. A can do whatever he wants with his
software, GPL has no effect on A. It would be A granting rights to A.
Nonsense. A does not need to "release" the software under any license
to himself. A has full rights on it, already.
> > rights on the software. He is the _owner_ of rights. A cannot "break"
> > the GPL. A needs no GPL to distribute. Are you saying A may sue himself?
>
> Yes, he can break the commonly accepted expectation of a GPLed software, which
> is what happens here. He is free to distribute the software under any other
> licence he sees fit, which is what i am asking here.
I'm sorry. We totally disagree on this. GPL is a license. The commonly
accepted expectation is that it places restrictions on the licensee,
in exchange of some rights. The copyright holder is no licensee.
He needs to comply to no conditions. He already has (and owns) full
rights. And anyway, he is the only one entitled the right of enforcing
those conditions or voiding the license. How could he enforce any
conditions on himself? How could he void a license to himself, given
that he needs no license at all?
Let's drop this, please, we're going nowhere.
> > >>>No. The source code is clearly the prefered form of modification, not
> > >>>some
> > >>>random intermediate state A may be claiming is source.
> > >>
> > >>In this context, it is. Only A may sue D for not distributing the source.
> > >>Whatever D distributes, D has to make A happy. If A is happy with D
> > >>distributing `dd if=/dev/random count=1` as source, no one can stop D
> > >>from doing that. Keep in mind A is the copyright holder. He grants
> > >>rights to third parties. No one but A can remove them.
> > >
> > >Yep, so if A was giving us an explicit right to distribute his sources,
> > >everyone would be happy, this not being the case, we have to take the
> > >hypothesis that A will sue us at a later time.
> >
> > A placed it under GPL. If that is not "explicit right to distribute his
> > source", I'm not able to think of anything that could be it.
>
> He is not distributing sources here, he is distributing binaries, my error.
Well, no. You are distributing the binary, after you compiled the
kernel. The hexstring is the source, the binary aggregated to the
kernel image is the binary. The GPL notice is attached to the hexstring.
[...]
> > So you seriously think this makes sense?
> >
> > A: you have to distribute the source, or the licence will be void
> > D: i am, i'm distributing the source you gave me
> > A: that is not the source, i was lying about it
> > D: then give me the right source, and I'll distribute it
> > A: No. I refuse to give you the right source, but expect you to distribute
> > it anyway, or i'll terminate the licence.
>
> No, the licence auto-terminate and the software becomes undistributable.
Nothing "auto-terminates". A can ask the judge to order D to stop
distribution. If you seriously think that, in front of such claims by A,
any judge will rule of favor of A, well, there's no point in discussing.
D is not able to distribute the source "as provided" by A, if A is not
providing it. A cannot have such a condition enforced without providing
the source, in the first place.
The license terminates when A manages to convince the judge D is not
fulfilling a condition. I think no one would ever consider
"i don't want to give you the right source, but you must distribute it
anyway" a valid argument.
> > >he could claim, as some did here, that obviously the fimrware was not
> > >GPLed,
> > >but mere aggregation, and that he nowhere gave any right to distribute
> > >them.
> >
> > "mere aggregation" refers to an action taken by a distributor. _You_
> > as debian are distributing the firmware as merely aggregated to the
> > kernel, assuming your intrepretation is right. That has nothing to do
> > with .c files.
>
> The fact remains that those firmware blob have no licence, and thus defacto
> fall under the GPL.
Precisely.
> > Moreover, the firmare in not in binary form, but is part of a C source
> > file.
>
> It is in binary form. Disguised binary form maybe but still binary form.
Ah, but this is a claim A has to make in front of a judge, before the
license of D can be terminated. "I gave him a source that is really
a disguised binary form, and not the real source. He's distributing
that 'source' as i provided it, but it's not the real one. I'm not
willing to give him the real one, but I'm requesting him to distribute
it.". Makes no sense. D: "I'm providing it as provided, which is the
requirement of GPL. Should I receive it in another form, I'd distribute
it in the new form."
> > I think you're going no where. A cannot put a licence statement on
> > the top of a .c file stating it's GPL'ed, and then say that some part
> > of it is not covered because it was "merely aggregated". It makes no
> > sense, and there's nothing in the GPL about mere aggregation of sources.
>
> What i want is that A aknolwedges that he is not distributing the sources of
> the firmware, and thus cannot place the binary blob under the GPL but should
> chose another licence.
That would be fine. But it's a matter of having thing sorted out
correctly.
> > >>>>That, in court? Is this really what you're afraid of?
> > >>>>The outcome is, very likely A will be forced to release the full source.
> > >>>>(and D forced to distribute it, but all D's we're talking of here are
> > >>>>very happy with the full disclosure scenario, aren't they?)
> > >>>
> > >>>Imagine A refusing to give away the source code, and D is ordered to
> > >>>remove
> > >>>the incriminated code it is illegally distributing from all its servers,
> > >>>and
> > >>>recall all those thousands of CD and DVD isos containing the code it
> > >>>distributed, and being fined for each day it doesn't do so ?
> > >>
> > >>Sorry, this is nonsense. D is well willing to distribute the source.
> > >>In this case, he _is_ distributing what A publicly stated to be the
> > >>source.
> > >
> > >Yep, apart from the fact that A never did publicly state such issue, but
> > >just
> > >passed it under silence.
> >
> > On the top of a .c file there's a nice copyright notice and licence
> > statement,
> > isn't there? A placed it there. _You_ think it may be changed. But what
> > if A is fine with it?
>
> Not in the tg3.c case, no.
Are you saying that the notice has been wrongly placed by the
holders or by someone else? If they changed their mind, there's
little they can do. If _someone else_ published the code and
put a wrong license notice on it, that's a different matter.
A _false_ notice is different from a _wrong_ legitimate one.
"Wrong" as in: they changed their mind at later time.
> > >But the GPL states that we must be able to distribute the sources, clearly
> > >defines what said sources are, and states what happens if you can't
> > >fullfill
> > >a clause of the GPL -> no right to distribute at all.
> >
> > No. GPL says you must be _willing_ to distribute the sources, as received
> > by A. See, GPL covers the source. There's no way you can distribute
> > the software in binary/executable form, unless you get the source and
> > complile it. That's what you do here. You compile the hexstring, and
> > the firmware (in binary form) gets "aggregated" to the kernel binary.
> > If you distribute the result, you have to distribute the source _as
> > you received it_. That's all. If you do, you're fine.
>
> And where did those hexstrings come from ?
There's only one subject that can put such a question: the copyright
holder, since it's the only one that can request enforcement of a
GPL condition. "You provided it" it's enough an answer. It's a dead
end, the copyright holder can't go any further w/o providing the
real source.
I think we reached a dead end ourself.
For the debian case, I think:
- no one can sue debian, but the copyright holder, for breaking GPL
in the act of distributing the firmware blob; debian received a GPL
from the copyright holder when they got the program
- there's no way the copyright holder could sue debian for not
distributing source (assuming debian is distributing the kernel
tarball of course, which is not a problem), w/o providing something
different they claim to be the "real" source.
As usual, IANAL.
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ [email protected]
On Wed, Apr 13, 2005 at 04:53:56PM +0200, Marco Colombo wrote:
> > > This is different. They are not giving the source at all. The licence
> > > for those object files _has_ to be different. _They_ want it to be
> > > different.
> >
> > Sure, but in this case, the binary firmware blob is also a binary without
> > sources. If they really did write said firmware directly as it is, then they
> > should say so, but this is contrary to everyone's expectation, and a dangerous
> > precedent to set.
>
> You should realize that any author can publish his work in the form he
> likes. He's not bound to "everyone's expectation". I see no danger in
> that.
I think there may be some limitation of using the GPL as licence in this case
though, as such behavior may limit its value, and the GPL itself is by no
means free software.
Friendly,
Sven Luther
> >Would you agree that compiling and linking a program that
> >uses a library creates a derivative work of that library?
> No. Compiling and linking are mechanical,
> non-intellectually-novel acts. At most, you have a collective
> work where the real intellectually-novel work was to select
> what goes into the collective.
Compiling and linking are mechanical, but unless you want to argue that the
result is not a single work, it clearly creates a derivative work of all the
things linked. The creativity is not in the linking itself but in the
creation of the individual works such that they can be linked together.
> >Wouldn't you agree that this is the normal form of use of a
> >library? And doesn't first sale give you the right to normal
> >use of a work you have legally acquired?
>
> Yes. And yes, if you buy a copy of the library, yes (but
> notice: not if you downloaded it for free from the Net).
There is no legal distinction. Your rights come not from the fact that you
paid money for the work but simply from the fact that you acquired it
legally. Again, the reductio ad absurdum is the guy who drops copies of his
poem from an airplane and then demands royalities from everyone who reads
it. If you legally acquired it, you get the bundle of rights under first
sale.
> >There are many ways you can lawfully create a derivative work
> >without explicit permission of the copyright holder. One
>
> No. The copyright law states that the copyright owner has the
> monopolistic right to create derivative works.
Yes, but this doesn't restrict first sale or fair use. You cannot use a
library without creating a derivative work, so if first sale grants you
rights to use, it automatically grants you the right to do anything
necessary for use.
> >clear case is when you lawfully possess the work, there is no
> >EULA or shrink-wrap agreement, and you need to produce a
> >derivative work to use the work in the ordinary fashion.
> No... Try writing a book with Harry Potter as your main
> character and JKR's lawyers will be at your door soon.
Sometimes I wonder if you are reading what I said or not. I said "you need
to produce a derivative work to use the work in the ordinary fashion" and
you say "No" and follow with an example where you clearly *don't* need to
produce a derivative work to use the work in the ordinary fashion.
> >This is, by the way, the FSF's own position. It's not
> >something I'm making up or guessing at.
>
> Please send us some pointers to this statements for the FSF.
Read any of Eben Moglen's posts.
> >"The license does not require anyone to accept it in order to
> >acquire, install, use, inspect, or even experimentally modify
> >GPL'd software. All of those activities are either forbidden
>
> Wrong again. GPL, section 0, para 1: "Activities other than
> copying, distribution, and *modification* are not covered by
> this License". Emphasis mine.
You are free to disagree with the FSF's interpretation of the GPL, but you
are not free to misrepresent the FSF's interpreration.
> >or controlled by proprietary software firms, so they require
> >you to accept a license, including contractual provisions
> >outside the reach of copyright, before you can use their
> >works. The free software movement thinks all those
> >activities are rights, which all users ought to have; we
> >don't even want to cover those activities by license."
>
> Except for the modification part, which *is* the scope of
> regular, Berne-convention-molded copyrights law.
Feel free to disagree with the FSF about the meaning of the GPL, but it is
the FSF's position that you can modify a GPL'd work without agreeing to the
GPL.
> >Now we draw different conclusions based on this, but we agree
> >on this. You do not need to agree to the GPL to create
> >derivative works.
>
> No, we disagree on this too.
I don't know who "we" is, but I agree with the FSF.
> >>If you will keep your copy and registration # of windows,
> >>yes, you *must* wipe out the machine before selling it.
> >
> >
> >Since there is no copy or registration number of a GPL'd work
> >to keep, this actually argues the reverse of what I said. If
> >I legally acquire ten copies of Windows, I can perform normal
> >use on those ten copies and then transfer those copies to
> >someone else.
> This is not the point: you still would have to wipe your ten
> computers clean if you want to sell the ten copies you have.
Right. You cannot increase the number of copies.
> In the GPL'd case, if you disregard the terms of the license,
> you can still keep, use, etc. You can *not* copy it,
> distribute it, or modify it tough.
You can, so long as you don't increase the number of copies. This is a
right under first sale.
> >>So, no, when you get a WinXP CD from Microsoft, you have
> >>absolutely *no* rights to create derivative works. If a
> >>person creates a derivative work, even if it does not
> >>distribute it, it would be infringing on MS's copyrights and
> >>I would not want to be in said person's shoes, if someone in
> >>the legal department of MS wakes up in the wrong side of the
> >>bed.
> >But you do have the right to create derivative works if such
> >derivative works are necessarily created in the process of
> >the ordinary use of the work.
> Ok, let's repeat ourselves:
> A derivative work is a novel intellectual creation (of the
> spirit) that results from some transformation of another work,
> said the "original" work.
>
> There is a similar (identical?) definition on 17 USC, but I am
> quoting (bad translation mine) our "Lei 9610/98 -- Lei de
> Direitos Autorais" (1998 Brazilian Author's Rights Act), art.
> 5?, VIII, 'g'.
>
> I can't think of any example where to use a work, you must
> create another work transforming the first. If you can, please
> enlighten me. Beware: your *spirit* must transform the work,
> not your computer. Yes, as when *you* translate a book to
> another language, in an non-automatable-non-automated process.
To use a library, you must write a program that uses that libraries and
includes its header files. You must compile the library and the program, and
link the result. You must then execute the result.
You can argue it one of two ways:
1) The result is a derivative work, hence creating a derivative work is
necessary for ordinary use. Thus permission to use means permission to
create (at least some) derivative works.
2) The result is not a derivative work, hence you don't need permission
from the copyright holder to do it.
Either way you get the same result, permission is not needed beyond
permission to use.
> >I think that if I write software that runs under Windows, an
> >argument can be made that that software is a derivative work
> >of Windows. That
> No, no, no, and no. A derivative work is not something that is
> "argumentable" :-). There is a clear legal definition, and
> there are even tools (the Holy Trinity of Derivation:
> Abstraction, Filtration, Comparison) to help us define and
> discover what is and what is not a derivative work. And no,
> HelloWorld.c is not a derivative work of Windows, even if it
> #include<windows.h>
>
> please, google for:
>
> abstraction filtration comparison derivative
>
> -- it will be enlightening.
Then all the people who think that creating a binary kernel module requires
creating a derivative work and hence can be restricted by the GPL are wrong.
Take that argument up with them.
> >argument is as strong as the argument that a driver with
> >linked in firmware is a single work.
>
> This would most certainly not prevail in any court at all.
> Obviously, IANAL and TINLA applies. But, that said, I have
> good credentials :-)
I think even if the result is not a derivative work, the rules for
distributing it would be the same. However, it would change the rules for
creating it. Either way, however, you get that you can do it without
agreeing to the GPL, and this is the FSF's position.
DS
> On Tue, Apr 12, 2005 at 12:05:59PM -0700, David Schwartz wrote:
> > Yes, the GPL can give you rights you wouldn't otherwise have. A
> > EULA can take away rights you would otherwise have.
> What compels you to agree with an EULA?
If you do not agree with the EULA, you cannot and do not acquire lawful
possession of the work.
> > In the few court cases that have directly addresses shrink-wrap and
> > click-wrap type agreements, I've seen them consistently upheld. However,
> > this is not relevent to the GPL issue at all because the GPL
> > can only give
> > you rights you wouldn't otherwise have, it cannot take away any rights.
> The GPL offers you certain rights if you agree to be bound by certain
> conditions.
Right, and normally the way you become bound by the GPL is if you do
something that you could not acquire the right to do any other way. That's
why GPL issues frequently hinge on whether you could not acquire the right
any other way. Possible other ways include first sale and fair use.
> You are not compelled to agree to those conditions, but those who do
> not gain no rights from the GPL.
Right, again, that's why it's important to look at whether they could have
acquired the rights any other way.
DS
> It seems to me, that to be consistent with the argument you seem to be
> presenting concerning binary data in GPLd code, that you also need to be
> demanding the "source" hardware design for binary register values.
>
> Why not consider the binary firmware in the same category as binary
> register programming information? You poke these magic bytes into these
> memory locations and it works.
>
> Where do you draw the lines between "write this byte to set the input
> gate here and the output gate to there" and "write this byte sequence to
> send the input byte through this loop, into this buffer, add it to the
> last byte entered, and output it over there"?
You draw the line at the source code, the preferred form of the work for
the purpose of making modifications to it. See GPL section 3. Firmware is an
executable work.
DS
This thread should probably get moved off-list soon, it's like
beating the dead horse long after its flesh has decayed and its
bones disintegrated to dust.
On Apr 13, 2005, at 21:54, David Schwartz wrote:
>> On Tue, Apr 12, 2005 at 12:05:59PM -0700, David Schwartz wrote:
>>> Yes, the GPL can give you rights you wouldn't otherwise have. A
>>> EULA can take away rights you would otherwise have.
>
>> What compels you to agree with an EULA?
>
> If you do not agree with the EULA, you cannot and do not acquire lawful
> possession of the work.
Of course, one could always assert the following:
1) I went to a store
2) I found a box
3) I went to the cash register
4) I gave money to the cashier for the box
5) I took the box home
6) I opened the box and took out the contents
Now, to the end user, the above is the same procedure for purchasing a
box of cereal or a piece of software, therefore the restrictions are the
same. I'm not allowed to distribute the copyrightable materials, which
for a cereal box is the images on the box, and for a CD is the digital
data stored therein. Other than that, I can take a hammer and smash my
CD/cereal, I can make a dozen copies of the CD/box-art and mount them
on the wall or burn them, both of which are symbolic speech. I can make
backup copies of my cereal box-art/CD too.
At what point of the above did I agree to any license? As far as I
know, a license (IE: contract) is not valid for a product unless made at
the point-of-sale, before exchanging money. This is especially valid
since almost all computer retailers refuse refunds for opened software.
When you have to open the box to see the license, that's bad, but when,
as I've seen far too many times, you have to break the seal and insert
the CD to even _see_ the license, it cannot be valid.
The only real point of most of the EULAs is to protect the owners
copyright, which is implicitly protected in any case.
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/U d- s++: a18 C++++>$ UB/L/X/*++++(+)>$ P+++(++++)>$
L++++(+++) E W++(+) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+
PGP+++ t+(+++) 5 X R? tv-(--) b++++(++) DI+ D+ G e->++++$ h!*()>++$ r
!y?(-)
------END GEEK CODE BLOCK------
> > What compels you to agree with an EULA?
On Wed, Apr 13, 2005 at 06:54:29PM -0700, David Schwartz wrote:
> If you do not agree with the EULA, you cannot and do not acquire
> lawful possession of the work.
What about cases where you pay for the software before you're allowed
to see the EULA?
--
Raul
David Schwartz wrote:
>> >Would you agree that compiling and linking a program that
>> >uses a library creates a derivative work of that library?
>
>
>>No. Compiling and linking are mechanical,
>>non-intellectually-novel acts. At most, you have a
>>collective work where the real intellectually-novel work was
>>to select what goes into the collective.
>
>
> Compiling and linking are mechanical, but unless you
>want to argue that the result is not a single work, it
>clearly creates a derivative work of all the things linked.
>The creativity is not in the linking itself but in the
>creation of the individual works such that they can be linked
>together.
That is the point: the result is not a single work. It is a
collection or compilation of works, just like an anthology. If
there is any creativity involved, is in choosing and ordering
the parts. The creation of works that "can be linked together"
is not protected by copyright: the literary analogy was to
"create a robot short story". Such a story could go into an
anthology called (duh) "Robot Short Stories", but its
licensing is independent of every other robot short story in
the world -- except those it is a derivative work of.
Now, this is what copyright protects: creation of derivative
works (see the definition, below) is an exclusive right of the
copyright owner. I can't write a history featuring Daneel
Olivaw or Susan Calving without the (written, express)
permission of Mrs. Asimov and/or her daughter. And if I *do*
have their consent (in the form of GPL'ing it, for instance),
even so I can only copy and distribute *my* work in the terms
permitted expressely by the consent I received (in the
example, the terms of the GPL)
>
>> >Wouldn't you agree that this is the normal form of use of
>> >a library? And doesn't first sale give you the right to
>> >normal use of a work you have legally acquired?
>>
>>Yes. And yes, if you buy a copy of the library, yes (but
>>notice: not if you downloaded it for free from the Net).
>
>
> There is no legal distinction.
Why do you think that? You can even be right on this, but your
argument below did not convince me.
>Your rights come not from the fact that you paid money for
>the work but simply from the fact that you acquired it
>legally. Again, the reductio ad absurdum is the guy who drops
>copies of his poem from an airplane and then demands
>royalities from everyone who reads it. If you legally
>acquired it, you get the bundle of rights under first sale.
You are spinning, you know? If I drop a poem from an airplane,
and you get it from the ground, you can read it (this is not
forbidden by copyright law) but you have *no* right of copying
it, publishing it or redistributing it. Especially if my poem
has my name or pseudonym on it.
Yeah, you can even get the bundle of rights under first sale
if you acquired it lawfully, and I must be wrong about my
quoted paragraph above, and so I back out on my error and
apologize for it.
But making a derivative work is not (in principle) a first
sale doctrine right.
>
>> >There are many ways you can lawfully create a derivative
>> >work without explicit permission of the copyright holder.
>> >One
>>
>>No. The copyright law states that the copyright owner has
>>the monopolistic right to create derivative works.
>
>
> Yes, but this doesn't restrict first sale or fair use.
>You cannot use a library without creating a derivative work,
>so if first sale grants you rights to use, it automatically
>grants you the right to do anything necessary for use.
You are making deaf ears: using a library (even by static
linkage) does NOT create a derivative work unless:
(a) you make another version, subset or superset of
the same library, modifying, enhancing, the
functionality of the original library; or
(b) you make a program that is *so* dependent on the
*internal* implementation structure of the library
that it can be considered a derivative work.
>
>> >clear case is when you lawfully possess the work, there is
>> >no EULA or shrink-wrap agreement, and you need to produce
>> >a derivative work to use the work in the ordinary fashion.
>
>
>>No... Try writing a book with Harry Potter as your main
>>character and JKR's lawyers will be at your door soon.
>
>
>Sometimes I wonder if you are reading what I said or not.
Me too.
>I said "you need to produce a derivative work to use the
>work in the ordinary fashion" and you say "No" and follow
>with an example where you clearly *don't* need to produce a
>derivative work to use the work in the ordinary fashion.
Ok, let's replay: David: "There are many ways you can lawfully
create a derivative work." Me: "no, the only way to create a
derivative work lawfully is having an authorization from the
copyright owner." David: "You cannot use a library without
creating a derivative work,", implying that it would be your
first sale doctring right. Me: "No, simply linking a library
in NO hypothesis creates a derivative work."
Summary? You could not show me any example where you *must*
create a derivative work to exert your first sale rights.
>
>> >This is, by the way, the FSF's own position. It's not
>> >something I'm making up or guessing at.
>>
>>Please send us some pointers to this statements for the FSF.
>
>
> Read any of Eben Moglen's posts.
>
>> >"The license does not require anyone to accept it in order
>> >to acquire, install, use, inspect, or even experimentally
>> >modify GPL'd software. All of those activities are either
>> >forbidden
>>
>>Wrong again. GPL, section 0, para 1: "Activities other than
>>copying, distribution, and *modification* are not covered by
>>this License". Emphasis mine.
>
>
>You are free to disagree with the FSF's interpretation of the
>GPL, but you are not free to misrepresent the FSF's
>interpreration.
No. First of all: you are begin uncivil here. I did not accuse
you of anything, other than not reading correctly what I
wrote previously; which I can attribute to my poor knowledge
of the English language. So, please, I am not being impolite
to you, do the same.
Second: you did not provide a concrete pointer to one of Eben
Moglen's posts, for instance, saying that modification is not
covered by the GPL. Me, OTOH, showed you that the TEXT of the
GPL says it covers modifications.
>
>> >or controlled by proprietary software firms, so they
>> >require you to accept a license, including contractual
>> >provisions outside the reach of copyright, before you can
>> >use their works. The free software movement thinks all
>> >those activities are rights, which all users ought to
>> >have; we don't even want to cover those activities by
>> >license."
>>
>>Except for the modification part, which *is* the scope of
>>regular, Berne-convention-molded copyrights law.
>
>
>Feel free to disagree with the FSF about the meaning of the
>GPL, but it is the FSF's position that you can modify a GPL'd
>work without agreeing to the GPL.
I don't disagree with the FSF -- you are alleging that this is
their position, and I am disagreeing with YOU. And you have
not produced evidence in contrary.
>
>> >Now we draw different conclusions based on this, but we
>> >agree on this. You do not need to agree to the GPL to
>> >create derivative works.
>>
>>No, we disagree on this too.
>
>
> I don't know who "we" is, but I agree with the FSF.
We = You and Me disagreeing. And you still have to show where
the FSF says the GPL does not cover modifications.
>
>> >>If you will keep your copy and registration # of windows,
>> >>yes, you *must* wipe out the machine before selling it.
>> >
>> >
>> >Since there is no copy or registration number of a GPL'd
>> >work to keep, this actually argues the reverse of what I
>> >said. If I legally acquire ten copies of Windows, I can
>> >perform normal use on those ten copies and then transfer
>> >those copies to someone else.
>
>
>>This is not the point: you still would have to wipe your ten
>>computers clean if you want to sell the ten copies you have.
>
>
> Right. You cannot increase the number of copies.
>
>>In the GPL'd case, if you disregard the terms of the
>>license, you can still keep, use, etc. You can *not* copy
>>it, distribute it, or modify it tough.
>
>
>You can, so long as you don't increase the number of copies.
>This is a right under first sale.
Ok, I'll concede on this.
>
>> >>So, no, when you get a WinXP CD from Microsoft, you have
>> >>absolutely *no* rights to create derivative works. If a
>> >>person creates a derivative work, even if it does not
>> >>distribute it, it would be infringing on MS's copyrights
>> >>and I would not want to be in said person's shoes, if
>> >>someone in the legal department of MS wakes up in the
>> >>wrong side of the bed.
>
>
>> >But you do have the right to create derivative works if
>> >such derivative works are necessarily created in the
>> >process of the ordinary use of the work.
>
>
>>Ok, let's repeat ourselves:
>
>
>>A derivative work is a novel intellectual creation (of the
>>spirit) that results from some transformation of another
>>work, said the "original" work.
>>
>>There is a similar (identical?) definition on 17 USC, but I
>>am quoting (bad translation mine) our "Lei 9610/98 -- Lei de
>>Direitos Autorais" (1998 Brazilian Author's Rights Act),
>>art. 5?, VIII, 'g'.
>>
>>I can't think of any example where to use a work, you must
>>create another work transforming the first. If you can,
>>please enlighten me. Beware: your *spirit* must transform
>>the work, not your computer. Yes, as when *you* translate a
>>book to another language, in an
>>non-automatable-non-automated process.
>
>
>To use a library, you must write a program that uses that
>libraries and includes its header files. You must compile the
>library and the program, and link the result. You must then
>execute the result.
>
> You can argue it one of two ways:
>
> 1) The result is a derivative work, hence creating a
>derivative work is necessary for ordinary use. Thus
>permission to use means permission to create (at least some)
>derivative works.
** NOT THIS ** :-)
>
> 2) The result is not a derivative work, hence you
>don't need permission from the copyright holder to do it.
** THIS ** : yes, the result is NOT a derivative work.
So, to link with a library you don't need permission.
That's what I said since the beginning.
> Either way you get the same result, permission is not
>needed beyond permission to use.
Conceded.
>
>> >I think that if I write software that runs under Windows,
>> >an argument can be made that that software is a derivative
>> >work of Windows. That
>
>
>>No, no, no, and no. A derivative work is not something that
>>is "argumentable" :-). There is a clear legal definition,
>>and there are even tools (the Holy Trinity of Derivation:
>>Abstraction, Filtration, Comparison) to help us define and
>>discover what is and what is not a derivative work. And no,
>>HelloWorld.c is not a derivative work of Windows, even if it
>>#include<windows.h>
>>
>>please, google for:
>>
>>abstraction filtration comparison derivative
>>
>>-- it will be enlightening.
>
>
> Then all the people who think that creating a binary
>kernel module requires creating a derivative work and hence
>can be restricted by the GPL are wrong. Take that argument
>up with them.
I took. Google my name on lkml and you'll see. They ARE wrong.
Linus himself studied carefully the situation and came to the
conclusion they are wrong,
I'll rewrite something, from this e-mail, for emphasis:
"You are making deaf ears: using a library (even by static
linkage) does NOT create a derivative work unless:
(a) you make another version, subset or superset of
the same library, modifying, enhancing, the
functionality of the original library; or
(b) you make a program that is *so* dependent on the
*internal* implementation structure of the library
that it can be considered a derivative work."
If you make a kernel module that only uses something
EXPORT_SYMBOL()'d from the kernel, you are NOT in principle
writing a derivative work. If you use EXPORT_SYMBOL_GPL()'d
symbols, then you are incurring in (b) above and your kernel
module is most certainly a derivative work.
I think Linus' opinion pacified this point, at least on LKML.
>
>> >argument is as strong as the argument that a driver with
>> >linked in firmware is a single work.
>>
>>This would most certainly not prevail in any court at all.
>>Obviously, IANAL and TINLA applies. But, that said, I have
>>good credentials :-)
>
> I think even if the result is not a derivative work,
>the rules for distributing it would be the same. However, it
>would change the rules for creating it. Either way, however,
>you get that you can do it without agreeing to the GPL, and
>this is the FSF's position.
You repeated this a lot of times, but you have not
substatitiated it, at least WRT something I asked you: please,
give me some *link* where EM, RMS, or any other FSF/GNU guy
contradicts the GPL section 0 paragraph 1 ("modification")
saying that you can modify a GPLd work without agreeing to the
GPL.
>
> DS
Hey, I am trying to help, don't be so hostile :-)
Massa
PS: yes, the "broken threads" thing p*sses me off too, but I
can't prevent it.
> That is the point: the result is not a single work. It is a
> collection or compilation of works, just like an anthology. If
> there is any creativity involved, is in choosing and ordering
> the parts. The creation of works that "can be linked together"
> is not protected by copyright: the literary analogy was to
> "create a robot short story". Such a story could go into an
> anthology called (duh) "Robot Short Stories", but its
> licensing is independent of every other robot short story in
> the world -- except those it is a derivative work of.
That's fine then, if you want to define derivative work in this way, then I
can configure, compile, and link the Linux kernel without permission of the
copyright holder under first sale (since no derivative work is created). I
can write a program that uses a library, compile my program, and link it to
the library, again without creating a derivative work.
> You are making deaf ears: using a library (even by static
> linkage) does NOT create a derivative work unless:
>
> (a) you make another version, subset or superset of
> the same library, modifying, enhancing, the
> functionality of the original library; or
>
> (b) you make a program that is *so* dependent on the
> *internal* implementation structure of the library
> that it can be considered a derivative work.
Okay. This gets to the same result that I get to, which is that you can do
all the things you want to do without permission from the copyright holder
under first sale. Since this is not creating a derivative work, no special
permission is needed.
> >> >This is, by the way, the FSF's own position. It's not
> >> >something I'm making up or guessing at.
> >>
> >>Please send us some pointers to this statements for the FSF.
> >
> >
> > Read any of Eben Moglen's posts.
> >
> >> >"The license does not require anyone to accept it in order
> >> >to acquire, install, use, inspect, or even experimentally
> >> >modify GPL'd software. All of those activities are either
> >> >forbidden
> >>
> >>Wrong again. GPL, section 0, para 1: "Activities other than
> >>copying, distribution, and *modification* are not covered by
> >>this License". Emphasis mine.
> >You are free to disagree with the FSF's interpretation of the
> >GPL, but you are not free to misrepresent the FSF's
> >interpreration.
> No. First of all: you are begin uncivil here. I did not accuse
> you of anything, other than not reading correctly what I
> wrote previously; which I can attribute to my poor knowledge
> of the English language. So, please, I am not being impolite
> to you, do the same.
Read the quote above.
> Second: you did not provide a concrete pointer to one of Eben
> Moglen's posts, for instance, saying that modification is not
> covered by the GPL. Me, OTOH, showed you that the TEXT of the
> GPL says it covers modifications.
Read the quote. For about the fourth time in this thread, here's the cite:
http://emoglen.law.columbia.edu/publications/lu-12.html "The license does
not require anyone to accept it in order to acquire, install, use, inspect,
or even experimentally modify GPL'd software."
> >Feel free to disagree with the FSF about the meaning of the
> >GPL, but it is the FSF's position that you can modify a GPL'd
> >work without agreeing to the GPL.
> I don't disagree with the FSF -- you are alleging that this is
> their position, and I am disagreeing with YOU. And you have
> not produced evidence in contrary.
I don't know what to say. The FSF has had a clear, consistent position on
the GPL for a very long time and it has always been that ordinary use is
permitted without agreeing to the GPL. For source code, modification is
often part of ordinary use. Anyone who has grabbed a package intended for a
different version of their OS and had to tweak things to get the code to
work knows this.
> We = You and Me disagreeing. And you still have to show where
> the FSF says the GPL does not cover modifications.
I never said that the FSF says the GPL does not cover modifications, I said
it doesn't cover ordinary use. That means it doesn't cover modifications
when those modifications are made in the course of ordinary use.
> > 2) The result is not a derivative work, hence you
> >don't need permission from the copyright holder to do it.
> ** THIS ** : yes, the result is NOT a derivative work.
> So, to link with a library you don't need permission.
> That's what I said since the beginning.
> > Either way you get the same result, permission is not
> >needed beyond permission to use.
>
> Conceded.
Okay. So you get to the same place I get by a different route. One of the
strange things I've noticed is nearly all cases, you get the same result
whether you think the final work is a derivative work or not.
> > Then all the people who think that creating a binary
> >kernel module requires creating a derivative work and hence
> >can be restricted by the GPL are wrong. Take that argument
> >up with them.
> I took. Google my name on lkml and you'll see. They ARE wrong.
> Linus himself studied carefully the situation and came to the
> conclusion they are wrong,
> I'll rewrite something, from this e-mail, for emphasis:
>
> "You are making deaf ears: using a library (even by static
> linkage) does NOT create a derivative work unless:
>
> (a) you make another version, subset or superset of
> the same library, modifying, enhancing, the
> functionality of the original library; or
>
> (b) you make a program that is *so* dependent on the
> *internal* implementation structure of the library
> that it can be considered a derivative work."
> If you make a kernel module that only uses something
> EXPORT_SYMBOL()'d from the kernel, you are NOT in principle
> writing a derivative work. If you use EXPORT_SYMBOL_GPL()'d
> symbols, then you are incurring in (b) above and your kernel
> module is most certainly a derivative work.
>
> I think Linus' opinion pacified this point, at least on LKML.
I don't think courts seem to agree with this, but I can only find cases
where the result really would have been the same whether or not the work was
derivative. For example, one case inolved a company that stole test
questions from another company. The courts ruled that the test with some of
the "borrowed" questions was a derivative work, even though there's no
special "integration" of the questions. But they could perfectly well have
reached the same conclusion without the "derivative work" argument.
There are court cases on point that definitely disagree with you, for
example Mirage Editions, Inv. v. Albuquerque ART (cutting a picture out of a
book creates a derivative work). Also National Football League v. TVRadio
Now (embedding someone else's broadcast with your advertisements through an
automated process creates a derivative work).
I think it would make a lot of sense if courts held that compiling and
linking are analogous to format changes (like converting an audio-visual
work from DVD to VHS). This process involves making copies of the work so
that it can be used in different environments that have different technical
requirements. (Except in cases where one work is heavily adapted to the
internals of another.) It's clear that anyone who tried to get an
independent copyright on their compiled Linux kernel binary should be
laughed off the planet.
> > I think even if the result is not a derivative work,
> >the rules for distributing it would be the same. However, it
> >would change the rules for creating it. Either way, however,
> >you get that you can do it without agreeing to the GPL, and
> >this is the FSF's position.
> You repeated this a lot of times, but you have not
> substatitiated it, at least WRT something I asked you: please,
> give me some *link* where EM, RMS, or any other FSF/GNU guy
> contradicts the GPL section 0 paragraph 1 ("modification")
> saying that you can modify a GPLd work without agreeing to the
> GPL.
This has always been their position, when modification is needed for
ordinary use. See the quote from Eben Moglen above. Now, as I said, they
reach different conclusions based on this, but we agree on this.
DS
On Wed, 2005-04-13 at 21:47 +0200, Sven Luther wrote:
> On Wed, Apr 13, 2005 at 04:53:56PM +0200, Marco Colombo wrote:
> > > > This is different. They are not giving the source at all. The licence
> > > > for those object files _has_ to be different. _They_ want it to be
> > > > different.
> > >
> > > Sure, but in this case, the binary firmware blob is also a binary without
> > > sources. If they really did write said firmware directly as it is, then they
> > > should say so, but this is contrary to everyone's expectation, and a dangerous
> > > precedent to set.
> >
> > You should realize that any author can publish his work in the form he
> > likes. He's not bound to "everyone's expectation". I see no danger in
> > that.
>
> I think there may be some limitation of using the GPL as licence in this case
> though, as such behavior may limit its value, and the GPL itself is by no
> means free software.
That GPL isn't the best license in this case (firmware included as
hexstring in the driver source), we already know. But fixing it is up
to the copyright holder. We or GPL face no risk.
Note that the holder does. I'd be interesting if someone produced a
derivative work, such a translation. A translation from the hex form
to some kind of textual formally defined language, such as, say,
assembler, or C. That would be covered by GPL. And would be
distributable under it. Say that the resulting binary is slightly
different. You are _required_ by GPL to provide the source in the
preferred form, this time, preferred by _you_. What if that is C?
Interesting enough. Can the hexstring be reverse-engineered into C,
if it's placed under GPL? Can the copyright holder really prevent that?
Something new to think of. :-)
Have a nice day,
.TM.
--
____/ ____/ /
/ / / Marco Colombo
___/ ___ / / Technical Manager
/ / / ESI s.r.l.
_____/ _____/ _/ [email protected]
David Schwartz wrote:
>>That is the point: the result is not a single work. It is a
>>collection or compilation of works, just like an anthology.
>>If there is any creativity involved, is in choosing and
>>ordering the parts. The creation of works that "can be
>>linked together" is not protected by copyright: the literary
>>analogy was to "create a robot short story". Such a story
>>could go into an anthology called (duh) "Robot Short
>>Stories", but its licensing is independent of every other
>>robot short story in the world -- except those it is a
>>derivative work of.
>
>
> That's fine then, if you want to define derivative
>work in this way, then I can configure, compile, and link the
Not me -- copyright law defines derivative works in this way.
>Linux kernel without permission of the copyright holder under
>first sale (since no derivative work is created). I can
>write a program that uses a library, compile my program, and
>link it to the library, again without creating a derivative
>work.
I already conceded on this.
(...)
>
> Read the quote above.
?! I did not understand which quote, or which part. But I
suspect you're talking about lu-12.html (below), for which
just now you pointed me to.
>>Second: you did not provide a concrete pointer to one of
>>Eben Moglen's posts, for instance, saying that modification
>>is not covered by the GPL. Me, OTOH, showed you that the
>>TEXT of the GPL says it covers modifications.
>
>
> Read the quote. For about the fourth time in this
>thread, here's the cite:
>http://emoglen.law.columbia.edu/publications/lu-12.html "The
>license does not require anyone to accept it in order to
>acquire, install, use, inspect, or even experimentally modify
>GPL'd software."
This is the first time you gave me an URL. I'll look into it.
(...)
>
>
> I never said that the FSF says the GPL does not cover
>modifications, I said it doesn't cover ordinary use. That
>means it doesn't cover modifications when those modifications
>are made in the course of ordinary use.
Insofar, you did not show me an example of need to create a
derivative work in the course of the ordinary use.
(...)
> Okay. So you get to the same place I get by a
>different route. One of the strange things I've noticed is
>nearly all cases, you get the same result whether you think
>the final work is a derivative work or not.
>
(...)
Now some things interesting:
> I don't think courts seem to agree with this, but I
>can only find cases where the result really would have been
>the same whether or not the work was derivative. For example,
>one case inolved a company that stole test questions from
>another company. The courts ruled that the test with some of
>the "borrowed" questions was a derivative work, even though
>there's no special "integration" of the questions. But they
>could perfectly well have reached the same conclusion without
>the "derivative work" argument.
>
> There are court cases on point that definitely
>disagree with you, for example Mirage Editions, Inv. v.
>Albuquerque ART (cutting a picture out of a book creates a
>derivative work). Also National Football League v. TVRadio
>Now (embedding someone else's broadcast with your
>advertisements through an automated process creates a
>derivative work).
The embedding was not made by a fully automated process, was
it? Didn't someone had to create the advertisements, with the
purpose to be presented embedded in the broadcast? I suspect
-- without looking at the case files at the moment -- that
there was the creation of the derivative works...
>
> I think it would make a lot of sense if courts held
>that compiling and linking are analogous to format changes
>(like converting an audio-visual work from DVD to VHS). This
Our (.br) courts do. I don't know (I'd have to read the cases
you cited) why did those courts ignored the intellectual
novelty requirement of a derivative work, but I'll look into
it.
>process involves making copies of the work so that it can be
>used in different environments that have different technical
>requirements. (Except in cases where one work is heavily
>adapted to the internals of another.) It's clear that anyone
>who tried to get an independent copyright on their compiled
>Linux kernel binary should be laughed off the planet.
>
>> > I think even if the result is not a derivative work,
>> >the rules for distributing it would be the same. However,
>> >it would change the rules for creating it. Either way,
>> >however, you get that you can do it without agreeing to
>> >the GPL, and this is the FSF's position.
>
>
>>You repeated this a lot of times, but you have not
>>substatitiated it, at least WRT something I asked you:
>>please, give me some *link* where EM, RMS, or any other
>>FSF/GNU guy contradicts the GPL section 0 paragraph 1
>>("modification") saying that you can modify a GPLd work
>>without agreeing to the GPL.
>
>
> This has always been their position, when modification
>is needed for ordinary use. See the quote from Eben Moglen
>above. Now, as I said, they reach different conclusions based
>on this, but we agree on this.
>
> DS
Now I concede a lot: you have really substantiated some of
your claims, and I'll have to look into your case examples.
HTH,
Massa
> > That is the point: the result is not a single work. It is a
> > collection or compilation of works, just like an anthology. If
> > there is any creativity involved, is in choosing and ordering
> > the parts. The creation of works that "can be linked together"
> > is not protected by copyright: the literary analogy was to
> > "create a robot short story". Such a story could go into an
> > anthology called (duh) "Robot Short Stories", but its
> > licensing is independent of every other robot short story in
> > the world -- except those it is a derivative work of.
On Thu, Apr 14, 2005 at 10:44:10AM -0700, David Schwartz wrote:
> That's fine then, if you want to define derivative work in this
> way, then I can configure, compile, and link the Linux kernel without
> permission of the copyright holder under first sale (since no derivative
> work is created). I can write a program that uses a library, compile
> my program, and link it to the library, again without creating a
> derivative work.
It's quite true that linking does not create a derivative work.
However, it might be the case that a derivative work had already been
created.
Only when you have legally obtained copies of a work are you entitled
to retain those copies.
Technical details (such as downloading the work in pieces, from different
sites, perhaps using bittorrent, or perhaps using ftp, or perhaps using
other protocols) don't make any more difference [either positively or
negatively] than linking does.
> Okay. This gets to the same result that I get to, which is that
> you can do all the things you want to do without permission from
> the copyright holder under first sale. Since this is not creating a
> derivative work, no special permission is needed.
Sure.
Of course this doesn't apply when you got the copy from someone who
wasn't entitled to give it to you.
For example, if I'm distributing some program derived from a GPLed program
and I have no intention of providing source for the derived form, I'm
at fault, and depending on details you might or might not have a license
to the derivative I authored.
On the other hand, the GPL itself has an explicit exception for this case,
the GPLed content is legal for other people to use even if the person
distributing it had lost their copyright grant. But if we're talking
about linking and derived works, you could easily be using derived code
which is not GPLed. The GPL can't offer you any rights to that code,
because someone else owns the copyright.
--
Raul