L UTILISATION DE COMPOSANTS OPEN SOURCE L INNOVATION ET LA COMPLIANCE JURIDIQUE Jérôme ARPIN-PONT General Counsel Qosmos Jonathan Rofé Avocat Counsel DLA Piper Armand Sylla Directeur des ventes France Black Duck Software
AGENDA Introduction sur les tendances actuelles et futures de l Open Source (Black Duck) Présentation des licences OSS les plus populaires (DLA Piper) Comment Qosmos a développé et implémenté sa politique d utilisation OSS (Qosmos) Réutilisation des composants open source au sein de logiciels propriétaires (Qosmos) Comment développer une stratégie proactive de compliance et de gouvernance (Black Duck) 2
SOFTWARE IS EATING THE WORLD. MARC ANDREESSEN - 2012 3
OPEN SOURCE TRENDS Black Duck KnowledgeBase 2,300+ licenses 4B+ files/1,000,000 + unique projects 4 10+ Million staff years >7,500+ sites Nearly 55,000 security vulnerabilities
THE GOOD NEWS / BAD NEWS Average Enterprise uses 29% open source code. 50% of companies will face challenges due to lack of FOSS policy and management 5.
REAL WORLD EXAMPLE Over 80% of the software in our handsets is open source Carl-Eric Mols, Head of OSS, Sony Mobile Communications 6
MULTI-SOURCE DEVELOPMENT; CODE ENTERS A CODE BASE UNCHECKED Commercial 3 rd Party Code Purchasing Licensing? Security? Quality? Support? Open Source Code Base SECURITY RISK Which components have vulnerabilities and what are they LEGAL RISK Which licenses are used and do they match anticipated use of the code OPERATIONAL RISK Which versions of code are being used, and how old are they 7
OPEN SOURCE ADOPTION IN ENTERPRISE ORGANIZATIONS A typical Enterprise IT organization has thousands of applications and uses hundreds of open source components Some apps Up to 90+% Open Source ENTERPRISE AVERAGE 30% 8
BLACK DUCK S EXPERIENCE ANALYZING CODE 99% of code audits find open source. 95% of audits find unknown open source 75% of audits contain unknown licenses. 50% of code audits contain GPL. Audits on average contain 33% open source. 5% of M&A deals never materialize due to our findings 9
DLA PIPER Examen des licences les plus populaires 10
LICENCES PROPRIÉTAIRES LES POINTS PRINCIPAUX Restrictions des droits d utilisation Modifications prohibées Code source inaccessible Restrictions de distribution Limitation de garantie et autre protections Redevances à payer 11
LES LICENCES OSS PRINCIPES DE BASE Il s'agit d une licence les droits de propriété restent dans les mains du concédant! La portée des droits n est pas limitée: Droit d utiliser à n importe quelle fin Aucune restriction en terme de durée Pas de restriction en nombre d utilisateurs, etc. Droit de modifier le logiciel Droit de redistribuer le logiciel à n importe qui En général, aucune garantie accordée et en particulier, aucune garantie de non-contrefaçon En général, pas de redevances à payer au concédant 12
LICENCES OSS: PERMISSIVE V. RESTRICTIVE 13
LICENCES PERMISSIVES QUELQUES ASPECTS CLÉS Restrictions minimales d utilisation Possibilité de combiner avec logiciel propriétaire Modifications peuvent rester propriétaires Distribution possible sous d autre licences Possibilité de distribuer seulement le code objet Mais pas l'équivalent du domaine public! 14
LICENCES RESTRICTIVES QUELQUES ASPECTS CLÉS Sans restrictions sur l utilisation personnelle Sans obligation de redistribuer Obligation de redistribuer sous certains termes Code source doit être rendu disponible Effet «viral» sur logiciel propriétaire Des stipulations plus complexes 15
LE SPECTRE DES LICENCES OSS GPL LGPL Mozilla MIT Apache AGPL BSD Copyleft fort Copyleft faible Licences permissives Restrictive Permissive 16
EXEMPLES CONCRETS 17
LICENCES PERMISSIVES: LA LICENCE DE BIÈRE <phk@freebsd.org> wrote this file. As long as you retain this notice you can do whatever you want with this stuff. If we meet some day, and you think this stuff is worth it, you can buy me a beer in return. 18
LICENCES PERMISSIVES : LICENCE MIT Permission is hereby granted, free of charge, to any person obtaining a copy of this 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 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 IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE Des droits très larges concernant l utilisation, modification, etc. Obligation d inclure des avis de copyright, etc. Exclusion de responsabilité de l auteur Note: Les conditions de licence ont été éditées à ces fins 19
LICENCES PERMISSIVES: LA LICENCE APACHE Each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, nocharge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form. You may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License. Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof Droits très larges sans obligation de distribuer le code source Exclusion explicite du copyleft Approche différente à la question de «viralité» Avis: Les conditions de licence ont été éditées à ces fins 20
LICENCES RESTRICTIVES: GPL V2.0: OBLIGATIONS COPYLEFT Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted You may copy and distribute verbatim copies of the Program's source code as you receive it provided that you keep intact all the notices that refer to this License You may modify your copy of the Program, thus forming a work based on the Program, and copy and distribute such modifications or work, provided that you also meet all of these conditions: b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License. Sans restriction de l utilisation personnelle du logiciel Obligation de distribuer des copies exactes sous les termes de la GPL Droits de modifier le logiciel Obligation de distribuer les modifications sous les termes de la GPL Avis: Les conditions de licence ont été éditées à ces fins 21
LICENCES RESTRICTIVES: GPL V2.0: MISE À DISPOSITION DU CODE SOURCE You may copy and distribute the Program (or a work based on it) in object code or executable form under the terms of provided that you also do one of the following: a) accompany it with the complete corresponding machine-readable source code which must be distributed under the terms of [Sections 1 and 2 above] on a medium customarily used for software interchange; or b) accompany it with a written offer to give any third party, for a charge no more than your cost of performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of [Sections 1 and 2 above] on a medium customarily used for software interchange Applicable au logiciel original et toutes ses modifications Mise à disposition d une copie du code source Offre écrite de fournir le code source à des frais minimes Avis: Les conditions de licence ont été éditées à ces fins 22
GPL V2.0: L EFFET "VIRAL Les obligations précédentes s appliquent au logiciel» qui est basé entièrement ou en partie sur ce logiciel ou sur un de ses éléments» Qu est-ce que cela signifie exactement? We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program. 23
GPL ET LA QUESTION DU SAAS La distribution de logiciel en mode SaaS exige-t-elle le respect des obligations de la GPL? GPL v2.0 GPL v3.0 Affero GPL v3.0 "Distribution" n est pas défini dans la GPL v2.0. Une entreprise exécute une version modifiée d un programme du type GPL sur son site web. Est-ce qu elle est obligée de publier le code source modifié? Le GPL permet de créer et d utiliser une version modifiée sans jamais la distribuer à des tiers. L action de cette entreprise en est une hypothèse, qui a priori n exige pas la mise à disposition du code source. «Transmettre» un exemplaire veut dire toute forme de propagation qui permet aux tiers de recevoir ou de faire des copies. La simple interaction avec un utilisateur à travers un réseau d ordinateur sans transmission d une copie ne représente pas une «transmission» d un exemplaire dans ce sens. En dépit de toutes les autres stipulations de cette licence, si vous modifiez un programme, l opportunité de recevoir le code source de cette version modifiée doit être offerte à tout utilisateur, qui interagit avec ce programme à travers un réseau d ordinateur. 24
LES POINTS IMPORTANTS DANS UNE POLITIQUE OSS Quelle est notre approche concernant l'oss? Relation avec les logiciels propriétaires Des règles différentes pour des licences différentes? Notre attitude au niveau des contributions Nomination d un responsable de compliance OSS Reporting et registres de contrôle 25
QOSMOS Comment Qosmos a développé et implémenté sa politique d utilisation OSS 26
INTRODUCTION ÉLÉMENTS DE CONTEXTE Qosmos édite des logiciels d analyse du trafic réseau Technologie dite d «intelligence réseau», qui apporte une visibilité sur les informations circulant sur les réseaux Utilisée par des équipementiers, des éditeurs et des intégrateurs informatiques, au sein de leurs produits Produits d optimisation des réseaux, de qualité de service informatique, de cyber sécurité Technologie commercialisée sous forme de briques technologiques Composants logiciels fournis sous licence à entreprises et des partenaires L intègrent au sein des applications et produits qu ils développent et commercialisent Commercialisation en mode "OEM" Pas de contrat entre Qosmos et l utilisateur final L utilisateur final acquiert un produit qui intègre la brique logicielle de Qosmos Cette brique n est pas accessible à cet utilisateur final qui n a souvent même pas connaissance de sa présence dans le produit qu il utilise 27
MISE EN PLACE D UNE POLITIQUE OSS Pourquoi mettre en place une politique de gestion de l open source? Même un éditeur de logiciels propriétaires ne peut ignorer le sujet Dans un projet propriétaire, open source peut être présent même à la marge Tendance des ingénieurs de développement à ne pas "réinventer la roue" Risques associés à l incorporation de composants open source Risque de contamination du code propriétaire par le composant libre Quelle type de politique mettre en place? Option 1 : objectif 100% propriétaire Interdiction totale d incorporer des composants sous licence libre Objectif difficile à atteindre Option 2 : tolérance totale à l open source Visibilité sur l open source utilisé Mais pas de restriction sur l utilisation de open source Respect des licences? Option 3 : tolérance sélective à l open source Appréciation au cas par cas, selon les composants et les licences 28
MODALITÉS D AJOUT D UN COMPOSANT OSS (1/2) Avant l intégration d un nouveau composant open source Transmission d informations par l équipe de développement au service juridique Informations sur le composant concerné Nom du composant, nom du ou des auteurs Source (site internet ) Licence Informations sur l utilisation envisagée Utilisation au sein de quel logiciel? Dans quel but? De quelle portion? Sous quelle forme? 29
MODALITÉS D AJOUT D UN COMPOSANT OSS (2/2) Procédure d approbation par le service juridique Analyse de la cohérence des informations relatives au composant Fiabilité de la source Source de 1 ère main ou de 2 nde main? Fiabilité de la licence Comparaison fichier texte "licence" et en-têtes de fichiers source Analyse de la compatibilité de la licence libre Compatibilité entre les obligations de la licence libre et le logiciel propriétaire Risque de contamination / de mise à disposition du code source propriétaire Conflit avec les conditions de commercialisation du logiciel propriétaire (exemple : clause de publicité) Décision d approbation ou de rejet du composant open source L approbation autorise l intégration du composant au sein du logiciel propriétaire* Peut être conditionnelle (exemple : uniquement sous forme de binaire distinct) En cas de rejet l intégration est impossible Recherche d un autre composant open source Ou développement en interne de la fonctionnalité 30
SUIVI DES COMPOSANTS OSS UTILISÉS Après l intégration d un composant open source 31 Maintien d une base de données de composants open source Liste des composants, des licences et des obligations associées Inclusion de ces informations en annexe de la documentation produit Maintien d un "dépôt" interne d archives des composants open source Moyen de preuve Permet de se prémunir contre la disparition du composant Permet de se prémunir contre le changement de licence du composant Utilisation d un outil d audit de code open source Corrélation entre les résultats de l inspection manuelle et les résultats de l outil Impossibilité de se fier totalement à une procédure purement déclarative Vérification du respect des obligations imposées par les licences libres utilisées Redistribution du composant open source en association avec le texte de la licence Mise à disposition du code source du composant open source Obligations plus originales : offrir une pizza ou une bière au développeur,,,
QOSMOS Réutilisation des composants open source au sein de logiciels propriétaires 32
OSS ET CONTRATS CLIENTS (1/2) Dans la relation contractuelle avec les clients Le client n est pas l utilisateur final, mais intervient comme re-distributeur Redistribution au sein de son propre produit de la brique technologique Qosmos, donc des composants open source Nécessité de respecter, à son tour, les obligations des différentes licences libres Nécessité d informer son propre client (utilisateur final) Redistribution sans visibilité sur le contenu (composants inclus) Obligation d information de la part de Qosmos sur les composants, les licences et les obligations Information à mettre à jour suite à chaque ajout / modification de composant open source 33
OSS ET CONTRATS CLIENTS (2/2) Le client souscrit une licence sur un logiciel propriétaire Les composants open source ne sont qu accessoires, marginaux Ne sont généralement pas visibles (incorporés dans un binaire unique) Clauses contractuelles de garantie demandées / imposées par les clients Évolution d une simple obligation d information Vers une obligation de défense et d indemnisation Voire une obligation de communication au client du code source propriétaire en cas de litige Droit d audit du code propriétaire par le client Audit comme condition suspensive du contrat de licence Audit ponctuel au cours de la vie du contrat 34
OSS ET CONTRATS FOURNISSEURS Dans les relations contractuelles avec les fournisseurs et sous-traitants Facteur de risque au niveau de la politique open source Produisent du code qui sera redistribué par Qosmos au sein de ses briques technologiques N ont pas nécessairement le même niveau de vigilance et de contrôle de l open source Ne doivent pas mettre à mal l application de la politique open source de Qosmos Le contrôle de l application de la politique open source doit être assuré par Qosmos Interdiction de l ajout d un quelconque composant open source au sein du code livré Sauf approbation préalable de ce composant par Qosmos Même procédure d approbation que pour les développements internes Le code ainsi livré est également soumis à l outil d audit de code open source Clauses contractuelles de garantie similaires à celles liant Qosmos à ses propres clients Défense et indemnisation de Qosmos en cas de litige lié à un composant open source 35
AUTOMATING AND ENABLING OSS USE Black Duck Software 36
WHY DO CUSTOMERS COME TO BLACK DUCK? I want to know what open source I use. I want to know where I use open source. I want to know how often open source is used. I want to increase the security of my open source. I want to know what my legal obligations are. I want to decrease the amount of code we need to maintain. I want to be able to reuse code. I want to participate in the open source ecosystem. 37
BLACK DUCK OSS LOGISTICS OSS Logistics speeds the velocity of development. Jeffery Hammond 38
THE VALUE Black Duck has enabled JPMorgan Chase to discover, identify and govern open source software across our application estate, said Dana Deasy, JPMorgan Chase CIO. The ability to easily assess and manage this footprint across all of the applications in the firm is critical for large enterprises like ours to ensure our code is secure and delivered most effectively. - Dana Deasy, CIO JPMorgan Chase 39
WHAT DO CUSTOMERS SAY ABOUT BLACK DUCK? "Black Duck made dealing with the Heartbleed bug extremely easy. The speed with which we are able to locate vulnerabilities and empower our customers to act with knowledge gives us a competitive advantage. Going forward I m convinced we ll use Black Duck on all products pre-release to head-off any future vulnerability. Global Telecom Provider 40
BLACK DUCK OPEN SOURCE RISK PROFILE In order to take advantage of OS, the first step is understanding the risks of what is already in use within an organization. SECURITY RISK Which components have vulnerabilities and what are they One Component contains at least 1 HIGH RISK vulnerability. Two Components contain at least 1 MED RISK vulnerability. Zero Components contain at least 1 LOW RISK vulnerability. LEGAL RISK Which licenses are used and do they match anticipated use of the code OPERATIONAL RISK Which versions of code are being used, and how old are they 1 HIGH License Risk Component: Reciprocal type licenses which conflict with a distributed proprietary application 2 MED License Risk Components: Weak Reciprocal type licenses which may conflict with a distributed proprietary application 17 No License Risk Components: Permissive type licenses that present no conflicts with a distributed proprietary application 4 Components have a HIGH RISK Version Status: At least 48 months old and at least 10 releases behind. 6 Components have a MED RISK Vers. Status: Either a) at least 24 months old and at least 10 releases behind, or b) at least 48 months old and at least 5 releases behind. 1 Component has a LOW Risk Version Status: Either a) no more than 24 months old and at least 10 releases behind, or b) no more than 48 months old and at least 5 releases behind. 9 Components are OK: Less than 5 releases behind. 41
MERCI BEAUCOUP! Jérôme ARPIN-PONT General Counsel Qosmos Jonathan Rofé Avocat Counsel DLA Piper Armand Sylla Directeur des ventes France Black Duck Software email: Jerome.ARPIN- PONT@qosmos.com email: Jonathan.Rofe@dlapiper.c om email: asylla@blackducksoftware.co m 42 2015 Black Duck Software, Inc, Qosmos 2015 & DLA Piper LLP 2015. All rights reserved