Re: [DRAFT] resolving DFSG violations
On Thu, Oct 23, 2008 at 06:32:51PM +0200, martin f krafft wrote:
> It's all a matter of defining what your priorities are, which brings
> us back to the Social Contract, which says that these include:
> - 100% freeness
> - cater best to the interests of our users
> Note that it does not say: release regularly, or on time. This may
> well be interpreted to be part of the second of the aforementioned
> priorities, but it's not explicitly so.
Except you're paraphrasing here. What the Social Contract actually says
is:
1. Debian will remain 100% free
We provide the guidelines that we use to determine if a work is "free" in
the document entitled "The Debian Free Software Guidelines". We promise
that the Debian system and all its components will be free according to
these guidelines. We will support people who create or use both free and
non-free works on Debian. We will never make the system require the use of
a non-free component.
So if we're promising that Debian will *remain* 100% free, then we already
broke that promise - depending on your POV, either we broke it when we
allowed the first piece of sourceless firmware or the first piece of GNU
documentation into the archive, or we broke it when we changed the scope of
"free" in the Social Contract.
It is not the release team that has broken this promise; it is Debian as a
whole. While the release team /could/ use their authority to decide to
block the lenny release until all known firmware issues are resolved, or
until the kernel has had a full license audit by a party of Robert Millan's
choosing, do you think that will beneficially affect the point at which we
have a Debian release that's free of kernel licensing problems, instead of
just negatively impacting the utility of Debian to our users due to the
open-ended delays of the lenny release?
Bear in mind that the current round of firmware bugs that have stirred up
such a ruckus are all bugs that have been discovered and filed within the
past three months - whereas the firmware bugs that were knowingly given
exceptions for etch have all been resolved.
> We've released sarge bundled with an excuse. We've agreed
> that these amendments, which have already been ratified by the
> Debian Project, will be reinstated immediately after the release
> of the next stable version of Debian, without further cause for
> deliberation.
> -- http://www.debian.org/vote/2004/vote_004
> We've released etch without an excuse for failing to comply to our
> own rules.
> Are we just going to continue down this road?
The road we're continuing down is one of incremental *improvement* of
Debian's compliance with the current Social Contract. We waived the
requirement for DFSG-compliant documentation for sarge, and resolved that
for etch; we waived the requirement for firmware in main to be accompanied
by source (http://www.debian.org/vote/2006/vote_007) for etch, and have
subsequently fixed, for lenny, the firmware source issues that we knew about
when etch was released. In between the once-a-release-cycle mailing list
rants from developers who aren't willing to do the hard work of ensuring
users can *use* the release on their systems, there's real progress being
made.
(We've even managed to see bug #368560 resolved for lenny, a software
licensing bug that predates any of the rest of this which, to my chagrin,
was reported as a bug that "little was done about" in spite of efforts by
multiple Debian developers over the years to discuss this with SGI.)
I don't see the point in delaying releases on the grounds that we haven't
yet reached the end of that road. I especially don't think it's a good plan
to treat difficult-to-resolve DFSG bugs as blockers for the release when
these bugs have only been brought to our attention after we're in freeze for
the release. Why is "release" a better cut-off for these bugs than
"freeze", anyway?
OTOH, I do understand the desire to put such (diminishing) exceptions to a
referendum instead of leaving them implicit, and am happy to vote for a GR
that makes clear to our users the state of affairs in lenny.
I also encourage the kernel team to pursue the patches that Ben Hutchings
has so wonderfully provided for this latest round of bugs. They need to be
weighed against the risk of regression, but they should still be considered
for inclusion in lenny. Kudos to those who are actually doing the legwork
to fix the bugs.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: