[radvd-devel-l] radvd licensing history investigation, and future licensing directions

[Reuben Hawkins]

I also have no objections to relicense my contributions to the project.

On Thu, Feb 4, 2021 at 6:07 AM Pekka Savola <pekkas at netcore.fi> wrote:

> Hello,
>
> When I was a maintainer I brought up (over 10 years ago) the issue of
> swiching to a more simplified license with previous authors (listed in
> source code copyright clauses). I don't recall the details, but I
> believe did not receive responses from all of them or the response
> might have been at least partially negative, ie. they did not see a
> need for change (although I myself did).
>
> I did not pursue the issue further, because doing so might have
> required identifying and reimplementing those parts of the code that
> were contributed under the original license and the contributor did
> not consent to relicensing it under a different license. This would
> have potentially been a big task for modest gains.
>
> You're of course welcome to try again. I have personally no objection
> to relicensing my very modest contributions under a different license.
>
> Pekka
>
> On Mon, 1 Feb 2021, Robin H. Johnson wrote:
>
> > TL;DR: should radvd be relicensed? Possibly a plain 3-clause BSD license?
> >
> > radvd's present license presents packaging problems for all parties that
> > wish to integrate with GPL code.
> >
> > Examples:
> > Fedora: https://fedoraproject.org/wiki/Licensing/radvd_License
> > ClearLinux: https://github.com/clearlinux/distribution/issues/2243
> >
> > This has been known as a problem for a very old time:
> > http://lists.litech.org/pipermail/radvd-devel-l/2006-July/000229.html
> >
> > radvd is licensing under the original 4-clause BSD license, with
> > the advertising clause, and an ADDITIONAL pass-through restriction if
> > added by some party on route.
> >
> > Hopefully Pekka, as the author of that message, and the original authors
> > (Lars Fennberg, Pedro Roque) can shed some light of some of the
> > historical reasons behind the original license choice.
> >
> > Further, I'd like to open discussions about moving to an OSI-compatible
> > license, that is ideally GPL compatible. I know that it will require
> > agreement from a significant majority of all copyright holds, but at
> > this point the discussion should be what to relicense to.
> >
> > I feel the goal should be a straight conversion to a less-restriction
> > BSD license: 3-clause or 2-clause. It would drop the advertising and
> > pass-through restriction, and leave any other users untouched.
> >
> > Conversion to other licenses, such as GPL or Apache-2 may end up
> > imposing more restrictions and complexity on distributors than the
> > 3-clause BSD license. (e.g. the directional nature of license
> > incompatibility between Apache-2 and GPL licenses).
> >
> > This also opens interesting possibilities for research:
> > Have all parties known to have shipped radvd under the existing license,
> > specifically in commercial products, complied with the license as it
> > stand? My cursory research would suggest that commercial products have
> > not complied with it, but enforcement would be a massive undertaking.
> > Better to forgive and let live.
> >
> >
>
> --
> radvd-devel-l mailing list  :  radvd-devel-l at lists.litech.org
> http://lists.litech.org/listinfo/radvd-devel-l
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.litech.org/pipermail/radvd-devel-l/attachments/20210204/a26a29f2/attachment.html>