class: center, middle # Le développement Open Source ## à travers le prisme de la recherche David Margery, Sébastien Campion Ingénieur de Recherche INRIA --- # Coder > Publier > Jeter La paillasse du chercheur en informatique est souvent un outil de programmation * Validation ou comparaison d'algorithmes * Production et analyses de données * Simulations, preuves de concept, etc ... Quid du code utilisé, voir du logiciel, après publication des résultats ? * Problème de reproductibilité des résultats scientifiques * Problème du partage de la connaissance * Problème du la valorisation industrielle des résultats de recherche --- # Coder > Publier > Diffuser Le monde du logiciel libre trouve ses racines dans la pratique du partage du savoir-faire dans le monde académique. * On ne peut partager que ce que l'on possède * Il y a plus d'une façon de partager C'est ici que la science rencontre : * La question de sa relation à la société * Faire avancer la connaissance * Faire profiter de la connaissance acquise au tissu socio-économique local * Les juristes Des débats passionnés s'en suivent --- #Le logiciel libre et l'industrie ###Le logiciel libre a aussi trouvé sa place dans l'entreprise * La question du prix * Coût d'acquisition faible, voir nul * Coût de gestion des licences simplifié * Partage des investissements avec le plus grand nombre * La question de le dépendance économique * Maîtriser les logiciels clés de son entreprise (évolutions & correctifs) * Stratégique : libérer l'outil en position de challenger * Recrutement ### Un logiciel libre est le plus souvent maintenu par une ou plusieurs entreprises --- # Plan ### Les Droits ### Les Devoirs ### Les Pratiques --- # Le droit d'auteur en France ## Un droit moral * Perpétuel, insaisissable, inaliénable * Droit à la paternité * Droit dévolu aux personnes ayant collaboré ou à la personne (physique ou morale) ayant coordonné. ## Un droit patrimonial * Droits d'exploitation pour en tirer profit * Dans le cadre du logiciel, c'est un droit dévolu à l'employeur: /!\ *ce n'est pas seulement le lieu de travail qui compte* * Cas du stage --- # Transmission des droits * **Cession** : le titulaire perd ses droits * **Concession** : le titulaire garde ses (ou des) droits L'autorisation d'utilisation est traduite par une **Licence** ### Pas de licence -> Pas de droit d'utilisation ## Nota Bene : Pas de formalité à faire pour acquérir le droit d'auteur mais des précautions à prendre pour prendre date ([Enveloppe Soleau](http://www.inpi.fr/fr/enveloppes-soleau.html)). --- # Avertissements * On parle de droit, et donc d'interprétation juridique et de jurisprudence * Ce n'est pas parce que vous avez une interprétation qu'un juge aura la même. * Ce n'est pas ma formation, ni mon métier Enchangez avec votre responsable de valorisation et de propriété interllectuelle. --- #Je possède, donc je partage ** Les 4 libertés de la Free Software Foundation ** 1. Permettre l’exécution du programme 2. Permettre l'étude du fonctionnement du programme, et son adaptation au contexte d'utilisation 3. Permettre la redistribution du programme en l'état 4. Permettre la redistribution des améliorations apportées au programme ** La question du copyleft ** * Ceux qui bénéficient du partage doivent-ils à leur tour partager aux mêmes conditions ? Rien n'est spécifié sur les personnes à qui l'on partage --- #Ne pas confondre !! Logiciel du domaine public * aucun droit patrimonial ne peut être revendiqué * n'implique pas la disponibilité du code source Logiciel gratuit - Freeware * mise à disposition d'un public, à titre gratuit généralement sous forme exécutable. * n'est pas un logiciel libre Un logiciel libre peut être commercial --- #Open Source et Logiciel Libre Le monde de l'"Open Source" se focalise sur la disponibilité du code source et la possibilité de faire et de redistribuer des modifications. Le monde du "Logiciel Libre" se focalise sur les droits, les libertés données aux utilisateurs d'un logiciel. En pratique : * On parle de la même chose * Un logiciel "Open Source" peut être plus contraignant, et pas vraiment libre. --- # Pourquoi partager Au-delà de vos convictions philosophiques, il va falloir convaincre celui qui détient les droits patrimoniaux * Analyse stratégique à réaliser : que voulez vous obtenir en échange de votre contribution ? * Vision claire de licences des logiciels ou bibliothèques liées à votre logiciel nécessaire * Ne pas vous mettre dans une situation ou votre développement ne peut pas être partagé. Si vous détenez l'ensemble des droits patrimoniaux, votre logiciel peut avoir plusieurs licences. Souvent, vous ne pouvez pas choisir : effet contaminant des licences des bibliothèques tierces --- # Quelques motivations * Faire connaître votre travail, attirer des utilisateurs * Mettre à disposition de la communauté scientifique le logiciel ayant servi à produire vos résultats * Éthique scientifique (reproductibilité des expériences, suffisant ?) * Pour que la communauté puisse construire sur vos travaux * Pour vous imposer comme un acteur clé d'une communauté, un catalyseur * Attirer des développeurs pour construire une offre logiciel complète autour de votre bout de code * Donner une chance à du code qui n'a plus de valeur pour vous * Parce que vous n'avez pas le choix * Pour l’ego --- # Les enjeux des licences libres * Le **copyleft** : la licence s'impose-t-elle à la redistribution ? * La **compatibilité** : la licence d'un composant s'impose-t-elle à l'ensemble du logiciel ? * La **clause de citation** : la licence d'un composant impose-t- elle que celui-ci soit cité ? * Les **services** : la licence s'applique-t-elle si le logiciel est utilisé sans être installé ? * Les **logiciels embarqués** : la licence prévoit-t-elle des droits pour les utilisation à travers un matériel spécifique, ou demandant des clés * La relation aux brevets logiciels --- # Les licences les plus connues ## Free Software Foundation  * GPLv2 * LGPL (v2 et v3) * AGPL pour les applis web * GPLv3 (only, or later) ## Les BSD (Berkeley Software Distribution) * BSD * FreeBSD * MIT --- ## Adaptées au droit Français : * CeCILL * CeCILL-B * CeCILL-C ## Ad-hoc: * QL, * MPL --- # Droit des marques Votre logiciel est libre, et d'autres peuvent donc en distribuer des variantes (a priori) : * Sous quel nom ? * Sur quel site web ? * Avec quelle apparence visuelle ? Entre défense de la marque et liberté du logiciel libre : * Cas de Linux * Cas de Firefox, Fedora, ... --- # Les problèmes commencent En plus d'avoir des utilisateurs, vous risquez d'avoir des contributeurs * Une communauté de fait, à structurer ? Entre les droits (libertés) accordés par la (les) licences choisies et la réalité, il peut y avoir un important décalage * Logiciel libre, mais développement fermé ? FFMPEG Une des questions clés est celle de la légitimité * De fait, le contrôle s'exerce par la légitimité plus que par le droit --- class: center, middle, inverse # II : Vous diffusez et ensuite ? --- # Le cas simple : les utilisateurs Voulez-vous que les utilisateurs contribuent à votre logiciel ? * Processus d'installation * À documenter * Fabrication de scripts et de paquets * Documentation d'utilisation * Sous quelle licence * Tests et retour de bugs * Accessibilité d'un gestionnaire de bug * Suggestions voir demandes de nouvelles fonctionnalités * Jusqu'où aller pour répondre à vos objectifs initiaux ? * Entre-aide * Forum, liste de diffusion ? --- # Déjà des questions difficiles Veut-on une communauté publique ? * Il n'y a pas d'obligation de distribuer le code source à d'autres que les utilisateurs * Pas d'obligation de mise en relation * Mais ce n'est pas juste de votre ressort Politique éditoriale d'un éventuel site web ou de listes de diffusion * Qui peut publier des informations, des nouvelles, des documents sur le site ? * Avec quel statut incorporer les contributions ? * Vers un contrat social de votre communauté ? --- # Statut des contributeurs Celui qui contribue du code source **se créé des droits patrimoniaux** * A-t-il la liberté de les exploiter selon la licence de votre logiciel ? Voulez-vous qu'il les garde, ou qu'il les cède ? En acceptant des contributions, vous devenez exploitant de droits patrimoniaux --- # Statut des contributeurs (suite) Si vous possédez les droits d'exploitation de tous les droits patrimoniaux associé à votre logiciel, vous pouvez changer la licence : * Pour vendre des licences d'utilisation * Pour combler un vide juridique dans la licence actuelle * Porter plainte en cas de violation de la licence --- # Cas complexe : les développeurs En plus de la question des droits patrimoniaux, les développeurs amènent d'autres problèmes * Accès à une version de travail * Souhaits de connaître et/ou de participer aux directions de développement à venir * Définition de ce qu'est une nouvelle version -> Un processus de développement va devoir être formalisé. >> « release early, release often » --- # Projets connexes au votre En théorie, on ne devrait distribuer que son code En pratique : * Souvent des bibliothèque tierces incluses * Ou des lots pour une installation facile Quelles relations avec les projets ayant produit le code inclus * Y contribuer des corrections de bugs * Y faire remonter les problèmes Les règles du savoir vivre dans l'univers du logiciel libre * dualité autorité/pouvoir --- # Les outils du développement communautaire * le dépôt de code, versionné * le site web, le wiki * les listes de diffusion * le bug tracker * la documentation * la page de téléchargement * les annonces (en particulier au niveau sécurité) Utilisation de forges, dont il est plus ou moins facile d'extraire son projet [INRIA Forge](http://gforge.inria.com) [GitHub](http://github.com) --- class: center, middle, inverse # III : Les pratiques de l'open source --- # Réduire "l’énergie d’hacktivation" (1/2) ## Définition * Choisir un bon nom * Donne une idée de l'objectif du projet * Simple à mémoriser en anglais * Différent de celui d’un autre projet et qui ne s’approche d’aucune marque déposée http://bases-marques.inpi.fr/ * Disponible comme nom de domaine en .com, .net ou .org si possible * Les objectifs : concrets, restreints et surtout concis * La licence * Ses fonctionnalités et celles prévues * Les pré-requis * Téléchargements (Code source, Paquet binaire, Conteneur) --- # Réduire "l’énergie d’hacktivation" (2/2) ## L' installation * Depuis le source : standardiser les procédures d’installation * En C > ./configure && make && make install * En python > python setup.py build * Paquet binaire : .bin statique (incluant la libc.a) * Paquet est préconfiguré: .deb, .rpm, .msi ## L' utilisation * Usage : comment utiliser le logiciel et faire tourner un diagnostic (test de base) * Donner différents exemples d'utilisation --- # Communication : README ## Minimal : * Le nom (le site web) * Les fonctionnalitées * La licence * Les dépendances (pré-requis) * L'installation * L'usage * Le(s) autheur(s) ### Format facilement éditable Mardown, txt ### Disponible a deux endroits : en ligne et sur le web (coordonnées aux versions) --- # Communication écrite ## La liste de diffusion * Montrer que vous etes joignable sur la liste de discussion * projet-commits : suivi des contributions ## Messagerie Instantané * IRC --- # Communication sur le dévelloppement * __Outils de suivi__ : * Bug tracker ( /!\ ce n'est pas un forum ) * Feature request, ... * __Gestion de versions__ : * Source code repository * Stratégie du numérotation de versions: Majeur.Mineur.Infra * __Les directives pour développeurs__ * Style Guidelines, on how to organize your source code. * Git Workflow Changes discusses how our workflow has changed now that Mono is hosted on GitHub. * Source Code Control details our source code control use. * Best Practices, used in the project. --- # Infrastructure technique Les forges fournissent : * Site Web * Listes de diffusion * Controle de versions * E-mails de commit * Référencement de bogues * Messagerie instantanée ou chat en temps réel * Wiki * Intégration continue >>>>> ##/!\ l'adhérence --- # Infrastructure sociale : Paquets, sorties et développement au quotidien * 1 commit = 1 modification * Ne pas trop attendre entre les releases, et l'intégration des patches, le risque est que le patch ne soit plus à jour. * Les branches de publications * Revue de code * Signature du commit --- # Conclusions Le chercheur n'est pas le seul à décider de la diffusion du résultat de son travail * Utiliser une licence libre est possible, mais doit se justifier Le monde du libre est * Extrêmement structuré, mais fragmenté * Très à cheval sur le droit d'auteur, du moins pour les logiciels * Basé sur un contrat social plus ou moins implicite --- # Conclusions (suite) On y est contraint de faire un certain nombre de choix * Licence du logiciel * Gestion des droits patrimoniaux d'éventuels contributeurs * Structuration du développement * Droits des marques * Intégration à un éco-système des logiciels libres --- class: center, middle, inverse #Fin http://scampion.github.io/devoss/