# Licenza del core e compatibilità del repository Data della verifica: 2026-09-02 Ticket: [Valutare licenza del core e compatibilità legale del repository](https://git.tylconsulting.it/mptyl/ThothII/issues/22) > Questa è un'analisi tecnica delle licenze e della provenienza osservabile nel repository, non > consulenza legale. Prima della prima distribuzione pubblica o commerciale, un professionista > qualificato nella giurisdizione di TYL Consulting e dei clienti deve validare confini dei lavori > derivati, titolarità, brevetti, marchi, EULA e obblighi di redistribuzione. ## Decisione proposta Adottare **Apache License 2.0** per la Community Edition e una licenza commerciale separata per l'Enterprise Edition. Apache-2.0 è preferibile a MIT per un prodotto enterprise perché contiene una concessione brevettuale esplicita con clausola di cessazione, disciplina i contributi, tutela i marchi e descrive esplicitamente come non derivati i lavori separabili o che si limitano a collegarsi alle interfacce. Rimane una licenza permissiva: consente uso commerciale, modifica e distribuzione proprietaria delle modifiche nel rispetto degli obblighi della licenza. **La pubblicazione non è ancora pronta.** Due problemi devono essere risolti prima di applicare Apache-2.0 al repository: 1. `yake==0.7.3` è importato direttamente dal runtime Python e il file `LICENSE` dell'artefatto ufficiale contiene AGPL-3.0, benché i metadati PyPI dichiarino in modo incoerente LGPL/GPL. Va sostituito con una dipendenza permissiva, rimosso, oppure coperto da una licenza commerciale verificata. L'isolamento va considerato solo dopo parere legale; nel codice attuale non c'è isolamento, ma un normale `import yake`. 2. [`harness/tht/vendor/VENDORED.md`](../../harness/tht/vendor/VENDORED.md) dichiara Apache-2.0 per `thoth_lsh.py`, mentre l'artefatto upstream `thoth-dbmanager==0.7.4` su PyPI contiene una licenza MIT e il relativo copyright. Occorre correggere la provenienza e conservare il testo MIT, oppure documentare formalmente una nuova licenza da parte di tutti i titolari effettivi. ## MIT, Apache-2.0 e copyleft | Tema | MIT | Apache-2.0 | GPLv3 / AGPLv3 | | --- | --- | --- | --- | | Uso commerciale e codice proprietario | Sì; obbligo essenziale di conservare copyright e licenza | Sì; consente termini diversi sulle modifiche, preservando gli obblighi Apache | Il codice coperto e le opere combinate distribuite devono rispettare il copyleft | | Brevetti | Nessuna concessione brevettuale espressa nel testo | Concessione espressa sui claim necessariamente violati dal contributo; termina in caso di determinata causa brevettuale | GPLv3/AGPLv3 contengono condizioni brevettuali proprie | | Redistribuzione | Conservare copyright e testo MIT nelle copie o porzioni sostanziali | Fornire la licenza, marcare i file modificati, conservare notice pertinenti e riprodurre `NOTICE` quando presente | Fornire il Corresponding Source e non imporre ulteriori restrizioni incompatibili | | Moduli proprietari | Consentiti; il testo non definisce il confine fra opere | Consentiti; la definizione esclude lavori separabili o che si limitano a collegarsi alle interfacce | Confine fattuale e giuridico. L'aggregazione di opere indipendenti è distinta da un programma combinato | | Uso via rete | Nessun obbligo specifico | Nessun obbligo specifico | AGPLv3 §13 richiede offrire il Corresponding Source agli utenti remoti di una versione modificata | | Contributi | Nessuna disciplina esplicita nel breve testo | §5: contributi intenzionalmente sottoposti sono Apache-2.0 salvo dichiarazione o accordo separato | Contributi al lavoro coperto devono poter essere distribuiti sotto la licenza applicabile | | Marchi | Non disciplinati | §6 non concede diritti sui marchi salvo uso descrittivo e `NOTICE` | Non sono automaticamente una licenza del marchio | Fonti primarie: [testo MIT dell'OSI](https://opensource.org/license/mit/), [Apache License 2.0](https://www.apache.org/licenses/LICENSE-2.0), [GPLv3](https://www.gnu.org/licenses/gpl-3.0.html), [AGPLv3](https://www.gnu.org/licenses/agpl-3.0.html) e [FAQ GNU su plugin e aggregazione](https://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins). ### Perché non scegliere MIT MIT renderebbe semplice l'adozione e il riuso proprietario, ma non dà a compratori e contributori la stessa chiarezza di Apache-2.0 sui brevetti, sui contributi e sui marchi. La brevità non compensa questa minore precisione per un prodotto venduto a IT department enterprise. MIT resta compatibile con l'obiettivo open-core, ma Apache-2.0 gestisce meglio il rischio del progetto. ### Perché non scegliere copyleft per il core Il copyleft aumenterebbe la reciprocità, ma rende più delicato il confine con l'Enterprise Edition e può creare una revisione legale più onerosa per i clienti. AGPL è inoltre poco allineata alla scelta commerciale già fissata: installazione interamente nel trust boundary del cliente e funzionalità Enterprise proprietarie. Se in futuro la priorità diventasse impedire fork proprietari del core, GPL/AGPL andrebbero valutate in una decisione distinta, non introdotte accidentalmente da una dipendenza. ## Confine Community / Enterprise Il confine raccomandato è tecnico oltre che contrattuale: - Community Edition in repository pubblico, licenza Apache-2.0, workflow fondamentale completo e interfacce di estensione pubbliche; - Enterprise Edition in repository, package e immagini separati, con EULA commerciale e SBOM autonomo; - integrazione attraverso API/versioned contracts o process boundary. Anche se Apache-2.0 consente linking e opere separabili, questa separazione riduce errori di packaging e rende auditabile il perimetro venduto; - una distribuzione Enterprise può aggregare componenti Community, ma deve continuare a fornire Apache-2.0 e tutti i notice della Community. L'EULA non deve revocare ai clienti i diritti Apache sui componenti Community; - marchio e logo `ThothII` richiedono una policy separata: la licenza del codice non deve essere usata come licenza del brand. Il giudizio finale sul fatto che un plugin concreto sia un'opera indipendente o derivata dipende dalla sua implementazione e dalla legge applicabile: è un punto da sottoporre al legale quando esisterà il primo modulo Enterprise. ## Inventario del repository L'inventario deriva dai file tracciati nel commit `ae053961`, dai lockfile e, per i casi anomali, dagli artefatti ufficiali dei registry. I metadati dei registry non sostituiscono i testi di licenza inclusi nelle distribuzioni: l'incoerenza di YAKE lo dimostra. ### Stato della licenza propria - Non esistono `LICENSE`, `NOTICE`, `COPYING`, `AUTHORS` o `THIRD_PARTY_NOTICES` alla radice. - I manifest `backend/package.json`, `frontend/package.json`, `harness/package.json`, `docker/pi-runtime/package.json`, `tools/html-to-pptx/package.json` e `harness/pyproject.toml` non dichiarano la licenza del progetto. - La cronologia Git contiene più identità (`mptyl`, `Marco Pancotti`, `User`, `Codex`, Gitea Actions) e trailer `Co-authored-by` di strumenti AI, ma nessun `Signed-off-by`. La dichiarazione del proprietario è che il codice appartiene interamente a TYL Consulting; prima del rilascio occorre collegare documentalmente gli alias al titolare e conservare i termini applicabili agli output generati. ### JavaScript / TypeScript Cinque lockfile npm sono presenti e nessun manifest dichiara la licenza del package ThothII. | Superficie | Package bloccati | Risultato dei metadati nel lock | | --- | ---: | --- | | backend | 366 | MIT 296, ISC 27, Apache-2.0 19, BSD-3-Clause 16, BlueOak 4, senza campo 3, Unlicense 1 | | runtime Pi | 140 | MIT 67, Apache-2.0 46, BSD-3-Clause 13, ISC 8, BlueOak 5, 0BSD 1 | | frontend | 874 | prevalentemente MIT; inoltre OFL-1.1, CC-BY-4.0, Python-2.0, BSD, ISC e licenze alternative | | harness (dev) | 1 | MIT | | exporter PPTX | 22 | prevalentemente MIT; `jszip` offre l'alternativa MIT oppure GPL-3.0-or-later | Elementi che richiedono notice o verifica esplicita: - `@fontsource-variable/geist@5.2.9` è OFL-1.1 e viene distribuito nel frontend; OFL richiede che copyright e licenza accompagnino ogni copia del font. Vedi [OFL 1.1](https://openfontlicense.org/open-font-license-official-text/). - `dompurify@3.4.11` offre `MPL-2.0 OR Apache-2.0`: documentare la scelta Apache-2.0. - `jszip@3.10.1` offre `MIT OR GPL-3.0-or-later`: documentare la scelta MIT. - `khroma`, `buildcheck`, `cpu-features` e `ssh2` non hanno il campo `license` nei lock/registry esaminati: lo scanner di release deve leggere la licenza inclusa nei tarball, non assumere MIT. - `@earendil-works/pi-coding-agent@0.80.3`, AG Grid Community, Fastify, Kysely e OpenID Client risultano MIT nei metadati ufficiali npm. Fonti: lockfile locali e metadata del [registry npm](https://registry.npmjs.org/). ### Python `harness/uv.lock` blocca 85 package, incluso il workspace `tht`; i metadata ufficiali PyPI degli 84 package esterni riportano soprattutto MIT, Apache e BSD. Le eccezioni sono: - **YAKE 0.7.3: blocker.** Il file `LICENSE` nel source distribution ufficiale è AGPL-3.0 e offre separatamente una licenza commerciale. I metadata dichiarano invece `LGPLv3` e classificano GPLv3. Il codice lo importa in [`harness/tht/session/store.py`](../../harness/tht/session/store.py). Fonti: [tag upstream v0.7.3](https://github.com/INESCTEC/yake/blob/v0.7.3/LICENSE) e [release PyPI](https://pypi.org/project/yake/0.7.3/). - `psycopg2-binary==2.9.12`: LGPLv3 con eccezioni specifiche nel file `LICENSE` dell'artefatto. - `certifi==2026.7.22`: MPL-2.0 per il bundle di CA modificato. - `tqdm==4.70.0`: licenza composita con parti MPL-2.0 e MIT, non una semplice alternativa; preservare il suo `LICENCE`. - `fsspec==2026.7.0`: il metadata PyPI è vuoto, ma il source distribution include BSD-3-Clause. `docs/requirements.lock` contiene 31 dipendenze di build documentale; fra queste `certifi` e `pathspec` riportano MPL-2.0. Sono build-time, ma vanno comunque incluse nella scansione del processo di release se vengono ridistribuite in immagini o toolchain. ### Go `tools/tht/go.mod` ha 12 dipendenze dichiarate e il grafo scaricato contiene solo famiglie permissive osservate nei testi root: Apache-2.0, MIT, BSD-2-Clause, BSD-3-Clause e ISC. Alcuni moduli Apache includono anche `NOTICE`, che deve essere propagato nell'immagine/binario distribuito. `tools/dwh-auth/go.mod` non dichiara dipendenze esterne. `go.sum` è presente solo per `tools/tht`. ### Codice vendorizzato e asset - `harness/tht/vendor/thoth_lsh.py` è copiato e modificato da `thoth-dbmanager==0.7.4`. L'artefatto PyPI ufficiale contiene MIT, mentre il repository lo marca Apache-2.0. È necessario risolvere la discrepanza e includere l'attribuzione corretta. Fonti: [metadata PyPI](https://pypi.org/pypi/thoth-dbmanager/0.7.4/json) e [`VENDORED.md`](../../harness/tht/vendor/VENDORED.md). - `frontend/prototypes/database-management/assets/thoth-cosmic-archive.png` è documentato come output del tool ImageGen. Prima di pubblicarlo sotto Apache-2.0, conservare evidenza del contratto applicabile e della decisione del titolare di includerlo nella Community Edition. - `presentations/thothii-congresso.pptx` è generato dalle sorgenti HTML/JSON locali e contiene PNG rasterizzati. L'HTML carica Fraunces e Manrope da Google Fonts: conservare le rispettive licenze font e decidere se la presentazione appartiene davvero al source release del prodotto. - Il solo font binario individuato nel bundle applicativo arriva da `@fontsource-variable/geist` ed è OFL-1.1. Non sono presenti altri font, PDF, archivi o WASM tracciati; è presente un PNG e un PPTX. ### Immagini container e modelli Il deploy usa immagini pin per Node, Python, Go, nginx-unprivileged, PostgreSQL, Qdrant e Ollama. Il bootstrap scarica dinamicamente `qwen3-embedding:0.6b`. I lockfile applicativi non inventariano i package OS delle immagini né la licenza dei pesi scaricati. Prima della distribuzione occorre generare un SBOM per ogni immagine finale, archiviare i notice dei base image e acquisire la licenza del modello esatto; il nome del modello senza digest non è una prova sufficiente. ## Contributi e copyright Per l'open-core proposto non è necessario acquisire il copyright di ogni contributore se l'Enterprise resta un'opera separata. Apache-2.0 §5 fornisce un default inbound=outbound, ma non è un trasferimento di titolarità. Raccomandazione iniziale: 1. `CONTRIBUTING.md` con Apache-2.0 inbound=outbound e Developer Certificate of Origin; 2. sign-off obbligatorio e verifica automatica; 3. CLA soltanto se TYL vuole in futuro dual-license **gli stessi file** Community, cambiare licenza unilateralmente o ottenere concessioni brevettuali/di relicensing ulteriori; 4. registro di provenienza per codice, asset, modelli e dipendenze vendorizzate; 5. policy marchio separata dalla licenza del codice. Fonti primarie: [Apache-2.0 §5](https://www.apache.org/licenses/LICENSE-2.0), [Developer Certificate of Origin](https://developercertificate.org/) e [Apache Contributor Agreements](https://www.apache.org/licenses/contributor-agreements.html). ## Gate prima della pubblicazione 1. Sostituire YAKE o ottenere e verificare una licenza commerciale compatibile con entrambe le edizioni; la sostituzione è preferibile perché YAKE serve soltanto a derivare il nome sessione. 2. Risolvere la provenienza MIT/Apache di `thoth_lsh.py` e correggere `VENDORED.md`. 3. Fissare per iscritto l'elenco di directory Community; spostare Enterprise in artefatti separati. 4. Aggiungere `LICENSE` Apache-2.0, copyright TYL, `NOTICE`, `THIRD_PARTY_NOTICES` e campi SPDX nei manifest pubblicati. 5. Generare SBOM e license report dai lockfile e dalle immagini; fallire la release su licenze non ammesse, metadata mancanti o modelli senza licenza acquisita. 6. Verificare titolarità degli alias Git e condizioni degli output AI; decidere se prototype e presentazione fanno parte del rilascio. 7. Far validare da un legale: EULA Enterprise, separazione dei moduli, politica contributi/CLA, marchio, notice e dipendenze LGPL/MPL/OFL. Con questi gate chiusi, Apache-2.0 offre il miglior equilibrio fra reputazione, adozione enterprise, chiarezza brevettuale e possibilità di vendere capacità superiori in moduli proprietari separati.