It is legal to use some AGPL Library Methods into a LGPL code?

Usage itself is not restricted, you can use GPL code in any other code. The issue comes with distribution to outsiders, and in case of AGPL, also offering the service to outsiders over network.

@Fast-Nop This is a repo from github, it depends on third party AGPL Code, but is licenced as LGPL

@bettoisc IMO, it can call AGPL code without problems. It's just that if the project were distributed as a whole, all licences would have to be respected.

That's also why you can have MIT code parts in a GPL licenced project without having to re-licence the MIT portion - as long as you comply to both licences.

In practice, this means that the toughest OSS licence sets the tone for the whole project.

@Fast-Nop when you say "respect", do you refer to have a copy of the license AGPL? Because I think that use a method of an AGPL Code makes your code automatically AGPL. But if you can use it, keeping your compatible own licence and just adding a copy of the AGPL for the third party code, I'd be great

@bettoisc The LGPL part is calling AGPL methods, but since they seem to be separate repos, the LGPL part isn't doing the integration. The AGPL only kicks in once you integrate the whole thing into a single product.

Of course, it's a bit funny to have an LGPL library that needs AGPL code, but maybe the idea is to be able to remove that code portion and operate without these parts.

@Fast-Nop that makes me confused, when a code depends on some methods and variables to operate, is it not an integration? even when they are separated repositories, the code depends on it.

@bettoisc well the other side could also be a non-AGPL part with the same method name if it's a clean interface. The important thing when the product is ready is that AGPL obligations will apply to all of it.

If you have the similar, but much more common situation of GPL code and MIT code in the same project, that doesn't make the MIT code to GPL code; re-licencing 3rd party MIT code is not even legal. However, the obligations from the GPL would apply to the whole codebase, not just the GPL parts.

This is possible because fulfilling the GPL obligations automatically fulfils the MIT obligations, so the MIT licence is GPL compatible (but not the other way around).

Likewise in your case, fulfilling all obligations from the AGPL introduced by the AGPL part also fulfils the obligations from LGPL, so LGPL is AGPL compatible (but not the other way around).

@Fast-Nop and if we develop a library under other license as LGPL that has same functionality as the third party (AGPL) it'll has legal implications?

@bettoisc well suppose that you discard the AGPL part and instead develop something compatible of your own under say MIT (or closed source). In this case, you would only have to respect the LGPL obligations from the LGPL code.

If you decide to replace the AGPL part by something else (developed on your own or not) that has LGPL, then you would have to respect the LGPL obligations from this part, too.

In both cases: if you only run the resulting binary on your own server and offer the usage over network, then you don't distribute the binary to anyone. Therefore, the LGPL does not oblige you to give the source code (or its modifications) of the LGPL parts to anyone.

If this network usage is the scenario you intend and don't want to give the source code of the whole project to your users, then it would be best not to use anything that has AGPL.

@Fast-Nop Perfect, I currently can't share this project, I've a confidentiality agreement signed, but I worried about the fact to be sue for copy its functionality or something like that

@bettoisc that won't be an issue if you do a "clean room" implementation yourself. The legal basis for the GPL's copyleft is the traditional copyright, and this does not protect ideas themselves. Patents could do that, though patents on algorithms are not possible in all countries, and certainly not on things that already have existed before (prior art).

GPL only protects the code implementation and any form of direct derivatives, like modifications or ports to other programming languages or translation to binary machine code. But if you do a "clean room" implementation yourself, then you can't run into that.

Note, just for caution: I've been into OSS licences for quite a while, but I'm not a lawyer.

@Fast-Nop it doesn't matter if you're not a lawyer, your opinion it enough for me