LGPL relicense port of rsync

[Andrey Gursky]

Hi,

from my point of view:

On Sat, 9 Jan 2016 14:48:09 +0100
Per Lundqvist <perlundq at gmail.com> wrote:

> ...
> > Getting the approval for a relicensing I think the contributions to
> > rsync have to be analyzed in detail to approach a reasonable number of
> > contributors.
> >
> > I experienced that finding a responsible person that is willing to
> > discuss such a case in an organization that contributed source code is
> > nearly impossible.

If they don't want to bother with just discussing, why would they take a
big effort to claim? And your proposition for LGPL is not very
different in opposite to BSD or public domain.

> > Looking at the source code (my short analysis refers to rsync-3.1.1)
> > some questions come to my mind to simplify the relicensing discussion:
> > - the GPL headers in the source code mention copyright owners: might it
> > be sufficient to approach these copyright owners and leave out every
> > patch author?
> 
> No I do not think so, everyone that has contributed owns its code and
> has to approve even if they aren't listed on the copyright
> notice (unless they have explicitly given it away). Otherwise you can
> never be fully protected against any future claims - although it's rather
> unlikely for LGPL (but I wouldn't chance).

I saw 2 approaches over the net. The most reliable one you're referring
to, which is used by Google. And the second one: you are really not
allowed to claim copyright on whatever you're writing. Your writings
must conform to rules of what can be copyrighted. In such a case each
contribution must be checked. And the problem with such a check is that
it depends on who and when have checked this and it is always possible
that not all will share the same opinion. But this second approach is
also reasonable, doesn't it?

By the way, why the rsync maintainer shouldn't also be afraid of
claims from people who contributed code, but their full names with
email addresses have been mentioned neither in a copyright header
nor in the AUTHORS and CONTRIBUTORS files? It is a big sin to violate a
GPL for others, but to violate a copyright for the project itself is
not a big deal?

> > - the yajsync implementation refers to a subset of rsync: does the
> > derivative work comprise only the according parts of the rsync source code?
> 
> Yes I believe it does, but the lines are murky. The code has evolved
> quite a bit since the beginning so it might be tricky to really sort
> this out.
> 
> > - supposed some parts of yajsync were developed looking at the rsync
> > interface definition (the man page) only [I can state this for the small
> > parts I contributed to yajsync]. Are these parts still derivative work
> > to rsync?
> 
> There's not a lot you can implement just by looking at the man
> page. The main thing is that you cannot implement the protocol without
> complying to GPL. There is no protocol specification so to have
> another license you would either have to reverse engineer it by
> looking only at the protocol itself (quite tricky I would say), or
> write a specification first using the code and then let somebody else
> implement the protocol from scratch using only the specification.

I don't believe the protocol can be GPL'ed, regardless it is
pseudocode- or C-documented (C code is simultaneously a documentation).
And I'm not alone with this [1] [2].

> > - supposed an author contributed a part of rsync like the md5
> > implementation that is not in use in yajsync because of a Java
> > replacement: does such an author have to be approached?
> 
> No that is not necessary. It's only necessary for code that is
> actually read/copied (even if that code is completely rewritten and
> only partially used).
> 
> >
> > Focusing on the source code only without tests, config scripts and free
> > libraries (zlib and popt) and without common knowledge functions like
> > md5 or sprintf or getaddrinfo or getpass and without rsync-batch I come
> > up with the following individuals being mentioned with a copyright:
> >
> > Wayne Davison
> > Andrew Tridgell
> > Martin Pool
> > Jeremy Allison (maybe only indirectly by code copy)
> > Paul Mackerras
> > Scott Howard
> 
> Yes, but there are more than that. And searching for attributed
> authors gives:
> 
>    $ git log -p | awk '$1 == "Author:"'| sort | uniq -c | sort -nk1
>    1 Author: restrict <restrict>
>    1 Author: Stefan Behrens <sbehrens at giantdisaster.de>
>    2 Author: Ben Walton <bwalton at artsci.utoronto.ca>
>    3 Author: John H Terpstra <jht at samba.org>
>    4 Author: Jos Backus <jos at samba.org>
>    10 Author: Tiziano Müller <tiziano.mueller at stepping-stone.ch>
>    11 Author: Paul Mackerras <paulus at samba.org>
>    14 Author: Paul Green <paulg at samba.org>
>    26 Author: Matt McCutchen <matt at mattmccutchen.net>
>    54 Author: rsync-bugs <rsync-bugs>
>    66 Author: J.W. Schultz <jw at samba.org>
>    208 Author: David Dykstra <dwd at samba.org>
>    545 Author: Andrew Tridgell <tridge at samba.org>
>    704 Author: Martin Pool <mbp at samba.org>
>    4710 Author: Wayne Davison <wayned at samba.org>
> 
> and then possible further investigate relevant output from
>  $ git log -p | egrep -i '\<author\>'| grep -v '^Author:'
> 
> and also investigate anyone not possible mathched by the above (which
> is all the lines from git log -p, especially surrounding copyright
> notices).
> 
> and double check in the mailing list archives and the bug tracker.
> 
> ...ugh
> 
> >
> > Maybe you could approach these people first to get the process started.
> 
> The main thing before even starting such a process is that it's still
> very hard to evolve a port if the upstream project has an incompatible
> license. You would need to ask for permission to relicense any
> relevant future modifications also.
> 
> So then that leaves out:
> 
>  1) split rsync into a library and application part and then make the
>     library part LGPL:ed. This could be useful for others too I
>     guess...

This would be very useful!

And is partially approached by librsync. But anyone remember why rsync
hasn't been splitted properly a decade ago? I mean: librsync (offline
and online aware), librsync-protocol (for online transfer),
rsync-frontend.

The problem with librsync is that it is not pipelined-transfer aware,
e.g. data can't be transferred unless all matches have been found. The
question is, are there any other significant differences? If not one
could try to introduce such a mode and implement the transfer protocol.
Then one would need just a frontend "rsync-lite".

> or
> 
>  2) write a protocol specification instead.

As mentioned above, I would treat the C code as a protocol
specification, as long as one is not provided in a different way.

> 1) is not that easy and it still requires all contributors to the
> library part to give permission to a license change. That's a lot to
> ask of the rsync project.

I always remember that videolan has succeeded with such an effort.

> I guess I could write an initial protocol specification - but it would
> not be complete and I wouldn't be able to relicense my library to
> LGPL anyway.
> 
> So I guess I have convinced myself that it is not worth the effort
> trying. Time is probably better spent coding ;) And that's OK too, it is not
> that big of a deal anyway.

Or think about following. You insist that your Java library is
derivative work from the C program. OK. However, I believe a
"translation into other languages" doesn't mean you make changes into
the workflow by code restructuring, introducing another data
structures, classes and so on. More such changes you made, less it just
a "translation" and more an inspiration. Often I read in code not
"based on" but "inspired by".

Anyway, you have written every line in Java. This means you're a
copyright holder on this. Thus you're allowed to license your work as
you wish. In case you still insist it is a derivative work, you're
required to allow the usage of your code under GPL. But! As a copyright
holder you're allowed to give an arbitrary license additionally and
even on a per case basis.

This was my opinion. Additional references to approve or disapprove are
welcome :)

[1] http://datacharmer.blogspot.de/2010/03/protocol-gpl-and-how-bazaar-can-help.html
[2] http://bugs.mysql.com/bug.php?id=52107


P.S. I'm really wondering, why Martin Pool, now librsync maintainer
doesn't participate on rsync mailing list anymore.