...> 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.
>
> 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).
> - 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.
> - 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...
or
2) write a protocol specification instead.
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 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.
--
Per Lundqvist