From: Ian Jackson <firstname.lastname@example.org>
> I do hope this DFSG example doesn't get out of hand. This is just one
> case where I think a more formal procedure would have helped. I'll
> continue to discuss it as an example ...
OK. First, I want to make the point that I am a bazaar-method manager
(see the oft-cited "Cathedral and the Bazaar" paper by Eric Raymond).
This means that my goal is to help the project reach a consensus, and
to only step in when that consensus is not happening. I am in place to
protect the project from the perils of design-by-comittee, while allowing
consensus management wherever it will work.
Regarding the DFSG process, I think I remember you offering an
objection to our compromise that developers could maintain the
integrity of a source code file and compel us to distribute patches to
that source file rather than modify the original source file. This
compromise was inspired by qmail's license, but DJB later did other
things with qmail's license that made it untenable for us to distribute
it. Eric Raymond was very pleased at the balance the compromise made
between the programmer's integrity and freedom of software, and this
inspired him to suggest the DFSG as a licensing guide for contributors
to Sunsite's FTP archive.
I logged your objections at the time they were received, but you had very
I consider the inclusion of this compromise results in a difference in
formatting of the source code and little more. I do not find that it
impairs our freedom to use the software in any way. However, I don't
have any evidence of software licenses that have actually _used_ the
> What I'm planning to do is make an arrangement whereby a sufficient
> number of developers can force a vote on an amendment. The votes on
> all the amendments would be done together when they'd all be
> collected, at the same time as the vote on the resolution itself, so
> you'd still just cast one ballot at the end, but it would have more
> than just `yes/no' on it.
If I had not seen that the majority of developers were already satisfied
with the _entire_ DFSG, I would have held off putting it to vote. The vote
was the developers indication that they could live with the entire DFSG as
a compromise with _each_other_. The alternative would have been the
developers voting on the document line-by-line, which would not have been
a compromise with each other at all, and would not necessarily have given
us a usable result. The document doesn't hold together if you start deleting
I have already seen that it is not really possible for me to go against
the majority of the developers, regardless of any fiat power they might
have granted me. They'd just walk off if sufficiently frustrated. Thus,
I think 100% of the power is already in the hands of the developers,
and my role is to act more as voice and guide for the group than as its
I did hold a confidence vote a while back in which the developers rejected
a shift to a "Roman Senate" form of government by a large margin. They
don't seem to resent having an executive with broad power, and they seem to
live with it much better than they did while we had a board of directors
running the project.
One meta-debate point:
> <fx: repeats `I will not be rude to people with poor reading
> comprehension' several times. Damn, it didn't work.>
You seem to be having difficulty in communicating your ideas, and the
failure to communicate drives you to be obliquely abusive of the reader.
You might instead accept that as a leader, the burden of any communication
failure with a member of the group lies on _your_ shoulders, and you must
patiently continue to explain yourself until you are understood.
Can you get your operating system fixed when you need it?
Linux - the supportable operating system. http://www.debian.org/support.html
Bruce Perens K6BP email@example.com NEW PHONE NUMBER: 510-620-3502
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
firstname.lastname@example.org . Trouble?
e-mail to email@example.com .