Your SlideShare is downloading. ×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Sept bonnes pratiques à mettre en oeuvre dans la gestion des droits de propriété intellectuelle portant sur un logiciel à l'heure de l'open source

343

Published on

Ce livre blanc liste les bonnes pratiques en matière de gestion de la propriété intellectuelle sur les logiciels comme : réutiliser les composants existants dans la mesure du possible ; suivre et …

Ce livre blanc liste les bonnes pratiques en matière de gestion de la propriété intellectuelle sur les logiciels comme : réutiliser les composants existants dans la mesure du possible ; suivre et contrôler les évolutions des composants internes ; contrôler la réutilisation des composants sensibles ou externes ; vérifier chaque version compilée et chaque release ; vérifier la conformité lors des transitions entre phases du projet ; contrôler la distribution des composants et les contributions en composants ; analyser les composants logiciels avant de les acheter.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
343
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Sept bonnes pratiques à mettre en œuvre dans la gestion des droits de propriété intellectuelle portant sur un logiciel à l’heure de l’Open Source© 2008-2012 Black Duck®, Know Your Code®, Ohloh®, SpikeSource®, Spike® et le logo Black Duck sont des marques déposées par Black Duck Software, Inc. aux Etats Unis et/oudans d’autres pays. Koders™ est une marque déposée par Black Duck Software, Inc. Toutes les autres marques sont les propriétés de leurs titulaires respectifs. Tous Droits Réservés.
  • 2. L’ère de l’open source • Les obligations imposées par les licences open source sont variables et diverses, avec unOAu cours des dix dernières années, une éventail allant de la licence BSD (qui comporteapproche révolutionnaire du développement peu d’obligations) à la licence GPL (qui en comporte beaucoup).logiciel, l’open source, a connu un formidable • Certaines licences open source sont juridiquementessor, qui a largement ouvert les possibilités de complexes, introduisant certaines contraintes dontréutiliser des logiciels existants. Les auteurs de les implications commerciales peuvent ne pas êtrecomposants et d’extraits open source développés évidentes pour un développeur lorsqu’il décide deen externe restent cependant titulaires des réutiliser un composant.droits sur ces derniers, comme les auteurs de • Les licences de certains composantscomposants commerciaux. Si la plupart de ces commerciaux et open source sont incompatibles entre elles.auteurs autorise une utilisation commerciale • L’origine d’un extrait de code donné peut s’avérerde leur code sans paiement d’un prix initial ou difficile à déterminer, rendant ainsi ses conditionsde royalties, beaucoup ont choisi d’opter pour de licence incertaines.d’autres formes de contraintes, en imposant par • Découvrir tardivement dans le développementexemple des clauses d’attribution, des rapports d’un projet la nécessité de se conformer auxsur l’utilisation du code, des réplications de sa stipulations d’une licence peut avoir des effets désastreux, tels que la publication forcée delicence ou l’exigence que tout logiciel dérivé soit l’ensemble du code source dudit projet, alors quelui aussi open source. Les vingt licences les plus reculer sa date de mise sur le marché de quelquesfréquemment utilisées par les projets open source mois aurait permis d’attendre que le composantpeuvent être consultées à l’adresse suivante : en cause soit remplacé.http://www.blackducksoftware.com/oss/ En plus des obligations juridiques imposéeslicenses#top20 par les licences, il arrive que les développeurs incorporant des composants open source dansLa conformité aux licences des projets se sentent contraints par les termesopen source de la licence, ou par un éventuel sentimentLes équipes de développement intégrant des d’obligation morale, d’apporter quelque chosecomposants ou des extraits de composants open en retour à la communauté. Cela peut parfois lessource dans leurs projets doivent se conformer mener à des inadvertances susceptibles de coûteraux conditions de licence inhérentes à ces à leur entreprise une dilution, voire une perte, decomposants, ce qui peut s’avérer difficile pour sa propriété intellectuelle.différentes raisons. En voici quelques-unes : 1
  • 3. Les options envisageables et technique. Elle doit par ailleurs désigner ces personnes comme décisionnaires dansA défaut de réponse appropriée aux problèmes le cadre de chaque projet actif et les chargerposés par les licences open source, certaines collectivement de la direction et de la supervisionentreprises préfèrent se voiler la face. D’autres de la préparation, de l’implémentation et depréfèrent proscrire l’usage de l’open source la gestion quotidienne des procédures depurement et simplement. Aucune de ces deux développement. L’entreprise doit ensuite procéderapproches n’est satisfaisante, car elles occultent à un audit initial de ses bases de code sourcetoutes les deux une réalité basique : la réutilisation existantes, une étape préliminaire essentielle, quide composants et l’open source ne sont pas lui permet d’identifier et d’établir un état des lieuxprêts de disparaître. La bonne approche est du pedigree, des licences et des composants ded’encourager la réutilisation des composants, ses applications logicielles, à chacune des phasesqu’ils aient été développés en interne ou en de leur cycle de développement.externe, qu’ils soient commerciaux ou opensource, tout en mettant en place des contrôles aux Sept bonnes pratiquesmoments critiques du cycle de développement pour la gestion de lad’un projet. Il est par ailleurs important de releverque la détection des défauts d’un logiciel est propriété intellectuelle surd’autant plus facile et sa réparation d’autant les logicielsmoins chère que les problèmes de licences sont Bonne pratique n°1identifiés rapidement au cours du développement Réutiliser les composants existants dansd’un projet. la mesure du possibleSe préparer à la gestion de Lorsqu’une équipe de développement envisagela propriété intellectuelle d’améliorer les fonctionnalités d’un projet ou de lui en ajouter de nouvelles, elle doit activementLors de la mise en place de bonnes pratiques, rechercher les composants développés enles personnes et les équipes en charge du interne et en externe susceptibles de raccourcirdéveloppement et de la gestion des licences les délais de livraison. L’équipe doit établir lesdoivent envisager diverses actions préliminaires. critères de sélection et d’acquisition applicablesUne entreprise soucieuse de la gestion de la à ces composants. Bien entendu, tout composantpropriété intellectuelle sur ses logiciels doit examiné ne répondant pas aux exigences poséesclairement identifier les responsables de chaque en termes de fonctionnalité, de performance,projet d’un point de vue commercial, juridique 2
  • 4. de fiabilité, de maturité ou de risques doit demande de brevet ou dans l’hypothèse où leêtre éliminé. code matérialise des algorithmes représentant un avantage significatif pour l’entreprise sur laL’équipe doit aussi éliminer tout composant concurrence, etc.), les responsables juridiques,tiers dont la licence figure sur la liste des commerciaux et techniques du projet doiventlicences proscrites, dont la licence comporte des se concerter. Si lesdits responsables estimentstipulations financièrement ou juridiquement effectivement que le composant est sensible,incompatibles avec les finalités commerciales ils doivent l’ajouter à la liste des composantsdu projet, ou qui utilise lui même d’autres sensibles pour l’entreprise.composants ou extraits de code tiers susceptiblesde poser les mêmes problèmes. Une entreprise Bonne pratique n°3développant un produit qui doit être fourni sous Contrôler la réutilisation des composantslicence propriétaire doit par exemple être certaine sensibles ou externesque tout code intégré à celui-ci, qu’il soit souslicence propriétaire ou open source, peut être En évaluant la sensibilité et les conditions deinclus sans risquer de causer une incompatibilité licence des composants dès l’instant où leurirrésoluble entre licences. Tout composant ayant réutilisation est envisagée, les décisions lespassé ce test initial doit ensuite faire l’objet concernant peuvent être prises sur la based’une évaluation “développer ou acheter”, afin d’informations vérifiables, éliminant toutede déterminer si son acquisition présente un mauvaise surprise, pari, compromis ou prisequelconque intérêt d’un point de vue commercial. de risque de dernière minute. Ceci réduit dramatiquement les risques de ne pas tenir lesBonne pratique n°2 délais, de dépasser les budgets et de nuire à laSuivre et contrôler les évolutions des réputation de l’entreprise.composants internes Cela contribue également à prévenir lesDans le cadre de la protection des éléments réutilisations à mauvais escient d’élémentscritiques de la propriété intellectuelle d’une critiques de propriété intellectuelle.entreprise, toute création ou modification A chaque fois qu’une équipe de développementd’un composant développé en interne doit propose d’utiliser un composant dans le cadreêtre horodatée et archivée en enregistrant le d’un projet, elle doit tenir compte :nom de chacun de ses auteurs, ses finalités et • De l’utilisation prévue et de sa justificationses contraintes d’utilisation. Si un composant • De la sensibilité du composantnouvellement créé ou modifié risque de s’avérer • De la façon dont le code sera intégrésensible (par exemple à l’occasion d’une 3
  • 5. La façon dont l’équipe doit appréhender une déclaration du fournisseur de toutchaque composant dépend notamment de si composant tiers dont le code source ne peut être directement examinél’utilisation prévue pour celui-ci est temporaire • Appréhender tous les risques d’incompatibilitésou permanente. Elle peut par exemple envisager entre les conditions de licence du composantd’utiliser un composant afin d’accélérer la mise et celles d’autres composants tiers inclus dansau point d’un prototype ou les premières phases le projetdu développement d’un projet, sans pour autant • Soumettre ces informations aux responsablessouhaiter l’intégrer de manière définitive à la base juridiques, techniques et commerciaux du projet et leur demander l’autorisation d’utiliser lede code. composant de la manière décriteL’équipe doit aussi déterminer si le composant Ces autorisations doivent ensuite être répertoriéessera utilisé en l’état ou si des modifications dans les listes partagées par toute l’entreprise.pourront lui être apportées et, si tel est le cas, à • Si un composant est interne et sensible, la listequelles conditions. répertoriant ce type d’éléments doit être mise àIl convient par ailleurs pour les équipes de jour pour signaler l’inclusion de ce composant dans le projet.développement de décrire la manière dont le • Si le composant a été développé par un tiers, sescomposant sera intégré à leur projet. Cette métadonnées et les informations relatives à sadémarche est importante car les conditions validation (origine, version, licence, conditions dede licence peuvent également dépendre du licence, formes d’utilisation autorisées, projetsmode d’intégration choisi (utilisation du code autorisés, responsables, date de validation) doivent être conservées dans la liste dessans modification, copie et fusion d’un extrait composants tiers validés.de code source dans un autre, intégration d’unexécutable dans une distribution, utilisation d’une Bonne pratique n°4bibliothèque statique, utilisation d’une bibliothèque Vérifier chaque version compilée etdynamique, etc.). chaque releasePour contrôler la réutilisation de composant de Examiner la base de code régulièrement permetmanière encore plus efficace, les équipes doivent d’éviter que des composants ne se glissentaussi : dans le projet sans se faire remarquer. Lors de • Vérifier si le composant a déjà été validé pour le l’établissement de chaque version compilée type d’utilisation envisagé (en consultant la liste du projet et de chaque release, les équipes de des composants tiers validés) développement doivent donc vérifier : • Vérifier la version du composant, ses conditions de licence et celles de tout composant tiers qu’il contienne ou qu’il utilise, ce qui nécessite 4
  • 6. • Qu’aucun composant ou extrait de code sensible, Bonne pratique n°5 qu’il soit interne ou tiers, n’a été ajouté au projet sans avoir été validé Vérifier la conformité lors des transitions entre phases du projet • Qu’aucune modification n’a été apportée à des composants internes sensibles sans autorisation Au terme de chaque étape importante du • Qu’aucune modification n’a été apportée à des développement d’un projet, ses responsables composants tiers lorsque leur mode d’utilisation juridiques, techniques et commerciaux l’interdit ou lorsqu’une autorisation est nécessaire doivent vérifier :Il faut immédiatement réagir à la découverte • Qu’aucun composant sensible, qu’il soit interne oud’un quelconque ajout ou modification non validé tiers, n’a été utilisé dans le projet sans autorisationau cours d’une vérification, soit en obtenant • Qu’aucune modification n’a été apportée à desl’autorisation des responsables juridiques, composants internes sensibles sans autorisation et qu’aucune modification interdite ou nontechniques et commerciaux, soit en revenant autorisée n’a été apportée à des composants tierssur la modification posant problème. La cause • Les conditions de licence de tous les composantsde toute mauvaise utilisation d’un composant tiers utilisés dans le cadre du projet et le respectdoit être isolée et corrigée pour veiller à ce que de ces conditionsl’incident ne se reproduise pas. Cette phase permet de valider le travail desEn examinant chaque version compilée et chaque développeurs, d’impliquer les responsablesrelease de manière rapide et efficace, l’équipe juridiques, techniques et commerciaux dans lade développement est à même de détecter les gestion quotidienne de la réutilisation de codeproblèmes au moment où leur correction est la et de vérifier si d’éventuelles modificationsmoins coûteuse. Au terme de chaque compilation des objectifs du projet sont à l’origineou release, les principales métadonnées sur tous d’incompatibilités juridiques, techniques oules composants tiers doivent être enregistrées financières avec les licences des composantsdans le récapitulatif des éléments inclus. Cela utilisés dans le cadre du projet.permettra d’établir facilement la conformité auxconditions de licence et cela éliminera touteincertitude liée aux modifications apportées entredifférentes releases du projet en permettant uneparfaite traçabilité. 5
  • 7. Bonne pratique n°6 Bonne pratique n°7Contrôler la distribution des composants Analyser les composants logiciels avantet les contributions en composants de les acheterLes raisons expliquant qu’on apporte des Si une entreprise envisage une acquisitioncomposants à un projet open source n’entrent qui emporterait des conséquences pour un oupas dans le champ de ce livre blanc. Les plusieurs composants logiciels, les responsablesconsidérations relatives aux cessions de droits juridiques, techniques et commerciaux concernésà des tiers et la création d’un nouveau projet doivent veiller à :open source non plus. Cependant, si l’on • Identifier chaque composant inclus n’appartenantestime souhaitable d’apporter ou de céder un pas au fournisseur ou à la ciblecomposant ou un extrait donné, les responsables • Examiner leurs conditions de licence à la lumière des règles de conformité, des politiques juridiquesjuridiques, techniques et commerciaux du projet et des objectifs commerciaux de l’acquéreurdoivent vérifier : • Évaluer l’impact de toute reprogrammation ou • Si la sensibilité du composant en cause (lorsqu’il modification nécessaire en termes de coûts, de s’agit d’un composant interne) est un obstacle à bénéfices et de qualité cet apport ou à cette cession • Si l’apport ou la cession est possible pour chacun Cette bonne pratique s’applique à un des composants ou extraits tiers inclus dans le large éventail de situations impliquant des composant en cause investissements financiers. Parmi celles-ci, onL’entreprise peut ainsi veiller à ne pas apporter du relèvera notamment les fusions et acquisitionscode par inadvertance alors que sa sensibilité ou d’entreprises, les achats de produits, les créationsl’étendue de ses droits le lui interdisait. de joint-ventures, les investissements en capital- risque, etc. 6
  • 8. ConclusionPour résumer, ce livre blanc décrit sept bonnespratiques dont l’objectif est de contribuer audéveloppement en tirant partie de la réutilisationde composants et des assemblages de logiciels.En mettant en œuvre ces pratiques dans leursprocédures de développement, les entreprisess’assureront du respect de toutes les conditionsde licence pertinentes et protégeront lapropriété intellectuelle sur leurs logiciels bienplus efficacement.Les entreprises qui adopteront ces pratiques A propos de Black Duck Software Black Duck Software est le leader en matière de produits et servicespourront se montrer beaucoup plus agressives destinés à l’automatisation de la gestion, de la gouvernance et dedans leur approche de l’assemblage de logiciels. l’utilisation sécurisée de logiciels libres et open source, à l’échelle de l’entreprise, dans le cadre d’un processus de développement multiCela permettra à ces entreprises, le moment venu, sources. Black Duck permet aux entreprises de raccourcir les délais ® d’implémentation et de réduire les coûts de développement tout ende mieux profiter des bénéfices et des avantages limitant les problèmes de gestion, de conformité et de sécurité liés aux logiciels libres et open source. Black Duck Software est derrièreconcurrentiels procurés pas cette nouvelle Koders.com, le principal moteur de recherche de codes open sourceapproche du développement – parmi lesquels un sur le marché, Ohloh.net, la plus grande communauté dédiée à l’open source et son répertoire public open source en libre accès, et Theraccourcissement des délais, une réduction des Olliance Group, le principal cabinet de conseil en management et stratégie open source. La société, qui figure parmi les 400 plus grandescoûts de développement et une amélioration de la sociétés de logiciels au monde selon Softwaremag.com, dispose d’un siège à proximité de Boston et de bureaux à San Mateo en Californie,qualité des logiciels. à Londres, Paris, Francfort, Hong Kong, Tokyo et Pékin. Pour plus d’informations, veuillez consulter www.blackducksoftware.com/fr. Royaume Uni & Irlande Pour plus d’informations, veuillez contacter : info-uk@blackducksoftware.com ou appeler au +44 (0)208.582.1081 DACH Pour plus d’informations, veuillez contacter : info-germany@blackducksoftware.com ou appeler au +49 (69) 67733-196 France Pour plus d’informations, veuillez contacter : info-france@blackducksoftware.com ou appeler au +33 (0) 6 28 07 77 39 Plus d’informations sont disponibles sur le site web de Black Duck disponible à l’adresse : www.blackducksoftware.com/frWP-BP-A4EU-0212-FR 7

×