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

Re: Social Contract GR's effect on sarge

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.)


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

Reply to: