Le libre en question


Aujourd’hui un client nous met le couteau sous la gorge d’une manière assez peu banale. Il y a quelques années il a choisi de prendre une plateforme libre pour développer ses outils internes et une partie des services qu’il propose à ses clients.

Son choix a été de prendre Plone pour les raisons suivantes :

  • pas de coût de licence
  • un développement via l’interface web de Zope quasiment sans avoir à écrire de code
  • une documentation abondante et une communauté réactive
  • présence en France d’acteurs majeurs du développement international de la plateforme
  • une licence libre (la GPL) qui lui permet de penser que la plateforme ne deviendra jamais propriétaire

Le projet a eu des hauts et des bas. Il y a eu des formations externes, de la maintenance externe, du développement interne et externe. Globalement le projet a dépassé les espérances et est passé en mode industriel il y a un an. Le client possède toutes les sources et la connaissance de son applicatif. Il est maître de son destin. Avec le recul il est satisfait de cette plateforme et de son coût.

Ayant acquis une maitrise certaine de la gestion de contenu dans son corps de métier, ce client aimerai développer un module métier qu’il utilisera pour lui dans un premier temps, mais qu’il compte aussi revendre à ses concurrents à moyen terme. Pour cela ce module sera vedu comme une technologie propriétaire. Cela soulève une série de questions politiques et juridiques en interne (attention, certains de ces arguments sont partiellement erronés ) :

  1. si un site web utilise du code GPL pour fournir un service à des clients, un client peut demander à avoir accès au code source de l’application puisqu’il paie pour ce service
  2. si nous fournissons des sources sous GPL notre code source ne peut être commercialisé à des tiers sans qu’ils soient obligés de reverser ce code dans le domaine public
  3. si nous utilisons une extension sous GPL tout le code source devient GPL

Sur le fond je comprends la démarche de la vente d’un savoir faire que l’on veut protéger. Chez ce client tout ces constats ont amené a une réponse : pour faire du propriétaire il faut se baser sur une technologie propriétaire qui permet de faire ce que l’on veut une fois achetée.

Que faire ? Faut-il abandonner tous les développements en Plone  ? Il est tout à fait possible de réaliser un tel module propriétaire avec Zope et de l’intégrer avec d’autres systèmes sans que cela pose de problèmes de licence. Par contre, le Core de Plone 2 et de Plone 3 sont sous licence GPLv2 ce qui provoque un certain malaise. En anticipant de tels questionnements, la fondation Plone a décidé que le Core de Plone 4 serait sous licence BSD et  qu’elle accepterait que les modules d’extensions soient sous licence compatibles LPGL et GPL. Elle accepte aussi que des plateformes sous licence propriétaire soit développé à partir de Plone.

Dans notre cas précis ce questionnement est orienté : il faut vendre notre savoir faire pour générer des royalties et améliorer la rentabilité. Pour cela le choix d’une technologie libre est risquée et il faut adopter en masse une technologie propriétaire quitte à remettre en cause les développements en cours. Les coûts à justifier sont tels qu’il n’est pas possible de tolérer qu’un autre technologie puisse damer le pion à la technologie propriétaire à court terme car le choix de la technologie propriétaire est celui fait à moyen terme.

Il nous est proposé de fournir un canva pour fabriquer ce module dans la technologie propriétaire qui soit intégrable à Plone. Et dans tous les cas Plone va être abandoné. Autant nous mettre la corde au cou nous-même et attendre le bourreau.

3 Responses to Le libre en question

  1. Bertrand dit :

    En clair: maintenant qu’ils en ont bien profité, ils ne veulent plus les avantages pour lesquels ils ont choisit le libre au départ. Autrement dit, sans le libre ils n’auraient rien fait, du moins pour plus cher et peut-être à l’arrivée un produit qu’il serait inconcevable de seulement espérer revendre.

    Sinon leur constat est faux: pour faire du propriétaire avec du GPL il faut être seul détenteur des droits (le dual-licencing ça c’est déjà vu, c’est pour ceux qui ont bossé leur produit du début à la fin, pas les profiteurs ;-)).

    sinon, pour le point 1: sous GPLv2 c’est non aucune obligation, il me semble que c’est justement ce que change la v3.

    point 2: non, pas de cette manière. D’abord le domaine public ça veut dire aucune licence, pas même l’obligation de citer les auteurs originaux (c’est la seule chose qu’apporte la BSD non? ;-)). Par contre le client peut demander le code, et libre à lui d’en faire ce qu’il en veut dont le diffuser, sauf que ça doit rester GPL, pour l’équité.

    pour le point 3: la licence est très claire pour le code C, la différence avec la LGPL porte spécifiquement sur le point liaison dynamique (lib externe) / statique (== incorporation du binaire dans l’executable final). Ces notions n’existent pas vraiment en python et autre languages dynamiques.
    Donc d’un point de vue éthique je suis d’accord avec toi ça ne me paraitrait pas anormal de pouvoir faire un module propriétaire pour plone et de considérer que ça ne viole pas la GPL de plone: le code de base de plone lui-même n’est pas modifié.

    Le changement de licence pour plone 4 (je savais pas) me parait être un joli nid à trolls affamés, alors je vais essayer d’éviter d’y lâcher ne serait-ce qu’un yaourt, je dirai juste: tant pis pour Plone – vu ce que ça m’intéresse maintenant… :-p

  2. youenn dit :

    Salut Encolpe,

    Je ne vois pas pourquoi que ta société ne puisse pas faire son module autour de plone et de le commercialisé. Tant qu’il n’y a pas de modification du kernel, je ne vois pas ce qui pourrais empêcher de faire du propriétaire en utilisant du code source GPLv2.
    Par contre je pense que la commercialisation du dit module ne doit pas inclure plone et consort car la licence l’interdit.
    Enfin peut être que je me trompe.

    Youenn.

  3. encolpe dit :

    Le client essaie de biaiser le débat sur le principe de la jurisprudence Illiad/BusyBox au sujet le la FreeBox.
    BusyBox est un logiciel sous GPLv2 et Illiad a contribué un petit peu à son développement pour l’intégrer dans les FreeBox en y rajoutant un certains nombres de logiciels et en utilisant d’autres logiciels sous GPLv2 (vls et vlc par exemple). Avec les milliers de FreeBox en France les développeurs de BusyBox ont attaqué Illiad car ils utilisent de manière commerciale leur travail, même si celui-ci n’est pas vendu (On pourrait presque faire un parallèle avec l’affaire Internet Explorer/Netscape).
    Son raisonnement est que de la même manière un service web fourni à un client à partir d’une plateforme GPLv2 peut être attaqué s’il n’est pas reversé à la communauté. Le défaut dans cette approche est que la jurisprudence n’existe pas puisqu’il n’y a pas eu de jugement. Maintenant, on voit bien le mécanisme de mise en place de la peur du libre pour imposer du propriétaire.

%d blogueurs aiment cette page :