----- "Robert Millan" <[EMAIL PROTECTED]> wrote:
> + <p>
> + In order to ensure continued compliance with this promise, the
> + following rule is to be followed:
> + </p>
> + <p>
> + When ever a package in Debian is found to have been violating the
> + Debian Free Software Guidelines for 60 days or more, and
> + none of the solutions that have been implemented (if any) is
> considered
> + suitable by the maintainers, the package must be moved from Debian
> + ("main" suite) to the Non-free repository ("non-free" suite).
> + </p>
> + <p>
> + The action of moving it may be performed by any of the developers.
> + When this happens, any known violation of the Debian Free Software
> Guidelines
> + in the package must be resolved before the package can be moved
> back into
> + Debian.
> + </p>
I've kept a low profile for some time but AJ's enthusiasm tempts me into
discussion.
These changes seem redundant to me. Rule 1 of the Social Contract is clear in
its intent and Rule 5 spells out (in perhaps even more detail than necessary)
how non-conforming software will be handled. I think adding links to the
relevant parts of policy from the Social Contract page might be a more
expedient way of drawing people's attention to the preferred "best practices".
A change to the SC mixes our policy (how things will be accomplished) with our
philosophy (what our motivations are). Foundational documents are intended to
communicate a more basic premise and having policy drift into them could set an
ugly precedent. Making simple changes in policy would more often require an
"act of congress" and it will be harder, rather than easier, to get work done.
I hear the daunting problems as illustrated in the SUNRPC/glibc issue. These
are the same issues that the community has faced from the beginning. We're
arguably in a far better position today than when Stallman was writing his
earliest GNU work and had to go through mind-warping contortions and
compromises to push towards a more open world. Viewing all this as a process,
perhaps we can require that any non-free code given a "stay of execution" be
part of a formal road-map that its developers commit to. If your package can't
commit to a road-map to get to Free then maybe it becomes part of the road-map
to arrange its removal.
I doubt a single massive move of everything that may be in violation will get
us somewhere useful. An optimistic view is that we are slowly formalizing what
has been done for a long time through an evasion of mind. If we can continue to
formalize our progress towards the goal we've held all along then that seem
productive. Rome wasn't built in a day and all that sort of thing.
--
Ean Schuessler, CTO Brainfood.com
[EMAIL PROTECTED] - http://www.brainfood.com - 214-720-0700 x 315
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
