TimesFM 3.0 di Google: la scheda cambia licenza, i pesi restano gli stessi

Il 24 agosto 2026, alle 22:41:42 UTC, Google carica su Hugging Face i pesi di TimesFM 3.0, il suo modello a pesi aperti per la previsione di serie temporali: 330,7 milioni di parametri, un solo file di circa 1,23 GB. Nel file README che accompagna quel caricamento, il campo che dichiara la licenza dice una cosa sola: license: apache-2.0. Sessantanove ore e trentanove minuti dopo, senza che il nome del repository cambiasse di una lettera e senza che un solo byte dei pesi venisse ritoccato, quel campo dice un’altra cosa: licenza non commerciale, uso di produzione vietato. Chi ha scaricato il modello guardando solo il nome — google/timesfm-3.0-pytorch — e non la revisione precisa, può avere in locale un file identico a quello di oggi accompagnato da un permesso che oggi non esiste più.

I fatti, in ordine

24 agosto 2026, 22:05:51 UTC — commit d’inizializzazione del repository google/timesfm-3.0-pytorch su Hugging Face.
24 agosto 2026, 22:41:42 UTC — il commit Upload TimesFM 3.0 PyTorch model weights and config carica model.safetensors (1.322.898.824 byte, 330.710.976 parametri in F32) e config.json (20 strati transformer, dimensione 1280, 16 teste, patch di contesto 32, patch di orizzonte 64, fino a 32 variate simultanee). Il README dichiara license: apache-2.0. Nessun file LICENSE è ancora presente nell’albero del repository.
27 agosto 2026, 20:21–22:13 UTC — tre commit in due ore: aggiunto il primo file LICENSE (7.270 byte, mai presente prima), rimosso il campo license: apache-2.0 dal README, poi riscritto con license: other, license_name: timesfm-non-commercial-license-v1.0.
28 agosto 2026, 23:34:07 UTC — su GitHub, in google-research/timesfm, un commit aggiunge una nota che distingue esplicitamente la versione 3.0 dalle precedenti (vedi sotto).
28 agosto 2026, 23:42:49 UTC — Google pubblica su GitHub la release ufficiale taggata v3.0.0, di nome TimesFM-3.0: quattro giorni dopo il primo caricamento dei pesi, oltre venticinque ore dopo che il cambio di licenza era già completo.
28 agosto–2 settembre 2026 — altri sei commit toccano ancora il README su Hugging Face, incluso uno fuso come pull request numero 1, co-firmato dal contributore esterno ayujain25, che corregge anche l’anno della citazione bibliografica, da 2024 a 2023 — lo stesso utente ha aperto, lo stesso giorno, le pull request gemelle #470 e #471 sul repository GitHub. L’ultimo commit sul ramo main di Hugging Face, al momento della verifica, è del 2 settembre alle 15:44:59 UTC, intitolato Test removing timesfm tag to check library_name; lo stesso giorno, su GitHub, due commit correggono ancora l’allineamento delle finestre di covariate nel modulo timesfm3, dopo che il tag v3.0.0 era già pubblicato.
Al momento della verifica, 4 settembre 2026, l’API di Hugging Face segna 46.862 download e 357 like sul repository.

Quello che il nome del repository non racconta

Il file dei pesi non si è mai mosso: lo stesso hash — Git e LFS — compare nell’albero del repository dal 24 agosto a oggi, bit per bit identico. Il cambiamento è tutto nel documento che lo accompagna, ed è un cambiamento di diritti, non di contenuto. Apache 2.0 permette uso commerciale, distribuzione, derivati, senza condizioni oltre l’attribuzione. La licenza che l’ha sostituita, timesfm-non-commercial-license-v1.0, esclude ogni uso commerciale e ogni deployment in produzione, definendo la «Non-Commercial Purpose» — finalità non commerciale — come «use for testing, evaluation, or research not tied to commercial gain, production deployment, or revenue generation» — uso per test, valutazione o ricerca non legato a un profitto commerciale, a un utilizzo in produzione o alla generazione di ricavi. Una riga a parte fra le restrizioni, senza condizione di scopo, vieta anche di «Distribute the TimesFM Model or a Derivative» — distribuire il Modello TimesFM o un suo Derivato: non solo l’uso commerciale, la distribuzione stessa, punto.

Il commit su GitHub del 28 agosto spiega perché il salto riguarda solo questa versione: «model weights up to version 2.5 remain Apache-2.0. However, for the time being, TimesFM 3.0 pretrained weights are distributed under the separate timesfm-non-commercial-license-v1.0 license» — i pesi dei modelli fino alla versione 2.5 restano Apache-2.0. Per il momento, però, i pesi pre-addestrati di TimesFM 3.0 sono distribuiti secondo la licenza separata timesfm-non-commercial-license-v1.0. Verificato in modo indipendente: la scheda di google/timesfm-2.5-200m-pytorch, il modello precedente, dichiara ancora oggi license: apache-2.0. Chi veniva da quella versione aveva ogni ragione, per tre giorni, di pensare che nulla fosse cambiato: la scheda di TimesFM 3.0 glielo confermava.

L’annuncio ufficiale non aiuta chi arriva dopo. La release GitHub v3.0.0, pubblicata a cambio già completo da oltre un giorno, dice per intero: «New model weights and associated code: TimesFM-3.0» — nuovi pesi del modello e codice associato: TimesFM-3.0. Nessuna menzione della licenza né del cambiamento avvenuto due giorni prima. Chi si fida solo del comunicato non impara, da quel testo, che il permesso è diverso da quello della versione precedente — e il ramo continua a muoversi anche dopo il tag: correzioni, rimozioni di tag, un commit il cui titolo comincia con la parola Test, tutti successivi al momento in cui chiunque avrebbe considerato il modello ormai rilasciato.

Quello che non abbiamo verificato

Non abbiamo trovato, né raggiunto, un annuncio dedicato sul blog di Google Research o di Google Cloud: ci siamo basati sul repository GitHub ufficiale, canale diretto dell’azienda, non una fonte terza. Non sappiamo quanti dei 46.862 download registrati oggi risalgano alla finestra di 69 ore in cui la scheda dichiarava Apache 2.0: l’API di Hugging Face non pubblica un conteggio per intervallo di tempo né per revisione. Non abbiamo eseguito il modello né riprodotto le classifiche di benchmark (GIFT-Eval, fev-bench, TIME) che la stampa attribuisce a Google: sono numeri dichiarati dal produttore e riportati da terzi, non misurati da noi. E non sappiamo se, presso chi ha clonato il repository fra il 24 e il 27 agosto, sopravviva ancora una copia del README con Apache 2.0: il file non è cancellato — resta nella cronologia — ma nessuno lo nota se non la guarda di proposito. E i commit stessi non dicono perché sia avvenuto il cambio: né i messaggi né la nota su GitHub lo definiscono una correzione di un’etichetta sbagliata piuttosto che una scelta deliberata, e non abbiamo trovato una dichiarazione di Google in un senso o nell’altro.

Cosa fare, in pratica

Quando scaricate un modello con from_pretrained o git clone, fissate una revisione precisa, non solo il nome del repository: è l’unico modo per sapere con certezza quale licenza avete accettato.
Prima della produzione, salvate una copia locale del file LICENSE insieme ai pesi, con la data del download: se cambia più avanti, avrete la prova di quale versione avevate accettato voi.
Non date per scontata la continuità di licenza da una versione alla successiva: verificate ogni major release, non solo la prima volta.
Leggete il testo della licenza, non solo l’etichetta: una clausola come il divieto di distribuzione cambia cosa potete fare anche in un progetto interno senza scopo di lucro.
Trattate un annuncio ufficiale come un punto di partenza, non come l’elenco completo delle condizioni: il testo della release di TimesFM 3.0 non menzionava affatto la licenza già cambiata.

I due assi, applicati

Adempiere. Un ente o un’impresa che valuta un modello a pesi aperti per un caso d’uso reale — previsione della domanda, manutenzione predittiva, pianificazione — deve poter dimostrare, in un audit o in una verifica di conformità, quale licenza copriva esattamente il file che ha in esercizio, alla data in cui lo ha scaricato. Un nome di repository non basta come prova: serve la revisione, il commit, la copia del testo legale conservata insieme ai pesi.

Decidere. Lo stesso principio regge l’architettura con cui costruiamo sistemi per grandi imprese, pubblica amministrazione e difesa: ogni componente — dati, modello, agente, operatore umano al comando — è tracciato con la versione esatta che gira, non con l’etichetta generica del fornitore. In due modalità, on-premise su macchine autonome o in cloud dedicato con VPN e data center in Italia, sempre con gestione condivisa: nessuno scopre in un audit che il modello che stava usando non era più, da settimane, quello che aveva verificato.

Avete in produzione un modello a pesi aperti scaricato mesi fa, e non sapete se la sua licenza è ancora quella che avevate letto? Parliamone in una sessione di trenta minuti: verifichiamo insieme la cronologia del repository prima che lo faccia un vostro cliente o un ispettore.

I fatti, in ordine

Quello che il nome del repository non racconta

Quello che non abbiamo verificato

Cosa fare, in pratica

I due assi, applicati

Fonti