License compatibility

[znicholls]

I was wondering if anyone had a clear answer to a question about licensing implications of dependencies. At present, pyam is Apache 2.0 licensed and iam-units (on which pyam depends) is GNU GPL3 licensed. Is anyone confident about whether this actually a compatible combination?

For what it's worth, I've read arguments both ways. As far as I understand, arguments saying its fine are basically, "It's Python and nothing is dynamically linked so it's like calling a CLI tool which means you don't get the license restrictions passing 'up the chain'." Arguments against are, "The package's behaviour depends on its dependencies so it has the same implications as dynamically linking hence your library's license has to be compatible with all dependencies."

Thoughts @phackstock @khaeru @danielhuppmann ?

[rgieseke]

nothing is dynamically linked

Do you mean "statically" linked? I read the argument that static linking would trigger GPL, even though some argue that both ways would trigger or linking not be decisive at all.

https://softwareengineering.stackexchange.com/questions/167773/how-does-the-gpl-static-vs-dynamic-linking-rule-apply-to-interpreted-languages

[znicholls]

Oops yes statically my bad

…

On Tue, 13 Dec 2022 at 6:39 pm, Robert Gieseke ***@***.***> wrote: nothing is dynamically linked Do you mean "statically" linked? I read the argument that static linking would trigger GPL, even though some argue that both ways would trigger or linking not be decisive at all. https://softwareengineering.stackexchange.com/questions/167773/how-does-the-gpl-static-vs-dynamic-linking-rule-apply-to-interpreted-languages — Reply to this email directly, view it on GitHub <#716 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFUH5G55TRJ5VDWVZQGKVRTWNAR4HANCNFSM6AAAAAAS42AN3U> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[gidden]

IANAL - but my understanding (for non-compiled languages) - as long as source code is not duplicated, then GPL is not triggered.

Having done the briefest of research, it seems like this is indeed contentious, with FSF arguing that python imports would trigger GPL. It seems that LGPL was designed to support this use case.

@khaeru any input here from your perspective?

[lukekirwan]

Hi, sorry for interrupting, but @phackstock asked if I could help with this last night and I only got a chance to look at it now. There's an EU license compatiblity checker for mixing licenses that may help, https://joinup.ec.europa.eu/collection/eupl/solution/joinup-licensing-assistant/jla-compatibility-checker

From what I can see, at least in terms of the compatibility tool, it's a matter of context. So If you are not wrapping up iam-units into Pyam, iam-units and pyam can be licensed differently. If you have merged iam-units with Pyam then pyam should use the same license as iam-units. https://joinup.ec.europa.eu/licence/compatibility-check/GPL-3.0-or-later/Apache-2.0

In case the URL goes dead here's the text from the compatibility check

[lukekirwan]

Compatibility is depending on the type of "Use".

• Private or internal use is never restricted by any open licence and the resulting combined work does not need specific licensing, as soon it is not distributed to third parties.
• In case the two components are not merged, but used according their normal usage instructions and distributed together to third parties (i.e. on the same media or distribution), each component - even modified - keeps its primary licence: inbound licence or outbound licence.
• In case the two components that could be used independently are linked for ensuring their interoperability, for example APIs or data structures for exchanging parameters are copied/reproduced from one program to the other, Some legal theses (not confirmed in courts) state that by a kind of "viral effect" the inbound licence becomes applicable to the whole combined work. However, in so far the European Law would be applicable, it states that by exception to strict copyright rules, such reproduction can be done without obtaining the right holder permission or licence, provide this linking is compatible with a normal exploitation of the programs and does not conflict the legitimate interest of copyright holder. This is resulting from Directive 2009/24/EC recitals 10 and 15 invoking a copyright exception for making interoperable two components from various providers.
• In case substantial parts of the source code covered by the inbound licence have been merged / integrated with code covered by the outbound licence, the outbound licence, which is compatible with the inbound licence, authorise distribution of the whole combined work under the inbound licence. This is applicable to this new combined work only (a derivative or "forking" from both source codes, which is a specific project with a specific name), and does not normally authorises relicensing (changing the licence) of the original code covered by the outbound licence.

[khaeru]

Thoughts @phackstock @khaeru @danielhuppmann ?

@khaeru any input here from your perspective?

I suspect by hunting around in the scientific Python ecosystem, one can find examples of GPL utility packages which are dependencies of non-copyleft packages. I don't have time to do this, however.

@lukekirwan's second bullet appears to me to cover the present case, which is even weaker, as iam-units is not even being provided with pyam "on the same media or distribution" AFAIK.

[znicholls]

Thanks everyone for comments, I'm happy to close then in case someone else wants to continue