The Mercurial license is GPLv2

[Peter Arrenbrecht]

On Tue, Aug 5, 2008 at 1:15 AM, Matt Mackall <mpm at selenic.com> wrote:
>
> On Mon, 2008-08-04 at 23:10 +0100, Paul Moore wrote:
>> 2008/8/4 Germán Póo-Caamaño <gpoo at calcifer.org>:
>> > Certainly, they can run it in a separate process.  The thing is using
>> > the API to communicate with Mercurial instead of parsing the output.
>>
>> So write a (GPL'd) extension to communicate with a persistent
>> Mercurial process via an easily parseable format (or XML, if you
>> prefer :-)). Best of both worlds. I assume that would be both in the
>> letter and the spirit (ie, Matt would be OK with it) of the license.
>
> Obviously you could use something like a trivial XMLRPC or eval/pickle
> wrapper to call all of Mercurial's APIs running in a separate process,
> even on a separate continent. And the result is probably a derived work
> of Mercurial, because copyright is more interested in intent than
> technology.
>
> Copyright and the GPL both talk about protection of original and
> "derived works". If your work is a derived work in the view of copyright
> law, then it is covered by the GPL. Precisely what does and does not
> constitute a derived work in software is something that currently can
> only be answered in a court of law. One possible test is: if Alice's
> code can't work in any useful sense without Bob's code, then Alice's
> code is probably a derived work of Bob's.

So, regardless of the interfacing technique, an Eclipse plugin for Hg
has to be GPL. But also EPL. Question is, can it be both? It seems to
me that:

  http://en.wikipedia.org/wiki/Eclipse_Public_License#Compatibility

says no. This would be very sad indeed.

Looks like the only workaround is to not _distribute_ the two parts
together, but let users obtain them separately. So I figure if the
plugin simply calls hg, it's in the clear as long as it simply assumes
_something_ obeying hg's UI is installed, wherever it came from,
whatever it really is. Same should go for a wrapper exposing a more
GUI-friendly API, but it gets more blurry here if the only source is
who provides the plugin, I guess.

Here's a related citation from
http://www.springsource.com/products/suite/applicationplatform/licensingfaq:

----
If the GPL and the Eclipse Public License (EPL) are incompatible, how
is it possible for SpringSource to license the Application Platform
under GPL when EPL-licensed modules are utilized by the Application
Platform?

When you download the Application Platform, portions of the platform
are licensed to you by SpringSource under the GPL, while the Eclipse
modules utilized by the platform are licensed to you under the EPL.
This practice of using different open source licenses for different
components is common. Anyone wishing to redistribute, rather than
simply use the SpringSource Application Platform and/or applications
which run on the platform, should consult with legal counsel to
determine the implications of such redistribution or take out a
commercial license with SpringSource.
----

Maybe this is where we should start thinking about a common dedicated
GUI-oriented API for Hg that is distributed as part of standard Hg? As
an extension, maybe. This could benefit all players like TortoiseHg,
IDE-Plugins, sites like bitbucket.org, etc.

IANAL, etc.
-parren