Re: [Linux-fbdev-devel] Re: ANNOUNCE New Open Source X server
On Wed, Apr 18, 2001 at 04:57:58PM -0700, Miles Lane wrote: > "David S. Miller" wrote: > > > > James Simmons writes: > > > The Linux GFX project grew out the need for a higher performance X > > > server that has a much faster developement cycle. In the last few years > > > the graphics card and multimedia environments have grow at such a rate > > > the current X solutions can no longer keep pace nor do they focus on > > > producing high performance X servers specifically for linux. Also the > > > community has demanded for specific functionality which has never come to > > > light. > > > > And this specific functionality is? > > > > I think this is not a worthwhile project at all. The X tree, it's > > assosciated protocols and APIs, are complicated enough as it is, and > > the xfree86 project has some of the most talented and capable people > > in this area. It would be a step backwards to do things outside of > > xfree86 development. > > > > If the issue is that "things don't happen fast enough in the xfree86 > > tree", why not lend them a hand and submitting patches to them instead > > of complaining? > > Yes, David, I concur. > > James, please just pitch in and help XFree86 evolve faster. > There are drivers that need to be "Render" extension enabled. Sure, but if there was a Render documentation or something such, things would be much easier. > There's more work to do on fleshing out the Render extension. > I am sure that Kieth Packard would be grateful for any > worthwhile contributions. > > If you are thinking that you'll provide better accellerated > graphics rendering performance, I'd love to know how you plan > to accomplish this. AFAIK, the main impediment to XFree86 > giving really good accelleration support for a broad array > of hardware is the lack of technical documentation from the > manufacturers. Unless you plan on trying to get hardware Well, in doing fbdev drivers you already solve this kind of problems. > manufactures to have you develop their closed-source drivers > for them, I don't see how you'll be able to do any better closed source driver are evil anyway, so don't worry about those. > than the XFree86 organization is already doing. > > XFree86 evolves in a measured way as a result of many > competing needs. Backward compatibility is needed for the > huge installed base of legacy apps. For the various > development toolkits (KDE, Gnome, etc.) there is a rapid > move toward using the Render and "Resize and Rotate" > extensions. These extensions will make all sorts of cool > rendering functionality available to the applications that > use these toolkits (alpha blending, anti-aliased fonts and > so on). > > I'd love to hear you enumerate all the shortcomings that you > believe need to be addressed. Also, please CC: [EMAIL PROTECTED] > At least give the competition an opportunity to win over the > support of the developers you'd like to pull away from > XFree86 work! I think the main critic (guessing from his announcement) is the interaction between the console system and xfree86, as well as the multi-head/keyboard/whatever handling, but let's hear what james has to say about it. 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 08:12:48PM +0100, Ian Campbell wrote: > On Mon, 2005-04-04 at 20:21 +0200, Sven Luther wrote: > > On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote: > > > Then let's see some acts. We (lkml) are not the ones with the percieved > > > problem, or the ones discussing it. > > [...] > > > All i am asking is that *the copyright holders* of said firmware blobs put a > > little comment on top of the files in question saying, all this driver is > > GPLed, except the firmware blobs, and we give redistribution rights to said > > firmware blobs. > > I think what Greg may have meant[0] was that if it bothers you, then you > should act by contacting the copyright holders privately yourself in > each case that you come across and asking them if you may add a little > comment etc, and then submit patches once you have their agreement. Yeah, that is step 3, i mailed LKML, because maybe you would have some useful coment, or some of you who wrote said code may have contacts or something with the copyright holders, or some other insight. I also didn't want this to cause a problem if i blundered in some tense relationship or whatever. For example, the tg3 driver says : * tg3.c: Broadcom Tigon3 ethernet driver. * * Copyright (C) 2001, 2002, 2003, 2004 David S. Miller (davem@redhat.com) * Copyright (C) 2001, 2002, 2003 Jeff Garzik ([EMAIL PROTECTED]) * Copyright (C) 2004 Sun Microsystems Inc. * * Firmware is: * Copyright (C) 2000-2003 Broadcom Corporation. There is no contact for either sun or broadcom, but i believe that Jeff or David may know where this firmware blob may (or not) come from. Friendly, Sven Luther - To unsubscribe 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote: > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote: > > Mmm, probably that 2001 discussion about the keyspan firmware, right ? > > > > http://lists.debian.org/debian-legal/2001/04/msg00145.html > > > > Can you summarize the conclusion of the thread, or what you did get from it, > > please ? > > That people didn't like the inclusion of firmware, I posted how you can > fix it by moving it outside of the kernel, and asked for patches. Yeah, that is a solution to it, and i also deplore that none has done the job to make it loadable from userland. For now, debian is satisfied by moving the whole modules involved to non-free, and this has already happened in part. > None have come. > > So I refuse to listen to talk about this, as obviously, no one cares > enough about this to actually fix the issue. Well, i disagree with the above analysis. The problem is not so much that the firmware violate the GPL, as it constitutes mere agregation, but that the actual copyright statement of the files containing the firmware blobs place them de-facto under the GPL, which i doubt is what was intented originally, don't you think. And *I* do care about this issue, and will follow up this issue with mails to the individual copyright holders of the file, to clarify the situation. > People drag this up about once a year, so you are just following the > trend... Nope, i am aiming to clarify this issue with regard to the debian kernel, so that we may be clear with ourselves, and actually ship something which is not of dubious legal standing, and that we could get sued over for GPL violation. > This is my last reply to this thread, unless it contains code. Ok, but i hope that not only code, but patches clarifying the legal situation will make you happy. Friendly, Sven Luther - To unsubscribe 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote: > On Apr 04, Greg KH <[EMAIL PROTECTED]> wrote: > > > What if we don't want to do so? I know I personally posted a solution > Then probably the extremists in Debian will manage to kill your driver, > like they did with tg3 and others. Nope, they were simply moved to non-free, as it should. I believe the package is waiting for NEW processing, but i also believe that the dubious copyright assignement will not allow the ftp-masters to let it pass into the archive, since it *IS* a GPL violation, and thus i am doing this in order to solve that problem. > This sucks, yes. Not really. Once the, post-sarge, transition is done, you just will have to load the non-free .udeb from the non-free d-i archive, or install the module package from non-free, and you won't even notice. Sarge kernels are messed beyond recognition in this anyway, but they are freezed so ... Friendly, Sven Luther - To unsubscribe 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 09:58:30PM +0200, Adrian Bunk wrote: > On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote: > > On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote: > > > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote: > > > > Mmm, probably that 2001 discussion about the keyspan firmware, right ? > > > > > > > > http://lists.debian.org/debian-legal/2001/04/msg00145.html > > > > > > > > Can you summarize the conclusion of the thread, or what you did get > > > > from it, > > > > please ? > > > > > > That people didn't like the inclusion of firmware, I posted how you can > > > fix it by moving it outside of the kernel, and asked for patches. > > > > Yeah, that is a solution to it, and i also deplore that none has done the > > job > > to make it loadable from userland. For now, debian is satisfied by moving > > the > > whole modules involved to non-free, and this has already happened in part. > > > Does this imply your installer will use these non-free modules? The installer already has provision for loading additional .udebs from floppy or net, not sure about other media, and we don't build yet non-free d-i images with those non-free modules builtin, but it could be arranged. This is post-sarge issues though, and we still have some time to solve them. > If the driver for the controller your harddisk is behind is not used by > the installer you could simply remove these modules instead of moving > them to non-free. yeah, the problem is a whole bunch of people have tg3 network cards it seem :) > > Nope, i am aiming to clarify this issue with regard to the debian kernel, so > > that we may be clear with ourselves, and actually ship something which is > > not > > of dubious legal standing, and that we could get sued over for GPL > > violation. > >... > > > If it was a GPL violation, it wasn't enough to contact only the small > subset of copyright holders that worked on this specific file since > this file might be compiled statically into the GPL'ed kernel. That is not a problem, since even if the firmware is built into the same executable as the rest of the kernel code, it still constitutes only mere agregation, where the kernel is the distribution media, in the GPL sense. Please read the mail i linked too in the original mail for detailed argumentation of this. The only problem to it constituting mere agregation is that the firmware blob is not clearly identified as such in the tg3.c file (for example), and that there is no licencing condition allowing their distribution apart the GPL, which these firmware blobs where evidently not meant to be put under. Friendly, Sven Luther - To unsubscribe 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 03:55:55PM -0400, Jeff Garzik wrote: > Matthew Wilcox wrote: > >On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote: > > > >>Then let's see some acts. We (lkml) are not the ones with the percieved > >>problem, or the ones discussing it. > > > > > >Actually, there are some legitimate problems with some of the files in > >the Linux source base. Last time this came up, the Acenic firmware was > >mentioned: > > > >http://lists.debian.org/debian-legal/2004/12/msg00078.html > > > >Seems to me that situation is still not resolved. > > And it looks like no one cares enough to make the effort to resolve this... > > I would love an open source acenic firmware. Yep, but in the meantime, let's clearly mark said firmware as not-covered-by-the-GPL. In the acenic case it seems to be even easier, as the firmware is in a separate acenic_firmware.h file, and it just needs to have the proper licencing statement added, saying that it is not covered by the GPL, and then giving the information under what licence it is being distributed. Jeff, since your name was found in the tg3.c case, and you seem to care about this too, what is your take on this proposal ? Friendly, Sven Luther - To unsubscribe 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 11:05:03PM +0200, Adrian Bunk wrote: > On Mon, Apr 04, 2005 at 10:23:08PM +0200, Sven Luther wrote: > > On Mon, Apr 04, 2005 at 09:58:30PM +0200, Adrian Bunk wrote: > > > On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote: > > > > On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote: > > > > > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote: > > > > > > Mmm, probably that 2001 discussion about the keyspan firmware, > > > > > > right ? > > > > > > > > > > > > http://lists.debian.org/debian-legal/2001/04/msg00145.html > > > > > > > > > > > > Can you summarize the conclusion of the thread, or what you did get > > > > > > from it, > > > > > > please ? > > > > > > > > > > That people didn't like the inclusion of firmware, I posted how you > > > > > can > > > > > fix it by moving it outside of the kernel, and asked for patches. > > > > > > > > Yeah, that is a solution to it, and i also deplore that none has done > > > > the job > > > > to make it loadable from userland. For now, debian is satisfied by > > > > moving the > > > > whole modules involved to non-free, and this has already happened in > > > > part. > > > > > > > > > Does this imply your installer will use these non-free modules? > > > > The installer already has provision for loading additional .udebs from > > floppy > > or net, not sure about other media, and we don't build yet non-free d-i > > images > > with those non-free modules builtin, but it could be arranged. This is > > post-sarge issues though, and we still have some time to solve them. > > > > > If the driver for the controller your harddisk is behind is not used by > > > the installer you could simply remove these modules instead of moving > > > them to non-free. > > > > yeah, the problem is a whole bunch of people have tg3 network cards it seem > > :) > > > I was more thinking about SCSI controllers, but tg3 is also interesting. > > Additional non-free d-i images will for sure be required, or several > hardware setups might make installation of Debian impossible without > bootstrapping through a different OS or distribution. Well, you only need one free way to get access to external media, non-free d-i simply add a bunch of non-free .udebs to the initrd. > > > > Nope, i am aiming to clarify this issue with regard to the debian > > > > kernel, so > > > > that we may be clear with ourselves, and actually ship something which > > > > is not > > > > of dubious legal standing, and that we could get sued over for GPL > > > > violation. > > > >... > > > > > > > > > If it was a GPL violation, it wasn't enough to contact only the small > > > subset of copyright holders that worked on this specific file since > > > this file might be compiled statically into the GPL'ed kernel. > > > > That is not a problem, since even if the firmware is built into the same > > executable as the rest of the kernel code, it still constitutes only mere > > agregation, where the kernel is the distribution media, in the GPL sense. > > Please read the mail i linked too in the original mail for detailed > > argumentation of this. > > > > The only problem to it constituting mere agregation is that the firmware > > blob > > is not clearly identified as such in the tg3.c file (for example), and that > > there is no licencing condition allowing their distribution apart the GPL, > > which these firmware blobs where evidently not meant to be put under. > > > This is one possible legal interpretation of "mere aggregation". > > Whether judges in all jurisdictions of the world follow this > interpretation or an interpretation of the GPL in one direction or > another is the more interesting question. This is also hinted at by the FSF FAQ, and a verbatim interpretation of the actual GPL text. And you can proof by asburd that it has to be so, or you start facing no end of troubles :) The thread i linked, which is rather short, has some more legalese explanations (not by me :), if you are interested. Friendly, Sven Luther - To unsubscribe 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 04:55:27PM -0400, Theodore Ts'o wrote: > On Mon, Apr 04, 2005 at 09:29:45PM +0200, Sven Luther wrote: > > > > Nope, i am aiming to clarify this issue with regard to the debian kernel, so > > that we may be clear with ourselves, and actually ship something which is > > not > > of dubious legal standing, and that we could get sued over for GPL > > violation. > > > > You know, the fact that Red Hat, SuSE, Ubuntu, and pretty much all > other commercial distributions have not been worried about getting > sued for this alleged GPL'ed violation makes it a lot harder for me > (and others, I'm sure) take Debian's concerns seriously. They probably didn't care :) > The problem may be that because Debian is purely a non-profit, and so > it can't clearly balance the costs and benefits of trying trying to > avoid every single possible risks where someone might decide to file a > lawsuit. Anytime you do *anything* you risk the possibility of a > lawsuit, and if you allow the laywers to take over your business > decisions, the natural avoid-risks-all-costs bias of lawyers are such > that it will either drive a company out of business, or drive a > non-profit distribution into irrelevance. Yes, the problem is indeed that we don't have a legal department which can counter sue, and we are present in a much more widespread area than other companies you cited above. And ubuntu has those driver in their non-free equivalent also. > If Debian wants to be this fanatical, then let those Debian developers > who care do all of the work to make this happen, and stop bothering > LKML. And if it continues to remain the case that a user will have to > manually edit /etc/apt/sources.lists (using vi!) to include a > reference to non-free in order to install Debian on a system that > requires the tg3 device driver, then I will have to tell users who ask > me that they would be better off using some other distribution which > actually cares about their needs. I don't get this, and you threat me as fanatic. I am only saying that the tg3.c and other file are under the GPL, and that the firmware included in it is *NOT* intented to be under the GPL, so why not say it explicitly ? Friendly, Sven Luther - To unsubscribe 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 04:47:36PM -0400, Jeff Garzik wrote: > Sven Luther wrote: > >Yep, but in the meantime, let's clearly mark said firmware as > >not-covered-by-the-GPL. In the acenic case it seems to be even easier, as > >the > >firmware is in a separate acenic_firmware.h file, and it just needs to have > >the proper licencing statement added, saying that it is not covered by the > >GPL, and then giving the information under what licence it is being > >distributed. > > Who has meaningfully contacted Alteon (probably "Neterion" now) about > this? What is the progress of that request? Nobody yet. I plan to do so as time allows though. But how do you respond about the firmware blobs being declared as GPL covered in the kernel ? Who put those firmware blobs there, and form where did they came ? > >Jeff, since your name was found in the tg3.c case, and you seem to care > >about > >this too, what is your take on this proposal ? > > > >Friendly, > > Bluntly, Debian is being a pain in the ass ;-) Thanks all the same, in this case, it is just me though, who want a clear solution to this, and you would too, i guess, especially as it is not much work to do it in the first place, so why is everyone making a problem of this ? > There will always be non-free firmware to deal with, for key hardware. Sure, but then you don't claim they are covered by the GPL as is currently the case ? And i thought that the whole SCO affaire teached us to be more careful about this. It assuredly can't hurt to add a few lines of comments to tg3.c, and since it is probably (well, 1/3 chance here) you who added said firmware to the tg3.c file, i guess you are even well placed to at least exclude it from being GPLed. Is this not a reasonable request ? Which should get a reasonable answer, and not claims of being a pain in the ass, and other wild fanatical accusations ? Friendly, Sven Luther - To unsubscribe 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 11:24:05PM +0200, Sven Luther wrote: > It assuredly can't hurt to add a few lines of comments to tg3.c, and since it > is probably (well, 1/3 chance here) you who added said firmware to the tg3.c > file, i guess you are even well placed to at least exclude it from being > GPLed. Is this not a reasonable request ? Which should get a reasonable > answer, and not claims of being a pain in the ass, and other wild fanatical > accusations ? Jeff, please ignore this last sentence, i should not have said it. Friendly, Sven Luther - To unsubscribe 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/
Re: [PATCH 00/04] Load keyspan firmware with hotplug
On Tue, Apr 05, 2005 at 12:23:29AM -0400, Jan Harkes wrote: > On Mon, Apr 04, 2005 at 12:17:46PM -0700, Greg KH wrote: > > On Mon, Apr 04, 2005 at 08:27:53PM +0200, Sven Luther wrote: > > > Mmm, probably that 2001 discussion about the keyspan firmware, right ? > > > > > > http://lists.debian.org/debian-legal/2001/04/msg00145.html > > > > > > Can you summarize the conclusion of the thread, or what you did get from > > > it, > > > please ? > > > > That people didn't like the inclusion of firmware, I posted how you can > > fix it by moving it outside of the kernel, and asked for patches. > > > > None have come. > > Didn't know you were waiting for it. How about something like the > following series of patches? > > [01/04] - add simple Intel IHEX format parser to the firmware loader. > [02/04] - make the keyspan driver use request_firmware. > [03/04] - converter program used to dump the keyspan headers as IHex files. > [04/04] - result of running the previous program. > > This ofcourse doesn't actually solve Debian's distribution issues since > the keyspan firmware can only be distributed as part of 'Linux or other > Open Source operating system kernel'. Well, if this is the case, it can be distributed on the non-free archive. > > So I refuse to listen to talk about this, as obviously, no one cares > > enough about this to actually fix the issue. > > I got tired of always building my own kernels on Debian just to get my > serial dongle to work since their included keyspan.ko driver is so > useless that it isn't even worth having. The only way to use it with a > Debian kernel is to have the dongle in a powered hub and first boot into > Windows or a normal kernel.org kernel to get the thing initialized. The non-free driver package should solve that for you. > Didn't send the patch earlier since I wanted to split off the > pre-numeration part of the driver so that after intialization we can > unload the unused parts of the driver as well as the the firmware class > module. Friendly, Sven Luther - 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/
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 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/
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 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/
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 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/
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 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/
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 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/
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 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/
Re: PATCH: separate non-GPL tg3 firmware from GPL driver file
On Tue, Apr 05, 2005 at 09:12:58AM -0500, Troy Benjegerdes wrote:
> Please either apply the following somewhere, or consider this a request
> for the human-readable version of the "tg3TsoFwText" string, per the GPL
> requirements.
Notice that the same thing comes from (one of) the drivers distributed by
broadcom directly from :
http://www.broadcom.com/drivers/driver-sla.php?driver=570x-Linux
$ cat fw_lso05.h
/**/
/**/
/* 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.*/
/**/
...
U32 t3StkOffLd05FwText[(0xe90/4) + 1] = {
0xc004003, 0x0, 0x10f04,
0x0, 0x1003, 0x0, 0xd,
0xd, 0x3c1d0001, 0x37bde000, 0x3a0f021,
0x3c11, 0x2610, 0xc004010, 0x0,
...
It is specially ironic to see the GPL advertizement and the firmware binary
words together :)
Will contact their driver support team, and see what it gives.
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/
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
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 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/
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 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Wed, Apr 06, 2005 at 09:34:44AM +0200, Josselin Mouette wrote: > Le mercredi 06 avril 2005 à 02:10 +0200, Sven Luther a écrit : > > > It merely depends on the definition of "aggregation". I'd say that two > > > works that are only aggregated can be easily distinguished and > > > separated. This is not the case for a binary kernel module, from which > > > you cannot easily extract the firmware and code parts. > > > > Josselin, please read the thread i linked to in debian-legal, and as nobody > > really gave reason to oppose it, i believe we have consensus that those > > firmware blobs constitute mere agregation, provided they are clearly > > identified and properly licenced, which they are not always. > > The fact that nobody cared to answer you shouldn't be considered as any > kind of approval for your sayings. There were a couple of replies, but if you are going to argue this, please read the analysis i made, and reply to it. Read in particular : http://lists.debian.org/debian-legal/2005/03/msg00288.html Which contains a more formal analysis from Humberto Massa. So, given that this thread together with the GPLed firmware flasher thread got a respectable amount of replies, i believe we can claim consensus, and this is something the debian-kernel team has been acting upon, and i believe even aknowledged by the release managers and ftp-masters. If you have strong evidence that this is not the case, it would really have been nice to comment on it before the kernel team (not only me which you may dislike for past dealings or whatever) waste effort on something which is wrong in the first place, and i commend you to participate in the above thread asap, voicing your concerns (or remain silent forever thereafter :). Friendly, Sven Luther - To unsubscribe 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Hi Jes, long time without hearing about you :) On Thu, Apr 07, 2005 at 03:17:33AM -0400, Jes Sorensen wrote: > Sven> On Mon, Apr 04, 2005 at 12:21:05PM +0200, Arjan van de Ven > Sven> wrote: > > Sven> Ok, can you please point to me where is the place it should be > Sven> taken off ? I suppose you mean LKML ? > > Yes please! Why ? It does concern you all, doesn't it ? or we will be working to get the actual firmware problem solved, and then people will introduce new problematic firmware case. > If you want the firmware situation changed, I'd recommend spending > your time on improving the firmware loader interface instead. Which will not help without the copyright licencing issue being solved first though, as we do not have any right to distribute most of those firmwares. And no, we are not only bringing this issue and bothering everyone else, we are also doing the work needed to solve the issue with upstream, see : http://wiki.debian.net/?KernelFirmwareLicensing Friendly, Sven Luther - 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Wed, Apr 06, 2005 at 01:22:36PM -0600, Eric W. Biederman wrote: > Arjan van de Ven <[EMAIL PROTECTED]> writes: > > > On Tue, 2005-04-05 at 11:11 +0200, Christoph Hellwig wrote: > > > On Tue, Apr 05, 2005 at 09:49:25AM +0100, Ian Campbell wrote: > > > > I don't think you did get a rejection, a few people said that _they_ > > > > weren't going to do it, but if you want to then go ahead. I think people > > > > are just fed up of people bringing up the issue and then failing to do > > > > anything about it -- so prove them wrong ;-) > > > > > > Actually patches to add firmware loader support to tg3 got rejected. > > > > I think they will be accepted if they first introduce a transition > > period where tg3 will do request_firmware() and only use the built-in > > firmware if that fails. Second step is to make the built-in firmware a > > config option and then later on when the infrastructure matures for > > firmware loading/providing firmware it can be removed from the driver > > entirely. > > For tg3 a transition period shouldn't be needed as firmware loading > is only needed on old/buggy hardware which is not the common case. > Or to support advanced features which can be disabled. > > I am fairly certain in that case the firmware came from the bcm5701 > broadcom driver for the tg3 which I think is gpl'd. So the firmware > may legitimately be under the GPL. So, where is the source for it ? Friendly, Sven Luther - To unsubscribe 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 05:46:27AM -0600, Eric W. Biederman wrote: > Sven Luther <[EMAIL PROTECTED]> writes: > > > On Wed, Apr 06, 2005 at 01:22:36PM -0600, Eric W. Biederman wrote: > > > For tg3 a transition period shouldn't be needed as firmware loading > > > is only needed on old/buggy hardware which is not the common case. > > > Or to support advanced features which can be disabled. > > > > > > I am fairly certain in that case the firmware came from the bcm5701 > > > broadcom driver for the tg3 which I think is gpl'd. So the firmware > > > may legitimately be under the GPL. > > > > So, where is the source for it ? > > The GPL'd driver that broadcom distributes. The history of tg3.c > is that broadcom's bcm57xx driver drove the hardware correctly but > not linux so it was rewritten from scratch. Ok, thanks for that clarification. > Beyond that you need to talk to Broadcom. But if the originator > of the bits distributes them gpl from a redistribution point the > kernel is fine. As you may know, i have contacted Broadcom about this issue, the information passed from the driver support contact to their linux developers, but i have not heard from them yet. > It sounds like you are now looking at the question of are the > huge string of hex characters the preferred form for making > modifications to firmware. Personally I would be surprised > but those hunks are small enough it could have been written > in machine code. Yep, i also think it is in broadcom's best interest to modify the licencing text accordyingly, since i suppose someone could technicaly come after them legally to obtain said source code to this firmware. Unprobable though. > So I currently have no reason to believe that anything has been > done improperly with that code. Well, it all depends if you consider this firmware blob as software, which i feel it is without doubt, or we have not the same definition of software, i.e., the program which runs on the hardware, or not. We cannot claim this is data, since there should be at least some kind of executable code in it, independenlty of the fact that we claim that data is also software. Thanks for the info, i will add it to the Wiki. Friendly, Sven Luther - To unsubscribe 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 10:56:47PM +0200, Adrian Bunk wrote: > On Tue, Apr 05, 2005 at 03:57:01PM +0200, Sven Luther wrote: > >... > > The other point is that other entities, like redhat, or suse (which is now > > novel and thus ibm) and so have stronger backbones, and can more easily > > muster > > the ressources to fight of a legal case, even one which is a dubious one, > > especially given the particularities of the US judicial system, where it is > > less important to be right, and more important to have lot of money to throw > > at your legal machine. Debian has nothing such, and SPI which would stand > > for > > this, is not really upto it either, so in this case, apart from all ideology > > and fanatism, it is for purely pragmatic reasons that they don't distribute > > undistributable files from the non-free part of our archive. You would do > > the > > same in their case. > >... > > > There are many possible legal risks for a Linux distribution. > > > This thread is about one. > > Another one is that RedHat removed MP3 support in their distribution > from programs like xmms ages ago because of the legal risks due to > patents. The Debian distribution still contains software that is capable > of playing MP3's. > > > I'd say of the two above cases, the MP3 patents are far more likely to > cause a lawsuit. > > YMMV. Yes, possibly, especially in these troubled times. > If your statement was true that Debian must take more care regarding > legal risks than commercial distributions, can you explain why Debian > exposes the legal risks of distributing software capable of decoding > MP3's to all of it's mirrors? I don't know and don't really care. I don't maintain any mp3 player (err, actually i do, i package quark, but use it mostly to play .oggs, maybe i should think twice about this now that you made me aware of it), but in any case, i am part of the debian kernel maintainer team, and as such have a responsability to get those packages uploaded and past the screening of the ftp-masters. I believe the planned solution is vastly superior to the current one of simply removing said firmware blobs from the drivers, which caused more harm than helped, which is why we are set to clarifying this for the post-sarge kernels. That said, i was under the understanding that after the SCO disaster, clarification of licencing issues and copyright attributions was a welcome thing here, but maybe i misunderstood those whole issues. Friendly, Sven Luther - To unsubscribe 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 09:06:58PM -0600, Eric W. Biederman wrote: > Sven Luther <[EMAIL PROTECTED]> writes: > > > > It sounds like you are now looking at the question of are the > > > huge string of hex characters the preferred form for making > > > modifications to firmware. Personally I would be surprised > > > but those hunks are small enough it could have been written > > > in machine code. > > > > Yep, i also think it is in broadcom's best interest to modify the licencing > > text accordyingly, since i suppose someone could technicaly come after them > > legally to obtain said source code to this firmware. Unprobable though. > > Possibly. It sounds like that is what you want to do. No, i am making them aware of the possibility, and hoping they fix the issue, but we will see. If they fail to act on this, i don't understand why though, since it is just addition of a clarification. It is not as if i am asking for the release of all their chip specs or something such. > > since there should be at least some kind of executable code in it, > > independenlty of the fact that we claim that data is also software. > > Do you have any evidence that ``software'' was not written directly in > machine code? Software is written directly in machine code when a programmer So what, i seriously doubt they where written using an vi in C, as the code currently stands, so we do need an additional level of source code, being it only some asm code or something. > looks at the instruction set and writes down the binary representation > of the instructions. I know ISC dhcpd has packet filter code that was written > in that manner, so it is not a lost art. And it is done often enough when > an assembler will not cooperate, and generate the correct instruction. But again, this is not the common assumption, so if this is so, they should write it down black on white in the copyright notice, and everyone would be happy. > Without evidence that we don't have the preferred form of the software > for making modifications I don't see how you can complain. No, it goes the other way around. Without evidence that all is clean, we have no right to distribute that code, and if what you describe was the case, a couple of lines telling us that fact would solve the issue, and not even need the involvement of their legal department. I would be somewhat suspisious though if all these guys came up and said they just wrote said firmware in binary directly though. Friendly, Sven Luther - 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, Apr 08, 2005 at 02:31:36AM +0200, Adrian Bunk wrote: > On Thu, Apr 07, 2005 at 11:05:05PM +0200, Sven Luther wrote: > > On Thu, Apr 07, 2005 at 10:56:47PM +0200, Adrian Bunk wrote: > >... > > > If your statement was true that Debian must take more care regarding > > > legal risks than commercial distributions, can you explain why Debian > > > exposes the legal risks of distributing software capable of decoding > > > MP3's to all of it's mirrors? > > > > I don't know and don't really care. I don't maintain any mp3 player (err, > > actually i do, i package quark, but use it mostly to play .oggs, maybe i > > should think twice about this now that you made me aware of it), but in any > > case, i am part of the debian kernel maintainer team, and as such have a > > responsability to get those packages uploaded and past the screening of the > > ftp-masters. I believe the planned solution is vastly superior to the > > current > > one of simply removing said firmware blobs from the drivers, which caused > > more > > harm than helped, which is why we are set to clarifying this for the > > post-sarge kernels. > > > Debian doesn't seem to care much about the possible legal problems of > patents. patents are problematic, and upto recently there where no software patents in europe, so i don't really care. I am not sure about the details of the above problem you mention, could you provide me some link to the problem at hand. I also believe that in the larger scheme restriction of this kind, as is the US restriction on distribution to cuba and everything else, is not-right and even immoral, and *I* personally would fight back if i was ever sued for such things, and there may be higher courts involved than just the US judicial system, which is for sale anyway, where redhat is dependent on. I cannot talk about the whole of debian on this though, and i feel it is for someone else to tackle and handle. If you feel strongly about this, you are free to go take it over with whoever handles this, post to debian-legal and debian-project about it, and help get the issue solved. (/me believes such restrictions of the above are a violation of the elemental human rights to go where one wants and run what operating system on wants). > The firmware issues are an urgent real problem? It is a problem that concerns me and the debian kernel team, thus we are out to fix it. If you have a problem at hand, even if it is not as important as others, would you sit back and not do anything just because others didn't solve other problems ? > Debian should define how much legal risk they are willing to impose on > their mirrors and distributors and should act accordingly in all areas. That is for the ftp-masters to decide, i am not in best speaking term with them, so you are free to go ask the question directly. > But ignoring some areas while being more religious than RMS in other > areas is simply silly. Come on, i am just asking for a damn explicit declaration that the firmware is not something covered by the GPL, and that we should have explicit distribution licence for it. We all agree that these are not covered by the GPL for various reasons, so why not have the copyright holder state it explicitly ? I don't see how do you jump to "more religious than RMS" from that, given that my analysis making the firmware aggregate works are a wee bit different from what they explicitly write in their GPL FAQ. > > That said, i was under the understanding that after the SCO disaster, > > clarification of licencing issues and copyright attributions was a welcome > > thing here, but maybe i misunderstood those whole issues. > > "SCO disaster"? > > It is a disaster for SCO. Now, yes. but we did strengthen our admission of patches policy for more tracability, didn't we, and there where companies who paid SCO for fear of retribution, and they where project who post-poned their linux adoptions, and what not. If nothing else, be it only for all the time we all lost following that story over the past tree years. Friendly, Sven Luther - 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 11:55:44PM -0400, Raul Miller wrote: > > > Also, "mere aggregation" is a term from the GPL. You can read what > > > it says there yourself. But basically it's there so that people make > > > a distinction between the program itself and other stuff that isn't > > > the program. > > On Thu, Apr 07, 2005 at 04:20:50PM -0700, David Schwartz wrote: > > It's also there because the GPL can only apply to either works > > placed under it by their authors and works that are legally classified > > as derivative. If you merely aggregate two works, there is no > > derivation. The GPL is making clear that it's not trying to exceed the > > scope of its authority (which is copyright law). > > The issue of whether or not the combined work is a derivative under > copyright law is a copyright law issue. The GPL does concern itself > with that issue, but not in the "mere aggregation" clause. > > The "mere aggregation" clause holds regardless of whether or not the > combined work is a derivative under copyright law. > > [P.S. I've set the Reply-To: header on this message because I think this > thread has drifted away from kernel issues.] Thanks. BTW, have any of you read the analysis i made, where i claim, rooted in the GPL FAQ and with examples, why i believe that the firmware can be considerated a non derivative of the linux kernel. The main points is that the firmware is not aimed to run in the same address space, even not the same cpu, as the rest of the linux kernel, and that there is a clearly defined communication channel between the GPLed driver and the target processor running the firmware. I further argumented that taking any different stance would bring us worlds of hurt as we would consider the bios as being a derivative work of the kernel they are running, or the bootloader, or the firmware present in proms on devices loaded into the system and so on. I think only the fact that if you consider firmware as being a derivative work, you should consider it a derivative work also when it is flashed on the prom of a pci card or what not, is decisive enough to make those firmware blobs not derivative works of the kernel they are under. Friendly, Sven Luther - 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, Apr 08, 2005 at 03:10:43AM +0100, Henning Makholm wrote: > Scripsit Humberto Massa <[EMAIL PROTECTED]> > > > After a *lot* of discussion, it was deliberated on d-l that > > this is not that tricky at all, and that the "mere > > aggregation" clause applies to the combination, for various > > reasons, with a great degree of safety. > > When was this alleged conclusion reached? I remember nothing like > that. http://lists.debian.org/debian-legal/2005/03/msg00273.html and : http://lists.debian.org/debian-legal/2005/03/msg00283.html and the following thread. These where linked from the original mail in this thread. > > No-one is saying that the linker "merely aggregates" object > > code for the driver; what *is* being said is: in the case of > > firmware, especially if the firmware is neither a derivative > > work on the kernel (see above) nor the firmware includes part > > of the kernel (duh), it is *fairly* *safe* to consider the > > intermixing of firmware bytes with kernel binary image bytes > > in an ELF object file as mere aggregation. > > No, it is completely wrong to say that the object file is merely an > aggregation. The two components are being coupled much more tightly > than in the situation that the GPL discribes as "mere aggregation". So read the analysis and comment on it if you disagree, but let's take it to debian-legal alone, ok ? Friendly, Sven Luther - 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 09:15:07AM -0300, Humberto Massa wrote: > This is where you are wrong IMMHO. All that is needed for you > to distribute the hexdump blob under the GPL is a declaration > from the copyright holder saying "this, to me, is the > preferred form for modification of the firmware and hence the > source code under the GPL." I strongly disagree. This could be an open door to to anyone claiming that whatever binary is the prefered form of modification. Friendly, Sven Luther - 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Fri, Apr 08, 2005 at 04:56:50AM +0100, Henning Makholm wrote: > Scripsit "David Schwartz" <[EMAIL PROTECTED]> > [quoting me] > > >> No, it is completely wrong to say that the object file is merely an > >> aggregation. The two components are being coupled much more tightly > >> than in the situation that the GPL discribes as "mere aggregation". > > > Would you maintain this position even if the firmware is identical > > across operating systems and the Linux driver is identical across different > > firmware builds for different hardware implementations? > > Yes I would. Linking forms a tighter coupling than just placing the > two parts side by side on a filesystem designed for general storage of > byte streams. There is more to say about the situation than the naked So, why didn't you say it when i posted my analysis to debian-legal a month ago and asked for comments ? > fact that that they are aggreated on the same medium; ergo the > sutiation does not constitute *only* aggregation, and the "mere > aggregation" language of the GPL does not apply. > > In particular, the end of GPL #2 does not provide a blanket exception > for all forms of aggregation; it specifically speaks about aggregation > "on a volume of a storage or distribution medium". Read my argumentation, comment on it, and be prepared to consider the same copy of the firmware as a derived work if shipped on a prom on the device itself. Friendly, Sven Luther - 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 05, 2005 at 11:50:54AM -0400, Richard B. Johnson wrote: > On Tue, 5 Apr 2005, Humberto Massa wrote: > > >Josselin Mouette wrote: > > > >>You are mixing apples and oranges. The fact that the GFDL sucks has > >>nothing to do with the firmware issue. With the current situation of > >>firmwares in the kernel, it is illegal to redistribute binary images of > >>the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still > >>be willing to distribute such binary images, but it isn't our problem. > >> > > Wrong! It is perfectly legal in the United States, and I'm pretty > sure in your country, to distribute or redistribute copyrighted > works. Otherwise there wouldn't be any bookstores or newspaper > stands. Mmm, so you are claiming it is perfectly right to make copies of the windows installation CD, or for that matter to duplicate music CDs ? I would be rather interested in knowing how you came to that conclusion :) Friendly, Sven Luther - 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 04:15:45PM +0200, Josselin Mouette wrote: > Le jeudi 07 avril 2005 à 09:03 -0400, Richard B. Johnson a écrit : > > Well it doesn't make any difference. If GPL has degenerated to > > where one can't upload microcode to a device as part of its > > initialization, without having the "source" that generated that > > microcode, we are in a lot of hurt. Intel isn't going to give their > > designs away. > > The GPL doesn't forbid that. The GPL forbids to put this microcode > directly in the same binary as the GPL code. Of course, nothing forbids > some GPL'ed code to take a binary elsewhere and to upload it into the > hardware. No, i am arguing, that we can consider here the binary as a media distribution, in the same way as we would clearly separate the compressor from the compressed data in a auto-uncompressing executable, or the firmware from the firmware flasher in a all-in-one firmware upgrade binary. > At least that's my opinion; AIUI, Sven Luther believes it is possible if > the firmware has a decent (but not necessarily free) license. Indeed, the sole problem is that the current copyright and licencing attributions de-facto sets those firmware blobs under the GPL, which of course makes them undistributable since the GPL clearly claims that we need source code for it, and if any condition of the GPL fails, the program becomes undistributable as a whole. Friendly, Sven Luther - 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Tue, Apr 05, 2005 at 12:50:14PM -0600, Chris Friesen wrote: > Josselin Mouette wrote: > > >The fact is also that mixing them with a GPLed software gives > >an result you can't redistribute - although it seems many people > >disagree with that assertion now. > > This is only true if the result is considered a "derivative work" of the > gpl'd code. > > The GPL states "In addition, mere aggregation of another work not based > on the Program with the Program (or with a work based on the Program) on > a volume of a storage or distribution medium does not bring the other > work under the scope of this License." > > Since the main cpu does not actually run the binary firmware, the fact > that it lives in main memory with the code that the cpu *does* run is > irrelevent. In this case, the Debian stance is that the kernel proper > and the binary firmware are "merely aggregated" in a volume of storage ( > ie. system memory). The problem is that you can only argue it is mere agregation, if the copyright notice doesn't de-facto put said firmware blobs under the GPL, thus making them undistributable by the selfsame definition of the GPL. Friendly, Sven Luther - 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Thu, Apr 07, 2005 at 11:07:23PM +0200, Adrian Bunk wrote: > On Tue, Apr 05, 2005 at 04:05:07PM +0200, Josselin Mouette wrote: > > Le lundi 04 avril 2005 à 21:32 +0200, Adrian Bunk a écrit : > > > On Mon, Apr 04, 2005 at 09:05:18PM +0200, Marco d'Itri wrote: > > > > On Apr 04, Greg KH <[EMAIL PROTECTED]> wrote: > > > > > > > > > What if we don't want to do so? I know I personally posted a solution > > > > Then probably the extremists in Debian will manage to kill your driver, > > > > like they did with tg3 and others. > > > > > > And as they are doing with e.g. the complete gcc documentation. > > > > > > No documentation for the C compiler (not even a documentation of the > > > options) will be neither fun for the users of Debian nor for the Debian > > > maintainers - but it's the future of Debian... > > > > You are mixing apples and oranges. The fact that the GFDL sucks has > > nothing to do with the firmware issue. With the current situation of > > firmwares in the kernel, it is illegal to redistribute binary images of > > the kernel. Full stop. End of story. Bye bye. Redhat and SuSE may still > > be willing to distribute such binary images, but it isn't our problem. > >... > > > It's a grey area. > > debian-legal did pick one of the possible opinions on this matter. > > The similarities between the GFDL and the firmware discussion can be > described with the following two questions: > > Is it true, that the removal of much of the documentation in Debian is > scheduled soon because it's covered by the GFDL, that this is called an > "editorial change", and that Debian doesn't actually care that this will > e.g. remove all documentation about available options of the standard C > compiler used by and shipped with Debian? Notice though that the GFDL problematic is part of a much older issue between debian and the FSF on this, and i believe discussions to solve this issues have been under discussions since more than a year without real progress that i know of. > Is it true, that Debian will leave users with hardware affected by the > firmware problem without a working installer in Debian 3.1? Yes, probably. not my fault though, and the current discussion is part of the plan to fix this, through availability of non-free installer components. > The point is simply, that Debian does more and more look dogmatic at > it's definition of "free software" without caring about the effects to > it's users. I reject this affirmation. > As a contrast, read the discussion between Christoph and Arjan in a part > of this thread how to move firmware out of kernel drivers without > problems for the users. This might not happen today, but it's better for > the users. It is indeed, but it is something that involves kernel development which i don't really have time to do right now, and even if we where to do that, the legal problem of the messed licencing situation would remain. The current short term solution is simply to move the affected drivers to non-free, and provide mechanisms for the user to load these installer modules with the free installer, or have a couple of builds of a non-free installer which include these non-free modules. Saying that we are dogmatic, without even caring to understand what the current reality is doesn't strike me at the most reasonable way to discuss such issues. Friendly, Sven Luther - 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 11, 2005 at 06:12:22PM +0200, Marco Colombo wrote: > [I'm not subscribed, so this in not a real reply - sorry if it breaks > threading somehow.] > > Sven Luther wrote: > > The ftp-master are the ones reviewing the licencing problems, and they > are the > > ones handling the infrastructure, and putting their responsability on the > > stake. If they feel that some piece of software has dubious legal issues > > which > > come at a risk of having them personally come on the receiving end of a > > legal > > case, then they will say, no, we don't distribute this software, and that is > > the end of it. > > I've been following the whole discussion (including later messages), > but I'm still missing one point. You seem to have investigated a lot > on the subject, so I'll ask you. I don't get what real legal issues > distributors may have. > > Let me explain with an example. Lets say: > > A - is the Author (or rights owner) of the software (GPL'ed); > B - is an user, who got the a copy of the software from A; > C - is another user, who got a copy indirectly, that is from a > distributor; > D - is the distributor C got the copy from. > > Now, IANAL at all. But it seems to me that B has the right to _use_ the > software by means of GPL. As long as A thinks B doesn't break GPL, B is > fine. All B needs to do is to fulfill GPL conditions (as a user, there's > little to do). > > C also has the right to use the software, in a very similar way. As long > as A thinks C doesn't break GPL, C is fine. > > D has the right to distribute the software, under GPL terms. As long as > A thinks D doesn't break GPL, D is fine. > > Now. It seems to me that the relationship between D (distributor) and C > (target of the distribution) is _not_ regulated by GPL at all. GPL is a > license, the _owner_ of the rights (A) and the recipient of some rights > (C, as an user) are the only subjects. D _owns_ no rights on the > software, so can't grant any to C. There's no GPL between D and C. I think you are missing the point. D get's a licence from A, the GPL, and this licence includes a licence, not on use, but on redistribution, and the act of D distributing the copy to C is covered by it. In a sense A allows D to distribute the software under the GPL to C. Now, D is only allowed to do this distribution if he also distribute the source code of it, which he can't do for the firmware. Notice also the fact that there are so many contributors to the linux kernel in effect means that there is nobody with the full rights as A, but only a multitude of people in the D case. > So, even if C comes to think D is breaking GPL, all C can do is notify > A. The GPL D is supposedly breaking is an agreement between A and D > only. On which basis may C sue D? For breaking what agreement? It's up > to A to sue D for breaking GPL. This is indeed an interpretation. I am not sure myself if a user receiving GPLed software in binary only fashion as is the case here can sue either D or A to get access to that source code. Now you could argue that any number of authors of GPLed bits of the linux kernel could sue D for distributing their software as a derived work of the binary-only bit, and the fact that D doesn't distribute the source code to the binary bit voids any other right allowed him by the GPL, and thus he has no right to do the distribution at all. The GPL is very clear on this topic. > What is the risk for D, if D is distributing the source of the software > _exactly_ in the form A publicly provides it? It's not up to D to > produce the source, all D has to do is to provide verbatim copies of > it to anyone D distributes the software to, on request. Imagine one of those companies got bought up by some predatory company who wishes us (linux, debian, redhat/suse, whoever) harm. They would then be able to sue for damage or prejudice or whatever. And given what i have heard about the uncertainities of the Alteon ownership, this seems indeed like a plausible scenario, which could result in a SCO bis case. This is the scenario i want to avoid by explicitly stating the relationships of all copyright issues of those firmware blobs. > Does is really matter if C thinks the source being incomplete, > or missing? C can take the issue up with A (by means of the GPL that > exists between A and C), but not with D, since there's no GPL between > D and C. C is in the same position of B. If the source is incomplete, > they may ask A to comply to the GPL, but not D. D made no promises to > them. /me wonders if C then holds an illegal copy of the software, and can then be prosecuted for piracy :) Friendly, Sven Luther - 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
ed to release the full source. > (and D forced to distribute it, but all D's we're talking of here are > very happy with the full disclosure scenario, aren't they?) Imagine A refusing to give away the source code, and D is ordered to remove the incriminated code it is illegally distributing from all its servers, and recall all those thousands of CD and DVD isos containing the code it distributed, and being fined for each day it doesn't do so ? > > This is the scenario i want to avoid by explicitly stating the relationships > > of all copyright issues of those firmware blobs. > > I don't see this scenario nowhere close to likely. Of course, A can > always sue any B, C, or D for whatever reason. It's very unlikely > A will sue anyone in full compliance of GPL, but it's possible. > There's nothing we can do about it. But there's no reason to worry > either. So, we don't take the risk and don't distribute it. If A is not ready to put a couple of lines of disclaimer on his work explaining the copyright and licencing issues, then we are better of not distributing its code, which is what debian will do. > As for the matter of explicit copyright notices, I can only agree. > They won't harm for sure. From a purist standpoint, you're right. And > I _am_ a purist. B-) :) > > > Does is really matter if C thinks the source being incomplete, > > > or missing? C can take the issue up with A (by means of the GPL that > > > exists between A and C), but not with D, since there's no GPL between > > > D and C. C is in the same position of B. If the source is incomplete, > > > they may ask A to comply to the GPL, but not D. D made no promises to > > > them. > > > > /me wonders if C then holds an illegal copy of the software, and can then be > > prosecuted for piracy :) > > No, because GPL explicitly states that: > > 4. You may not copy, modify, sublicense, or distribute the Program > except as expressly provided under this License. Any attempt otherwise > to copy, modify, sublicense or distribute the Program is void, and will > automatically terminate your rights under this License. However, parties > who have received copies, or rights, from you under this License will > not have their licenses terminated so long as such parties remain in > full compliance. Yeah, but who know what mad laws will be passed to repress piracy which will make this void. > Note also that GPL says nothing about how you get your copy. You can > get it while hanging from the ceiling ala Mission Impossible, but if > the software is GPL'ed, then your license is valid. The action may > still be illegal, but that's another matter: you _can_ use the software > (even if in jail). B-) I am not sure. If i where to get a copy of windows, and manage to install it without clicking on the "i agree" button, does that make it a legal copy of windows to use ? Friendly, Sven Luther - 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
incriminated code it is illegally distributing from all its servers, > >and > >recall all those thousands of CD and DVD isos containing the code it > >distributed, and being fined for each day it doesn't do so ? > > Sorry, this is nonsense. D is well willing to distribute the source. > In this case, he _is_ distributing what A publicly stated to be the source. Yep, apart from the fact that A never did publicly state such issue, but just passed it under silence. > That's all. You say what if A changed his mind about what the source is? > Well since it's still GPL'ed (we agree A can't chance the licence on the > fly, right?) A is to provide the new, complete version of the source. > Then, if and only if D refuses to distribute _that_ source, D is in > violation. GPL requires D to distribute source _as received by A_. > If A refuses to give the source, the specific requirement is not > enforceable. No, the GPL itself voids the distribubtion and redistribution rights if the specific requirement is not fullfilled. This doesn't make the requirement not enforceable, but voids the whole GPL licence and makes the work not distributable. > >>>This is the scenario i want to avoid by explicitly stating the > >>>relationships > >>>of all copyright issues of those firmware blobs. > >> > >>I don't see this scenario nowhere close to likely. Of course, A can > >>always sue any B, C, or D for whatever reason. It's very unlikely > >>A will sue anyone in full compliance of GPL, but it's possible. > >>There's nothing we can do about it. But there's no reason to worry > >>either. > > > >So, we don't take the risk and don't distribute it. If A is not ready to > >put a > >couple of lines of disclaimer on his work explaining the copyright and > >licencing issues, then we are better of not distributing its code, which is > >what debian will do. > > There no such a risk. A already placed a copyright notice on his work. > Is it the wrong one? Who cares? I'd even say that once he released it > under GPL, he can't take it back. But the GPL states that we must be able to distribute the sources, clearly defines what said sources are, and states what happens if you can't fullfill a clause of the GPL -> no right to distribute at all. > > > >I am not sure. If i where to get a copy of windows, and manage to install > >it > >without clicking on the "i agree" button, does that make it a legal copy of > >windows to use ? > > Come on, please, do not mix things up. I've said GPL'ed software. Last time > I checked, Windows was not GPL'ed (yet). :-) What has the GPL to do with it ? Friendly, Sven Luther - 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/
Re: [PATCH] ppc32: MV643XX ethernet is an option for Pegasos
On Tue, Apr 12, 2005 at 05:13:04PM +1000, Benjamin Herrenschmidt wrote: > Hi ! > > This patch allows Kconfig to build the MV643xx ethernet driver on > Pegasos (CONFIG_PPC_MULTIPLATFORM) and adds what I think is a missing > fix from Dale's batch, that is remove SA_INTERRUPT and add SA_SHIRQ in > there as the interrupt is shared if I understand things correctly. > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]> > Signed-off-by: Fabio Massimo Di Nitto <[EMAIL PROTECTED]> Well, it originated by me/you/dale, but i think it is trivial stuff anyway. 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
to give away the source code, and D is ordered to > >>>remove > >>>the incriminated code it is illegally distributing from all its servers, > >>>and > >>>recall all those thousands of CD and DVD isos containing the code it > >>>distributed, and being fined for each day it doesn't do so ? > >> > >>Sorry, this is nonsense. D is well willing to distribute the source. > >>In this case, he _is_ distributing what A publicly stated to be the > >>source. > > > >Yep, apart from the fact that A never did publicly state such issue, but > >just > >passed it under silence. > > On the top of a .c file there's a nice copyright notice and licence > statement, > isn't there? A placed it there. _You_ think it may be changed. But what > if A is fine with it? Not in the tg3.c case, no. > >But the GPL states that we must be able to distribute the sources, clearly > >defines what said sources are, and states what happens if you can't > >fullfill > >a clause of the GPL -> no right to distribute at all. > > No. GPL says you must be _willing_ to distribute the sources, as received > by A. See, GPL covers the source. There's no way you can distribute > the software in binary/executable form, unless you get the source and > complile it. That's what you do here. You compile the hexstring, and > the firmware (in binary form) gets "aggregated" to the kernel binary. > If you distribute the result, you have to distribute the source _as > you received it_. That's all. If you do, you're fine. And where did those hexstrings come from ? Friendly, Sven Luther - 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Wed, Apr 13, 2005 at 04:53:56PM +0200, Marco Colombo wrote: > > > This is different. They are not giving the source at all. The licence > > > for those object files _has_ to be different. _They_ want it to be > > > different. > > > > Sure, but in this case, the binary firmware blob is also a binary without > > sources. If they really did write said firmware directly as it is, then they > > should say so, but this is contrary to everyone's expectation, and a > > dangerous > > precedent to set. > > You should realize that any author can publish his work in the form he > likes. He's not bound to "everyone's expectation". I see no danger in > that. I think there may be some limitation of using the GPL as licence in this case though, as such behavior may limit its value, and the GPL itself is by no means free software. Friendly, Sven Luther - 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/
Re: [shorty: Re: 2.6.12 debian powerpc kernels and ppc64 ...]
On Mon, Jul 18, 2005 at 10:39:05PM +0200, Wolfgang Pfeiffer wrote: > The first try to send the message below didn't work. Hoping it does > now ... :) > > Regards > Wolfgang > > - Forwarded message from Wolfgang Pfeiifer - > > To: Sven Luther <[EMAIL PROTECTED]> > Cc: debian-powerpc@lists.debian.org, debian-kernel@lists.debian.org, > linux-kernel@vger.kernel.org > Subject: Re: 2.6.12 debian powerpc kernels and ppc64 ... > Date: Mon, 18 Jul 2005 22:17:37 +0200 > User-Agent: Mutt/1.5.9i > X-URL: http://www.wolfgangpfeiffer.com > > On Mon, Jul 18, 2005 at 07:23:05AM +0200, Sven Luther wrote: > > On Sun, Jul 17, 2005 at 07:52:30PM +0200, Wolfgang Pfeiffer wrote: > > > Hi Sven > > > > > > On Fri, Jul 15, 2005 at 11:04:17PM +0200, Sven Luther wrote: > > > > Hello, > > > > > > > > I would like testers who want to test new powerpc kernels on ppc64 > > > > machines : > > > > > > > > These i have uploaded here : > > > > > > > > > > > > http://people.debian.org/~luther/ppc64/kernel-image-2.6.12-sven_1_powerpc.deb > > > > > > At least the latter one works here. Or at least it boots here without any > > > probs, > > > as it seems .. : > > > > > > $ uname -a > > > Linux debby 2.6.12-sven #1 Fri Jul 15 13:44:26 UTC 2005 ppc GNU/Linux > > > > > > $ cat /proc/cpuinfo > > > processor : 0 > > > cpu : 7455, altivec supported > > > clock : 867MHz > > > revision: 0.2 (pvr 8001 0302) > > > bogomips: 865.18 > > > machine : PowerBook3,5 > > > motherboard : PowerBook3,5 MacRISC2 MacRISC Power Macintosh > > > detected as : 80 (PowerBook Titanium IV) > > > pmac flags : 001b > > > L2 cache: 256K unified > > > memory : 768MB > > > pmac-generation : NewWorld > > > > As was expectet, the 64bit is the one i am not sure about. > > > > > But how come this kernel still does not have the necessary patches > > > applied to run kismet: > > > > Please provide a bug report with this info, > > No. Please see: > http://lkml.org/lkml/2004/8/27/303 > > As you can see I sent them a bug report once. It won't happen again in > the foreseeable future. Send a bug report to the debian kernel package i meant, not upstream, altough ther policy is to follow upstream on this, there may be exceptions. The debian kernel maintainer is a team, not just me, and sending personal mail and nort an archived bug report, is bound to get lost in my (huge) inbox, especially now that i am mostly offline 2 weeks. > that page nobody seemed to be interested in the problem. IIRC I could > not compile for weeks or perhaps even months a new 2.4 kernel version > because of the mentioned errors. 2.4 is dead on desktop powerpc for over a year and a half now, so ... > > i will apply as soon as i am back > > in 2 weeks, if someone from the kernel team doesn't beat me to it. > > The site for the patch I used, IIRC: > <http://www.kismetwireless.net/download.shtml#orinoco2611> > > wget http://www.kismetwireless.net/code/orinoco-2.6.12-rfmon-dragorn-1.diff > > The md5sum for the latter that I have here is > 41fb7cec09f4de93cd2432eb1aceba92 > > So if yours will be different you can let me know. Nice , but please apply this info to a debian bug report (reportbug kernel on a running debian system). > > And I applied the patch to 2.6.12. Or better: I probably patched a > 2.6.11 (tarball) source with patch-2.6.12.bz2, and then applied the > above orinoco patch. (Uncertainty because it's already a few weeks ago > I compiled this kernel ... ) > > And just in case it might help someone else: > The following snippet might serve as an example of how to compile this > more or less wifi ready patched source [Please check for yourself in > case I made any mistakes ... :) ... ]: > > > tar xzvf linux-2.6.11.tar.gz > cd linux-2.6.11/ > bzip2 -cd /path/to/patch-2.6.12.bz2 | patch -p1 > > [then applying the orinoco patch from above] > > cp /boot/someconfig . > make oldconfig > fakeroot make-kpkg clean > > time MAKEFLAGS="CC=gcc-4.0" fakeroot make-kpkg --append-to-version=-somename > --revision +anothername kernel_image > > or > > time MAKEFLAGS="CC=gcc-4.0" fakeroot make-kpkg > --append-to-version=+orinoco-patched --revision +050703 kernel_image > > > HTH > > Thanks for responding, Sven ... and yes: for your work, too :) > > And sorry for refusing to play nice if things run ugly .. Well, just provide a debian bug report so we can continue having this conversation the right way. TW, is this a different patch than the one Jens had applied back them in the 2.6.4 debian powerpc kenrel days ? And which was removed for bugginess or something ? 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/
Re: [PATCH 2.6.10-rc3][PPC32] Fix Motorola PReP (PowerstackII Utah) PCI IRQ map
On Tue, Feb 22, 2005 at 10:36:36AM +0200, Meelis Roos wrote: > >The PCI IRQ map for the old Motorola PowerStackII (Utah) boards was > >incorrect, but this breakage wasn't exposed until 2.5, and finally fixed > >until recently by Sebastian Heutling <[EMAIL PROTECTED]>. > > Yesterday I finally got around to testing it. It seems the patch has > been applied in Linus's tree so I downloaded the latest BK and tried it. > > Still does not work for me but this time it's different. Before the > patch SCSI worked fine but PCI NICs caused hangs. Now I can't test PCI > NICs because even the onboard 53c825 SCSI hangs - seems it gets no > interrupts. > > It detects the HBA, tries device discovery, gets a timeout, ABORT, > timeout, TARGET RESET, timeout, BUS RESET, timeout, HOST RESET and there > it hangs. > > Does it work for anyone else on Powerstack II Pro4000 (Utah)? Can you try : http://people.debian.org/~luther/d-i/images/daily/powerpc/netboot/vmlinuz-prep.initrd It works for me, and the kernel (2.6.8) has the irqs patched, but not the scsi stuff touched, i think. 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/
Re: [PATCH 2.6.10-rc3][PPC32] Fix Motorola PReP (PowerstackII Utah) PCI IRQ map
On Thu, Feb 24, 2005 at 05:47:15PM +0200, Meelis Roos wrote: > >Can you try : > > > > http://people.debian.org/~luther/d-i/images/daily/powerpc/netboot/vmlinuz-prep.initrd > > Unfortunately there are only floppy and floppy-2.4 dirs under powerpc. Oh, damn, need to fix my daily builder, should be ok for tomorrow. IN the meanwhile, you can try : http://people.debian.org/~luther/d-i/images/2005-02-23/powerpc/netboot/vmlinuz-prep.initrd This is a zImage.prep kernel with builtin initrd, you just put it somewhere where you can boot it from, usually a tftp server. 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/
Re: [PATCH 2.6.10-rc3][PPC32] Fix Motorola PReP (PowerstackII Utah) PCI IRQ map
On Thu, Feb 24, 2005 at 06:34:03PM +0200, Meelis Roos wrote: > >Oh, damn, need to fix my daily builder, should be ok for tomorrow. IN the > >meanwhile, you can try : > > > > http://people.debian.org/~luther/d-i/images/2005-02-23/powerpc/netboot/vmlinuz-prep.initrd > > This seems to work fine: onboard scsi is OK, pci nic with de4x5 is OK > too. Haven't got more PCI cards in there currently. Ok, can you now install the 2.6.10-3 package from : http://people.debian.org/~luther/powerpc/2.6.10-3 (you need kernel-image-2.6.10-powerpc and mkvmlinuz), call mkvmlinuz on it (or add it to kernel-img.conf as postinst_hook=/usr/sbin/mkvmlinuz). You may probably want also to modify /etc/mkinitrd/mkinitrd:MODULES_DEP to dep instead of MOST, or you may hit size problems with your initrd, i would be interested in knowing that. Then just dd your /boot/vmlinuz-2.6.10-powerpc to your prep partition, or better yet to a tftp server, and try it out. If the scsi problems are there, can you fill a bug report against kernel-source-2.6.10 ? 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/
Re: [PATCH 2.6.10-rc3][PPC32] Fix Motorola PReP (PowerstackII Utah) PCI IRQ map
On Fri, Feb 25, 2005 at 01:24:19AM +0100, Christian Kujau wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Sven Luther wrote: > > > > Oh, damn, need to fix my daily builder, should be ok for tomorrow. IN the > > meanwhile, you can try : > > > > > > http://people.debian.org/~luther/d-i/images/2005-02-23/powerpc/netboot/vmlinuz-prep.initrd > > oh, what fun - it's booting! de4x5 is loading (although i build my kernels > with a (compiled in) tulip driver). sym53c8xx gets loaded and initializing > the scsi bus is *not* blocking all other activities as usual. > > here are the logs: > > http://nerdbynature.de/bits/hal/d-i-2005.02.23/ (working 2.6.8 from Sven) > http://nerdbynature.de/bits/hal/2.6.11-rc3/ (scsi errors) > > (note: i still have no disks attached) So, now, we need to find out what the problems where, i think it is something that went in between 2.6.8 and 2.6.10, and leigh said he had some ideas. Leigh can you elaborate on those ? 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/
Re: [PATCH 2.6.10-rc3][PPC32] Fix Motorola PReP (PowerstackII Utah) PCI IRQ map
On Fri, Feb 25, 2005 at 12:59:04PM +0100, Christian wrote:
> On Fri, February 25, 2005 7:36, Sven Luther said:
> > So, now, we need to find out what the problems where, i think it is
> > something that went in between 2.6.8 and 2.6.10, and leigh said he had
> > some ideas.
>
> may i ask what patches were applied to a vanilla 2.6.8 kernel to build the
> 2.6.8-d-i then?
Some backports that i got from the list. The complete list of patches is at :
http://svn.debian.org/wsvn/kernel/trunk/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/?rev=0&sc=0
And i guess the one at hand here is :
http://svn.debian.org/wsvn/kernel/trunk/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/powerpc-prep-powerstack-irq.dpatch?op=file&rev=0&sc=0
--- kernel-source-2.6.8.orig/arch/ppc/platforms/prep_pci.c 2004-12-28
08:24:07.0 +0100
+++ kernel-source-2.6.8/arch/ppc/platforms/prep_pci.c 2005-01-03
11:15:30.604274816 +0100ll lines beginning with `## DP:' are a description of
the patch.
## DP: Description: Fix PReP - motorola powerstack II utah pci irq mapping.
## DP: Patch author: Tom Rini <[EMAIL PROTECTED]>
## DP: Upstream status: backport
. $(dirname $0)/DPATCH
@DPATCH@
@@ -115,13 +115,13 @@
static char Utah_pci_IRQ_map[23] __prepdata =
{
0, /* Slot 0 - unused */
-0, /* Slot 1 - unused */
+4, /* Slot 1 - IDE - SL82C105 */
5, /* Slot 2 - SCSI - NCR825A */
0, /* Slot 3 - unused */
-1, /* Slot 4 - Ethernet - DEC2114x */
+3, /* Slot 4 - Ethernet - DEC2114x */
0, /* Slot 5 - unused */
-3, /* Slot 6 - PCI Card slot #1 */
-4, /* Slot 7 - PCI Card slot #2 */
+2, /* Slot 6 - PCI Card slot #1 */
+3, /* Slot 7 - PCI Card slot #2 */
5, /* Slot 8 - PCI Card slot #3 */
5, /* Slot 9 - PCI Bridge */
/* added here in case we ever support PCI bridges */
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/
Re: [PATCH 2.6.10-rc3][PPC32] Fix Motorola PReP (PowerstackII Utah) PCI IRQ map
On Sat, Feb 26, 2005 at 04:39:45AM +0100, Christian wrote: > Sven Luther wrote: > >Some backports that i got from the list. The complete list of patches is > >at : > > > > > > http://svn.debian.org/wsvn/kernel/trunk/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches/?rev=0&sc=0 > > dooh, these websvn patches are giving me a headache will have to > learn /usr/bin/svn first :-\ Well : svn co svn://svn.debian.org/kernel/trunk/kernel/source/kernel-source-2.6.8-2.6.8/debian/patches > >--- kernel-source-2.6.8.orig/arch/ppc/platforms/prep_pci.c 2004-12-28 > > yes, the prep_pci.c and its irq-mappings. the PowerStackII lines were > changed back and forth, and a current 2.6-BK is only different in one > line to the patch you mentioned: I guess the one line is the one for the IDE device, ..., indeed. The one line in question is to enable the onboard IDE controller, which exist but is probably not used, since the place on the board where it should be has no connector soldered. I hear that there is an IDE powerstack II model though, so ... > http://nerdbynature.de/bits/hal/2.6.11-rc5.patched/powerpc-prep-powerstack-irq_2.6.11-rc5.patch > > unfortunately it did not help either and i'll switch back to vanilla > 2.6.8 again and hopefully find out exactly when scsi stopped working. As i understand leigh's and other post, i believe that this is the fix, but that other stuff went in too which did break. > http://nerdbynature.de/bits/hal/2.6.11-rc5/ > http://nerdbynature.de/bits/hal/2.6.11-rc5.patched/ 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 12:21:05PM +0200, Arjan van de Ven wrote: > On Mon, 2005-04-04 at 12:09 +0200, Sven Luther wrote: > > please take this discussion elsewhere. Also please never cc three such Ok, can you please point to me where is the place it should be taken off ? I suppose you mean LKML ? > lists on the same posting, there is absolutely no point in doing that. We already had this discussion on debian-legal and debian-kernel, so i included them for documentation purpose, so people there can follow the discussion even if they don't follow LKML which is rather high volume. As the discussion already was hold there, i don't believe you will see many comments from them. So, i posted to LKML directly, as i believe that it is where this needs to be solved, as only the copyright holders can fix this licencing problem, and currently the kernels distributed from ftp.kernel.org are not legally distributable. Friendly, Sven Luther - 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/
non-free firmware in kernel modules, aggregation and unclear copyright notice.
Hello, Current linux kernel source hold undistributable non-free firmware blobs, and to consider them as mere agregation, a clear licence statement from the copyright holders of said non-free firmware blobls is needed, read below for details. Please keep everyone in the CC, as not everyone reads debian-legal or LKML. Some kernel modules present in the kernel sources as distributed from ftp.kernel.org present some non-free binary only firmware that gets uploaded in the target chip by the controler. tg3, qla2xxx, acenix and a couple of others are example of such modules with non-free firmware blobs. This is no major problem per see, since, as discussed in this thread : http://lists.debian.org/debian-legal/2005/03/msg00283.html It is obvious in this context that the non-free firmware constitute a mere aggregation and not an act of linking with the rest of the kernel. This is at least the consensus that debian has reached with input from the debian-legal lists, and what we will stand by this. Naturally even if debian has come to the conclusion that these non-free firmware blobs are not a violation of the rest of the kernel GPL licence, it still doesn't make these non-free firmware blobs free software, and thus they and the drivers which contain it will be removed from debian/main, and put into the non-free section of our archive. Now, these non-free firmware are distributed in the same file as the rest of the module which uses it. This is still ok since it constitute agregation on a same distribution media, where the distribution media is the file in this case. But these files, as seen in the tg3.c case, have no special mention of the firmware in the file header, nor are they distinguished in any way from the rest of the content of that file, which places them de facto under the GPL, since. Accordying to the GPL, we thus needs the source files for this non-free firmware, which is not available, and thus makes the files undistributable. Even if we would consider these firmware as separate and not covered by the de-facto GPLing of the files in question, we still would have no licence allowing us to distribute those non-free firmware blobs, and thus we have again no right to distribute them as part of the kernel. The clean solution is to have a small notice in the header of those files or in the toplevel COPYING file, excluding those firmware blobs from the general GPLing of the files, and have a small comment inside the files to identify the firmware blobs as such and again excluding them from the GPL, and possibly a toplevel listing of all the files wich have such problems. This is an easy fix, and i believe even those who held the above analysis as non-sense or whatever will agree that this is something that should be done. The real problem being that nobody except the copyright holder of those firmware blobs is legally allowed to make said modification, and thus i bring this issue to everyone's attention, for comment and feedback, before trying to reach the copyright holders of those individual firmware blobs asking them to clarify the situation. I believe many of those read this list anyway, so would be able to fix the issue or comment on it without further proding needed. In hopes of quick resolution of these murky legalese issues nobody is really fond of, Friendly, Sven Luther - 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 09:26:58AM -0400, Michael Poole wrote: > Sven Luther writes: > > > Hello, > > > > > > Current linux kernel source hold undistributable non-free firmware blobs, > > and > > to consider them as mere agregation, a clear licence statement from the > > copyright holders of said non-free firmware blobls is needed, read below for > > details. > > > > > > Please keep everyone in the CC, as not everyone reads debian-legal or LKML. > > This question comes up every four or five months. You might have even > been the last one to raise this question on one or more of the mailing > lists you cc'ed. Please, go check the list archives for the previous > (lengthy and multiple) discussions about this topic. Sure, i raised this the last time, and it was discussed on debian-legal and debian-kernel, and since nobody objected, and many where in accord with my arguments in that thread i linked in the parent post, i believe consensus was reached. This is basically the position debian has, and work has already been started to move some of the affected modules in a separate package, which will be distributed from non-free. This is just the followup on said discussion, involving the larger LKML audience, in order to get this fixed for good. As said, it is just a mere technicality to get out of the muddy situation, all the people having contributed source-less firmware blobs, need to give us (us being debian, but also all the linux kernel community) either the source if they persist in distributing the code under the GPL, or a clear distribution licence for these firmware blobs, and clearly identificate them as not covered by the GPL that the file they come in is. Discussing legal issues is all cool and nice for those that appreciates such sport, but it doesn't really make sense if it is not applied to acts later on. Friendly, Sven Luther - To unsubscribe 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote: > On Mon, Apr 04, 2005 at 04:16:47PM +0200, Sven Luther wrote: > > This is just the followup on said discussion, involving the larger LKML > > audience, in order to get this fixed for good. As said, it is just a mere > > technicality to get out of the muddy situation, all the people having > > contributed source-less firmware blobs, need to give us (us being debian, > > but > > also all the linux kernel community) either the source if they persist in > > distributing the code under the GPL, or a clear distribution licence for > > these > > firmware blobs, and clearly identificate them as not covered by the GPL that > > the file they come in is. > > What if we don't want to do so? You mean, you as copyright holder are not willing to mark the firmware blobs as not covered by the GPL, then it is simple, the firmware blob in question is covered by the GPL, and since it lacks source, the whole lot is non-distributable, and any contributor to the linux kernel can sue ftp.kernel.org or whoever else is distributing the kernel code. I don't know if users are able to sue you under the GPL for failing to provide the source code though. Seriously, it is just a couple of lines of comments on top of the file, who in his right mind would object to fixing this issue ? > I know I personally posted a solution for this _5_ years ago in debian-legal, > and have yet to receive a patch... Well, maybe, but *I* was not there 5 years ago, indeed i believe i didn't even was remotely connected to the kernel folks inside debian back then, nor even heard of debian-legal, so i would much like to hear of your proposal, care to give me a hint about the name of the thread it was in or something ? > > Discussing legal issues is all cool and nice for those that appreciates such > > sport, but it doesn't really make sense if it is not applied to acts later > > on. > > Then let's see some acts. We (lkml) are not the ones with the percieved > problem, or the ones discussing it. Well, it is currently a violation of the GPL to distribute those firmware blobs without clearly saying that they are not covered by the GPL. What is the harm that comes by doing that ? All the other dubious points have been set aside by the discussion on the thread you probably didn't read. Right now, the licencing information is only present in the toplevel COPYRIGHT file, which is mostly the GPL (excluding user programs :), and since things like tg3.c which contain such non-free firmware blobs don't say anything else about the copyright of them, they de-facto fall under the toplevel COPYRIGHT, including their firmware blobs which lack sources. All i am asking is that *the copyright holders* of said firmware blobs put a little comment on top of the files in question saying, all this driver is GPLed, except the firmware blobs, and we give redistribution rights to said firmware blobs. The mention of acts was for the folk at debian-legal who like speaking a lot in circle and not bring anything forward, which your mention of patches above confirms :) Friendly, Sven Luther - To unsubscribe 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/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Mon, Apr 04, 2005 at 10:51:30AM -0700, Greg KH wrote: > On Mon, Apr 04, 2005 at 04:16:47PM +0200, Sven Luther wrote: > > This is just the followup on said discussion, involving the larger LKML > > audience, in order to get this fixed for good. As said, it is just a mere > > technicality to get out of the muddy situation, all the people having > > contributed source-less firmware blobs, need to give us (us being debian, > > but > > also all the linux kernel community) either the source if they persist in > > distributing the code under the GPL, or a clear distribution licence for > > these > > firmware blobs, and clearly identificate them as not covered by the GPL that > > the file they come in is. > > What if we don't want to do so? I know I personally posted a solution > for this _5_ years ago in debian-legal, and have yet to receive a > patch... Mmm, probably that 2001 discussion about the keyspan firmware, right ? http://lists.debian.org/debian-legal/2001/04/msg00145.html Can you summarize the conclusion of the thread, or what you did get from it, please ? Friendly, Sven Luther - To unsubscribe 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/
Re: [PATCH] raid6: altivec support
On Thu, Jan 20, 2005 at 10:22:18AM +1100, Benjamin Herrenschmidt wrote: > On Wed, 2005-01-19 at 07:43 +, David Woodhouse wrote: > > On Wed, 2005-01-19 at 15:11 +1100, Benjamin Herrenschmidt wrote: > > > We should probably "backport" that simplification to ppc32... > > > > Yeah I'm increasingly tempted to merge ppc32/ppc64 into one arch > > like mips/parisc/s390. Or would that get vetoed on the basis that we > > don't have all that horrid non-OF platform support in ppc64 yet, and > > we're still kidding ourselves that all those embedded vendors will > > either not notice ppc64 or will use OF? > > Oh well... i've though about it too, and decided that I was not ready to > try it. For one, the problem you mention, with the pile of embedded > junk. I made the design decision to define an OF client interface as the > standard & mandatory entry mecanism to the ppc64 kernel (except legacy > iSeries of course, but I don't want that to multiply). That or the > kexec-like entrypoint passing a flattened device-tree in. > > Also, there are other significant differences in other areas. At this > point, I think the differences are bigger than the common code. > > What would be interesting would be to proceed incrementally, having a > directory somewhere to put the "common" ppc/ppc64 code, and slowly > moving things there. It may be too complicated, but what about letting the commong code in ppc, and moving the ppc32 code into ppc32 ? 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/
