Sylvain Wallez wrote:
FrÃdÃric Glorieux wrote:
vous ne pourrez avoir comme contributeurs que des gens qui acceptent les contraintes de la GPL, c'est à dire soit qui font du non commercial, soit qui font du commercial non redistribuà (comme un site), mais pas du projet pour un client.
??? je ne comprends pas bien ce point. Et quand le client demande du GPL ?
Il faut l'Ãduquer pour lui expliquer qu'il garantit peut-Ãtre la libertà du code dont il finance le dÃveloppement, mais n'en retirera pas les avantages que pourraient donner un vrai dÃveloppement communautaire...
Bon, je vais quand mÃme expliciter un peu cette dÃclaration à l'emporte-piÃces. Ce que j'exprime ici est bien entendu mon opinion personnelle, rÃsultat de mon expÃrience et mes constats aprÃs 5 ans passÃs à contribuer chez Apache et construire des projets commerciaux avec du logiciel opensource.
-- oOo --
A mon avis, la licence GPL est trÃs bien adaptÃe à des produits finis, c'est à dire destinÃs à Ãtre utilisÃs tels quels et non à former la base d'un dÃveloppement spÃcifique plus important. Dans cette premiÃre catÃgorie, on trouve tous les outils ligne de commande d'Unix et les progiciels type Abiword, Inkscape, Gimp etc. Ils sont destinÃs à Ãtre utilisÃs tels quels mais pas Ãtendus. La licence GPL permet une utilsation non restrictive par le plus grand nombre, mÃme dans un cadre commercial (utiliser gcc pour compiler du code commercial ne pose pas de problÃmes), mais impose la redistribution des Ãvolutions et extensions.
Dans le cas des librairies ou infrastructures destinÃes à la construction de quelque chose de plus grand (Cocoon ou... SDX), les contraintes de la GPL interdisent carrÃment toute utilisation dans un cadre commercial, puisque ce qu'on construit au dessus devient forcÃment un travail dÃrivÃ, devant donc Ãtre redistribuÃ.
Cette redistribution imposÃe fait que les utilisateurs commerciaux (sociÃtÃs de services, services informatiques des entreprises, etc) vont se contenter d'utiliser les logiciels GPL de faÃon externe et vont prendre grand soin à Ãviter d'en faire des dÃrivations pour ne pas prendre le risque de devoir redistribuer l'intÃgralità de ce qu'ils ont construit au dessus pour leurs clients.
Bilan, les communautÃs qui dÃveloppement les logiciels d'infrastructure en GPL sont soit des communautÃs fermÃes (un Ãditeur qui dÃveloppe un produit "libre" pour gagner plus facilement des contrats de service autour de son produit, un prestataire qui dÃveloppe en GPL suite à une demande de son client institutionnel), soit des communautÃs rÃellement bÃnÃvoles, c'est à dire ne dÃveloppant pas le logiciel GPL dans le cadre de leur actività professionnelle.
On perd donc ÃnormÃment en nombre d'utilisateurs potentiels et en sociÃtÃs qui pourront investir pour contribuer parce qu'elles y trouvent leur compte par ailleurs.
-- oOo --
La licence Apache (ASL -- Apache Software Licence) n'impose quand à elle que deux choses : l'obligation d'attribution (marquer dans la doc "ce logiciel utilise des produits dÃveloppÃs par la fondation Apache") et l'interdiction d'utiliser le nom du produit utilisà ou de "Apache" pour votre propre produit. A part Ãa, vous faites ce que vous voulez : modification, renommage, extension, vous pouvez mÃme le vendre.
C'est la porte ouverte aux profiteurs, allez-vous dire ? Oui, certainement. Mais ceux qui tentent Ãa se rendent compte rapidement que c'est peine perdue. Il y a eu dans l'histoire de Cocoon une sociÃtà qui a repris l'intÃgralità du code, a tout renommà et en a fait son propre produit. Il ne l'ont jamais vendu : pourquoi payer pour un logiciel devenu propriÃtaire alors que la souche opensource dont il est issu continue son Ãvolution, aussi bien corrective que fonctionnelle ?
Les utilisateurs commerciaux ayant les coudÃes franches, ils utilisent le logiciel sous licence ASL à toutes les sauces pour toutes sortes de projets. Il en ressort forcÃment des bugs et de nouveaux besoins fonctionnels de niveau infrastructure, c'est à dire loin du contexte mÃtier spÃcifique du projet dÃveloppÃ.
Puisqu'il n'y a aucune contrainte de redistribution, les sociÃtÃs corrigent donc les bugs ou font de petites Ãvolutions. Mais elles se retrouvent alors avec une branche parallÃle interne alors que la souche opensource continue à Ãvoluer. Quel intÃrÃt de garder ces modifications alors qu'elles ne sont pas liÃes à la vraie valeur ajoutÃe mÃtier construite dans le cadre du projet ? Aucun. Donc ces modifications sont restituÃes à la communautà et on commence à contribuer.
Et c'est ainsi que la trÃs grande majorità des contributeurs aux logiciels avec des licences type Apache sont des personnes qui contribuent sur leur temps salariÃ, mÃme s'ils sont aussi des passionnÃs et donc en font en plus sur leur temps perso. Apache est donc pour ces entreprises une sorte de dÃpartement R&D partagÃ, chacun construisant sa valeur ajoutÃe spÃcifique au dessus de la souche commune.
-- oOo --
Donc, pour en revenir au client qui demande du GPL, il faut lui expliquer qu'en accordant une libertà (ASL) plutÃt qu'en l'imposant (GPL), il permet la formation d'une communautà d'entreprises qui vont contribuer à la souche opensource. Il y aura certes des "consommateurs" qui profiteront du logiciel sans jamais rien contribuer, mais ceux-ci ne sauront de toute faÃon jamais exploiter aussi bien le logiciel que ceux qui participent à la communautÃ.
Au final, donc, un client qui finance le dÃveloppement d'un logiciel opensource sous licence ASL sera gagnant parce que l'ÃcosystÃme qui se constituera autour de la souche qu'il aura financÃe vivra bien au-delà de ce qu'il aura dÃpensà initialement, sans qu'il ait besoin de rÃinjecter continuellement des fonds pour des Ãvolutions.
C'est le discours que je fais trÃs rÃguliÃrement, et il passe trÃs bien. J'espÃre que certains "clients" sont sur cette liste et l'entendront :-)
Sylvain
-- Sylvain Wallez Anyware Technologies http://apache.org/~sylvain http://anyware-tech.com Apache Software Foundation Member Research & Technology Director
--------------------------------------------------------------------- Liste francophone Apache Cocoon -- http://cocoon.apache.org/fr/ Pour vous desinscrire : mailto:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
