On Sun, Dec 28, 2008 at 08:45:16PM -0500, Theodore Tso wrote:
> On Mon, Dec 29, 2008 at 12:48:24AM +0000, Simon Huggins wrote:
> > I wonder how many DDs were ashamed to vote the titled "Reaffirm the
> > social contract" lower than the choices that chose to release.
> I'm not ashamed at all; I joined before the 1.1 revision to the Debian
> Social Contract, which I objected to them, and I still object to now.
> If there was a GR which chainged the Debian Social contract which
> relaxed the first clause to only include __software__ running on the
> Host CPU, I would enthusiastically vote for such a measure.
So what would such a SC look like?
We previously had a vote to revert the SC to 1.0, and while it defeated
reaffirming the current SC, it lost to the option of simply postponing it.
Maybe with nearly four years of experience since then, that's changed
though.
Using the word "software" as the basis for the divide might be too much:
we've already done a lot of work restricting main to DFSG-free docs, and
I think it makes sense to keep that. Having main be a functioning bunch
of free stuff with a minimal and decreasing amount of random non-free
stuff we still need to support it works well, it seems to me.
Back in the day, I tried writing a version of the SC that felt both
inspiring and within the bounds of what we could actually meet. It looked
like:
We, the members of the Debian project, make the following pledge:
1. We will build a free operating system
We will create and provide an integrated system of free software
that anyone can use. We will make all our work publically available
as free software.
2. We will build a superior operating system
We will collect and distribute the best software available, and
strive to continually improve it by making use of the best tools
and techniques available.
3. We will build a universal operating system
We will accept the use of our operating system by all users,
for all purposes, without discrimination. We will support our
users to the best of our ability in all the choices they make,
no matter what our opinion of those choices may be.
4. We will be open about our activities
We will conduct our affairs in public and allow anyone to follow our
discussions. Where public disclosure is not immediately feasible
we will make any private discussions publically available at the
earliest opportunity.
5. We will respect the community
We will ensure that members of the community can easily and
effectively contribute their skills and views to the project. We
will respect the membership of the community, and ensure that our
treatment of their contributions reflects that respect.
It doesn't try to say how these goals are met, leaving that up to the DPL,
ftpmaster, debian-policy, individual maintainers and future resolutions
by the project. I think that makes sense by and large, but having the
project state that explicitly might be necessary to avoid continuing
ambiguity and arguments.
For example, having "non-free" in the archive and the BTS (and potentially
buildds and elsewhere) is implied by point (3) (ie, supporting Debian
users who choose to use non-free software to the best of our ability),
and potentially using non-free software ourselves (such as qmail or pgp
in the past) may be implied by point (2) (using the best available tools
and techniques to do the best job we can). I would personally prefer
for the project to have the freedom to decide those sorts of things
on a day-to-day basis through regular decision making (maintainers,
list debate, DPL, ftpmaster, RM, tech-ctte, simple majority vote), but
I don't know if the rest of the project will buy that these days. I'm
fairly sure some people won't, at any rate.
It drops the "100% free" phrasing we've had in the past, because
fundamentally what we have isn't 100% free. It might be three-nines
edging onto four-nines, but we don't even have an accurate measurement.
Calling main as it stands today an "integrated system of free software"
seems the best compromise between staying focussed on freedom, not
claiming to be completely free until we are, and not devolving into
impenetrable jargon that I could come up with.
It redoes the "we will not hide problems" phrasing in a way that,
I think, reflects the intent better than the current wording, which
seems to support just about everything but the BTS to be done in
secret. Unfortunately that's some way off current practice wrt conducting
project activities on restricted machines, private IRC channels, unlogged
IRC channels, in personal emails, and on private lists.
I don't think the "community" clause is terribly well worded, but
that's what you get when you make stuff up out of whole cloth rather
than building on previous attempts.
One other thing the above does is, unlike the current SC, is use the word
"Debian" to refer solely to the project -- so it doesn't suffer from the
confusion that when the current SC says "Debian will remain 100% free" you
don't have to mentally substitute in "The main component of ... releases"
in order to reconcile it with the later mentions of non-free stuff.
Since it's worded as a pledge, it might make sense that if it (or
something like it) is ever adopted, that existing developers membership
being dependent on them agreeing to the pledge. That didn't happen with
the previous SC change, but it seems strange to claim to have a social
contract when a significant number of members don't actually support
it 100%.
Anyway, given the last proposal I made [0] went nowhere, unless people
want to come up with their own proposals, or want to second the above as
a draft proposal to be improved and voted on, I suspect nothing much will
change, and we'll have this discussion again in a few years when squeeze
is looking like releasing.
Cheers,
aj
[0] http://lists.debian.org/debian-vote/2008/03/msg00025.html
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
