Re: Nomination

[Mike Goldman <whig@by.net>]

Joseph Carter wrote:

> [ Please send replies to -devel, Cc's to me encouraged ]

I am a new Debian maintainer, and although I have very strong opinions on many
things, I have tried to stay out of internal political disputes, but instead
pursue the best policy as I see it in my own actions.  Nevertheless, I thought
I would write you and let you know I felt that your message was very
encouraging.

> The obvious requirement for the job is time for the project and lots of it
> at that.  But I also believe the project leader should take an active role
> in leading the project, but not to the point that they start pushing instead
> of leading.  The ability to listen to people you don't agree with is also
> very important, as is the ability to say what you're trying to say clearly.
> I believe I have these qualities.

Having been involved in many organizations, where leadership became very
activist about its own agenda, I know the importance of this.  No matter how
thoughtful and intelligent a leader is, there will be valid points of
disagreement with his ideas from time to time.  In this circumstance, unless
emergency action is called for, the leader must stand back and allow sufficient

opportunity for all sides to be heard, and defer his own preference to the
opinions of the group.  This is more difficult than it appears, and requires
sometimes allowing a very strongly held minority opinion, even one opposite to
his own, to prevail.  While democratic principles are appropriate in many
cases, in a volunteer organization the recognition must be made that a minority

may vote with their feet, i.e., leave the group.  A leader's own preference
should be enforced principally by the persuasiveness of his argument, not his
authority to decide (or force decision of) a question.

> I think it's important that those who are planning to support me in this
> election be aware of my position on a few issues.  One of the most prominent
> issues I see affecting the project right now is IWJ's proposal to rewrite
> the DFSG.  I am opposed to this and believe we should focus on correcting
> the problems with the current DFSG rather than trying to totally replace it.

Relating to my previous paragraph, great discontinuities require significant
consensus.  It is the obligation of those who would replace the existing DFSG
to create such a consensus, yet I have seen no very strong arguments that the
existing language cannot be remedied (if appropriate) through lesser
amendment.  If you are made project leader, I hope that you will encourage a
full consideration of the supposed defects in the current language, and if
these are generally agreed to, a full and fair discussion of the best (and
preferably least disruptive) means of correcting them.

> I also am opposed to some of the changes made in Ian's proposal, namely
> placing a time limit on use of the BSD Advertising clause and disallowing
> licenses which require modifications to source code be made as patches.  I
> can agree that both of these things are not desirable even if they are at
> the moment allowed by the DFSG.  I can agree that we might make it known in
> a revision of the DFSG that both of these are depreciated because they are
> difficult to work with, but removing them outright seems like a bad plan to
> me, as does applying a time limit to their acceptance or grandfathering
> well-known applications or licenses.

Grandfather-clauses are really an example of inconsistent policy resulting from

an excessively disruptive change.  Either a policy should be adopted or not,
and if the effects of such a policy are deemed too disruptive in view of the
objective, then the weight of argument against the policy is increased.  Since
Debian distributes everything in pristine-source + patch form, I do not see any

urgency to the question, although I can certainly see good reasons to prefer
that this not be a requirement.  Nonetheless, Debian policy should not require
enforcement of every preference, but may sufficiently state the preference and
enforce only what is required to allow us to include a package consistent with
our principles.