Re: Results for General Resolution: Lenny and resolving DFSG violations
Hi,
On Mon, Dec 29, 2008 at 03:02:41PM +1000, Anthony Towns wrote:
> 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?
I am impressed by your well thought proposal. Thanks!
Here are my comments to it.
> 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.
I hope people have learned from this :-)
> 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.
Yes.
> 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:
...
> 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.
...
>
> 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.
...
> 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.
You mean like many contracts which use best effort clause ... For
example, "we will use and promote FREE softwares to the extent possible."
> 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.
But the way you wrote in 4 as "we will make any private discussions
publically available at the earliest opportunity." is problematic since
it is 100% disclosure pledge. I suggest something along "we will make
any private discussions publically available at the earliest opportunity
to the extent appropriate for this objective." I am using "this
objective" as "to allow anyone to follow our discussions". I hope
someone can rephrase this better.
...
> 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.
Yes, I like this.
> 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%.
I am not sure about the last part. If you said "when a significant
number of members don't actually abide by it 100%.", I can agree. As
much as we are discussing SC change now, we should allow us to discuss
changing it as long as we abide by the current SC during its valid term.
I mean people with view to have stricter FREE requirement should not be
forced to leave project via this "pledge process".
To me, none of us made action which does not abide to the valid current
SC. We only overruled a part of SC when it conflicted with another one
in SC via GR. I.e. "100% free" vs. "user".
Although I did not agree to the current SC vote, I have been abiding to
the current SC. Thus we casted our vote for this GR for lenny.
> 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.
...
> [0] http://lists.debian.org/debian-vote/2008/03/msg00025.html
This is "Technical committee resolution". I am not very clear about
what Anthony is talking here.
Osamu
PS: Current process to set 3:1 majority requirement by the secretary is
understandable one since we have no supreme court to struck down a GR
when it conflicts with valid current SC. We may wish to change this
decision of 3:1 requirement to be made by elected person such as DPL.
But that is orthogonal and mere procedural issue which needs to be
cleared in some future independently.
Reply to: