On Mon, Apr 26, 2004 at 09:36:44AM -0500, Steve Langasek wrote: > The rhetorical argument used by those who insisted the DFSG should not > apply to documentation was that documentation was not software, > therefore its freeness did not matter. So since "those" includes "me", let's clarify this. I believe the freeness of documentation matters; both absolutely and for Debian's purposes. What I don't believe is that the previous Debian Social Contract required the DFSG to be applied to stuff that wasn't programs. > I personally never accepted this argument, nor considered it relevant to > the policy for sarge; Well, it is: otherwise the sarge release policy was in direct violation of the social contract. The social contract is not the release policy, and is not debian-policy. It's the fundamental promise we make to our userbase of how we're going to run our organisation. It's the document that lets our users trust that we're going to stay around, that we're going to think of them, that we're going to commit to free software. Violating technical policies is one thing -- technical arguments can be made as to why a policy's a bad thing, and as long as the new solution still works, that's all fine. If done wrong, it can make things break, and even if done right it'll still make things confusing, but that's okay. Violating the social contract, though, is treating the trust our users place in us with contempt. > IMHO, the justification for delaying the > enforcement of the DFSG on documentation and other non-program software > is that this is a de facto policy change compared with previous > releases, and *not* a de jure change, and making a sweeping, disruptive > change like this does not serve our interests. Many people would have said that being committed to free software rather than making money doesn't serve our interests either. That's for the project to decide, and, well, it appears to have done so. > I think even after this > GR, it's still within the purview of the release manager to not enforce > this policy for the release in progress, just as it's considered ok that > build-depends are currently not enforced in testing. If Build-Depends support was required in the Social Contract, I'd expect testing to be dropped from the archive if that support couldn't be added. (Oh, if people want to require Build-Depends in testing, because hey, it's not like we're going to release soon anyway, and who cares whether it requires any effort to implement it -- please do it by a GR overriding the decisions of the appropriate delegates, not by changing the social contract. And don't take this as support: it would be a stupid thing to try doing at the moment or for sarge.) Cheers, aj -- Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/> Don't assume I speak for anyone but myself. GPG signed mail preferred. Protect Open Source in Australia from over-reaching changes to IP law http://www.petitiononline.com/auftaip/ & http://www.linux.org.au/fta/
Attachment:
signature.asc
Description: Digital signature