> 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:[EMAIL PROTECTED] Autres commandes : mailto:[EMAIL PROTECTED]
