Re: Proposal: The DFSG do not require source code for data, including firmware
On Sat, Sep 02, 2006 at 09:46:32PM +0200, Wouter Verhelst wrote: On Tue, Aug 29, 2006 at 12:01:55AM +0200, Sven Luther wrote: He has full control of it, in the sense that it is often binary only, and that he produces it, and not some third party (like the operating system vendor). Also, i believe that modifying the firmware, like you propose, usually voids the waranty. Replacing a supplied operating system by something totally different (like, say, Debian) often also voids warranty (or, at least, the right to tech support). How is that any different? Well, hosing the firmware, and thus the method to reflash or bootup the board results more often than not in an unusable piece of hardware. Changing the operating system loaded by said firmware is not so dramatic, as you can always fix it and stuff. This is not the case for firmware usually, unless you know what you do, and have some heavy soldering or on-site flashing equipement. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 29, 2006 at 12:01:55AM +0200, Sven Luther wrote: He has full control of it, in the sense that it is often binary only, and that he produces it, and not some third party (like the operating system vendor). Also, i believe that modifying the firmware, like you propose, usually voids the waranty. Replacing a supplied operating system by something totally different (like, say, Debian) often also voids warranty (or, at least, the right to tech support). How is that any different? -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 29, 2006 at 03:07:11PM +0200, Sven Luther wrote: On Tue, Aug 29, 2006 at 11:00:44PM +1000, Hamish Moffatt wrote: To those who consider ROM-less hardware cheap and nasty I suggest the opposite is true. I design hardware (FPGAs) professionally for expensive communications equipment. We avoid ROMs as much as possible, because they are difficult to upgrade reliably and they are a waste of money. We deliberately load our FPGAs with different functionality at different times and that isn't possible from ROM. The emi62.c sound driver seems to do something similar - it loads different firmware for midi and spdif modes! Very interesting. Do you consider FPGA config files as programs, or would you say that the normal DFSG requirement for source applies to those also in order to be considered fit for debian/main ? Aren't these two alternatives the same? I am interested in your profesional opinion on this, since you clearly seem to either be, or in close contact to someone who is, an upstream author of such firmwares. In any case, they are not programs (there is no sequential operation, no program counters etc) but data that gets loaded into memory circuits (SRAM) inside the physical device. However they do have source code (Verilog and VHDL are the relevant languages). The hex dumps in the drivers are not only not the preferred form, they are in fact useless for modification. The vendors don't even publish the format of that information. There are no free tools for rebuilding those images, though that isn't an excuse in itself. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 30, 2006 at 12:13:32AM +0200, Sven Luther wrote: On Tue, Aug 29, 2006 at 10:07:55PM +0100, Mark Brown wrote: Speaking as someone with experience of the software rather than hardware side of this I'd call FPGA images hardware. From the point of view of working with it it looks very much like hardware. That's just my opinion, though. Well, but it is stuff with sources. You could argue that actual hardware also has sources (the design document, schematics and routing files) though. That's true, but software also has design documentation and we don't require that to be distributed to meet the DFSG. Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
[EMAIL PROTECTED] wrote: So I think the real question is How does us refusing to ship non-free firmware help free software?. WE'RE NOT CONSIDERING DOING THAT. I hate to shout, but *have* you heard of non-free? It was mentioned in the post you're replying to! I did. And it's not part of Debian. I am interested in working on Debian, not in Debian + other repositories. (Especially if their purpose is distribution of random proprietary programs.) -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Joey Hess wrote: 1. The archive did not support a non-free section for udebs until today. Done. 2. libd-i and anna do not support multiple udeb sources, but can only pull from one at a time; noone has yet fixed this mrvn pointed out that true multiple source support isn't needed for this (though it would be very nice for other things). Actually, at least net-retriever already supports multiple suites. 3. The Debian kernel does not currently have non-free firmware separated into different packages. 4. Numerous installation cases become much more complex assuming the above is all implemented. Examples: -- see shy jo signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 31, 2006 at 05:55:43PM -0400, Joey Hess wrote: Joey Hess wrote: 1. The archive did not support a non-free section for udebs until today. Done. 2. libd-i and anna do not support multiple udeb sources, but can only pull from one at a time; noone has yet fixed this mrvn pointed out that true multiple source support isn't needed for this (though it would be very nice for other things). Actually, at least net-retriever already supports multiple suites. Actually, it was Nathanael Nerode which pointed this out in [EMAIL PROTECTED]. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Matthew Garrett wrote: Bernhard R. Link [EMAIL PROTECTED] wrote: We are giving a promise here, that with the stuff in our distribution you have the freedom to use it, to give it to others and to fix it. This means the missing of legal obstacles and the possibility to do so. For this discussion preferred form of modification is perhaps not the best definition. It's good for licenses as it is not easily to work around. I think here the difference is between the source being in a form practical to edit or not. Without a practical form there is no possibility to change it. And this is a limitation we have to make clear to people and not lock them into by claiming all is good and well and it could be part of our free operating system. We never included non-free applications in main because we felt that there was no need to. And, indeed, even in 1993 it was possible to use a computer without any non-free applications. That doesn't hold with the firmware argument. With applications, we had the choice between Free but less functional and Non-free but more functional. With firmware we have the choice between Non-free but on disk and Non-free but in ROM. There isn't a Free option at all yet. Except for those cases where there is, such as adaptec, ser_a2232, ixp2000, wanxlfw, atmel, 53c700, 53c7xx, aic7xxx, sym53c8xx_2, and keyspan_pda. Yes, that includes a very common SCSI card and a very common NIC. So I think the real question is How does us refusing to ship non-free firmware help free software?. WE'RE NOT CONSIDERING DOING THAT. I hate to shout, but *have* you heard of non-free? It was mentioned in the post you're replying to! well, we are considering doing it in the cases where the firmware is *improperly licensed*. There, the benefit is (a) not getting sued and protecting downstream from liability, (b) clearly respecting copyright holders and respecting their stated desires. -- 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: Proposal: The DFSG do not require source code for data, including firmware
MJ Ray wrote: I think the idea that refusing to ship non-free firmware in main will strengthen demand for free firmware is worthy of consideration. Debian helps users to take control of their operating system. Increasing the demand for free firmware might also help users to take control of their hardware, or at least highlight that there's this crap which their operating system uses to support their hardware but doesn't have its normal freedoms. However, I'm undecided whether it's a good idea to exclude them from the distribution CDs and so on. How big is the problem of vital hardware which won't work without firmware being copied to it? Complete list at http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html, with details. What that list does *not* show is that certain drivers only need firmware loaded for some of their supported cards. In the case of tg3, only a few rare (and old) cards actually need the firmware loaded. Should we split non-free into non-free-hardware and non-free, allowing non-free-hardware packages onto the CDs? Should we allow certain non-free material onto the installation CDs? Actually, that would be an compromise OK with me: the installation CDs only get used the once, and the material would be clearly separated out into the non-free section during and after installation. Doesn't address the legal issue of whether material without a proper distribution license should be included. -- 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: Proposal: The DFSG do not require source code for data, including firmware
Matthew Wilcox wrote: On Wed, Aug 23, 2006 at 02:44:48PM +0200, Sven Luther wrote: On Wed, Aug 23, 2006 at 06:08:08AM -0600, Matthew Wilcox wrote: I think the key distinction (as far as I'm concerned) is that Debian isn't producing a distribution for the microcontroller in my fibrechannel card, it's producing a distribution for my computer. In order to make my fibrechannel card work, it has to poke some bits in a documented way. Even if there happens to be an ARM onboard that card that's running a program, that ARM isn't running Debian. One of the purposes of having access to the prefered form of modification, is to be able to fix bugs. Certainly, it's one of the purposes. But I don't think we've *lost* anything by distributing binary firmware. Certainly not. That's what non-free is for, and I am in full support of distributing binary-only firmware in non-free. As long as it's properly licensed, which most of the stuff at issue isn't. :-/ Consider the cases: 1. Everything in hardware. You're not able to fix anything without a soldering iron ... and good luck to you with that. 2. Unmodifiable firmware in EEPROM. Need an EEPROM programmer, and a good deal of skill to fix anything. Again, best of luck. 3. Binary-only firmware in the driver. Slightly better chance of trying to figure out what's going on, but still low. 4. Firmware source in non-preferred form. Modifications probably possible, but when the next round of changes come out from the vendor, you probably have to ditch your mods. 5. Firmware source in preferred form. Can send changes back to vendor, everybody wins. (and I'm sure people can think of other finer distinctions). You seem to want to disallow cases 3 and 4 ... in main. Non-free exists for this. which makes sense from a here are the rules of data freedom, now i must follow them point of view, but really don't make sense to the vendor, nor to the user. It seems like an all-or-nothing approach. Well, if you don't realize that non-free exists to make exactly this compromise. -- 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: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 29, 2006 at 09:28:56AM +0200, Mike Hommey wrote: On Tue, Aug 29, 2006 at 12:47:42AM +0200, Sven Luther [EMAIL PROTECTED] wrote: On Mon, Aug 28, 2006 at 03:25:05PM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: The idea is that the firmware is all the software and other softwarish information which the vendor provides to make use of the board he sells you. I see. If I buy a standard-issue Dell computer, then Windows is firmware, right? (Dell does provide it, for the purpose of making full use of the computer.) The BIOS is, not windows, since it is coming from a third party, namely microsoft, and furthermore, the drivers are also not it. The BIOS is usually coming from Phoenix or some similar company, i.e. a third party. The framework of it maybe, but it is tailored to the board, doing the low level initialization of things like the ram controler, the layout off the different buses in main memory and stuff like that. The important thing is that even if there is a common base for the code, it is modified to fit the board, and contains information about the boards layout (what chip is connected where and so on), and that it will come from the board vendor and not from a third party. For example, if you want to upgrade your bios on your random motherboard, you don't go to microsoft, and you don't go to phoenix or similar, but you go to asus or whoever made your board to download the upgraded firmware and its flash tool. The firmware is linked to the layout of the flash chip holding it, and the boot method chosen for the board, and is thus done by the same folk who do the schematics for the board, and produce it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 29, 2006 at 12:47:42AM +0200, Sven Luther [EMAIL PROTECTED] wrote: On Mon, Aug 28, 2006 at 03:25:05PM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: The idea is that the firmware is all the software and other softwarish information which the vendor provides to make use of the board he sells you. I see. If I buy a standard-issue Dell computer, then Windows is firmware, right? (Dell does provide it, for the purpose of making full use of the computer.) The BIOS is, not windows, since it is coming from a third party, namely microsoft, and furthermore, the drivers are also not it. The BIOS is usually coming from Phoenix or some similar company, i.e. a third party. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 08:03:39PM +0100, Mark Brown wrote: Within a Debian context people normally seem to use the term firmware to mean any binary blob that gets programmed into hardware. This could include things like register settings or FPGA images as well as programs to execute on embedded processors. I'm not sure if there are any instances of these other types in the upstream kernel, though. FWIW (and a few days late) I did some searching for drivers in the kernel (2.6.17.11 from kernel.org) which refer to FPGAs and found the following: drivers/usb/atm/ueagle-atm.c drivers/media/video/bt8xx/bttv-cards.c sound/pci/vx222/* sound/pcmcia/vx/* sound/pci/pcxhr/* sound/pci/mixart/* sound/drivers/vc/* -- These load image via the standard kernel interface (hotplug) drivers/media/video/stradis.c drivers/net/wan/lmc/* -- Loads FPGA image supplied by an ioctl drivers/net/hamradio/yam.c -- Loads firmware from const arrays in yam*.h drivers/net/pcmcia/smc91c92_cs.c -- Loads firmware from const array in ositech.h drivers/usb/misc/emi26.c, emi62.c -- Loads firmware from const array in emi26_fw.h / emi62_fw*.h drivers/isdn/hardware/eicon/* -- Loads firmware from file directly (?) drivers/media/video/dabusb.c -- From file I think. Driver is confusing. arch/sh/boards/overdrive/fpga.c -- Loads from missing file To those who consider ROM-less hardware cheap and nasty I suggest the opposite is true. I design hardware (FPGAs) professionally for expensive communications equipment. We avoid ROMs as much as possible, because they are difficult to upgrade reliably and they are a waste of money. We deliberately load our FPGAs with different functionality at different times and that isn't possible from ROM. The emi62.c sound driver seems to do something similar - it loads different firmware for midi and spdif modes! Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 29, 2006 at 11:00:44PM +1000, Hamish Moffatt wrote: To those who consider ROM-less hardware cheap and nasty I suggest the opposite is true. I design hardware (FPGAs) professionally for expensive communications equipment. We avoid ROMs as much as possible, because they are difficult to upgrade reliably and they are a waste of money. We deliberately load our FPGAs with different functionality at different times and that isn't possible from ROM. The emi62.c sound driver seems to do something similar - it loads different firmware for midi and spdif modes! Very interesting. Do you consider FPGA config files as programs, or would you say that the normal DFSG requirement for source applies to those also in order to be considered fit for debian/main ? I am interested in your profesional opinion on this, since you clearly seem to either be, or in close contact to someone who is, an upstream author of such firmwares. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Thomas Bushnell BSG [EMAIL PROTECTED] writes: Steve Langasek [EMAIL PROTECTED] writes: 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. I am bothered that there is never a definition of firmware here. Please note in this subthread, that Steve ist talking about ``device firmware'', whereas this subthread is talking about ``firmware'' in general. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 29, 2006 at 03:54:13PM +0200, Reinhard Tartler wrote: Thomas Bushnell BSG [EMAIL PROTECTED] writes: Steve Langasek [EMAIL PROTECTED] writes: 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. I am bothered that there is never a definition of firmware here. Please note in this subthread, that Steve ist talking about ``device firmware'', whereas this subthread is talking about ``firmware'' in general. And note how the line blurs when you consider a peripheral firmware which is using the same set of chips which would be also used in standalone devices. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Sven Luther [EMAIL PROTECTED] writes: Please note in this subthread, that Steve ist talking about ``device firmware'', whereas this subthread is talking about ``firmware'' in general. And note how the line blurs when you consider a peripheral firmware which is using the same set of chips which would be also used in standalone devices. I don't think I really understand this sentence. I assume for now that you mean with ``peripheral firmware'' what Steve means with ``device firmware''. Let me try to describe what you mean: Given a hardware device, which is commonly used as peripheral device for a computer system. This hardware device happens to have enough ram, rom and peripherial on its own, so that it could run as a ``standalone device''. In this case, you could make use of source of the sourceless ``device firmware'' in question for your own programms on the ``standalone device''. In case I'm right: WTF?! Can you please give me some concrete examples of devices which can be used both as ``peripherial'' as well as ``standalone''? In case I'm wrong, please clarify. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 29, 2006 at 04:50:45PM +0200, Reinhard Tartler wrote: Sven Luther [EMAIL PROTECTED] writes: Please note in this subthread, that Steve ist talking about ``device firmware'', whereas this subthread is talking about ``firmware'' in general. And note how the line blurs when you consider a peripheral firmware which is using the same set of chips which would be also used in standalone devices. I don't think I really understand this sentence. I assume for now that you mean with ``peripheral firmware'' what Steve means with ``device firmware''. Let me try to describe what you mean: Given a hardware device, which is commonly used as peripheral device for a computer system. This hardware device happens to have enough ram, rom and peripherial on its own, so that it could run as a ``standalone device''. In this case, you could make use of source of the sourceless ``device firmware'' in question for your own programms on the ``standalone device''. In case I'm right: WTF?! Can you please give me some concrete examples of devices which can be used both as ``peripherial'' as well as ``standalone''? Let's say i have a wireless chip, which includes a pci interface which can be either host or device, a wireless interface to some antenas, an arm core, some ram and flash. This chip can be used to put the pci in device mode and make a pci add-in card, or it could be used to put the pci in host mode, and connect a ethernet port on it, and create a standalone wifi access point device, which is totally independent. The same (or similar) firmware would run on both cases, in the pci card example, it would be a device firmware, while in the standalone device, the firmware would be considered as a bios or generic firmware. This is not a 100% real example, since i am not aware of a wireless chip with a real pci interface, they usually come with some gpios, usb, or some kind of serial interface, and you would need maybe a bit stronger core than those chips usually use to act as access point, but it is not all that far from reality, and we will assuredly see more of this kind of stuff in the years to come. I hope this clarifies it for you ? Other examples are SATA or SCSI HW RAID device, like the AMCC/3WARE one, which include a IO-processor which is in turn a powerpc 40x or 44x based core, which you could turn into a standalone device all by itself. Or other HW RAID card which use some kind of service processor from intel. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Sven Luther [EMAIL PROTECTED] writes: Let's say i have a wireless chip, which includes a pci interface which can be either host or device, a wireless interface to some antenas, an arm core, some ram and flash. [explanations snipped] This is not a 100% real example, since i am not aware of a wireless chip with a real pci interface, they usually come with some gpios, usb, or some kind of serial interface, and below: Other examples are SATA or SCSI HW RAID device, like the AMCC/3WARE one, which include a IO-processor which is in turn a powerpc 40x or 44x based core, which you could turn into a standalone device all by itself. Or other HW RAID card which use some kind of service processor from intel. I'm not sure if its clear, but I think this discussion is about device firmware for hardware which (given existance) can be used in multiple operational modes. Honestly, I find this rather hypothetic (maybe quite academic) and I don't feel that this is what Steve is talking about. Perhaps to wording can be fixed for that. The 2nd example you give is a bit different and hits way better what Steve had in mind: These peripherials (well, better controllers for peripherials but I don't think this matters here) are using non-free software (device firmware) which is in turn used by free software, like a debian operating system. I don't think that anyone here seriously doesn't consider this as what we commongly call ``program''. The relevant part is this: 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. I as non native speaker understand that as this: We of course consider device firmware as programs in general. It is just that for some hardware devices, additional non-free software is needed so that our free software (both applications and device drivers) can be used on this kind of hardware. As we want to serve both of our users and spreading beautiful and usable free software, for some cases [1] we accept that our free software is using some non-free programs on our (peripherial/controlling) devices. For these hardware devices, we support our users and the free software movement by providing them the needed ``device firmware''. We therefore make the clarification that for the purposes of DFSG #2 we special case ``device firmware'' so that for this specific issue, ``device firmware'' is not considered as a program. There are some variations on this which set a limit until we have better infrastructure to separate non-free ``device firmware'' from the kernel and the installer. Please note that I'm not really decided on this matter. This mail may sound biased. If it is, I'm sorry. I really don't know yet what I would vote (if I was allowed to vote, of course). In fact, I'd love to see some better rationale for the quoted point (#4) of the proposed amendment. [1] the case that there we don't have free access to the sources of the ``device firmware'' -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 29, 2006 at 05:49:47PM +0200, Reinhard Tartler wrote: Sven Luther [EMAIL PROTECTED] writes: Let's say i have a wireless chip, which includes a pci interface which can be either host or device, a wireless interface to some antenas, an arm core, some ram and flash. [explanations snipped] This is not a 100% real example, since i am not aware of a wireless chip with a real pci interface, they usually come with some gpios, usb, or some kind of serial interface, and below: Other examples are SATA or SCSI HW RAID device, like the AMCC/3WARE one, which include a IO-processor which is in turn a powerpc 40x or 44x based core, which you could turn into a standalone device all by itself. Or other HW RAID card which use some kind of service processor from intel. I'm not sure if its clear, but I think this discussion is about device firmware for hardware which (given existance) can be used in multiple operational modes. Honestly, I find this rather hypothetic (maybe quite academic) and I don't feel that this is what Steve is talking about. Perhaps to wording can be fixed for that. Well, i am dealing with a wireless chip that can be used in a similar case right now, thus the example, and like said, the wireless situation is way worse than the disk controller or ethernet driver one. The 2nd example you give is a bit different and hits way better what Steve had in mind: These peripherials (well, better controllers for peripherials but I don't think this matters here) are using non-free software (device firmware) which is in turn used by free software, like a debian operating system. I don't think that anyone here seriously doesn't consider this as what we commongly call ``program''. The I wouldn't bet on this. The amount of : firmware are just data claims in this issue is rather important. relevant part is this: 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. I as non native speaker understand that as this: We of course consider device firmware as programs in general. It is just that for some hardware devices, additional non-free software is needed so that our free software (both applications and device drivers) can be used on this kind of hardware. As we want to serve both of our users and spreading beautiful and usable free software, for some cases [1] we accept that our free software is using some non-free programs on our (peripherial/controlling) devices. For these hardware devices, we support our users and the free software movement by providing them the needed ``device firmware''. We therefore make the clarification that for the purposes of DFSG #2 we special case ``device firmware'' so that for this specific issue, ``device firmware'' is not considered as a program. Yeah, but then way not say it clearly, and say that we will make an DFSG exception for firmware, independently of them being programs or not. There are some variations on this which set a limit until we have better infrastructure to separate non-free ``device firmware'' from the kernel and the installer. Please note that I'm not really decided on this matter. This mail may sound biased. If it is, I'm sorry. I really don't know yet what I would vote (if I was allowed to vote, of course). In fact, I'd love to see some better rationale for the quoted point (#4) of the proposed amendment. I think the rationale behind it is : We want to keep the firmware in main, so we say they are not program. [1] the case that there we don't have free access to the sources of the ``device firmware'' Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Steve Langasek [EMAIL PROTECTED] writes: If it's the latter, I maintain that this is precisely the subject matter of the proposed GR; we obviously *don't* have agreement in Debian over what should or should not be considered a program, so I think that's begging the question. However, your proposed amendment declares that firmware should not be considered a program. Can you please tell me what firmware is? I've seen a half dozen definitions tossed around recently, and I haven't a fig of a clue which one you mean: 1) A program which runs on a peripheral processor 2) A program which is distributed by the hardware manufacturer 3) A program which is controlled by the hardware manufacturer 4) A program which runs out of NVRAM or ROM instead of RAM 5) A program which, if you change it, voids the warranty for the hardware on which it runs, 6) A program which is necessary to support a piece of device hardware and for which we don't happen to have source I can't properly evaluate or think about this amendment while this rather crucial element remains unresolved. Also, it would seem very bizarre to say a program which ... is not really a program, so can you find a wording in which you don't define firmware as a particular sort of program, only to then declare that programs of that sort aren't really programs at all? Yes, these are reasonable definitions of both program and firmware. What is the definition of firmware which you are using? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Sven Luther [EMAIL PROTECTED] writes: relevant part is this: 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. I as non native speaker understand that as this: [...] Yeah, but then way not say it clearly, and say that we will make an DFSG exception for firmware, independently of them being programs or not. I'm not sure if Steve really meant it the way I rephrased it, but I think it is. Of course there could be some more clear wording on this, right. In fact, I'd love to see some better rationale for the quoted point (#4) of the proposed amendment. I think the rationale behind it is : We want to keep the firmware in main, so we say they are not program. This is the motive, but not the rationale why we (can) make such an exception. -- Gruesse/greetings, Reinhard Tartler, KeyID 945348A4 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 29, 2006 at 03:07:11PM +0200, Sven Luther wrote: On Tue, Aug 29, 2006 at 11:00:44PM +1000, Hamish Moffatt wrote: To those who consider ROM-less hardware cheap and nasty I suggest the opposite is true. I design hardware (FPGAs) professionally for expensive communications equipment. We avoid ROMs as much as possible, because they are difficult to upgrade reliably and they are a waste of money. Do you consider FPGA config files as programs, or would you say that the normal DFSG requirement for source applies to those also in order to be considered fit for debian/main ? I am interested in your profesional opinion on this, since you clearly seem to either be, or in close contact to someone who is, an upstream author of such firmwares. Speaking as someone with experience of the software rather than hardware side of this I'd call FPGA images hardware. From the point of view of working with it it looks very much like hardware. That's just my opinion, though. I'd also observe that newer FPGA chips often feature encryption support: the hardware has a secret key blown into it during manufacturing which must be used when building FPGA images to be loaded onto the hardware. -- You grabbed my hand and we fell into it, like a daydream - or a fever. signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 29, 2006 at 10:07:55PM +0100, Mark Brown wrote: On Tue, Aug 29, 2006 at 03:07:11PM +0200, Sven Luther wrote: On Tue, Aug 29, 2006 at 11:00:44PM +1000, Hamish Moffatt wrote: To those who consider ROM-less hardware cheap and nasty I suggest the opposite is true. I design hardware (FPGAs) professionally for expensive communications equipment. We avoid ROMs as much as possible, because they are difficult to upgrade reliably and they are a waste of money. Do you consider FPGA config files as programs, or would you say that the normal DFSG requirement for source applies to those also in order to be considered fit for debian/main ? I am interested in your profesional opinion on this, since you clearly seem to either be, or in close contact to someone who is, an upstream author of such firmwares. Speaking as someone with experience of the software rather than hardware side of this I'd call FPGA images hardware. From the point of view of working with it it looks very much like hardware. That's just my opinion, though. Well, but it is stuff with sources. You could argue that actual hardware also has sources (the design document, schematics and routing files) though. I'd also observe that newer FPGA chips often feature encryption support: the hardware has a secret key blown into it during manufacturing which must be used when building FPGA images to be loaded onto the hardware. Nice. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Michael Poole wrote: I'm not going to argue with your previous points, which are all basically accurate. Related to (a), current programmable hardware cannot run *any* CPU at speeds that most users would accept for desktop use. However, solving that issue simply requires training users to expect even less function[1]. There is a rather subtle, but vital, point here which you appear to be missing. Debian supports users of non-free software, and will continue to. The goal is to make it *possible* to run Debian on a fully free system. The goal is certainly *not* to make a fully free system a *requirement* for Debian. In other words: If Debian is running on *one* fully free system, then the Debian system doesn't require the use of non-free components. You may prefer to use non-free components, however, and the Debian system should retain compatibility with/support for them as long as developers are willing to do so. It seems like this option is more palatable to Debian than helping users get the most function for their hardware and time investment. That statement is a strawman given what I just pointed out above. We understand that at any given time before the utopian free software world of the far future, there will probably be components where the free alternatives perform worse than the non-free ones. Most users will use a combination of the Debian system and a few non-free components, as they do now. If they start getting irritated with the non-free components, they may switch to the free alternatives, and/or try to improve them. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFE9M9jRGZ0aC4lkIIRApOZAJ90zk7TlcKU11FV1muKTa63XZUZawCcCNLf dMpFEZyGbeo50SMf6Wclwfw= =IPMP -END PGP SIGNATURE- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: late for party (was Re: Proposal: The DFSG do not require source code for data, including firmware)
Marco d'Itri [EMAIL PROTECTED] [...] de Raadt firmware I have found: http://www.theage.com.au/articles/2004/10/29/1098992287663.html And http://kerneltrap.org/node/6550: Thanks. (Neither were in the OpenBSD list archives...) -- 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: Proposal: The DFSG do not require source code for data, including firmware
I think it is ludicrous to pretend that firmware is not a program. Suppose we had in our possession the source code and an assembler for it. Surely then it would be obviously a program. thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Steve Langasek [EMAIL PROTECTED] writes: 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. I am bothered that there is never a definition of firmware here. It seems to me that if you gave one, it would be something like: firmware is a program which runs on a secondary CPU inside the computer. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Steve Langasek [EMAIL PROTECTED] writes: As you and I discussed previously on IRC, I don't agree with this amendment. The premise of my proposal is that we are *not* granting an exception nor redefining any terms, we are merely recognizing a latent definition of programs that has guided Debian since its inception in spite of standing in contrast to the dictionary definition of the word. In other words, Debian has been redefining the word from day one, dishonestly using the word program to mean something much narrower. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Sven Luther [EMAIL PROTECTED] writes: Notice that the bios or other firmware used on most machines today is also refered as firmware. The original definition is, i believe, any kind of code provided by the vendor of said device, and on which he has full control, so firmware was non-free by definition originally. How does the vendor of a device have full control over what firmware I choose to load into it? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Mon, Aug 28, 2006 at 02:26:42PM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: Notice that the bios or other firmware used on most machines today is also refered as firmware. The original definition is, i believe, any kind of code provided by the vendor of said device, and on which he has full control, so firmware was non-free by definition originally. How does the vendor of a device have full control over what firmware I choose to load into it? Maybe bad phrasing. The idea is that the firmware is all the software and other softwarish information which the vendor provides to make use of the board he sells you. He has full control of it, in the sense that it is often binary only, and that he produces it, and not some third party (like the operating system vendor). Also, i believe that modifying the firmware, like you propose, usually voids the waranty. The main definition would be something like : all software support part that comes from the hardware vendor, to enable or drive or whatever the hardware he sells you, and which is not part of the operating system. Drivers don't fall in this category because it is part of the operating system, but the bios, and other such do. /me does firmware writing for living. I am also investigating going into hardware manufacturing, and preferably in hardware with full free firmware, but having to deal with the chip vendors, i can guarantee you that this is not an easy thing to do, especially for those wireless and bluetooth and whatever chips out there, where the primary market are cell phones, and even high volume pc markets are only a drop of water in comparison. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Mon, Aug 28, 2006 at 02:23:10PM -0700, Thomas Bushnell BSG wrote: Steve Langasek [EMAIL PROTECTED] writes: 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. I am bothered that there is never a definition of firmware here. It seems to me that if you gave one, it would be something like: firmware is a program which runs on a secondary CPU inside the computer. And that would be false, since the firmware was originally something refering to the bios or other enablement software for hardware boards. This is a definition present in terms like OpenFirmware (IEEE 1275), and also in various hardware manufacturer documentation, the x86 bios being an example of such firmware. In cases like hte NLSU thingy, the firmware goes to include the whole linux + userland stack on top of whatever they use for booting, since it is held in the flash of the board. I suppose that in the OneLaptopPerChild project, which holds a 512MB flash disk, the system will also be able to be labeled firmware, not sure if they will use this word. In this sense, the firmware uploaded to a wireless or bluetooth chip, most of them holding an arm core, is very similar to a uclinux or even fully fledged linux running on a cell phone or other embedded device. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Sven Luther [EMAIL PROTECTED] writes: In cases like hte NLSU thingy, the firmware goes to include the whole linux + userland stack on top of whatever they use for booting, since it is held in the flash of the board. Wow. I thought that doesn't run on the main CPU was entirely indefensible. It hadn't occurred to me that there is a definition which is even *worse*: runs out of NVRAM instead of DRAM. Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Sven Luther [EMAIL PROTECTED] writes: The idea is that the firmware is all the software and other softwarish information which the vendor provides to make use of the board he sells you. I see. If I buy a standard-issue Dell computer, then Windows is firmware, right? (Dell does provide it, for the purpose of making full use of the computer.) He has full control of it, in the sense that it is often binary only, and that he produces it, and not some third party (like the operating system vendor). Also, i believe that modifying the firmware, like you propose, usually voids the waranty. Oh, so because the OEM can't modify Windows it's not firmware. But if I buy a Dell PC that comes with Red Hat installed, it *is* something Dell can modify, so then it is firmware? all software support part that comes from the hardware vendor, to enable or drive or whatever the hardware he sells you, and which is not part of the operating system. Um, this is not a definition. The whole point of a definition is to describe what is firmware and what is the operating system. When I suggest that there is no good principled definition, you can't counter by definining firmware as essentially whatever is not part of the operating system. Pretend I don't have any idea what this word firmware is or operating system. I'm familiar with programming and all that, just not with these words. Can you explain the distinction in a noncircular way? Thomas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Mon, Aug 28, 2006 at 03:21:35PM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: In cases like hte NLSU thingy, the firmware goes to include the whole linux + userland stack on top of whatever they use for booting, since it is held in the flash of the board. Wow. I thought that doesn't run on the main CPU was entirely indefensible. It hadn't occurred to me that there is a definition which is even *worse*: runs out of NVRAM instead of DRAM. Nope, it could just as well be decompressed into RAM from the flash. Basically, it is all software (largest sense) which is provided by the hardware vendor, as board support software. Firm = Vendor for this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Mon, Aug 28, 2006 at 03:25:05PM -0700, Thomas Bushnell BSG wrote: Sven Luther [EMAIL PROTECTED] writes: The idea is that the firmware is all the software and other softwarish information which the vendor provides to make use of the board he sells you. I see. If I buy a standard-issue Dell computer, then Windows is firmware, right? (Dell does provide it, for the purpose of making full use of the computer.) The BIOS is, not windows, since it is coming from a third party, namely microsoft, and furthermore, the drivers are also not it. It depends. Like said, the NLSU considers all the linux+userland as firmware. He has full control of it, in the sense that it is often binary only, and that he produces it, and not some third party (like the operating system vendor). Also, i believe that modifying the firmware, like you propose, usually voids the waranty. Oh, so because the OEM can't modify Windows it's not firmware. But if I buy a Dell PC that comes with Red Hat installed, it *is* something Dell can modify, so then it is firmware? The firmware comes from the original hardware manufacturer, so not dell, but whoever builds boards for dell. That is the link, it is the same guys who do the hardware, and provide the most basic support, often as closed source, to the OEM or whoever else may use it. all software support part that comes from the hardware vendor, to enable or drive or whatever the hardware he sells you, and which is not part of the operating system. Um, this is not a definition. The whole point of a definition is to describe what is firmware and what is the operating system. When I suggest that there is no good principled definition, you can't counter by definining firmware as essentially whatever is not part of the operating system. :) Pretend I don't have any idea what this word firmware is or operating system. I'm familiar with programming and all that, just not with these words. Can you explain the distinction in a noncircular way? Like said, it is all the hardware enablement software that is provided by the original hardware manufacturer as part of the hardware bundle. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
[EMAIL PROTECTED] wrote: I think it is ludicrous to pretend that firmware is not a program. I am not sure, it's not very funny to me. But it worked pretty well until you and a few other people started pretending we have been confused for all these years and actually meant something else. Suppose we had in our possession the source code and an assembler for it. Surely then it would be obviously a program. So what? -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Nathanael Nerode writes: If you want to amend the DFSG to state 3. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. However, this requirement does not apply to firmware, defined as insert your pet exemption here. I would strongly oppose such a change, but it would be a legitimate, reasonable GR (requiring 3:1 supermajority of course). Recent history -- in particular, GR 2006-001's winning option -- suggests that broad DFSG exemptions, when treated as clarifications or interpretations of the project, are not necessarily so clear-cut about requiring a 3:1 supermajority. Michael Poole -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Manoj Srivastava wrote: On Tue, 22 Aug 2006 15:18:04 -0700, Steve Langasek [EMAIL PROTECTED] said: snip 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. This would require us to amend the foundation document of the DFSG, and define that what Debian defines as software program is different from the common definitions of the term In order for us to have a meaninglul foundation document, we can't debate and use our own special definitions of common terms, since the definition in turn uses words that can be defined in a special fashion. So, unless otherwise stated, the foundation document terms refer to commonly understood meanings of words; looking to dictionaries, encyclopedias, and common references. Calling firmware not programs is our own special definition of firmware, and or program, and hence must be defined explicitly in the DFSG. If we want to state that we only consider certain programs to be free, we ought to be upfront and clear about it in our foundation document. 110% in agreement with Manoj. Q: How many legs does a dog have, if you call the tail a leg? A: Four. Calling the tail a leg doesn't make it one. (Attributed to Abraham Lincoln.) I fail to see any way in which an executable MIPS binary is not a program, by any definition. If you want to amend the DFSG to state 3. Source Code The program must include source code, and must allow distribution in source code as well as compiled form. However, this requirement does not apply to firmware, defined as insert your pet exemption here. I would strongly oppose such a change, but it would be a legitimate, reasonable GR (requiring 3:1 supermajority of course). In contrast, clause 4 of Steve Langasek's proposal is a backhanded and not very forthright way of trying to change the DFSG without changing them. Steve, you're better than this: please fix your proposal to do the straightforward thing. manoj -- 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: Proposal: The DFSG do not require source code for data, including firmware
Manoj Srivastava wrote: Indeed, all the references I have found tell me that firmware is computer programs. Interesting, as I note that *none* of those you quoted do so -- although some do say that it is software that is stored in less-volatile storage than RAM. Given the scale of the discussion that we had about the definition of software, I think it's probably unwise to equate it to programs in this situation! Cheers, Nick -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: late for party (was Re: Proposal: The DFSG do not require source code for data, including firmware)
Kurt Roeckx wrote in http://lists.debian.org/debian-vote/2006/08/msg00205.htm I'm not sure about those 46 that already use request_firmware() I see no reason to take them out. I listed them as a measure of success, at least with recently added drivers. It would be interestig to know if any of those other 46 are currently in non-free, or what their license is. I don't understand the question. If you are asking about how a debian user should get the firmware needed by those 46 request_firmware()-ified drivers, I can only answer for a few cases. There is support for the ipw3945 and some qlogic adapters in firmware-nonfree (a package in experimental). I have not tested this myself. Bill Allombert wrote in http://lists.debian.org/debian-vote/2006/08/msg00225.html I consider a lack of licence or license prohibiting modification to be much more problematic that a lack of source. In my inventory, many files with firmware in them did not themselves include a license. In those cases, I chose to assume that its license followed the file that #included or otherwise used the data. I had made research on the topic of binary blob in linux 2.4.18 in the past I thank you for that! It was a good starting point, and I reference your work. I don't remember seeing a single firmware with all of: 1) A detailed copyright notice. (Not just a blob put inside a GPL file without any hint about how the blob was derivated and who actually wrote it). 2) A license that allows redistribution without source (i.e not the GPL) 3) A license that allows modification, redistribution and all of DFSG 1,3-10. 4) No source available. Most of the 59 sourceless-firmware-contaminated files I found do not pass all your tests, mostly (44 of them) because they are (at least superficially) GPL'd. The cases that pass all your tests the best are: drivers/net/tg3.c drivers/net/typhoon-firmware.h drivers/scsi/advansys.c In addition, the drivers/scsi/qla2xxx/ql*_fw.c files do pretty well, except the Linux kernel managed to not include the required LICENSE.qla2xxx file. If they (we) did, its terms are acceptable for non-free. The conclusion is that the proposed GR would have had little effect on linux 2.4.18. I think the point of Steve's GR is to allow distribution of the sourceless-firmware-contaminated files that are GPL'd. To me, that's intrinsically not possible. DD opinions on how to interpret the SC have no bearing on the legal problems of satisfying the terms of the GPL. The fact that Red Hat distributes these files in the Linux kernel is IMHO irrelevant -- they not only have lawyers to evaluate the system, they have lawyers to defend themselves, and a pretty big pot of money with which to settle out of court. OTOH, it might be an interesting experiment for a paying Red Hat customer to ask for the source to drivers/usb/serial/io_fw_boot2.h . Marco d'Itri wrote in http://lists.debian.org/debian-vote/2006/08/msg00204.html And http://kerneltrap.org/node/6550: Theo de Raadt: [...] But in the end, if we wish to support any such devices, we must be practical. We must accept the risk that there is a flaw in the firmware. OK, Marco, you're right on this one. I reread material from Theo, and he does (mistakenly, from my point of view) make a distinction between binary blobs that run on the host processor (which he forbids in OpenBSD) and those that run on peripheral processors (which he calls firmware, and accepts into OpenBSD if they have a suitable license). Note that he doesn't have to deal with GPL'd code to the extent we do, nor is he expected to uphold Debian's SC. - Larry -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
#include hallo.h * Frans Pop [Wed, Aug 23 2006, 02:28:30AM]: Seconded. Also seconded. The application of DFSG#2 to firmware and other data The Debian Project recognizes that access to source code for a work of software is very important for software freedom, but at the same time source is often not a well-defined concept for works other than those traditionally considered programs. The most commonly cited definition is that found in version 2 of the GNU GPL, the preferred form of the work for making modifications to it, but for non-program works, it is not always clear that requiring this source as a precondition of inclusion in main is in the best interest of our users or advances the cause of Free Software: - The author's preferred form for modification may require non-free tools in order to be converted into its final binary form; e.g., some device firmware, videos, and graphics. - The preferred form for modification may be orders of magnitude larger than the final binary form, resulting in prohibitive mirror space requirements out of proportion to the benefits of making this source universally available; e.g., some videos. - The binary and source forms of a work may be interconvertible with no data loss, and each may be the preferred form for modification by different users with different tools at their disposal; e.g., some fonts. While the Debian Free Software Guidelines assert that source code is a paramount requirement for programs, they do not state that this is the case for non-program works, which permits us to consider whether one of the above points justifies a pragmatic concession to the larger context within which Free Software operates. THE DEBIAN PROJECT therefore, 1. reaffirms its dedication to providing a 100% free system to our users according to our Social Contract and the DFSG; and 2. encourages authors of all works to make those works available not only under licenses that permit modification, but also in forms that make such modifications practical; and 3. supports the decision of the Release Team to require works such as images, video, and fonts to be licensed in compliance with the DFSG without requiring source code for these works under DFSG #2; and 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. == -- Ich weiß nicht, welche Waffen im nächsten Krieg zur Anwendung kommen, wohl aber, welche im übernächsten: Pfeil und Bogen. -- Albert Einstein signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
#include hallo.h * Joey Hess [Wed, Aug 23 2006, 02:15:59PM]: Anthony Towns wrote: If it makes sense, what are the major difficulties/inconveniences/whatever that were found in having this happen for etch, that will need to be addressed to achieve an etch+1 release that's both useful and convenient for both people who need/want non-free things, and those who want a completely free system? From the d-i side, the major difficulties are: Thanks for your explanation. The legitimation for most of the stupid discussion parts seems to be the assumption that there is no other way for dealing with firmware but adding it to main. And let me say sorry if I sound too offensive in the following text. b. CD install where the CD, disk, NIC, etc need non-free firmware. Possible approaches include: i. Provide some way for the user to remaster the CD. * Too hard for most users. * If the CD drive itself needs non-free firmware they will need to modify the initrd too, which gets into the really hard territory. I would say, we shold provide at least one way for installation for a loadable-firmware poisoned system. We can construct any arbitrary usecase where loadable firmware is involved at the complexity of the support method will increase more and more. We have to make a cut somewhere and say that this way is supported and this way isn't. Note that most system vendors are not stupid, and most hardware manufacturers are not either. Droping legacy support already bites MS Windows users since nowadays many have to install a floppy drive again simply because the installer does not support SATA drives. Which means: we should assume that there is at least one way to fetch the additional data. I assumed that it would be possible with d-i to add custom sources, and even if it isn't it should not be the hardest thing to do. * Assumes that the drivers for the that don't need non-free firmware and that the machine supports floppy, usb or network. . Ship a separate non-free CD. * Which then becomes the one everyone uses because it works, as with the non-free netboot image above. And why not? The only severe reason is free version will get less testing but when the installer is effectively the same with just some extra code parts enabled, this would not make a significant difference. * Does bad things to our CD/DVD disk space requirements. How? Basedebs take about 40MB. I think there is a plenty of space on the non-free CD for those, together with udebs and boot images. Also, in the case of a CD that needs non-free firmware, we have to provide the installer with a way to get not just udebs for the firmware, but debs for it, for the installed system. This complicates all of the above approaches significantly. Fetching udebs from multiple sources is a feature that should be implemented anyway. Eduard. -- DeVries Wann kommt Debian3.0? Jemand n ungefähres oder genaues Datum parat? Alfie DeVries: Wenn es fertig ist. Falky dwVries wenn es fertig ist weasel DeVries: ziemlich genau dann, wenn es fertig ist.
Re: Proposal: The DFSG do not require source code for data, including firmware
[Eduard Bloch] . Ship a separate non-free CD. * Does bad things to our CD/DVD disk space requirements. How? Basedebs take about 40MB. I think there is a plenty of space on the non-free CD for those, together with udebs and boot images. Because it implies that we provide 2 copies each of the business card, netinst, full CD number 1, and full DVD number 1, for every architecture. signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
Hrm, maybe this thread should move elsewhere. On Sat, Aug 26, 2006 at 05:35:00AM -0500, Peter Samuelson wrote: [Eduard Bloch] . Ship a separate non-free CD. * Does bad things to our CD/DVD disk space requirements. How? Basedebs take about 40MB. I think there is a plenty of space on the non-free CD for those, together with udebs and boot images. Because it implies that we provide 2 copies each of the business card, netinst, full CD number 1, and full DVD number 1, for every architecture. We could concentrate on building just e.g. the netinst ISO with broken out firmware, only duplicating things there. People could still download the full regular CD1 if they need it and use apt-cdrom after a netinst-install. Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Sat, Aug 26, 2006 at 11:24:47AM +0200, Eduard Bloch wrote: #include hallo.h Thanks for saying those things, which i was thinking myself, but could not have expressed without being seen as a whiner. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 22, 2006 at 03:18:04PM -0700, Steve Langasek wrote: Ever since the sarge release, an ongoing question has been: what do the DFSG require for works that are not programs as previously understood in Debian? Several rounds of general resolutions have now given us answers for some subclasses of non-program works, but debate still rages regarding one particularly important class: firmware for peripheral devices. This discussion has indeed been going on for a while. The most important arguments seem to be that one side is saying It must be Free! while the other claims There is nothing useful in making it Free. I think the answer to that discussion can only be found in trying to analyse and answer these arguments. So let's try that. If we're saying It must be Free, since we want it to be free, even if that isn't useful at all, I think it would be fair to say you're a zealot, interested in nothing more than your own agenda. If this were the only argument in favour of requiring that firmware be free, I personally would reject it. So that leaves us with the claim that making firmware be free is not a useful goal, since there's nothing you can do with free firmware that you can't do with non-free firmware, either. Is this a true claim? I don't think so. Sure, firmware is there to support the hardware, and usually does not do anything more than just copy bits from the host CPU to some bits of the hardware on which you're running. Usually, if you want to add another feature to the device for which the firmware exists, you'll need to modify the hardware, too. Firmware is, in fact, so tightly coupled to hardware. This would seem to support the claim that you can't do *anything* useful with a free firmware, and that it having the source is a freedom which is not necessarily useful at all; that, therefore, it does not matter whether you get the source to any firmware or not, because having this source doesn't give you anything which you wouldn't already have otherwise. But I don't think this holds. As a real-life example, let us look at the Linksys wlan stuff, where the provided firmware is often exchanged by people to use openwlan instead. Then again, it could be argued that these are not actually hardware devices, but rather computer nodes. This may be true. Then again, there may be cases of devices where additional features could be implemented by just modifying the firmware. One such example could be one of a wireless network interface that supports one encryption protocol, but would need additional support for another encryption protocol. If the other encryption protocol does not need one to do things that the hardware cannot provide for, it would be a useful freedom to be able to code this support yourself. Also, while hardware (with its firmware) usually gets more rigourous testing than does usually software, that doesn't mean there cannot be bugs that still slip through the cracks; especially in the area of performance. Having the ability to fix such bugs is a useful freedom, IMO. An argument against these could be made that by uploading modified firmware to the device, one is at risk of damaging it beyond all repair, and that this may lead to loss of support options from the manufacturer. While this is true, it is equally true that loading Linux on hardware as produced by some manufacturers will also void your support options. I see no difference. Therefore, I would conclude that the ability to modify firmware, while not useful in even remotely all cases, is still a useful freedom to have; and that therefore, there is no reason why we should not require firmware in main to be free. Then again, maybe I'm just crazy and don't know what I'm talking about. That wouldn't be a first ;-) -- Lo-lan-do Home is where you have to wash the dishes. -- #debian-devel, Freenode, 2004-09-22 signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 12:01:38AM -0700, Steve Langasek wrote: On Wed, Aug 23, 2006 at 01:12:25AM +0100, Stephen Gran wrote: I would like to see some language to the effect that we make the exception for firmware only in the cases of data that use the moral equivalent of the kernel load_firmware interface, so that it's clear we aren't talking about the sort of completely non-free things like that adsl driver with a userspace binary library or the drivers from sangoma's site. First of all, I'm not asking for an exception; I'm asking the project to confirm whether programs should be understood to include firmware. Only if the project votes this GR down would it be time to consider making exceptions (which would definitely require 3:1 majority), I think. I would welcome any suggestions about how to make the language of the resolution clearer on this point. I would be very interested to see examples of firmwares affected by this GR. Sourceless firmwares tend to come with either no proper license statement or a license that prohibit modification and/or limit distribution. I consider a lack of licence or license prohibiting modification to be much more problematic that a lack of source. I had made research on the topic of binary blob in linux 2.4.18 in the past and I don't remember seeing a single firmware with all of: 1) A detailed copyright notice. (Not just a blob put inside a GPL file without any hint about how the blob was derivated and who actually wrote it). 2) A license that allows redistribution without source (i.e not the GPL) 3) A license that allows modification, redistribution and all of DFSG 1,3-10. 4) No source available. The conclusion is that the proposed GR would have had little effect on linux 2.4.18. In any cases, example of firmware affected by this GR would help the discussion. Cheers, (Please CC me) -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
#include hallo.h * Peter Samuelson [Sat, Aug 26 2006, 05:35:00AM]: [Eduard Bloch] . Ship a separate non-free CD. * Does bad things to our CD/DVD disk space requirements. How? Basedebs take about 40MB. I think there is a plenty of space on the non-free CD for those, together with udebs and boot images. Because it implies that we provide 2 copies each of the business card, netinst, full CD number 1, and full DVD number 1, for every architecture. No. We just keep providing the official free images. And someone else will provide the non-free variants. This scenario would reflect exactly the situation that already exists WRT Debian as in (free) Debian and Debian as in Debian + non-free + even-more-evil-external-non-distributable repositories. Eduard. -- Erfahrung heißt gar nichts. Man kann seine Sache auch 35 Jahre schlecht machen. -- Kurt Tucholsky -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
[EMAIL PROTECTED] wrote: This discussion has indeed been going on for a while. The most important arguments seem to be that one side is saying It must be Free! while the other claims There is nothing useful in making it Free. Wrong. The real other argument is there is nothing useful in making it non-free. Quite a different position. I think the answer to that discussion can only be found in trying to analyse and answer these arguments. So let's try that. Maybe you should try again after understanding what we are talking about. Then again, maybe I'm just crazy and don't know what I'm talking about. That wouldn't be a first ;-) Indeed. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
[EMAIL PROTECTED] wrote: No. We just keep providing the official free images. And someone else will provide the non-free variants. Yes: Ubuntu. This scenario would reflect exactly the situation that already exists WRT Debian as in (free) Debian and Debian as in Debian + non-free + even-more-evil-external-non-distributable repositories. Except that ~everybody agrees that non-free software is not part of Debian while most people do not agree that some firmwares should not be part of Debian. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 05:38:07PM +1000, Anthony Towns wrote: On Wed, Aug 23, 2006 at 01:28:35AM -0500, Peter Samuelson wrote: [Steve Langasek] That's an interesting point. Can you elaborate on how you see this being a loophole, in a sense that having the firmware on a ROM wouldn't also be? The day Debian begins to distribute ROM chips, or devices containing ROM chips, I will expect those chips to come with source code. Until then, this is a red herring. Note that while Peter is currently in the n-m queue (on hold pending further response to TS checks apparently), he's not yet a developer, and his expectations shouldn't be inferred to be those of the developers as a whole. Well, I hereby fully agree with Peter's expectations. And I am a DD. Please don't dismiss people just on grounds that they're not, yet, DD's. Regards: David -- /) David Weinehall [EMAIL PROTECTED] /) Rime on my window (\ // ~ // Diamond-white roses of fire // \) http://www.acc.umu.se/~tao/(/ Beautiful hoar-frost (/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
#include hallo.h * Sven Luther [Sat, Aug 26 2006, 06:21:54PM]: On Sat, Aug 26, 2006 at 11:24:47AM +0200, Eduard Bloch wrote: #include hallo.h Thanks for saying those things, which i was thinking myself, but could not have expressed without being seen as a whiner. You know, it's always the same. When the release comes closer, some kind of which-hunt begins... Eduard. -- Wie man sein Kind nicht nennen sollte: R. Würgt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Sat, Aug 26, 2006 at 09:31:58PM +0200, Eduard Bloch wrote: #include hallo.h * Sven Luther [Sat, Aug 26 2006, 06:21:54PM]: On Sat, Aug 26, 2006 at 11:24:47AM +0200, Eduard Bloch wrote: #include hallo.h Thanks for saying those things, which i was thinking myself, but could not have expressed without being seen as a whiner. You know, it's always the same. When the release comes closer, some kind of which-hunt begins... This one started last fall though. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: late for party (was Re: Proposal: The DFSG do not require source code for data, including firmware)
On Thu, Aug 24, 2006 at 09:56:49PM -0700, [EMAIL PROTECTED] wrote: Sven Luther wrote in http://lists.debian.org/debian-vote/2006/08/msg00125.html I would indeed vote for a solution including a non-free hardware, or even better an additional CD, which contained a non-free version of d-i (which need to include certain non-free firmwares and drivers in the images), and all the additional non-free firmware stuff. This way, we could add a list of pci ids needding non-fre hardware, and do a check pretty early in the installer, and if those non-free hardware is found, inform the user about it, and use the non-free installer CD instead, and all the rest would be taken care for him. Nice idea, Sven. Do you really think that can work reliably for etch, in December? No, it is already too late. The time to work on this was quickly after the sarge release last fall, but upstream was not ready, the kernel team was hard working on things like the common package, and the devfs removal / ramdisk generator issues, and in general to bringing a more timely release schedule in action. Other teams clearly dismissed the issue and are now also blocking point. As thus, the most reasonable way, would be to delay the issue until etch+1, which gives us time to work on it in tranquility, be able to make more adventursome choices and experiments, without the fear of breakage that comes at a moment where major component affected (kernel, d-i) are already frozen. While Steve's proposal item (4) is just plain false, I can certainly see the argument to continue to make a firmware exception for etch. I would support such a plan only if it was explicitly etch-only, and linux-2.6 only, and there was a commitment to rip out superficially illegal GPL/s-f-c files the day after etch releases. Well, not the day after the etch release, but shortly thereafter. I do believe that there is a certain rythm to a release schedule. At first after a release is a time of rest, where the pression of the release is evacuated, and it is a time for thought and reflexion over what went badly, and what could be improved. Then is a time for more adventursome changes, new implementations, and so on, then once the choices are implemented, they are validated through a time of testing, and then we enter in the pre-release fine-tuning phase culminating with the release. We are now in that last phase, and it is too late for a solution to the non-free firmware issue for etch, and our best guess would be to get it out of the way quickly, and be able to concentrate on it post etch. The problem also was that a certain amount of developers had trouble with the above rythm, and kind of believed they where already in the no-major-change fine-tuning period immediately after sarge, most prominent among them the d-i team, probably due to lack of man power after the post-sarge defection. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Heya, I second the proposal quoted below. Steve Langasek [EMAIL PROTECTED] writes: The application of DFSG#2 to firmware and other data The Debian Project recognizes that access to source code for a work of software is very important for software freedom, but at the same time source is often not a well-defined concept for works other than those traditionally considered programs. The most commonly cited definition is that found in version 2 of the GNU GPL, the preferred form of the work for making modifications to it, but for non-program works, it is not always clear that requiring this source as a precondition of inclusion in main is in the best interest of our users or advances the cause of Free Software: - The author's preferred form for modification may require non-free tools in order to be converted into its final binary form; e.g., some device firmware, videos, and graphics. - The preferred form for modification may be orders of magnitude larger than the final binary form, resulting in prohibitive mirror space requirements out of proportion to the benefits of making this source universally available; e.g., some videos. - The binary and source forms of a work may be interconvertible with no data loss, and each may be the preferred form for modification by different users with different tools at their disposal; e.g., some fonts. While the Debian Free Software Guidelines assert that source code is a paramount requirement for programs, they do not state that this is the case for non-program works, which permits us to consider whether one of the above points justifies a pragmatic concession to the larger context within which Free Software operates. THE DEBIAN PROJECT therefore, 1. reaffirms its dedication to providing a 100% free system to our users according to our Social Contract and the DFSG; and 2. encourages authors of all works to make those works available not only under licenses that permit modification, but also in forms that make such modifications practical; and 3. supports the decision of the Release Team to require works such as images, video, and fonts to be licensed in compliance with the DFSG without requiring source code for these works under DFSG #2; and 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. Marc -- BOFH #57: Groundskeepers stole the root password pgpnJizxpl83L.pgp Description: PGP signature
Re: Proposal: The DFSG do not require source code for data, including firmware
Steve Langasek [EMAIL PROTECTED] wrote: [...] Our voting mechanism is *clone*proof, preventing multiple identical ballot options from influencing the outcome; but it's not proofed against influence by toothless variants that will inevitably appeal to a broader constituency because they say less of substance. If you think the Debian voting system handles compound resolutions badly, then why did you propose one? Hadn't you noticed that thread before? I want to read the Debian Voting System (J.Voss?) again before saying whether or not this is the case, but *if* you have harmed the chances of your proposal by unnecessarily making it a compound resolution instead of two independent simple resolutions, then I think that's justice. Best wishes, -- 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: Proposal: The DFSG do not require source code for data, including firmware
[Matthew Garrett] The biggest area which is likely to bite us is with network cards, though we'll probably lose some degree of SCSI support as well. Fortunately, at least with SCSI, users have a choice. They can buy Adaptec or LSI 53c* and they get _truly free_ firmware (in the case of Adaptec, the kernel includes firmware source and a matching assembler; for LSI, the firmware is augmented with byte-code scripts apparently assembled by the driver at runtime). Perhaps coincidentally, between aic7xxx, aic79xx and sym53c8xx_2, the most popular commodify SCSI chips are covered. (Well, there's the megaraid family, but those don't _appear_ to need to load firmware at runtime either.) Incidentally, the aic7xxx / aic79xx drivers in particular are a great thing to point out to people who are inclined to be lenient toward vendors on the theory that it is inherently not practical for them to ship open source firmware for their devices. Adaptec figured out how to do this a _long_ time ago: $Id: aic7xxx.reg,v 1.4 1997/06/27 19:38:39 gibbs Exp $ $Id: aic7xxx.seq,v 1.77 1998/06/28 02:58:57 gibbs Exp $ signature.asc Description: Digital signature
Re: late for party (was Re: Proposal: The DFSG do not require source code for data, including firmware)
[EMAIL PROTECTED] wrote: My understanding is that upstream has not been entirely receptive to patches that remove non-free firmware from it. Maybe that's because they don't have an established firmware-nonfree project (like Debian does) into which to move that firmware? No, it's because they really do not believe this to be a problem, like everybody else but a few people polluting debian-legal. A consensus of DD that firmware is not software carries no legal weight. 44 of the sourceless-firmware-contaminated files in the Linux kernel are claimed to be covered by the GPL. There is no legal way for Debian to redistribute those files, since we can't provide that source to people who attempt to exercise their GPL-mandated rights. Other distributions disagree, and they have actual lawyers who are payed to care about such things. http://lists.debian.org/debian-vote/2006/08/msg00166.html I think we should learn from OpenBSD on this front. I agree. Indeed, the OpenBSD project not only distributes sourceless firmwares, but also sourceless firmwares with a license which forbids modifications and reverse engineering. Care to back up that statement? It runs 180 degrees counter to my understanding of OpenBSD. Feel free to dig in the OpenBSD mailing lists archives if you care. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: late for party (was Re: Proposal: The DFSG do not require source code for data, including firmware)
Marco d'Itri [EMAIL PROTECTED] posted from wonderland.linux.it: No, it's because they really do not believe this to be a problem, like everybody else but a few people polluting debian-legal. I note that several of those supporting the current source code requirement for main don't post much to debian-legal (and certainly don't pollute it with claims like the DFSG does not addrss patents. This means that there is no point in arguing that patent restrictions violate thit http://lists.debian.org/debian-legal/2006/08/msg00106.html ). [... [EMAIL PROTECTED] wrote: ] http://lists.debian.org/debian-vote/2006/08/msg00166.html I think we should learn from OpenBSD on this front. I agree. Indeed, the OpenBSD project not only distributes sourceless firmwares, but also sourceless firmwares with a license which forbids modifications and reverse engineering. Care to back up that statement? It runs 180 degrees counter to my understanding of OpenBSD. Feel free to dig in the OpenBSD mailing lists archives if you care. Searching OpenBSD mailing list archives for mails matching both keywords firmware and source found nothing. Are you sure it's in there? Thanks, -- 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: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 05:08:33PM -0700, Steve Langasek wrote: On Thu, Aug 24, 2006 at 08:29:49PM +0200, Kurt Roeckx wrote: On Thu, Aug 24, 2006 at 01:16:42AM -0700, Steve Langasek wrote: Point 3 then seems to go the other way around and say we don't need sources for of few types of works. My main problem with this is that still a little vague about which types of works don't require source. What problems do you consider this vagueness to cause? What changes would you suggest to make this less vague? It lists images, video, and fonts. And I'm assume it's going to cover more than just that. I'm also not sure that this is something we want for all types of data. I think we *want* the best possible form for modification for all types of data. I don't think the DFSG *requires* this, and therefore I don't think *we* should require it. Do you disagree? I think we should require it. The DFSG says we need the source, and I understand that as the best possible form for modification. For instance, bison/yacc generates a C file. You could consider that C file a source, but it's not. We want the original file that was used to generate that C file. There might be several layers of tools that are used to generate an object file from it's source, but it's the source we want. For instance when they're raster images or fonts, I'd rather have the source, if there ever was a vector based format of it. But I don't care if there never was a vector based format, so nothing that would be a more prefered way of changing it. Rather have != Insist on for inclusion in main, though? No, I would insist on having it. Anyway, the answer I had in mind was a hex editor or a decompiler. If the firmware in question *is* code, and we know what the chip in question is that the code is running on, both options seem within the realm of plausibility to me. No, of course they're not the *ideal* means of editing such a work, but AFAIK most firmware is on the order of what programmers used to program directly in assembly, so it's also not totally *insane* to try to edit such a binary directly as it would be for most modern userspace apps, for instance.) I don't see a hex editor useful for much, and a decompiler only slightly better. If a decompiled version was useful to do derived work, it would be the same as source, so not requiring source doesn't make sense to me. The difference with source is that you actually have names of functions and variables, you have comments with it. Those things make it easy to understand what it's trying to do. So it's easier to make changes too. OTOH, the source may require a non-free tool to render it into a binary firmware form. If you don't have that tool, and maybe even no hope of getting access to it, is it any longer evident that the source is more useful than the binary for derived works? Yes, from there we get into discussions about defining source as whatever form people prefer to work from -- hmm, redefinition? -- and whether we can ship anything in main that we don't have a full toolchain for; but a) is that actually required by the DFSG, and b) is that the right standard to set, either today or in the future? The DFSG doesn't say that the toolchain should be available for it to be free, and it shouldn't. But I understand the SC as requiring it to be included in main. It's also one of the reasons we have such a thing as contrib. There was a time when alot of java applications were in contrib because there wasn't anything in main we could use them with. But those were free software. You just needed non-free software for it to be useful. And now most, if not all, have moved to main. It would also be useful to have a list of firmwares we're currently are talking about, and what license they have. Are there any that only fail DFSG 2, or will this part of GR have no effect at all? Larry Doolittle has prepared a very helpful table at http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html. A number of these are marked as being under a BSD-ish license, which would qualify; a number of others are listed as GPL but sourceless, which nominally makes them non-distributable, but it seems unlikely that any copyright holders on these would refuse to relicense under more appropriate terms even if they weren't willing/able to release source. So, from that list: * 46 source files that already use request_firmware() or mod_firmware_load() * 18 already removed from Debian (linux-2.6_2.6.17.orig.tar.gz) * 47 apparently nondistributable * 12 apparently ok for non-free * 14 free So, we have a total of 137 drivers that require firmware. We have 14 that are free and can stay in main in any case. I'm not sure about those 46 that already use request_firmware(), but we seem to have atleast 12 (BSD-ish) that could go to non-free, but with
Re: Proposal: The DFSG do not require source code for data, including firmware
On Fri, Aug 25, 2006 at 08:04:51PM +0200, Kurt Roeckx wrote: On Thu, Aug 24, 2006 at 05:08:33PM -0700, Steve Langasek wrote: On Thu, Aug 24, 2006 at 08:29:49PM +0200, Kurt Roeckx wrote: On Thu, Aug 24, 2006 at 01:16:42AM -0700, Steve Langasek wrote: Point 3 then seems to go the other way around and say we don't need sources for of few types of works. My main problem with this is that still a little vague about which types of works don't require source. What problems do you consider this vagueness to cause? What changes would you suggest to make this less vague? It lists images, video, and fonts. And I'm assume it's going to cover more than just that. I'm also not sure that this is something we want for all types of data. I think we *want* the best possible form for modification for all types of data. I don't think the DFSG *requires* this, and therefore I don't think *we* should require it. Do you disagree? I think we should require it. Well, you're entitled to your opinion on that, of course. I disagree, because I don't see that the DFSG requires it, and I don't think it's worth delaying a release over (which is how I understand require). The DFSG says we need the source, and I understand that as the best possible form for modification. The DFSG says we need the source for programs. For instance, bison/yacc generates a C file. You could consider that C file a source, but it's not. We want the original file that was used to generate that C file. There might be several layers of tools that are used to generate an object file from it's source, but it's the source we want. Presumably we're all in agreement that this is a program, though, not data... -- 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/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 03:40:49PM +0100, Matthew Garrett wrote: We never included non-free applications in main because we felt that there was no need to. And, indeed, even in 1993 it was possible to use a computer without any non-free applications. That doesn't hold with the firmware argument. With applications, we had the choice between Free but less functional and Non-free but more functional. With firmware we have the choice between Non-free but on disk and Non-free but in ROM. There isn't a Free option at all yet. So I think the real question is How does us refusing to ship non-free firmware help free software?. If a user wants to use Debian, then the obvious thing for them to do will be to buy hardware that has the non-free firmware in ROM. Ironically, this will actually make it harder for them to ever use free firmware! I think it's reasonable to refuse to ship non-free code when there's actually a choice or when it's likely to provide an incentive to implement a free version. But right now, I don't see any evidence that refusing to ship non-free firmware will do anything other than cost us users without providing any extra freedom. AFAICS, there has never been a debate about whether to ship non-free firmware, only about where to ship it. If not having source for firmware makes it non-free, then it seems obvious to me that under the DFSG, it shouldn't be shipped in main. -- 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/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 05:39:43PM -0500, Peter Samuelson wrote: [Sven Luther] To add to that, if i where Peter, i may feel slightly offended by the tone of your reply as well as the content of it. I wasn't offended. AJ's tone wasn't derogatory - he made some observations and offered some advice. He's quite right that my views are not those of a developer, and that when I say I will expect something to happen, this is a user expectation, no more. Ok. It is also true that saying something is a red herring, without explaining why, is probably negligent. What I meant is this: the status of software which Debian does not ship (the software embedded in hardware) is outside the scope of the Social Contract, and thus it's not meaningful to argue about the status of software Debian ships by comparing the two. And if a comparison is not meaningful, introducing it into an argument constitutes a red herring. Well, it was evident from your post that that was what you meant. You are the DPL, and as thus speak with the authority given by the whole project He didn't use the [EMAIL PROTECTED] address. It was clear to me that he was speaking as a developer, not as the DPL. he doesn't use the leader@ address even on issues related to his DPL role, as i well know, so this is no guarantee. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 01:38:41PM -0700, Steve Langasek wrote: On Wed, Aug 23, 2006 at 02:41:22PM +0200, Sven Luther wrote: Si, am I silly and alone in thinking that firmware is binary computer programs? Let us ask google to define: firmware: You are silly in pretending that the DFSG and the widely shared consensus among developers always intended considering them non-free and inappropriate for main. The last of the three pre-sarge non-free GRs confirmed the fact that firmware is indeed a code binary, and should have source. No, it did not. Reread the GR that passed; it says nothing about firmware or source code. The discussion leading to it did clearly and numerously mention the firmware issues, together with the GFDL documentation, the fonts, and a couple of others maybe i don't remember. The first GR was the one where we decided to keep non-free, and there already non-free drivers and firmware where mentioned as one of the reason to keep non-free. The second GR was the cosmetic change one, which left us with a (new to some) interpretation including fonts, documentation and firmware as software needing source. The third was a reaction to this one, where we decided to waive this requirement for sarge, in order to get sarge out in a timely fashion. Now, you are, in disrespect of the decision taken back then, and with lot of sugary wrapping to make it pass easier, trying to go back over those decisions. I don't care about word play, or nit picking, it is only the plain fact which counts, and nothing you will say will change what was decided back then and what you are trying to decide now. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 03:25:49PM -0700, Steve Langasek wrote: On Wed, Aug 23, 2006 at 10:30:33AM +0200, Bas Zoetekouw wrote: You wrote: 3. supports the decision of the Release Team to require works such as images, video, and fonts to be licensed in compliance with the DFSG without requiring source code for these works under DFSG #2; and 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. Would it be possible to vote on these two issues seperately? It would certainly be possible, but I don't see any value in voting on the first of these points on its own because I think the release team is already doing the right thing and doesn't need a GR to confirm it. It's only the latter point that's a question in my mind, so if someone wants to vote on the former point alone they'd need to propose their own GR. N.B., I would object to having any ballot options on the same GR that consist of this same draft with point #4 stricken, because assuming rational voters I would expect the voters who approve of that option to be a strict superset of those who approve of my proposal, and I would call on the Project Secretary to exercise his authority to keep these two proposals on separate ballots to avoid prejudicing the outcome in favor of a watered down option. Then why don't you put the point 4 in a separate GR, where the project would vote in all honesty if firmware are programs or not, and then on the strength of that, you propose nice wordings surrounding it. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 01:57:20AM +0200, [EMAIL PROTECTED] wrote: Hi, I'd actually see some restriction with regard to interoperability (i.e. some reasonably documented interface between the firmware and the driver code), but getting this right is likely not worth the effort. Hmm, I'm not sure what that would look like at all; as someone else noted, That someone being me, i think i should reply. one generally doesn't talk to the firmware even, one talks to the device. That's mostly wrong. In case of the DAC960 for example the driver does talk to the firmware, same for the fore ATM cards or USB devices which have downloadable firmware. Well, the point is the following. From the driver point of view, it speaks to the device, with a given protocol, over a given hardware interface (pci, random set of GPIO pins, etc). But there is no way the device driver can make a difference between speaking to said firmware program running on the device, or to a firmware version not uploaded but hold in flash, or to a hardcoded non-firmware device. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Hi, Well, the point is the following. From the driver point of view, it speaks to the device, with a given protocol, over a given hardware interface (pci, random set of GPIO pins, etc). No. It talks to the firmware. Or do you really believe anything else then the firmware can give a sensible answer to commands like 'get version' ? And why do the commands remain unanswered before the firmware is loaded ? But there is no way the device driver can make a difference between speaking to said firmware program running on the device, or to a firmware version not uploaded but hold in flash, or to a hardcoded non-firmware device. It can. Requests remain unanswered or return an error when the driver sends them before the firmware is loaded. Requests do get answered properly after the firmware has been loaded and started. In short don't try to deny reality... Cheers, Peter (p2). -- Goa is a state of mind -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 09:48:52AM +0200, [EMAIL PROTECTED] wrote: Hi, Well, the point is the following. From the driver point of view, it speaks to the device, with a given protocol, over a given hardware interface (pci, random set of GPIO pins, etc). No. It talks to the firmware. Or do you really believe anything else then the firmware can give a sensible answer to commands like 'get version' ? And why do the commands remain unanswered before the firmware is loaded ? sure, but embedded or hardcoded firmware could do just as well as the downloaded firmware. Also, there are processor version registers which you could also speak to do a 'get version'. But there is no way the device driver can make a difference between speaking to said firmware program running on the device, or to a firmware version not uploaded but hold in flash, or to a hardcoded non-firmware device. It can. Requests remain unanswered or return an error when the driver sends them before the firmware is loaded. Requests do get answered properly after the firmware has been loaded and started. In short don't try to deny reality... Well, as said, it depends on the chip, but there is really no difference between an incarnation of the chip where the firmware resides in on-chip flash, and you can upgrade or something by software, or one where you have to upload the firmware in question, or one that has no firmware at all. As far as the driver is concerned, he speaks to a ship, with a given pre-defined upon protocol, and the presence or not of firmware is irrelevant to this. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 08:30:31PM +0200, Kurt Roeckx wrote: On Tue, Aug 22, 2006 at 03:18:04PM -0700, Steve Langasek wrote: THE DEBIAN PROJECT therefore, 1. reaffirms its dedication to providing a 100% free system to our users according to our Social Contract and the DFSG; and 2. encourages authors of all works to make those works available not only under licenses that permit modification, but also in forms that make such modifications practical; and 3. supports the decision of the Release Team to require works such as images, video, and fonts to be licensed in compliance with the DFSG without requiring source code for these works under DFSG #2; and 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. I'm a little confused as to what this means exactly. Point 2 seems to say that we consider source to be such a form of the work that modifications are practical, but without actually saying anything. However, I think such a definition of source would be a good thing. But this point really doesn't say much about Debian, it just says we encourage others to do something. So I don't see why this belongs in the GR in the first place. A position statement tells the wider community, not just Debian's own developers, Debian's views on a subject. Don't worry about source code for firmware, no one cares about it is not a message I want to send. This clause states that we *do* care about source code for firmware: we just don't consider it worth the trade-offs to *require* such source code as a condition of inclusion in Debian. Point 3 then seems to go the other way around and say we don't need sources for of few types of works. My main problem with this is that still a little vague about which types of works don't require source. What problems do you consider this vagueness to cause? What changes would you suggest to make this less vague? I guess point 4 is saying the firmware should be considered the same as the other works in point 3 and the source isn't needed for firmware. Correct. However, it doesn't say anything about other points of the DFSG. Nope, nor was it my intention that it do so. So we should still need a license that allows atleast derived works. Correct. And I don't see how we're going to make derived works of firmware without the source for it. That seems to be orthogonal to the licensing question, though? Anyway, the answer I had in mind was a hex editor or a decompiler. If the firmware in question *is* code, and we know what the chip in question is that the code is running on, both options seem within the realm of plausibility to me. No, of course they're not the *ideal* means of editing such a work, but AFAIK most firmware is on the order of what programmers used to program directly in assembly, so it's also not totally *insane* to try to edit such a binary directly as it would be for most modern userspace apps, for instance.) -- 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/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
* Steve Langasek: I'd actually see some restriction with regard to interoperability (i.e. some reasonably documented interface between the firmware and the driver code), but getting this right is likely not worth the effort. Hmm, I'm not sure what that would look like at all; as someone else noted, one generally doesn't talk to the firmware even, one talks to the device. The higher-layer protocol the device speaks to the driver is typically implemented by the firmware. But it turns out that what I want has not much to do with interoperability. The thing I'd like to rule out is that application-specific code is transferred to a device, and we do not provide source code for that device. For example, implementing OpenGL primitives (or JPEG decompression) on the GPU in sourceless firmware might be acceptable, but putting computer AI for games in there, or rendering a proprietary video format using it would be much harder to accept. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
[EMAIL PROTECTED] wrote: I would prefer if the term firmware would be defined or at least explained in the GR. Something like: firmware (data which is sent to attached devices for processing and which is not, directly or indirectly, executed on the host CPU) I don't object to this. Is there agreement among the GR sponsors that this is the definition of firmware that should be used? I agree with the general idea, but I am not sure if this definition covers CPU microcode updates like the ones uploaded by the microcode.ctl package. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 08:30:23AM +0200, Sven Luther wrote: he doesn't use the leader@ address even on issues related to his DPL role, as i well know, so this is no guarantee. AFAICT, he always signs those mails with DPL in the signature. Plus, at least in this thread, he did use [EMAIL PROTECTED] Michael -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, 23 Aug 2006 15:25:49 -0700, Steve Langasek [EMAIL PROTECTED] said: On Wed, Aug 23, 2006 at 10:30:33AM +0200, Bas Zoetekouw wrote: You wrote: 3. supports the decision of the Release Team to require works such as images, video, and fonts to be licensed in compliance with the DFSG without requiring source code for these works under DFSG #2; and 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. Would it be possible to vote on these two issues seperately? It would certainly be possible, but I don't see any value in voting on the first of these points on its own because I think the release team is already doing the right thing and doesn't need a GR to confirm it. It's only the latter point that's a question in my mind, so if someone wants to vote on the former point alone they'd need to propose their own GR. N.B., I would object to having any ballot options on the same GR that consist of this same draft with point #4 stricken, because assuming rational voters I would expect the voters who approve of that option to be a strict superset of those who approve of my proposal, and I would call on the Project Secretary to exercise his authority to keep these two proposals on separate ballots to avoid prejudicing the outcome in favor of a watered down option. Speaking with my secretary hat on, it seems to me that options 3 and 4 are somewhat orthogonal -- inasmuch that it appears eminently reasonable for someone to have differing opinions on these two options. So people may approve of 3, and disapprove of 4: and this makes me think that they do not belong on the same ballot, since they are unrelated wrt to voting (though obviously addressing related areas) manoj -- A woman is like your shadow; follow her, she flies; fly from her, she follows. Chamfort Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, 24 Aug 2006 01:16:42 -0700, Steve Langasek [EMAIL PROTECTED] said: A position statement tells the wider community, not just Debian's own developers, Debian's views on a subject. Don't worry about source code for firmware, no one cares about it is not a message I want to send. This clause states that we *do* care about source code for firmware: we just don't consider it worth the trade-offs to *require* such source code as a condition of inclusion in Debian. I am afraid that this distinction was too subtle for me in the form of the proposal as written. manoj -- It is better to give than to lend, and it costs about the same. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
If there is a vote, I will vote AGAINST granting a special exception to firmware, or considering firmware as data. Manoj's arguments are compelling IMHO. In addition, the proposed GR makes no mention of blobs, which are binary-only pieces of software that execute *in kernel space*, *on the central processing unit*. Linux contains a few blobs. I would therefore: - oppose a GR waives the requirement for source code for firmware - propose a GR that bans both blobs and firmware from main, especially from the linux packages in main. If something is redistributable but not modifiable in the preferred form for modification (source), then it belongs in non-free. The proposed GR mentions that some firmware requires non-free tools in order to create it from source code. Just because no free tools exist *now* does not imply that no free tools will *ever* exist; and just because some vendor tries to lock people in with non-free firmware does not mean we should accept to be locked in. I think we should learn from OpenBSD on this front. -- Ludovic Brenta. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
Ludovic Brenta [EMAIL PROTECTED] wrote: If there is a vote, I will vote AGAINST granting a special exception to firmware, or considering firmware as data. Manoj's arguments are compelling IMHO. In addition, the proposed GR makes no mention of blobs, which are binary-only pieces of software that execute *in kernel space*, *on the central processing unit*. Linux contains a few blobs. Where? -- Matthew Garrett | [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
[EMAIL PROTECTED] wrote: If there is a vote, I will vote AGAINST granting a special exception to firmware, or considering firmware as data. Manoj's arguments are compelling IMHO. In addition, the proposed GR makes no mention of blobs, which are binary-only pieces of software that execute *in kernel space*, *on the central processing unit*. Linux contains a few blobs. I would therefore: No, blobs are opaque streams of bytes which are uploaded to some device and never executed by the system CPU. You are talking about non-free object files to be linked with the rest of the kernel code, and the Linux kernel does not contain any. Please get a clue. The proposed GR mentions that some firmware requires non-free tools in order to create it from source code. Just because no free tools exist *now* does not imply that no free tools will *ever* exist; and just because some vendor tries to lock people in with non-free firmware does not mean we should accept to be locked in. We *are* locked in no matter if we distribute sourceless firmwares or not since everybody will always end up using some. I think we should learn from OpenBSD on this front. I agree. Indeed, the OpenBSD project not only distributes sourceless firmwares, but also sourceless firmwares with a license which forbids modifications and reverse engineering. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, 23 Aug 2006 16:23:20 -0700, Steve Langasek [EMAIL PROTECTED] said:
As you and I discussed previously on IRC, I don't agree with this
amendment. The premise of my proposal is that we are *not* granting
an exception nor redefining any terms, we are merely recognizing a
latent definition of programs that has guided Debian since its
inception in spite of standing in contrast to the dictionary
definition of the word. If I felt that we were actually redefining
terms at this juncture, I would wholeheartedly agree with Manoj that
it should be done by modifying the DFSG with a 3:1 supermajority.
And it seems to me that your proposed amendment falls on the other
side of this line, where you would have us define program to mean
one thing now and something else later.
It may be that this discussion will lead me to the conclusion that
the distinction between stating what our definition of 'program'
is and redefining 'program' is too subtle, in which case I expect
that I'll go for an amendment to the DFSG instead.
It is not just a dictionary definition. Let me see if I can
drive this point home. I have looked at text books, encyclopedias,
references in the IEEE and ACM digital libraries, and various
glossaries and dictionaries of computer and electronic terms. I
personally would consider Computer Organization Design: The
hardware /software interface by David A. Patterson and John
L. Hennessey authoritative in this area.
It is not as if the term is not well understood and fairly
rigorously defined in the texts, literature and media out there --
and redefining it by using a latent definition is indeed like
redefining what words mean in order to meet our convenience.
What would it take to convince the proponents of this position
that the term is ill-defined or vacuous enough to require further
(and wildly different) definition by the project?
Indeed, all the references I have found tell me that firmware
is computer programs. The only confusion I have ever seen is in
Debian fora linked to a discussion in which comeone is trying to
continue to inject such source-less computer programs in main --
which makes me wonder about the depth of such confusion.
If Debian chooses to use words in its foundation documents
which is privately re-defines to be at odds with the general and
commonly accepted meaning of the term, and does not explicitly insert
the private special definition into the foundation document, I
consider it deceptive, unethical, and putting a lie to the social
contract.
I mean, if Debian can today define program to mean not
firmware, despite what all references say, what is to prevent it
from redefining it privately tomorrow to say anything not written by
microsoft, since that isn't programs, but crap? and ship the freely
distributable but non-free crap in main, since they are not programs?
(Yes, this example is a little over the top, but not a whole
lot. If we are redefining common words, let us have the honesty to
put in our definition where we use it in the foundation documents).
manoj
Computer Organization Design: The hardware /software interface,
David A. Patterson and John L. Hennessey, pp 424-425, talking about
how firmware is programming instructions interpreted by the FSM
controller (ie computer code interpreted by a micrprocessor inside
the MIPS CPU itself -- so the CPU distinction is void).
Encyclopedias: Wikipedia says it unequivocally:
http://en.wikipedia.org/wiki/Firmware
In computing, firmware is software that is embedded in a hardware
device. It is often provided on flash ROMs or as a binary image file
that can be uploaded onto existing hardware by a user.
Gazillions of Glossaries:
Google for define: firmware
And yes, the dictionaries:
From The Free On-line Dictionary of Computing (19 Sep 2003) [foldoc]:
Firmware
Software stored in read-only memory (ROM) or programmable ROM
(PROM). Easier to change than hardware but harder than
software stored on disk. Firmware is often responsible for
the behaviour of a system when it is first switched on. A
typical example would be a monitor program in a
microcomputer which loads the full operating system from disk
or from a network and then passes control to it.
From WordNet (r) 2.0 (August 2003) [wn]:
firmware
n : (computer science) coded instructions that are stored
permanently in read-only memory [syn: {microcode}]
The Jargon file: Embedded software contained in EPROM or flash
memory.
--
Did you hear that two rabbits escaped from the zoo and so far they
have only recaptured 116 of them?
Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe.
Re: Proposal: The DFSG do not require source code for data, including firmware
Steve Langasek [EMAIL PROTECTED] [...] This GR is a position statement, not an amendment to the foundation documents, which means a couple of things. [...] As I understand it, this proposal seeks to exempt parts of debian from part of the DFSG. Why is that not an amendment to the foundation documents? The application of DFSG#2 to firmware and other data I note this proposal also applies to much 'other data'. It is self-contradictory and contains things which seem unsupportable. I hope that it will not pass in this form. In particular: The Debian Project recognizes that access to source code for a work of software is very important for software freedom, but at the same time source is often not a well-defined concept for works other than those traditionally considered programs. I think I disagree with this: the concept of source is well-defined from long before programs. I think I first learnt about it in history lessons, before I knew what program source code was. It would be interesting to know if the term 'source code' came from the concept of sources for literary works, but not essential for this discussion. A primary work is its own source, while secondary and later works have other works as sources. What class of work do the proponents claim has no source? It may not be clear *what* the source code is for a particular work, but those are practical problems to be solved. A few particular problems does not make the concept of source ill-defined for those works. The most commonly cited definition is that found in version 2 of the GNU GPL, the preferred form of the work for making modifications to it, but for non-program works, it is not always clear that requiring this source as a precondition of inclusion in main is in the best interest of our users or advances the cause of Free Software: - The author's preferred form for modification may require non-free tools in order to be converted into its final binary form; e.g., some device firmware, videos, and graphics. How does this differ from free software C programs before GCC? It is a problem, but existance of the free software still advances free software. - The preferred form for modification may be orders of magnitude larger than the final binary form, resulting in prohibitive mirror space requirements out of proportion to the benefits of making this source universally available; e.g., some videos. Do ftpmasters currently reject packages for source being too large relative to the binary? If not, I ask the proposer to remove this point from the proposal. - The binary and source forms of a work may be interconvertible with no data loss, and each may be the preferred form for modification by different users with different tools at their disposal; e.g., some fonts. This problem seems to be a consequence of applying the GPL meaning of source. I ask the proposer to remove this obvious strawman from the proposal. While the Debian Free Software Guidelines assert that source code is a paramount requirement for programs, they do not state that this is the case for non-program works, which permits us to consider whether one of the above points justifies a pragmatic concession to the larger context within which Free Software operates. Abandoning hope of adaptable, maintainable software is not pragmatic. I ask the proposer to replace 'a pragmatic concession' with 'these concessions'. THE DEBIAN PROJECT therefore, 1. reaffirms its dedication to providing a 100% free system to our users according to our Social Contract and the DFSG; and Point 1 above contradicts points 3 and 4 below. We are not reaffirming the DFSG if we are partly waiving them. 2. encourages authors of all works to make those works available not only under licenses that permit modification, but also in forms that make such modifications practical; and This point should call on licensors, not authors. Authors are often powerless to change the licences, if the firmware is a work made for hire and so the copyright is held by the employer. Arguably, it's also encouraging manufacturers to continue shipping sourceless firmware if it's even allowable in debian main. 3. supports the decision of the Release Team to require works such as images, video, and fonts to be licensed in compliance with the DFSG without requiring source code for these works under DFSG #2; and This seems to require a modification to the foundation documents. 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. On what planet is device firmware not a program? It runs, even if not on a CPU running the rest of debian. I remain of the opinion that allowing a non-free-hardware-support onto CDs is the most logical compromise, but I wait to see what response the above questions and request bring. Regards, -- MJR/slef My Opinion Only:
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 10:24:58AM -0500, Manoj Srivastava wrote: On Thu, 24 Aug 2006 01:16:42 -0700, Steve Langasek [EMAIL PROTECTED] said: A position statement tells the wider community, not just Debian's own developers, Debian's views on a subject. Don't worry about source code for firmware, no one cares about it is not a message I want to send. This clause states that we *do* care about source code for firmware: we just don't consider it worth the trade-offs to *require* such source code as a condition of inclusion in Debian. I am afraid that this distinction was too subtle for me in the form of the proposal as written. Suggestions for improvement are welcome. -- 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: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 08:08:18AM +0200, Florian Weimer [EMAIL PROTECTED] wrote: * Steve Langasek: I'd actually see some restriction with regard to interoperability (i.e. some reasonably documented interface between the firmware and the driver code), but getting this right is likely not worth the effort. Hmm, I'm not sure what that would look like at all; as someone else noted, one generally doesn't talk to the firmware even, one talks to the device. The higher-layer protocol the device speaks to the driver is typically implemented by the firmware. But it turns out that what I want has not much to do with interoperability. The thing I'd like to rule out is that application-specific code is transferred to a device, and we do not provide source code for that device. For example, implementing OpenGL primitives (or JPEG decompression) on the GPU in sourceless firmware might be acceptable, but putting computer AI for games in there, or rendering a proprietary video format using it would be much harder to accept. Note that there are more and more applications trying to use the power of the GPU for computation. The hole should not be left open in the GR. Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, 23 Aug 2006 15:25:49 -0700, Steve Langasek [EMAIL PROTECTED] said: [...] N.B., I would object to having any ballot options on the same GR that consist of this same draft with point #4 stricken, because assuming rational voters I would expect the voters who approve of that option to be a strict superset of those who approve of my proposal, and I would call on the Project Secretary to exercise his authority to keep these two proposals on separate ballots to avoid prejudicing the outcome in favor of a watered down option. Hi Steve, Maybe I don't quite understand your concern correctly, but isn't this one of the advantages of using Condorcet? i.e. if we had points [1-3] on the same ballot as points [1-4], even though the number of votes for [1-3] compared to NOTA would obviously be higher than the number of votes for [1-4] compared to NOTA, the thing that would determine whether [1-3] wins, or [1-4], would be the ranking between those two options (assuming both win compared to NOTA). So those who agree with point 4 should rank [1-4] higher than [1-3] (and those who don't would obviously rank it lower). Hence if more people agree with #4 than disagree with it, then [1-4] should win over [1-3]. Or am I wrong in my understanding? -- Hubert Chan - email Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 08:48:20AM +0200, Sven Luther [EMAIL PROTECTED] wrote: The second GR was the cosmetic change one, which left us with a (new to some) interpretation including fonts, documentation and firmware as software needing source. Note that this consmetic change applied to the Social Contract, but not to the guidelines themselves. The DFSG still speaks of programs and not works. This is a hole that shouldn't exist in the first place... Mike -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 12:57:58PM -0600, Hubert Chan wrote: On Wed, 23 Aug 2006 15:25:49 -0700, Steve Langasek [EMAIL PROTECTED] said: N.B., I would object to having any ballot options on the same GR that consist of this same draft with point #4 stricken, because assuming rational voters I would expect the voters who approve of that option to be a strict superset of those who approve of my proposal, and I would call on the Project Secretary to exercise his authority to keep these two proposals on separate ballots to avoid prejudicing the outcome in favor of a watered down option. Maybe I don't quite understand your concern correctly, but isn't this one of the advantages of using Condorcet? i.e. if we had points [1-3] on the same ballot as points [1-4], even though the number of votes for [1-3] compared to NOTA would obviously be higher than the number of votes for [1-4] compared to NOTA, the thing that would determine whether [1-3] wins, or [1-4], would be the ranking between those two options (assuming both win compared to NOTA). So those who agree with point 4 should rank [1-4] higher than [1-3] (and those who don't would obviously rank it lower). Hence if more people agree with #4 than disagree with it, then [1-4] should win over [1-3]. http://lists.debian.org/debian-vote/2003/10/msg00168.html This old thread describes a mechanism by which to ensure that any resolution fails by losing out to a watered-down version of itself, regardless of how much support the resolution in question enjoys among developers. Our voting mechanism is *clone*proof, preventing multiple identical ballot options from influencing the outcome; but it's not proofed against influence by toothless variants that will inevitably appeal to a broader constituency because they say less of substance. Cheers, -- 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/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 11:28:02AM +0200, Aurelien Jarno wrote: This is a good proposition, as it does not allow firmwares already in non-free (eg madwifi) to go into main. This is a bad example, as the madwifi HAL case is *not* a firmware: the code is executed on the host CPU. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 03:42:28PM -0700, Steve Langasek wrote: On Thu, Aug 24, 2006 at 12:57:58PM -0600, Hubert Chan wrote: On Wed, 23 Aug 2006 15:25:49 -0700, Steve Langasek [EMAIL PROTECTED] said: N.B., I would object to having any ballot options on the same GR that consist of this same draft with point #4 stricken, because assuming rational voters I would expect the voters who approve of that option to be a strict superset of those who approve of my proposal, and I would call on the Project Secretary to exercise his authority to keep these two proposals on separate ballots to avoid prejudicing the outcome in favor of a watered down option. Maybe I don't quite understand your concern correctly, but isn't this one of the advantages of using Condorcet? i.e. if we had points [1-3] on the same ballot as points [1-4], even though the number of votes for [1-3] compared to NOTA would obviously be higher than the number of votes for [1-4] compared to NOTA, the thing that would determine whether [1-3] wins, or [1-4], would be the ranking between those two options (assuming both win compared to NOTA). So those who agree with point 4 should rank [1-4] higher than [1-3] (and those who don't would obviously rank it lower). Hence if more people agree with #4 than disagree with it, then [1-4] should win over [1-3]. http://lists.debian.org/debian-vote/2003/10/msg00168.html Sorry, let's get a more refined reference here; the thread following from that particular post is long and scary, and mostly irrelevant to this discussion. http://lists.debian.org/debian-vote/2003/11/msg00051.html http://lists.debian.org/debian-vote/2003/11/msg00066.html http://lists.debian.org/debian-vote/2003/11/msg00074.html -- 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/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 08:29:49PM +0200, Kurt Roeckx wrote: On Thu, Aug 24, 2006 at 01:16:42AM -0700, Steve Langasek wrote: Point 3 then seems to go the other way around and say we don't need sources for of few types of works. My main problem with this is that still a little vague about which types of works don't require source. What problems do you consider this vagueness to cause? What changes would you suggest to make this less vague? It lists images, video, and fonts. And I'm assume it's going to cover more than just that. I'm also not sure that this is something we want for all types of data. I think we *want* the best possible form for modification for all types of data. I don't think the DFSG *requires* this, and therefore I don't think *we* should require it. Do you disagree? For instance when they're raster images or fonts, I'd rather have the source, if there ever was a vector based format of it. But I don't care if there never was a vector based format, so nothing that would be a more prefered way of changing it. Rather have != Insist on for inclusion in main, though? Anyway, the answer I had in mind was a hex editor or a decompiler. If the firmware in question *is* code, and we know what the chip in question is that the code is running on, both options seem within the realm of plausibility to me. No, of course they're not the *ideal* means of editing such a work, but AFAIK most firmware is on the order of what programmers used to program directly in assembly, so it's also not totally *insane* to try to edit such a binary directly as it would be for most modern userspace apps, for instance.) I don't see a hex editor useful for much, and a decompiler only slightly better. If a decompiled version was useful to do derived work, it would be the same as source, so not requiring source doesn't make sense to me. The difference with source is that you actually have names of functions and variables, you have comments with it. Those things make it easy to understand what it's trying to do. So it's easier to make changes too. OTOH, the source may require a non-free tool to render it into a binary firmware form. If you don't have that tool, and maybe even no hope of getting access to it, is it any longer evident that the source is more useful than the binary for derived works? Yes, from there we get into discussions about defining source as whatever form people prefer to work from -- hmm, redefinition? -- and whether we can ship anything in main that we don't have a full toolchain for; but a) is that actually required by the DFSG, and b) is that the right standard to set, either today or in the future? It would also be useful to have a list of firmwares we're currently are talking about, and what license they have. Are there any that only fail DFSG 2, or will this part of GR have no effect at all? Larry Doolittle has prepared a very helpful table at http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html. A number of these are marked as being under a BSD-ish license, which would qualify; a number of others are listed as GPL but sourceless, which nominally makes them non-distributable, but it seems unlikely that any copyright holders on these would refuse to relicense under more appropriate terms even if they weren't willing/able to release source. Cheers, -- 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/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, Aug 24, 2006 at 10:21:21AM -0500, Manoj Srivastava wrote: N.B., I would object to having any ballot options on the same GR that consist of this same draft with point #4 stricken, because assuming rational voters I would expect the voters who approve of that option to be a strict superset of those who approve of my proposal, and I would call on the Project Secretary to exercise his authority to keep these two proposals on separate ballots to avoid prejudicing the outcome in favor of a watered down option. Speaking with my secretary hat on, it seems to me that options 3 and 4 are somewhat orthogonal -- inasmuch that it appears eminently reasonable for someone to have differing opinions on these two options. So people may approve of 3, and disapprove of 4: and this makes me think that they do not belong on the same ballot, since they are unrelated wrt to voting (though obviously addressing related areas) I agree that points 3 and 4 are potentially orthogonal, but I believe I have the right under the constitution to ask for the project to vote on a resolution that includes both of these points. If someone were to bring an amendment that eliminates point 4 while leaving the rest of the resolution intact and unchanged, those two ballot options would have orthogonal elements, and I would ask that they be treated on separate ballots so that voters have the opportunity to vote on this position statement per se without having to compete with ballot options that remove one of the axes of content. -- 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/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
Hi Steve and others, On Tue, Aug 22, 2006 at 03:18:04PM -0700, Steve Langasek wrote: 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. I am in the NM queue, so my opinion does not matter, but still... I cannot stay silent reading that. :) I will attempt to make it short for you to grasp quickly my worried viewpoint for Debian. I know dead right that users want their peripherals to work without recompiling external drivers not present in the archive. They even want to get their peripherals to work at the debian-installer stage which is quite natural. Being involved in hardware - software low-level development, I can assure you that what is called a firmware is considered a program in my world of understanding: it may bug, follows an algorithm, does loops, and so on... Okay, you can argue that I play on words and so can I for you, but words hold defined meanings, otherwise we would not be able to communicate. :) Some years ago, that situation did not happen or only marginally, since firmware were often located in ROM chips, but in these last few years, hardware makers started to distribute more and more the firmware in the driver. The driver runs on the host CPU and it uploads the firmware to the hardware. There has always been firmware in hardware, at least only to provide a suitable interface for the main CPU to interact with, so this is not abnormal to talk about firmware. The firmware was executed on a micro-controller years ago and even hardcoded in the chip static logic years before, but nowadays, the tendency is to embed in hardware more and more modern CPU cores instead of micro-controllers... And guess what we can run on modern CPU cores with even sometimes a MMU? Well, the Linux or ucLinux kernels. Unfortunately, I consider both as programs. Therefore, I am worried for Debian to make its Debian Free Software Guidelines cross the border of the Free Software philosophy on the firmware issue. I do not deny there is an issue with firmware not being in ROM anymore which was their place. They are now being forced upon kernel drivers to be distributed and thus upon Debian which distributes those drivers. However, I do not think altering the DFSG in an abrupt way like this suites the Free Software philosophy. To my mind, it is only refusing blindly to consider their is another world besides the main CPU of a modern computer, such as a GPU, a specific cryptographic unit, or anything new you can imagine. :) Firmware are so very purpose-specific programs compared to other normal any-day programs that my idea would be to propose another section besides main, contrib, and non-free. Therefore, instead of declaring in the DFSG that firmware are not programs, but only data, maybe the firmware might be cleanly included into a new section such as firmware. That section might be considered as compatible with main. A description of the firmware section might be: hardware specific code for the kernel driver to interact with, once uploaded into the hardware by the driver. Cheers, -- .''`. Aurélien GÉRÔME : :' : `. `'` Free Software Developer `- Unix Sys Net Admin signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, 24 Aug 2006 17:08:33 -0700, Steve Langasek [EMAIL PROTECTED] said: OTOH, the source may require a non-free tool to render it into a binary firmware form. If you don't have that tool, and maybe even no hope of getting access to it, is it any longer evident that the source is more useful than the binary for derived works? But if you, as a user, do have such tools, then having the sources around is a freedom that could be important for you. So that software, if it shipped with source, will give some additional freedoms, perhaps to only a subset of our users. One should not that the freedom granted to some users does not detract from the freedom of other users. manoj -- Every man is as God made him, ay, and often worse. Miguel de Cervantes Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, 24 Aug 2006 17:35:34 -0700, Steve Langasek [EMAIL PROTECTED] said: On Thu, Aug 24, 2006 at 10:21:21AM -0500, Manoj Srivastava wrote: N.B., I would object to having any ballot options on the same GR that consist of this same draft with point #4 stricken, because assuming rational voters I would expect the voters who approve of that option to be a strict superset of those who approve of my proposal, and I would call on the Project Secretary to exercise his authority to keep these two proposals on separate ballots to avoid prejudicing the outcome in favor of a watered down option. Speaking with my secretary hat on, it seems to me that options 3 and 4 are somewhat orthogonal -- inasmuch that it appears eminently reasonable for someone to have differing opinions on these two options. So people may approve of 3, and disapprove of 4: and this makes me think that they do not belong on the same ballot, since they are unrelated wrt to voting (though obviously addressing related areas) I agree that points 3 and 4 are potentially orthogonal, but I believe I have the right under the constitution to ask for the project to vote on a resolution that includes both of these points. If someone were to bring an amendment that eliminates point 4 while leaving the rest of the resolution intact and unchanged, those two ballot options would have orthogonal elements, and I would ask that they be treated on separate ballots so that voters have the opportunity to vote on this position statement per se without having to compete with ballot options that remove one of the axes of content. Condorcet does not do well with options with multiple axes of content. If we have two orthogonal options, A an B, on a ballot, than the ballot becomes: 1) No on A, No on B 2) No on A, Yes on B 3) Yes on A, no on B 4) Yes on A, Yes on B 5) Further discussion. Add any other axes, and the ballot rapidly becomes more complex. I think we should only put an proposal and _related_ options on the same axis on each ballot, in order to offer fully nuanced choices to the voting populace. This also avoids the diluted proposal wins bit if some ballot option reduced the axes of content. manoj -- Tcl tends to get ported to weird places like routers. Larry Wall in [EMAIL PROTECTED] Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 22, 2006 at 03:18:04PM -0700, Steve Langasek wrote: The application of DFSG#2 to firmware and other data The Debian Project recognizes that access to source code for a work of software is very important for software freedom, but at the same time source is often not a well-defined concept for works other than those traditionally considered programs. The most commonly cited definition is that found in version 2 of the GNU GPL, the preferred form of the work for making modifications to it, but for non-program works, it is not always clear that requiring this source as a precondition of inclusion in main is in the best interest of our users or advances the cause of Free Software: - The author's preferred form for modification may require non-free tools in order to be converted into its final binary form; e.g., some device firmware, videos, and graphics. - The preferred form for modification may be orders of magnitude larger than the final binary form, resulting in prohibitive mirror space requirements out of proportion to the benefits of making this source universally available; e.g., some videos. - The binary and source forms of a work may be interconvertible with no data loss, and each may be the preferred form for modification by different users with different tools at their disposal; e.g., some fonts. While the Debian Free Software Guidelines assert that source code is a paramount requirement for programs, they do not state that this is the case for non-program works, which permits us to consider whether one of the above points justifies a pragmatic concession to the larger context within which Free Software operates. THE DEBIAN PROJECT therefore, 1. reaffirms its dedication to providing a 100% free system to our users according to our Social Contract and the DFSG; and 2. encourages authors of all works to make those works available not only under licenses that permit modification, but also in forms that make such modifications practical; and 3. supports the decision of the Release Team to require works such as images, video, and fonts to be licensed in compliance with the DFSG without requiring source code for these works under DFSG #2; and 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. == Seconded. Aníbal Monsalve Salazar -- http://v7w.com/anibal signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Thu, 24 Aug 2006 16:25:48 -0700, Steve Langasek [EMAIL PROTECTED] said: On Thu, Aug 24, 2006 at 03:42:28PM -0700, Steve Langasek wrote: On Thu, Aug 24, 2006 at 12:57:58PM -0600, Hubert Chan wrote: [...] Maybe I don't quite understand your concern correctly, but isn't this one of the advantages of using Condorcet? i.e. if we had points [1-3] on the same ballot as points [1-4], even though the number of votes for [1-3] compared to NOTA would obviously be higher than the number of votes for [1-4] compared to NOTA, the thing that would determine whether [1-3] wins, or [1-4], would be the ranking between those two options (assuming both win compared to NOTA). So those who agree with point 4 should rank [1-4] higher than [1-3] (and those who don't would obviously rank it lower). Hence if more people agree with #4 than disagree with it, then [1-4] should win over [1-3]. http://lists.debian.org/debian-vote/2003/10/msg00168.html Sorry, let's get a more refined reference here; the thread following from that particular post is long and scary, and mostly irrelevant to this discussion. http://lists.debian.org/debian-vote/2003/11/msg00051.html http://lists.debian.org/debian-vote/2003/11/msg00066.html http://lists.debian.org/debian-vote/2003/11/msg00074.html Hmm... interesting. Thanks for the references. I don't quite fully understand it yet, so I'll have to think about it more. But the attack seems to depend on the supermajority requirement. I'm not sure if it still works if a simple majority is required. -- Hubert Chan - email Jabber: [EMAIL PROTECTED] - http://www.uhoreg.ca/ PGP/GnuPG key: 1024D/124B61FA (Key available at wwwkeys.pgp.net) Fingerprint: 96C5 012F 5F74 A5F7 1FF7 5291 AF29 C719 124B 61FA -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
late for party (was Re: Proposal: The DFSG do not require source code for data, including firmware)
Hi - Sorry I'm late for the party. I'm on travel, with less than ideal 'net connections. Reading 147 messages on d-v over a hotel's erratic wireless link was not fun. Moritz Muehlenhoff wrote in http://lists.debian.org/debian-vote/2006/08/msg00117.html None of the trolls demanding the removal of firmware from main has ever done significant work to resolve this upstream. As one of the trolls who points out that non-free firmware doesn't belong in main, I wish to also point out that Debian's etch release plan doesn't permit this to be resolved upstream, since 2.6.18 is nearly out, and that's what Debian's etch kernel will be based on. My understanding is that upstream has not been entirely receptive to patches that remove non-free firmware from it. Maybe that's because they don't have an established firmware-nonfree project (like Debian does) into which to move that firmware? Matthew Garrett wrote in http://lists.debian.org/debian-vote/2006/08/msg00116.html: Do you believe that hardware with the firmware in ROM is preferable (from a pure freedom point of view) to hardware with firmware loaded by the OS? Hardware that is shipped with defective firmware in EEPROM is defective, and can be returned to the manufacturer under warranty. The owner of hardware that is useless because of defective firmware shipped in the Linux kernel has no such recourse. Florian Weimer wrote in http://lists.debian.org/debian-vote/2006/08/msg00068.html A completely different issue is whether we take upstream's word for GPL compability, or if we claim that something is not redistributable because it contains a firmware blob *and* is licensed under the GPL as a whole. A consensus of DD that firmware is not software carries no legal weight. 44 of the sourceless-firmware-contaminated files in the Linux kernel are claimed to be covered by the GPL. There is no legal way for Debian to redistribute those files, since we can't provide that source to people who attempt to exercise their GPL-mandated rights. The best that a GR could do would be to permit Debian to distribute the 12 BSD-ish licensed sourceless-firmware-contaminated files to be distributed in main instead of non-free. Better might be to relabel the Linux kernel non-free. Before you ask, no, 44+12 != 59. There are three s-f-c Linux kernel files that are neither GPL nor BSD-ish. Check out for yourself if you think Debian should redistribute them. I have research in progress that I hope will start the ball rolling to find out which of those s-f-c GPL's programs could be relicensed. Sorry, nothing to report yet. Watch for it in d-k. Mike Hommey wrote in http://lists.debian.org/debian-vote/2006/08/msg00171.html Note that there are more and more applications trying to use the power of the GPU for computation. The hole should not be left open in the GR. Right. Here's a thought experiment for those who would call non-free firmware suitable for main: if Macromedia^WAdobe distributed a Linux Flash plug-in that only worked on nVidia graphics cards, because it downloaded critical parts of the Flash interpreter (in binary form, without source code, of course) to the GPU and executed it there, would you consider that program valid for Debian main? Pierre Habouzit wrote in http://lists.debian.org/debian-vote/2006/08/msg00159.html * if there is no source, but that the blob is modifiable, redistribuable, ... then we tolerate it in main. Hmm. Case 1: the blob is under the GPL. You can't distribute it, even under non-free, and even if you split out the firmware, because you can't satisfy requests for source. Case 2: the blob is under BSD-ish terms. Why _not_ move the firmware to non-free? Keeping it under free is disingenuous, since it doesn't satisfy DFSG. The license is entirely compatible into a (free source/nonfree firmware) architecture, just like 47 other extant drivers in the Linux kernel. Marco d'Itri wrote in http://lists.debian.org/debian-vote/2006/08/msg00166.html I think we should learn from OpenBSD on this front. I agree. Indeed, the OpenBSD project not only distributes sourceless firmwares, but also sourceless firmwares with a license which forbids modifications and reverse engineering. Care to back up that statement? It runs 180 degrees counter to my understanding of OpenBSD. Sven Luther wrote in http://lists.debian.org/debian-vote/2006/08/msg00125.html I would indeed vote for a solution including a non-free hardware, or even better an additional CD, which contained a non-free version of d-i (which need to include certain non-free firmwares and drivers in the images), and all the additional non-free firmware stuff. This way, we could add a list of pci ids needding non-fre hardware, and do a check pretty early in the installer, and if those non-free hardware is found, inform the user about it, and use the non-free installer CD instead, and all the rest would be taken care for him. Nice idea, Sven. Do you really
Re: Proposal: The DFSG do not require source code for data, including firmware
Seconded. * Steve Langasek [EMAIL PROTECTED] [2006-08-22 15:18]: The application of DFSG#2 to firmware and other data The Debian Project recognizes that access to source code for a work of software is very important for software freedom, but at the same time source is often not a well-defined concept for works other than those traditionally considered programs. The most commonly cited definition is that found in version 2 of the GNU GPL, the preferred form of the work for making modifications to it, but for non-program works, it is not always clear that requiring this source as a precondition of inclusion in main is in the best interest of our users or advances the cause of Free Software: - The author's preferred form for modification may require non-free tools in order to be converted into its final binary form; e.g., some device firmware, videos, and graphics. - The preferred form for modification may be orders of magnitude larger than the final binary form, resulting in prohibitive mirror space requirements out of proportion to the benefits of making this source universally available; e.g., some videos. - The binary and source forms of a work may be interconvertible with no data loss, and each may be the preferred form for modification by different users with different tools at their disposal; e.g., some fonts. While the Debian Free Software Guidelines assert that source code is a paramount requirement for programs, they do not state that this is the case for non-program works, which permits us to consider whether one of the above points justifies a pragmatic concession to the larger context within which Free Software operates. THE DEBIAN PROJECT therefore, 1. reaffirms its dedication to providing a 100% free system to our users according to our Social Contract and the DFSG; and 2. encourages authors of all works to make those works available not only under licenses that permit modification, but also in forms that make such modifications practical; and 3. supports the decision of the Release Team to require works such as images, video, and fonts to be licensed in compliance with the DFSG without requiring source code for these works under DFSG #2; and 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. == -- Martin Michlmayr http://www.cyrius.com/ signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
[Steve Langasek] That's an interesting point. Can you elaborate on how you see this being a loophole, in a sense that having the firmware on a ROM wouldn't also be? The day Debian begins to distribute ROM chips, or devices containing ROM chips, I will expect those chips to come with source code. Until then, this is a red herring. signature.asc Description: Digital signature
Re: Proposal: The DFSG do not require source code for data, including firmware
I second the proposal below. The application of DFSG#2 to firmware and other data The Debian Project recognizes that access to source code for a work of software is very important for software freedom, but at the same time source is often not a well-defined concept for works other than those traditionally considered programs. The most commonly cited definition is that found in version 2 of the GNU GPL, the preferred form of the work for making modifications to it, but for non-program works, it is not always clear that requiring this source as a precondition of inclusion in main is in the best interest of our users or advances the cause of Free Software: - The author's preferred form for modification may require non-free tools in order to be converted into its final binary form; e.g., some device firmware, videos, and graphics. - The preferred form for modification may be orders of magnitude larger than the final binary form, resulting in prohibitive mirror space requirements out of proportion to the benefits of making this source universally available; e.g., some videos. - The binary and source forms of a work may be interconvertible with no data loss, and each may be the preferred form for modification by different users with different tools at their disposal; e.g., some fonts. While the Debian Free Software Guidelines assert that source code is a paramount requirement for programs, they do not state that this is the case for non-program works, which permits us to consider whether one of the above points justifies a pragmatic concession to the larger context within which Free Software operates. THE DEBIAN PROJECT therefore, 1. reaffirms its dedication to providing a 100% free system to our users according to our Social Contract and the DFSG; and 2. encourages authors of all works to make those works available not only under licenses that permit modification, but also in forms that make such modifications practical; and 3. supports the decision of the Release Team to require works such as images, video, and fonts to be licensed in compliance with the DFSG without requiring source code for these works under DFSG #2; and 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. === === Cheers, pgpuCvG7r8WYJ.pgp Description: PGP signature
Re: Proposal: The DFSG do not require source code for data, including firmware
On Wed, Aug 23, 2006 at 01:12:25AM +0100, Stephen Gran wrote: I would like to see some language to the effect that we make the exception for firmware only in the cases of data that use the moral equivalent of the kernel load_firmware interface, so that it's clear we aren't talking about the sort of completely non-free things like that adsl driver with a userspace binary library or the drivers from sangoma's site. First of all, I'm not asking for an exception; I'm asking the project to confirm whether programs should be understood to include firmware. Only if the project votes this GR down would it be time to consider making exceptions (which would definitely require 3:1 majority), I think. I would welcome any suggestions about how to make the language of the resolution clearer on this point. That said, then, I'm not sure there's any value in worrying over wording to make it clear that userspace binary libraries aren't covered. AFAIK, no one is arguing that such a library isn't covered by DFSG #2 because it's not a program; it's clear to me that it is part of a program when used, and is covered by DFSG #2. If someone did try to claim it wasn't covered by DFSG #2, we would have to amend the DFSG to close whatever loophole they were using, and I don't think it's worth speculating about what that loophole would be before someone actually tries it, so I don't see any point in tying this GR to a DFSG amendment unnecessarily. OTOH, if you think people -- either Debian developers or others in the community -- will be confused into thinking this GR means closed userspace tools are also ok, then by all means please tell me where you think the ambiguities lie so that we can eliminate them. Cheers, -- 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/ signature.asc Description: Digital signature
calling firmware code data is not being honest with ourselves, includes counterproposal and RFC on a possible Amendment (Was: Proposal: The DFSG do not require source code for data, including firmware
On Tue, Aug 22, 2006 at 03:18:04PM -0700, Steve Langasek wrote: Hi folks, Ever since the sarge release, an ongoing question has been: what do the DFSG require for works that are not programs as previously understood in Debian? Several rounds of general resolutions have now given us answers for some subclasses of non-program works, but debate still rages regarding one particularly important class: firmware for peripheral devices. Andi Barth and I have discussed how we think the DFSG requirements apply to firmware and have fairly similar views on the subject, but we also know that there are other viewpoints within the project, so we're reluctant to make a unilateral decision about firmware handling for the etch release policy without finding out how the project as a whole feels about it. In the meantime, the ongoing discussions within the kernel team and without have shed, as they say, more heat than light on the subject, so I feel it's time to answer this question so we can stop being paralyzed by these differences of opinion, agree to disagree, and move forward with the work that needs to be done for etch -- whichever set of work we decide that is. So below is a proposal that I'm seeking seconds on to establish how DFSG#2 should be understood to apply to firmware -- i.e., that for Debian's purposes firmware should be considered data, not programs, and along with ... 4. determines that for the purposes of DFSG #2, device firmware shall also not be considered a program. Hello, As i have warned you on irc, when you first asked the kernel team about this GR, i think that the whole reasoning you propose is flawed, based on patently wrong assumptions. There is no way you can just decide that firmware is not code, especially as there is overwhelming evidence in some case that it is indeed code (or microcode as some call it), ranging from declaration on the LKML mailing list by the drivers author, or when the peripheral processor holds a mips or arm or whatever core. Sure, other firmware cases consist of only register dumps, but my own involvement in hardware development shows me that the trend is more and more for peripheral hardware with embedded processor cores, and the firmware of those being actual processors, some of them could run some variant of linux (or uclinux at least) in their own right. This is especially true for high-end raid cards and wireless applications. Trying to argue, as other did before you, that it is just data, because that is more convenient, thus ignoring the facts, is kind of misleading and dishonest, and furthermore is the wrong strategical choise for debian, who has long stood for free software, and would thus compromise its ideals for the sake of convenience. Furthermore, if you start going down this way, ignoring blatant issues like the lack of source code for those firmware blobs, some of which are defacto under GPL, and thus becoming fully non-distributable, and making the linux kernel non-distributable, then you take the first step down a road debian doesn't want to go. You will have to consider cases like the unicorn driver (currently in non-free), which includes a soft-adsl binary-only library, or issues like tge miboot bootloader, which includes a half sector of m68k instructions, copyrighted by apple, and very analogous to the firmware case, and then from there, you have to go further, and if you are true to yourself, end up allowing everything in main. Notice also that in the social contract, we already claim to support our users and free software equally, and that we furthermore agreed to keep non-free around for exactly those users needing non-free components, like those non-free drivers or firmware, and there only needs to be a relatively small technical work to be done for this to work seamlessly for all users. So, if we of debian want to stay true to ourself, and not live in self-deception just because it convenience us, then the right argumentation on this should be of the following : 1) We aknowledge that there are some firmware blobs which consist of actual code running on an processor embedded in a peripheral device, or configuration code for fpgas and such, as opposed to pure register dumps, which need actual source code to be considered free enough to pass the DFSG. 2) But, as the removal of those firmwares and drivers cause a major inconvenience on the usability of the system, and 3) Peripherals allowing for uploadable firmwares are orders of magnitude more free than peripheral where everything is hardcoded, or peripherals where the firmware blob is embedded on a rom or flash or similar. 4) Upstream has long resisted considering the firmware situation, and is now slowly setting up infrastucture to handle these cases, and removing those firmwares from the main linux code, so the problem, will solve itself in the future. 5) There is no way the kernel team alone or even with help, can
