[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnu-arch-users] Inclusion of Bzr into the GNU system

From: Stephen J. Turnbull
Subject: [Gnu-arch-users] Inclusion of Bzr into the GNU system
Date: Wed, 26 Nov 2008 13:18:07 +0900

deadlyhead writes:

 > But Python, while ostensibly free software,

Even RMS admits that it is strictly freer than GPL software, but based
on the long-term interests of the community he decided that GNU policy
should be oriented to *freedom-preserving* software, and not merely
free software.  For that reason he defined "software freedom" in such
a way as to allow restrictive licenses like the GPL, and the GPL is
(at least to a pretty good approximation) the most restrictive license
that still qualifies as a free software license (even the GFDL does
not, although some instances of the GFDL do).

 > has a rather weak license and in the past its community has shown a
 > bit of hostility toward maintaining the Four Freedoms.  This
 > greatly troubles me for a project that has been accepted as part of
 > the GNU system.

I guess you refuse to use X11, Perl, TeX, Apache, OpenSSH, and the BSD
shell utilities, then?  The GNU System has a long history of
incorporating free software even though it it not copyleft.

The license is easy enough to fix.  You can create a GNU Python
project which simply GPLs each release of Python as it comes out (I
told you Python's license was freer than the GPL, and this is an
important example of that freedom -- go ahead and try the reverse on
FSF-owned software if you don't believe me), and test whether Bazaar
works with the GPLed version.  If not, you complain to the Bazaar

Also, it's a fundamental principle of copyleft theory that you
separate the platform from the licensed work.  If people want to port
Emacs to Windows, this is not a problem for the Emacs project as long
as it doesn't provide features that make using Emacs on Windows more
attractive than using Emacs on free platforms.  The rationale is that
Emacs becomes no less free, and all else equal Emacs users on Windows
will find it easier to migrate to free platforms because they don't
have to worry about learning a new editor.

For those reasons, I rather doubt that the discussion of admitting
Bazaar as a GNU project (which AFAIK is kept private and simply
consists of getting the developers to sign a document saying they
adhere to GNU goals) considered whether Python was GNUish or not.

It certainly did not come up at all in the discussion of a DVCS for
Emacs, which RMS summarily terminated by deciding on Bazaar because it
was an active GNU project.  This, despite the presence of advocates of
GNU Arch---who actually have maintained a working Arch mirror of Emacs
for years.  Even Tom Lord, who participated in that discussion, was
unable to effectively argue for Arch.

 > This is just my perspective.  I'd like to see what others have to
 > say for the inclusion of Bazaar as a GNU project, how that sits
 > with the GNU Arch community, its benefits and detriments, and what
 > that means for the future of Arch.

Sad to say, I don't think Arch has a future beyond maintaining
existing projects that use Arch.  Distributed revision control has
moved on.  Git provides performance and the most intuitive database
schema, Mercurial gives almost as good performance and a convenient
UI, Darcs is patch-oriented, has some nice UI features, and
automatically computes optimal merge strategies for you, and Bazaar is
a GNU project (acceptable to RMS as long-term host for his first-born
child) for freedom-lovers.

So there's no longer room for proof-of-concept implementations, and
that's all that Arch ever was to Tom Lord, at least that's what he
said when he was busking for (financial) contributions.  He even
regrets many of the UI and feature concessions he made to the crew of
developers who later became the nucleus of the Bazaar project.  Making
Arch into a contender again will require a genius (or, to be specific,
Tom).  But Tom, too, has moved on I think.  While there are many ideas
in Arch that haven't made it into other VCSes even today, the
value-add to implementing them in Yet Another DVCS probably isn't that

reply via email to

[Prev in Thread] Current Thread [Next in Thread]