ThothII/docs/research/2026-09-02-core-license-and-repository-compatibility.md

Licenza del core e compatibilità del repository

Data della verifica: 2026-09-02
Ticket: Valutare licenza del core e compatibilità legale del repository

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 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, Apache License 2.0, GPLv3, AGPLv3 e FAQ GNU su plugin e aggregazione.

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.
• 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.

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. Fonti: tag upstream v0.7.3 e release PyPI.
• 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 e 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, Developer Certificate of Origin e Apache Contributor Agreements.

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.