Autorisations, conditions et limitations en un coup d'œil
Conditions
- Mention de droit d'auteur et de licenceLors de la distribution, une copie de la licence et la mention de droit d'auteur doivent être incluses.
- Indication des modificationsLes modifications apportées à l'original doivent être signalées.
- Divulgation du sourceLe code source doit être fourni lors de la distribution.
- Même licenceLes versions modifiées et dérivés doivent être distribués sous la même licence (ou une licence compatible).
Limitations
- Limitation de responsabilitéLa licence précise qu'aucune responsabilité n'est assumée pour les dommages.
- Absence de garantieLa licence précise qu'aucune garantie n'est fournie.
Classement autorisations/conditions/limitations : données de choosealicense.com (GitHub, licence MIT).
De quelle licence s'agit-il ?
La GPL-2.0 est la deuxième version de la GPL, publiée par la FSF en juin 1991. Son principe de copyleft est le même que celui de la GPL-3.0 : distribuer un programme qui inclut ce code ou le combine impose de fournir l'ensemble sous GPL-2.0 avec son source. Le noyau Linux (GPL-2.0-only, avec une exception syscall pour certains en-têtes), Git (GPL-2.0-only) et WordPress (GPL-2.0-or-later) en sont des exemples typiques.
only et or-later
Les projets sous GPL-2.0 choisissent généralement l'une des deux options.
- GPL-2.0-only : distribution uniquement selon les conditions de cette version. C'est le choix du noyau Linux, qui ne peut donc pas passer à la GPL-3.0.
- GPL-2.0-or-later : le destinataire peut choisir la version 2.0 ou toute version ultérieure publiée par la FSF (3.0, etc.). C'est l'option de l'avis recommandé dans le texte de la GPL.
L'article 9 du texte prévoit que, pour un programme qui ne précise pas de numéro de version, n'importe quelle version publiée par la FSF peut être choisie. Il est donc important d'indiquer clairement l'option retenue dans l'en-tête des fichiers ou l'identifiant SPDX (guide).
Ce qu'il faut respecter lors de la distribution
- Fournir le code source avec le programme, ou par une offre écrite valable au moins trois ans (article 3).
- Conserver les mentions de droit d'auteur, l'exclusion de garantie et une copie de la licence (article 1).
- Indiquer dans les fichiers modifiés le fait et la date de la modification (article 2 a).
- Aucune restriction supplémentaire ne peut être imposée aux droits des destinataires (article 6). Si un accord sur des brevets, par exemple, vous empêche de respecter les conditions de la GPL, vous ne pouvez pas distribuer du tout (article 7).
Idées reçues fréquentes
- « GPL-2.0 et GPL-3.0 sont toutes deux la GPL, on peut les mélanger » — Du code GPL-2.0-only et du code GPL-3.0 ne peuvent pas être combinés et distribués. L'un des deux doit être « or later ».
- « On peut aussi y intégrer du code Apache-2.0 » — La FSF considère l'Apache-2.0 comme incompatible avec la GPL-2.0. Pour un projet « or later », la solution consiste à distribuer sous GPL-3.0.
- « Sans clause de brevets, on peut faire valoir ses brevets » — Il n'y a pas de licence de brevets explicite, mais l'article 7 et le préambule visent à empêcher une distribution dont la liberté serait restreinte par des brevets. Les interprétations divergent ; si les brevets comptent, envisagez la GPL-3.0.
Comment l'appliquer
Placez le texte tel quel dans LICENSE ou COPYING et ajoutez l'avis officiel dans chaque fichier. Si vous conservez la phrase « either version 2 of the License, or (at your option) any later version » de l'avis, c'est or-later ; si vous la retirez, c'est only. Les identifiants SPDX sont GPL-2.0-only / GPL-2.0-or-later.
Dans quels cas l'utiliser ?
Elle est nécessaire pour les projets qui doivent échanger du code avec l'écosystème GPL-2.0-only, comme les modules du noyau Linux. Pour un nouveau projet visant un copyleft fort, la GPL-3.0, aux clauses de brevets et à la compatibilité améliorées, ou la « GPL-2.0-or-later » sont plus souples.
Peut-on intégrer du code GPL-2.0 dans un autre projet ?
Verdict général lorsque du code publié sous cette licence est intégré et distribué dans un projet sous l'une des licences ci-dessous. Voir d'autres combinaisons dans le vérificateur de compatibilité →
| Projet de destination | Verdict | Remarque |
|---|---|---|
| Logiciel propriétaire (commercial) | Impossible | Tout le programme combiné et distribué devrait être publié avec son source sous la même licence GNU : impossible de l'intégrer en conservant la licence du projet. |
| MIT | Impossible | Tout le programme combiné et distribué devrait être publié avec son source sous la même licence GNU : impossible de l'intégrer en conservant la licence du projet. |
| Apache-2.0 | Impossible | Tout le programme combiné et distribué devrait être publié avec son source sous la même licence GNU : impossible de l'intégrer en conservant la licence du projet. |
| MPL-2.0 | Impossible | Tout le programme combiné et distribué devrait être publié avec son source sous la même licence GNU : impossible de l'intégrer en conservant la licence du projet. |
| LGPL-2.1 | Possible sous conditions | La LGPL-2.1 autorisant le passage à la GPL, c'est possible uniquement si l'ensemble combiné est distribué sous GPL-2.0-only. |
| LGPL-3.0 | Impossible | Le code GPL-2.0-only n'est pas compatible avec les conditions supplémentaires de la GPL-3.0, LGPL-3.0 et AGPL-3.0. |
| GPL-3.0 | Impossible | Le code GPL-2.0-only n'est pas compatible avec les conditions supplémentaires de la GPL-3.0, LGPL-3.0 et AGPL-3.0. |
| AGPL-3.0 | Impossible | Le code GPL-2.0-only n'est pas compatible avec les conditions supplémentaires de la GPL-3.0, LGPL-3.0 et AGPL-3.0. |
Le contenu de ce site est fourni à titre d'information générale et ne constitue pas un conseil juridique. Pour toute décision de distribution, de contrat ou de litige, consultez un avocat ou un autre professionnel.