[radvd-devel-l] radvd licensing history investigation, and future licensing directions
pekkas at netcore.fi
Thu Feb 4 09:04:54 EST 2021
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.
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.
> 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:
> 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.
More information about the radvd-devel-l