On Wed, Aug 23, 2006 at 09:09:31AM +0200, Sven Luther wrote: > 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), This GR doesn't use the word 'code'. > 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, This is FUD. Nothing in this proposal says that we will ignore licenses when distributing firmware or any other works. > 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. I would prefer it if you would strike references to "non-free" in the above and replace them with the term "sourceless", to keep the scope the same as the current GR proposal. With that change made, I would encourage you to propose the above as a formal amendment -- I would reject the amendment, of course, since it doesn't agree with my views on the matter, but I think it's a viewpoint that deserves to be represented on the ballot. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature