Generatore di Licenze

Avanti

Spedire un progetto senza un file LICENSE significa tecnicamente “tutti i diritti riservati”, nessuno può riutilizzare il codice. Questo generatore produce il testo completo e non modificato delle licenze open source più popolari, con il tuo nome e l’anno corrente sostituiti nell’intestazione del copyright. Incollalo in un file LICENSE nella radice del tuo repository e fai il push.

Come scegliere e generare una licenza

  1. 1

    Scegli una licenza

    MIT per permissiva, Apache-2.0 per permissiva + concessione di brevetto, GPLv3 per copyleft.

  2. 2

    Inserisci il tuo nome e anno

    Il titolare del copyright, il tuo nome legale o la tua azienda. L'anno è il primo anno di rilascio.

  3. 3

    Rivedi il testo completo

    Il testo della licenza rimane esattamente come lo pubblicano OSI / FSF; solo la riga del copyright cambia.

  4. 4

    Inseriscilo in LICENSE

    Salva nella radice del tuo repository. GitHub lo rileva e lo visualizza nella barra laterale.

Scegliere tra le opzioni popolari

Non esiste una licenza open source “migliore” universale. La scelta dipende da cosa vuoi che gli utenti downstream possano, e non possano, fare.

Licenza Tipo Concessione di brevetto Copyleft? Utenti notevoli
MIT Permissiva Implicita No Rails, pacchetti Node, jQuery
Apache-2.0 Permissiva Esplicita No Kubernetes, Android AOSP
BSD-3-Clause Permissiva No No Libreria standard Go, Nginx
GPL-3.0 Copyleft forte GCC, Bash, GIMP
LGPL-3.0 Copyleft debole Parziale glibc, Qt (storicamente)
MPL-2.0 Copyleft debole Parziale Firefox, Thunderbird
AGPL-3.0 Copyleft di rete MongoDB (pre-2018), Grafana
Unlicense / CC0 Dedica al pubblico dominio - No Piccole librerie utilitarie

Le tre domande pratiche

  1. Vuoi fork chiusi? Permissive (MIT, Apache, BSD) → sì. Copyleft (GPL, AGPL) → no.

  2. Ti interessa la ritorsione sui brevetti? Apache-2.0, GPLv3 e MPL-2.0 hanno concessioni di brevetto esplicite che terminano in caso di contenzioso. MIT e BSD-2/3 non lo fanno.

  3. Il tuo codice funziona come servizio di rete? AGPL-3.0 chiude il “buco” SaaS, gli utenti del servizio contano come distribuzione. Se questo è importante, sceglilo; altrimenti GPLv3 è più semplice.

Errori comuni da evitare

  • Non modificare il testo della licenza. Una licenza “MIT-con-le-mie-modifiche” è una nuova licenza incompatibile. I tribunali rifiutano modifiche ad hoc.
  • Non usare due licenze senza comprendere la compatibilità. Apache-2.0 e GPLv2 non sono compatibili; Apache-2.0 e GPLv3 lo sono.
  • Non dimenticare l’identificatore SPDX negli header di origine: SPDX-License-Identifier: MIT sulla riga 1 aiuta gli strumenti a rilevare la tua scelta.
  • Non usare “Creative Commons” per il software. Le licenze CC sono per opere creative; usale su documentazione e immagini, non su codice.

Licenze duali

Alcuni progetti vengono distribuiti sotto due licenze, tipicamente una copyleft, una commerciale, in modo che le aziende possano acquistare l’uscita dai termini copyleft. Qt e MySQL lo fanno famosamente. È legalmente complesso; se non monetizzi il progetto, attieniti a una singola licenza approvata da OSI.

Domande frequenti

MIT è la più popolare per piccoli progetti open source: breve, permissiva, ampiamente compresa e compatibile con praticamente ogni altra licenza. Apache-2.0 è una scelta leggermente più sicura se il tuo progetto ha qualche novità brevettabile.

Sì. Senza uno, il tuo codice è completamente protetto da copyright e nessuno può riutilizzarlo legalmente, l’accesso pubblico di GitHub non è una licenza. Aggiungi un file LICENSE lo stesso giorno in cui rendi pubblico il repo.

Il primo anno di rilascio (anno singolo) o un intervallo che termina nell’anno corrente (ad es. “2019-2026”). Aggiornare l’anno ogni gennaio è una cortesia, non un requisito legale nella maggior parte delle giurisdizioni.

No, la sostituzione avviene nel tuo browser e il tuo nome, anno e scelta della licenza non vengono mai inviati a noi.

Strumenti correlati

Strumento disponibile in altre lingue