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
Amendment: special exception for firmware because of technical limitations
I propose the following amendment to Steve's proposal. 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 as a special exception to DFSG #2, the source code for device firmwares contained in the kernel packages will not be required as long as there are no other technical means to install and run the Debian system on these devices. Rationale: most of us want to release etch ASAP, and most of us want to remove the firmwares from the kernel ASAP. This is a way that shouldn't stop the ongoing work on both of these issues. The wording makes it clear that as soon as the kernel and d-i are able to use split out firmwares, the migration will have to be done. This way we won't discourage the work from Nathanael Nerode and other people who worked hard so far to remove the non-free blobs, and we won't hold etch development because of that issue. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
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: Amendment: special exception for firmware because of technical ?limitations
[EMAIL PROTECTED] wrote: Rationale: most of us want to release etch ASAP, and most of us want to remove the firmwares from the kernel ASAP. This is a way that shouldn't This is false: most of us do not mind at all distributing sourceless (or even not modifiable) firmwares in the kernel packages. stop the ongoing work on both of these issues. The wording makes it clear that as soon as the kernel and d-i are able to use split out firmwares, the migration will have to be done. This way we won't discourage the work from Nathanael Nerode and other people who worked hard so far to remove the non-free blobs, and we won't hold etch development because of that issue. We are not discouraging them, the upstream kernel maintainers did when they clearly showed that they could not care less about their patches. -- ciao, Marco -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Amendment: special exception for firmware because of technical ?limitations
Le samedi 26 août 2006 à 11:50 +0200, Marco d'Itri a écrit : [EMAIL PROTECTED] wrote: Rationale: most of us want to release etch ASAP, and most of us want to remove the firmwares from the kernel ASAP. This is a way that shouldn't This is false: most of us do not mind at all distributing sourceless (or even not modifiable) firmwares in the kernel packages. Please, let's not argue about what people think. There is a vote for that. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: Ceci est une partie de message numériquement signée
Re: Amendment: special exception for firmware because of technical ?limitations
On Sat, Aug 26, 2006 at 11:50:11AM +0200, Marco d'Itri wrote: Rationale: most of us want to release etch ASAP, and most of us want to remove the firmwares from the kernel ASAP. This is a way that shouldn't This is false: most of us do not mind at all distributing sourceless (or even not modifiable) firmwares in the kernel packages. I don't think you can legitimately claim to speak for *most* developers on this issue. -- 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
[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: Amendment: special exception for firmware because of technical ?limitations
[EMAIL PROTECTED] wrote: Rationale: most of us want to release etch ASAP, and most of us want to remove the firmwares from the kernel ASAP. This is a way that shouldn't This is false: most of us do not mind at all distributing sourceless (or even not modifiable) firmwares in the kernel packages. I don't think you can legitimately claim to speak for *most* developers on this issue. And I have no intention of doing it, I merely noted what has been and still is the prevalent opinion on the issue that can be observed on our mailing lists and in its practical effects: it's obvious that there is only a small number of people, some of them not even developers, who want to remove the firmwares from the kernel ASAP. -- 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 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: Proposal: Source code is important for all works in Debian, and required for programmatic ones
On Fri, 25 Aug 2006, Enrico Zini wrote: In this view, I see two problems with your GR: 1. It needs a separate vote to affirm we happen to need it. Yes, that's by design. IMO such a exception to the SC/DFSG should be addressed explicitely by a GR doing exactly that and specifically setting aside the source requirements for specific works (or classes of work) in main. 2. It would make the exception etch-specific, just like we previously made a sarge-specific exception, and now we have to vote on the same issue again. I feel this issue is subtly different from the sarge question, but regardless, since it's something that compromises our ethics, I think it's good for us to revisit the decision each time and put pressure on ourselves to resolve the problem so that we don't have to compromise. Plus, we have to have a few good topics to flame about or the lists get boring. I understand that the urgent issue is are we ok in having sourceless firmware in etch?, and I think it's a waste of time to vote a GR that doesn't address that. The current GR is asking Does the Social Contract/DFSG require source for programmatic works in main which do not run on the CPU? as opposed to this question. I believe the answer to the current GR's question is yes, which is why I proposed this amendment. I agree that the question you're interested in answering is the more important question, which, so far, is the question which has not been asked or a GR proposed to deal with. [Presumably, it is to be proposed if my option succeeds.] In framing my amendment, I have assumed that this question was orthogonal, and so I've not dealt with it. Don Armstrong -- All bad precedents began as justifiable measures. -- Gaius Julius Caesar in The Conspiracy of Catiline by Sallust http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
