Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple APILearn More
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.
@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.
@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).
@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.
@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.