potiuk commented on PR #58138: URL: https://github.com/apache/airflow/pull/58138#issuecomment-3511357545
Unfortunately - the https://www.apache.org/legal/src-headers.html#faq-binaries is very clear that the licence should be in the produced binaries. I think it's a serious legal requirement, and pyspark is not doing it **right** . And yes for me this is always kinda "stupid" that in all Android apps (.apk files) not only you have licences for all the libraries included extracted from those binaries but also there is this completely unparseable "Licences" in "About" - that you should be able to see as a user. This is legal stuff and a little of the "red-tape" we have here. small comment - as ASF security committee - we have 5-10 reports a day called "licence confusion" when someone complains that Apache had taken over their phone and doing nasty things - as a proof showing screenshots from that licence screen in their apps. 😱 > This also means I'd prefer it not symlinked either. Yeah that was my second thought. The problem is that IF we want it dynamically added, then as far as I can tell - we cannot use a PEP-standard backend any more - without anything that wraps around and creating this file. And this is the simplest build backend. And we **cannot** use anything outside of the "source" tree of the project. I tried various things and I could not make it work otherwise -according to the PEP standards for pyproject.toml 1. Tried parent inclusion ``` license-files = ['../../LICENSE', '../../NOTICE'] ``` This is the error that flit reports. ``` Config error: Invalid glob pattern for [project.license-files]: '../../LICENSE'. Pattern must not contain '..' ``` This is in-line with the expectation of pyproject.toml "glob patterns" specification: https://packaging.python.org/en/latest/specifications/glob-patterns/ > Parent directory indicators (..) MUST NOT be used. 2. Tried to remove the files and see what happens when they are dynamically generated: ``` Config error: No files found for [project.license-files]: 'LICENSE' pattern ``` This is in-line with the same glob-patterns definition: > MUST raise an error if any individual user-specified pattern does not match at least one file. 3. We could probably try to have build backend to generate those files dynamically - but this complicates A LOT the build process for providers and it basically means that either we have to use some 3rd-party hatchling plugins (and switch to those). And I think this is far too "complex" to make it really part of our build. If we don't have this plugin, our users will stop having the possibility of building our providers by just `python -m build .` - or for example will not be able to install providers via Git URL - probably some other things will be more "complex" as well. I honestly have no other ideas how to do it to be compliant with the standards. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
