LGPL relicense port of rsync

[Per Lundqvist]

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