[slivingston]

This PR is a very small patch to #252 so that the license field of pyproject.toml gives the license of this package, not its dependencies. When creating distributions that include dependencies, respective licenses are bundled as separate LICENSE files.

@moorepants Does that match your understanding of how to indicate the license in wheels? I ask because you commented on the relevant PR previously.

Closes #258

[moorepants]

Given that BSD is compatible with GPL, my understanding is that slycot would simply be licensed as GPL. You'd have to figure out whether that is GPL 2 or 3 and whether the gcc exception is included. A website like https://licensecompat.com/ is helpful to figure out the final license that encompasses all compatibilities.

[slivingston]

Given that BSD is compatible with GPL, my understanding is that slycot would simply be licensed as GPL. You'd have to figure out whether that is GPL 2 or 3 and whether the gcc exception is included. A website like https://licensecompat.com/ is helpful to figure out the final license that encompasses all compatibilities.

@moorepants Sorry, I was not clear in my question. I believe that license in pyproject.toml should have the license of the package itself only. When bundling wheels, the licenses of dependencies should be indicated in some other way, like LICENSE text files, not by adding a dependency's license to license in pyproject.toml. Do you agree?

In PR 252, the author wrote

I have also changed the "license" field in pyproject.toml to account for all the dependencies, though I see other projects, e.g., scipy-openblas64, don't do that: the license field seems to only refer to the project's "own" code.

and you reacted with 👍 , so I am asking now to confirm standard practice (in your view) of making wheels.

[roryyorke]

ugh, sorry. I forked your branch to test the conda failure, and pushed to it instead of my copy. I'm going to force push to fix it.