Tribunes

Florange Telecom

L'approche radicaliste de l'architecture du Web : l'assembleur

Big Dataxe

Le Big Data individuel

La comptine du cloud

Toute les tribunes

La vidéo du moment
Actualité marchés verticaux

Les entreprises françaises sont assises sur une mine d'or inexploitée

par martine joulia-cubizolles
le 25/11/2014 à 11:19

Markess identifie les 6 évolutions majeures d'ici 2016 en matière de stockage

par pascalie
le 24/11/2014 à 03:21

Sécurité des données entreprises : les salariés traitent (encore) la question par dessus la jambe

par durand
le 12/11/2014 à 09:16

E-commerce : comment conformer son tunnel de commande à la loi Hamon

par Damien
le 08/11/2014 à 11:21

Quelle santé pour demain ?

par Jean Mourain
le 07/11/2014 à 10:41

Rechercher
Services
Logo_abonn Job Les derniers communiqués de presse Proposer un communiqué de presse
Fils RSS : Top 10 quotidien

A coeur ouvert
Par Jean-Marie Chauvet

lundi 26 juillet 2010

Il y a environ un mois, Consona Corporation un spécialiste du build-up financier dans le secteur des progiciels de gestion intégrés (PGI) et de la gestion de la relation client (GRC) faisait l'acquisition de l'PGI/GRC Open Source emblématique Compiere. Cette acquisition d'un projet Open Source d'une si grande visibilité par un tenant de l'économie « propriétaire » de l'industrie du logiciel, provoque évidemment un vague à l'âme certain dans la communauté du libre et pousse même les animateurs-fondateurs de Compiere (Jorg Janke et Kathy Pink) à s'interroger sur l'échec d'un des (du ?) modèles du logiciel libre.



Open Source
 

En 2001, ceux-ci avaient fait le choix de publier en Open Source leurs développements initiaux d'un PGI, préférant ce modèle où ils voyaient l'abandon des revenus de licences largement compensé par l'effacement des coûts de vente et l'accroissement de visibilité marketing à celui, traditionnel, de l'éditeur de logiciels dans lequel habituellement les revenus de licences financent les coûts et la force de vente, et les revenus de maintenances contribuent au financement de la recherche et du développement. La formation devint rapidement, avec le succès grandissant, l'articulation du business model de Compiere, se transformant en véritable avant-vente prépayée. Le second moteur du développement, durant cette période, fut le réseau de partenaires qui vendait et installait Compiere, prenant en charge l'implémentation et le support technique de premier niveau (Souvent, certains développaient leurs propres modules complémentaires - propriétaires - à des fins de différentiation).
 

Avec la diffusion croissante de Compiere via ses partenaires commerciaux, cet équilibre subtil entre développement et produits d'une part, et services, implémentation et support d'autre part — fondé sur la confiance entre la communauté et un réseau commercial — commençait de laisser les fondateurs sur leur faim. À la recherche d'une part plus importante des revenus totaux engendrés par le logiciel libre, Compiere, après une levée de fonds auprès d'investisseurs en capital-risque ($6m en juin 2006 auprès de New Enterprise Associates) et, en conséquence, le déménagement obligatoire d'Europe vers la Silicon Valley — Eheu ! Eheu ! Fugaces labuntur ETI... Ô, Europe, où donc fuient tes ETI ? — la société Compiere chercha à rééquilibrer la relation avec le réseau partenarial. Les deux mesures prises à l'époque visaient à la fois à étendre ce réseau, passage de la licence MPL à la GPL plus attractive, et à mieux le contrôler, en contractualisant un reporting des partenaires agréés sur leur processus de prospection et de vente.
 

Cette redéfinition ne fut pas partout acceptée de bonne grâce et elle est généralement considérée comme une des principales raisons d'un fork du projet Compiere qui devait donner naissance à Adempiere. L'idée, chuchotée par les investisseurs au creux de l'oreille des managers, fut ensuite d'accroître les revenus en proposant une version « professionnelle » payante de Compiere en plus de l'offre libre. Ce modèle, souvent appelé «  Open Core  », est sujet aujourd'hui à de bouillonnantes controverses.
 

Dans la variante Open Core, les stratégies de licences propriétaires et de licences libres sont savamment intriquées : l'éditeur offre un noyau qui est libre ainsi qu'une ou plusieurs versions propriétaires, fermées, avec des extensions particulières. (Ces versions, souvent qualifiées de professionnelles, sont obtenues soit en ajoutant au noyau Open Source des modules non-libres, soit en « dégradant » la version Open Source par basculement de certains de ses modules dans le domaine propriétaire, ne laissant libre que son coeur de code.) Inutile de dire que ses opposant reprochent évidemment à la variante Open Core de ternir la fleur immarcescible de l'Open Source ! — et avec quelle pugnacité encore !
 

Les héros de l'aventure Compiere attribuent finalement leur chute récente à leur incapacité à « exécuter » — pour poursuivre l'emprunt aux américanismes modernes du private equity —, simplement à appliquer cette stratégie plus traditionnelle d'éditeur de logiciels dans le contexte d'un projet fondamentalement Open Source. Sortie de scène d'une grande élégance.
 

Mais n'y a-t-il vraiment à invoquer que cet écueil, à la merci duquel, somme toute, naviguent toutes les équipes lancées dans l'aventure de la startup ?
 

Open Core
 

Simon Phipps, directeur à l'Open Source Initiative, vitupère brillamment la variante Open Core, en réponse à Mårten Mickos — ex-CEO de MySQL, maintenant présidant aux destinées d'Eucalyptus Systems, l'infrastructure Open Source de cloud computing — qui lui n'y voit rien de nouveau, pointant vers les licences de la Fondation Apache, et surtout, rien de dangereux ni de répréhensible pour le logiciel libre.
 

Phipps, au contraire, fait une lecture critique de la variante Open Core qu'il accuse d'exploiter sciemment et sans scrupules les failles des licences Open Source, inévitables dit-il dans des systèmes d'une telle complexité. Dans sa conclusion, il rappelle que cette critique est loin d'être abstraite ou virtuelle : pour l'OSI, les quatre libertés fondamentales de l'Open Source, d'utilisation, de modification, d'étude et de distribution sans restriction, ont permis de créer un vaste marché du logiciel économique et flexible. Tout effort délibéré de dévoiement de ces libertés fondatrices, se drapant de surcroît du lin blanc de la vertu Open Source, mérite alors d'être dénoncé.
 

Ce débat appelle deux commentaires qui peuvent peut-être éclairer les enjeux sous-jacents.
 

La variante Open Core illustre le schisme en germe dans l'Open Source, d'ailleurs présent dès les débuts de sa formalisation progressive de ces dernières années hors des limbes du hacking Stallmanien, entre les moyens et la fin. Si l'on considère l'Open Source comme une fin en soi, son statut est comparable à celui d'une marque qu'il convient effectivement de protéger et les progrès perçus ou constatés de l'Open Core appellent naturellement une réaction. En revanche, si l'on considère le modèle Open Source comme un instrument au service d'une fin, comme par exemple celle, louable et légitime, d'abaisser le coût du développement des logiciels — mettons pour établir ou développer une société éditrice de logiciels privée ou publique — il n'y a pas de « marque Open Source » à protéger, juste une description d'un jeu de licences de logiciel, auquel se conformer, mais indépendant des stratégies business qui les mettent en oeuvre.
 

La modernisation des licences du libre
 

La seconde remarque oppose à Simon Phipps que sa vision de la relation entre projets communautaires Open Source et entreprises commerciales de l'industrie (propriétaire) du logiciel est de trop caricaturale en 2010. Voyons-en pour preuve l'effort majeur de modernisation de la licence MPL dans lequel la Fondation Mozilla vient de s'engager.
 

L'époque où d'ardents débats ébranlaient la communauté sur des questions aussi graves que « Emacs ou vi ? », « BSD ou GPL ? », « GNU/Linux ou Linux ? » est définitivement révolue. Le long et laborieux contentieux SCO a mis fin à ces enfantillages et la crise provoquée par cette jurisprudence a projeté la communauté du libre dans l'âge adulte des batailles de prétoires contre l'adversaire propriétaire.
 

Comme l'illustrent le cas SCO et le cas Jacobsen v. Katzer et al. aux États-Unis, la communauté du libre doit aujourd'hui prendre en compte dans la rédaction de ses licences la possibilité de procès « irrationnels » dans lesquels aucune des parties n'a réellement d'espoir de gagner mais s'engagent néanmoins au tribunal — ce qu'a démontré le cas SCO avec une ampleur inédite. Comment faire ? Observer les développements dans le secteur des technologies et adapter la licence aux nouvelles menaces qu'ils peuvent entraîner : c'est ce qui a mené à la GPL v3. Observer ce qui se passe dans les tribunaux et intégrer d'emblée la jurisprudence au fur et à mesure qu'elle est constituée : c'est ce qui se passe avec la révision en cours de la MPL.
 

Dans le cas Jacobsen v. Katzer et al., il est question du projet Open Source JMRI emmené par le hobbyiste des trains électriques Robert Jabobsen (une suite de logiciels de pilotage et contrôle de petits trains électriques), attaqué sous une allégation de violation de brevets par Matt Katzer de KAM Industries. (C'est Toy Story au pays de l'Open Source !) La licence libre en discussion est ici l'Artistic License, probablement l'une des plus problématique de l'arsenal de l'OSI. La cour fédérale avait au final et en appel prononcé un jugement favorable à l'Open Source en considérant que les conditions figurant explicitement dans une licence Open Source devaient être considérées comme des conditions de copyright, qu'en conséquence s'appliquait la loi sur le copyright et, dans le cas d'espèce, le droit de la communauté à contrôler l'usage qui est fait du logiciel. (Notons qu'il s'agit de la loi américaine, i.e. fédérale, du copyright et que la question de la validité de la transposition aux droits du copyright dans d'autres pays est ouverte.) Cette notion jurisprudentielle est désormais prise en compte dans le projet de modernisation de la licence MPL.

Pour la communauté du libre, la difficulté principale dans l'orchestration de ces révisions indispensables réside sans doute dans le recrutement d'avocats qui ne soient pas complètement inféodés aux intérêts corporatistes de l'industrie du logiciel et prêts, au contraire, à imaginer les lignes de défense contre les attaques ultérieures de leurs pairs.

 



Les 10 derniers articles mis en ligne