Catégorie: "Open Source"

Les 2.0 sceptiques

Les 2.0 sceptiques

Régulièrement, je vois passer des articles dans la catégorie 2.0 sceptique… [Note: l’article source n’existe plus]

A chaque fois, je ne peux m’empêcher de faire la comparaison avec ce qui se passait il n’y a même pas 10 ans, lorsque les gens découvraient l’open source.

Le web 2.0 est comme l’open source:

  • Il n’a pas de définition claire et précise (ou du moins unique);
  • Il ne correspond à aucun business model antérieur, connu et éprouvé;
  • Il génère de la résistance au changement;
  • Les protagonistes dudit phénomène ne portent pas de cravate!

Cela fait quelques années qu’on n’entend plus dire que l’open source est une “hypothèse ridicule” et que “ça ne marchera jamais".

Combien de temps encore pour le web 2.0 ?

Ironiquement, ça fait 10 ans que l’on nous parle de télé interactive et de publicités où l’on peut acheter impulsivement d’un simple appui sur une touche de sa télécommande.

Ironiquement, à l’heure où les gens passent moins de temps devant leur TV et plus de temps sur l’Internet, à l’heure où acheter d’un simple clic est devenu une réalité, on refuse tout à coup d’y croire…

Peut être parce que ça ne se passe pas sur le canapé du salon?

Encore quelques mois de patience et il y aura des Apple TV et des Tivo 2.0 dans tous les salons… enfin je veux dire – en France – des Neufbox / Freebox / bidulobox 2.0 dans tous les salons.

Licence GPL, 20ans après...

ONLamp publie une interview de Eric Raymond [En] assez intéressante sur la licence GPL. Il revient sur l'utilité même de la licence GPL qu'il juge potentiellement dépassée de nos jours, 20 ans après sa création.

Le concept open-source serait aujourd'hui suffisament puissant pour s'imposer de lui même sans avoir besoin de la protection d'une licence virale telle que GPL. Cet aspect viral serait justement devenu contre-productif dans la mesure où il effraie les développeurs/chefs d'entreprises...

L'inteview évoque également le projet de licence GPL 3.0 ainsi que le vide "viral" de GPL 2.0 par rapport à l'utilisation des logiciels sous forme de services en ligne.

There's more than the code...

Oh well... I think it's been too long since I last read some great wisdom like the one on Joel on Software.

I read this really insightful peace today about all the important things beyond just the actual software code.

Here's a funny quote:

Human emotions can be really, really superficial. In particular people ridiculously overvalue aesthetics and beauty when evaluating products. It's one of the reasons iPods, and, for that matter, Keanu Reeves, are so successful.

...but the whole article is definitely a must read!

Of course, this so much applies to b2evolution as well... :-/

Choix d'une license open source

Cet article fait suite à:

Combien existe-t-il de licences Open-Source ?

Beaucoup!

De très nombreux auteurs ont décidé qu'une licence existante (notamment la licence GPL et son aspect viral) ne correspondait pas à leurs impératifs et ont créé la leur, souvent en modifiant une licence existante.

Il faut savoir aussi que certaines licences se prétendent "open source" sans l'être vraiment.

Une bonne liste de référence est fournie par l'Open Source Initiative.

Quelle licence choisir?

Le choix ne doit pas uniquement porter sur les caractéristique que l'on jugerait idéales. Il faut également choisir une licence qui sera compatible avec les codes tiers que l'on veut pouvoir intégrer à son projet.

"Compatible" signifie ici que les licences respectives de chaque morceau ou bibliothèque de code que l'on veut assembler doivent autoriser cet assemblage avec du code sous licence tierce.

A cet effet, il est généralement une mauvaise idée de créer une nouvelle licence. Il vaut mieux en utiliser une existante et dont la compatibilité est étendue.

On observe également une tendance grandissante consistant à diffuser du code sous plusieurs licences simulatnément, ce qui limite les incompatibilités en donnant la possibilité d'utiliser la bonne licence au bon moment.

Un point de départ intéressant peut être la consultation des Statistiques SourceForge en termes de répartition par licence.

On constate (évidemment) facilement l'écrasante domination de la licence GPL suivie (de loin!) par son pendant LPGL (Lesser GPL).

SourceForge.net License Selection Breakdown

Quelles sont les principales alternatives ?

On peut classer les différentes licences open-source en 3 grandes catégories selon leur degré de permissivité par rapport à l'idéal du "Logiciel Libre":

  • Les licences autorisant à basculer en closed source à tout moment (la seule condition étant de mentionner les auteurs et leur copyright):
    • BSD License,
    • MIT License,
    • X.Net License,
    • autres licences dites "permissives".
  • Les licences obligeant à garder le code en open source en cas de modification, mais autorisant la combinaison avec du code closed source:
    • MPL (Mozilla Public License),
    • LGPL (GNU Lesser Generak Public License).
  • Les licences n'autorisant aucune concession par rapport au caractère open source ou a la combinaison avec du code closed source:
    • GPL (GNU General Public License).

Précisions sur la licence GNU GPL

Cet article fait suite à "Open Source & Sociétés Commerciales".

Avant tout, ATTENTION: bien que j'aie essayé de faire de mon mieux, je ne suis pas juriste et je ne peux en aucun cas garantir les informations ci-dessous. Qui plus est, la plupart des analyses disponibles dans ce domaine sont basées sur le droit américain et peuvent ne pas forcément se transposer au droit français, européen ou international...

En effet, il est important de prendre en compte le fait qu'à l'heure de l'Internet, les différentes contributions à un projet Open Source proviennent souvent de pays très divers. Identifier des règles de droit applicables à tous ces pays est au delà de mes compétences.

Les informations rassemblées ci-dessous sont donc à prendre à titre indicatif!

Pourquoi la licence GPL pose-t-elle problème?

Si vous diffusez un logiciel sous GPL et que d'autres équipes lui ajoutent des fonctionnalités intéressantes, vous pouvez à tout moment récupérer ces différents ajouts et les fusionner au projet initial.

Le revers de la médaille c'est que si vous voulez intégrer un morceau de code diffusé sous GPL dans l'un de vos propres logiciels, vous devez alors obligatoirement diffuser ce logiciel dans son entiereté sous licence GPL... ou bien ne pas le diffuser du tout.

On peut discuter longtemps de la pertinence de l'idéal derrière cette licence, mais il est un fait que dans une entreprise capitaliste, la manipulation de code sous licence GPL finit toujours par poser des problèmes auxquels il faut préter une attention particulière.

Et c'est sans compter le fait que la légalité même du texte de la licence GPL est remise en cause par différents avocats et juristes...

Quelle est la valeur légale des licences Open Source?

La réponse de Bruce Perens "s'appuie" ici sur le droit américain mais il y a quelques principes généraux à retenir: une licence logicielle est une combinaison des droits d'auteur ("copyright law" qui s'applique assez mal aux logiciels) et du droit contractuel (dans lequel on peut ajouter pratiquement toutes les restrictions imaginables tant qu'elles n'atteignent pas aux autres droits garantis par les lois). Mais de toutes façons, la plupart du temps les problèmes de non respect des licences se sont réglés avec succès en dénonçant publiquement les abus (mauvais pour l'image...) plutôt qu'en attaquant les contrevenants en justice.

On peut toutefois douter de l'efficacité d'une dénonciation publique sur une PME ou même un développeur indépendant qui abuserait d'un code open source dans un marché de niche... :|

Après avoir rendu public un logiciel sous licence GPL, est-il possible de changer la licence?

D'après Bruce Perens, oui et non. Non on ne peut pas se retracter sur la licence GPL portant sur les versions existantes. Mais oui, si personne d'autre n'a contribué, il est possible de sortir les nouvelles versions sous une autre licence. Il est également possible de sortir le même logiciel simultanément sous plusieurs licences (et pas forcément toutes Open Source).

Ce point est souvent contesté par les opposants à la GPL qui prétendent que la licence GPL empêche l'auteur même du logiciel de l'utiliser autrement que sous les termes de la GPL, y compris pour les travaux dérivés. J'oserai affirmer ici que c'est faux! La FSF le dit clairement dans sa FAQ sur la GPL:

The GNU GPL does not give users permission to attach other licenses to the program. But the copyright holder for a program can release it under several different licenses in parallel. One of them may be the GNU GPL.

The license that comes in your copy, assuming it was put in by the copyright holder and that you got the copy legitimately, is the license that applies to your copy.

I would like to release a program I wrote under the GNU GPL, but I would like to use the same code in non-free programs.
To release a non-free program is always ethically tainted, but legally there is no obstacle to your doing this. If you are the copyright holder for the code, you can release it under various different non-exclusive licenses at various times.

Si d'autres personnes ont contribué, elles sont propriétaires du "copyright" sur leurs modifications (et ça se transpose probablement aux droits d'auteur français, mais on doit pas être très loin...?). Plusieurs options pour changer la licence dans ce contexte:

  • Eliminer le problème: supprimer le code contribué.
  • Traiter le problème au niveau du copyright: demander un transfert du "copyright" aux auteurs concernés. On peut aussi envisager qu'il cède un copyright tout en conservant le sien ("split-copyright"). Pas sûr que tout celà puisse s'appliquer aux droits d'auteur français. Cette solution est intéressante car elle n'aliène pas le contributeur en lui imposant une licence plus restrictive que la GPL. Cette solution permet éventuellement de distribuer les modifications à la fois sous GPL et sous une autre licence en fonction des besoins.
  • Traiter le problème au niveau de la licence: utiliser dès le départ une licence telle que la Netscape Public License (NPL) qui implique que les fichiers modifiés soient redistribuables sous une autre license... (mais pas forcément les nouveaux fichiers ajoutés par d'autres, dans le cas de la NPL). Sinon, si le projet est en GPL dès le départ par exemple, il est nécessaire d'obtenir le consentement de tous les contributeurs avant de changer la license. Voir l'exemple de Mozilla.org qui est engagée dans un processus de changement de licence où non seulement elle change les licences NPL en MPL (Mozilla Public License) mais où elle ajoute d'autres licences (GNU GPL et GNU LGPL) et où elle bascule des licences tierces vers MPL+GPL+LGPL avec le consentement des contributeurs concernés.

Un programme GPL peut-il inclure des modules non GPL?

Oui, mais la licence des modules doit être compatible avec la licence GPL. Dans le cas contraire, il faut prendre des dispositions particulières.

Sur la compatibilité des diverses licences open source avec la GPL, voir: Various Licenses and Comments about Them.

Un plug-in pour un programme GPL doit il forcément être ditribué sous GPL?

On entre dans une zone de flou...

La FSF prétend que le plugin doit être ditribué en GPL, mais s'il est distribué séparément... on est bien dans un cas où l'auteur peut distribuer son code sous la licence qu'il veut non?

Maintenant, le problème c'est qu'un plugin est généralement construit à partir d'une classe ou d'un template type, lequel est généralement soumis à la licence GPL... ce qui implique que le plug-in derivé soit GPL également. Mais si la classe ou le template de base existe sous différentes licences... tout semble permis, non?