License question: Importing mercurial module from open-source but possibly non-GPL-compatible code?

Matt Mackall mpm at selenic.com
Thu Sep 24 13:58:34 CDT 2009


On Thu, 2009-09-24 at 13:09 +0200, Michael Haggerty wrote:
> Michael Haggerty wrote:
> > I am the maintainer of cvs2svn, which is under a CollabNet license [1],
> > which was until recently also used by the Subversion project.  IANAL but
> > it is clear to me that the CollabNet license is open-source in name and
> > in spirit.  What is not clear to me is whether it is GPLv2-compatible.
> 
> I inquired at licensing at fsf.org whether cvs2svn's CollabNet
> license is GPLv2-compatible.  According to the response (attached), it
> *is*.  To me (IANAL) this means that cvs2hg can import from mercurial.

My take is that it means is that the combined work can be consistently
licensed under GPLv2 as the CollabNet license is a proper subset of the
restrictions in GPLv2 and there's no restriction in the CollabNet
license has no restriction on -adding new restrictions- (namely those
from GPLv2).

In other words:

GPLv2: a derived work must have exactly restrictions X
CollabNet: a derived work must have at least restrictions Y

So long as Y is a strict subset of X, you may make a derived work with
license restrictions X.

So if cvs2svn is a "derived work" of Mercurial (or you just want to be
unambiguously in the clear), you ought to further restrict your license
to GPLv2. I don't know the answer to that one, but I personally prefer
to stay out of the gray areas here. The 'linking' rule of thumb is good
here as it gives an unambiguous technical guideline for when you're in
the clear.

Because the CollabNet license is a BSD-style 'copycenter' license,
anyone (including you), can take the code and re-release it under a
license with addition restrictions, including proprietary ones or
GPL-style ones so long as the base restrictions Y remain.

The whole Apache2.0 thing throws a bit of a wrench in there, of course.

> The same CollabNet license applied to Subversion prior to trunk r38370,
> at which time the license was changed to Apache 2.0.  To me (IANAL) this
> means that Mercurial's convert extension can import the Subversion
> Python bindings even under a strict interpretation of the GPL, because
> it is OK to form a derived work with the GPLv2-compatible versions of
> Subversion.  It would of course be inadvisable to use any API calls that
> were added after the change to the Apache 2.0 license because it depends
> on the unanswerable question about what constitutes a derived work.

An astute observation. As that was only 2 months ago, we're actually in
significantly better shape than I thought.

-- 
http://selenic.com : development and support for Mercurial and Linux




More information about the Mercurial mailing list