cocoon-users-fr mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: GPL vs ASL (était Re: [ANNONCE] Myotis 0.80)
Date Mon, 04 Apr 2005 09:04:15 GMT
Frédéric Glorieux wrote:

>
> Merci beaucoup Sylvain pour cette réponse. J'étais déjà d'accord avec 
> les 4 lignes, je me permettrais juste quelques remarques, qui 
> pondèrent mais je ne crois pas contredisent le propos.
>
>>> Frédéric Glorieux wrote:
>>
>
>>>> ??? je ne comprends pas bien ce point. Et quand le client demande 
>>>> du GPL ?
>>>
>
>> 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é.
>
>
> Parmi les développeurs de SDX, je voulais ajouter des précisions. Je 
> ne suis pas autorisé à m'exprimer au nom de la communauté, je n'ai que 
> quelques opinions qui n'engagent que leur auteur.
>
> Le choix de licence a été fait par le commanditaire public. Je n'ai 
> pas d'opinion à avoir là-desssus, mais je suppose qu'il y a eut à 
> l'époque (2000-2001, notez le tout de même) des discussions qui ne 
> sont pas indemmes de politique.


Certainement.

> C'est une décision difficile pour une administration d'investir de 
> l'argent, en sachant que cela peut directement servir au profit des 
> entreprises.


Là encore, une question politique : un des rôles de l'état est aussi, à 
travers le financement de développements publics, de favoriser le 
développement économique. La création d'un écosystème est certainement 
plus efficace pour cela que le financement pur et simple du 
développement par des marchés publics. Ceux-ci sont toutefois 
nécessaires pour initialiser la naissance de l'écosystème.

Comment s'assurer ensuite que l'écosystème favorise l'industrie 
nationale, et pas le monde entier ? La réponse théorique est "on ne peut 
pas". Mais la pratique est différente. Le financement public, plutôt que 
de servir au financement d'un produit, peut servir à la création de 
l'écosystème en faisant intervenir plusieurs prestataires (sur des 
parties différentes du système, pour qu'ils ne se marchent pas sur les 
pieds), qui auront de part la licence la possibilité d'aller plus loin 
que le financement initial à travers leur propre activité commerciale.

Par ailleurs, nous avons la chance (pour une fois!) d'utiliser une 
langue qui n'est pas le français : on peut donc réduire l'étendue de 
l'écosystème en n'utilisant que le français.

Petite parenthèse au sujet des prestataires multiples : j'ai dit que la 
licence a une influence sur la communauté qui se forme autour d'un 
logiciel. Un autre facteur essentiel est la modularité et la 
segmentation de l'architecture : il faut qu'un nouvel arrivant puisse 
entamer sa prise de connaissance par un "petit bout" du système, sans 
avoir besoin de maîtriser et comprendre l'ensemble du logiciel, ce qui 
le découragerait rapidement. De petit bout en petit bout, il pourra 
arriver progressivement à une connaissance complète.

> Je constate et doit me rendre à l'opinion de Sylvain sur l'efficacité 
> du modèle économique de Cocoon. Je ne pense pas que la licence 
> explique tout. Il y a aussi la beauté de l'idée, une communauté 
> directement internationale, l'adossement à des gros derrière Apache...


Ah, les "gros" derrière Apache... Certes, certains projets sont des 
donations d'IBM, BEA, Sun et sont développés en bonne partie par leurs 
employés. Malgré tout, une des contraintes permettant à un projet de 
sortir de l'incubateur est la nécessaire diversité de sa communauté de 
développeurs : aucune société ou entité ne doit être vitale à la survie 
du projet [1]. C'est une condition essentielle pour que le projet vive, 
survive à d'éventuels changements stratégiques du donateur initial et 
aie suffisamment de cadres d'utilisation différents pour assurer son 
adaptation et son évolution.

Il faut considérer un logiciel comme un organisme vivant : il doit 
évoluer et s'adapter à son environnement ou mourir. L'environnement est 
constitué des utilisateurs. Sans utilisateurs, il meurt. Les "agents 
mutagènes" sont les développeurs, qui réagissent aux stimulations de 
l'environnement (ils en font partie aussi, d'ailleurs).

> Peut on imaginer l'état français, ou l'Europe, membre d'Apache ?


Non, puisque Apache ne considère pas les organisations, mais uniquement 
les individus, même si le travail de ceux-ci est bien évidemment financé 
par quelqu'un. Cette attitude peut sembler "autruche" ou hypocrite, mais 
dans la pratique un grand souci est apporté au fait que les directions 
prises par les projets ne soient pas directement liées aux intérêts 
particuliers d'une entreprise au mépris de ceux de la communauté. C'est 
ce que permet aussi la contrainte de diversité évoquée plus haut.

> S'il on considère l'effort juridique fait dernièrement 
> <http://www.cecill.info/index.fr.html>, il y a déjà tout simplement un 
> problème, licence GPL comme Apache n'ont pas de sens en droit français 
> (théoriquement, c'est de même pour la plupart des pays d'Europe 
> continentale, même si la jurisprudence commence à régler des cas, 
> avant la loi). Autrement dit, GPL ou Apache, légalement, ne protègent 
> rien devant un tribunal français.


C'est fort possible. Et même aux Etats-Unis d'ailleurs où ces licences 
n'ont jamais été "testées" dans des tribunaux. N'étant pas un juriste je 
ne peux pas me prononcer sur ce sujet, je discute simplement l'esprit de 
ces licences par les contraintes qu'elles imposent. Par ailleurs, la 
licence Cecill me paraît plus apparentée à la LGPL que la GPL. Et la 
LGPL conditionne à mon avis beaucoup moins la communauté que la GPL.

Reste que Cecill, avec les notions de "module statique" et "module 
dynamique" ne prend pas vraiment en compte les environnements comme Java 
ou les langages de script.

> Imaginons, une société française pourrait reprendre tout le code de 
> MySQL, le modifier et en faire son produit. MySQL.com ne peut pas 
> l'attaquer en France (sauf nouvelle jurisprudence à l'occasion), mais 
> MySQL.fr n'a pas intérêt à chercher à vendre aux Etats-Unis. C'est 
> commercialement et technologiquement idiot, mais cela relativise un 
> peu les débats sur les licences.
>
> A mon sens, le problème essentiel, c'est de réussir son coup. Dans un 
> marché, on sait qu'il y a facilement 9 fausses bonnes idées sur 10 qui 
> consomment des jours et des jours de dev, qui vivotent ou s'oublient. 
> C'est vrai pour le commercial, comme pour le libre.
>
> En théorie, que Cocoon soit GPL ne serait pas vraiment bloquant. 
> Combien de sociétés modifient réellement le code ?


Si ça serait bloquant : combien de sociétés *utilisent* réellement le 
code ? Tout ceux qui développent une appli avec Cocoon !

C'est là qu'est le problème de la GPL : si on *utilise* le code de 
Cocoon pour développer son projet, alors tout le projet doit être en GPL.

> Ou serait le problème de devoir exposer un générateur ou une action 
> sur un entrepôt quelconque pour être en conformité avec la lettre de 
> la GPL (même si ce n'est pas vraiment l'esprit) ? En tous cas pour 
> SDX, la licence n'a gêné personne, public comme privé (d'autant plus 
> que comme dit plus haut, cela n'a pas de valeur jurique en France).


Bon, pavé dans la mare (et je reconnais être totalement ignorant sur la 
question) : combien de projets non publics utilisent SDX ?

> Cette remarque ne vient pas contredire les faits décrits pas Sylvain, 
> mais relativise. <http://www.orbeon.com/> sort un comparable à Cocoon 
> en LGPL (notez bien le "L", c'est un cas qui n'est pas envisagé par 
> Sylvain, une licence beaucoup plus permissive que la GPL).


Le sujet était "GPL vs ASL". Comme je l'ai dit plus haut, la LGPL, à mon 
avis, pose beaucoup moins de problèmes dans la formation d'une 
communauté diverse que la GPL, même s'il est parfois délicat de définir 
où s'arrête l'extension (qui doit être redistribuée) et ou commence 
l'utilisation (qui n'a pas besoin de l'être), particulièrement avec les 
langages objets ou à linking dynamique comme Java.

Donc, autant je n'aime pas la GPL pour du logiciel d'infrastructure (sur 
lequel on développe ses projets), autant la LGPL est beaucoup plus 
acceptable, à condition d'en connaître les limites.

> Pensez vous que cela suffise à créer une grande communauté de 
> développeurs autour ? Même si tout le code était dans le domaine 
> public (encore plus permissif qu'Apache), est-ce que cela changerait 
> les rapports de force, les masses en présence ? Je ne pense pas qu'une 
> société s'engage dans une technologie au seul regard de la license, 
> elle calcule aussi les compétences en présence, la pérennité des 
> apprentissages nécessaires pour se mettre à une nouvelle, et puis tout 
> bêtement, si c'est bon et que cela marche bien.


Bien sûr ? Mais c'est le problème de l'oeuf et de la poule. On n'a pas 
encore inventé la machine à produire toute seule les logiciels (ça 
serait super cool, mais on serait tous au chômage !) et le logiciel 
reste donc la création de personnes. Et si le groupe est suffisamment 
important, avec des contextes d'utilisations suffisamment variés, alors 
le logiciel sera d'autant plus pertinent, vivant, etc.

Et on revient à la nécessaire vitalité et diversité de la communauté ;-)

> [...]
>
>> 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.
>
>
> Apache n'est probablement pas la seule licence qui permet ce modèle 
> économique, mais oui, produire sous licence "libre" assouplit 
> certaines difficultés de la propriété intellectuelle en entreprise. Ne 
> parlons pas des majors (genre Microsoft), mais pour la taille 
> habituelle de ce qui se trouve en France, il y a des cas difficiles à 
> trancher.


Encore une fois, la GPL est la seule licence qui me pose réellement 
problème pour du logiciel d'infrastructure. LGPL et CPL qui imposent des 
redistributions des modifications du code qu'on a obtenu gratuitement 
sont pour moi parfaitement acceptables.

> Un programmeur génial pose un concept formidable qui potentiellement 
> permet à sa société de faire une fortune. Selon le droit français, sa 
> société possède son code (droit commercial), mais pas ses textes 
> (droits d'auteurs). Autrement dit, le programmeur pourrait plaider que 
> par son salaire son employeur a acheté les jars, les sources, mais que 
> s'il veut  les commentaires, il faut lui donner une part du gateau.
>
> Lorsque l'on considère l'engagement personnel que représente la sortie 
> d'une bonne idée (le loisir des passionnés), on n'imagine facilement 
> la frilosité des salariés qui travaillent sous licence commerciale, 
> quand leur nuits ne se transforment pas en revenus. Je n'ai pas 
> d'informations statistiques sur le sujet, mais je constate autour de 
> moi que le "libre" peut parfois libérer les talents. Par contre, 
> j'imagine mal que ce modèle puisse être la norme des sociétés 
> informatiques.


Il ne faut pas considérer l'implication des sociétés au même titre que 
celle des passionnés. Une société est là pour gagner de l'argent, et ne 
financera le temps de ses salariés sur du développement libre ou 
opensource que si elle y trouve son intérêt.

Par exemple, Anyware Technologies n'a jamais eu de contrats où le client 
impose une licence libre. Quel intérêt donc ? On en retire de l'image et 
de la visibilité, qui a un bénéfice commercial et marketing important. 
On en retire des bénéfices techniques, puisque nous connaissons très 
bien la plateforme sur laquelle nous développons nos projets et pouvons 
d'une certaine manière en influencer les évolutions conformément à nos 
besoins. Autre bénéfice technique : quand nous contribuons une nouvelle 
fonctionnalité nécessaire dans le cadre d'un de nos projets, d'autres 
continuent son évolution et sa "robustification", ce dont nous 
bénéficions sur les projets suivants.

Que du bassement matériel et pragmatique ;-)

> Les écoles ne forment pas que des passionnés, et en 40 ans de 
> carrière, cela doit être des cas bien particuliers pour lesquels la 
> passion ne s'épuise jamais.


Certainement. Les développeurs de logiciels libre/opensource sont 
manifestement des bêtes un peu à part ;-)

>> 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 :-)
>
>
> Je partage cet objectif, mais je crois que ce serait trop facile de 
> réduire cela à une question de license.


Encore une fois, ce n'est pas qu'une question de licence. C'est une 
question de communauté, dont la formation est influencée par la licence.

> Oui, nous souhaitons une spirale vertueuse où l'intérêt particulier se 
> conjugue avec l'intérêt général, où les salariés soient heureux de 
> travailler dans leurs boîtes et contribuent avec passion aux projets, 
> où les patrons dégagent des excédents suffisants pour continuer à 
> avoir des projets intéressants et permettre la R&D, où les 
> administrations considèrent leurs investissements informatiques avec 
> la même intention stratégique que lorsque l'on trace une autoroute, où 
> dans toute formation informatique la contribution à un projet libre 
> soit obligatoire...


Houla, ne dérivons pas vers l'utopisme ;-)

> Plus raisonnablement, souhaitons déjà que cette liste soude et 
> peut-être aide à grossir la communauté francophones de Cocoon.


C'est le but principal de cette liste, que j'ai souhaité ouvrir après 
avoir constaté que nombre d'utilisateurs de Cocoon en France ne sont pas 
sur les listes anglophones pour différentes raisons (trafic, barrière de 
la langue) et sont bien loin de la communauté.

> Je regrette personnellement qu'il n'y ait pas plus de contribution 
> universitaires à Cocoon. Les sociétés ont la force de l'efficacité, 
> mais parfois, on aurait besoin d'investissements plus désintéressés, 
> qui n'aient pas la pression de la rentabilité.


Des idées pour les impliquer ?

Sylvain

[1] 
http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Exit+Requirements

-- 
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