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