Licenze Open Source: MIT, GPL, Apache, LGPL — Guida alla Scelta • Meteora Web Agency

Hai sviluppato un plugin, una libreria o un tema WordPress. Ora ti chiedi: con che licenza lo rilascio? Non è una domanda da lasciare al caso. Una licenza sbagliata può bloccare adozione, generare conflitti legali o, al contrario, far perdere il controllo sul tuo lavoro. Noi, di Meteora Web, ci siamo passati. Abbiamo rilasciato codice open source, integrato librerie terze e consigliato clienti su quale strada prendere. Questa guida ti spiega le differenze reali tra MIT, GPL, Apache e LGPL, senza gergo legale inutile, e ti dà uno schema operativo per decidere.

Il problema: perché una licenza non è un dettaglio burocratico

Immagina di aver costruito un componente per Laravel che risolve un problema diffuso. Lo pubblichi su GitHub. Senza licenza, nessuno può usarlo legalmente — il copyright impedisce ogni riproduzione. Con una licenza sbagliata (es. GPL) rischi che un’azienda lo eviti perché obbliga a rendere open tutto il loro software proprietario. Oppure scegli MIT e qualcuno lo rivende senza nemmeno citarti. La licenza è il contratto tra te e chi usa il tuo codice. Definisce cosa può fare l'utente, cosa deve fare, e cosa succede al tuo lavoro.

Noi lo vediamo spesso: progetti abbandonati perché la licenza non era chiara, fork persi, contributi rifiutati. Conosci le quattro licenze più diffuse, il loro impatto pratico e come sceglierle in base al tuo obiettivo.

Le quattro licenze che contano

Esistono centinaia di licenze open source, ma il mondo reale ruota attorno a quattro principali. Ogni altra è una variazione. Capisci queste e hai il 90% delle situazioni coperte.

MIT — la via libera, quasi senza obblighi

Permissiva, corta, chiara. Con la licenza MIT chiunque può copiare, modificare, distribuire, vendere il tuo codice, a patto che includa il testo della licenza e l'avviso di copyright. Nessun obbligo di rendere open le modifiche.

Quando usarla? Vuoi massima diffusione, il progetto è una libreria di utilità, un componente base. Esempi famosi: React (prima del cambio), jQuery, Node.js (parti).

Attenzione: Non hai alcun controllo su come il codice viene usato. Un'azienda può prenderlo, chiuderlo in un prodotto proprietario e non contribuire mai indietro.

MIT License

Copyright (c) [year] [fullname]

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.

GPL (GNU General Public License) — la copyleft forte

Obbliga a rilasciare con la stessa licenza. Se distribuisci un software che include codice GPL, l'intero lavoro deve essere distribuito sotto GPL. Questo impedisce che il codice venga inglobato in prodotti proprietari chiusi. È la licenza del kernel Linux, di WordPress, di MySQL (prima del fork).

Quando usarla? Vuoi che ogni miglioramento rimanga open e non venga “rubato” da progetti chiusi. Ideale per framework o piattaforme dove vuoi una comunità che condivide tutto.

Attenzione: Se sei un fornitore di servizi (es. un tema WordPress), la GPL può limitare il tuo modello di business perché chiunque può ridistribuire la tua creazione. WordPress stesso è GPL, ma molti temi premium usano licenze doppie per aggirarlo.

GNU GENERAL PUBLIC LICENSE
Version 3, 29 June 2007

Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.

[... sezioni lunghe ...]

You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:
  a) The work must carry prominent notices stating that you modified it.
  b) The work must carry prominent notices stating that it is released under this License.
  c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy.

Apache 2.0 — permissiva con protezioni extra

Simile a MIT ma include clausole su brevetti e contributi. Apache 2.0 concede una licenza esplicita sui brevetti detenuti dall’autore, proteggendo chi usa il codice da cause per violazione di brevetto. Inoltre richiede di mantenere gli avvisi di attribuzione. È la licenza di Android, Kubernetes, Apache HTTP Server.

Quando usarla? Se il progetto ha rilevanza brevettuale (es. algoritmi, metodi) o se lavori in contesti aziendali che temono rischi legali. Molte grandi aziende preferiscono Apache 2.0 proprio per la copertura brevettuale.

Attenzione: È leggermente più lunga di MIT, ma l’effetto pratico per un utente normale è molto simile. Non obbliga a rilasciare modifiche.

Apache License
Version 2.0, January 2004

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

    http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

LGPL (GNU Lesser General Public License) — copyleft solo per la libreria

Permette di collegare il codice a software proprietario senza obbligare l’intero programma. Ideale per librerie. La LGPL richiede che le modifiche alla libreria stessa restino LGPL, ma chi usa la libreria (collegandola dinamicamente) non è obbligato a rilasciare il proprio codice. Esempio famoso: glibc, GTK.

Quando usarla? Stai distribuendo una libreria che vuoi sia usata anche in progetti chiusi, ma vuoi che i miglioramenti alla libreria tornino alla comunità. È un compromesso tra MIT e GPL.

GNU LESSER GENERAL PUBLIC LICENSE
Version 3, 29 June 2007

... (simile a GPL ma con sezioni aggiuntive che permettono il linking dinamico a opere non GPL) ...

Come scegliere: il decision tree pratico

Non esiste la licenza perfetta in assoluto. Esiste quella giusta per il tuo progetto. Ecco le domande da porti:

Obiettivo principale — massima diffusione? → MIT o Apache. Protezione da chiusure? → GPL. Libreria da integrare in progetti misti? → LGPL.
Modello di business — vuoi vendere licenze commerciali? Allora devi usare una licenza doppia (es. GPL + commerciale). Se usi MIT, chiunque può rivendere il tuo codice gratis.
Comunità e contributi — GPL incoraggia la condivisione ma può scoraggiare contributori aziendali. Apache 2.0 è più friendly per le imprese.
Rischio brevetti — Apache 2.0 è l’unica delle quattro a dare una licenza esplicita sui brevetti. Se il tuo progetto riguarda un’invenzione brevettabile, scegli Apache.

Scenario 1: stai creando un plugin per WordPress

WordPress è GPLv2. Se il tuo plugin usa codice WordPress (inclusi hooks e funzioni di core), devi rilasciarlo con una licenza compatibile GPL. Puoi usare GPL o MIT (MIT è compatibile con GPL solo per linking? No — attenzione: la FSF dice che MIT è compatibile, ma la pratica comune è usare GPL stessa per evitare dubbi. Noi consigliamo GPL per plugin WordPress perché la community se lo aspetta e semplifica la distribuzione ufficiale su WordPress.org.

Scenario 2: libreria JavaScript per il frontend

Se è un piccolo utilitario che vuoi usato da tutti, MIT è la scelta naturale. Se vuoi che i fork restino aperti, GPL. Ma su npm la maggior parte delle librerie è MIT, quindi attieniti a quella per massima adozione.

Scenario 3: tema o template per vendita

Se vendi temi, la licenza doppia è comune: GPL per le parti obbligatorie (se basato su WordPress) e una licenza commerciale per rimuovere attribuzioni o ottenere supporto. Noi abbiamo visto molti sviluppatori ignorare la GPL e mettere “All rights reserved”, ma se il tema include funzioni WordPress, stai violando la licenza di WordPress. Fai attenzione.

Errori comuni che vediamo nei progetti dei nostri clienti

“Non metto nessuna licenza tanto è mio” — Senza licenza, nessuno può usare il tuo codice legalmente. Di fatto è chiuso.
Copiare la licenza da un altro progetto senza capirla — abbiamo visto progetti con GPL quando volevano MIT. Risultato: contributori confusi.
Ignorare la compatibilità — usare codice GPL in un progetto Apache 2.0 è legale solo se l’intero progetto diventa GPL. Controlla sempre la compatibilità tra licenze.
Non includere il file LICENSE — la licenza va nel repository root. Molti lo dimenticano e il progetto diventa di fatto non open.

Cosa fare adesso — azioni concrete

Analizza il tuo progetto: è una libreria, un'applicazione completa, un plugin? Chi lo userà?
Decidi l'obiettivo (diffusione vs controllo) e scegli la licenza tra MIT, Apache, GPL, LGPL usando lo schema sopra.
Scarica il testo ufficiale dal sito choosealicense.com o da opensource.org e aggiungilo nel repository come file LICENSE.
Aggiorna il README con una riga: “This project is licensed under the [licenza] — see the LICENSE file for details.”
Se hai dubbi legali, consulta un avvocato specializzato in proprietà intellettuale. Noi non siamo avvocati, ma queste quattro licenze sono standard e collaudate.

Noi, di Meteora Web, usiamo licenze diverse a seconda del progetto. Per i nostri tool interni spesso preferiamo MIT perché vogliamo che la comunità li adotti senza barriere. Per plugin WordPress che rilasciamo per clienti, scegliamo GPL per rimanere compatibili con la piattaforma. La scelta giusta parte dalla consapevolezza: non subire la licenza, ma usala come strumento strategico. Se vuoi approfondire il tema della sicurezza nei progetti open source che gestisci, abbiamo scritto una guida sulla sicurezza informatica sotto attacco che ti può interessare.