cocoon-users-fr mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject GPL vs ASL (était Re: [ANNONCE] Myotis 0.80)
Date Sun, 03 Apr 2005 17:22:25 GMT
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:users-fr-unsubscribe@cocoon.apache.org
Autres commandes : mailto:users-fr-help@cocoon.apache.org


Mime
View raw message