search

pombredanne / spdx-pypi-pep

Python Enhancement Proposals
https://www.python.org/dev/peps/
1 stars 1 forks source link

Should we freeze the SPDX license list version used in the metadata (e.g. the list of license identifiers)? #6

Open pombredanne opened 5 years ago

pombredanne commented 5 years ago

Originally from https://github.com/pombredanne/spdx-pypi-pep/pull/2#discussion_r330419938

Moved here as a ticket based on @pradyunsg suggestion to support a more focused discussion:

@Conan-Kudo thanks for your answer details... I was afk for a while and I am back.

You wrote in https://github.com/pombredanne/spdx-pypi-pep/pull/2#discussion_r321973682:

I want updating to new SPDX identifier versions to require PEP updates.

That's reasonable (this is more or less what we ended up doing for the Linux kernel: we store the list of valid identifiers in the kernel doc)... but at the same time, this means an update to a foundational document (the metadata doc/PEP) which is fairly significant and not to be done lightly.

To me the key thing would be how often would this possibly happen in the future? The rate at which new FOSS and related licenses evolve is slow enough. Here are some anecdotes:

  1. SPDX adds about 20 new licenses per year
  2. In ScanCode this is more like 1 or 2 per week.

That said, the new added licenses are mostly either old, seldom used licenses that were not yet "discovered" and new licenses that are not much used as of now. So in 99% of the cases the new licenses could be qualified as exotic.

Therefore, I think we could freeze a version of the SPDX license list in the PEP alright and the need for an update should be rather rare (maybe once in three years or so).

@Steap @ncoghlan @pfmoore @cjerdonek what would you think about this? This would mean being strict in this section: https://github.com/pombredanne/spdx-pypi-pep/pull/2/files#diff-7a25ca1769914c1141cb5c63dc781f32R223 and specify that we use a defined version of the list and that adopting future version would require an update to the metadata doc and version.

graingert commented 5 years ago

Is this different to https://github.com/pombredanne/spdx-pypi-pep/issues/7 ?

graingert commented 5 years ago

the title should be should we freeze the SPDX license list version used in the metadata (e.g. the list of license identifiers)?

pombredanne commented 5 years ago

@graingert fixed! thank you ++ ... someone is paying attention at least!

ncoghlan commented 5 years ago

If we were strict, what would we expect publishing tools or PyPI to do if a package used a license from a later version of SPDX?

I think we should definitely be strict about the obsolescence warnings: if it isn't deprecated in the SPDX 3.6 list, don't warn about it. That way, if a license is acceptable on first publication of a project, it will stay acceptable for that metadata version.

I don't see the value in emitting a warning if a project uses a license expression that doesn't appear in the SPDX 3.6 list, but does appear in a later version. Folks aren't going to change their chosen license just because their build tool doesn't recognise it, so the warning would just be useless noise, and metadata consumers would need to deal with the more recent license expressions anyway.

pombredanne commented 5 years ago

@ncoghlan this all makes sense and I agree with your take.

Here are possible cases and their outcomes in terms of soft validation, assuming a tool knows only about version 3.6 of the licenses

  1. license is in 3.6: all OK
  2. license is obsoleted in 3.6: report a warning that license is obsolete
  3. license is not in 3.6 (either this is in a new version or this is a typo): report a warning that license is unknown (and could suggest closely related ids)

Now later on, the tool supports 3.8:

  1. license is in 3.8: all OK
  2. license is obsoleted in 3.6: report a warning that license is obsolete
  3. license is valid in 3.6 and obsolete in 3.8: either all OK or information message that the license was marked obsolete since 3.6
  4. license is not in 3.8: (either this is in a newer version or this is a typo): report a warning that license is unknown

So in all cases since we issue a warning anyway, it does not make sense to be strict wrt. the exact list version that is used.

@ncoghlan you also wrote:

I don't see the value in emitting a warning if a project uses a license expression that doesn't appear in the SPDX 3.6 list, but does appear in a later version.

We still need to issue some message of sorts because there is no way to distinguish between a typo in a license id and a valid id in a version of license list that is not yet supported by the tool ... unless the tools would fetch and cache the latest versions of the license list... which is technically not hard but a bit too much to require from the tools?

ncoghlan commented 5 years ago

@pombredanne We're in agreement, as my "I don't see the value ..." comment was referring to the cases like your example where the tool is already aware of license list version 3.8, and the project uses a license that's present in license list 3.8.

It's OK if a tool that is only aware of license list version 3.6 emits a warning in such cases, but one that is aware of newer list versions should just accept the newer license ID as valid.