Examiner les implications et les évaluations des licences

  • 9 minutes

Comprendre les termes du contrat de licence n’est que la première étape : les organisations doivent évaluer la façon dont les licences affectent leurs modèles métier, pratiques de développement et stratégies de distribution de produits spécifiques. Les implications de licence déterminent si les composants open source conviennent pour des cas d’usage particuliers et quelles obligations les organisations doivent remplir.

Implications de licence pour les logiciels commerciaux

Différents types de licences ont des implications radicalement différentes pour le développement de logiciels commerciaux :

Implications de licence permissive

Logiciels utilisant des composants sous licence permissive (MIT, Apache 2.0, BSD) :

Restrictions minimales :

  • Distribution propriétaire : Peut incorporer des composants dans des logiciels propriétaires sans ouvrir votre code.
  • Produits commerciaux : Peut construire et vendre des produits commerciaux intégrant des composants permissifs sous licence.
  • Distribution fermée : Aucune exigence de fournir du code source aux clients.
  • Sous-licence : Peut généralement distribuer sous vos propres termes de licence.

Obligation principale :

  • Attribution : Doit conserver les mentions de droits d'auteur et le texte de licence, ce qui est généralement satisfait par l'inclusion de ces mentions dans la documentation, les boîtes de dialogue "À propos" ou les fichiers d'agrégation de licences.

Considérations relatives aux brevets :

  • MIT et BSD : N’incluez pas d’octrois de brevets explicites, ce qui crée une ambiguïté potentielle au sujet des droits de brevet.
  • Apache 2.0 : Inclut l’octroi explicite de brevets, offrant une protection plus claire et un arrêt défensif pour les litiges de brevet.

Implications commerciales :

  • Choix sûr : Les licences permissives présentent un risque minimal pour les produits commerciaux.
  • Conformité simple : Les exigences d’attribution sont simples à remplir.
  • Flexibilité maximale : Activez n’importe quel modèle d’entreprise, y compris les ventes de logiciels propriétaires.

Implications d'une licence copyleft faible

Logiciels utilisant des composants à faible copyleft (LGPL, MPL) :

L’utilisation de la bibliothèque est autorisée :

  • Applications propriétaires : Peuvent utiliser des bibliothèques copyleft faibles dans des applications propriétaires.
  • Liaison autorisée : Peut lier du code propriétaire avec des bibliothèques copyleft faibles (en particulier par le biais d’une liaison dynamique).
  • Aucune copie complète : l’utilisation de bibliothèques ne déclenche pas l’exigence d’open source pour l’ensemble de l’application.

Exigences de modification :

  • Les modifications de bibliothèque doivent être partagées : Si vous modifiez le composant copyleft faible lui-même, ces modifications doivent être open source.
  • Suivi au niveau du fichier (MPL) : Pour MPL, les exigences s’appliquent au niveau du fichier, ce qui rend les limites plus claires.
  • Travaux dérivés : La création de travaux dérivés de la bibliothèque déclenche des exigences open source.

Considérations relatives à la conformité :

  • Provision de code source : doit fournir du code source pour la bibliothèque copyleft faible (y compris les modifications).
  • Conservation des licences : Doit conserver les termes du contrat de licence pour la bibliothèque.
  • Séparation claire : Conservez des limites claires entre le code de bibliothèque et le code propriétaire.

Implications commerciales :

  • Généralement acceptable : La plupart des entreprises peuvent utiliser des bibliothèques à faible copyleft dans des produits propriétaires.
  • Charge de modification : La modification des bibliothèques crée des obligations de conformité en cours.
  • Problèmes de liaison statique : La liaison statique peut créer des exigences plus strictes ; préférez la liaison dynamique.

Implications importantes de la licence copyleft

Logiciels utilisant des composants copyleft forts (PG, AGPL) :

Propagation de copyleft :

  • Travaux dérivés : La création de travaux dérivés ou la combinaison de code avec des logiciels sous licence GPL déclenche des exigences de copyleft.
  • Application entière : La licence GPL s'applique généralement à l'ensemble de l'application, et pas seulement au composant sous licence GPL.
  • Exigence du code source : Doit fournir du code source complet lors de la distribution de fichiers binaires.
  • Même licence : Les œuvres dérivées doivent être distribuées sous GPL.

Déclencheurs de distribution :

  • Distribution binaire : La distribution de fichiers binaires exécutables nécessite la fourniture de code source.
  • Utilisation du réseau (AGPL) : Pour AGPL, il suffit de rendre les logiciels disponibles sur un réseau déclenche des exigences.
  • Utilisation interne : L’utilisation du logiciel DEPG en interne sans distribution ne déclenche pas les exigences.

Problèmes de liaison :

  • Liaison statique : Crée les travaux dérivés nécessitant clairement la conformité à la GPL.
  • Liaison dynamique : L’interprétation juridique varie : certains considèrent qu’il est sûr, d’autres croient qu’il crée des travaux dérivés.
  • Séparation des processus : L’exécution d’un logicielPG en tant que processus distinct (microservices) peut éviter l’état de travail dérivé.

Implications commerciales :

  • Incompatible avec les logiciels propriétaires : Impossible d’incorporer des composants DEPG dans des logiciels propriétaires que vous distribuez.
  • Produits open source : Vous pouvez utiliser la GPL pour les produits que vous souhaitez publier en open source.
  • Exception SaaS : La GPL v2 et v3 ne nécessitent pas de divulgation du code source pour les offres SaaS (l'AGPL le nécessite).
  • Risque élevé : LAPG présente un risque important pour les logiciels propriétaires commerciaux.

Évaluations des risques de licence

Les organisations évaluent généralement les licences en fonction du risque qu’elles présentent pour le développement de logiciels commerciaux :

Framework d’évaluation des risques

Faible risque (vert) :

  • Licences: MIT, BSD, Apache 2.0, ISC, d’autres licences permissives.
  • Caractéristiques: Restrictions minimales, principalement les exigences d’attribution.
  • Cas d’usage : Sécurisé pour toute utilisation commerciale, y compris les logiciels propriétaires.
  • Charge de conformité : Faible , principalement en conservant les avis d’attribution.

Risque moyen (jaune) :

  • Licences: LGPL, MPL, EPL, autres licences copyleft faibles.
  • Caractéristiques: Autorisez l’utilisation dans des logiciels propriétaires avec des restrictions sur les modifications.
  • Cas d’usage : Acceptable pour l’utilisation de bibliothèques non modifiées ; attention requise lors de la modification.
  • Charge de conformité : Modéré : doit suivre la source de la bibliothèque et la fournir à la demande.

Risque élevé (rouge) :

  • Licences: GPL v2, GPL v3, AGPL, autres licences copyleft fortes.
  • Caractéristiques: Exiger des travaux dérivés d’approvisionnement ouvert et des applications combinées.
  • Cas d’usage : Incompatible avec la distribution de logiciels propriétaires ; acceptable pour les projets open source.
  • Charge de conformité : Élevé : doit fournir du code source complet pour l’ensemble de l’application.

Risque inconnu (Orange) :

  • Licences: Licences personnalisées, licences non claires, informations de licence manquantes, licences obsolètes.
  • Caractéristiques: Termes peu clairs, compatibilité incertain, examen juridique requis.
  • Cas d’usage : Évitez jusqu’à ce que l’examen juridique clarifie les termes et les implications.
  • Charge de conformité : Inconnu jusqu’à ce que les termes du contrat de licence soient précisés.

Facteurs affectant l’évaluation des risques

Modèle métier :

  • Produits open source : LAPG est un risque acceptable.
  • Logiciels propriétaires : la GPL est un risque inacceptable.
  • Offres SaaS : GPL v2/v3 acceptable, AGPL inacceptable.
  • Outils internes : Toutes les licences sont généralement acceptables, car aucune distribution n’est possible.

Méthode de distribution :

  • Distribution binaire : Déclenche les exigences GPL.
  • Déploiement SaaS : Déclenche les exigences AGPL.
  • Utilisation interne uniquement : Ne déclenche pas la plupart des exigences.
  • Provisionnement de bibliothèque : Déclenche les exigences LGPL/MPL.

Extension de modification :

  • Composants non modifiés : Réduire le fardeau de conformité.
  • Composants modifiés : augmente les obligations, en particulier pour le copyleft.
  • Intégration approfondie : Rend la conformité plus complexe.

Environnement juridique :

  • Différences entre les juridictions : L’interprétation des licences varie selon le pays/la région.
  • Historique de l’application : Certaines licences ont un précédent plus fort en matière d’application.
  • Considérations relatives aux brevets : Les clauses de brevet interagissent avec les stratégies de brevet organisationnelles.

Considérations relatives à la propriété intellectuelle

Les choix de licence affectent la propriété intellectuelle organisationnelle :

Protection IP propriétaire

Licences permissives :

  • Adresse IP conservée : Votre code propriétaire reste propriétaire.
  • Secrets commerciaux protégés : Il n’est pas nécessaire de divulguer les détails de l’implémentation.
  • Avantage concurrentiel maintenu : N’avez pas besoin de partager des innovations avec les concurrents.

Licences copyleft fortes :

  • Divulgation IP requise : LAPG nécessite des travaux dérivés open-sourcing, susceptibles d’exposer des algorithmes propriétaires, une logique métier et des innovations.
  • Secrets commerciaux perdus : La divulgation de code source élimine la protection des secrets commerciaux.
  • Avantage concurrentiel réduit : Les concurrents peuvent utiliser vos innovations.

Considérations relatives aux brevets

Octroi de brevets :

  • Apache 2.0 : Inclut l’octroi explicite de brevets qui fournit des droits clairs et une résiliation défensive.
  • GPL v3 : Inclut les dispositions relatives à l’octroi de brevets et à l’anti-tivoisation.
  • MIT/BSD : Aucune disposition explicite sur les brevets, ce qui crée une ambiguïté potentielle.

Arrêt défensif de brevet :

  • Apache 2.0 etPG v3 : Les octrois de brevets se terminent si le titulaire poursuit les contributeurs pour violation des brevets.
  • Implication stratégique : Les organisations disposant de stratégies de brevet agressives peuvent faire face à des complications.

Pools de brevets :

  • Certaines licences s’intègrent aux pools de brevets : Les licences peuvent interagir avec les contrats de brevet du secteur.

Implémentation de la conformité

L’implémentation réussie de logiciels open source nécessite des processus de conformité systématiques :

Inventaire des dépendances

Suivi complet :

  • Facture de matériaux : Conservez l’inventaire complet de tous les composants open source.
  • Dépendances transitives : Suivez non seulement les dépendances directes, mais les dépendances des dépendances.
  • Suivi des versions : Enregistrez des versions spécifiques, car les licences changent parfois entre les versions.
  • Surveillance des mises à jour : Surveillez de manière continue les mises à jour des dépendances et de leurs licences.

Outils automatisés :

  • Gestionnaires de packages : npm, pip, Maven effectue automatiquement le suivi des dépendances directes.
  • Outils SBOM : Les outils de liste de matériaux logiciels génèrent des inventaires de dépendances complets.
  • Scanneurs de licences : Les outils comme FOSSA, WhiteSource, Black Duck identifient les licences entre les arborescences de dépendances.

Vérification de compatibilité des licences

Vérification de compatibilité :

  • Analyse automatisée : Les outils identifient automatiquement les incompatibilités de licence.
  • Révision légale : Les cas complexes nécessitent une expertise juridique pour évaluer la compatibilité.
  • Flux de travail d’approbation : Établissez des processus pour examiner les nouvelles dépendances avant l’utilisation.

Incompatibilités courantes :

  • GNU + Apache 2.0 (GPL v2) : Incompatible : impossible de combiner.
  • PG + Propriétaire : Incompatible pour les logiciels distribués.
  • Plusieurs licences copyleft : Généralement incompatibles entre elles.

Conformité des attributions

Répondre aux exigences d’attribution :

  • Agrégation de licences : Collectez tous les textes de licence dans un fichier unique (souvent LICENSES.txt ou THIRD_PARTY_NOTICES).
  • À propos des dialogues : Incluez des attributions dans l’application À propos des dialogues ou des paramètres.
  • Documentation: Incluez les informations de licence dans la documentation du produit.
  • Génération automatisée : Utilisez des outils pour générer automatiquement des fichiers d’attribution à partir de données de dépendance.

Approvisionnement de code source

Pour les licences copyleft :

  • Accès source : Fournir le code source complet pour les composants sous GPL et leurs dérivés.
  • Même moyen : Historiquement nécessaire pour fournir la source sur le même support que les fichiers binaires ; Téléchargement Internet maintenant acceptable.
  • Offre écrite : Peut proposer de fournir du code source plutôt que de le regrouper.
  • Instructions de compilation : Incluez des instructions de génération pour permettre aux utilisateurs de reconstruire à partir de la source.

Sécurité de la chaîne d’approvisionnement logicielle

La conformité et la sécurité des licences sont des préoccupations interconnectées :

Gestion des vulnérabilités

La sécurité est égale au composant le plus faible :

  • Dépendance de chaîne : La sécurité des applications dépend de chaque composant de l’arborescence des dépendances.
  • Propagation des vulnérabilités : La vulnérabilité dans n’importe quelle dépendance affecte toutes les applications qui l’utilisent.
  • Urgence de mise à jour : Les vulnérabilités de sécurité nécessitent des mises à jour rapides sur toutes les applications affectées.

Analyse des vulnérabilités :

  • Détection automatisée : Outils tels que Snyk, Dependabot, WhiteSource analysent les dépendances pour détecter les vulnérabilités connues.
  • Surveillance CVE : Suivez les identificateurs des vulnérabilités et des expositions courantes pour les dépendances.
  • Scoring CVSS : Utilisez le système de scoring des vulnérabilités commun pour hiérarchiser la correction.
  • Réponse rapide : Établissez des processus pour mettre à jour rapidement les dépendances lorsque des vulnérabilités critiques sont divulguées.

Attaques de chaîne d’approvisionnement

Atténuation des risques :

  • Vérification du package : vérifiez les signatures et les sommes de contrôle du package.
  • Réputation de la source : Préférez les packages avec une maintenance active, des bases d’utilisateurs volumineuses et des mainteneurs réputés.
  • Registres privés : Mettre en miroir des packages publics dans des registres privés pour contrôler ce que les développeurs utilisent.
  • Épinglage des dépendances : verrouillez des versions spécifiques pour empêcher les mises à jour automatiques des versions compromises.

Évaluation de la qualité des composants

Indicateurs de qualité :

  • Maintenance active : Les mises à jour régulières indiquent le projet géré.
  • Taille de la communauté : Les grandes collectivités offrent une meilleure durabilité.
  • Qualité de la documentation : Une bonne documentation suggère une maintenance professionnelle.
  • Couverture des tests : Les tests automatisés indiquent le focus de qualité.
  • Pratiques de sécurité : Les processus de divulgation responsable et les avis de sécurité démontrent l’engagement de sécurité.

Stratégies organisationnelles

Une gestion open source efficace nécessite des stratégies organisationnelles claires :

Flux de travail d’approbation

Évaluation préalable à l’utilisation :

  • Révision de sécurité : Recherchez les vulnérabilités connues avant l’approbation.
  • Révision de licence : Vérifiez la compatibilité des licences avec l’utilisation prévue.
  • Évaluation de la qualité : Évaluez la qualité du code, l’état de maintenance et la santé de la communauté.
  • Analyse alternative : Déterminez si des alternatives approuvées existent.

Listes de packages approuvées :

  • Composants pré-vérifiés : Conservez les listes de packages approuvés pour les besoins courants.
  • Adoption plus rapide : Les développeurs peuvent utiliser immédiatement des packages approuvés.
  • Réévaluation périodique : Passez régulièrement en revue les packages approuvés pour connaître l’état de sécurité et de maintenance.

Éducation pour les développeurs

Programmes de formation :

  • Sensibilisation aux licences : Informez les développeurs sur les types de licences et les implications.
  • Pratiques de sécurité : Effectuez l’apprentissage sur l’évaluation de la sécurité des composants.
  • Processus de conformité : Expliquez comment demander l’approbation pour les nouvelles dépendances.
  • Sensibilisation aux risques : Aidez les développeurs à comprendre les préoccupations organisationnelles.

Surveillance continue

Conformité en cours :

  • Mises à jour des dépendances : surveillez les nouvelles versions et les correctifs de sécurité.
  • Modifications de licence : Suivez le moment où les projets modifient les licences.
  • Divulgation des vulnérabilités : Abonnez-vous aux avis de sécurité pour les dépendances.
  • Audits de conformité : Auditez régulièrement les applications pour la conformité des licences.

Comprendre les implications de licence et implémenter des processus de conformité systématiques permet aux organisations d’exploiter les avantages open source tout en gérant efficacement les risques. L’unité suivante fournit un résumé des concepts clés abordés dans ce module.