Page suivante Page précédente Table des matières

8. En quoi le prix d'acquisition pose problème

L'ouverture des sources complique la tâche de capturer un prix d'acquisition direct sur le logiciel. Ce n'est pas une difficulté technique : le code source n'est ni plus ni moins copiable que les binaires, et l'application des lois de propriété intellectuelle visant à faire respecter les copyrights et les licences afin de permettre la collecte des prix d'acquisition n'a pas de raison d'être plus difficile dans le cas des produits à sources ouverts que dans le cas des produits à sources fermés.

La difficulté est plutôt inhérente au contrat social qui sous-tend le développement à sources ouverts. Pour trois raisons se renforçant mutuellement, la plupart des licences à sources ouverts interdisent la plupart des restrictions sur l'utilisation, la redistribution, et la modification, qui pourraient faciliter la capture de revenus directement liés à la vente. Pour comprendre ces raisons, il nous faut examiner le contexte social dans lequel ces licences ont évolué ; la culture hacker sur l'Internet.

En dépit des mythes qui circulent encore largement (en 1999), en dehors de celle-ci, sur la culture hacker, aucune de ces raisons n'a pour origine une hostilité au marché. Même si une minorité de hackers demeurent hostiles aux motivations lucratives, la communauté, en général, souhaite coopérer avec des distributeurs de Linux à but lucratif comme Red Hat, SuSE, Caldera, ce qui montre que la plupart des hackers sont heureux de travailler avec le monde des entreprises quand celui-ci sert leurs fins. Les véritables raisons pour lesquelles les hackers apprécient peu les licences permettant l'appropriation d'un flux de revenus direct sont plus subtiles et intéressantes.

L'une de ces raisons est en rapport avec la symétrie. Alors que la plupart des développeurs à sources ouverts ne sont pas intrinsèquement opposés à l'idée que d'autres profitent des cadeaux qu'eux font à la communauté, la plupart exigent également qu'aucune partie (à l'exception possible de celle qui est à l'origine d'une portion de code) ne se retrouve dans une position privilégiée pour tirer profit d'un projet. T Codeur-Lambda accepte que Toto & compagnie puisse gagner de l'argent en vendant ses logiciels ou ses correctifs, si T. C-L peut lui aussi, potentiellement, en faire autant.

Une autre de ces raisons est en rapport avec les conséquences non désirées. Les hackers ont observé que les licences qui incluent des restrictions et des taxes pour l'utilisation « commerciale » ou la vente (la forme la plus courante de tenter de capturer une valeur commerciale directe, et ce n'est pas à première vue un désir déraisonnable) ont divers effets secondaires dissuasifs. L'un d'entre eux est de faire planer l'ombre des poursuites en justice sur les activités de redistribution dans des compilations sur CD-ROM peu onéreux, qu'on souhaiterait idéalement encourager. Plus généralement, les restrictions sur l'utilisation, la vente, la modification, la distribution (et d'autres complications des licences) entraînent un surcoût temporel et financier pour s'assurer qu'on respecte bien toutes les conditions et (alors que le nombre de paquetages manipulés augmente), une explosion combinatoire d'incertitudes et des risques juridiques réels. De tels résultats sont considérés dommageables, et la pression sociale est donc forte qui tend à promouvoir des licences simples et dénuées de telles restrictions.

La dernière raison, la plus critique aussi, est en rapport avec la préservation de la revue par les pairs et de la dynamique de la culture du don décrite dans [HtN] . Les restrictions sur les licences mises au point pour protéger la propriété intellectuelle ou pour capturer des sources de revenus ont souvent l'effet de rendre impossible toute scission du projet (c'est par exemple le cas de la licence de la société Sun, prétendue « sources communautaires » (Community Source), mise au point pour les programmes Jini et Java). Même si on n'aime pas les scissions et si on n'y a recours qu'en dernière extrémité (pour des raisons exposées en détail dans [HtN] ), ce dernier recours a une importance capitale dans les cas où le mainteneur est incompétent ou déficient (dans les cas par exemple où il fait le choix d'une licence plus fermée).

Les hackers de la communauté lèvent pour certains le pied sur l'argument de symétrie ; c'est pourquoi on tolère des licences comme la NPL de la société Netscape, qui donne des privilèges d'exploitation à ceux de qui le code est issu (spécifiquement, dans le cas de la NPL, le droit exclusif d'utiliser le code ouvert du projet Mozilla dans des produits dérivés, y compris à sources fermés). Moins nombreux sont ceux qui ferment les yeux sur la raison tendant à éviter les conséquences non désirées, et personne n'accepte l'impossibilité de toute scission (c'est pourquoi les schémas de « licences communautaires » de la société Sun pour Jini et Java ont été rejetées en masse par la communauté).

Ces raisons expliquent les clauses de la définition de l'Open Source, qui fut écrite pour exprimer le consensus de la communauté des hackers à propos des spécificités critiques des licences standard (la GPL, la licence BSD, la licence MIT, et la licence Artistic). Ces clauses ont l'effet (mais pas l'intention) de rendre extrêmement difficile la capture directe d'une valeur commerciale.


Page suivante Page précédente Table des matières