License may not be properly implemented?

[banesullivan]

Please reference the instructions from the license itself on how to apply it to your work. My impression is that you are not correctly following this at this time and technically it is unclear who the copyright is held by.

EOmaps/LICENSE

Lines 623 to 674 in 7136149

	How to Apply These Terms to Your New Programs
	If you develop a new program, and you want it to be of the greatest
	possible use to the public, the best way to achieve this is to make it
	free software which everyone can redistribute and change under these terms.
	To do so, attach the following notices to the program. It is safest
	to attach them to the start of each source file to most effectively
	state the exclusion of warranty; and each file should have at least
	the "copyright" line and a pointer to where the full notice is found.
	<one line to give the program's name and a brief idea of what it does.>
	Copyright (C) <year> <name of author>
	This program is free software: you can redistribute it and/or modify
	it under the terms of the GNU General Public License as published by
	the Free Software Foundation, either version 3 of the License, or
	(at your option) any later version.
	This program is distributed in the hope that it will be useful,
	but WITHOUT ANY WARRANTY; without even the implied warranty of
	MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
	GNU General Public License for more details.
	You should have received a copy of the GNU General Public License
	along with this program. If not, see <https://www.gnu.org/licenses/>.
	Also add information on how to contact you by electronic and paper mail.
	If the program does terminal interaction, make it output a short
	notice like this when it starts in an interactive mode:
	<program> Copyright (C) <year> <name of author>
	This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
	This is free software, and you are welcome to redistribute it
	under certain conditions; type `show c' for details.
	The hypothetical commands `show w' and `show c' should show the appropriate
	parts of the General Public License. Of course, your program's commands
	might be different; for a GUI interface, you would use an "about box".
	You should also get your employer (if you work as a programmer) or school,
	if any, to sign a "copyright disclaimer" for the program, if necessary.
	For more information on this, and how to apply and follow the GNU GPL, see
	<https://www.gnu.org/licenses/>.
	The GNU General Public License does not permit incorporating your program
	into proprietary programs. If your program is a subroutine library, you
	may consider it more useful to permit linking proprietary applications with
	the library. If this is what you want to do, use the GNU Lesser General
	Public License instead of this License. But first, please read
	<https://www.gnu.org/licenses/why-not-lgpl.html>.

---

I also want to highlight a note from @jhkennedy in pyOpenSci/software-submission#138 (comment) that I second greatly:

Using a copy-left license like GPL means, for me, I will happily use and contribute to EOMaps, but I will be unable to build upon it as I'm obligated to use a permissive use license in my work. This is fine for EOMaps for the most part, I think, as it's more of an end-user package than a library.

Major +1 from me.

---

I want to ensure that you have deeply thought about your choice of license here and feel confident in using and applying that license to your work as well as understanding the tradeoffs that license may provide:

• If no to the above, then I'll do my best to provide you with support and resources to make that decision with confidence. A good place to start is PyOpenSci's licensing guide here: https://www.pyopensci.org/python-package-guide/documentation/repository-files/license-files.html
• If yes to the above, then I'll do my best to help ensure you are properly applying that license to your work

[raphaelquast]

Thank you very much for bringing this up!
I agree that licensing has to be improved and that GPL might not be the best choice for EOmaps due to the "same license" clause.
I will check the implications of switching to MPL or maybe LGPL and report back once I have a good idea of how to continue!

[raphaelquast]

@banesullivan I spent some time investigating details of licenses and their implications and there are some remaining questions where I was not able to find a definitive answer:

• To what extent am I responsible to choose a license that is compliant with the licenses of my dependencies?
• Considering the fact that one of the current core dependencies (e.g. cartopy) is licensed as LGPL would you recommend to just switch to LGPL or do you think it is still preferable (and legally OK) to still go with a more permissive license such as MIT or BSD? (what would be the benefit of this if the package still contains an LGPL licensed dependency ...especially since (as noted by @jhkennedy), EOmaps is not really intended as a "library" but rather as a end-user package...)
  • ... or in other words... would switching to a permissive license somewhat imply a "long-term goal" to get rid of any dependencies with more restrictive licenses?

Any insights from your side on this would be highly appreciated!

---

To get an idea of what my dependencies are using, I checked with the nice pip-licenses tool:

Here are some results (using dependency-groups from #216).
(output of pip-licenses --order=license in a fresh environment with only eomaps installed)

minimal dependencies (e.g. pip install eomaps )

Name	Version	License
packaging	23.2	Apache Software License; BSD License
python-dateutil	2.8.2	Apache Software License; BSD License
click	8.1.7	BSD License
colorama	0.4.6	BSD License
contourpy	1.2.0	BSD License
cycler	0.12.1	BSD License
descartes	1.1.0	BSD License
kiwisolver	1.4.5	BSD License
numpy	1.26.2	BSD License
scipy	1.11.4	BSD License
shapely	2.0.2	BSD License
Cartopy	0.22.0	GNU Lesser General Public License v3 or later (LGPLv3+)
Pillow	10.1.0	Historical Permission Notice and Disclaimer (HPND)
pyshp	2.3.1	MIT
fonttools	4.47.0	MIT License
pyparsing	3.1.1	MIT License
pyproj	3.6.1	MIT License
six	1.16.0	MIT License
certifi	2023.11.17	Mozilla Public License 2.0 (MPL 2.0)
matplotlib	3.8.2	Python Software Foundation License

full set of dependencies (e.g. pip install eomaps[all] )

Name	Version	License
importlib-metadata	7.0.0	Apache Software License
requests	2.31.0	Apache Software License
rioxarray	0.15.0	Apache Software License
tzdata	2023.3	Apache Software License
xarray	2023.12.0	Apache Software License
packaging	23.2	Apache Software License; BSD License
python-dateutil	2.8.2	Apache Software License; BSD License
cligj	0.7.2	BSD
llvmlite	0.41.1	BSD
multipledispatch	1.0.0	BSD
partd	1.4.1	BSD
OWSLib	0.29.3	BSD License
affine	2.4.0	BSD License
cairocffi	1.6.1	BSD License
click	8.1.7	BSD License
click-plugins	1.1.1	BSD License
cloudpickle	3.0.0	BSD License
colorama	0.4.6	BSD License
contourpy	1.2.0	BSD License
cssselect2	0.7.0	BSD License
cycler	0.12.1	BSD License
dask	2023.12.1	BSD License
datashader	0.16.0	BSD License
descartes	1.1.0	BSD License
fiona	1.9.5	BSD License
fsspec	2023.12.2	BSD License
geopandas	0.14.1	BSD License
idna	3.6	BSD License
joblib	1.3.2	BSD License
kiwisolver	1.4.5	BSD License
locket	1.0.0	BSD License
lxml	4.9.4	BSD License
mapclassify	2.6.1	BSD License
networkx	3.2.1	BSD License
numba	0.58.1	BSD License
numpy	1.26.2	BSD License
pandas	2.1.4	BSD License
param	2.0.1	BSD License
pycparser	2.21	BSD License
pyct	0.5.0	BSD License
rasterio	1.3.9	BSD License
scikit-learn	1.3.2	BSD License
scipy	1.11.4	BSD License
shapely	2.0.2	BSD License
threadpoolctl	3.2.0	BSD License
tinycss2	1.2.1	BSD License
toolz	0.12.0	BSD License
webencodings	0.5.1	BSD License
colorcet	3.0.1	CC-BY License
CairoSVG	2.7.1	GNU Lesser General Public License v3 or later (LGPLv3+)
Cartopy	0.22.0	GNU Lesser General Public License v3 or later (LGPLv3+)
PyQt5	5.15.10	GPL v3
Pillow	10.1.0	Historical Permission Notice and Disclaimer (HPND)
PyQt5-Qt5	5.15.2	LGPL v3
pyshp	2.3.1	MIT
snuggs	1.4.7	MIT
PyYAML	6.0.1	MIT License
QtPy	2.4.1	MIT License
attrs	23.1.0	MIT License
cffi	1.16.0	MIT License
cftime	1.6.3	MIT License
charset-normalizer	3.3.2	MIT License
fonttools	4.47.0	MIT License
netCDF4	1.6.5	MIT License
pyparsing	3.1.1	MIT License
pyproj	3.6.1	MIT License
pytz	2023.3.post1	MIT License
six	1.16.0	MIT License
urllib3	2.1.0	MIT License
zipp	3.17.0	MIT License
certifi	2023.11.17	Mozilla Public License 2.0 (MPL 2.0)
defusedxml	0.7.1	Python Software Foundation License
matplotlib	3.8.2	Python Software Foundation License
PyQt5-sip	12.13.0	SIP

[raphaelquast]

Just noticed that cartopy is also in the process of switching from LGPL to BSD-3: SciTools/cartopy#2285.

This stripps the question for the EOmaps license down to using either MIT or also BSD-3.
@banesullivan do you have any comments concerning which of the 2 licenses is more suitable?

[banesullivan]

I think MIT and BSD-3 are both fantastic, permissive licenses and either would be a solid choice here.

In practice, I don't think there would be much difference between these two licenses here. In my mind, I typically equate the MIT and BSD 3 clause licenses, but since I'm not a lawyer/expert, I'd like to point you to this great answer: https://opensource.stackexchange.com/a/582

Typically, I go with the MIT license for everything, but in this case I think following the precedent set by the core upstream dependency of using BSD-3 would be a sound choice here.

[raphaelquast]

Thanks for your insights on this... they very much align with my opinion!

I'll start to implement relevant changes to switch to BSD-3 as soon as possible!

Since there have been no substantial contributions so far (only 1-liners and typos and most of them are no longer in the code),
I don't think it's required to get permission from the contributors to perform the license-change.

[raphaelquast]

There is now a PR to implement the switch from GPL to BSD-3 (#220)
@banesullivan It would be awesome if you could have a look and let me know if you see any issues with the way I implemented the license there.

[raphaelquast]

@banesullivan The change to BSD 3-clause has now been merged into the dev-branch to be included in the upcoming v8.0 release (#205)!

In addition I also added a section on Licensing to the FAQ to clarify that some upstream dependencies
have more restrictive licensing that might need to be considered more carefully (https://eomaps.readthedocs.io/en/dev/FAQ.html#licensing-and-redistribution), e.g.:

• required cartopy dependency is still LGPL (but will be BSD soon)
• optional Qt / PyQT gui framework bindings offers flexible licensing but requires GPL/LGPL for open-source projects

The good thing is that once the switch to BSD for cartopy is released, all core dependencies of EOmaps are BSD-compatible.

In my opinion this should address any Licensing concerns for EOmaps mentioned in this issue.

Please let me know if you see any further issues that should be addressed. (otherwise, I think this can be closed)

[banesullivan]

This all looks excellent and sounds good to me! Glad you found a compatible license and are happy with the implementation!