Re: What your ballot should look like if you're in favor of releasing sarge
Wouter Verhelst <wouter@grep.be> writes:
> Op wo 23-06-2004, om 18:16 schreef Clint Adams:
>> > as "grandfather resolutions" as described, and, by explicitly removing
>> > the Social Contract's requirement to have DFSG-free documentation and
>> > firmware for sarge/some-period-of-time/whatever, go back to allowing
>> > discretion on the part of those who would ordinarily be responsible for
>> > release issues and DFSG control.
>>
>> You're implying here that those things were allowed under a valid
>> interpretation of the original SC.
>
> I'm getting sick of that argument.
>
> You're implying here that there's only one possible "valid"
> interpretation of the original SC.
>
> Who's to say what's "valid" and what isn't? When I originally read (and
> agreed with) the SC, there was nobody to tell me that the way I read it
> at the time wasn't considered "valid". There was also nobody who pointed
> me at the subtle inconsistency in the way I interpreted the original SC.
> Sue me, English isn't my native language.
>
> I read "software" as I have always read it for the conscious part of the
> first 24 years of my life, namely, "anything you can run on a computer";
> and thus, I didn't consider the SC to apply to "documentation". That's
> right: I didn't read "Debian consists of software, which is 100% free";
> I read "Debian consists of software and other things, and the software
> part is 100% free". Sue me, English isn't my native language.
>
> Telling people that the way they interpreted the Social Contract is not
> "valid", and therefore not even worth considering, seems very childish
> to me.
The probably with that interpretation, as has been pointed out
previously, is that there is a lot of gray area. Does literate
programming constitute software or documentation? What about
documentation with embedded code examples? And so on...
I think what Clint means be "valid" is that there is only one
interpretation that is clear and enforceable, with no gray area--just
consider *everything* in Debian to be software. Any other
interpretation just leads to endless arguments. I don't think it's
possible to draw a clear line between documentation and software.
I happen to believe that the DFSG and SC were written with only "things
you can run on a computer" in mind. Sure, it would nice if all
documentation complied with the DFSG, but I'm not convinced we should
demand all of the DFSG requirements for every bit in Debian. A document
that is not modifiable is still uncrippled and fully functional--it can
be read on any Debian machine. In a way, it's still "modifiable"
because a reader can take ideas from the document and use them as he or
she sees fit. If it contains factual inaccuracies, a supplemental
document can be included that points out any errors. Obviously, we
would prefer to be able to modify the document itself and distribute
that, but non-modifiability does not impose a significant problem.
However, a non-modifiable program, especially one that is only available
in binary form, is far more troublesome. Errors cannot be corrected,
behavior cannot be modified, etc.
Nonetheless, I still feel there was only one interpretation of the SC as
it was written that would allow the project to move forward. Now that
we have a clear SC, we can figure out where to go from here.
--
You win again, gravity!
Reply to: