The project tries to download arbitrary license files over the internet during build https://github.com/coherent-oss/coherent.licensed/blob/fe0a6e10e7e1bd0dbb7cb83055140cf7ff7d83ee/__init__.py#L18-L20 which most distributions don't allow in non networked builds.

With the latest release of coherent.licensed (0.4), it no longer has any behavior if the LICENSE file already exists, which it does. Moreover, for projects that don't declare a build-time dependency on coherent.licensed in their pyproject.toml, the behavior is disabled. This means that for Setuptools as currently implemented with the static LICENSE file, and for other projects not in the skeleton system, the behavior should be a no-op.

Along with that the build backend used by coherent.licensed https://github.com/coherent-oss/coherent.licensed/blob/fe0a6e10e7e1bd0dbb7cb83055140cf7ff7d83ee/pyproject.toml#L2-L3, coherent.build is partly not possible to build at least from the git repo as it has a cyclic dependency on itself. This in turn makes setuptools hard to build.

coherent-oss/coherent.build#48

Addressed in that issue.

I don't see why setuptools needs to have this dependency, as afaiu everything was fine with license files kept in repo. Maybe it solves some problems but the coherent.license dependency and its dependencies are not very packagable.

Strictly speaking, it doesn't currently require it. However, I'd like to keep Setuptools aligned with other skeleton projects as much as possible. Moreover, I'd like to reintroduce the reliance on coherent.licensed in Setuptools after I've worked through administrative concerns about the presence of the license.

coherent.license has no dependencies (just build dependencies). I'd like for coherent.license to have dependencies, but I'm avoiding adding them until all dependencies avoid the build from source bootstrapping problem with setuptools (i.e. all dependencies build on flit-core or another primitive backend).

If we remove the coherent.license dependency now, it will alleviate these problems for now, but it will leave them as a lingering risk if Setuptools ever adopts other build dependencies or dependencies in general (as it needs its own dependencies to build itself). Moreover, there are many other projects in the ecosystem that still have coherent.licensed declared as a build dependency, which will be subject to this same problem, so removing it from Setuptools does not help with those projects, so we're just kicking the can down the road.

I'm open to removing this dependency in the short term in order to provide downstream integrators time to devise a strategy to accommodate this workflow, but I don't want to simply give up on this sole solution to the bootstrapping problem. If compile-to-sdist can't be the recommended solution to the bootstrapping problem, I'm afraid we may need to ask the integrators to invest more in selecting another broad solution. The answer can't be "build backends cannot in general have dependencies", which is essentially the state today.

Moreover, for projects that don't declare a build-time dependency on coherent.licensed in their pyproject.toml, the behavior is disabled.

So projects that do declare a build dependency on coherent.licensed will try to download licenses from the internet during build? Because one of the dependencies of coherent.build https://github.com/python/importlib_resources does not have a license in the repo and has declared to be dependent on coherent.licensed.

If this is the case then the problem does not go away.

This is not just one module, it's the same thing with https://github.com/jaraco/jaraco.compat, https://github.com/jaraco/jaraco.functools all of which are listed as dependencies of coherent.build.

does not have a license in the repo

Well it had until you deleted it ... python/importlib_resources@9a81db3 which is a violation of MIT (but that's not the topic here)

I think you're starting to notice that all of these projects are derived from jaraco/skeleton. These common issues should be addressed there.

I can't transfer this issue to that project, so I'm going to close it. Feel free to re-open an issue with the skeleton.

I don't want to open another issue, for now since you merged the PR removing it, my immediate concern re setuptools is resolved.

I didn't understand what problem it's trying to solve but I'd suggest rather than trying to download the license from internet, make it dependent on spdx-license-data which some distros package.

Ship some stripped down vendored copy of it with your sdist/wheels on pypi and have some build time option/way to use a system copy of spdx-license-data. Then use the license files from there (either system or vendored copy of the file) and if missing fallback to try downloading at build time.

This still doesn't resolve, the concerns (legal or otherwise) about removing the license files from repo but that's not upto me.

I don't want to open another issue

Also I noticed coherent-oss/system#22 which was transferred from coherent.license repo and shares the same concerns/problems, so another issue is likely not needed.