Dans un récent billet traduit ci-dessous, Google nous annonce s’engager à ne pas attaquer en premier un acteur de l’open source avec ses brevets, seule la riposte est envisagée.

Nous avons demandé à Gérald Sédrati-Dinet (Gibus) de l’April, l’un de nos spécialistes sur le sujet, non seulement de relire la traduction mais également de nous donner son éclairant point de vue.

« Mon avis est que c’est un pas dans la bonne direction de la part d’une entreprise informatique influente. Mais cet engagement illustre à merveille l’inadaptabilité intrinsèque du système de brevets aux idées informatiques. À quoi servent ces “brevets logiciels” si leur détenteur s’engage à ne pas les utiliser ? Si Google était cohérent, il compléterait cet Engagement pratique par un engagement politique visant à ce qu’aucun “brevet logiciel” ne puisse s’appliquer aux activités des développeurs et utilisateur informatiques. Une telle exception a été récemment proposée par Richard Stallman, Google irait-il jusqu’à la soutenir ? »

Prendre position sur l’Open Source et les brevets

Taking a stand on open source and patents

Duane Valz – 28 mars 2013 – Google Blog Open Source
(Traduction : brouberol, Neros, Melchisedech, cherry, gibus + anonymes)

Chez Google, nous pensons que les systèmes ouverts sont meilleurs (NdT : article sous le lien traduit par le Framablog). Les logiciels open source ont été à l’origine de nombreuses innovations dans l’informatique en nuage, le web mobile et l’Internet en général. Et alors que les plateformes ouvertes on été de plus en plus confrontées à des attaques via des brevets, obligeant les entreprises à se défendre en acquérant encore plus de brevets, nous restons attachés à un Internet ouvert — un Internet qui protège l’innovation réelle et continue de fournir des produits et services de qualité.

Aujourd’hui, nous faisons un pas de plus vers ce but en annonçant l’Open Patent Non-Assertion Pledge (Engagement ouvert de non-application des Brevets) : nous nous engageons à ne poursuivre aucun utilisateur, distributeur ou dévelopeur de logiciel open source sur la base des brevets spécifiés, à moins d’avoir d’abord été attaqués.

Nous avons commencé par identifier dix brevets reliés à MapReduce, un modèle de calcul permettant de traiter d’importants jeux de données initialement développé par Google — dont les versions open source sont désormais largement utilisées. Nous avons l’intention d’étendre au fur et à mesure l’ensemble des brevets possédés par Google concernés par cet engagement à d’autres technologies.

Nous espérons que l’Engagement OPN servira de modèle à l’industrie, et nous encourageons les autres détenteurs de brevets à adopter un engagement ou une initiative similaire. Nous pensons que cela a plusieurs avantages :

• La transparence. Les détenteurs de brevets déterminent précisément sur quels brevets et technologies associées ils souhaitent s’engager, garantissant aux développeurs comme au grand public une gestion transparente des droits des brevets.
• Étendue. Les protections sous l’Engagement OPN ne sont pas confinées à un projet spécifique ou à une licence open source de droits d’auteur. (Google apporte beaucoup de code sous de telles licences, comme les licences Apache ou GNU GPL, mais les protections qu’elles confèrent contre les brevets sont limitées.) L’Engagement OPN, par contraste, s’applique à n’importe quel logiciel open source – passé, présent ou futur – qui pourrait s’appuyer sur des brevets faisant partie de l’Engagement.
• Protection défensive. L’Engagement peut être résilié, mais seulement si une des parties a intenté une action en violation de brevet contre des produits ou des services de Google, ou s’il profite directement d’un tel litige.
• Durabilité. L’Engagement demeure en vigueur pendant toute la durée de vie des brevets, même si nous les transférons.

Notre engagement s’appuie sur des efforts passés d’entreprises comme IBM et Red Hat et sur le travail de l’Open Invention Network (dont Google est membre). Cela complète également nos efforts en matière de licences coopératives, sur lesquelles nous travaillons avec des entreprises partageant nos idées, afin de développer des accords de brevets qui permettraient de réduire les poursuites judiciaires.

Au delà de ces initiatives pilotées par l’industrie, nous continuons à soutenir les réformes pouvant améliorer la qualité des brevets tout en réduisant le nombre excessif de litiges.

Nous espérons que l’Engagement OPN fournira un exemple pour les entreprises cherchant à mettre leurs propres brevets au service du logiciel open source, qui contribuent à d’incroyables innovations.

Par Duane Valz, conseil en brevets

Crédit photo : OpenSourceWay (Creative Commons By-Sa)

Traduction : Framalang d’après une première traduction effectuée par Liu qihao (aka Eastwind) qui remercie François van der Mensbrugghe, Catherine Philippe et Ciarán O’Riordan.

Quelques considérations sur le rôle du juriste dans le domaine du logiciel libre et open source

Till Jaeger

Le docteur Till Jaeger est collaborateur du cabinet d’avocats JBB Rechtsanwaelte depuis 2001. Avocat diplômé et spécialisé dans le domaine du droit d’auteur et du droit des médias, il conseille autant les grandes et moyennes entreprises du secteur des technologies de l’information que les institutions gouvernementales et les développeurs de logiciels sur des sujets impliquant contrats, licences et usage en ligne. Son travail est orienté vers les contentieux relatifs aux logiciels libres et open source. Il est co-fondateur de l’institut pour l’étude juridique du logiciel libre et open source (ifrOSS). En outre, il aide développeurs et éditeurs de logiciels dans le processus de mise en compatibilité et en conformité de leurs licences libres. Till a représenté le projet gpl-violations.org dans plusieurs procès (NdT : devant les juridictions allemandes) dont l’objet portait sur le respect de la GPL. Il a également publié divers articles et livres à propos de questions juridiques sur les logiciels libres et open source. Il a été membre du comité C lors de l’élaboration de la GPLv3.

Pour commencer, clarifions une chose : je ne suis pas un geek. Je ne l’ai jamais été, et je n’ai aucune intention de le devenir. En revanche, je suis juriste. La plupart des lecteurs de ce livre auront probablement tendance à éprouver une plus grande sympathie à l’égard des geeks qu’envers les juristes. Cependant, je ne souhaite pas éluder ce fait : la communauté du logiciel libre et open source n’est pas nécessairement passionnée par les juristes, elle est trop occupée à développer du code. Cela, je le savais déjà au début de l’année 1999, lorsque nos chemins se sont croisés pour la première fois. Néanmoins, d’autres éléments m’étaient, à ce moment-là, encore inconnus. En 1999, tandis que je terminais ma thèse de doctorat portant sur le droit d’auteur classique, j’évaluais l’étendue des droits moraux. Dans ce contexte, j’ai passé un certain temps à réfléchir à la question suivante : comment les droits moraux des développeurs sont-ils protégés par la licence GPL, étant donné que celle-ci confère aux utilisateurs un droit de modification sur leurs logiciels ? C’est ainsi que je suis entré pour la première fois en contact avec le logiciel libre et open source.

À cette époque, les qualificatifs « libre » et « ouvert » avaient évidemment des significations différentes. Mais dans le monde dans lequel je vivais, cette distinction ne méritait pas d’être débattue. Cependant, vu que j’étais libre d’étudier ce qui m’intéressait et ouvert à l’exploration de nouvelles questions sur le droit d’auteur, j’ai rapidement découvert que les deux termes ont quelque chose en commun : bien qu’ils soient effectivement différents, ils sont bien mieux utilisés lorsqu’ils sont ensemble…

Voici trois choses que j’aurais souhaité savoir à l’époque :

Tout d’abord, que mes connaissances techniques, en particulier dans le domaine du logiciel, étaient insuffisantes. Ensuite, que je ne comprenais pas véritablement la communauté et que j’ignorais ce qui importait aux yeux de ses membres. Et cerise sur le gâteau, que je ne connaissais pas grand-chose aux juridictions étrangères, à l’époque. Ces notions m’auraient été précieuses si j’avais pu les aborder dès le départ.

Depuis, j’ai appris suffisamment et, à l’instar de la communauté qui se réjouit de partager ses réalisations, je suis heureux de partager mes leçons (1).

Connaissances techniques

Comment est formée une architecture logicielle ? À quoi ressemble la structure technique d’un logiciel ? Quelles sont les licences compatibles ou incompatibles entre elles ? Comment et pourquoi ? Quelle est la structure du noyau Linux ? Pour citer un exemple, la question essentielle des éléments constitutifs d’une « œuvre dérivée » selon la GPL détermine la manière dont le logiciel pourra être licencié. Tout élément rentrant dans le champ d’une œuvre dérivée d’un logiciel originaire sous licence GPL doit être redistribué selon les termes de cette dernière. Pour évaluer si un programme constitue une « œuvre dérivée » ou pas, il est nécessaire d’avoir au préalable une compréhension technique approfondie. Ainsi, l’interaction des modules de programmes, des liaisons, des IPC (Communications inter-processus), des greffons, des infrastructures technologiques, des fichiers d’en-tête, etc. détermine au niveau formel (parmi d’autres critères) le degré de connexité d’un logiciel par rapport à un autre, ce qui aide à le qualifier ou non d’œuvre dérivée.

Connaissance de l’industrie et de la communauté

Au-delà de ces questions fonctionnelles, l’étendue de mes connaissances des principes régissant le libre était limitée, tant au regard de la motivation des développeurs que des entreprises utilisant du logiciel libre. En outre, je ne connaissais pas son arrière-plan philosophique, et n’étais pas plus familier avec les modalités pratiques d’interactions sociologiques de la communauté. Ainsi, les questions : « Qui est mainteneur ? » ou « Quel est le fonctionnement d’un système de contrôle de version ? » ne trouvaient pas d’écho à mes oreilles. Or, pour servir du mieux possible vos clients, ces questions sont toutes aussi importantes que la maitrise des aspects d’ordre purement technique. Par exemple, nos clients nous demandent de nous occuper du côté juridique des modèles économiques construits sur une double licence de type « open core ». Ceci inclut la gestion des contrats de supports, de services, de développements ainsi que les conventions applicables aux codes sources venant des contributions. Ce faisant, nous guidons entreprises et institutions dans la grande réserve du logiciel libre lors de la mise en place de ces modèles.

D’autre part, nous conseillons aussi les développeurs sur la manière de régler les litiges nés des violations de leur droit d’auteur, notamment via l’élaboration et la négociation de contrats en leur nom et pour leur compte. Ceci étant, pour répondre à tous ces besoins de manière complète, il est fondamental de s’être familiarisé avec cette multiplicité de points de vue.

Connaissances en droit comparé

La troisième chose dont un juriste libriste a besoin, c’est de connaissances à propos des juridictions étrangères, au moins quelques-unes et, plus il en acquiert, mieux il se porte. Pour pouvoir interpréter les différentes licences correctement, il est essentiel de comprendre l’état d’esprit dans lequel s’inscrivaient les personnes qui les ont écrites.

Dans la plupart des cas, le système juridique américain est d’une importance capitale. Par exemple, lors de l’élaboration de la GPL, celle-ci a été écrite avec, à l’esprit, des notions issues de la common law étasunienne. Aux États-Unis le terme « distribution » inclut la distribution en ligne. Or, le système de droit d’auteur allemand établit un distinguo entre la distribution en ligne et hors-ligne. Dès lors,  les licences qui ont été rédigées par des juristes de la common law étasunienne peuvent être interprétées comme incluant la
distribution en ligne. Au cours d’un procès, cet argument peut devenir particulièrement pertinent (2).

Un apprentissage permanent

Au final, toutes ces connaissances sont d’une grande utilité. Aussi, j’espère qu’à l’image du processus d’évolution d’un logiciel, qui apporte son lot de solutions aux besoins de tous les jours, mon esprit continuera à répondre aux défis que la vibrante communauté du logiciel libre et open source pose constamment à l’attention d’un juriste.

(1) L‘Institut für Rechtsfragen der Freien und Open Source Software (institut des questions de droit sur les logiciels libres et open source) propose, entre autres, une collection d’ouvrages et de jurisprudences en lien avec les logiciels libres et open source ; pour plus de détails, voir sur le site http://www.ifross.org/.

(2) Voir : http://www.ifross.org/Fremdartikel/LGMuenchenUrteil.pdf, Cf. Welte v.Skype, 2007

Source :

• Google n’aime pas la définition du mot « ungooglable » en Suède (Big Browser – Le Monde)

Crédit : Simon Gee Giraudot (Creative Commons By-Sa)

* Aujourd’hui 28 mars, dernière séance de traduction collaborative sur ce projet avec l’épisode n°42 !

Traduction Framalang : tcit, Julius22, Sphinx, goofy, peupleLà, merlin8282, lamessen, BAud, Jej, Alpha

Modèles économiques basés sur le libre et l’open source

Carlo Daffara

Carlo Daffara est chercheur dans le domaine des modèles économiques basés sur l’open source, le développement collaboratif d’objets numériques et l’utilisation de logiciels open source dans les entreprises. Il fait partie du comité éditorial de relecture du journal international des logiciels et processus open source (International Journal of Open Source Software & Processes : IJOSSP), est membre du comité technique de deux centres régionaux de compétences open source et est également membre du réseau juridique européen FSFE (fondation européenne pour le logiciel libre). Il a pris part aux comités SC34 et JTC1 pour la branche italienne de l’ISO, UNINFO et a travaillé au sein du groupe de travail de la société Internet du logiciel public (Internet Society Public Software) ainsi que pour beaucoup d’autres initiatives liées à la normalisation.

Auparavant, Carlo Daffara était le représentant italien dans le groupe de travail européen sur le logiciel libre, la première initiative de l’Union européenne afin de soutenir l’open source et le logiciel libre. Il a présidé le groupe de travail SME du groupe d’étude de l’UE sur la compétitivité et le groupe de travail IEEE des intergiciels open source du comité technique sur le calcul évolutif. Il a travaillé en tant qu’examinateur du projet pour la commission Européenne dans le domaine de la coopération internationale, l’ingénierie logicielle, l’open source et les systèmes distribués et a été directeur de recherche dans plusieurs projets de recherche de l’Union européenne.

Introduction

« Comment gagner de l’argent avec le logiciel libre ? » était une question très courante, il y a encore seulement quelques années. Désormais, cette question s’est transformée en « Quelles sont les stratégies commerciales pouvant être mises en œuvre en se basant sur le logiciel libre et open source ? ». Cette question n’est pas aussi gratuite qu’elle peut paraître, puisque de nombreux chercheurs universitaires écrivent encore ce genre de textes : « le logiciel open source est délibérément développé hors de tout mécanisme de marché… il échoue à contribuer à la création de valeur aux développements, contrairement au marché du logiciel commercial… il ne génère pas de profit, de revenus, d’emplois ou de taxes…

Les licences open source sur les logiciels visent à supprimer les droits d’auteurs sur le logiciel et empêchent d’établir un prix pour le logiciel. Au final, les logiciels développés ne peuvent être utilisés pour générer des profits. » [Koot 03] ou [Eng 10] indiquent que « des économistes ont montré que les collaborations open source dans le monde réel s’appuient sur plusieurs incitations différentes telles qu’enseigner, se démarquer et se créer une réputation » (sans parler des incitations économiques). Cette vue purement « sociale » du logiciel libre et open source est partiale et fausse. Et nous démontrerons qu’il y a des raisons économiques liées au succès des métiers du libre et de l’open source qui vont au-delà des collaborations purement bénévoles.

Le logiciel libre et open source face aux réalités économiques

Dans la plupart des domaines, l’utilisation d’un logiciel libre et open source apporte un avantage économique substantiel, grâce aux développements partagés et aux coûts de maintenance, déjà décrits par des chercheurs comme Gosh, qui a estimé une réduction de coût de 36 % en R&D (« Recherche et Développement », NdT). La vaste part de marché des déploiements « internes » de logiciels libres et open source explique pourquoi certains des bénéfices économiques ne sont pas directement visibles sur le marché des services commerciaux.

L’étude FLOSSIMPACT a montré, en 2006, que les entreprises qui contribuent au code de projets de logiciels libres et open source ont, au total, au moins 570 000 employés et un chiffre d’affaires annuel de 263 milliards d’euros [Gosh 06], faisant ainsi du logiciel libre et open source l’un des phénomènes les plus importants des NTIC. Il est important aussi de reconnaître qu’un pourcentage non négligeable de cette valeur économique n’est pas directement perceptible du marché, vu que la majorité du logiciel n’est pas développée dans l’intention de le vendre (le soi-disant logiciel « prêt à l’emploi ») mais uniquement à usage interne. Comme le réseau thématique FISTERA EU l’a identifié, en réalité, la majorité du logiciel est développée seulement pour un usage interne.

Il est clair que ce qui est appelé « le marché logiciel » est en réalité bien plus réduit que le vrai marché du logiciel et des services et que 80 % restent invisibles. Nous verrons que le FLOSS tient une place économique importante de ce marché, directement grâce à ce modèle de développement interne.

Modèles économiques et proposition de valorisation

L’idée de base d’un modèle économique est assez simple : j’ai quelque chose ou je peux faire quelque chose (la « proposition de valeur ») et c’est plus rentable de me payer ou d’obtenir ce quelque chose plutôt que de le faire soi-même (il est même parfois impossible de trouver des alternatives, comme dans le cas de monopoles naturels ou créés par l’homme, et l’idée même de le produire par soi-même n’est pas envisageable). Il y a deux sources possibles de valeur : une propriété (quelque chose qui peut être échangé) et l’efficacité (quelque chose propre à ce que fait une entreprise et la manière dont elle le fait).

Avec l’open source, la « propriété » est généralement non exclusive (à l’exception de ce qui est nommé « cœur ouvert », où une partie du code n’est pas libre du tout et cela sera abordé plus loin dans cet article). D’autres exemples de propriété concernent le droit des marques, les brevets, les licences… tout ce qui peut être transféré à une autre entité par contrat ou par une transaction légale. L’efficacité est la capacité à effectuer une action avec un coût moindre (qu’il soit tangible ou intangible) et cela correspond à la spécialisation dans un domaine d’application ou apparaît grâce à une nouvelle technologie.

Pour le premier cas, les exemples sont simplement la réduction du temps nécessaire pour réaliser une action quand vous augmentez votre expertise concernant ce sujet. La première fois que vous installez un système complexe, cela peut demander beaucoup d’efforts et cet effort diminue d’autant plus que vous connaissez les tâches nécessaires pour réaliser l’installation elle-même. Pour le second, cela peut être l’apparition d’outils qui simplifient le processus (par exemple, avec le clonage d’images) et introduisent une importante rupture, un « saut » dans la courbe efficacité-temps.

Ces deux aspects sont la base de tout modèle économique que nous avons analysé par le passé ; il est possible de montrer que tout ceux-ci échouent afin de garantir une continuité entre les propriétés et l’efficacité.

Parmi les résultats de notre précédent projet de recherche, nous avons trouvé que les projets basés sur un modèle propriétaire ont tendance à obtenir moins de contributions extérieures car cela nécessite une opération juridique pour faire partie des propriétés de l’entreprise, pensez par exemple aux licences doubles : afin que son code fasse partie du code du produit, un contributeur extérieur doit signer l’abandon des droits sur son code afin que l’entreprise puisse vendre la version commerciale ainsi que la version open source.

D’un autre côté, les modèles totalement orientés sur l’efficacité ont tendance à avoir plus de contributions et de visibilité mais des résultats financiers plus faibles. Je l’ai écrit plusieurs fois : il n’y a pas de modèle économique idéal mais un éventail de modèles possibles et les entreprises devraient s’adapter elles-mêmes pour changer les conditions du marché et aussi adapter leur modèle. Certaines entreprises débutent par des modèles entièrement axés sur l’efficacité puis construisent, avec le temps, une propriété en interne, d’autres ont commencé avec un modèle orienté vers la propriété et ont évolué différemment pour augmenter les contributions et réduire les efforts d’ingénierie (ou développer la base d’utilisateurs afin de créer d’autres moyens d’avoir un retour financier grâce aux utilisateurs).

Une typologie des modèles économiques

L’étude EU FLOSSMETRICS des modèles économiques basés sur le logiciel libre a identifié, après analyse de plus de 200 entreprises, une taxonomie des principaux modèles économiques utilisés par les entreprises open source ; les principaux modèles identifiés sur le marché sont :

• la double licence : le même code source logiciel distribué sous GPL et sous une licence propriétaire. Ce modèle est principalement utilisé par les producteurs de logiciel et outils pour développeurs et fonctionne grâce à une forte association de la GPL, qui requiert que les travaux dérivés et logiciels liés directement soient distribués sous la même licence. Les entreprises ne souhaitant pas distribuer leur propre logiciel sous GPL peuvent obtenir une licence propriétaire leur octroyant une exemption des conditions de la GPL, ce qui semble souhaitable à certains. L’inconvénient de cette licence double est que les contributeurs externes doivent accepter des conditions similaires et cela a révélé des réductions de contributions externes, se limitant à des corrections de bogues et des ajouts mineurs ;
• le modèle « cœur ouvert » (précédemment appelé « valeur ajoutée propriétaire » ou « séparation entre libre et propriétaire » \* ? *\) : ce modèle se distingue entre un logiciel libre basique et une version propriétaire, basée sur la version libre mais avec l’ajout de greffons propriétaires. La plupart des entreprises qui suivent un tel modèle adoptent la Mozilla Public Licence, car elle permet explicitement cette forme de mélange et permet une plus grande participation des contributions externes sans les mêmes contraintes de consolidation du droit d’auteur comme dans l’usage de doubles licences. Ce modèle a l’inconvénient intrinsèque que le logiciel libre doit être de grande valeur pour être attractif pour les utilisateurs, i.e. il ne doit pas être réduit à une version aux possibilités limitées, tout comme, dans le même temps, il ne doit pas « cannibaliser » le produit propriétaire. Cet équilibre est difficile à atteindre et à maintenir dans la durée ; en outre, si le logiciel est de grand intérêt, les développeurs peuvent essayer d’apporter les fonctionnalités manquantes dans le logiciel libre, réduisant ainsi l’intérêt de la version propriétaire et donnant potentiellement naissance à un logiciel concurrent entièrement libre qui ne souffrira pas des mêmes limitations ;
• les experts produits : des entreprises qui ont créé ou maintiennent un projet logiciel spécifique et utilisent une licence libre pour le distribuer. Les principaux revenus viennent du service, comme la formation ou l’expertise, et suivent la classification EUWG d’origine « le meilleur code vient d’ici » et « les meilleures compétences sont ici » [DB 00]. Cela conforte l’impression, courante, que les experts les plus compétents sur un logiciel sont ceux qui l’ont développé et qu’ils peuvent ainsi fournir des services au prix d’un démarchage minimal, s’appuyant sur la fourniture gratuite du code. L’inconvénient de ce modèle est que le coût d’entrée pour des concurrents potentiels est faible, vu que le seul investissement nécessaire est l’acquisition des compétences sur le logiciel lui-même ;
• les fournisseurs de plateforme :des entreprises qui apportent un ensemble de services, avec support et intégration de certains projets, constituant une plateforme cohérente et testée. En ce sens, même les distributions GNU/Linux sont classées en tant que plateforme ; une observation intéressante est que ces distributions sont distribuées en grande partie sous licence libre pour maximiser les contributions externes et s’appuyer sur la protection du droit d’auteur pour empêcher la copie sauvage sans empêcher les « déclinaisons » (suppression des particularités soumises à droit d’auteur comme les logos ou droit des marques, pour créer un nouveau produit). Des exemples de clones de Red Hat sont CentOS et Oracle Linux. La valeur ajoutée provient d’une qualité garantie, de la stabilité et de la fiabilité ainsi que d’une garantie de support pour les applications métier critiques ;
• les entreprises de conseil et de recrutement : les entreprises de cette catégorie ne font pas vraiment de développement mais fournissent des conseils de sélection et des services d’évaluation pour un large éventail de projets, d’une manière qui est proche du rôle de l’analyste. Ces entreprises ont tendance à avoir un impact très limité sur les communautés car les résultats de l’évaluation et du processus d’évaluation sont généralement des données propriétaires ;
• les fournisseurs de support global : des entreprises qui proposent un support centralisé pour un ensemble de produits de logiciel libre, généralement en employant directement les développeurs ou en remontant les demandes de support ;
• la validation juridique et l’expertise : ces entreprises n’apportent pas de développements de code source mais fournissent une aide à la vérification de conformité aux licences, parfois en apportant une garantie et une assurance contre les attaques juridiques ; certaines entreprises utilisent des outils pour assurer que le code n’est pas réutilisé ;
• la formation et la documentation : des entreprises qui proposent de la formation, en ligne et en présentiel, des documentations et des manuels supplémentaires. Cela est généralement fourni dans le cadre d’un contrat de support, mais, récemment, quelques réseaux de centres de formation ont lancé des cours orientés spécifiquement vers le logiciel libre ;
• le partage des coûts de R&D : une entreprise ou une société peut avoir besoin d’une nouvelle version ou d’une amélioration d’un paquet logiciel et financer un consultant ou un développeur pour réaliser le travail. Plus tard, le logiciel développé est redistribué en open source pour bénéficier de l’ensemble des développeurs expérimentés pouvant le déboguer et l’améliorer. Un bon exemple est la plateforme Maemo, utilisée par Nokia pour ses smartphones (comme le N810) ; au sein de Maemo, seul 7,5 % du code est propriétaire, apportant une réduction des coûts estimée à 228 millions de dollars (et une réduction du temps de mise sur le marché d’un an). Un autre exemple est l’écosystème Eclipse, un environnement de développement intégré (EDI) distribué à l’origine par IBM comme logiciel libre puis ensuite géré par la fondation Eclipse. De nombreuses entreprises ont choisi Eclipse comme socle pour leur produit et ont ainsi réduit le coût global pour la création d’un logiciel fournissant une fonctionnalité pour les développeurs. Il y a un grand nombre d’entreprises, d’universités et de personnes qui participent à l’écosystème Eclipse. Comme récemment constaté, IBM contribue aux alentours de 46 % au projet, les contributeurs à titre personnel représentant 25 % et un grand nombre d’entreprises comme Oracle, Borland, Actuate et de nombreuses autres ayant des participations allant de 1 à 7 %. Ceci est semblable aux résultats obtenus grâce à l’analyse du noyau Linux et qui montre que, lorsqu’il y a un écosystème sain et de grande taille, le partage des tâches réduit de manière significative les coûts de maintenance, dans [Gosh 06], on estime qu’il est possible de faire des économies de l’ordre de 36 % dans la recherche et la conception logicielle grâce à l’utilisation du logiciel libre, ces économies constituent en elles-mêmes le plus gros « marché » réel pour le logiciel libre, ce qui est démontré par le fait qu’au moins une partie du code des développeurs est basé sur du logiciel libre (56,2 % comme mentionné dans [ED 05]). Un autre excellent exemple de « coopétition » inter-entreprises est le projet WebKit, le moteur de rendu HTML à la base du navigateur Google Chrome ainsi que d’Apple Safari et qui est utilisé dans la majorité des appareils mobiles. Dans ce projet, après un délai initial d’un an, le nombre de contributions externes a commencé à devenir significatif et, après un an et demi, il surpasse largement les contributions d’Apple — réduisant de fait les coûts de maintenance et d’ingénierie grâce à la répartition des tâches entre les co-développeurs ;
• les revenus indirects : une entreprise peut choisir de financer des projets de logiciel libre si ces projets peuvent créer une source de revenus importante pour des produits dérivés, non liés directement au code source ou au logiciel. L’un des cas les plus courants correspond à l’écriture de logiciel nécessaire au fonctionnement de matériel, par exemple, les pilotes d’un système d’exploitation pour un matériel spécifique. En fait, de nombreux fabricants de matériel distribuent déjà gratuitement leurs pilotes logiciels. Certains d’entre eux distribuent déjà certains de leurs pilotes (surtout ceux pour le noyau Linux) sous une licence libre. Le modèle du produit d’appel est une stratégie commerciale traditionnelle, répandue même à l’extérieur du monde du logiciel : dans ce modèle, les efforts sont consacrés à un projet de logiciel libre et open source afin de créer ou d’étendre un autre marché dans des conditions différentes. Par exemple, les fournisseurs de composants matériels investissent dans le développement de pilotes logiciels pour des systèmes d’exploitation open source (comme GNU/Linux) pour s’étendre sur le marché spécifique des composants. D’autres modèles de revenus auxiliaires sont ceux, par exemple, de la fondation Mozilla qui réunit une somme d’argent non négligeable grâce à un partenariat avec Google sur le moteur de recherche (estimé à 72 millions de dollars en 2006), tandis que SourceForge/OSTG est financé en majorité par les recettes des ventes en ligne du site partenaire ThinkGeek.

Certaines entreprises ont plus d’un modèle principal et sont, par conséquent, comptées en double ; notamment, la plupart des entreprises pratiquant une licence double vendent aussi du service de support. En outre, les experts d’un produit ne sont comptés que s’ils ont une partie visible de leur entreprise qui contribue au projet en tant que « commiter principal ». Autrement, le nombre d’experts serait bien plus élevé, du fait que certains projets sont au cœur du support commercial de nombreuses entreprises (de bons exemples sont OpenBravo et Zope).

Il faut aussi tenir compte du fait que les fournisseurs de plateforme, même s’ils sont limités en nombre, tendent à avoir des taux de facturation plus élevés que les experts ou que les entreprises à cœur ouvert. De nombreux chercheurs essaient d’identifier s’il y a un modèle plus « efficace » parmi ceux pris en compte ; ce que nous avons trouvé est que le futur le plus probable sera l’évolution d’un modèle à l’autre, avec une consolidation sur le long terme des consortiums de développement (comme les fondations Eclipse et Apache) qui fournissent une forte infrastructure légale et des avantages de développement ainsi que des spécialistes apportant des offres verticales pour des marchés spécifiques.

Conclusion

Le logiciel libre et open source permet non seulement une présence pérenne, et même très large, sur le marché (Red Hat est déjà proche du milliard de dollars de revenus annuels), mais aussi plusieurs modèles différents qui sont totalement impossibles avec le logiciel propriétaire. Le fait que le logiciel libre et open source est un bien non concurrent facilite aussi la coopération entre entreprises, tant pour accroître sa présence mondiale et pour signer des contrats à grande échelle pouvant demander des compétences multiples que sur le plan géographique (même produit ou service, région géographique différente) ; « verticalité » (entre produits) ou « horizontalité » (des domaines d’application). Cet adjuvant à créer de nouveaux écosystèmes est l’une des raisons expliquant que le logiciel libre et open source fait partie intégrante de la plupart des infrastructures informatiques dans le monde, enrichissant et aidant les entreprises et administrations publiques à réduire leurs coûts et à collaborer pour de meilleurs logiciels.

Bibliographie

• [DB00] Daffara, C.Barahona, J.B. Free Software/Open Source: Information Society Opportunities for Europe working paper,http://eu.conecta.it paper, OSSEMP workshop, Third international conference on open source. Limerick 2007
• [ED05] Evans Data, Open Source Vision report, 2005
• [Eng10] Engelhardt S. Maurer S. The New (Commercial) Open Source: Does it Really Improve Social Welfare Goldman School of Public Policy Working Paper No.GSPP10-001, 2010
• [Gar06] Gartner Group, Open source going mainstream. Gartner report, 2006
• [Gosh06] Gosh, et al. Economic impact of FLOSS on innovation and competitiveness of the EU ICT sector. http://bit.ly/cNwUzû
• [Koot03] Kooths, S.Langenfurth, M.Kaiwey,N.Open-Source Software: An Economic Assessment Technical report, Muenster Institute for Computational Economics (MICE), University of Muenster

Comment des hackers adultes peuvent-ils s’assurer de faire émerger une nouvelle génération de hackers libres ?

La réponse d’un père de famille dynamique et avisé 😉

Former la prochaine génération de bidouilleurs open source

Growing the next generation of open source hackers

Dave Neary (Red Hat) – 26 février 2013 – OpenSource.com
(Traduction Framalang : Antoine, cherry, psychoslave, Jeff_, Eijebong, biglittledragoon, goofy, Vero, mathilde, tcit, Quentin, Metal-Mighty, jtanguy, Penguin, Pat, Asta, arnaudbey + anonymes)

En tant que père de trois enfants de 5, 7 et 10 ans, j’ai hâte de partager avec eux les valeurs qui m’ont attiré vers l’open source : partager et créer ensemble des choses géniales, prendre le contrôle de son environnement numérique, adopter la technologie comme moyen de communication plutôt qu’un média de consommation de masse. En d’autres termes :

Comment des bidouilleurs adultes peuvent-ils s’assurer de faire émerger une nouvelle génération de bidouilleurs open source ?

Une des choses que j’ai apprise est qu’il ne faut pas aller trop vite. J’ai mis mes enfants devant Scratch et Sugar à l’âge de 5 et 8 ans, et, bien qu’ils se soient amusés à changer les nombres sur un petit programme que je leur ai montré et aient aimé dessiner leurs propres voitures pour ensuite les diriger sur l’écran, ils étaient trop petits pour comprendre le concept de lier des fonctions entres elles pour arriver à obtenir des comportements plus sophistiqués.

Voici quelques-unes des leçons que j’ai apprises en tant que parent qui, je crois, peuvent être adaptées selon l’âge et les centres d’intérêt de vos enfants.

Un espace à vivre bidouillable

Nous avons encouragé nos garçons à décorer leur chambre, à organiser leurs meubles comme ils voulaient et à avoir leurs propres petits fiefs. Parfois cela nous rend complètement dingues en tant que parents, et, régulièrement, nous devons les aider à ranger, mais leur espace leur appartient.

De même, chaque enfant de plus de 7 ans peut avoir un vrai couteau qu’il peut utiliser pour tailler du bois et couper de la ficelle.

Ingénierie préscolaire

J’adore les jouets qui permettent aux enfants de donner libre cours à leur imagination. En plus c’est génial, parce qu’en tant qu’adulte, je prends autant de plaisir qu’eux à jouer ensemble ! Mes jeux de construction préférés (achetés à peu près au moment où les enfants ont l’habileté nécessaire pour les manipuler) sont les Kapla, les trains en bois, les lots de Duplo, Playmobil, Lego et les voitures Meccano.

Lego et Meccano notamment font un super boulot pour faire des kits adaptés aux enfants de tout âge. Une autre petite astuce est d’encourager le mélange et d’assembler différentes marques de jouets. Nous avons des ponts Kapla passant par-dessus des trains Ikea et des camions Lego qui transportent des personnages Playmobil.

Les Kapla aussi sont très intéressants. Ce sont des planchettes en bois découpées selon des proportions très précises ; elles sont trois fois plus larges qu’épaisses, et cinq fois plus longues que larges. Avec ces simples proportions et la précision des découpes, il est possible de construire des objets très complexes, comme la Tour Eiffel ou une maison Kapla.

Se lancer dans l’électronique

Nous avons un kit Arduino, et mon aîné commence à avoir le niveau pour comprendre comment câbler un circuit, mais il n’a pas encore découvert comment programmer dans le dialecte C propre à Arduino.

Mais même avant quelque chose de ce genre, les arts et les activités artisanales sont un excellent entraînement pour le DIY (NdT : Do It Yourself, c’est-à-dire « Faites-le vous-même »), et nous avons toujours quelques bâtonnets de glaces ou des pinces à linge et un pistolet à colle pour des cadeaux « faits main ».

Puis vous pouvez laisser traîner des tournevis, pinces, multimètres et autres fers à souder, pour que les enfants puissent désosser leurs vieux jouets, ou des appareils électroniques cassés, réparer les choses par eux-mêmes avec de simples circuits électriques, lorsque que quelque chose ne marche pas, et récupérer des pièces détachées pour les intégrer dans leurs futurs projets. Une supervision parentale est recommandée avec le fer à souder jusqu’à ce qu’ils maîtrisent son utilisation.

Apprendre aux enfants à bidouiller

J’adorerais entendre parler de ressources pour que les enfants apprennent à maîtriser la programmation ! Je connais l’existence de la Code Academy et la Khan Academy qui apprennent aux enfants à coder ; et Scratch and Sugar, que j’ai déjà mentionné.

Merci de partager vos propres conseils sur la manière d’endoctriner la prochaine génération de bidouilleurs open source !

Crédit photo : See-Ming Lee (Creative Commons By-Sa)

L’écrivain Evgeny Morozov n’aime pas les visions bisounours des nouvelles technologies.

On se souvient qu’il y a deux ans il avait vertement critiqué le soit-disant pouvoir libérateur d’Internet, ce qui lui avait valu réponse de Cory Doctorow traduite par nos soins.

Il s’en prend aujourd’hui à l’usage immodéré de l’expression « open » qui, à force d’être utilisé à tous les sauces, prend le risque d’être vidé de son (noble ?) sens.

Ouvert et fermé

Open and Closed

Evgeny Morozov – 17 mars 2013 – NewYorkTimes.com (Opinion)
(Traduction Framalang)

« L’impression 3D peut-elle être subversive ? » demande une voix dans la vidéo la plus terrifiante que vous puissiez trouver sur Internet ce mois-ci. Il s’agit de la bande-annonce pour Defcad.com, un moteur de recherche pour des modèles imprimables en 3D de choses que les « institutions et les industries ont pour intérêt commun de garder loin de nous », incluant des « appareils médicaux, médicaments, biens, pistolets ».

La voix appartient à Cody Wilson, un étudiant en droit du Texas qui a fondé l’année dernière Defense Distributer, une initiative controversée visant à produire une « arme wiki » imprimable. Avec Defcad, il s’étend au-delà des armes, autorisant, par exemple, des passionnés de drones à rechercher des pièces imprimables.

M. Wilson joue la carte de « l’ouverture » de Defcad jusqu’à dire qu’elle est l’opium des masses armées d’iPad. Non seulement le moteur de recherche Defcad sera placé sous le signe de l’« open source » — la bande-annonce le clame à deux reprises — mais également de « l’open data  ». Avec une telle ouverture, Defcad ne peut pas être le Mal, n’est-ce pas ?

Personne n’a besoin de voir des projets tels que Defcad pour constater que « l’ouverture » est devenue un terme dangereusement vague, avec beaucoup de sex-appeal mais peu de contenu un tant soit peu analytique. Certifiées « ouvertes », les idées les plus odieuses et suspectes deviennent soudain acceptables. Même l’Église de Scientologie vante son « engagement envers la communication ouverte ».

L’ouverture est aujourd’hui un culte puissant, une religion avec ses propres dogmes. « Posséder des gazoducs, personnes, produits, ou même la propriété intellectuelle n’est plus la clef du succès. L’ouverture l’est », clame l’éditorialiste Jeff Jarvis.

La fascination pour « l’ouverture » provient principalement du succès des logiciels open source, du code informatique publiquement accessible auquel tout le monde peut contribuer. Mais aujourd’hui ce principe est en train d’être appliqué à tout, de la politique à la philanthropie ; des livres intitulés « The Open-Source Everything Manifesto » (le Manifeste du Tout Open Source) et « Radical Openness » (L’Ouverture Radicale) ont récemment été publiés. Il existe même « OpenCola » — un vrai soda pour le peuple.

Pour de nombreuses institutions, « ouvert » est devenu le nouveau « vert ». Et de la même façon que certaines entreprises « verdissent » (greenwash) leurs initiatives en invoquant une façade écolo pour cacher des pratiques moins recommandables, un nouveau terme vient d’émerger pour décrire ce besoin d’introduire « l’ouverture » dans des situations et environnements où elle existe peu ou pas : « openwashing » (« ouvertisation »).

Hélas, « l’ouvertisation », aussi sympathique que cela puisse sonner, ne questionne pas l’authenticité des initiatives « ouvertes » ; cela ne nous dit pas quels types « d’ouverture » valent le coup, s’il en est. Toutes ces ouvertures, ou prétendues ouvertures, ne se valent pas et nous devons les différentier.

Regardez « l’ouverture » célébrée par le philosophe Karl Popper, qui a défini la « société ouverte » comme l’apothéose des valeurs politiques libérales. Ce n’est pas la même ouverture que celle du monde de l’open source. Alors que celle de Popper concernait principalement la politique et les idées, l’open source concerne avant tout la coopération, l’innovation, et l’efficacité — des résultats utiles, mais pas dans toutes les situations.

Regardez comme George Osborne, le chancelier britannique a défini les « politiques open source » récemment. « Plutôt que de se baser sur le fait que des politiciens » et des « fonctionnaires aient le monopole de la sagesse, vous pouvez vous engager via Internet » avec « l’ensemble du public, ou du moins les personnes intéressées, pour résoudre un problème particulier ».

En tant qu’ajout à la politique déjà en place, c’est merveilleux. En tant que remplacement de la politique en place, en revanche, c’est terrifiant.

Bien sûr, c’est important d’impliquer les citoyens dans la résolution des problèmes. Mais qui décide des « problèmes particuliers » auxquels les citoyens doivent s’attaquer en premier lieu ? Et comment peut-on définir les limites de ce « problème » ? Dans le monde du logiciel open source, de telles décisions sont généralement prises par des décideurs et des clients. Mais en démocratie, les citoyens tiennent la barre (plutôt en délèguent la tenue) et rament simultanément. En politique open source, tout ce qu’ils font, c’est ramer.

De même, un « gouvernement ouvert » — un terme autrefois réservé pour discuter de la responsabilité — est aujourd’hui utilisé plutôt pour décrire à quel point il est facile d’accéder, manipuler, et « remixer » des morceaux d’informations du gouvernement. Ici, « l’ouverture » ne mesure pas si de telles données augmentent la responsabilité, mais seulement combien d’applications peuvent se baser dessus, et si ces applications poursuivent des buts simples. L’ambiguïté de l’ouverture permet au Premier Ministre britannique David Cameron de prôner un gouvernement ouvert, tout en se plaignant que la liberté d’expression « bouche les artères du gouvernement ».

Cette confusion ne se limite pas aux gouvernements. Prenez par exemple cette obsession pour les cours en ligne ouvert et massif (NdT : MOOC). Que signifie le mot ouvert dans ce cas? Eh bien, ils sont disponibles en ligne gratuitement. Mais il serait prématuré de célébrer le triomphe de l’ouverture. Un programme d’ouverture plus ambitieux ne se contenterait pas d’étendre l’accès aux cours mais donnerait aussi aux utilisateurs la possibilité de réutiliser, modifier et d’adapter le contenu. Je pourrais prendre les notes de conférence de quelqu’un, rajouter quelques paragraphes et les faire circuler en tant qu’élément de mon propre cours. Actuellement, la plupart de ces cours n’offrent pas cette possibilité : le plus souvent leurs conditions d’utilisation interdisent l’adaptation des cours.

Est-ce que « l’ouverture » gagnera, comme nous l’assurent ces Pollyanas numériques? Probablement. Mais une victoire pour « l’ouverture » peut aussi marquer la défaite de politiques démocratiques, d’une réforme ambitieuse et de bien d’autres choses. Peut-être faudrait-il mettre en place un moratoire sur le mot « ouvert ». Imaginez les possibilités que cela pourrait ouvrir !

Crédit photo : Pumpkincat210 (Creative Commons By)

« Comment ma fille a fait son TPE grâce au Framapad », tel est le titre d’un court billet du blog de Nicolas Fressengeas, billet rédigé ici justement par sa fille.

Nous ne résistons pas au plaisir de le reproduire ici tant nous sommes fiers nous rendre ainsi utiles, à fortiori dans l’éducation.

Pour rappel TPE est l’acronyme de Travaux personnels encadrés et c’est l’une des rares fois où l’on se retrouve à travailler réellement en groupe au cours de sa scolarité.

Cette année, comme pour tous les élèves de première L, nous devions préparer un TPE. Un dossier d’une vingtaine de pages, sur le sujet de notre choix. Pour cela, le lycée nous prévoit environ six mois de travail. Alors lorsque l’on réalise, une semaine avant la date du ramassage des dossiers, qu’il reste la moitié du TPE à rédiger, on se retrouve un peu pris de panique.

Que faire alors ?

Plus le temps d’organiser des séances de travail collectives ! Heureusement, mon père m’a alors présenté le Framapad. Il m’a suffit d’envoyer l’adresse à mes deux coéquipières, pour pouvoir travailler ensemble, le Framapad étant relativement simple à utiliser, notamment grâce au chat, et au système de couleur ! Ainsi, en une soirée, notre dossier fut entièrement rédigé !

L’histoire ne dit pas quel était le sujet du TPE en question mais peut-être que mademoiselle viendra nous en faire confidence dans les commentaires 😉

Le ”community manager” de SourceForge se rebiffe : ce n’est pas parce que la plateforme héberge une foultitude de projets libres morts ou non actifs que SourceForge est lui-même en train de mourir.

On ne peut lui donner tort, mais la grande question reste en suspens : pourquoi tout le monde (ou presque) s’en va désormais sur GitHub ?

Peut-être trouvera-t-on réponse dans les commentaires 😉

Le mythe de la mort de SourceForge

The myth of the death of SourceForge

Rich Bowen – 07 décembre 2012 – Notes in the Margin (blog personnel)
(Traduction : tcit, Sky, goofy, KoS, Tr4sK, audionuma, Asta, Rudloff)

Je suis le community manager de SourceForge. À ce titre, je vois tous les jours des tweets annonçant la mort imminente de SourceForge. La preuve fournie est le nombre important de projets morts sur SourceForge.

Cela reflète une profonde ignorance de la façon dont l‘open source (et le développement logiciel en général) fonctionne.

Une des choses qui font du développement logiciel un hobby irrésistible est que cela ne coûte presque rien d’échouer. Vous avez une idée ? Chouette. Essayez-la. Ça a marché ? Non ? Bah, ce n’est pas une grande perte. Passez à la prochaine idée. Mais publiez donc ouvertement vos notes pour que d’autres personnes puissent y jeter un coup d’œil et voir si elles peuvent faire mieux.

La plupart des projets de logiciels échouent. Désolé. C’est la réalité.

Ainsi, le fait que SourceForge contienne de nombreux projets ayant échoué n’est pas une indication de la mort de SourceForge. Cela indique son âge. SourceForge a 12 ans. Github est encore un bébé et n’a donc encore qu’un petit nombre de projets morts. Attendez quelques années et nous entendrons dire que Github est l’endroit où vont les projets pour mourir et que le nouveau truc à la mode est beaucoup mieux.

Ceci est un non-sens et n’est donc pas un bon instrument de mesure. Les forges open source sont un endroit où vous pouvez essayer une idée, à peu de frais et, si nécessaire, trouver là où ça échoue. Il est rare de réussir.

Bien sûr, cela amène la question qui est toujours posée : pourquoi ne purgeons-nous pas tous les projets morts ? Eh bien, si vous y réfléchissez quelques minutes, vous verrez que ce n’est pas faisable. Qui suis-je pour déterminer quel projet est mort et lequel ne l’est pas ? J’ai un projet vieux de 10 ans, que je n’ai pas touché depuis 8 ans mais que j’ai l’intention de réécrire ce week-end. Que se passerait-il si nous l’avions effacé la semaine dernière ? Plus important, les notes et le code source de votre projet « mort » ou « loupé » mènent souvent à un fork qui lui, réussit. Purger les références historiques ne rend service à personne.

Pendant ce temps, je passe des heures chaque jour à faire la promotion des nouvelles versions et des développements de projets open source très actifs et très passionnés. Il ne se passe pas une semaine où, avec un tweet pour chacune des nouvelles versions, ma femme ne me dit pas « wow, tu tweetes vraiment énormément ! » Un tweet à peu près chaque heure, 24 heures par jour, chaque jour des 9 derniers mois. Ça fait un paquet de projets actifs. Pas morts du tout.

C’est un grand honneur d’être le community manager de SourceForge, de travailler avec des dizaines de milliers de projets vivants et passionnés. SourceForge reste un élément très important dans l’écosystème open source, avec de nouveaux projets créés chaque jour. Certains de ces projets sont destinés à devenir des succès, d’autres non. C’est juste comme cela que ça marche, et ça n’indique le déclin d’aucune des forges open source où cela arrive.

Crédit photo : Joiseyshowaa (Creative Commons By-Sa)