Re: Results for General Resolution: Lenny and resolving DFSG violations
On Mon, Dec 29, 2008 at 10:10:24PM +0900, Osamu Aoki wrote:
> 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.
IMO, discussion that leads to technical changes, is really part of the
source, much like in-code comments, READMEs, and version control logs. If
you've got access to the reasoning that led up to a decision, you can
have a much better understanding of what's going on, just as if you have
access to criticisms being made, and what people propose to do about them,
you've got a much better idea of what the code's capabilities are.
There's nothing wrong with having a closed discussion with some friends
about how to improve your packages, but it's much better if after the fact
you make that discussion available to everyone who might be interested.
The same thing applies to discussions about the direction of Debian --
when it might release, how decisions get made, what exciting new things
we might consider doing. These are important bits of information that
users, upstream, and developers of other distros should have access to.
That doesn't mean *every* private discussion DDs have -- "gosh, wasn't
the football exciting last night?" isn't very interesting to Debian, eg.
But equally, it's not especially on-topic for most Debian areas, either.
If there's a casual environment -- like debconf, or a pub, or an IRC
channel; there's no need for complete logs or video records for everyone
to be able to pore over, but summaries of the technical bits would be
a win.
> > 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".
I don't think the text I wrote puts any limits on how much you can support
free stuff; it only puts limits on how much you can ignore other people's
opinions and how poorly you can treat other people. If you only want to
license your work under the MIT license, and never the GPL because you think
that is too restrictive, eg, you can perfectly well make that pledge.
> 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".
I'm not saying the project doesn't support the SC as it stands, just that
some DDs don't. That applies to both the "remain 100% free" claim ("it's
silly to do that now, because it wouldn't be a functioanl OS" or "we've
never been 100% free up 'til now, how can we `remain' that way?") or the
"we support [non-free works'] use and provide infrastructure for non-free
packages" ("but Debian will remain 100% free", "I certainly won't",
"non-free should be dropped").
It makes sense that day-to-day decisions that flow from the social
contract might result in disagreements (eg, "is the GFDL ever free?",
"should non-free be released as part of stable, or kept separately?",
"should packages in non-free ever delay packages in main getting released
into testing or stable?"), but when the social contract *itself* is the
cause of disagreement within the project, I find that troubling.
> 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.
Yeah, you can abide by a document you don't support, but if it's
possible to get a document that 95% of the project as it stands actually
*supports*, I think it makes sense to consider whether keeping the remaining
5% who have principled disagreements with some part or other is going to
be a good way of running the project.
My draft was written with the aim of being something that who simply
want complete (software) freedom above all else could readily agree with,
and sign their name to, as can people who don't much care about the politics
or philosophy of free software and just want to keep some non-free packages
well maintained. Maybe it doesn't succeed at that, I don't know.
> > Anyway, given the last proposal I made [0] went nowhere, [...]
> This is "Technical committee resolution". I am not very clear about
> what Anthony is talking here.
Knowingly changing traditions within Debian is hard and requires hard
decisions; much as I'd like to be proven wrong, I don't think it's
particularly likely there'll actually be any changes made as a result
of these discussions.
Cheers,
aj
Reply to: