cocoon-users-fr mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric Glorieux <frederic.glori...@ajlsm.com>
Subject Re: GPL vs ASL (était Re: [ANNONCE] Myotis 0.80)
Date Mon, 04 Apr 2005 12:22:57 GMT
Je ne souhaite absolument pas donner l'apparence d'un désaccord que sur 
le fond je n'ai pas avec Sylvain Wallez. Juste que je suis moins engagé 
dans la défense d'une licence ou d'une autre, et qu'au contraire, j'ai 
constaté (qu'en France en tous cas), la question juridique était 
beaucoup moins critique que la réalité des acteurs, compétences, et 
argent que l'on arrive à mettre autour d'un projet.

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

Entièrement d'accord là-dessus. Evitons de choisir une licence qui 
facherait des partenaires majeurs.

[Cocoon dans l'enseignement supérieur français]
 > Des idées pour les impliquer ?

Je suis par exemple intervenu dernièrement dans une université où la 
découverte de Cocoon a semblé recueillir de l'intérêt. Il y a un 
problème de prix des prestations entre le tarif que peut payer une 
Université et ce qui se fait dans le privé.

Peut-être pourrait-on imaginer un événement pas trop cher autour de 
Cocoon en France (comme le CocoonGT), mais on n'est pas là de trouver 
l'institution ou l'entreprise prête à fournir l'effort d'organisation.


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

Et dans le microcosme logiciel libre public, on a vu des virages de tous 
les côtés selon les alternances, parce que pour le dire un peu bêtement, 
le "libre" peut être vu libertaire, ou libéral, l'opinion peut se 
demander s'il est de droite ou de gauche.

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

Cette vue est certainement juste, les états le calculent très bien 
lorsqu'ils décident et financent des équipements d'infrastructure (ex: 
un pont). Cette réflexion ne semble pas toujours prise en compte dans 
les services informatiques.

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

Malheureusement, la nature des marché publics fonctionne généralement au 
produit. Les subventions peuvent permettre une autre manière de 
fonctionner, mais cette forme de financement peut ne pas convenir à une 
entreprise privée.

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.

Et là le design de Cocoon s'y prête très bien.

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

:o) J'aime beaucoup la métaphore agent mutagène Wallez

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

Cela peut aussi faire comprendre la difficulté pour des entités 
politiques. Un fonctionnaire membre d'Apache  n'aurait aucun mandat pour 
représenter son administration (et donc nous, les citoyens). Une 
entreprise peut vivre avec ça, mais pour d'autres organisations, c'est 
plus difficile.


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

J'ai essayé de me faire préciser la notion par les juristes Cecill, pas 
très clair. En fait, je suis sorti de la discussion avec cette 
conclusion "comprenez Cecill comme une GPL". D'ailleurs sur le site, il 
ne se situe que par rapport à la GPL 
<http://www.cecill.info/faq.fr.html#compatibilite>

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

Je n'ai aucune intention de cette sorte. Nous avons fortement contribué 
à SDX, mais aussi d'autres applications, avec Cocoon, mais aussi sans.

> (et je reconnais être totalement ignorant sur la 
> question) : combien de projets non publics utilisent SDX ?

Je n'en suis pas comptable, mais par exemple ceci
<http://www.la-croix.com/sdx/alc/rech.xsp?q=pape&x=0&y=0>



[...]

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

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

En effet.

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


Merci encore. Désolé de ne pouvoir suivre qu'épisodiquement.

-- 
Frédéric Glorieux ("AJLSM", <http://ajlsm.com>)
"Transfolio" <http://transfolio.org>


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