Types de licences dans le développement d'applications et leurs différences

Qu'est-ce qu'une licence logicielle ?

Une licence logicielle est un ensemble de règles qui explique comment une application ou un code source peut être utilisé par d'autres.

Grâce à une licence, le créateur de l'application peut déterminer si d'autres peuvent :

• Utiliser l'application gratuitement.
• Modifier le code source.
• Revendre l'application.
• Utiliser le code pour des projets commerciaux.
• Créer des œuvres dérivées.
• Rendre le code source fermé après modification.
• Doivent partager le code source modifié.

Ainsi, même si le code source est disponible publiquement sur GitHub, cela ne signifie pas que le code peut être utilisé librement sans restrictions.

Sans licence, les règles de droit d'auteur s'appliquent automatiquement. Cela signifie que le propriétaire du code conserve tous les droits et que les autres n'ont essentiellement aucune permission de copier, modifier ou distribuer le code.

Open source ne signifie pas gratuit sans règles

Beaucoup de gens supposent que l'open source signifie que le code source peut être utilisé pour n'importe quoi sans conditions. En réalité, chaque licence open source a des règles différentes.

En général, les licences open source permettent d'utiliser, d'étudier, de modifier et de partager le logiciel. Cependant, certaines licences accordent des libertés très larges, tandis que d'autres exigent que les applications dérivées restent open source.

Les licences logicielles sont généralement divisées en plusieurs groupes principaux :

1. Licence permissive
2. Licence Copyleft
3. Licence Copyleft faible
4. Licence propriétaire
5. Licence domaine public

Tableau comparatif des licences logicielles

Licence	Type	Usage commercial autorisé	Modification autorisée	Peut être rendue fermée	Doit ouvrir le code source	Protection des brevets	Adaptée pour
MIT	Permissive	Oui	Oui	Oui	Non	Non explicitement spécifié	Bibliothèques, applications, projets personnels
Apache 2.0	Permissive	Oui	Oui	Oui	Non	Oui	Projets d'entreprise et technologies
BSD 2-Clause	Permissive	Oui	Oui	Oui	Non	Non explicitement spécifié	Systèmes, bibliothèques et applications
BSD 3-Clause	Permissive	Oui	Oui	Oui	Non	Non explicitement spécifié	Projets nécessitant la protection du nom du créateur
ISC	Permissive	Oui	Oui	Oui	Non	Non explicitement spécifié	Petits projets et bibliothèques JavaScript
GNU GPL	Copyleft fort	Oui	Oui	Non pour les œuvres dérivées	Oui, lors de la distribution	Dépend de la version	Applications entièrement open source
GNU LGPL	Copyleft faible	Oui	Oui	Oui, avec certaines conditions	Uniquement certaines parties de la bibliothèque	Dépend de la version	Bibliothèques open source
GNU AGPL	Copyleft réseau fort	Oui	Oui	Généralement non	Oui, y compris service réseau	Oui sur AGPLv3	Serveurs, SaaS et applications web
MPL 2.0	Copyleft au niveau fichier	Oui	Oui	Oui, pour des fichiers séparés	Uniquement les fichiers modifiés sous MPL	Oui	Projets mixtes open source et propriétaires
Unlicense	Style domaine public	Oui	Oui	Oui	Non	Non	Code simple destiné à être libéré
Propriétaire	Code source fermé	Selon autorisation du propriétaire	Généralement non	Oui	Non	Selon accord	Applications internes et produits payants

1. Licence MIT

La licence MIT est l'une des licences open source les plus simples et les plus flexibles.

Cette licence permet aux autres de :

• Utiliser le logiciel.
• Copier le code source.
• Modifier le code source.
• Vendre le logiciel.
• Inclure le code dans des applications payantes.
• Convertir l'application en code source fermé.

L'exigence principale est que l'avis de droit d'auteur et le texte de la licence MIT doivent rester inclus dans toutes les copies ou parties substantielles du logiciel.

Avantages de la licence MIT

• Texte de licence court.
• Facile à comprendre.
• Amical pour un usage commercial.
• Peut être utilisé dans des applications à source fermée.
• Largement utilisé dans les bibliothèques et frameworks.

Inconvénients de la licence MIT

• D'autres peuvent prendre le code, le modifier, puis le vendre en tant qu'application à source fermée.
• N'a pas de protection des brevets aussi claire qu'Apache 2.0.
• Le propriétaire du code ne peut pas exiger que les versions modifiées restent open source.

Adaptée quand

MIT est adaptée pour les développeurs qui veulent que leur code source soit utilisé aussi largement que possible sans imposer beaucoup de restrictions.

2. Licence Apache 2.0

La licence Apache 2.0 a des caractéristiques similaires à MIT. Le logiciel peut être utilisé, modifié, distribué et inclus dans des applications commerciales.

La différence clé est qu'Apache 2.0 inclut des dispositions concernant les licences de brevets. Cette licence exige également des avis d'attribution via des fichiers comme LICENSE et, si disponible, NOTICE.

Avantages d'Apache 2.0

• Peut être utilisé pour des projets commerciaux.
• Peut être inclus dans des applications à source fermée.
• A une protection et des dispositions de brevet plus claires.
• Adapté pour les projets d'entreprise.
• Les utilisateurs sont tenus de documenter les changements importants effectués.

Inconvénients d'Apache 2.0

• Texte de licence plus long comparé à MIT.
• La gestion de l'attribution et du fichier NOTICE peut être plus complexe.
• N'exige pas que les œuvres dérivées soient open source.

Adaptée quand

Apache 2.0 est adaptée pour les projets professionnels ou les entreprises qui souhaitent une licence flexible avec une protection des brevets plus claire.

3. Licence BSD

La licence BSD est une licence permissive similaire à MIT. Elle a plusieurs versions, mais les plus courantes sont BSD 2-Clause et BSD 3-Clause.

Les deux permettent l'utilisation, la modification et la distribution sous forme de code source et binaire.

BSD 2-Clause

BSD 2-Clause est également appelée Simplified BSD License.

Ses principales exigences :

• L'avis de droit d'auteur doit rester inclus.
• Le texte de licence et la clause de non-responsabilité doivent rester inclus.

BSD 3-Clause

BSD 3-Clause a une règle supplémentaire : les noms des créateurs ou contributeurs ne peuvent pas être utilisés pour promouvoir des produits dérivés sans autorisation.

Avantages de la licence BSD

• Simple et flexible.
• Peut être utilisée commercialement.
• Peut être incluse dans des applications à source fermée.
• Adaptée pour les bibliothèques et les logiciels système.

Inconvénients de la licence BSD

• Les modifications de code ne sont pas obligatoirement partagées.
• N'a pas de dispositions sur les brevets aussi claires qu'Apache 2.0.
• D'autres peuvent créer des produits propriétaires en utilisant le code.

4. Licence ISC

La licence ISC est une licence permissive très concise. Fonctionnellement, elle est presque identique à MIT et BSD 2-Clause.

Les utilisateurs peuvent utiliser, copier, modifier et distribuer le logiciel tant que l'avis de droit d'auteur et le texte de permission restent inclus.

Avantages de la licence ISC

• Texte très court.
• Facile à appliquer.
• Autorisée pour un usage commercial.
• Peut être utilisée dans des applications à source fermée.

Inconvénients de la licence ISC

• N'exige pas que les versions modifiées soient open source.
• Les dispositions sur les brevets ne sont pas aussi claires qu'Apache 2.0.
• Moins adaptée lorsque le créateur veut maintenir l'ouverture du code dérivé.

ISC est assez courante dans les packages et bibliothèques de l'écosystème JavaScript.

5. GNU General Public License ou GPL

GNU n'est pas un nom de licence unique. GNU a plusieurs types de licences, tels que :

• GNU GPL
• GNU LGPL
• GNU AGPL

La GNU General Public License ou GPL est une licence copyleft fort. Cela signifie que lorsque le logiciel GPL est modifié et distribué en tant qu'œuvre dérivée, le code source de cette application doit également être mis à disposition sous une licence GPL compatible.

La GPL n'interdit pas l'usage commercial. Les développeurs peuvent toujours vendre du logiciel sous GPL. Cependant, les destinataires du logiciel doivent recevoir les droits accordés par la GPL, y compris l'accès au code source selon les conditions exigées par la licence.

Avantages de GNU GPL

• Maintient le logiciel et ses dérivés ouverts.
• Les améliorations et développements peuvent retourner à la communauté.
• Empêche les autres de prendre le code et de fermer la source des œuvres dérivées.
• Adaptée pour les projets basés sur la communauté.

Inconvénients de GNU GPL

• Difficile à utiliser dans des produits propriétaires.
• Il faut être prudent lors de la combinaison avec d'autres codes sous licence.
• Moins adaptée pour les entreprises qui veulent garder le code source de leur produit fermé.

Le code interne doit-il être ouvert ?

Pas toujours.

Si une application sous GPL est uniquement utilisée en interne et non distribuée à d'autres, généralement le code source n'a pas automatiquement à être divulgué au public.

L'obligation principale de la GPL survient généralement lorsque le logiciel ou les œuvres dérivées sont distribués.

6. GNU Lesser General Public License ou LGPL

LGPL est une version copyleft plus flexible par rapport à GPL.

Cette licence est généralement utilisée pour les bibliothèques. Les applications propriétaires peuvent utiliser ou lier des bibliothèques LGPL tant qu'elles respectent les termes de la licence. GNU déclare que les bibliothèques LGPL peuvent être liées avec des applications propriétaires, contrairement à la GPL qui a un effet copyleft plus fort sur les œuvres dérivées.

Avantages de GNU LGPL

• Adaptée pour les bibliothèques open source.
• Peut être utilisée par des applications à source fermée.
• Les modifications de la bibliothèque LGPL doivent toujours suivre les règles LGPL.
• Étend l'utilisation de la bibliothèque sans libérer toutes les protections copyleft.

Inconvénients de GNU LGPL

• Les règles d'intégration sont plus complexes que MIT.
• Les méthodes de liaison et de distribution nécessitent attention.
• Les modifications directes de la bibliothèque peuvent déclencher des obligations de partage du code source de la bibliothèque.

Adaptée quand

LGPL est adaptée lorsque vous créez une bibliothèque que vous voulez rendre utilisable à la fois par des applications open source et propriétaires.

7. GNU Affero General Public License ou AGPL

AGPL est une licence copyleft spécialement conçue pour les logiciels utilisés sur un réseau, tels que :

• Applications web.
• Software as a Service ou SaaS.
• API.
• Serveurs.
• Plateformes en ligne.

Avec la GPL classique, une entreprise peut modifier le logiciel et l'exécuter sur un serveur sans distribuer l'application. Dans une telle situation, l'exigence de distribution du code source de la GPL peut ne pas s'appliquer.

AGPL ajoute des obligations liées à l'utilisation du logiciel sur un réseau. Les utilisateurs qui interagissent avec une version modifiée du logiciel via un réseau doivent avoir la possibilité d'accéder au code source correspondant.

Avantages de GNU AGPL

• Adaptée pour maintenir les applications SaaS open source.
• Empêche les autres de modifier une application serveur et de fermer son code.
• Offre une protection copyleft plus forte.

Inconvénients de GNU AGPL

• Difficile à utiliser dans des applications propriétaires.
• Souvent évitée par les entreprises qui ne veulent pas ouvrir le code source du serveur.
• L'intégration nécessite un examen attentif.

8. Mozilla Public License 2.0

La Mozilla Public License ou MPL 2.0 est une licence copyleft au niveau fichier.

Cela signifie que les fichiers déjà sous MPL et ensuite modifiés doivent rester disponibles sous MPL. Cependant, ces fichiers peuvent toujours être combinés avec d'autres fichiers propriétaires au sein d'une même application.

Par conséquent, MPL se situe entre les licences permissives comme MIT et les licences copyleft fortes comme GPL. MPL 2.0 est également une licence open source reconnue par l'Open Source Initiative.

Avantages de MPL 2.0

• Plus flexible que GPL.
• Les fichiers open source modifiés restent ouverts.
• Peut être combinée avec du code source fermé.
• Adaptée pour les projets avec des modules à la fois ouverts et propriétaires.

Inconvénients de MPL 2.0

• Plus complexe que MIT ou BSD.
• Les développeurs doivent savoir quels fichiers sont sous MPL.
• Moins adaptée si vous voulez que l'ensemble de l'application dérivée reste open source.

9. Unlicense

L'Unlicense est utilisée lorsqu'un créateur souhaite libérer du code dans le domaine public dans toute la mesure permise par la loi.

En général, les utilisateurs peuvent :

• Copier le code.
• Modifier le code.
• Vendre le code.
• Distribuer le code.
• Utiliser le code sans attribution.

L'Unlicense impose très peu de conditions aux utilisateurs.

Avantages de Unlicense

• Très libre.
• Presque aucune obligation d'attribution.
• Adaptée pour de petits extraits de code ou du code d'exemple.

Inconvénients de Unlicense

• Le concept de domaine public peut être traité différemment selon les pays.
• Pas idéal pour les projets d'entreprise.
• N'offre pas de protection claire des brevets.
• Les contributeurs en entreprise peuvent préférer MIT ou Apache 2.0.

10. Licence propriétaire

Une licence propriétaire est une licence pour les applications à source fermée. Les droits d'utilisation du logiciel sont entièrement déterminés par le propriétaire de l'application.

Les utilisateurs reçoivent généralement uniquement l'autorisation d'utiliser l'application, pas de posséder ou de modifier le code source.

Exemples :

• Applications par abonnement.
• Logiciels internes d'entreprise.
• Applications de caisse payantes.
• Systèmes de gestion hôtelière.
• Applications spécifiques aux clients.
• Logiciels de bureau payants.

Règles courantes

• Ne peut pas copier l'application.
• Ne peut pas partager les comptes.
• Ne peut pas voir ou modifier le code source.
• Ne peut pas revendre l'application.
• L'utilisation est limitée par appareil, utilisateur, entreprise ou temps.
• Les droits d'utilisation prennent fin lorsque l'abonnement s'arrête.

Adaptée quand

Une licence propriétaire est adaptée lorsque l'application est un produit commercial et que le code source doit rester fermé.

11. Double licence

La double licence est une méthode qui offre deux options de licence pour le même logiciel.

Exemples :

• Gratuit avec GPL pour les projets open source.
• Payant avec une licence commerciale pour les entreprises qui veulent utiliser le logiciel sans suivre la GPL.

Ce modèle permet aux créateurs de logiciels de bénéficier de la communauté open source tout en vendant des licences commerciales.

Cependant, la double licence est plus facile à mettre en œuvre lorsque le droit d'auteur du code source est entièrement détenu par une seule entreprise ou entité. S'il y a de nombreux contributeurs, la gestion des droits de contribution doit être clairement établie.

Peut-on utiliser Creative Commons pour le code source ?

Creative Commons ou CC est plus adapté pour :

• Articles.
• Images.
• Vidéos.
• Musique.
• Documentation.
• Matériel d'apprentissage.
• Designs et contenu créatif.

Creative Commons ne recommande pas d'utiliser les licences CC pour les logiciels et le matériel car il existe des licences logicielles spécifiques qui traitent plus adéquatement des questions telles que le code source, la distribution et la modification.

Dans un projet d'application unique, vous pouvez utiliser :

• MIT, Apache ou GPL pour le code source.
• Creative Commons pour la documentation, les images ou d'autres matériels.

Assurez-vous que chaque partie est expliquée séparément pour éviter de confondre les utilisateurs.

Différences entre licence permissive et copyleft

Aspect	Licence Permissive	Licence Copyleft
Exemples	MIT, Apache 2.0, BSD, ISC	GPL, AGPL
Usage commercial	Autorisé	Autorisé
Modification du code	Autorisée	Autorisée
Peut devenir à source fermée	Généralement autorisé	Généralement non pour les œuvres dérivées
Doit partager les changements	Non	Oui sous certaines conditions
Niveau de restriction	Plus simple	Plus strict
Adapté pour les entreprises	Très adapté	Dépend du modèle économique
Adapté pour la communauté open source	Adapté	Très adapté
Protection de l'ouverture du code	Faible	Élevée

Quelle licence choisir ?

Utilisez MIT quand

• Vous voulez une licence simple.
• Vous voulez que le code soit utilisé aussi largement que possible.
• Vous ne craignez pas que le code soit utilisé dans des applications à source fermée.
• Vous créez une bibliothèque ou un projet personnel.

Utilisez Apache 2.0 quand

• Vous voulez la liberté de MIT.
• Vous avez besoin de dispositions sur les brevets plus claires.
• Vous créez un projet d'entreprise.
• Vous prévoyez d'accepter de nombreuses contributions.

Utilisez BSD quand

• Vous voulez une licence permissive simple.
• Vous créez un logiciel système ou une bibliothèque.
• Vous ne voulez pas que le nom du créateur soit utilisé pour promouvoir des produits dérivés.

Utilisez GPL quand

• Vous voulez que les applications dérivées restent open source.
• Vous ne voulez pas que des entreprises prennent le code et ferment sa source.
• Vous créez un projet communautaire.

Utilisez LGPL quand

• Vous créez une bibliothèque.
• Vous voulez que la bibliothèque soit utilisable par des applications propriétaires.
• Vous voulez que les modifications de la bibliothèque restent ouvertes.

Utilisez AGPL quand

• Vous créez une application SaaS ou serveur.
• Vous voulez que les changements utilisés sur un réseau soient partagés.
• Vous ne voulez pas que des entreprises exécutent des versions modifiées en privé sur leurs serveurs.

Utilisez MPL 2.0 quand

• Vous voulez qu'une partie du code reste ouverte.
• Vous voulez toujours combiner du code avec des modules propriétaires.
• Vous avez besoin d'un juste milieu entre MIT et GPL.

Utilisez une licence propriétaire quand

• Le code source ne peut pas être ouvert.
• L'application est faite à des fins commerciales.
• Vous voulez restreindre l'utilisation du logiciel.
• L'application est vendue via un système de licence ou d'abonnement.

Exemple d'application de licence sur GitHub

Typiquement, le texte de licence est stocké dans le fichier suivant :

LICENSE

ou :

LICENSE.md

Ce fichier est placé dans le dossier principal ou racine du dépôt. GitHub recommande également d'inclure le fichier de licence directement dans le dépôt afin qu'il soit disponible lorsque le projet est cloné, téléchargé ou distribué.

Exemple de structure de projet :

app-name/
├── app/
├── public/
├── src/
├── README.md
├── LICENSE
└── package.json

Des informations brèves peuvent également être ajoutées dans README.md :

## License

This project is licensed under the MIT License.
See the LICENSE file for more information.

Éléments à vérifier avant de choisir une licence

Avant de décider d'une licence, tenez compte des points suivants :

1. L'application peut-elle être utilisée commercialement ?
2. D'autres peuvent-ils modifier le code source ?
3. Les modifications doivent-elles être partagées ?
4. Les œuvres dérivées peuvent-elles être à source fermée ?
5. L'application sera-t-elle utilisée comme SaaS ?
6. Le projet utilise-t-il des bibliothèques tierces ?
7. Les licences de chaque dépendance sont-elles compatibles ?
8. Y a-t-il du code provenant d'autres contributeurs ?
9. Une protection des brevets est-elle nécessaire ?
10. L'application sera-t-elle vendue à des clients ?

Ne choisissez pas une licence simplement parce qu'elle est populaire. Choisissez une licence en fonction des objectifs du projet et de la manière dont l'application sera utilisée.

Conclusion

Chaque licence logicielle offre des droits et obligations différents.

MIT, BSD et ISC conviennent aux projets qui souhaitent donner de larges libertés aux utilisateurs. Apache 2.0 offre une liberté similaire avec des dispositions sur les brevets plus claires.

GPL est adaptée pour maintenir les applications dérivées open source. LGPL est plus appropriée pour les bibliothèques, tandis qu'AGPL offre une protection supplémentaire pour les applications web, serveurs et SaaS.

MPL 2.0 peut être un compromis car elle n'exige que certains fichiers restent ouverts. Pendant ce temps, une licence propriétaire est plus adaptée aux applications commerciales dont le code source doit rester fermé.

Le choix de la licence doit être fait tôt dans le développement. Outre la protection du créateur de l'application, une licence claire aide également les utilisateurs et les contributeurs à comprendre ce qui est autorisé ou non.

Remarque : Cet article fournit une explication générale et n'est pas un avis juridique. Pour les applications commerciales à grande échelle, l'utilisation intensive de dépendances ou les projets avec de nombreux contributeurs, consultez une personne compétente en droit de la propriété intellectuelle concernant le choix de la licence.