LGPL relicense port of rsync

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

LGPL relicense port of rsync

Per Lundqvist
Hi,

I am maintaining a port of rsync (https://github.com/perlundq/yajsync)
which is GPL:ed of course. The main purpose of the project is to
provide a Java API library for the rsync protocol. It would
therefore be really nice to be able to use LGPL as the license.

But in order to do so I would first have to get a list of all the
individual contributors to rsync and then be able to contact them and
ask them to agree to this and also verify their identity. I do however suspect
this to be an almost impossible task...

Is this as futile as it seems? ;)

And is there a complete list of contributors available somewhere?

thanks,
--
Per Lundqvist

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Reply | Threaded
Open this post in threaded view
|

Re: LGPL relicense port of rsync

Florian Sager
Am 07.01.2016 um 23:26 schrieb Per Lundqvist:

> Hi,
>
> I am maintaining a port of rsync (https://github.com/perlundq/yajsync)
> which is GPL:ed of course. The main purpose of the project is to
> provide a Java API library for the rsync protocol. It would
> therefore be really nice to be able to use LGPL as the license.
>
> But in order to do so I would first have to get a list of all the
> individual contributors to rsync and then be able to contact them and
> ask them to agree to this and also verify their identity. I do however suspect
> this to be an almost impossible task...
>
> Is this as futile as it seems? ;)
>
> And is there a complete list of contributors available somewhere?
>
> thanks,
> --
> Per Lundqvist
>

Hi Per,

relicensing the yajsync library with LGPL might be a precondition for
the longterm awareness and survivability of the yajsync project. So it's
really worth the attempt to relicense.
I saw that librsync is as well LGPL'ed. In my view it would have never
gotten the attention and usage/linkage it has today with being GPL'ed only.

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?
- the yajsync implementation refers to a subset of rsync: does the
derivative work comprise only the according parts of the rsync source code?
- 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?
- 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?

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

Maybe you could approach these people first to get the process started.

Regards,
Florian


--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Reply | Threaded
Open this post in threaded view
|

Re: LGPL relicense port of rsync

Per Lundqvist
...

> 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 <[hidden email]>
   2 Author: Ben Walton <[hidden email]>
   3 Author: John H Terpstra <[hidden email]>
   4 Author: Jos Backus <[hidden email]>
   10 Author: Tiziano Müller <[hidden email]>
   11 Author: Paul Mackerras <[hidden email]>
   14 Author: Paul Green <[hidden email]>
   26 Author: Matt McCutchen <[hidden email]>
   54 Author: rsync-bugs <rsync-bugs>
   66 Author: J.W. Schultz <[hidden email]>
   208 Author: David Dykstra <[hidden email]>
   545 Author: Andrew Tridgell <[hidden email]>
   704 Author: Martin Pool <[hidden email]>
   4710 Author: Wayne Davison <[hidden email]>

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

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Reply | Threaded
Open this post in threaded view
|

Re: LGPL relicense port of rsync

Andrey Gursky
Hi,

from my point of view:

On Sat, 9 Jan 2016 14:48:09 +0100
Per Lundqvist <[hidden email]> 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 <[hidden email]>
>    2 Author: Ben Walton <[hidden email]>
>    3 Author: John H Terpstra <[hidden email]>
>    4 Author: Jos Backus <[hidden email]>
>    10 Author: Tiziano Müller <[hidden email]>
>    11 Author: Paul Mackerras <[hidden email]>
>    14 Author: Paul Green <[hidden email]>
>    26 Author: Matt McCutchen <[hidden email]>
>    54 Author: rsync-bugs <rsync-bugs>
>    66 Author: J.W. Schultz <[hidden email]>
>    208 Author: David Dykstra <[hidden email]>
>    545 Author: Andrew Tridgell <[hidden email]>
>    704 Author: Martin Pool <[hidden email]>
>    4710 Author: Wayne Davison <[hidden email]>
>
> 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.

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Reply | Threaded
Open this post in threaded view
|

Re: LGPL relicense port of rsync

Per Lundqvist
Hi Andrey,

2016-01-23 4:02 GMT+01:00 Andrey Gursky <[hidden email]>:
...
> 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

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Reply | Threaded
Open this post in threaded view
|

Re: LGPL relicense port of rsync

Per Lundqvist
In reply to this post by Andrey Gursky
Hi Martin,

2016-01-23 18:41 GMT+01:00 Martin Pool <[hidden email]>:
> 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

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
mbp
Reply | Threaded
Open this post in threaded view
|

Re: LGPL relicense port of rsync

mbp
In reply to this post by Per Lundqvist

>
> > 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

These are talking about different situations:

 - 'porting' in the sense of making code run on a different platform while still having some code in common
 - line-by-line rewrite or translation
 - writing a new program using the rsync source as documentation of the protocol, as you are doing

In my (not a lawyer) opinion, the last of them does not create a copyright derivative, and (separately) I don't object to you doing that on GPL'd work that I wrote. I would consider the first two to be a violation.

I think you have a couple of cheap options to get some clarity:

 - mail the other key authors listed above explaining what you're doing and ask if they object 
 - mail the FSF or SFLC as custodians of the L/GPL
 
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.


 

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Reply | Threaded
Open this post in threaded view
|

Re: LGPL relicense port of rsync

Per Lundqvist
2016-01-24 18:53 GMT+01:00 Martin Pool <[hidden email]>:

...

>> 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
>
>
> These are talking about different situations:
>
>  - 'porting' in the sense of making code run on a different platform while
> still having some code in common
>  - line-by-line rewrite or translation
>  - writing a new program using the rsync source as documentation of the
> protocol, as you are doing
>
> In my (not a lawyer) opinion, the last of them does not create a copyright
> derivative, and (separately) I don't object to you doing that on GPL'd work
> that I wrote. I would consider the first two to be a violation.

OK, that distinction does make sense.

> I think you have a couple of cheap options to get some clarity:
>
>  - mail the other key authors listed above explaining what you're doing and
> ask if they object
>  - mail the FSF or SFLC as custodians of the L/GPL

Yes that is a very good idea. I will start by contacting FSF and see
if they can clarify this.

Thanks.

--
Per Lundqvist

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html