From 61b7e19c403b7b575751be6cc885900411948317 Mon Sep 17 00:00:00 2001 From: Codex Date: Wed, 2 Sep 2026 18:19:22 +0200 Subject: [PATCH] docs: assess core license compatibility --- ...re-license-and-repository-compatibility.md | 219 ++++++++++++++++++ 1 file changed, 219 insertions(+) create mode 100644 docs/research/2026-09-02-core-license-and-repository-compatibility.md diff --git a/docs/research/2026-09-02-core-license-and-repository-compatibility.md b/docs/research/2026-09-02-core-license-and-repository-compatibility.md new file mode 100644 index 00000000..4f7dbf7d --- /dev/null +++ b/docs/research/2026-09-02-core-license-and-repository-compatibility.md @@ -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.