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

Re: Ready to vote on 2004-003?

On Thu, May 20, 2004 at 12:39:00PM +0200, Andreas Barth wrote:
> > For the whateverth time, it's the project's interpretation of the SC
> > that's important, not mine. I don't believe it's possible to interpret
> > the current SC to allow that policy; but I might be wrong.
> I disagree. 

Really? You think it's my interpretation that's important? Then quick, make
me supreme dictator for life, so folks with unimportant interpretations can't
overrule me.

Or do you think it's possible to interpret the current SC to allow GFDL'ed
docs in main? Then quick, better talk to the tech ctte so they can change
the release policy as they seem to think's best without violating the SC,
and to Andrew Suffield since his clarifying amendment doesn't seem to have
achieved his goals.

Or do you think that I can never be wrong?

> The SC still says that our priorities are our users and
> the free software community. That there are no "Debian User
> Interaction Guidelines" doesn't change that. So, if we have to either
> neglect a bit the freeness in border cases (as Debian is about
> creating a free operating system, hardware-specific low-level firmware
> _is_ a border case), or to finally release sarge, I consider that the
> SC gives us not only the right to release sarge now, but really tells
> us to do it.

So, if it was quicker to release sarge by developing d-i using VMWare --
and purchasing licenses for d-i hackers to do so, you'd think that was
a good thing? We've previously decided not to do that (or something
similar, which people who care can look through the -private archives
for), because we've considered ourselves to be too committed to freedom
to rely on non-free products as a project, if at all possible.

More acutely, if it were easier to provide a GUI by using a non free
graphics toolkit (Motif? pre-QPL/GPL Qt?), would you likewise consider
the social contract to require us to release using that because it'd be
better, or faster, and who cares about violating our commitment to free
software in just a couple of cases anyway?

(For reference, the SC changes also cover GFDL'ed docs and other data;
I think it'll take a reasonable amount of time for us to find and go
through all the packages that contain such documentation and get it
removed, rewritten or reverted appropriately. I can't tell from the
above whether you think make and glibc documentation count as irrelevant
and to be ignored, or whether you think they should be all dropped,
or something in between.  You, or someone similar, will need to work
that out if you're trying to be productive rather than rhetorical)

In any case, if that's what you really think, you should make your case
to the tech ctte, not me. Presumably if your idea's sound and sensible,
it'll be easier to convince the handful of guys on that than to do a GR
to set the policy as you apparently think is appropriate, but if not,
you could do that too.


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.

``Like the ski resort of girls looking for husbands and husbands looking
  for girls, the situation is not as symmetrical as it might seem.''

Attachment: signature.asc
Description: Digital signature

Reply to: