zwave-js-server-python
zwave-js-server-python copied to clipboard
home-assistant-libs
Use SPDX license identifier
Use the SPDX license identifier for Apache-2.0 instead of the whole license file inside the project metadata. This will make it easier to correctly identify the project license. See also PEP-639 which is close to being finalized.
https://spdx.org/licenses/
https://github.com/home-assistant-libs/zwave-js-server-python/blob/11652fd1045661d6e0485cb78437084d22e49a07/LICENSE#L1-L3
Use the SPDX license identifier for GPL-2.0-or-later
We use Apache 2.0.
Use the SPDX license identifier for GPL-2.0-or-later
We use Apache 2.0.
Sorry, copy-paste error in the PR description. The file change is correct though.
How compatible is this with our current license validation in Home Assistant core? I know there was some work done already to replace the text variable with classifiers in 3rd party libraries.
How compatible is this with our current license validation in Home Assistant core?
It's fully compatible. The current implementation just looks for "Apache License" and similar (which is obviously part of the full license text) but it also checks the SPDX identifier "Apache-2.0".
I found this as part of an effort to improve the license check in Core. See https://github.com/home-assistant/core/pull/123119 for details.
I know there was some work done already to replace the text variable with classifiers in 3rd party libraries.
That was a mistake IMO. License classifier have several shortcomings compared to full license expressions so I believe the latter will be the future, especially with PEP 639 finally being finalized after such a long time.
Anyway, I don't yet plan on updating opening PRs in other projects, besides this one. I'd appreciate your feedback on https://github.com/home-assistant/core/pull/123119. Maybe we can discuss it there further if there are open questions?
License SPDX identifiers sounds good. But until the PEP is accepted I don't think we should try to change libraries in one way or the other. I think we should try to be as forgiving as possible in our core license validation. If we can detect a valid open source license that's enough and we shouldn't try to nudge libraries until there's a clear path forward as stipulated by the PEP.
License SPDX identifiers sounds good. But until the PEP is accepted I don't think we should try to change libraries in one way or the other.
The current status https://discuss.python.org/t/pep-639-round-3-improving-license-clarity-with-better-package-metadata/53020/80 from the PEP-Delegate. They are only discussing one last implementation detail around the supported glob syntax for license-files. Everything else looks good.
we shouldn't try to nudge libraries until there's a clear path forward as stipulated by the PEP.
I'd slightly disagree here. For example, as mentioned in https://github.com/home-assistant/core/pull/123119, poetry will auto-add the Other/Proprietary License license classifier if no valid SPDX license is detected. Just from looking at the classifiers alone it isn't clear what the intent here would be ['Apache Software License', 'Other/Proprietary License'].
As mentioned, I won't go around opening PRs for it. However, I still think this particular one is still fine to merge as is 😄
PEP 639 has been provisionally accepted. It'll still take some time before the build backends fully support it though. However, changing the license text to the SPDX identifier should be fine now. Saw you also merged a similar PR in another project: https://github.com/MartinHjelmare/aiovlc/pull/268
That project is using poetry which documents that the SPDX identifiers should be used for the license field. I think we should wait until the PEP is fully accepted until we move forward here.
That project is using poetry which documents that the SPDX identifiers should be used for the license field.
BTW: Both (poetry and setuptools) output to the same project metadata field: License.
The setuptools documentation doesn't clarify what way to identify the license is preferred and the Python Packaging User Guide prefers the classifiers. Until this is spelled out better (accepting the PEP will do that), we should wait.