The project does not have a license

[dvzrv]

Hi! 👋

over in jaraco/jaraco.itertools#23 I raised the issue of the removal of the required license file and pointed out that this project downloads it during build time.

I briefly looked into packaging this project for Arch Linux, but realized that it does not provide license information at all (which does not allow us to package it)!

Further, looking at jaraco/skeleton#171 and jaraco/skeleton#174 I am now of the opinion, that this project offers a solution in search of a problem.
It is incompatible with downstream requirements (ie. "provide a license file" and "do not download files during build").

[mtelka]

@dvzrv, what about this?

$ wget https://files.pythonhosted.org/packages/source/c/coherent_licensed/coherent_licensed-0.4.0.tar.gz
$ gtar xf coherent_licensed-0.4.0.tar.gz
$ cd coherent_licensed-0.4.0
$ grep License PKG-INFO 
Summary: License management tooling for Coherent System and skeleton projects
License-Expression: MIT
$ head -n3 LICENSE 
MIT License

Copyright (c) 2025 <copyright holders>
$

[dvzrv]

$ wget https://files.pythonhosted.org/packages/source/c/coherent_licensed/coherent_licensed-0.4.0.tar.gz
$ gtar xf coherent_licensed-0.4.0.tar.gz
$ cd coherent_licensed-0.4.0
$ grep License PKG-INFO 
Summary: License management tooling for Coherent System and skeleton projects
License-Expression: MIT
$ head -n3 LICENSE 
MIT License

I'm not sure I understand what you mean by that? 🤔
The sources of this repository state no license information anywhere!
(noone can legally contribute to it or reuse it)

We are not helped with a PyPI sdist tarball either, as we do not use those for packaging anymore (see https://rfc.archlinux.page/0020-sources-for-python-packaging/) as they are intransparent (see https://rfc.archlinux.page/0046-upstream-package-sources/) and often broken (for tests, patching, etc.).
We often package directly from git sources, or from auto-generated source tarballs (as they directly relate to the commit they originate from).

Having a simple license file in a repository does not seem like a complicated thing to me (the proposed system in this repository on the other hand is). 🤔

Copyright (c) 2025 <copyright holders>
$

Hm, and who is the copyright holder now (see https://spdx.org/licenses/MIT.html)?

[jaraco]

I need to make it explicitly documented in the Coherent System. Similar to skeleton, projects are by default licensed under MIT. I have aspirations to provide a mechanism to allow for other licenses.

The main thing I'm trying to avoid is to add to the burden of ancillary details that need to be copy-pasted across hundreds of repositories.

Hm, and who is the copyright holder now (see https://spdx.org/licenses/MIT.html)?

Skeleton (and the hundreds of projects derived from it) have not had a "copyright holder" since April 2023, but even before then, there was no copyright year and I believe the copyright was incorrect anyway. It states that the code is copyright by me, even though conventional wisdom says the copyright is held by the contributors, the detail which is much more reliably represented in the source code history than in a line of copyright declaration.

Moreover, the license itself is broken on other levels:

• The license text speaks of a copyright notice that's not applicable and possibly not even present.
• The license text demands that the text be included in all substantial portions of the software. That sounds like a holdover from when licenses were copy/pasted into every file, which I think we've all agreed by now is tedious and overkill and wasteful.

Therefore, it's my opinion that providing a traceable, unambiguous statement of the intended license for the whole of the project should be an acceptable way to license the code of the project.

Having a simple license file in a repository does not seem like a complicated thing to me (the proposed system in this repository on the other hand is). 🤔

Thanks for asking. You're right. If all you're concerned about is a single repository managed by a developer or team of developers, it's not a big deal. Neither is managing any one of the ancillary concerns of a project. However, the aggregate burden of each ancillary concern multiplied by potentially hundreds of projects becomes a major burden (accounting for ~50% of the maintenance burden for my projects). The introduction of each file that's not project-specific adds to that burden.

Moreover, including a license file, which is metadata about the project, in the root of the project folder, violates the goals of the essential layout.

The Coherent System is aiming to move cross-project concerns into system-level tooling and documentation.

We are not helped with a PyPI sdist tarball either,

I acknowledge this concern is a limitation of the Coherent System. I believe this concern can be dealt with by providing clear system-level guidance as to what the license is. Also, you'll see that a license expression and license text are provided in the resultant package metadata even when built from a GitHub checkout. Builds from GitHub source tarballs may never be supported as the system relies very heavily on having git metadata for inferring package metadata. There may be an opportunity for downstream integrators to supply this metadata another way, but I'm not going to promise anything at this stage. I'm happy to explore the problems with representative integrators toward weighing tradeoffs and identifying solutions.

[lahwaacz]

The MIT license says:

The above copyright notice and this permission notice (including the next paragraph) shall be included in all copies or substantial portions of the Software.

The source code repository is the most substantial copy of any FOSS project and so it must contain the license file explicitly.

Therefore your mechanism is not legal even for your default MIT license, I don't see how you can aspire to make it a universal and accepted approach for FOSS developers.

[dvzrv]

I need to make it explicitly documented in the Coherent System. Similar to skeleton, projects are by default licensed under MIT.

This is highly problematic and I don't think we can continue to package your projects that way.

However, the aggregate burden of each ancillary concern multiplied by potentially hundreds of projects becomes a major burden (accounting for ~50% of the maintenance burden for my projects). The introduction of each file that's not project-specific adds to that burden.

How is adding a file to the repository when creating it (and then never touching it again) a maintenance burden though?
Sorry, but I'm not buying it.
This entire approach rather seems to follow some personal sense of purity wrt how many files are in the repository - and that is not how licensing works!

I acknowledge this concern is a limitation of the Coherent System. I believe this concern can be dealt with by providing clear system-level guidance as to what the license is.

No. The "concern" can be dealt with by just having a single file in your source code repository and not building a complex system around everything that downloads the internet during build time!
(FWIW: We are often building from git sources. I don't think your claims that other sources than PyPI are not supported is correct at all).

Frankly, I am shocked to see that you are doubling down on this idea, even after having been contacted by the PSF to reinstate the license file for setuptools (see pypa/setuptools#5001) and having been asked by multiple downstream maintainers in several tickets of the projects you maintain to stop this!

To put things very clearly, as a downstream we are interested in:

• redistribution (impossible with your setup as the license is undefined in the sources we use)
• contribution (impossible with your setup, as the license is undefined in the sources)
• the transparency and integrity of the sources we build from (not guaranteed with PyPI sdist tarballs - see https://rfc.archlinux.page/0020-sources-for-python-packaging/ and https://rfc.archlinux.page/0046-upstream-package-sources/)
• ease of patching (not guaranteed with your setup, or PyPI sdist tarballs)
• building offline (impossible with your setup and the sources we use)

As is, I am currently stopping to upgrade packages that use this system until further notice.
I am legally not allowed to redistribute things this way and I am also not up for patching every single project of yours.