On Sun, Sep 27, 2009 at 3:58 PM, Michael Haggerty <mhagger_at_alum.mit.edu> wrote:
> In r38370 on 2009-07-08, the Subversion project license was apparently
> changed from the CollabNet license to the Apache 2.0 license.
> God, how I hate licensing issues and I personally have no particular
> objection to this change. But I must have somehow completely overlooked
> any discussion on the mailing lists about this change, and now Google
> isn't helping me find any discussion of the reasons for this change or
> how it was decided. Did I simply miss the discussion, or did the
> discussion took place in a loftier forum to which I am not party?
There was not a lot of discussion because this was always viewed as a
foregone conclusion once the SVN Corp. was formed. It was just a
matter of gathering CLA's and getting the necessary software grant
from CollabNet. The discussion that did take place happened on the
> In any case, I have one comment to toss out there (in the sense that one
> "tosses" a hand grenade). According to advice that I solicited from
> licensing_at_fsf.org with respect to the cvs2svn project, the old CollabNet
> license was compatible with GPLv2, whereas the FSF's position is that
> the Apache 2.0 license is *not* compatible with GPLv2 (though it *is*
> compatible with GPLv3) .
The CollabNet license was just the Apache 1.1 license with CollabNet
and tigris substituted for Apache. Given the way the Apache 1.1
license was worded, this was not an uncommon way to apply that license
to projects that were not a part of the ASF. According to my
readings, the Apache 1.1 license is NOT considered GPLv2 or GPLv3
compatible so I do not see how the CollabNet license could be either.
Given that Subversion has a critical dependency on APR and even
exposes some if its struct in our API, I do not see how it matters.
To use Subversion you have to be OK with Apache 2.0 license anyway.
Although it is certainly debatable whether
> the import of one library by another constitutes creating a derivative
> work, this issue will undoubtedly cause concerns among other projects
> and distributors (e.g., Debian Linux).
I do not see how that could be possible. They all distribute Apache
httpd and APR which are Apache 2.0 licensed. Subversion moving to a
standard license and helping do away with license proliferation should
be welcomed by these groups.
> In fact, this incompatibility is already causing consternation in the
> Mercurial project, which is GPLv2 but whose SVN->hg convert plugin uses
> the SVN Python bindings. A few days ago Matt Mackall disabled the SVN
> support in their repo due to perceived license incompatibility.
> Analogous problems are imaginable with the git project (also GPLv2) with
> respect to its git-svn support.
Frankly, that is none of our business. We have always been
"Apache-licensed" and have required Apache 2.0 licensed software. It
is up to those projects to decide if they can use our code or not.
Having us move to a more standard license should be a good thing. If
they have a problem with the Apache 2.0 license then they already
should not have been using our code due to the APR requirement. So
this is another case where using a standard license has helped. hg
apparently never intended to use our Apache-licensed code and now that
the license is clear the decision became easier for them to make.
> I can respect a change to the Subversion license, and welcome a change
> from the obscure CollabNet license to a better-known license. But I
> would hate for the project to stumble into a thicket of licensing issues
> without having considered the ramifications.
We understood that moving to a standard license simplifies the
interpretation of the licensing issues. Whether or not another
license or project considers its code to be compatible is now a lot
easier for them to decide. That should be as far as we want to get
I will note that TortoiseSVN is GPL licensed and has never had a
problem building upon Subversion and APR in its code.
Received on 2009-09-27 23:23:21 CEST