[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Social Contract GR's Affect on sarge

Stephen Ryan writes:

> If I ask my wife about it, she will declare that the images, sounds, and
> text accompanying some bit of executable code together comprises a
> "program".  *THAT* is what the "rest of the world" sees and knows. 
> According to the "average" user, whatever that might mean, the image of
> Clippy is a part of the "program" known as Microsoft Word.  It's rather
> more common than you're implying.

This "average" user is also infamous for asking why the cup holder is
broken or what to do with the foot pedal.  I conducted an informal
poll of several (very computer literate) acquaintances.  Only one said
he would include documentation and images in "software" -- and he
retracted that when I asked whether a specification such as an RFC was

>> The entire point of the recent GR was that some Debian developers and
>> users use "software" as the rest of the world uses the word, and
>> exclude things like fonts, images, or statistical data.
> I'm with Branden on this one: *every* single person arguing for a more
> restricted definition of software is a "W4ReZ d00d".  

That is very offensive.  Please retract your accusation or provide
some basis to support it.

> I really don't understand why the right to modify the auxiliary
> materials is not just as important, if not more important, than the
> right to modify the underlying code.

I was asking "Are auxiliary materials software?"  You are asking "Is
it important to be able to modify auxiliary materials?"  They are
different issues, and rational people might say no to the first and
yes to the second.

I'm going to skip the rest of your post, since it wobbles (often)
between assuming many users can change data and that very few users
can change data, and you try to apply conclusions from one line of
argument to the other assumptions.

Consider, though: Who is helped when one demands that Debian provide
source code but all the tools to process it are non-free?  Who is
helped when there is no public specification?  Except for GFDL'ed
documentation (where the consensus has been clear), those are the most
common areas of argument.

If the basis is that we cannot provide documentation to support
modification of software, a great many more device drivers would
become "non-free."


Reply to: