Re: Debian export question: JAPAN and the world
On Tue, Apr 05, 2005 at 01:41:02PM +0900, Satoshi Kawase (Fukuoka) wrote: > I work for a major Japanese electronics company and we would like include > Debian into one of our new products. > > The trouble we are facing is that because Japan is one of the countries in > the wassenaar arrangement exports of cryptographic software count as > "munitions" and hence must be passed through the Japanese version of the BXA > (Bureau of Industry and Security). This may be true, but as I understand it, the Wassenaar arrangement doesn't specifically cover software. Note that the Debian non-US server (which was intended to circumvent the US controls) is in a Wassenaar arrangement country. It was merely the additional US restrictions that caused a problem. dave... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian export question: JAPAN and the world
Dave, I think you may be mistaken about this. If you look here, http://jya.com/wa/wacat52.htm The WA munitions list states in Category 5 section 2: Note The control status of "information security" equipment, "software", systems, application specific "electronic assemblies", modules, integrated circuits, components or functions is determined in Category 5, Part 2 even if they are components or "electronic assemblies" of other equipment. The word "software" here seems to indicate that, yes, the export of software is controlled by the WA. My assumption was that the non-US and non-free server were meant to circumvent controls for WA restrictions as well as the additional US restrictions you speak of. -Satoshi On Apr 5, 2005 4:28 PM, David Schleef <[EMAIL PROTECTED]> wrote:On Tue, Apr 05, 2005 at 01:41:02PM +0900, Satoshi Kawase (Fukuoka) wrote:> I work for a major Japanese electronics company and we would like include> Debian into one of our new products.>> The trouble we are facing is that because Japan is one of the countries in> the wassenaar arrangement exports of cryptographic software count as> "munitions" and hence must be passed through the Japanese version of the BXA> (Bureau of Industry and Security).This may be true, but as I understand it, the Wassenaar arrangementdoesn't specifically cover software. Note that the Debian non-USserver (which was intended to circumvent the US controls) is ina Wassenaar arrangement country. It was merely the additionalUS restrictions that caused a problem.dave...-- Satoshi Kawase[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: [PATCH 00/04] Load keyspan firmware with hotplug
On Mon, 2005-04-04 at 23:51 -0500, Dmitry Torokhov wrote: > On Monday 04 April 2005 23:23, Jan Harkes wrote: > > On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote: > > > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote: > > > > Mmm, probably that 2001 discussion about the keyspan firmware, right ? > > > > > > > > http://lists.debian.org/debian-legal/2001/04/msg00145.html > > > > > > > > Can you summarize the conclusion of the thread, or what you did get > > > > from it, > > > > please ? > > > > > > That people didn't like the inclusion of firmware, I posted how you can > > > fix it by moving it outside of the kernel, and asked for patches. > > > > > > None have come. > > > > Didn't know you were waiting for it. How about something like the > > following series of patches? > > > > [01/04] - add simple Intel IHEX format parser to the firmware loader. > > Firmware loader is format-agnostic, I think having IHEX parser in a separate > file would be better... Why should this be in-kernel at all? Convert the firmware into a binary blob or do it in the userspace request. Kay -- 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: [PATCH 00/04] Load keyspan firmware with hotplug
Hi Jan, > > > > Mmm, probably that 2001 discussion about the keyspan firmware, right ? > > > > > > > > http://lists.debian.org/debian-legal/2001/04/msg00145.html > > > > > > > > Can you summarize the conclusion of the thread, or what you did get > > > > from it, > > > > please ? > > > > > > That people didn't like the inclusion of firmware, I posted how you can > > > fix it by moving it outside of the kernel, and asked for patches. > > > > > > None have come. > > > > Didn't know you were waiting for it. How about something like the > > following series of patches? > > > > [01/04] - add simple Intel IHEX format parser to the firmware loader. > > Firmware loader is format-agnostic, I think having IHEX parser in a separate > file would be better... I agree with Dmitry on this point. The IHEX parser should not be inside firmware_class.c. What about using keyspan_ihex.[ch] for it? Regards Marcel -- 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: [PATCH 00/04] Load keyspan firmware with hotplug
On Tue, Apr 05, 2005 at 10:32:38AM +0200, Kay Sievers wrote: > On Mon, 2005-04-04 at 23:51 -0500, Dmitry Torokhov wrote: > > Firmware loader is format-agnostic, I think having IHEX parser in a separate > > file would be better... > > Why should this be in-kernel at all? Convert the firmware into a binary > blob or do it in the userspace request. Because the keyspan headers seem to have a specific sequence of operations, something like 'load these 5 bytes at offset 10, load this byte at offset 0, etc.' I don't know if there is some magic in that sequence. Without knowing what is in the firmware, it looks to me like a little bit of bootstrap code is loaded first. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH 00/04] Load keyspan firmware with hotplug
On Tue, Apr 05, 2005 at 11:22:06AM +0200, Marcel Holtmann wrote: > I agree with Dmitry on this point. The IHEX parser should not be inside > firmware_class.c. What about using keyspan_ihex.[ch] for it? That's what I had originally, actually called firmware_ihex.ko, since the IHEX format parser is not in any way keyspan specific and there are several usb-serial converters that seem to use the same IHEX->.h trick which could trivially be modified to use this loader. But the compiled parser fairly small (< 2KB) and adding it to the existing module didn't effectively add any size to the firmware_class module since things are rounded to a page boundary anyways. Jan -- 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: [PATCH 00/04] Load keyspan firmware with hotplug
Hi Jan, > > I agree with Dmitry on this point. The IHEX parser should not be inside > > firmware_class.c. What about using keyspan_ihex.[ch] for it? > > That's what I had originally, actually called firmware_ihex.ko, since > the IHEX format parser is not in any way keyspan specific and there are > several usb-serial converters that seem to use the same IHEX->.h trick > which could trivially be modified to use this loader. > > But the compiled parser fairly small (< 2KB) and adding it to the > existing module didn't effectively add any size to the firmware_class > module since things are rounded to a page boundary anyways. so it seems that this is usb-serial specific at the moment. Then I would propose to add it to the core of the usb-serial driver. Unless no other driver in the kernel needs a IHEX parser, I think it is bad idea to mess it up at the moment. People are also working on a replacement for the current request_firmware(), because the needs are changing. Try to keep it close with the usb-serial for now. Regards Marcel -- 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: [PATCH 00/04] Load keyspan firmware with hotplug
Sven Luther wrote: On Tue, Apr 05, 2005 at 12:23:29AM -0400, Jan Harkes wrote: > This ofcourse doesn't actually solve Debian's distribution issues since > the keyspan firmware can only be distributed as part of 'Linux or other > Open Source operating system kernel'. Well, if this is the case, it can be distributed on the non-free archive. Nope, looks awfully non-distributable for me, unless you put it into a kernel-non-free with the entire kernel -- but it says clearly that it's undistributable by itself. HTH, Massa -- 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: [PATCH 00/04] Load keyspan firmware with hotplug
On Apr 5, 2005 9:36 AM, Marcel Holtmann <[EMAIL PROTECTED]> wrote: > People are also working on a replacement for the > current request_firmware(), because the needs are changing. Try to keep > it close with the usb-serial for now. > Could you elaborate on what do you think is needed? I have some of patches to firmware loader and wondering if we should coordinate out efforts. I have 1. convert from using a timer to wait_for_comletion_timeout which simplifies logic 2. tightening of state transition rules and removing possible memory leak (very unlikely) 3. converting firmware_priv to fw_class_dev to simplify memory management. 4. removing request_firmware_nowait as noone seems to be using it - and I doubt one would ever want to request firmware from an interrupt. 5. Creating firmware class in a separate thread to work around selinux (with prism54 firmware is loaded when interface is configured and thus firware loader runs in context of /sbin/ip which may not have access to sysfs. Having separate thread will ensure that firmware loader runs in kernel context). And I was thinking about caching firmware (siomething like if you do "echo 2 > /sys/class/firmware/blah/loading" instead of 0 it will keep a copy of the firmware in memory. One could see all firmwares in /sys/class/firmware/loaded/ and by erase cached firmware by echoing 0 into it). What do you think? -- Dmitry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH 00/04] Load keyspan firmware with hotplug
On Tue, Apr 05, 2005 at 04:36:31PM +0200, Marcel Holtmann wrote: > > > I agree with Dmitry on this point. The IHEX parser should not be inside > > > firmware_class.c. What about using keyspan_ihex.[ch] for it? > > > > That's what I had originally, actually called firmware_ihex.ko, since > > the IHEX format parser is not in any way keyspan specific and there are > > several usb-serial converters that seem to use the same IHEX->.h trick > > which could trivially be modified to use this loader. > > > > But the compiled parser fairly small (< 2KB) and adding it to the > > existing module didn't effectively add any size to the firmware_class > > module since things are rounded to a page boundary anyways. > > so it seems that this is usb-serial specific at the moment. Then I would I really don't see the point you are trying to argue. I said, sure it is possible to make it a separate module, that is what my initial implementation was. Why do you want to pigeon-hole it with anything but the existing firmware loading code? It is _not_ usb-serial specific, in fact once the device is initialized this isn't even needed. And the initialization as far as I can see uses little or no usb-serial code. It happens that many usb-serial devices are built around the ezusb chipset, which in turn seems to be a 8051-based microcontroller. The compilers for such microcontrollers seem to generate IHEX formatted output possibly because eprom burners generally support the format. > it up at the moment. People are also working on a replacement for the > current request_firmware(), because the needs are changing. Try to keep > it close with the usb-serial for now. What? I find the existing request_firmware fairly simple and straightforward, it has a very KISS-like quality to it, it is nice and small and even the userspace support is trivial. I only saw a mention about 'replacing' it in the current thread which mostly involved complaints but didn't actually see anyone volunteering to start working on such a replacement. If a driver wants to load 5 different chunks, just call request_firmware 5 times (i.e. drivers/bluetooth/bcm203x.c). If the data is a single binary blob, just ask for the single binary blob. In this case there seems to be some structure to the blob that I wanted to preserve, and that would either be some custom binary format that contains []... tuples, which ofcourse causes problems for our big-endian brothers, or a similar ascii format, where the IHEX is not only pretty much standardized, it is trivial to parse and even adds checksum information. The only thing that I see missing right now is a change to the makefiles to have in-tree firmware files get installed in /lib/modules/`uname -r`/firmware or some similar place. Ideally people would add a line like, fw-$(CONFIG_FOO) = foo-firmware-blob.fw And make install could drop it a place where hotplug can find it. Jan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH 00/04] Load keyspan firmware with hotplug
Hi Dmitry, > > People are also working on a replacement for the > > current request_firmware(), because the needs are changing. Try to keep > > it close with the usb-serial for now. > > > > Could you elaborate on what do you think is needed? I have some of > patches to firmware loader and wondering if we should coordinate out > efforts. I have > > 1. convert from using a timer to wait_for_comletion_timeout which > simplifies logic > 2. tightening of state transition rules and removing possible memory > leak (very unlikely) > 3. converting firmware_priv to fw_class_dev to simplify memory management. > 4. removing request_firmware_nowait as noone seems to be using it - > and I doubt one would ever want to request firmware from an interrupt. > 5. Creating firmware class in a separate thread to work around selinux > (with prism54 firmware is loaded when interface is configured and thus > firware loader runs in context of /sbin/ip which may not have access > to sysfs. Having separate thread will ensure that firmware loader runs > in kernel context). > > And I was thinking about caching firmware (siomething like if you do > "echo 2 > /sys/class/firmware/blah/loading" instead of 0 it will keep > a copy of the firmware in memory. One could see all firmwares in > /sys/class/firmware/loaded/ and by erase cached firmware by > echoing 0 into it). > > What do you think? actually there is a thread about firmware loading rewrite and POST calling of programs. It must be on LKML or the hotplug mailing list. However my backlog for the interesting topics of these lists increased while I was traveling the last 5-6 weeks. I think you should simply start a new one on LKML. Regards Marcel -- 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: [PATCH 00/04] Load keyspan firmware with hotplug
On Apr 5, 2005 6:45 AM, Jan Harkes <[EMAIL PROTECTED]> wrote: > On Tue, Apr 05, 2005 at 11:22:06AM +0200, Marcel Holtmann wrote: > > I agree with Dmitry on this point. The IHEX parser should not be inside > > firmware_class.c. What about using keyspan_ihex.[ch] for it? > > That's what I had originally, actually called firmware_ihex.ko, since > the IHEX format parser is not in any way keyspan specific and there are > several usb-serial converters that seem to use the same IHEX->.h trick > which could trivially be modified to use this loader. > > But the compiled parser fairly small (< 2KB) and adding it to the > existing module didn't effectively add any size to the firmware_class > module since things are rounded to a page boundary anyways. > It is not about the size, it is about source separation. Since it has nothing to do with actualy loading of a BLOB from userspace to kernel space I'd put it into lib/, like crc functions, etc. It does not really have to work with "struct firmware *", "void *data, size_t len" should be just as useable. -- Dmitry -- 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: [PATCH 00/04] Load keyspan firmware with hotplug
Hi Jan, > > > > I agree with Dmitry on this point. The IHEX parser should not be inside > > > > firmware_class.c. What about using keyspan_ihex.[ch] for it? > > > > > > That's what I had originally, actually called firmware_ihex.ko, since > > > the IHEX format parser is not in any way keyspan specific and there are > > > several usb-serial converters that seem to use the same IHEX->.h trick > > > which could trivially be modified to use this loader. > > > > > > But the compiled parser fairly small (< 2KB) and adding it to the > > > existing module didn't effectively add any size to the firmware_class > > > module since things are rounded to a page boundary anyways. > > > > so it seems that this is usb-serial specific at the moment. Then I would > > I really don't see the point you are trying to argue. I said, sure it is > possible to make it a separate module, that is what my initial > implementation was. Why do you want to pigeon-hole it with anything but > the existing firmware loading code? the existing request_firmware() has nothing in common with IHEX parser and such a parser should not belong there. So either make it a separate module or add it to the module that is using it. In this case this is the keyspan module or the usb-serial core. > It is _not_ usb-serial specific, in fact once the device is initialized > this isn't even needed. And the initialization as far as I can see uses > little or no usb-serial code. > > It happens that many usb-serial devices are built around the ezusb > chipset, which in turn seems to be a 8051-based microcontroller. The > compilers for such microcontrollers seem to generate IHEX formatted > output possibly because eprom burners generally support the format. Then make it at separate module. > > it up at the moment. People are also working on a replacement for the > > current request_firmware(), because the needs are changing. Try to keep > > it close with the usb-serial for now. > > What? I find the existing request_firmware fairly simple and > straightforward, it has a very KISS-like quality to it, it is nice and > small and even the userspace support is trivial. I only saw a mention > about 'replacing' it in the current thread which mostly involved > complaints but didn't actually see anyone volunteering to start working > on such a replacement. > > If a driver wants to load 5 different chunks, just call request_firmware > 5 times (i.e. drivers/bluetooth/bcm203x.c). If the data is a single > binary blob, just ask for the single binary blob. In this case there > seems to be some structure to the blob that I wanted to preserve, and > that would either be some custom binary format that contains > []... tuples, which ofcourse causes problems for > our big-endian brothers, or a similar ascii format, where the IHEX is > not only pretty much standardized, it is trivial to parse and even adds > checksum information. I am not going to repeat the current arguments and it is not about loading multiple firmware files (btw I wrote the bcm203x). Check the mailing list archives for the details. I still need to catch up with the discussion, but there is some ongoing work. > The only thing that I see missing right now is a change to the makefiles > to have in-tree firmware files get installed in /lib/modules/`uname > -r`/firmware or some similar place. Ideally people would add a line > like, > > fw-$(CONFIG_FOO) = foo-firmware-blob.fw > > And make install could drop it a place where hotplug can find it. This is another approach and if you want something like that, then send a patch for it and let Sam and others comment on it. Regards Marcel -- 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]> 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
kernel firmware status
I created a wiki page that contains a list of all drivers that are currently considered undistributable by Debian, the available license information we have for them, and various other comments: http://wiki.debian.net/?KernelFirmwareLicensing I would appreciate feedback from d-l about the various firmware blobs that *do* contain licensing. Remember that the goal is to distribute the firmware in non-free, embedded in the drivers themselves; however, separate from the main kernel tree. -- 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: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: sql-ledger may belong in non-free
On Mon, Apr 04, 2005 at 05:12:28AM -0400, Glenn Maynard wrote:
> "The GPL license allows you to extend SQL-Ledger and distribute the
> "Larger Work". This does NOT mean, that you can remove or alter the
> copyright, nor remove or alter the SQL-Ledger logo. You must give the
> "Larger Work" a different name, but must include "Powered by SQL-Ledger"
> in the product name or subtitle. (e.g. XYZ Accounting, Powered by
> SQL-Ledger). In addition, you need to acknowledge the SQL-Ledger
> trademark and copyright ("SQL-Ledger â is a registered trademark of DWS
> Systems Inc. Copyright  DWS Systems Inc. All rights reserved.").
>
> If you do not want to display the SQL-Ledger logo, the "powered by", or
> the trademark and copyright notice, you need to obtain explicit
> permission from DWS."
By the way, this text seems to be gone. (There are still some bogus
trademark claims on that page--IANAL, but I doubt a trademark allows
them to prevent people from using "sql-ledger" in domain names as long
as the use isn't confusing--but they probably don't affect the software,
or at least the name could be removed if it became a problem.)
--
Glenn Maynard
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: sql-ledger may belong in non-free
Glenn Maynard <[EMAIL PROTECTED]> writes: > By the way, this text seems to be gone. (There are still some bogus > trademark claims on that page--IANAL, but I doubt a trademark allows > them to prevent people from using "sql-ledger" in domain names as long > as the use isn't confusing--but they probably don't affect the software, > or at least the name could be removed if it became a problem.) If Intel can [1], why not these guys? [1] http://www.heise.de/newsticker/meldung/54177 -- Måns Rullgård [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Draft summary of Creative Commons 2.0 licenses (version 3)
On Tue, 05 Apr 2005 01:45:02 +0200 Thomas wrote: > I think that one of the biggest differences between CC and dfsg is the > meaning and the value we give to the word "software". > > Remember that the goal of CC is to give tools (licenses) that allow > the author to use the copyright not in its "default" version, but in > a "creative" way. > > That's the reason why CC has a set of licenses, which go from the most > restrictives (BY-ND-NC) to the most free (BY-SH). > > On the second category are we focusing to find out some dfsg > compliance ;-) > > > But to get this is necessary to fix the > "software-different-meaning-issue". I don't think that this is of paramount importance. As long as Debian and CC take the different language into account and don't engage in misleading word-playing, we can still talk, despite differences in terminology. What's important is to keep in mind that we (Debian) think that the same freedoms are valuable for programs and non-programs. -- :-( This Universe is buggy! Where's the Creator's BTS? ;-) .. Francesco Poli GnuPG Key ID = DD6DFCF4 Key fingerprint = C979 F34B 27CE 5CD8 DC12 31B5 78F4 279B DD6D FCF4 pgp6VRPg4cLT9.pgp Description: PGP signature
Re: kernel firmware status
On Tue, Apr 05, 2005 at 06:06:34PM -0400, Andres Salomon wrote: > I created a wiki page that contains a list of all drivers that are > currently considered undistributable by Debian, the available license > information we have for them, and various other comments: > > http://wiki.debian.net/?KernelFirmwareLicensing > > I would appreciate feedback from d-l about the various firmware blobs that > *do* contain licensing. Remember that the goal is to distribute the > firmware in non-free, embedded in the drivers themselves; however, > separate from the main kernel tree. Also, as i got a response from broadcom about the tg3 driver, and it was noted to me that the text i proposed : 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. Which i put there only as an example and asked them to consult their legal department, was not a good one, i am now asking the help of debian-legal to word a nice licencing text which we can then propose to all copyright holders of proprietary firmware, and even maybe propose to the kernel folk as sample for future firmware licencing policy. As i understand this, the firmware has to be distributable in binary format, as part of an otherwise GPLed file. Additional requirement are that the binary blob content is not modifiable, but the form it takes in the actual GPLed files source code should be (like adding spaces or other syntactic modifications). As for distribution, it should be distribuable by most things, not just inside the kernel tree, or inside the manufacturers driver, as is the case for the keyspan usb driver, and should allow us to move the module in question inside a separate package in non-free. Notice that if we are pushing through with this, we should probably think about a future splitting of our non-free area into a part which is non-free because of not containing the sources, and a part which is non-free because it has some distribution constraints, and draft a non-free-but-distributable-guideline kind of document. Thanks for your help, and i believe in the past few days this issue has been making nice progres, and will hopefully be solved to everyone's satisfaction. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
