Re: Git mirrors

["Stephen J. Turnbull" <stephen@xemacs.org>]

Karl Fogel writes:

 > (Sorry, no, I'm not going to spend time digging up the references unless
 > there's a serious chance that doing so will cause GNU Emacs development
 > to switch to Git or some other system that the majority of this group
 > actually prefers.)

Realistically, there won't be any such majority.  Bazaar today is
perhaps the best dVCS for supporting the traditional Emacs workflow,
and people who want to evolve their own workflows can use either non-
default or experimental bzr plugins, or $dVCS mirrors with levels of
effort that are hardly prohibitive.

 > The idea that we are helping either ourselves or a fellow GNU project
 > here should be treated as merely a hypothesis until there is actual
 > evidence of it.

Sorry, Karl, although as a social scientist *I* agree with you, *GNU*
is a social movement.  Action *should* be taken, and Richard has
decided that he is sure enough of this effect that he has instituted
the "Prefer GNU over non-GNU" policy.  You really can't use "treat as
an hypothesis until proof is available" here; this is a "you bet your
movement" decision, and "deciding not to decide" is a negative
decision because it means inaction.

I really think the Bazaar case should get a post-mortem review,
though.  Comparing "What it means for a program to be a GNU package"
in <URL:http://www.gnu.org/help/evaluation.html> with the actual
behavior of the Bazaar project (which should not be confused with the
aspirations of some of its developers) and its parent corporation is
discouraging.  Pretty much every point in "evaluation.html" is
violated (admittedly mostly in petty ways) by the Bazaar project,
starting with licensing (use of GPL v2 and an allegedly obnoxious
contributor agreement).  Although the software is free, in practice
the Bazaar project is a wholly-owned subsidiary of a corporation that
has used proprietary software or ASP/SaaS based on undistributed
software on a large scale in its products (eg, Launchpad itself,
proprietary at its launch but since freed, I believe).

If the "Use GNU" policy is to make sense, I think the criterion
proposed by Vijay Lakshminarayanan should be applied:

    The reason to support GNU projects over others is that it is the
    stated goal of GNU that all distributed software should be Free
    ....  To this end, any software project that shares the same goals
    will be supported.

(Note: the omitted text was "and copylefted by law", which AFAIK is a
non-goal.  Use of copyleft is a means to the goal of software freedom,
and will be impossible when copyright in software is abolished, which
AFAIK still is a particular goal in support of software freedom.)

I don't think that Bazaar fits Vijay's description well at all.  It is
a commercial enterprise in support of the Launchpad product and
Canonical's consulting business first and foremost, and software
freedom hardly ever enters the discussion -- rather it is quite taken
for granted.  Support for proprietary platforms is an explicit goal of
the project.  In general, the project ethos seems to be closer to open
source than to free software to me.  Quite a contrast to the GNU Arch
project (which although a GNU package since 2003 and quite usable even
then, was never seriously considered for the kind of preference Bazaar
got)!

I don't think either the GNU package status of Bazaar or Emacs's use
of it should be changed.  Rather, based on what I've seen so far I
think that it would be wise if (1) the GNU Project required a bit more
evidence of devotion to software freedom and to GNU than merely adding
the GNU brand to the home page and occasionally substituting
"GNU/Linux" for "Linux" in documentation before granting "GNU package"
status, (2) Bazaar (in particular) were encouraged to devote on-going
effort to working for software freedom (as opposed to running a
business based on free software), (3) the GNU Project would devote
more effort to getting all projects to do the same, (4) Emacs (as a
flagship GNU project) would exercise leadership in the above.  Thus
the suggestion for a review of this case.

Of course, since I actively disagree with the policy in the first
place, I'm not going to do any of the above myself.  I'm just
suggesting a path to improvements in the implementation of a policy
based on my understanding of the goals of its proponents. ;-)

Nobody-expects-the-Loyal-Opposition-ly y'rs,