PEP 639, Round 3: Improving license clarity with better package metadata

[daniele (Daniele Nicolodi)]

@barry

I have been prototyping some more REST-ish APIs for PyPI and it’s something I’m quite keen on helping make happen.

The API to access the data is not the problem. The problem is that PyPI does not currently record the information: there is no per distribution artifact metadata collected. In the case of licensing information, making sense of metadata prior to version 2.4 is a lost cause, unless you want to try to interpret free text licensing information is a gazillion of different formats with fall back to ambiguously defined classifiers. Metadat 2.4 makes it much easier but still not trivial: the License-Expression metadata field is not mandatory. Licensing information can be expressed linking to license text via License-File fields, or not present at all.

[daniele (Daniele Nicolodi)]

@steve.dower

Based on the responses, I believe mine came across more lightly than yours. Though I may have the advantage of knowing Hynek personally.

Except the one reply from Hynek, which hasn’t reacted to your suggesting that his suffering should be endured for the collective good, the only replies are mine and yours, so I don’t know on what you are basing your conclusion.

@steve.dower

@hynek

@daniele

If it makes you feel better, the time you spent is most likely a few order of magnitude less than what the people involved invested to create the infrastructure to get those three letters there

Despite everyone always giving the best, suffering in FOSS is not a competition.

This is well off-topic now, though. Please direct message me if you want to continue.

I was not the one to link time spent to suffering. I don’t consider the time I spend working on open source projects as suffering. I was indeed very surprised when Hynek jumped from time spent to suffering and that motivated my next message on the topic where I lightly suggested that if time spent working on FOSS contributions is perceived as suffering, maybe it is time to revisit something.

I think that the accepted view that maintainers of open source projects have any responsibility toward the users of their code, to the extent that maintaining the project is more important than their well being is something that need to change. Comments like yours, even if intended only as jokes, only reinforce this view.

@steve.dower

This is well off-topic now, though. Please direct message me if you want to continue.

You are accusing me of mean or inconsiderate behavior on a public forum. I prefer to defend my behavior on the same forum.

[fungi]

The API to access the data is not the problem. The problem is that PyPI does not currently record the information: there is no per distribution artifact metadata collected. In the case of licensing information, making sense of metadata prior to version 2.4 is a lost cause, unless you want to try to interpret free text licensing information is a gazillion of different formats with fall back to ambiguously defined classifiers. Metadat 2.4 makes it much easier but still not trivial: the License-Expression metadata field is not mandatory. Licensing information can be expressed linking to license text via License-File fields, or not present at all.

As has been pointed out repeatedly in prior discussions, license information reported for packages on PyPI is at best a strong hint as to the copyright license(s) covering downloads for that project. Anyone concerned about the actual licenses for all of the files contained within the downloads in each project’s release need to consult files shipped in those projects, or their upstream developers’ documentation. Recent metadata changes improve this, but do not address all possible complexities of applying copyright licenses in projects.

[steve.dower]

@daniele

You are accusing me of mean or inconsiderate behavior on a public forum. I prefer to defend my behavior on the same forum.

I intended no such accusation, and I apologise that it was perceived that way. For anyone else reading this, I’ll clearly state that I don’t believe Daniele was being mean or inconsiderate.

@daniele

I was not the one to link time spent to suffering. I don’t consider the time I spend working on open source projects as suffering. I was indeed very surprised when Hynek jumped from time spent to suffering

That’s fair. They aren’t directly the same thing, though I do understand how they logically link together (primarily because the time spent in this case is time that didn’t need to be spent except that we forced it to be, and that is what maintainers often refer to as “suffering”).

@daniele

I think that the accepted view that maintainers of open source projects have any responsibility toward the users of their code, to the extent that maintaining the project is more important than their well being is something that need to change. Comments like yours, even if intended only as jokes, only reinforce this view.

Again, I apologise that my comments were seen that way. I certainly don’t endorse suffering in any real sense. Though it’s important to understand that the term is commonly used in OSS maintainer circles to refer broadly to unnecessary demands being placed upon maintainers, and in that sense most maintainers do feel a responsibility to “suffer” for their projects and their users. We hope the other parts of the experience are rewarding enough to make up for it, and they often are, but we also help by not minimizing the additional work we cause when our own contributions don’t go smoothly.^[1]

---

1. And for complete clarity, this is not directed at Daniele specifically, but all of us on this forum. ↩︎

[ambv (Łukasz Langa)]

@daniele @steve.dower you’re derailing the discussion here. This is not a topic I can sensibly split, because there is no category that would fit your back and forth here. So let’s leave it at that, otherwise I’ll have to hide the off-topic messages that users keep flagging.

[ofek (Ofek Lev)]

@daniele

If you ask me, it was irresponsible for the Hatchling maintainers to start unconditionally emitting metadata version 2.4 while packaging tools are still catching up.

Nope, I was quite responsible in fact and waited to release the new version of Hatchling until others confirmed that they would not be broken: Hatchling v1.27.0 changelog dead link + no tag · Issue #1842 · pypa/hatch · GitHub

[webknjaz (🇺🇦 Sviatoslav Sydorenko (read: /sʋʲɑtɔˈslɑw/))]

@cdce8p

There is an open PR to add support for metadata version 2.4 to twine. From the looks of it, it should be merged soon. Switch to packaging for parsing metadata and support metadata 2.4 by dnicolodi · Pull Request #1180 · pypa/twine · GitHub

FTR, I was just checking the state of it and realized that it’s been merged 3 weeks ago: Switch to packaging for parsing metadata and support metadata 2.4 by dnicolodi · Pull Request #1180 · pypa/twine · GitHub. So it seems like the last bit everybody’s waiting for is a new Twine release, unless I’m missing something.