On Monday 18 September 2006 16:09, Nathanael Nerode wrote: > > The project acknowledges that a lot of progress has been made with > > regard to the removal from the distribution (main) of "software" that > > could be considered non-free given the current wording of the Social > > Contract. > > You mean "...that is non-free according to the Social Contract." > > I tire of hearing the completely invalid claim that the Social Contract > as written, now or before, can possibly allow non-free programs in main. I'm not advocating to keep it in main indefinitely, only to allow it in main for Etch. Also, I personally don't see why firmware that is properly licenced but is only lacking source needs to be non-free. IMO firmware by its nature is sufficiently different from "normal code" that some exceptions are acceptable for the good of our users. I do agree that having a source would be preferable and is something to strive for. > FYI: > This will require at a minimum (assuming undistributable firmware is > allowed in general) removal of lumps of hex from 13 files in the kernel. > The 'new' ones are noted at ldoolit's page: > http://doolittle.icarus.com/~larry/fwinventory/2.6.17.html My personal standpoint is that firmware that is properly licenced and this distributable can fall under exception. Firmware that is not should in principle not be included in Debian. > > (d) Following the release of etch, the Debian Project as a whole > > shall reopen the question of which commitments should be codified in > > the project's Social Contract. This shall include both an online > > consultation with Debian developers, users, Debian derivatives and the > > free software community, and a public in-person discussion at DebConf 7 > > in Edinburgh in honour of the 10th anniversary of the original > > publication of the Social Contract on the 4th of July 1997. > > As long as it's recalled that supermajority requirements are needed to > change the SC, great! Of course. > > - (almost) everybody agrees that sourceless firmware at least needs to > > be distributable before any kind of support can be considered; > > I think you're wrong here, unless you're using an unusual definition > of "distributable". The usual definition used by debian-legal is "We > have explicit legal permission to distribute it." If you were right, we > wouldn't have 46 undistributable files in Debian's Linux kernel packages > today. I have never followed d-legal. My definition would be "has by the copyright holder been put/made available under a licence that allows distribution". > > - probably a larger number feels that we should not kill the project > > As if anything suggested here would "kill the project". Hyperbole? Yes. > Implementations of firmware loading in the kernel are straightforward > at this point and require no discussion. They are all feasible, and > some are completed. Sure. That is not the issue here. The issue is supporting the Debian packaging of the firmware in an acceptable way in the installer and on installation media. > Details have not been worked out for d-i, but the implementation appears > to be 90% complete, and feasibility is definite. It's time for testing, > to find the "weak points". I beg to differ. > - Joey Hess has claimed that it will take upwards of six months to ready > the installer for loading firmware from non-free. However, it turns out > the majority of the work which he listed as necessary has *already been > done* and requires *no changes*. See Goswin von Brederlow's message at > http://lists.debian.org/debian-devel/2006/09/msg00017.html . Thanks for linking to that message. I had not seen that yet (partly due to my mailbox running full during my VAC and partly because that message, given its content, has a non-descriptive subject and is not on the optimal list for discussing implementing things in d-i). There a lot of interesting information in that mail, some of which is new to me. Wouldn't it have been nice if the split in the kernel had happened half a year earlier and people who obviously have relevant knowledge _and_ feel the subject is important had come forward to join the d-i team to solve this issue? Unfortunately that is not the case and it is now too late for implementation given the status of D-I in relation to Etch release planning. The target date of the D-I RC1 release has been communicated by the Debian RMs almost a year ago, so everybody could have known that structural changes at this late date would not be acceptable. > Charitably, I would like to assume Joey Hess was just ignorant of > the status of d-i. (I didn't know either.) Can you really blame someone for not being aware of a relatively minor technical detail that seems to have been implemented a long time ago but has never actually been used? I hope not. > But everyone is incompetent sometimes (consider my efforts to find the > d-i repo), and it's more charitable to assume incompetence. I'd appreciate it if you would retract the term "incompetent".
Attachment:
pgppXzRBlaYnP.pgp
Description: PGP signature