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