Les réglementations open source ont des exigences de réussite inhabituelles. Découvrez comment les avocats open source peuvent aider leurs employeurs à trouver une voie viable.
Comme je l'ai partagé dans la première partie de cette série en deux parties , je suis un avocat open source chez Red Hat. Une partie importante de mon travail consiste à fournir des informations à d'autres entreprises, y compris leurs conseillers juridiques internes, sur la manière dont Red Hat adopte un modèle de développement entièrement open source pour créer des produits d'entreprise, et à répondre à leurs questions générales sur les licences open source. Après avoir entendu parler des succès de Red Hat, la conversation que ces avocats ont avec moi porte souvent sur la façon dont leurs organisations peuvent évoluer vers des organisations plus conscientes et plus compétentes en matière d'open source, et ils me demandent souvent comment ils peuvent améliorer leurs pratiques pour devenir plus compétents en matière d'open source. conseils juridiques aux employés de ses organisations. Dans ces deux articles, je partagerai ce que je dis habituellement aux conseillers juridiques d'entreprise sur ces sujets.
Trouvez toujours un chemin réalisable
Ce qui rend mon employeur, Red Hat, unique dans son utilisation des logiciels open source, c'est que notre modèle de développement commence par une communauté open source avec des milliers de contributeurs et aboutit à un produit final essayé, testé et fiable. Plus précisément, grâce à notre modèle de développement unique, nous commençons par des logiciels open source créés par la communauté et travaillons sur chaque projet pour renforcer la sécurité, corriger les bugs, corriger les vulnérabilités et ajouter de nouvelles fonctionnalités. Nous apportons ensuite ces améliorations à chaque projet afin qu'elles profitent à l'ensemble de la communauté open source. Les avantages de cette approche sont importants et comprennent :
- Tirer parti de l'innovation externe grâce à la collaboration entre les équipes internes et d'autres personnes extérieures à l'organisation ;
- Lorsqu'une communauté existante ou potentielle travaille sur le même problème que vous et peut collaborer, vous évitez les coûts et l'inefficacité liés au développement et à la maintenance d'une solution open source vous-même ;
- Grâce à une collaboration productive avec les partenaires et la communauté du projet en amont, la maintenance coûteuse des branches en aval du projet principal peut être évitée.
- Certaines entreprises sont tentées de créer des branches non publiques de code en amont parce que c'est un moyen rapide de résoudre un cas d'utilisation spécifique ou parce qu'elles ne souhaitent pas collaborer au sein de la communauté. Cependant, la charge de maintenance à long terme d'une telle branche peut être prohibitive en raison de l'augmentation des coûts de développement, de la perte d'interopérabilité et d'autres raisons. En revanche, la centralisation du développement dans la communauté d’origine en amont répartit les coûts de développement entre tous les participants.
À quelques exceptions près (telles que Red Hat), la plupart des organisations utilisant des logiciels open source disposent probablement d'un modèle de licence de logiciels propriétaires (ou l'équivalent SaaS) et licencient des logiciels propriétaires dans le cadre de leur activité. Ces organisations estiment disposer de composants logiciels qui leur confèrent un certain avantage concurrentiel et ne souhaitent pas que ces composants soient mis à la disposition de tiers dans des conditions open source. C'est compréhensible. Cependant, j'encourage tout avocat open source consulté sur de telles questions à inciter ses clients à adopter un modèle de développement open source, en particulier pour tous les logiciels indifférenciés et courants.
Par exemple, si votre entreprise développe une application pour téléphones mobiles et que vous avez besoin d'un module logiciel pour lire et écrire des fichiers image PNG, il sera beaucoup moins cher d'utiliser l'un des modules logiciels PNG open source populaires sur GitHub. L'encodage et le décodage des images PNG peuvent être indiscernables pour votre entreprise, alors pourquoi consacrer un temps précieux à l'ingénierie à écrire votre propre version ? De plus, l'écriture de votre propre module pour cette fonctionnalité peut également entraîner des problèmes de compatibilité avec d'autres logiciels utilisant des modules open source couramment disponibles. Pourquoi est-ce? Bien que vos modules et modules open source puissent avoir été écrits pour encoder et décoder la spécification PNG publiée, la spécification peut parfois être interprétée différemment et des erreurs d'implémentation peuvent survenir. Tous ceux qui utilisent le même module pour exécuter cette fonctionnalité garantissent la compatibilité pour la majorité des utilisateurs et réduisent les coûts de développement et de maintenance.
Il est également important de réaliser que vous devrez peut-être que certains logiciels restent propriétaires et ne soient pas soumis aux conditions open source. En fonction de l'architecture logicielle de votre système et de la licence open source utilisée, le code logiciel destiné à rester propriétaire peut devenir soumis aux termes de la licence open source à moins que certaines mesures (au-delà de la portée de cet article) ne soient prises. C'est là qu'il serait utile de fournir des services de conseil aux clients concernant la sélection et l'architecture des licences.
Trouver des solutions flexibles
Les organisations qui auparavant accordaient principalement des licences sur des logiciels propriétaires augmentent progressivement leur utilisation de logiciels open source, mais les exigences en matière d'examen et d'approbation sont susceptibles de croître (même de manière exponentielle, d'après mon expérience). Ces organisations peuvent avoir des difficultés en raison de contraintes de ressources. Voici quelques solutions flexibles que vous pouvez adopter.
Autoriser et déléguer à d’autres
Les avocats ne peuvent et ne doivent pas jouer le rôle de gardiens. Cela est inefficace et entraînera certainement des goulots d'étranglement dans les délais de développement et de publication, créant ainsi de la frustration et une perte de revenus. Au lieu de cela, le pouvoir d’approbation devrait être accordé à des personnes compétentes en matière de gestion et d’ingénierie de produits ou de projets. Cela permet aux organisations de rester efficacement flexibles. L’éducation de vos clients (voir section suivante) est essentielle pour y parvenir.
Une approche que j'adopte consiste à fournir une formation open source à l'ensemble de l'organisation d'ingénierie afin qu'elle puisse faire des choix de base en matière de modèle de licence et d'architecture, tout en fournissant une formation plus spécialisée aux développeurs de logiciels pour leur permettre de fournir des conseils et des décisions plus complexes. Envisagez également des limites claires sur les autorisations à chaque niveau, y compris les types de problèmes et de décisions qui doivent vous être signalés en tant qu'avocat open source. Le niveau d'autorisation spécifique de votre organisation dépendra de l'expérience de votre équipe en matière d'open source et de sa sensibilité à certains problèmes open source.
Éduquer les clients
J'ai trouvé que la formation est l'un des outils les plus efficaces pour migrer votre organisation vers une organisation plus open source. La formation de vos ingénieurs logiciels et chefs de produits est essentielle. Permettez-moi de développer.
Bien que vos ingénieurs logiciels soient à la pointe et soient généralement très compétents en matière d'open source et de licences logicielles, il est toujours important de les former en fonction des exigences spécifiques de votre organisation. Par exemple, votre entreprise peut autoriser uniquement l'utilisation de licences open source permissives et peut avoir certaines exigences concernant sa notice de droit d'auteur et la disponibilité du code source. Pour éviter des problèmes de développement qui doivent ensuite être corrigés (une pratique coûteuse et longue), il est préférable de former les ingénieurs afin de minimiser la possibilité de comportements inappropriés, en particulier au début de tout processus de développement (voir section suivante).
Les chefs de produits doivent également recevoir une formation. Dans de nombreuses entreprises, les chefs de produit sont responsables des quatre aspects classiques du marketing (produit, prix, positionnement et promotion) et sont responsables de l'ensemble du cycle de vie d'un produit, du berceau à la tombe. Chaque aspect du travail d’un chef de produit peut être affecté par l’utilisation de logiciels open source. Pour les mêmes raisons mentionnées ci-dessus, il leur est utile de comprendre les exigences liées à l’utilisation de logiciels open source. De plus, et plus important encore, l’influence significative des chefs de produit au sein d’une organisation signifie qu’ils sont souvent en mesure d’apporter les changements nécessaires aux processus et aux politiques. Les chefs de produit peuvent être l’un de vos plus ardents défenseurs des changements de processus en faveur de l’ouverture.
La détection précoce
Résoudre les problèmes de licences open source vers la fin du processus de développement est difficile et coûteux. A mesure que la date de sortie du logiciel approche, l'architecture et les modules logiciels open source sont choisis et difficiles à changer. Si un problème est détecté, tel qu'un logiciel « copyleft » intégré dans un module logiciel propriétaire (lorsque ce module propriétaire n'est pas destiné à être soumis aux termes open source), modifier l'architecture ou le module à ce stade de développement peut être difficile et coûteux. cher. Au lieu de cela, le processus d'analyse architecturale et de sélection des modules open source doit avoir lieu dès le début du processus de développement afin que des corrections moins coûteuses et plus efficaces puissent être apportées.
Les « récompenses » de la réglementation open source
Pratiquer la réglementation de l'open source est une carrière enrichissante car la capacité d'influencer une organisation dans une direction « ouverte » présente de grands avantages. Le succès dépend de votre capacité à trouver des solutions réalisables et flexibles à mesure que votre organisation se développe et mûrit.
À propos de l'auteur : Jeffrey R. Kaufman est conseiller juridique principal au sein de l'équipe juridique open source de Red Hat, le premier fournisseur mondial de solutions logicielles open source. Il est également professeur adjoint de droit à l'Université de Caroline du Nord. Avant de rejoindre Red Hat, Jeffrey a été conseiller en brevets et open source pour Qualcomm.
Profil du traducteur : Xue Liang, directeur du département des affaires Internet de Jihuizhijia Intellectual Property Consulting Company, est doué en analyse de brevets, en mise en page de brevets, en suivi des concurrents, en analyse FTO et en analyse des risques de propriété intellectuelle des logiciels open source. Il s'engage à fournir aux sociétés Internet. et des entreprises de haute technologie proposant des services de conseil en propriété intellectuelle.
