Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Licensing of babeld and ldpd #1923

Closed
dmbaturin opened this issue Mar 19, 2018 · 4 comments
Closed

Licensing of babeld and ldpd #1923

dmbaturin opened this issue Mar 19, 2018 · 4 comments
Labels
question Not a bug

Comments

@dmbaturin
Copy link
Contributor

All libraries under /lib are licensed under GPL, including zclient.h. This makes me wonder why LGPL is and has been included since Zebra times if none of the libraries is under LGPL. This implies that everything that links with them must also be under GPL.

However, babeld and ldpd are under MIT. Since they link with those libraries, their own license is moot: the composite work after compiling and linking clearly ends up under GPL. Moreover, if someone is trying to distribute modified versions of them under GPL-incompatible conditions, they will, perhaps unknowingly, violate GPL.

Shouldn't those daemon be relicensed under GPL to make their effective status clear?

@mwinter-osr
Copy link
Member

@dmbaturin You are correct, that the "composite work after compiling" is under GPL.
However, the source itself does not have to be under GPL. You can take the Babel or LDP
code and build it on your own (may need to modify it a bit) and use any other compatible
license to THIS PART for your own derivate work.

MIT/BSD licenses are compatible to GPL in a way, that we can copy and include code licensed under it in a GPL licensed binary.

But the source code is not "composite work", but rather a "collection".
So, yes, if you compile the code, then the result is GPLv2+, but not for the source.

On the LGPL, I'm not sure. This sounds like a "bug", because you might be right and I'm not aware of any parts under LGPL. (But could be wrong - did you check headers on all files?)

@mwinter-osr mwinter-osr added the question Not a bug label Mar 19, 2018
@qlyoung
Copy link
Member

qlyoung commented Mar 19, 2018

The only part we have under LGPL is two copy-pasted source files from glibc, specifically lib/strlcat.[ch], which were copied into Quagga/FRR because it's a GNU extension and not part of the standard.

In the project root we have a copy of the LGPL license, which itself says:

[This is the first released version of the Lesser GPL.  It also counts
 as the successor of the GNU Library Public License, version 2, hence
 the version number 2.1.]

I would guess -- though I am not sure -- that the intent was to remain GPLv2 licensed and this was interpreted as an updated version of the GPLv2 license.

I am not a lawyer, nor do my statements represent the opinions of this project as a whole.

@richardfontana
Copy link

@qlyoung I don't think so, looking at the Quagga repository, if I understand correctly, LGPLv2.0 (in COPYING.LIB) was added around the same time as at least some of the source files taken from glibc, so I would guess it was an effort to retain and comply with the license of glibc as to such files.

@eqvinox
Copy link
Contributor

eqvinox commented Apr 16, 2019

Closing since there is nothing to be done here.

Our files indicate in their header which license applies to them (particularly LGPL only applies to a few files copied from glibc; libfrr as a whole is under GPLv2+)

babeld & ldpd source code remains under their respective licenses, but compound works with libfrr (e.g. object files & binaries linked against it) must be distributed under the GPLv2+.

@eqvinox eqvinox closed this as completed Apr 16, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Not a bug
Projects
None yet
Development

No branches or pull requests

5 participants