Re: Call for seconds: post-Lenny enforceability of DFSG violations
On Wed, Oct 29, 2008 at 05:09:58PM +0200, Kalle Kivimaa wrote:
> Robert Millan <firstname.lastname@example.org> writes:
> > ACK about your concerns (and the ones pointed by others, which are roughly
> > the same). Do you have any suggestion on what would be a better approach?
> How about dropping the GR and continuing with the current process,
> where anybody can file a RC bug against a non-DFSG package, maintainer
> (or during the release process, anybody) makes a new package release
> moving the package to contrib/non-free, and the ftpmasters do the move
> when they get around to it? Alternatively, you can always provide
> patches to dak where the priority of the semi-automatically moved
> packages is raised to the top of the NEW processing list and a note is
> shown to the ftpmaster doing the processing (meaning an almost
> automatic Apply override reflex) - remember to check that the source
> tar.gz is identical to the existing one, to make it easier to trust
> that there's nothing non-distributable trying to sneak in.
I don't think NEW is the problem here. The question, from my POV, is that
as developer I don't feel I am empowered to move a package to non-free
without permission from the maintainers, even if it is obviously infringing
on the Social Contract.
Such kind of controversial actions are IMO sometimes necessary, but should
never be done without consensus and endorsement from the project as a whole.
To me, the purpose of this GR is to sanction a procedure that would otherwise
have a doubtful legitimacy.
And if this involves overseeing by the ftp team, so be it. I have no reason
to believe they would actively obstruct a decision that has been endorsed by
the majority of the project.
The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
how) you may access your data; but nobody's threatening your freedom: we
still allow you to remove your data and not access it at all."