Kurt Roeckx a écrit :
I want to amendment the following proposal:=== START OF PROPOSAL === Definition: For the purpose of this resolution, the "firmware" mentioned below designates binary data included in some of the linux kernel drivers, usually as hex-encoded variables and whose purpose is to be loaded into a given piece of hardware, and be run outside the main memory space of the main processor(s). 0. This resolution overrides the resolution just voted (http://www.debian.org/vote/2006/vote_007). 1. We affirm that our Priorities are our users and the free software community (Social Contract #4); 2. We acknowledge that there is a lot of progress in the kernel firmware issue, both upstream and in the debian packaging; however, it is not yet finally sorted out. 3. We give priority to the timely release of Etch over sorting every bit out; for this reason, we will treat removal of problematic firmware as a best-effort process, and in no case add additional problematic material to the upstream released kernel tarball. 4. We allow inclusion of such firmware into Debian Etch, even if their license does not normally allow modification, as long as we are legally allowed to distribute them. 5. We further note that some of these firmware do not have individual license, and thus implicitly fall under the generic linux kernel GPL license. We will include these firmware in Debian Etch and review them after the release. Vendors of such firmware may wish to investigate the licensing terms, and make sure the GPL distribution conditions are respected, especially with regards to source availability. 6. We will include those firmware into the debian linux kernel package as well as the installer components (.udebs) used by the debian-installer. ==== END OF PROPOSAL ====And replace the text with: ==== BEGIN OF PROPOSAL ==== We, the Debian project, find freeness that we want for firmware used by the kernel is an important question, and that we will have to deal with this. However, we think that we as a project need more time to deal with it, and having more general resolutions isn't going to solve this. Therefor we will not have another general resolution about firmware until after the release of etch and atleast 6 moths have passed since this general resolution. This does not mean we will not discuss this issue, or work on getting things better. ==== END OF PROPOSAL ==== I'm open for suggestions on how to better word this.
Why are you trying to get a decision from Debian developers if the decision can be overridden by the release team as state in the "Release standards" [1]:
"Further to this, certain issues may be exempted from being considered release critical for etch by the release manager. This is expressed by tagging the report "etch-ignore"; this should not be done without explicit authorisation from the release manager." Aurelien [1] http://release.debian.org/etch_rc_policy.txt -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `- people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
