Licensing of vendored files in source code

[DimitriPapadopoulos]

Shouldn't the following line also refer to the licences of vendored files?

pip/pyproject.toml

Line 6 in d311405

license = "MIT"

Perhaps the respective licence files should be listed individually, with a comment with an SPDX identifier to summarize the contents of the file:

pip/pyproject.toml

Lines 7 to 12 in d311405

	license-files = [
	"AUTHORS.txt",
	"LICENSE.txt",
	"src/pip/_vendor/**/*COPYING*",
	"src/pip/_vendor/**/*LICENSE*",
	]

See also pypa/setuptools#5049.

[notatallshaw]

Whether to include the vendored licenses in the license field was discussed in the PR that added it: #13335

Which led to an extensive discussion on DPO about the intent and wording of the PEP: https://discuss.python.org/t/expressing-project-vs-distribution-licenses-post-pep-639/90314. That discussion become too onerous for me to follow, but I believe the conclusion was the license is for the project and there may be future PEPs to cover the distribution licenses? But I could be wrong about that.

[DimitriPapadopoulos]

I see. Additionally, pypa/flit#788 (comment) provides interesting information probably taken from the DPO discussion:

There have been some discussions regarding that topic on discuss.python.org. IMNAL so take my opinion for what it is but I believe that as long as the vendoring is done correctly, the resulting license doesn't necessarily change. I.e. just including MIT license code doesn't mean the project itself needs to be licensed with AND MIT.

That's somewhat different with copy-left licenses but that's not the point here.

Perhaps it's best to close this issue for now. I guess these licensing issues will clarify with time, especially if a new PEP is under way.

[pfmoore]

That discussion become too onerous for me to follow, but I believe the conclusion was the license is for the project and there may be future PEPs to cover the distribution licenses?

That's the impression I got, along with a clear feeling that no-one had really thought about this issue when the PEP adding the new license metadata was discussed and approved...

As far as I can tell, the discussion there has died down with no real conclusion, so for now I think pip will have to remain as we are, which is not ideal but I'd rather wait for a proper answer. We have the licenses present in the source, so we're doing what's needed to acknowledge them properly, it's just fitting that into the packaging framework that we'll have to do once the right way to do so is decided.

Additionally, pypa/flit#788 (comment) provides interesting information

My impression is slightly different - with vendoring there are two subtly different licenses involved. The license the actual project code is developed and released under, which is the license contributors must work under, and the combined license¹ under which the distributed "product" (the application in the case of pip, or the distributed library wheel for other projects) is made available. The packaging metadata only has one set of license fields, so it can't yet express that distinction.

Footnotes

1. The "combined" license is only different when code is vendored into the shipped product. Libraries generally don't vendor their dependencies, and unfortunately the packaging ecosystem tends to ignore applications, which is why this slipped under the radar. ↩