On Mon, Apr 26, 2004 at 02:01:10PM -0400, Joey Hess wrote: (...) > > b. As firmware support is dropped from the debian kernel, document it. > Refer angry users to debian-devel and Fedora. Release as soon as sarge > is otherwise ready. This is the one I (and I believe our users and many dds) would prefer most. (...) > What's currently strongly tipping me toward option b. despite not having > all the numbers handy, is that there's a good chance that if sarge is > delayed until next year, it is effectively delayed until when we would > have released sarge+1, if this mess had not happened. As such, a sarge > release now can only help us, since it will be better than no release > for some nonzero subset of our users. I agree wholeheartedly with you. Unless we are capable of _right_now_ strip off all the non-DFSG software/firmware/data/you_name_it in a 3.0r3 release we are better off releasing sarge right away. Acknowledging (sp?) we have a lot to do regarding purging/replacing non-DFSG stuff and stating the fact that we are going to do it. We would be in a similar philosophical (or even legal) position if we ship sarge than if we kept woody as-is (with all the non-DFSG stuff in either one). Obviously, releasing sarge now would only be to the benefit to our users, which is also a requirement of our SC. Now, even before we can commence an audit for non-DFSG stuff we have to decide which stuff is non-DFSG. Many people believe GFDL stuff is not DFSG-free, but there has not been an _official_ statement by the project related to it. Has there been one? (besides -legal discussions, which I've tried to follow) We have not, similarly, discussed what data will be affected by this review: will it be bmp/jpg/png images? will it be also fonts? will it be some other kind of binary data we are not aware exists in Debian?  Or even, what should these data be licensed as. Clearly, the GPL does not cover that data properly as the FSF has acknowledged himself. Regards Javier PS: Just for the record, I was away on VAC when this GR was voted and, after reviewing my e-mail, I also considered the "Editorial" change a minor change, like (obviously) many other dds. Still, I'm willing to stick with "the purge", if we do it in a sensible way.  Consider for example the case I've brought up niche applications: astronomy software and star data catalogues. This includes: #108452 (closed), #198499 (closed), #198495 (closed), #225002 (open) and some others I've opened up recently.
Description: Digital signature