Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Goswin von Brederlow wrote: [EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 31, Nathanael Nerode [EMAIL PROTECTED] wrote: Marco trolled again. FYI, no serious person disagrees with this interpretation. Except every other distribution, which usually retain real lawyers to advise them about potential problems like this instead of relying on mailing lists posts. It's pathetic that you dismiss dissenting opinions as trolling. -- ciao, Marco Every other distribution does not concern itself with the question wether it is legal to distribute this. They are only concerned with Will anybody sue us? and Do we loose more profit by risking a lawsuite or by dropping support?. MfG Goswin And we all agree that it is very unlikely that anyone will sue us if we distribute these firmware blobs. I did specify that, didn't I? Now, Is anyone likely to sue us? *is* the standard Debian generally uses for patents. I presume this is because most software patents are in fact issued illegally at this point (in the US see the statutes and pre-Federal Circuit caselaw, in the EU see the European Copyright Convention and non-EPO caselaw), and DDs generally consider these illegitimate and unworthy of respect. If we use the Is anyone likely to sue us? standard, then definitely these mislicensed lumps should be distributed. However, traditionally Debian has used a higher standard for copyright. (Perhaps because Debian developers generally respect copyright law and think it deserves better treatment than can we get away with this? Perhaps for some other reason?) The higher standard has been more like If the copyright was bought up by EvilCorp and they sued us, would we probably win anyway because we behaved impeccably? In the case of the mislicensed lumps, we would probably *not* win; we would probably be enjoined from any further distribution at least. Perhaps this is a mistake and Debian should use the Is anyone likely to sue us? standard for copyrights as well. Discussion is welcome. Perhaps discussion will clarify why the different standards are used. Discussion on debian-legal please. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Nathanael Nerode [EMAIL PROTECTED] writes: Joe Smith wrote: Sven Luther [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] 1. Module and firmware in free. (The firmware can be compiled into the module, or can be loaded from a file.) 2. Module in free, firmware in nonfree, loaded from file by driver. [One could argue that the modules belong ion contrib, unless the firmware is optional (perhaps allowing access to non-essential features)]. 3. Module in non-free. [Firmware compiled into module, has not yet be seperated into seperate file. This is acceptable, but many of these could be converted to type 2 if somebody puts in the work]. I know we have some modules of type 1. I'm pretty sure we have some modules of type 3. It has not been clear to me if we currently have any modules of type 2. Yes, we do. bluez-firmware and atmel-firmware. Obviously if the infrastucture is not there, that should be fixed. It's there except for d-i. Actualy D-I has the support it needs for this, at least net-retriever I checked myself. But if the cd-retriever lacks it then it is trivial to add the same code there. What isn't there is the md5sum / sha1 sum in the release file for non-free/debian-installer/* on the debian archive. A minor config problem. The only real problem left arises when you need firmware to access the udebs containing the firmware. That means if you use netboot and need firmware for the network card or netinst and a cdrom that needs firmware to be accessible. That can only be solved by building non-free D-I images that already include non-free firmware. I don't think that needs anything but config file changes for the build process. Besides D-I there is also the problem of debian-cd. Someone has to build non-free CD images that include the firmware udebs. That is mainly a infrastructure matter and not a software problem though. Then we have DI. AIUI D-I curretly lacks support for Type 2 and Type 3 modules. This can definately be fixed, but doing it for etch could delay release. Right. Wrong, see above. Surprisingly enough the support for this was addes _5_ years ago to support having udebs in main and local sections. A non-free section is just a variation of that. So the question I have is how long would etch need to be delayed to add support for non-free firmware to D-I? Joey Hess estimated 6 months work, but that was to implement a whole bunch of uncommon special cases. I think it is totally unnecessary to implement all, or even any, of those. http://lists.debian.org/debian-vote/2006/08/msg00122.html (1) was nearly done. The Release file are missing the checksums. Minor problem. For (2) from that post, which is the key sticking point for d-i, it needs to be done anyway, and honestly should not take more than a month if someone bothers. So -- point me to the correct parts of the installer. I don't know where to find this anna. libdebian-installer I'm looking at -- it would be a great help if someone could direct me to the part of the code which loads udebs from disk/network, because I can't find it. Is that all in 'anna', which I can't find? :-/ If I can't find the source code for 'anna', I can't fix it. (2) was done 5 years ago (for the non-free case) by having the retriver concatenate the downloaded Packages files into one before passing it off to anna/libd-i. That way the problem is circumvented. I also have a patch for libd-i to parse multiple packages files but Bastian told me that the internal data structures of the parser will break if packages with the same name appear and dependency resolving might be off. Something I haven't yet seen happening since all my tests had disjunct Packages files. This feature would only be needed to support 3rd party repositories inside the installer though. Not for Debians non-free. One could also extend the trick of concatenating the packages file even for 3rd party repositories. The retriever just need an extra option to no delete the old file. (3) is trivial and simply requires the will to fix RC bugs. (3) is wrong since there is a frimware-nonfree package with 2 firmware udebs in experimental for example. (4) is frankly not nearly as important as Joey makes it out to be. It is very unlikely that someone will have a machine where *both* the CD *and* the NIC *and* the floppy drive if present *and* the USB driver (USB key) need non-free firmware. As long as there is one piece of hardware with fully free drivers which can be used to load the additional non-free material on the machine, it is perfectly tolerable that an alternate piece of hardware is not so supported. (I've seen systems where the NIC needed non-free firmware downloaded and ones where the CD did, but never ones where both did.) I know it's theoretically possible that someone will buy a hell machine where every single peripheral requires a non-free firmware download -- but it's unlikely. And if that happens,
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
[EMAIL PROTECTED] (Marco d'Itri) writes: On Aug 31, Nathanael Nerode [EMAIL PROTECTED] wrote: Marco trolled again. FYI, no serious person disagrees with this interpretation. Except every other distribution, which usually retain real lawyers to advise them about potential problems like this instead of relying on mailing lists posts. It's pathetic that you dismiss dissenting opinions as trolling. -- ciao, Marco Every other distribution does not concern itself with the question wether it is legal to distribute this. They are only concerned with Will anybody sue us? and Do we loose more profit by risking a lawsuite or by dropping support?. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Thu, Aug 31, 2006 at 12:15:20AM -0400, Nathanael Nerode wrote: I'd love to see a legal opinion from the SPI lawyers regarding who would be liable if Debian did commit copyright infringment (or whatever) and someone sued. FWIW, there's a few things I'd love to see legal opinions on too, including the Java/non-free questions John Goerzen raised some time ago. They're still pending on SPI's todo list. If any qualified lawyers with experience in the US are reading this and would like to volunteer some of their time on a pro-bono basis to benefit Debian and other free software organisations such as FreeDesktop.org and PostgreSQL, sending mail to [EMAIL PROTECTED] to that effect might be worthwhile. Cheers, aj signature.asc Description: Digital signature
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Steve Langasek [EMAIL PROTECTED] wrote: [...] On Wed, Aug 30, 2006 at 08:26:56PM -0400, Nathanael Nerode wrote: Should the ftpmasters, who have even less legal expertise, Judging by some of the nonsense that debian-legal is typically riddled with, It's generally quite easy to spot the nonsense. Look for telltale signs like: 1. over-use of authoritative statements and guesswork (such as 'many people X' or 'most people X' instead of 'some people X') to support a weak argument; 2. refusing to explain reasoning which leads to a conclusion; 3. failure to give references to past discussions unless pressed. (Observant readers will have spotted parts of 1, 2 and 3 in support of several of the proposed GRs.) It's a shame that we have to play 'spot the nonsense' but that's how the weakly-moderated debian lists seem to work when the cost of gathering data about the possible solutions is so high. if I were an ftpmaster I would find that claim insulting. Could it be insulting but accurate? Brains out on the table, please! How many ftpmasters: a) have previously been involved in copyright cases; b) have previously been involved in trademark or patent cases; c) are currently studying for a legal qualification; or d) are currently employed as legal experts? The only claim to expertise that debian-legal has is in the area of analyzing license terms and how they stack up against the requirements of the DFSG. That is an important function, but it is *not* legal expertise. There have been debian-legal contributors in each of the above categories, (examples OTTOMH: a. me c. http://lists.debian.org/debian-legal/2006/06/msg00197.html d. http://lists.debian.org/debian-legal/2006/08/msg00133.html ) although some don't stick around long because of the 'spot the nonsense' contests. The qualified experts are mostly quiet in the DFSG-comparison threads, as that's mostly not a legal expertise subject and tends to draw quite offensive personal abuse from some contributors. Some other stuff, like permission to distribute, is more obviously linked to law. Hope that explains, -- MJR/slef My Opinion Only: see http://people.debian.org/~mjr/ Please follow http://www.uk.debian.org/MailingLists/#codeofconduct -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Aug 31, Nathanael Nerode [EMAIL PROTECTED] wrote: Marco trolled again. FYI, no serious person disagrees with this interpretation. Except every other distribution, which usually retain real lawyers to advise them about potential problems like this instead of relying on mailing lists posts. It's pathetic that you dismiss dissenting opinions as trolling. -- ciao, Marco signature.asc Description: Digital signature
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Wed, 30 Aug 2006, Mike Hommey wrote: On Tue, Aug 29, 2006 at 07:17:47PM -0700, Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: Debian needs to make a decision on how it will deal with this legal minefield. That is higher priority than the entire discussion going on right now, because it determines whether Debian will distribute these 53 BLOBs *at all*, in 'main' or in 'non-free'. Oddly enough nobody has proposed a GR addressing this, Because voting is an absurd means of settling questions of legal liability. It's the domain of the ftp team to determine whether we can legally distribute a package on our mirrors. So, all in all, all this fuss for seven blobs ? waw, what a waste of time. 53 + 7 = 60. Please Mike, you have lately a tendency to inflame discussions for nothing. You've used me to expect better from you. Cheers, -- Raphaël Hertzog Premier livre français sur Debian GNU/Linux : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Aug 30, Nathanael Nerode [EMAIL PROTECTED] wrote: Debian must decide whether it wants to ship BLOBs with licensing which technically does not permit redistribution. At least 53 blobs have this problem. Many of them are licensed under the GPL, but without source code provided. Since the GPL only grants permission to distribute if you provide source code, the GPL grants no permission to distribute in these cases. Many people disagree with this interpretation. Oddly enough nobody has proposed a GR addressing this, and Debian continues to ship 47 improperly licensed files in linux-2.6. If I were SCO, I'd buy up the copyrights to them from the original companies, and then I'd have a real case for a lawsuit. Not really. What effects do you think a lawsuit about this would have? -- ciao, Marco signature.asc Description: Digital signature
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Wed, Aug 30, 2006 at 09:27:21AM +0200, Marco d'Itri wrote: On Aug 30, Nathanael Nerode [EMAIL PROTECTED] wrote: Debian must decide whether it wants to ship BLOBs with licensing which technically does not permit redistribution. At least 53 blobs have this problem. Many of them are licensed under the GPL, but without source code provided. Since the GPL only grants permission to distribute if you provide source code, the GPL grants no permission to distribute in these cases. Many people disagree with this interpretation. A few very vocal people do. I guess they can be counted on the fingers of both hands or so. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Wed, Aug 30, 2006 at 09:00:27AM +0200, Raphael Hertzog wrote: On Wed, 30 Aug 2006, Mike Hommey wrote: On Tue, Aug 29, 2006 at 07:17:47PM -0700, Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: Debian needs to make a decision on how it will deal with this legal minefield. That is higher priority than the entire discussion going on right now, because it determines whether Debian will distribute these 53 BLOBs *at all*, in 'main' or in 'non-free'. Oddly enough nobody has proposed a GR addressing this, Because voting is an absurd means of settling questions of legal liability. It's the domain of the ftp team to determine whether we can legally distribute a package on our mirrors. So, all in all, all this fuss for seven blobs ? waw, what a waste of time. 53 + 7 = 60. Re-read Nathanael's mail. The blobs that are concerned by all the discussion that has happened so far, and wasted a lot of time, are 7. The 53 are those that have licenses that technically don't allow redistribution. Please Mike, you have lately a tendency to inflame discussions for nothing. You've used me to expect better from you. I'm just pissed about all this waste of time discussing in the void while a release is supposed to happen in 3 months. And here I'm not only talking about this particular thread. Mike PS: Don't worry, you won't hear a lot from me since I'll be on vacation from saturday for almost 3 weeks. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Hello, On Wed, 30.08.2006 at 09:27:21 +0200, Marco d'Itri [EMAIL PROTECTED] wrote: On Aug 30, Nathanael Nerode [EMAIL PROTECTED] wrote: Debian must decide whether it wants to ship BLOBs with licensing which technically does not permit redistribution. At least 53 blobs have this problem. Many of them are licensed under the GPL, but without source code provided. Since the GPL only grants permission to distribute if you provide source code, the GPL grants no permission to distribute in these cases. Many people disagree with this interpretation. I'm not a lawyer, but my take on this is that if someone ships you a BLOB under the GPL, you have the legal right to demand sources from him. So, in other words, I think Debian (or SPI? or FSF?) *could* make a real hurricane in the press (and courts) by trying to wrestle source code from said vendors. If that'd be good or bad for Debian, I don't know, but it will be very expensive and time consuming. Best, --Toni++ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Op wo, 30-08-2006 te 17:16 +0200, schreef Toni Mueller: Hello, On Wed, 30.08.2006 at 09:27:21 +0200, Marco d'Itri [EMAIL PROTECTED] wrote: On Aug 30, Nathanael Nerode [EMAIL PROTECTED] wrote: Debian must decide whether it wants to ship BLOBs with licensing which technically does not permit redistribution. At least 53 blobs have this problem. Many of them are licensed under the GPL, but without source code provided. Since the GPL only grants permission to distribute if you provide source code, the GPL grants no permission to distribute in these cases. Many people disagree with this interpretation. I'm not a lawyer, but my take on this is that if someone ships you a BLOB under the GPL, you have the legal right to demand sources from him. So, in other words, I think Debian (or SPI? or FSF?) *could* make a real hurricane in the press (and courts) by trying to wrestle source code from said vendors. If that'd be good or bad for Debian, I don't know, but it will be very expensive and time consuming. No you can not demand this from the vendor which owns the copyright on the BLOB. They are not bound by the GPL and can distribute the BLOB anyway the want. Third parties, like Debian, are bound by the GPL to distribute the BLOB with the corresponding sources and if they don't distribute the source the can not distribute the BLOB. Of course IANAL and don't know the fine details of copyright law. Greetings Arjan signature.asc Description: Dit berichtdeel is digitaal ondertekend
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Wed, Aug 30, 2006 at 05:16:29PM +0200, Toni Mueller wrote: Hello, On Wed, 30.08.2006 at 09:27:21 +0200, Marco d'Itri [EMAIL PROTECTED] wrote: On Aug 30, Nathanael Nerode [EMAIL PROTECTED] wrote: Debian must decide whether it wants to ship BLOBs with licensing which technically does not permit redistribution. At least 53 blobs have this problem. Many of them are licensed under the GPL, but without source code provided. Since the GPL only grants permission to distribute if you provide source code, the GPL grants no permission to distribute in these cases. Many people disagree with this interpretation. I'm not a lawyer, but my take on this is that if someone ships you a BLOB under the GPL, you have the legal right to demand sources from him. So, in other words, I think Debian (or SPI? or FSF?) *could* make a real hurricane in the press (and courts) by trying to wrestle source code from said vendors. If that'd be good or bad for Debian, I don't know, but it will be very expensive and time consuming. My own understanding, and we discussed this on -legal when we aproached broadcom about the tg3 licencing, is that this is not the case, not really anyway. What happens, is that we, debian have not the possibility to provide those sources, and as thus, simply lose all rights per the GPL to distribute the source code in question, and thus what could happen, would be for the copyright holder to sue us for not respecting the GPL clauses. Obviously, since he doesn't do so himself, he would lose anyway, so the point is mostly moot, but the GPL itself says it doesn't allow us to distribute the problematic code in those cases. Since the firmware blobs are not derivative works of the kernel, but constitute mere agregation in the same binary format, the authors of other pieces of GPLed code fo the linux kernel cannot even sue us for distributing the kernel code with those GPL-violating binary BLOBs. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Sven Luther [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Wed, Aug 30, 2006 at 09:27:21AM +0200, Marco d'Itri wrote: On Aug 30, Nathanael Nerode [EMAIL PROTECTED] wrote: Debian must decide whether it wants to ship BLOBs with licensing which technically does not permit redistribution. At least 53 blobs have this problem. Many of them are licensed under the GPL, but without source code provided. Since the GPL only grants permission to distribute if you provide source code, the GPL grants no permission to distribute in these cases. Many people disagree with this interpretation. A few very vocal people do. I guess they can be counted on the fingers of both hands or so. I think everybody can agree that it would be clearer if the blobs used a licence that clearly allows distribution without requiring source. In the case of the GPL that is definately not clear. About the main issue: As I see it, there are three possible catagories for drivers using firmware that all drivers should ideally fall into assuming the driver part is free : 1. Module and firmware in free. (The firmware can be compiled into the module, or can be loaded from a file.) 2. Module in free, firmware in nonfree, loaded from file by driver. [One could argue that the modules belong ion contrib, unless the firmware is optional (perhaps allowing access to non-essential features)]. 3. Module in non-free. [Firmware compiled into module, has not yet be seperated into seperate file. This is acceptable, but many of these could be converted to type 2 if somebody puts in the work]. I know we have some modules of type 1. I'm pretty sure we have some modules of type 3. It has not been clear to me if we currently have any modules of type 2. Obviously if the infrastucture is not there, that should be fixed. Then we have DI. AIUI D-I curretly lacks support for Type 2 and Type 3 modules. This can definately be fixed, but doing it for etch could delay release. Besides all of that we have quite a few modules with problematic licences. Generally the licence problem is on the firmware, although some might affect the rest of the driver. Some are type-3 style (firmware hard-coded into module, firmware lacking source.)Many of those could be shipped as type-3 modules if licence clarification can be obtained (or preferable: relicencing). A few are type-2 style, they could be shipped as type-2 if proper clarification can be obtained. The above is a rough summer of the problems as I understand it. Please correct be if I am wrong. So the question I have is how long would etch need to be delayed to add support for non-free firmware to D-I? We could also push back the freeze on the kernel by the same amount and have some people work on obtaining clarification on some of the problematic licences. With the combination of those two we could end up with having very few drivers not ship, and all shipped drivers both free and non-free be usable during installation. While pushing Etch back is a big deal, it almost seems to me that some of the proposed GRs are an even bigger deal, and, as has been pointed out, the GRs would probably only make a difference for a small number of modules, unless we ignore the problematic licencing of most of the remaining drivers. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Joe Smith wrote: Sven Luther [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Wed, Aug 30, 2006 at 09:27:21AM +0200, Marco d'Itri wrote: On Aug 30, Nathanael Nerode [EMAIL PROTECTED] wrote: Debian must decide whether it wants to ship BLOBs with licensing which technically does not permit redistribution. At least 53 blobs have this problem. Many of them are licensed under the GPL, but without source code provided. Since the GPL only grants permission to distribute if you provide source code, the GPL grants no permission to distribute in these cases. Many people disagree with this interpretation. A few very vocal people do. I guess they can be counted on the fingers of both hands or so. Probably less. The people who disagree with this interpretation are contradicting the plain text of the GPL, ignoring copyright law, ignoring the stated intent of the drafters of the GPL and the FSF, etc. As I said, the distributors of this unlicensed material probably *intended* to give it a proper distribution license. Should Debian rely on the assumption of good intentions? Debian doesn't do that for copyright issues in *general*. I think everybody can agree that it would be clearer if the blobs used a licence that clearly allows distribution without requiring source. In the case of the GPL that is definately not clear. About the main issue: As I see it, there are three possible catagories for drivers using firmware that all drivers should ideally fall into assuming the driver part is free : 1. Module and firmware in free. (The firmware can be compiled into the module, or can be loaded from a file.) 2. Module in free, firmware in nonfree, loaded from file by driver. [One could argue that the modules belong ion contrib, unless the firmware is optional (perhaps allowing access to non-essential features)]. 3. Module in non-free. [Firmware compiled into module, has not yet be seperated into seperate file. This is acceptable, but many of these could be converted to type 2 if somebody puts in the work]. I know we have some modules of type 1. I'm pretty sure we have some modules of type 3. It has not been clear to me if we currently have any modules of type 2. Yes, we do. bluez-firmware and atmel-firmware. Obviously if the infrastucture is not there, that should be fixed. It's there except for d-i. Then we have DI. AIUI D-I curretly lacks support for Type 2 and Type 3 modules. This can definately be fixed, but doing it for etch could delay release. Right. Besides all of that we have quite a few modules with problematic licences. Generally the licence problem is on the firmware, although some might affect the rest of the driver. Some are type-3 style (firmware hard-coded into module, firmware lacking source.)Many of those could be shipped as type-3 modules if licence clarification can be obtained (or preferable: relicencing). A few are type-2 style, they could be shipped as type-2 if proper clarification can be obtained. The above is a rough summer of the problems as I understand it. Please correct be if I am wrong. That's all correct. So the question I have is how long would etch need to be delayed to add support for non-free firmware to D-I? Joey Hess estimated 6 months work, but that was to implement a whole bunch of uncommon special cases. I think it is totally unnecessary to implement all, or even any, of those. http://lists.debian.org/debian-vote/2006/08/msg00122.html For (2) from that post, which is the key sticking point for d-i, it needs to be done anyway, and honestly should not take more than a month if someone bothers. So -- point me to the correct parts of the installer. I don't know where to find this anna. libdebian-installer I'm looking at -- it would be a great help if someone could direct me to the part of the code which loads udebs from disk/network, because I can't find it. Is that all in 'anna', which I can't find? :-/ If I can't find the source code for 'anna', I can't fix it. (3) is trivial and simply requires the will to fix RC bugs. (4) is frankly not nearly as important as Joey makes it out to be. It is very unlikely that someone will have a machine where *both* the CD *and* the NIC *and* the floppy drive if present *and* the USB driver (USB key) need non-free firmware. As long as there is one piece of hardware with fully free drivers which can be used to load the additional non-free material on the machine, it is perfectly tolerable that an alternate piece of hardware is not so supported. (I've seen systems where the NIC needed non-free firmware downloaded and ones where the CD did, but never ones where both did.) I know it's theoretically possible that someone will buy a hell machine where every single peripheral requires a non-free firmware download -- but it's unlikely. And if that happens, they can still use the hard drive method or master their own CD. We could also
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Sven Luther wrote: Since the firmware blobs are not derivative works of the kernel, but constitute mere agregation in the same binary format, the authors of other pieces of GPLed code fo the linux kernel cannot even sue us for distributing the kernel code with those GPL-violating binary BLOBs. This is not clear in the cases where the blobs are embedded directly into the kernel, particularly when they're embedded in the same source files. There's a case to be made that this is *not* mere aggregation, but creation of an enhanced combination work which is derivative of both the firmware and the other parts of the kernel. Simply putting files side by side is mere aggregation -- what's happening with the drivers and firmware might be mere aggregation, but nobody can be sure until a court case happens. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Steve Langasek wrote: On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: Debian needs to make a decision on how it will deal with this legal minefield. That is higher priority than the entire discussion going on right now, because it determines whether Debian will distribute these 53 BLOBs *at all*, in 'main' or in 'non-free'. Oddly enough nobody has proposed a GR addressing this, Because voting is an absurd means of settling questions of legal liability. It's the domain of the ftp team to determine whether we can legally distribute a package on our mirrors. Actually, letting an overworked team of four with (to my knowledge) zero legal expertise settle questions of legal liability is pretty absurd too. I know this is Debian tradition, but it's worth thinking about whether it really makes sense. Debian-legal has very little legal expertise, and as a result the consensus errs on the side of caution at essentially all times with regard to copyright. Probably too much caution, but without getting an actual legal opinion, that seems like the right thing to do. Should the ftpmasters, who have even less legal expertise, ever take the risk of erring on the side of recklessness? (This risk is currently being taken with the mislicensed 'firmware' BLOBs.) Does this expose anyone but the ftp team to legal liability? Now, if the rest of Debian has repeatedly disavowed all responsibility, it may be that the ftp team and only the ftp team are *personally* liable if Debian makes an illegal distribution, and in that case it would make sense for them to determine such things. I'm not sure the ftpmasters are actually comfortatble with assuming personal legal liability for every package in Debian though. I wouldn't be! -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Wed, Aug 30, 2006 at 08:18:28PM -0400, Nathanael Nerode wrote: Sven Luther wrote: Since the firmware blobs are not derivative works of the kernel, but constitute mere agregation in the same binary format, the authors of other pieces of GPLed code fo the linux kernel cannot even sue us for distributing the kernel code with those GPL-violating binary BLOBs. This is not clear in the cases where the blobs are embedded directly into Please reread the discussion on debian-legal about this, where consensus was mostly found to support this idea, and also remember that we contacted broadcom with this analysis, who contacted their legal team, and i also mailed the FSF lawyers with it, and got no counter-claim to it. the kernel, particularly when they're embedded in the same source files. There's a case to be made that this is *not* mere aggregation, but creation of an enhanced combination work which is derivative of both the firmware and the other parts of the kernel. Simply putting files side by side is mere aggregation -- what's happening with the drivers and firmware might be mere aggregation, but nobody can be sure until a court case happens. Well, in the debian-legal discussion i gave plenty of counter examples, ranging from a firmware flasher (little C program with embedded firmware, exact same case as the kernel situation), to compressed binaries with uncompressing software embedded, passing by filesystem binaries containing both GPLed content as well as non-free content. So, all in all, unless you bring new evidence, there is really very little doubt about this, unless you want to consider your hardware a derived work of the linux kernel, but i doubt a judge will follow you on this one. IANAL, but there is a part of common sense and simple logic in most legal cases. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Toni Mueller wrote: Hello, On Wed, 30.08.2006 at 09:27:21 +0200, Marco d'Itri [EMAIL PROTECTED] wrote: On Aug 30, Nathanael Nerode [EMAIL PROTECTED] wrote: Debian must decide whether it wants to ship BLOBs with licensing which technically does not permit redistribution. At least 53 blobs have this problem. Many of them are licensed under the GPL, but without source code provided. Since the GPL only grants permission to distribute if you provide source code, the GPL grants no permission to distribute in these cases. Many people disagree with this interpretation. Marco trolled again. FYI, no serious person disagrees with this interpretation. From the GPL: 3. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following: a) Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, -- Debian is not doing this for the BLOBs b) Accompany it with a written offer, valid for at least three years, to give any third party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or, -- Debian is not doing this for anything c) Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.) -- Debian is not allowed to do this So Debian isn't satisfying the conditions of clause 3. Therefore, the GPL does not grant Debian permission to distribute the BLOBs in object code or executable form. I'm not a lawyer, but my take on this is that if someone ships you a BLOB under the GPL, you have the legal right to demand sources from him. Unfortunately not. Generally, only a copyright holder can sue for GPL violation. (In contrast, Debian's Social Contract promises that Debian will distribute source code for all the programs in Debian -- so under common law I could sue Debian for false advertising because it isn't distributing source code for some of the programs.) *However*, consider the following case: (1) The driver is written by person A and released properly under the GPL. (2) The firmware is written by corporation B and distributed without source. (3) Either B or person C combines the firmware with the driver to make a single work, and distributes it -- without the source for the firmware. In this case, person A can sue any distributor of the combined work. Arguably, any contributor with copyright in any part of the Linux kernel might be able to sue any distributor of a kernel with firmware in it. Some of the contributors to the kernel are very vociferously against sourceless firmware, and might actually do it. Dropping -vote, setting followups to -legal. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Wed, Aug 30, 2006 at 08:26:56PM -0400, Nathanael Nerode wrote: On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: Debian needs to make a decision on how it will deal with this legal minefield. That is higher priority than the entire discussion going on right now, because it determines whether Debian will distribute these 53 BLOBs *at all*, in 'main' or in 'non-free'. Oddly enough nobody has proposed a GR addressing this, Because voting is an absurd means of settling questions of legal liability. It's the domain of the ftp team to determine whether we can legally distribute a package on our mirrors. Actually, letting an overworked team of four with (to my knowledge) zero legal expertise settle questions of legal liability is pretty absurd too. They are the team responsible for vetting the legality of what's distributed on the mirrors. None of them have any legal expertise to my knowledge; but they do know where the lawyers are if they have questions, and they *are* the ones in the hot seat(s). Should the ftpmasters, who have even less legal expertise, Judging by some of the nonsense that debian-legal is typically riddled with, if I were an ftpmaster I would find that claim insulting. The only claim to expertise that debian-legal has is in the area of analyzing license terms and how they stack up against the requirements of the DFSG. That is an important function, but it is *not* legal expertise. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
[Nathanael Nerode] So -- point me to the correct parts of the installer. I don't know where to find this anna. svn://svn.debian.org/d-i/trunk/packages/anna signature.asc Description: Digital signature
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
Steve Langasek wrote: On Wed, Aug 30, 2006 at 08:26:56PM -0400, Nathanael Nerode wrote: snip Actually, letting an overworked team of four with (to my knowledge) zero legal expertise settle questions of legal liability is pretty absurd too. They are the team responsible for vetting the legality of what's distributed on the mirrors. None of them have any legal expertise to my knowledge; but they do know where the lawyers are if they have questions, Well, that's good! Do they really have the hotline to the lawyers? Excellent! I hope they actually use it occasionally; I've never heard of them doing so, so if they have gotten any legal opinions, they've kept them secret. (Dammit, when Debian developers attempted to get legal advice on trademark policy, it sunk into a black hole. The advice never really came back, after several years.) and they *are* the ones in the hot seat(s). Meaning that they are personally liable and the rest of the Debian developers aren't? :-) I'd love to see a legal opinion from the SPI lawyers regarding who would be liable if Debian did commit copyright infringment (or whatever) and someone sued. It seems to me that the developers have entrusted the ftpmasters with the responsibility of guarding Debian's funds and property against a copyright infringment lawsuit. Is that the general feeling of the developers? Are the ftpmasters comfortable with that responsibility? If so, my proverbial hat is off to them. Should the ftpmasters, who have even less legal expertise, Judging by some of the nonsense that debian-legal is typically riddled with, if I were an ftpmaster I would find that claim insulting. There is at least one laywer who posts regularly. Which counts as some legal expertise, and which is exactly what I was referring to when I said very little. The only claim to expertise that debian-legal has is in the area of analyzing license terms and how they stack up against the requirements of the DFSG. That is an important function, but it is *not* legal expertise. See above. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firmware poll
Hi, -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 6c557439-9c21-4eec-ad6c-e6384fab56a8 [ ] Choice 1: Release etch on time [ 1 ] Choice 2: Do not ship sourceless firmware in main [ ] Choice 3: Support hardware that requires sourceless firmware [ ] Choice 4: None of the above -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- Because freedom is, has been and should be our top-most priority (IMHO). It's too important an issue to make any compromises just because of some short-term nice-to-have goals such as release on time... Don't get me wrong, I'd like to see etch released on time, too; and I also don't have a problem with sourceless firmware (in non-free) as an interim solution until vendors provide free code or at least specs so that free code can be written. But none of these issues are important enough to compromise our ideals or a free distribution. Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org signature.asc Description: Digital signature
Re: Firmware poll
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luk Claes wrote: -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 6c557439-9c21-4eec-ad6c-e6384fab56a8 [ 1 ] Choice 1: Release etch on time [ 3 ] Choice 2: Do not ship sourceless firmware in main [ 2 ] Choice 3: Support hardware that requires sourceless firmware [ ] Choice 4: None of the above -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- [Non-DD opinion] [ x ] Choice 5: Ship *BLOBs* (does *not* mean closed-source drivers like nvidia) that can be legally redistributed, do not ship BLOBs that can not be legally redistributed. Yes, I know BLOBs are, well, binary, but they do *not* run on the system's CPU. They run on little CPUs on PCI cards, in USB devices, etc, etc, etc. Morally, it is the same as a FSF/GNU devotee running a machine that has ROMs and Flash EEPROMs on the mobo, on high-performance NICs, etc. - -- Ron Johnson, Jr. Jefferson LA USA Is common sense really valid? For example, it is common sense to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that common sense is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE9BjjS9HxQb37XmcRAhNJAKCbRTAkua6pMLCmoi6y9QMro/Mq9ACgtA7b vcdcVHaU1Bmr7eOVAPqZfac= =wDRI -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firmware poll
On Tue, 29 Aug 2006 05:37:23 -0500, Ron Johnson wrote: [ x ] Choice 5: Ship *BLOBs* (does *not* mean closed-source drivers like nvidia) that can be legally redistributed, do not ship BLOBs that can not be legally redistributed. Yes, I know BLOBs are, well, binary, but they do *not* run on the system's CPU. They run on little CPUs on PCI cards, in USB devices, etc, etc, etc. Morally, it is the same as a FSF/GNU devotee running a machine that has ROMs and Flash EEPROMs on the mobo, on high-performance NICs, etc. I disagree, or I am not understanding the difference between the two. FSF/GNU devotees would much prefer to use a free BIOS[0] or EEPROM code if they had a choice imho. [0] http://www.fsf.org/campaigns/free-bios.html -- Chris Lamb, Cambs, UK GPG: 0x634F9A20 Q. Why is top posting bad? A. Because it breaks the logical sequence of discussion signature.asc Description: PGP signature
Re: Firmware poll
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chris Lamb wrote: On Tue, 29 Aug 2006 05:37:23 -0500, Ron Johnson wrote: [ x ] Choice 5: Ship *BLOBs* (does *not* mean closed-source drivers like nvidia) that can be legally redistributed, do not ship BLOBs that can not be legally redistributed. Yes, I know BLOBs are, well, binary, but they do *not* run on the system's CPU. They run on little CPUs on PCI cards, in USB devices, etc, etc, etc. Morally, it is the same as a FSF/GNU devotee running a machine that has ROMs and Flash EEPROMs on the mobo, on high-performance NICs, etc. I disagree, or I am not understanding the difference between the two. FSF/GNU devotees would much prefer to use a free BIOS[0] or EEPROM code if they had a choice imho. Yes, they would *prefer* to. So would I. But still... Even RMS uses closed-source binaries. If not the mobo's BIOS, then the video card's BIOS, the NIC's BIOS, etc. I guess I just take the view that mobo card manufacturers are *not* going to release enough detailed specs to allow for every mobo (or even a reasonable percentage of mobos) to have an OSS BIOS. - -- Ron Johnson, Jr. Jefferson LA USA Is common sense really valid? For example, it is common sense to white-power racists that whites are superior to blacks, and that those with brown skins are mud people. However, that common sense is obviously wrong. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE9DXhS9HxQb37XmcRAkzlAKDa5Db2jtmvy23ujFi76BC1pmMMkACfRedP YOQnnvGrry2j8wO2Eb644AU= =ybnT -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Firmware poll
On Tue, Aug 29, 2006 at 01:23:48PM +0100, Chris Lamb wrote: I disagree, or I am not understanding the difference between the two. FSF/GNU devotees would much prefer to use a free BIOS[0] or EEPROM code if they had a choice imho. Yes, and there is a choice, partly already working, partly in the works... See for example http://linuxbios.org/. Uwe. -- Uwe Hermann http://www.hermann-uwe.de http://www.it-services-uh.de | http://www.crazy-hacks.org http://www.holsham-traders.de | http://www.unmaintained-free-software.org signature.asc Description: Digital signature
The bigger issue is badly licensed blobs (was Re: Firmware poll
Ron Johnson wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luk Claes wrote: -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 6c557439-9c21-4eec-ad6c-e6384fab56a8 [ 1 ] Choice 1: Release etch on time [ 3 ] Choice 2: Do not ship sourceless firmware in main [ 2 ] Choice 3: Support hardware that requires sourceless firmware [ ] Choice 4: None of the above -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- [Non-DD opinion] [ x ] Choice 5: Ship *BLOBs* (does *not* mean closed-source drivers like nvidia) that can be legally redistributed, do not ship BLOBs that can not be legally redistributed. It's worth noting for purposes of discussion the actual numbers here. From http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html we find: * 14 free pieces of firmware with source code (great) * 46 drivers requesting BLOBs from userland (OK) * 47 BLOBs which can't be legally redistributed (bad) * 6 addditional BLOBs removed from Debian which can't be legally redistributed (bad) * at least 2 BLOBs (radeon and r128) which appear to be shipped with false copyright statements (bad), but if not, then are distributable. * the 12 keyspan BLOBs, removed from Debian, which have a unique license which makes them distributable in the linux kernel package, but makes it unclear whether they can be legally distributed as an addon package! * 1 BLOB in Debian (emi26) with a license like the keyspan BLOBs. * 9 BLOBs which can definitely be legally redistributed (in five drivers: mga_warp, tg3, typhoon, advansys, qla2xxx). So frankly the output of this entire discussion isn't going to cover very many BLOBs: exactly seven drivers will definitely be allowed to go into or stay in main for etch if 'sourceless firmware' is allowed without other changes. Of those, one (tg3) functions without the BLOBs for most cards and has been converted to userland firmware loading, and one (qla2xxx) has firmware loading code included upstream but disabled -- so those two are among the very easiest cases for moving the BLOBs to non-free. I've also volunteered to work on converting advansys to userland firmware loading, and to test anyone else's advansys conversion. The majority of the BLOBs have serious licensing problems, which won't be addressed by any decision regarding free, non-free, source, or sourceless material. Debian must decide whether it wants to ship BLOBs with licensing which technically does not permit redistribution. At least 53 blobs have this problem. Many of them are licensed under the GPL, but without source code provided. Since the GPL only grants permission to distribute if you provide source code, the GPL grants no permission to distribute in these cases. However, presumably the manufacturers who (in nearly all cases) provided the BLOBs intended them to be distributed -- although they never granted a proper license. (Of course, for all I know perhaps some of the manufacturers were evil geniuses and knew perfectly well they weren't granting a proper license, intending to cause trouble later.) Debian needs to make a decision on how it will deal with this legal minefield. That is higher priority than the entire discussion going on right now, because it determines whether Debian will distribute these 53 BLOBs *at all*, in 'main' or in 'non-free'. Oddly enough nobody has proposed a GR addressing this, and Debian continues to ship 47 improperly licensed files in linux-2.6. If I were SCO, I'd buy up the copyrights to them from the original companies, and then I'd have a real case for a lawsuit. -- Nathanael Nerode [EMAIL PROTECTED] Bush admitted to violating FISA and said he was proud of it. So why isn't he in prison yet?... -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: Debian needs to make a decision on how it will deal with this legal minefield. That is higher priority than the entire discussion going on right now, because it determines whether Debian will distribute these 53 BLOBs *at all*, in 'main' or in 'non-free'. Oddly enough nobody has proposed a GR addressing this, Because voting is an absurd means of settling questions of legal liability. It's the domain of the ftp team to determine whether we can legally distribute a package on our mirrors. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
Re: The bigger issue is badly licensed blobs (was Re: Firmware poll
On Tue, Aug 29, 2006 at 07:17:47PM -0700, Steve Langasek [EMAIL PROTECTED] wrote: On Tue, Aug 29, 2006 at 08:48:00PM -0400, Nathanael Nerode wrote: Debian needs to make a decision on how it will deal with this legal minefield. That is higher priority than the entire discussion going on right now, because it determines whether Debian will distribute these 53 BLOBs *at all*, in 'main' or in 'non-free'. Oddly enough nobody has proposed a GR addressing this, Because voting is an absurd means of settling questions of legal liability. It's the domain of the ftp team to determine whether we can legally distribute a package on our mirrors. So, all in all, all this fuss for seven blobs ? waw, what a waste of time. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Firmware poll
-=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- 6c557439-9c21-4eec-ad6c-e6384fab56a8 [ 1 ] Choice 1: Release etch on time [ 3 ] Choice 2: Do not ship sourceless firmware in main [ 2 ] Choice 3: Support hardware that requires sourceless firmware [ ] Choice 4: None of the above -=-=-=-=-=- Don't Delete Anything Between These Lines =-=-=-=-=-=-=-=- Of course I have to choose releasing etch on time first as a RA :-) As I want to have all hardware supported (in some way or another), that's my second option. As I can live with shipping sourceless firmware in main, I put it above NOTA. Cheers Luk -- Luk Claes - http://people.debian.org/~luk - GPG key 1024D/9B7C328D Fingerprint: D5AF 25FB 316B 53BB 08E7 F999 E544 DE07 9B7C 328D signature.asc Description: OpenPGP digital signature
