docs: assess core license compatibility

2026-09-02 18:19:22 +02:00
1 changed files with 219 additions and 0 deletions
@@ -0,0 +1,219 @@
+# 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.