Re: [DRAFT] resolving DFSG violations
----- "Robert Millan" <rmh@aybabtu.com> 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
ean@brainfood.com - http://www.brainfood.com - 214-720-0700 x 315
Reply to: