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

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: