Skip to main content

Lors du changement de licence sur OneGeo Suite, il est important d’examiner la compatibilité des dépendances avec Affero GPL. Au vu des implications qui en découlent, est-il surtout possible de vérifier que nos dépendances aient toujours une licence conforme ? 

La compatibilité entre les licences  

La compatibilité de licences inclut deux éléments clé à prendre en compte :  

  • Le projet en lui-même (ex : un module Python, une bibliothèque de fonctions, etc.) ; 
  • Un travail dérivé (ex : un logiciel complet comme FireFox). Les travaux dérivés d’un projet, quant à eux, peuvent être des modifications du code du projet ou des produits intégrant le projet. 

Une compatibilité des licences sera possible lorsque le travail dérivé possède une licence qui n’enfreint pas les règles de la licence du projet. 

Les licences « copyleft » obligent à redistribuer les travaux dérivés sous la même licence (ou une compatible) pour protéger les libertés du code et de l’utilisateur. A contrario, les licences permissives autorisent le changement de licence, et il est également possible de faire un produit propriétaire, en intégrant des composants sous ce type de licence. Par exemple, Sony base son système d’exploitation propriétaire de la Playstation sur FreeBSD, qui est un logiciel libre sous licence FreeBSD.  

Source : https://janelia-flyem.github.io/licenses.html (Creative Commons BY-SA-3.0)  

Dans ce schéma, le code en domaine public est intégrable dans un produit MIT, lui-même dans un produit sous licence BSD, lui-même dans un produit licence Apache 2.0, et ainsi de suite jusqu’à la licence Affero GPL 3. 

Deux catégories supplémentaires sont introduites par ce schéma : 

  • Weakly protective (faiblement protectrice) : elle implique qu’une modification du code doit être sous la même licence (donc rester libre). Néanmoins, l’intégration du projet peut se faire dans un produit sous une autre licence (même propriétaire). 
  • Network Protective (protectrice des utilisateurs réseau) : la licence GPL protège les utilisateurs de la machine. Dans le cadre d’applications client-serveur, la partie serveur protège l’utilisateur du serveur, donc l’administrateur système. Une conformité à la GPL existe dans le cas où l’administrateur système de OneGeo Suite a accès aux sources modifiées du produit, mais pas l’utilisateur de la partie client. Les licences Network Protective permet aussi de protéger la liberté des utilisateurs du client. 

Notez bien les versions des licences : par exemple la licence Apache 2.0 est compatible avec la licence LGPL, alors que la version 1.1 ne l’est pas. 

Pour vous aiguiller, voici quelques incompatibilités à souligner : 

  • Apache 1.1 ou MPL 1.1 (Mozilla Public Licence) ne sont pas compatibles avec les licences GPL, alors qu’une clause explicite de compatibilité existe dans les versions 2.0 de ces mêmes licences ; 
  • CC-BY-3.0 empêche de changer la licence, donc impossible à changer en AGPL. La version 4.0 permet explicitement de changer la licence en GPL 3.0 et donc en AGPL 3.0 ; 
  • Licence originelle BSD : elle forçait à indiquer une notice de copyright dans la documentation du produit final, ce qui peut poser problème quand il y a de nombreux composants avec cette licence dans un produit. 

Vérifier la conformité

En pratique, la conformité de licence peut se vérifier grâce au DevOps.  

Pour illustrer nos projets, essentiellement en Python et Javascript, nous vous présentons deux outils simples qui pourront vous aider. Dans ces exemples, nous nous en servirons en ligne de commande, afin de comparer les licences des dépendances avec une liste validée de licences.  

Vérification des licences en Python  

L’outil « pylic » analyse tous les modules Python installés dans l’environnement virtuel et compare leurs licences avec une section du pyproject.toml. S’il trouve un module avec une licence non validée, il sort en émettant erreur que l’on pourra exploiter dans une CI. 

Commençons par installer le programme :  

$ pip install pylic  

Ensuite, nous indiquons à “pylic” les licences compatibles avec notre logiciel, en lui donnant une liste de licences compatibles AGPL 3.0, dans la section tool.pylic de notre pyproject.toml : 

$ cat << EOF >> pyproject.toml 
[tool.pylic]  
safe_licenses = [  
"Apache Software License", 
"BSD License",  
"BSD",   
"MIT License",  
"MIT",   
"Mozilla Public License 2.0 (MPL 2.0)", 
"GNU Library or Lesser General Public License (LGPL)", 
"GNU Lesser General Public License v3 or later (LGPLv3+)",  
  "Python Software Foundation License",  
"Historical Permission Notice and Disclaimer (HPND)"  
  ]  
EOF  

Vous remarquerez que ces licences ont parfois des noms très similaires. En effet, “pylic”  s’appuie sur le nom déclaré par le mainteneur du module python (dans le setup.cfg/setup.py…) qui n’est pas normalisé. Nous devons déclarer comme « safe » les deux identifiants « MIT » et « MIT License », alors que nous aurions pu utiliser les identifiants de licence SPDX dans la configuration du module Python. 

Revenons à “pylic” et lançons une vérification : 

$ pylic check  
✨ All licenses ok ✨  

Comment peut-on faire en cas de non-conformité ?  

En commentant la licence « Apache Software License » de pyproject.toml, nous obtenons ce message : 

$ pylic check  
Found unsafe licenses: 
  nltk (3.8.1): Apache Software License  
  phonenumbers (8.13.8): Apache Software License  
  importlib-metadata (6.1.0): Apache Software License
  bleach (6.0.0): Apache Software License  
  cryptography (42.0.1): Apache Software License  
  regex (2023.12.25): Apache Software License 
  django-onegeo-suite (1.0.2): Apache Software License 
  requests (2.31.0): Apache Software License  
  packaging (23.2): Apache Software License 
  pyOpenSSL (24.0.0): Apache Software License 
  tzdata (2023.4): Apache Software License  
  elasticsearch (7.17.9): Apache Software License 
  async-timeout (4.0.3): Apache Software License 
  josepy (1.14.0): Apache Software License  
  django-onegeo-rproxy-mapstore2 (1.0.0b2): Apache Software License  

Plutôt simple, non ?  

 

Vérification des licences en Javascript  

De la même façon, on peut vérifier les licences des projets javascript avec license-checker. ilIl n’est toujours pas au courant des licences qui existent donc il faudra construire la liste à la main.  

L’utilisation est plutôt simple :  

$ npx license-checker --onlyAllow "CC-BY-4.0;ISC;Apache-2.0;BSD-3-Clause;Custom: https://github.com/tmcw/jsonlint;BSD-2-Clause;Unlicense;UNLICENSED;BSD;Public Domain;CC0-1.0;MPL-2.0" --production   

Package « @fortawesome/fontawesome-common-types@0.2.36 » is licensed under « MIT » which is not permitted by the –onlyAllow flag. Exiting.  

 On obtient des erreurs pour chaque licence non autorisée.  

L’option « –onlyAllow » permet de lister les licences autorisées séparées par des point virgules « ; ». Tandis que l’option « –production » permet d’écarter les licences des modules de la section « devDependencies » du package.json.  

Pensez aussi à corriger la section « license » du package.json pour ne pas perturber l’outil :  

  "license": "AGPL-3.0-only",  

Je vous conseille aussi d’ajouter un script dans le package.json pour automatiser les vérifications :  

cat package.json  
{  
[...]  
  "scripts": { 
[...]    "lint": "vue-cli-service lint",  
    "license-checker": "license-checker --onlyAllow \"MIT;CC-BY-4.0;ISC;Apache-2.0;BSD-3-Clause;Custom: https://github.com/tmcw/jsonlint;BSD-2-Clause;Unlicense;UNLICENSED;BSD;Public Domain;CC0-1.0;MPL-2.0\" --production"
  },  

On peut ainsi lancer simplement :  

$ npm run  license-checker  

 

Conclusion  

Il existe probablement des outils plus sophistiqués pour vérifier la compatibilité des licences des bibliothèque externes utilisées par votre projet, notamment en utilisant la matrice de compatibilité des licences de l’OSADL : https://www.osadl.org/html/CompatMatrix.html  

Mais pour une utilisation légère et rapide dans une CI, ces deux outils feront l’affaire, en investissant néanmoins un peu de temps pour vérifier les nouvelles licences qui peuvent apparaître pendant la vie de votre projet.    

Sources :  

https://janelia-flyem.github.io/licenses.html : image compatibilité  

https://www.gnu.org/licenses/license-list.html : informations sur les compatibilités avec la GPL  

https://www.apache.org/licenses/GPL-compatibility.html : compatibilité Apache 2.0 et GPL  

https://medium.com/@iharmandeep/easily-check-licenses-of-your-npm-dependencies-in-your-ci-pipeline-9102150d6907 : utilisation de license-checker  

 

Rédacteur : Sébastien DA ROCHA 

 

Leave a Reply