add huggingface id to .LICENSE yaml frontmatter

[armijnhemel]

Short Description

Huggingface uses different descriptions than in SPDX or other places. Adding a huggingface id to the .LICENSE yaml frontmatter might make referencing things easier.

Possible Labels

• new feature

Select Category

• Enhancement
• Add License/Copyright
• Scan Feature
• Packaging
• Documentation
• Expand Support
• Other

Describe the Update

Inspired by #4900 : huggingface calls this "apple-sample-code-license" (as seen when browsing the HuggingFace website for the project linked in #4900 ). This isn't the same name as used in SPDX or the ScanCode licensedb.

Just as there already is spdx_license_key it might make sense to add something like huggingface_license_key.

How This Feature will help you/your organization

I think that the onslaught of licenses coming from huggingface in the near future will make this a useful feature.

Possible Solution/Implementation Details

A good first start would be to add data from this list:

https://huggingface.co/docs/hub/repositories-licenses

Example/Links if Any

Can you help with this Feature

[mjherzog]

The SPDX license id has special standing because of its widespread adoption as a standard. Adding specific keys for other ecosystems that use non-standard license naming is potentially a slippery slope to special license key proliferation. For other cases we have historically used keywords in the DejaCode license record so a better solution might be to continue using the keyword/alias approach and publish that data to ScanCode LicenseDB.
The longer term solution is to help huggingface to use standard license keys in general.

[armijnhemel]

Some other keyword would also help for sure.

[mjherzog]

@DennisClark @AyanSinhaMahapatra I am interested in your feedback on this idea.

[DennisClark]

we should encourage huggingface to use standard license keys

[armijnhemel]

we should encourage huggingface to use standard license keys

So what if this isn't going to happen? @pombredanne

[mjherzog]

We encourage them to use ScanCode LicenseDB - because we are much more responsive than SPDX to add new licenses.
We cannot start adding data fields for every org that has poor license naming practices.

[pombredanne]

@armijnhemel Until now for anything beyond SPDX and the OSI, we have erred towards having either rules for alternate ids or using one of key_aliases rather than tracking each new if in a new field. For instance with Fedora license ids, we do not have a new field for that.

See

scancode-toolkit/src/licensedcode/models.py

Line 283 in 6570c13

key_aliases = attr.ib(

But that feature is not used anywhere in the data and not used in code either, only an attribute and nothing more.

We could nicely use that and also add a rule for "Apple-Sample-Code-License"

We could also starting using key aliases for detection, but that would require we ensure these are globally unique in the database across all keys.

[armijnhemel]

@armijnhemel Until now for anything beyond SPDX and the OSI, we have erred towards having either rules for alternate ids or using one of key_aliases rather than tracking each new if in a new field. For instance with Fedora license ids, we do not have a new field for that.

See

scancode-toolkit/src/licensedcode/models.py

Line 283 in 6570c13
key_aliases = attr.ib(

But that feature is not used anywhere in the data and not used in code either, only an attribute and nothing more.

We could nicely use that and also add a rule for "Apple-Sample-Code-License"

We could also starting using key aliases for detection, but that would require we ensure these are globally unique in the database across all keys.

All I want is a field that basically indicates "hey, this is what HuggingFace calls it". Nothing more, nothing less. It should be quite easy to do (we are talking about 40 or so, see https://huggingface.co/docs/hub/repositories-licenses ). These values are used in queries on the HuggingFace website (and perhaps also in other places?) so it would, in my opinion, be useful to record it.

[mjherzog]

We should/can not add a field for each repo or org that uses an idiosyncratic license list!

[pombredanne]

We should/can not add a field for each repo or org that uses an idiosyncratic license list!

@mjherzog actually may be we could, this would be a small data structure change and we could generalize that for OSI and others, for instance, something like this:

key: aml
short_name: Apple MIT License
name: Apple Sample Code License 2006
category: Permissive
owner: Apple
homepage_url: https://fedoraproject.org/wiki/Licensing/Apple_MIT_License
spdx_license_key: AML
other_urls:
    - https://huggingface.co/apple/OpenELM/blob/main/LICENSE
other_keys:
  - source_url: https://huggingface.co/docs/hub/repositories-licenses
    key: foo
  - source_url: https://opensource.org/license/cvw
    key: cvw

Let me reach out to HF too

[armijnhemel]

I apologize if I wasn't clear, but I don't want any changes to the code, just to the YAML frontmatter, so it becomes easier for cross referencing with other data sources.

I could imagine something like (building on what @pombredanne said):

- origin: huggingface
  key: some-stupid-license-name

We are talking about 80 license names (just verified) which would be about 3% of the current license texts in scancode. Adding this data would make cross referencing with other sources much easier as I would be able to do it programmatically, instead of first having to do a manual lookup and recording the data anyway to be used by a script.

And yes, HuggingFace should be using standardized licenses, but they aren't and I don't see this happening soon as their notation is used in different parts of the HuggingFace infrastructure code and people are relying on it.

Also see #4914 where HuggingFace is using a different name than the license text.

[mjherzog]

@armijnhemel Please clarify what you mean by "YAML frontmatter". If you are referring to the metadata shown in the yml file for a license on ScanCode LicenseDB that is data from fields in the license record in DejaCode.

[armijnhemel]

@armijnhemel Please clarify what you mean by "YAML frontmatter". If you are referring to the metadata shown in the yml file for a license on ScanCode LicenseDB that is data from fields in the license record in DejaCode.

Ah, I now understand where the miscommunication is happening. If I understand correctly the data in src/licensedcode/data/ is an export of the data that is stored in a DejaCode instance run by AboutCode, and which can only be accessed by AboutCode. I was not aware of that, I only saw the rules in src/licensedcode/data/ (which have the YAML frontmatter) and thought that (or at least a local copy maintained by AboutCode that is synced every now and then) was the canonical source of truth. Apparently it is not.

As it seems, adding a field to the YAML frontmatter in rules in src/licensedcode/data/ would possibly require a change in the source code of DejaCode and probably a rebuild and reinstall of DejaCode? If that is indeed the case, then I think you have the workflow the wrong way around for an open source project because how are people then going to contribute to the licenses more proactively?

[ahsan-h-shihab]

Reading the discussion above: there are objections to adding an HF-specific
field, and there is a sketch of a generic key_aliases / other_keys: [{source_url, key}] structure that could carry other ecosystems'
identifiers without a per-ecosystem field. I am not arguing for either
option. In case it is useful for evaluating that generic mechanism (how many
entries it would carry, and what shape they have), here is a checked mapping
for the model-specific identifiers in Hugging Face's license vocabulary
(https://huggingface.co/docs/hub/repositories-licenses). The Hub's
software-license ids are already SPDX ids in lowercase (apache-2.0, mit,
cc-by-4.0, …), so the non-trivial part is these 22. Checked against
LicenseDB per-key records on 2026-08-17.

HF license id	HF label	LicenseDB key today	Note	HF repos
llama2	Llama 2 Community License Agreement	llama-2-license-2023		10,673
llama3	Llama 3 Community License Agreement	— (none)	plain Llama 3 (2024-04-18) has no key; 3.1/3.2/3.3 do — see #5269	10,452
llama3.1	Llama 3.1 Community License Agreement	llama-3.1-license-2024		9,331
llama3.2	Llama 3.2 Community License Agreement	llama-3.2-license-2024		8,256
llama3.3	Llama 3.3 Community License Agreement	llama-3.3-license-2024		2,659
llama4	Llama 4 Community License Agreement	llama-4-cla-2025	note llama-4-license-2025 is the Llama 4 Acceptable Use Policy — naming is inverted relative to the 3.x keys	655
gemma	Gemma Terms of Use	gemma-tou-2024-04-01 and gemma-tou-2025-03-24	HF id is version-less; one-to-many (both records point at the same homepage)	15,239
grok2-community	Grok 2 Community License Agreement	xai-cla-2025	that record's other_urls already points at HF's license:grok2-community facet	123
openrail	OpenRAIL license family	— (family)	HF documents it as a family; LicenseDB has bigscience-open-rail-m, bigscience-open-rail-m2, bigscience-rail-1.0, bigcode-open-rail-m-v1; one-to-many	41,435
bigscience-openrail-m	BigScience OpenRAIL-M	bigscience-open-rail-m		2,809
creativeml-openrail-m	CreativeML OpenRAIL-M	stable-diffusion-2022-08-22	record name is "CreativeML Open RAIL-M 2022-08-22" (cf. #4599 on the key name)	32,873
openrail++	Open Rail++-M License	bigscience-open-rail-m2 ⚑	that record's homepage is Stability-AI/stablediffusion LICENSE-MODEL (CreativeML Open RAIL++-M); the SDXL text (2023-07-26) was not diffed against it	17,381
bigscience-bloom-rail-1.0	BigScience BLOOM RAIL 1.0	bigscience-rail-1.0		2,979
bigcode-openrail-m	BigCode Open RAIL-M v1	bigcode-open-rail-m-v1		2,522
openmdw-1.0	Open Model, Data & Weights License Agreement	openmdw-1.0 (SPDX OpenMDW-1.0)		80
openmdw-1.1	Open Model, Data & Weights License Agreement v1.1	— (none)	already requested in #5158	226
intel-research	Intel Research Use License Agreement	intel-research-use-2024		61
apple-ascl	Apple Sample Code license	apple-sscl		138
apple-amlr	Apple Model License for Research	— (none) ⚑	no matching key found (apple-ml-ferret-2023 is a different, model-specific license); not yet requested as far as I can see	280
deepfloyd-if-license	DeepFloyd IF Research License Agreement	— (none)	not yet requested as far as I can see	128
fair-noncommercial-research-license	FAIR Noncommercial Research License	— (none) ⚑	chameleon-research-2024 is a different Meta research license	171
h-research	H Research License	— (none) ⚑	not yet requested as far as I can see	59

Two observations from the same pass, in case they matter for the field design:

• Two HF ids (openrail, gemma) are one-to-many by construction (family /
  version-less), so any alias / other-key mechanism would need to allow the
  same HF id on several LicenseDB records (or a list) rather than assuming
  one id ↔ one record.
• Beyond the enum, the Hub's license: other repos (113,548 on 2026-08-17)
  carry free-text license_name values; the most common ones I sampled
  (lfm1.0 → lfm-open-1.0, deepseek → deepseek-la-1.0,
  tongyi-qianwen → tongyi-qianwen-2023, faipl-1.0-sd →
  fair-ai-public-1.0-sd, …) also resolve to existing keys, but those strings
  are not part of HF's vocabulary, so I have left them out of this table.

Happy to re-check any row or add the ones I skipped if this goes anywhere.