Re: non-free?
Stefano Zacchiroli <zack@debian.org> writes:
> That's a very interesting viewpoint for me, because it's kinda dual to
> mine. I understand what you're saying and it has its own merits. But
> OTOH I see another part of our *current* stance as non honest, the part
> where we say that contrib and non-free are not part of Debian, because
> for many practical purposes that's simply not true.
It's a compromise, and as such neither side is happy with it.
I think we should treat non-free software as part of Debian, but
deprecated and discouraged and with large caveats about how we can't
properly maintain it, it undermines user control over their own hardware,
and we're providing it only because there is no good alternative.
You (and others; I know your opinion is common) would like to push it
farther away from the project and basically make it a separate, parallel
project to Debian.
We currently have a compromise that doesn't make either of us happy, but
which is livable. I'm going to object to any attempt to move away from
that compromise towards your preferred position, just as you're likely
going to object to any attempt to move away from that compromise towards
my preferred position. :)
Right now, non-free is part of the project in some respects: it uses the
same upload rights and vetting, the same bug tracking system, the same
developers, to some extent the same buildd network, the same mirror
network, and so forth. It's not part of the project in some other
respects: no or minimal security support, not considered release-blocking,
not enabled by default, and partially not auto-built.
The reality is that it is part of the project but a second-class citizen.
I think that's what we capture right now by saying that it's maintained by
the project but is not part of our distribution. We could probably say
that more clearly, but I don't think moving away from that compromise is a
particularly good idea. (Unless, of course, you all decide that I'm right
and we should just treat it as a deprecated and discouraged part of our
distribution. *grin*)
Bear in mind my background: I fought tooth and nail to use Debian as the
primary (and fairly close to the only) Linux distribution for central
computing services for Stanford. Stanford central IT, institutionally,
doesn't really care about free software. (Well, that's not *completely*
true, but management certainly doesn't care about the ideological argument
for it.) Now, don't get me wrong: I believe in the ideology of free
software myself, and I'm all in favor of supporting it. But insofar as I
have to explain or work around practical, concrete problems with running
servers that are created by free software ideology, it constantly reopens
conversations that start with the question "why don't we just use Red Hat
like everyone else?" Those conversations are always stressful and never
fun. So I'm a little defensive around changes that would make my job, as
a Debian advocate in an organization that doesn't have an ideological
committment to our project ideals, even harder.
I understand that you want to do this in a way that won't cause practical
problems, so this is more in the way of explanation for my kneejerk
response rather than a considered objection to your proposal.
> Essentially, that statement is true only for who has read it in the
> social contract, in a weird sort of self-fulfilling way. What is true
> --- and we should pride ourselves with it --- is that contrib and
> non-free are not enabled by default. But aside from that choice, often
> done once and for all, many of our users would have a hard time
> distinguishing which packages (that they use or otherwise) are from main
> and which are not.
I think there is some common ground here. For example, I think both of
these ideas sound fine:
> - add debtags facets to classify non-free packages in terms of which
> freedom you give up when using it (is it non-redistribution? is it
> restriction of use? etc.)
> - make vrms ship APT hooks that tell the user about that
provided that I can easily disable warning messages with debconf
preseeding, APT configuration, or the like on servers where I just don't
care. Those sorts of changes feel lower-impact to me than shuffling
everything off to a different domain.
My concern is that, as part of an attempt to be cleaner and clearer about
this, you will recreate all of the annoyances and roadblocks caused by
backports.org being a separate project with a separate archive. Merging
it with Debian as backports.debian.org was a huge improvement and made my
life considerably easier (and I'm sure I'm not the only one). I would be
sad to see us intentionally reintroduce that whole class of problems again
in a different place.
This idea:
> making our APT frontend be more clear about the fact that the user is
> about to install non Debian software.
I think is fine in a different form. I think we want to say something
more specific and concrete than non-Debian. Just saying that it doesn't
have security support is, by itself, going to be plenty scary. :) Saying
that it's non-Debian software implies to the average user that, for
example, it may not be signed, or the upload queue may not be controlled
or vetted, or that no Debian developer reviewed it, or that no bug
tracking system is available, or that normal Debian tools don't work with
those packages. We should not imply those things about software in
non-free because they're simply not *true*.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: