Weekly Hugging Face model license and access audit

Every Monday at 9am, audit the Hugging Face models my team depends on and flag any that have become more legally restrictive since we approved them.

The watchlist lives in a Google Sheets tab. Read it with Get Values. Each row is one approved model and has these columns: the model repo id (for example acme-labs/summarizer-7b), the license we recorded when we approved that model, the product or team that depends on it, the access status we last recorded (open, gated, or unavailable), and the timestamp of the last check. Skip the header row. Treat this sheet as the system of record for what we approved, because Hugging Face has no concept of our internal approval state.

For each row, call Get Model on Hugging Face with the repo id and read the current license, the gated status, and the tags. If the call comes back as not found or forbidden, treat the model as private, deleted, or otherwise no longer accessible to us rather than as an error to abort on.

Compare what you find against the recorded values and decide whether restrictions have increased. Restrictions have increased when a permissive license (Apache 2.0, MIT, BSD, and similar) has shifted to a custom, research only, non commercial, or unspecified license; when a model that was open has become gated; or when the repo has become private or been deleted. Use judgement on the license strings, since many are custom names rather than standard identifiers, and a rename or a change of casing for the same underlying license is not a real change. Gated status matters as much as the license string, because a model going gated silently breaks automated pulls.

Only raise an issue when restrictions increase. Never raise one when a model becomes more permissive, for example moving from a research only license to Apache 2.0. In that case just update the sheet and move on.

For each model where restrictions increased, create a Linear issue with Create Issue on the team that handles legal review. The title should name the model and the nature of the change. The description should state the model repo id, the old recorded license and the new current license, exactly what changed (license, gating, or availability), the product or team at risk, and a link to the repo at https://huggingface.co/ followed by the repo id. Set the issue priority to High (priority value 2 in Linear) so legal picks it up in the current week.

After handling each row, use Update Values to write the current license, the current access status, and today's date as the last checked timestamp back into that row. This write back is also how we avoid duplicate reports: next week's run compares against the updated recorded values, so a change that has already been filed will match and will not produce a second issue. Never file a second issue for a change that is already recorded in the sheet.

If nothing has changed, do not create any issues, but still refresh the last checked timestamps so we can prove the audit ran.