On Fri, 12 Feb 2010, Sverre Rabbelier wrote:
> Heya,
>
> On Fri, Feb 12, 2010 at 10:35, Johannes Schindelin
> <Johannes.Schindelin@xxxxxx> wrote:
> > On Fri, 12 Feb 2010, Mike Hommey wrote:
> >> It is already mentioned on the wiki that this would probably be a
> >> problem, license-wise. (the svn library is Apache license, which is
> >> incompatible with GPLv2)
>
> Yeah, guess who put that there ;).
>
> > So git-remote-svn would have to be under an Apache-compatible license, so
> > what? It is not as if git-remote-svn was a derivative work of Git, just
> > because it abides by a very simple command-line interface that happens to
> > be defined in Git, but would work anywhere else, too.
>
> Excellent point, I think we could safely argue that if we only expose
> 'import' and 'export' (so adhere to the fast-import/fast-export format
> that is already widely used), that it is indeed not a derative work.
> Also, becaus of how we set up the remote helpers (as drop in
> binaries), we shouldn't have to worry too much about distributing?
It was intentional on my part that the mode where the helper only talks to
the remote system and to its parent be not a derived work of the parent,
under the usual analysis that something is not covered by copyright if it
has to be a particular way for functional or interoperability reasons.
This does not strictly mean that helpers won't be derived works of git,
simply because they may use git code internally (strbuf, for example), and
because it's currently much easier to do incremental imports by looking up
the current state from the git object database than to be completely
agnostic.
Also note that the current helper protocol is definitely insufficient to
replace git-svn ('export' isn't actually specified, although I think
everyone who guesses how it works guesses the same thing), and the
transport code needs to be extended to handle the "dcommit" situation
(when you push a commit, the state that you see on the remote changes
based on the semantics of what you sent, but it does not change to have
the same hash as what you pushed).
Distribution of binaries shouldn't be a problem (the GPL specifically
states that just coming in the same package doesn't matter for licensing,
and this is generally what copyright laws say anyway); the main issue is
that packages would have to specify which things have which license, since
it won't just be obvious.
-Daniel
*This .sig left intentionally blank*
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html