Hi, On Thu, Apr 29, 2004 at 09:45:18AM +1000, Craig Sanders wrote: > On Tue, Apr 27, 2004 at 08:41:35PM -0500, Steve Langasek wrote: ... > > 1. that the amendments to the Social Contract contained within the > > General Resolution "Editorial Amendments To The Social Contract" > > (2004 vote 003) be immediately rescinded; ... > i propose an amendment that deletes everything but clause 1 of this proposal, > so that the entire proposal now reads: > > that the amendments to the Social Contract contained within the > General Resolution "Editorial Amendments To The Social Contract" > (2004 vote 003) be immediately rescinded. I second this. (I also seconded Colin's one. That was the safe fall back option for me.) Since there seem to be no delay requirements for rescinding already decided GR, I guess this is a fair game now. (In future, it may be a good idea to limit/delay on proposing rescinding, at the same time increasing quorum for the 3:1 majority requiring GR, though.) Here is my thought. The old SC "1. Debian Will Remain 100% Free Software" was only for ambiguous entity called "software". This ambiguity was good. Font, documentation, firmware, data, ... are different issues. It is nice to have them comply with fully with DSFG, sometimes it is not practical. Strong push of DSFG to all components is good thing to have but unpractical and pedantic application of DSFG to these benefits none. Common sense shall dictate how far the word "software" shall be interpreted. Technology is a moving target and pedantic discussion on what the word "software" means is not much useful until we face with each concrete case and weigh the benefit and liability. For example, I think removing firmware support to the network devices, graphic card, etc. from the "Official" Debian boot CD#1 will be pity since it hinders usefulness of Debian. So they should be included even when these firmware data do not comply with DSFG in the strict sense. I also do not consider that all loadable binary hardware data such as firmware are all eligible being in main. Some shall be OK, others shall be rejected from Debian main based on the common sense interpretation of "software". So drawing a hard line based on a word "firmware" is also dangerous one. Case studies: * GPU acceleration routine binary firmware data used to draw graphics image to the screen. (Yes to main) * Loadable binary data (without source code) to the coprocessor (or GPU) whose instruction set is published and its functionality is to provide a functionality similar to the one provided by the standard library function one on main CPU? (No to main) * Driver binary data for network cards which have some DSP/CPU type devices and which store these driver program data on the RAM of the card. This driver also have encryption capability which will be used for communication with external device. (Yes to main.) * Alternative driver binary data for the above network cards. This binary data provides a function call service which returns encrypted data back to the main system. The CPU instruction set is unknown. (I will accept it being in main but I do not mind it being in non-free.) * What are we going to do with binary configuration data for FPGA like device which may be functioning as the ix86 or ARM compatible main processor and where no "free" tool is available to create it from the source? (Yes to main but I have not seen such a computer yet.) Similar situation exist for the documentation, font, ... Discussion on the removal of unmodifiable standard documents from the main looked to me nothing but pedantic use of DSFG to non-software. When in doubt with how to interpret "software", we can always have a simple majority GR for each type of question. (I think collective common sense can only be reached through voting.) Osamu
Attachment:
signature.asc
Description: Digital signature