Note operative Osservatorio

Licenza aperta, accesso chiuso: un modello Hugging Face in apache-2.0 dietro il login

7 min di lettura

Grata metallica a losanghe davanti a porte chiuse, fotografia in bianco e nero, senza persone né scritte leggibili
Attraverso la grata si vede tutto quello che c’è dietro; per attraversarla, bisogna comunque fermarsi al varco.

Il 15 agosto compare su Hugging Face il repository orcarouter/Qwen3.8-27B-Uncensored-FP8: campo createdAt 2026-08-15T05:45:04Z, ultima modifica il giorno dopo. Lo abbiamo verificato di persona il 17 agosto, interrogando l’API pubblica e riprovando a scaricare un file senza autenticarci. In quel momento: 4.285 download, 344 like, 20 file, di cui 7 shard .safetensors. I tag dichiarati: abliterated, uncensored, ai-red-team, red-teaming, image-text-to-text, function-calling, reasoning, fp8, block-fp8, vllm, mtp. I metadati pubblici dichiarano license: apache-2.0 e base_model: Qwen/Qwen3.8-27B; abbiamo controllato anche la scheda del modello base, ed è apache-2.0 pure quella — le due licenze coincidono, quindi qui non c’è la trappola del derivato che cambia licenza lungo la catena di cui avevamo scritto per un’altra famiglia di modelli.

C’è però un secondo campo, e non riguarda il testo della licenza: gated: "auto". Interroghiamo un file del repository senza account — prima il README.md, poi il file LICENSE — e la risposta è HTTP 401, con questo messaggio, verbatim: «Access to model orcarouter/Qwen3.8-27B-Uncensored-FP8 is restricted. You must have access to it and be authenticated to access it. Please log in.» — traduzione nostra: l’accesso al modello è riservato, bisogna averne diritto ed essere autenticati per accedervi, occorre effettuare il login. Il file LICENSE compare fra i 20 elencati dall’API del repository, ma il suo testo non è consultabile senza accettare condizioni che, a loro volta, non sono leggibili senza accedere.

Sulla pagina pubblica, senza login, compaiono due frasi, verbatim: «This repository is publicly accessible, but you have to accept the conditions to access its files and content.» e «You need to agree to share your contact information to access this model» — traduzione nostra: il repository è pubblicamente accessibile, ma bisogna accettare le condizioni per accedere ai suoi file e contenuti; occorre acconsentire a condividere i propri dati di contatto per accedere a questo modello.

Due piani, non uno

La licenza Apache 2.0 è fra le più permissive che esistano: chi la riceve può usare, copiare, modificare e ridistribuire l’opera senza chiedere permesso a nessuno. Ma governa che cosa si può fare con il file, una volta ottenuto — non il canale con cui il file arriva a chi lo vuole. Il gate, la richiesta di accesso, è una decisione di chi amministra il repository, non una clausola della licenza: Apache 2.0 non obbliga nessuno a tenere un canale di download aperto a chiunque, né lo vieta.

Hugging Face documenta pubblicamente il meccanismo: un repository con le richieste di accesso abilitate è un gated model; se chi lo amministra lascia il valore di default, l’accesso «is automatically granted to the user when requesting it» — traduzione nostra: è concesso automaticamente a chi lo richiede, non appena l’utente ha condiviso le proprie informazioni; è il caso che Hugging Face chiama automatic approval. L’alternativa, che va scelta esplicitamente, è l’approvazione manuale, dove ogni richiesta resta in coda finché qualcuno non la accetta. Il valore che leggiamo nell’API, gated: "auto", corrisponde al primo caso — quello di default. Lo riportiamo perché è ciò che la documentazione pubblica dice di quel campo, non perché lo abbiamo verificato di persona: non disponiamo di un account con cui completare una richiesta d’accesso.

La stessa documentazione spiega che cosa raccoglie il modulo nella sua forma predefinita: nome utente ed email di chi chiede accesso. Chi amministra un repository può aggiungere altri campi — azienda, paese, uso previsto — personalizzando il modulo. Quali campi compaiano su questo repository specifico è ciò che non abbiamo verificato: per vederlo serve lo stesso accesso che il 401 ci nega.

Perché un registro non può fermarsi ad apache-2.0

Un registro dei modelli che annota solo la licenza dichiarata sulla scheda — qui, apache-2.0 — ha scritto qualcosa di vero. Non ha scritto tutto. Nelle ultime due settimane abbiamo verificato registri agli estremi opposti dello stesso spettro: un repository senza alcuna licenza dichiarata, un altro in MIT, senza un secondo documento che la restringa, e ieri una licenza permissiva con una soglia di fatturato oltre la quale serve un contratto separato. Questo caso aggiunge un quarto punto sullo stesso spettro: licenza dichiarata, coerente con il modello base, per niente ambigua — e un canale di distribuzione che comunque richiede di identificarsi prima di consegnare i file.

Tre cose che la sola riga apache-2.0 non dice:

  1. La licenza non è il controllo d’accesso. Sapere che un modello è Apache 2.0 non dice se domani lo si potrà riscaricare dallo stesso repository, né se il repository esisterà ancora, né a quali condizioni è stato ottenuto la prima volta — condizioni che possono cambiare senza che il campo licenza si muova di una virgola.
  2. Il gate raccoglie dati su chi scarica. Chi lo fa in azienda, per portare un modello in produzione, lo fa quasi sempre con un account personale: una decisione aziendale — quali informazioni condividere, con quale controparte — presa da una persona, e quasi mai tracciata in un registro che qualcun altro possa consultare in seguito.
  3. Il modello ha le protezioni tolte e sa chiamare funzioni. I tag lo dichiarano insieme: abliterated, uncensored, function-calling. Non lo abbiamo provato e non affermiamo nulla sul suo comportamento — ne avevamo scritto a proposito di migliaia di derivati con lo stesso trattamento, il rifiuto tolto dai pesi e non dalla conversazione. Qui lo osserviamo insieme alla capacità dichiarata di invocare strumenti: un modello che non rifiuta nulla e sa agire su sistemi esterni, se entra in un impianto che tocca dati o processi reali, è una scelta di architettura che qualcuno in azienda deve avere approvato per iscritto — non un dettaglio che si scopre dopo.

Vedi il servizio · Parlane con un tecnico

Quello che non sappiamo

Non abbiamo scaricato il modello, non abbiamo un account con cui accettare le condizioni e non abbiamo letto il model card per intero: il 401 ce lo impedisce senza autenticarci, e tutto ciò che riportiamo viene dai metadati pubblici e dalla pagina pubblica del repository. Non abbiamo provato il modello e non affermiamo nulla sulla sua qualità né sul suo comportamento reale. Non sappiamo chi sia l’autore — l’account si chiama orcarouter, niente di più — né quali condizioni esatte impone il modulo di accesso, perché leggerle richiede lo stesso login che il download nega. E non diamo qualificazioni giuridiche: se un modello con le protezioni tolte rientri in una categoria dell’AI Act dipende dall’uso concreto che se ne fa, ed è una valutazione di chi lo mette in servizio, non nostra.

Come lo risolviamo noi

Adempiere: il registro dei modelli in produzione diventa un controllo che gira sui sistemi del cliente — per ciascun modello: versione e digest dell’artefatto, canale e data di acquisizione, se il repository era gated e chi ha accettato le condizioni, licenza archiviata nel testo di quel giorno, usi approvati e chi li ha approvati — con la traccia datata da esibire a un’ispezione, a un cliente in gara o a un consiglio di amministrazione.

Decidere: lo stesso impianto tiene insieme modelli, dati, contratti, archivi e documenti in un modello operativo unico su cui agenti AI eseguono decisioni con un operatore al comando, per grandi imprese, difesa, pubblica amministrazione e sanità. Conservare l’artefatto dentro il perimetro del cliente, invece di ripescarlo ogni volta dal repository di qualcun altro, è ciò che rende l’impianto indipendente dalla sopravvivenza di un canale che può chiudersi da un giorno all’altro: il repository può sparire, il gate può cambiare condizioni, l’account che ha accettato può lasciare l’azienda — l’obbligo di documentare che cosa gira in produzione resta comunque. Sempre nelle due modalità dell’offerta — on-premise, su macchine autonome che non richiedono un’integrazione profonda nella rete del cliente, oppure cloud dedicato con VPN dedicata e data center in Italia — e sempre con gestione condivisa: non dovete già avere in casa chi amministra questi sistemi.

Dalla prima sessione, senza costi, esce il registro datato dei modelli in esercizio: per ciascuno, come è stato ottenuto, se il canale è ancora aperto e che cosa avete conservato — comprese le caselle che restano vuote. Resta a voi anche se non proseguiamo insieme.

Fonti