...> 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 HowardYes, 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
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.
Hi Andrey, 2016-01-23 4:02 GMT+01:00 Andrey Gursky <andrey.gursky at e-mail.ua>: ...> 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.Yes, I agree. The risk of having a future lawsuit against my project would be pretty small if I relicensed it as LGPL. It is such a small project and it is the LGPL license we're talking about. But I would like to do this the right way (TM). And if rsync itself could be split into a LGPL licensed library + GPL application others could benefit from this too (and possible rsync also with an increased user base).> > 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?Yes. If the rsync project had asked all its contributors to give away their copyright, this would have been easier. But you cannot change this now (well you can, if you contact them and get their permission)> 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?I do not think it is a violation to not keep them listed. Aren't the AUTHORS and CONTRIBUTORS files only there to help out in these kind of situations? All the individual contributors to rsync have agreed to license their code as GPL, but they still have copyright on their code, it is just not that clear who they are for the case of rsync. ...> 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].I agree, the protocol itself cannot be GPL:ed, but since the only specification for the protocol is the code for rsync itself, I still think you are bound by the GPL license for any rsync compatible implementation. If you read any GPL code and reimplement it, even if it is completely unrecognisable, it still a derivative work. Although I do realise in practice people does not follow this at all. ...> > 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".OK I see. This would definitely be useful for a lot of projects. But I do not know if rsync could switch to this as easily (might be too big of a change and hard to combine with backwards compatibility to historic versions of the protocol).> > > 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.I think this would be a GPL violation. Couldn't big enough organisations easily "steal" GPL code by doing this?> > > 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.Thanks, that is interesting.> > > 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 :)You might be right but I am a bit hesitant. http://programmers.stackexchange.com/questions/58338/when-porting-code-must-i-follow-the-original-license http://programmers.stackexchange.com/questions/90232/original-author-rights-in-a-licensed-software-project?rq=1 http://programmers.stackexchange.com/questions/86754/is-it-possible-to-rewrite-every-line-of-an-open-source-project-in-a-slightly-dif I think that the best thing would be if rsync would be split into a library part (LGPL) and application part (GPL). This could make the rsync protocol even more used. But again, it could be quite some substantial work, both coding (?) but also getting permissions from previous contributors to relicense the library part. -- Per Lundqvist
Hi Martin, 2016-01-23 18:41 GMT+01:00 Martin Pool <mbp at sourcefrog.net>:> It seems like yajsync is a reimplementation of rsync's protocol by looking > at the GPL'd C rsync source, but it doesn't actually include any code from > rsync. Is that right?Yes correct, it is a complete rewrite in Java. Most of it is completely different, only some small parts of the actual code is actually similar to the original.> In that case I think the yajsync authors are welcome to use whatever licence > they think fit. > > If it was a line-by-line translation or a mere obfuscation of the existing > code that might be different.OK, but I am hesitant about this anyway, but I might very well be wrong.> > I don't consider the protocol copyrighted or restricted by the GPL.Agreed, the protocol is not copyrighted but the code is, and the code the only specification there is at the moment.> As for why am I not on this list? It's been a long time! I just got > interested in other things.Thanks for input! -- Per Lundqvist