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 solve all the legal and technical issues in a timely fashion in order to not let the etch release slip. 6) Given the above, and the fact that every past release of debian included those non-free firmware blobs, the fact of delaying etch in order to solve the issue, or releaseing etch with the non-free firmware blobs and then working the solution, is not going to change anything with respect of the released and development versions of debian. 6) We thus ask the project to temporarily waive the DFSG requirement for those non-free firmware blobs, in order to let the etch release to ship in a timely fashion, and let us work on these issues, within the kernel and related affected teams, the project as a whole (The DPL could mandate a delegate or delegate team to contact manufacturers and such), but also upstream, in a calm and posed way, not hurried by the needs of the release, and other such pressure. I welcome help to turn the above in a GR, as i believe that this would be a better and more honest way to allow non-free firmware in main, in all good concience. This cannot be solved in a satisfactory manner by deluding ourselves and the world at large, and it is always best to face reality, and call things as they are, instead of what is attempted here. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
