Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Sven Luther writes: > Hello, > > > 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. > > > 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 09:26:58AM -0400, Michael Poole wrote: > Sven Luther writes: > > > Hello, > > > > > > 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. > > > > > > 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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) signature.asc Description: Digital signature
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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!! signature.asc Description: This is a digitally signed message part
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 (davem@redhat.com) * 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Apr 04, Sven Luther <[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 Thank you for clarifying that they have been removed from Debian indeed. > 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. Sure, and I suppose that the SuSE and Red Hat lawyers who are allowing them to distribute this "violation" are all morons, right? -- ciao, Marco signature.asc Description: Digital signature
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> On Apr 04, Sven Luther <[EMAIL PROTECTED]> wrote: > > 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. On Mon, Apr 04, 2005 at 09:47:50PM +0200, Marco d'Itri wrote: > Sure, and I suppose that the SuSE and Red Hat lawyers who are allowing > them to distribute this "violation" are all morons, right? That's an irrelevant question: The linux kernel is big and complicated enough that the presence of any non-immediate problem tells us little about anyone. If those lawyers have specifically read this part of the code and realized that the GPL notices on these bits of code are invalid they've probably adopted a "wait and see" approach. There's probably no way to determine whether or not Red Hat or SuSE pay their lawyers to read the kernel code, looking for mis-handled copyright issues. But I'd guess that there's not a lot of money to be made that way. -- Raul -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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] = {
0x, 0x1003, 0x, 0x000d, 0x000d, 0x3c1d0800,
0x37bd3ffc, 0x03a0f021, 0x3c100800, 0x2610, 0x0e18, 0x,
0x000d, 0x3c1d0800, 0x37bd3ffc, 0x03a0f021, 0x3c100800, 0x26100034,
0x0e00021c, 0x, 0x000d, 0x, 0x, 0x,
0x27bdffe0, 0x3c1cc000, 0xafbf0018, 0xaf80680c, 0x0e4c, 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.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Adrian Bunk <[EMAIL PROTECTED]> wrote: (-project added to the Cc:, non-debian related lists removed) > 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"... Jesus. With hindsight, describing the social contract changes as "editorial changes" was clearly massively less than idea. But developers have had the opportunity to revert that change since then and didn't do so - and even now, any developer has the opportunity to put forward a general resolution that would change this. If you believe that the DFSG should not apply to everything in main, then propose a general resolution to change it. The consitution gives people this ability in order to allow them to fix mistakes that have occured in the past. If you think the project's current attitude is wrong, then do something about it. Complaining without actually *doing* anything doesn't help anyone. -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Hello Jeff, ... If i can believe what i see in : http://linux.bkbits.net:8080/linux-2.6/anno/drivers/net/[EMAIL PROTECTED]|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| 0x, 0x1003, 0x, 0x000d, 0x000d, 0x3c1d0800, 2002/03/07 jgarzik| 0x37bd3ffc, 0x03a0f021, 0x3c100800, 0x2610, 0x0e18, 0x, 2002/03/07 jgarzik| 0x000d, 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> > 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Raul Miller wrote: On Apr 04, Sven Luther <[EMAIL PROTECTED]> wrote: 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. On Mon, Apr 04, 2005 at 09:47:50PM +0200, Marco d'Itri wrote: Sure, and I suppose that the SuSE and Red Hat lawyers who are allowing them to distribute this "violation" are all morons, right? That's an irrelevant question: The linux kernel is big and complicated enough that the presence of any non-immediate problem tells us little about anyone. If those lawyers have specifically read this part of the code and realized that the GPL notices on these bits of code are invalid they've probably adopted a "wait and see" approach. There's probably no way to determine whether or not Red Hat or SuSE pay their lawyers to read the kernel code, looking for mis-handled copyright issues. But I'd guess that there's not a lot of money to be made that way. I agree with you on this, Raul, but I also must say that if they adopted a "wait and see" approach, they are putting Novell's and RedHat's assets at stake: if Debian does the same, it would be putting a lot of people's assets at stake: mirror network, CD distributors, some DDs, Debian-based distros, etc. HTH Massa -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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.. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> > 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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 (davem@redhat.com) * 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, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 pr
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 (davem@redhat.com) > * 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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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.
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
[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 signature.asc Description: Digital signature
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 07:39:09PM +0100, 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 and http://lists.debian.org/debian-legal/2004/04/msg00072.html for a similar issue. Also, one year ago I made some factual research about firmwares in the Linux kernel 2.4.25. The results are here: http://lists.debian.org/debian-legal/2004/04/msg00074.html One of the conclusion is that several firmwares would benefit from a license clarification which explicitly allow redistribution. Cheers, -- Bill. <[EMAIL PROTECTED]> Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> "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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
"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] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> "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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RE: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
