search

NLeSC / python-template

Netherlands eScience Center Python Template
https://research-software-directory.org/software/nlesc-python-template
Apache License 2.0
164 stars 74 forks source link

Potential license issue with prospector in Apache-2.0 projects #300

Closed jspaaks closed 2 years ago

jspaaks commented 3 years ago

https://pypi.org/project/prospector/ is licensed GPLv2+ but https://www.apache.org/licenses/GPL-compatibility.html says "However, GPLv3 software cannot be included in Apache projects."

Needs looking into

bouweandela commented 3 years ago

This is only a problem if you use prospector as a dependency (i.e. import prospector). If you use it as a command-line tool for linting your source code, it's not considered a dependency, just like the license of your text editor does not apply to the source code you write with it.

LourensVeen commented 3 years ago

There are several separate issues here. I agree with Bouwe that the project we're instantiating is not a derivative work of prospector if prospector is used only as a linting tool (even if you run it using import prospector and then calling it from your script). It's only a derivative work if the functionality of the program depends on code from prospector.

License compatibility is about the ability for someone else to combine Apache-licensed code and GPL-licensed code into a single derivative work. That derivative work would end up being licensed under both the GPL and the Apache license, which means that anyone distributing it would have to adhere to both licenses simultaneously. In case of the combination of Apache License 2.0 and GPLv2, that is impossible, because the Apache License 2.0 has a clause basically requiring you to not sue anyone for patent infringement of the licensed code, and the GPLv2 doesn't have such a clause and forbids any additional restrictions (which this is, at least according to the Free Software Foundation, although the Apache Software Foundation disagrees) from being added. So if you distribute the combined derivative work then you have to either remove the patent clause and violate the AL2.0, or keep it and violate the GPLv2.

Note that the FSF doesn't consider that patent clause a bad idea, it's just that software patents weren't an issue when the GPLv2 was written, and so no exception for such a clause was added. This has been fixed in the GPLv3, which everyone agrees is compatible with the AL2.0, but that doesn't help anything released under the GPLv2 only.

On the page you linked, the ASF says:

We avoid GPLv3 software because merely linking to it is considered by the GPLv3 authors to create a derivative work. We want to honor their license. Unless GPLv3 licensors relax this interpretation of their own license regarding linking, our licensing philosophies are fundamentally incompatible. This is an identical issue for both GPLv2 and GPLv3.

This statement isn't about license compatibility at all, it is about the policy of the ASF towards "Apache projects", this being the projects they steward. Their policy is to license their projects under the Apache License. If you have a GPL dependency then there are cases (e.g. when distributing a statically linked binary, to pick an uncontroversial example and avoid a discussion on what is and isn't linking and when a derived work is or isn't created) in which you have to license the whole thing under the GPL, meaning the GPL would also cover the part of the code that was created by the Apache Foundation. They don't want that, so they avoid GPL dependencies in their projects.

At the eScience Center our stance is similar, but we're not that strict about it. We try to avoid GPL dependencies, but if they're unavoidable then we'll use them. We'll still license the source code we've written under the AL2.0, so that people can use it under those terms if they don't need the GPL dependency, and if we make some kind of combined distribution then we'll license that under the GPL. If the dependency is GPLv2 only, then we'll have to either-or dual-license our code under the AL2.0 and GPLv2 to avoid the compatibility issue mentioned above.

egpbos commented 2 years ago

To conclude: for Python, using GPL-licenced dependencies is not an issue. Please reopen for further discussion.

LourensVeen commented 2 years ago

I don't agree with that summary, but the issue can be closed, yes :-).

egpbos commented 2 years ago

For brevity, I left out all the disclaimers, which all come down to: ask @LourensVeen when in doubt in specific situations ;)