Actualités

[26/06/2017] Smile acquiert Hypertexte, expert en référencement naturel et en contenus optimisés

Smile annonce l’acquisition de l’agence Hypertexte, spécialiste du référencement naturel, de la conception et de la réalisation de contenus pensés pour le SEO.

[21/06/2017] Smile dans le top 10 des entreprises où il fait bon travailler !

Smile entre dans le classement très fermé des entreprises où il fait bon débuter sa carrière. Un palmarès publié dans Les écho...

[01/06/2017] Découvrez le nouveau livre blanc Smile : Android pour l'embarqué

Smile publie aujourd'hui un nouveau livre blanc dédié à Android pour l'embarqué.

Toutes les actualités picto
       

Top consultation

Logo Smile : Open Source Solutions

Guillemet ouvrant introduction
à l'open source Guillemet fermant

Copyright et licences

Copyright et licences

Principes élémentaires

Les programmes open source ne sont pas des programmes sans licences. C’est au contraire leur licence qui les fait open source. Ils ne sont pas non plus dans le domaine public, c’est à dire n’appartenant à personne en particulier.
Lorsqu’un développeur écrit un programme, il en détient les droits d’auteur, le copyright. Dans certains cas, ce peut être l’entreprise qui l’emploie qui en détient les droits. Et ce copyright peut être vendu, comme bien immatériel, d’une entreprise à une autre.

Le détenteur du copyright est libre de définir l’utilisation qui peut être faite de son programme :

  • Il peut le garder pour lui, en interdire l’utilisation à qui que ce soit.
  • Il peut vendre ses droits à un tiers, personne physique ou morale.
  • Il peut utiliser son droit d’auteur pour préciser les conditions qu’il pose à l’utilisation de son programme. Il écrit ces conditions dans les termes de la licence d’utilisation.

A noter qu’en droit français, il n’est pas aisé d’abandonner ses droits et de mettre son programme dans le domaine public de manière irréversible.

Il faut bien expliquer aussi que ce n’est pas la diffusion des sources qui fait qu’un programme est open source, c’est le droit, inscrit dans la licence, de les utiliser, de les modifier et de les redistribuer librement.
Il est donc important de bien assimiler la logique suivante : à la base de l’open source il y a la licence, et la licence n’existe qu’à partir du droit d’auteur.

Ainsi tous les logiciels open source ont un propriétaire, ils ne sont pas « à personne ». Dans certains cas, ce propriétaire peut être une fondation à but non lucratif, ou bien ce peut être une entreprise commerciale ordinaire. Le détenteur des droits est libre de fixer les conditions de licences, il est libre d’en changer même, et il est libre d’y faire des aménagements ou exceptions, ou de diffuser à certains selon une licence, à d’autres selon une autre licence.

Celui qui reçoit le programme, en revanche, n’est pas libre. Il est lié par les termes de la licence. Certes il n’a pas signé de contrat, mais la licence lui a été bien énoncée, et elle stipule qu’il n’a le droit d’utiliser le programme qu’à telles et telles conditions. S’il refuse ces conditions, il n’a pas le droit d’utiliser le programme.

Mentions élémentaires des licences

Toutes les licences open source ont en commun quelques clauses de bon sens :

  • L’identification claire du propriétaire du copyright, y compris au travers des copies ou travaux dérivés.
  • L’obligation de conserver la notice de licence en l’état, sur le programme et les travaux dérivés. C’est bien sûr une nécessité technique : inutile de définir des termes de licence s’ils sont évacués dès la première copie.
  • La protection de l’auteur vis à vis des utilisateurs de son programme, ses éventuels défauts et les conséquences de ces défauts : « ce programme est fourni ‘en l’état’ (« as is »)… ». C’est bien le moins qui puisse être exigé : l’auteur vous laisse utiliser librement son travail, vous n’allez pas quand même lui réclamer des dommages et intérêts.

A noter que dans certains pays, la distribution payante d’un programme entraîne des droits inaliénables. D’une manière générale, la licence ne peut être contraire au droit national. C’est pourquoi elle dit “Si vous ne pouvez pas distribuer le programme en satisfaisant à la fois vos obligations liées à licence et d’autres obligations applicables, alors vous ne pouvez pas distribuer le programme du tout ».

C’est à dire que soit l’on peut respecter les lois nationales et la licence à la fois, soit on est dans l’interdiction de distribuer le programme sous ladite licence.

Définition d'un logiciel libre

Le logiciel libre se définit par le respect de quatre libertés fondamentales :

  • exécuter le programme,
  • étudier le programme et l’adapter selon son besoin (ce qui implique bien sûr l’accès au code source),
  • redistribuer le programme pour aider son prochain,
  • et enfin améliorer le programme et distribuer ces améliorations au public (ce qui de même implique le libre l’accès aux sources).

La finalité première est la liberté, l’accès au source n’est qu’un pré requis pour respecter cette liberté.

Définition d'une licence open source

L’OSI, Open Source Initiative, a édicté une définition précise de ce que signifie open source, une définition qui est aujourd’hui reconnue de manière à peu près universelle.

Avoir une définition officielle précise est très important, une licence ne doit pas pouvoir être plus ou moins open source : elle l’est ou ne l’est pas, les choses doivent être claires.

Et le site de l’OSI, opensource.org, indique aussi quelles sont les principales licences qui se conforment à cette définition. On y retrouve bien entendu les licences bien connues, à commencer par la GPL.

La définition comporte dix points, dont les trois premiers sont les principaux :

  1. Libre redistribution : la licence ne doit pas interdire à qui que ce soit de vendre ou donner le programme.
  2. Code source : la licence doit permettre la distribution sous forme de code source, et si le code source n’accompagne pas le programme il doit être disponible de manière facile et pratiquement gratuite.
  3. Travaux dérivés : la licence doit permettre des modifications et des travaux dérivés, et doit permettre que ces travaux soient distribués sous les mêmes termes de licence.

Revenons sur ce point 3 : la licence doit au minimum permettre de redistribuer les travaux dérivés sous la même licence. Elle ne doit pas nécessairement l’obliger. On verra que cette nuance est à la base de la distinction entre la famille BSD et la famille GNU.

Parmi les autres articles de cette définition figurent différentes clauses de non-discrimination : la licence ne doit pas exclure tel groupe d’utilisateurs, ni tel domaine d’application, ni tel environnement technique. Par exemple, l’auteur du programme ne peut pas, en pacifiste militant, préciser que son programme ne doit pas être utilisé pour guider des missiles. Du moins s’il ajoute cette clause la licence ne sera plus open source.

Licences GNU et BSD

Il y a deux grandes familles de licences open source : la famille BSD et la famille GNU. On parle parfois de licences copyleft pour les secondes et de licences non copyleft pour les premières. « Copyleft » est bien sûr un jeu de mot en référence au « copyright », jeu de mot traduit parfois par « gauche d’auteur », vs. « droit d’auteur ». Mais pour autant copyleft n’est pas un abandon de droit.

Pour qu’il n’y ait pas de confusion, précisons que si le mouvement du logiciel libre préfère les licences copyleft, à commencer par la GPL, il n’y a pas correspondance entre logiciel libre et copyleft : les licences BSD sont aussi du logiciel libre.

La famille BSD

La licence BSD (Berkeley Software Distribution) autorise n’importe quelle utilisation du programme, de son code source et de travaux dérivés. Le code sous licence BSD peut en particulier être utilisé intégré à des logiciels sous licence non open source. On sait que Microsoft a repris du code TCP-IP sous licence BSD dans Windows, et que MacOSX est basé sur FreeBSD.

La seule contrainte spécifique est l’interdiction de chercher à tirer avantage de la dénomination de l’auteur, ici l’Université de Berkeley.

C’est donc la licence la plus libérale, qui entraîne le moins de contraintes : les programmes sous licence BSD sont quasiment dans le domaine public. C’est aussi peut-être la plus ancienne, puisqu’elle remonte à 1980. Il n’est pas interdit de modifier le texte de la licence, de sorte que l’on rencontre une multitude de versions dérivées, à quelques mots près. C’est un handicap pour la clarté et la lisibilité de la licence.

Dans la famille BSD, on trouve aussi la licence MIT, et la licence Apache. Cette dernière est d’une grande importance puisque utilisée déjà par la cinquantaine de projets de la fondation Apache. On peut citer également les licences Mozilla (MPL) et SUN (CDDL). Les différences entre ces différentes licences sont de l’ordre du détail.

La licence GNU GPL

Définition

La licence GNU GPL est utilisée par 70% des programmes open source. Mais ce pourcentage en nombre n’est pas le plus important puisque certains logiciels phares de l’open source sont sous d’autres licences.

La licence GNU GPL, « GNU General Public Licence », se caractérise principalement par son article 2, qui énonce le droit de modifier le programme et de redistribuer ces modifications, qui constituent des œuvres dérivées, à la condition que ce soit sous la même licence GPL.

C’est ce que certains appellent le caractère viral de la licence : elle se communique aux travaux dérivés. Mais il est plus correct de parler de réciprocité, ou de donnant-donnant.

Bien sûr, toute la question est alors de savoir qu’est-ce exactement qu’une œuvre dérivée et qu’entend-on par distribuer ? Il existe une vaste littérature sur le sujet, et pourtant les zones d’ombre subsistent. Certains estiment même qu’il n’est pas mauvais de laisser quelques doutes.

Voyons déjà ce qui est clair.

Que signifie « Œuvre dérivée » ?

A coup sûr, si vous prenez un morceau de code source du programme A, que vous modifiez des lignes ou ajoutez des lignes pour obtenir un programme B, c’est une œuvre dérivée.

De manière certaine également, si vous appelez des fonctions du programme A depuis un programme B, en liant les deux programmes (« link »), alors ici aussi, le programme B est une œuvre dérivée. Cette liaison entre les programmes peut être statique ou bien dynamique, c’est à dire résolue à l’exécution seulement. Il existe un débat quand à savoir si une liaison dynamique donne une œuvre dérivée.

Dans les environnements techniques modernes, il existe en fait une diversité de moyens d’invoquer les services d’un programme autrement qu’en appelant une fonction. L’appel des services d’un programme A au moyen de protocoles d’échange réseau standards n’implique pas que le programme B soit une œuvre dérivée. Si c’était le cas, alors un navigateur adressant une requête à un site dont les programmes sont sous GPL, se trouverait lui-même obligé d’être GPL.

En fait, il est souvent admis qu’un programme B est considéré œuvre dérivée du programme A, si B ne peut pas fonctionner de manière utile sans A, ceci indépendamment des modalités techniques de la liaison.

Qu’en est-il d’un programme qui utilise par exemple une base de données MySql, sous licence GPL ? Si ce programme n’utilise pas, pour appeler la base, de librairies sous licence GPL, alors il n’invoque les services de MySql que au moyen de protocoles standards, ce qui n’implique pas qu’il soit GPL lui-même. Mais si le programme ne peut fonctionner autrement qu’avec une base MySql, alors on pourra considérer qu’il est œuvre dérivée malgré tout. A noter que la FAQ de MySql sur le sujet des licences a été critiquée pour laisser entendre que toute forme d’utilisation commerciale devait être sous licence commerciale, ce qui est erroné.

Que signifie « Distribuer » ?

Ici encore, certaines choses sont claires. A coup sûr, si vous commercialisez votre programme en tant que progiciel, cela s’appelle distribuer.

A l’inverse, utiliser et déployer un programme au sein d’une même organisation, n’est pas distribuer. Ce qui signifie qu’une entreprise peut construire une œuvre dérivée, et l’utiliser en interne sur autant de postes ou serveurs qu’elle juge utile, sans être tenue de diffuser les sources de l’œuvre. C’est un point essentiel dans la sphère économique.
Une autre question importante est celle de la relation client-fournisseur dans les métiers de l’informatique. Lorsqu’un prestataire tel que Smile construit une application utilisant des composants sous licence GPL, et livre cette application à son client, le prestataire doit livrer l’ensemble des sources, y compris ajoutés. Cette obligation de distribution des sources ne concerne QUE les personnes qui reçoivent le programme, ici donc le client. Il n’est pas requis de les mettre sur la place publique.

Par ailleurs, le client peut soit garder pour lui le programme (c’est à dire au sein de son organisation), soit le distribuer, mais alors obligatoirement sous licence GPL.

Notons aussi que utiliser l’œuvre dérivée sous forme de service en ligne (software as a service), même commercial, n’est pas distribuer. C’est ce que fait Google par exemple. Sur ce point, voir plus loin la licence AGPL.

L’esprit de la GPL

Au delà des mots, l’esprit de la licence GPL est que, en tant qu’auteur ou propriétaire d’un programme, je vous donne le droit de l’utiliser et d’utiliser ses sources à condition que vous en fassiez autant. En somme, c’est donnant-donnant.

La licence GPL a pour effet de diviser le monde en deux « camps » : le GPL et le reste du monde. Si vous êtes du coté GPL, alors tout le patrimoine open source sous GPL vous est accessible sans restriction. Si vous êtes dans l’autre camp, c’est à dire que vous ne voulez pas distribuer votre code en donnant aux autres la même liberté qui vous était donnée, alors vous ne pouvez pas en profiter.

C’est ce qu’on pourrait appeler du donnant-donnant, que les critiques de cette licences appellent son aspect viral.

Compatibilité des licences

La question de compatibilité des licences est primordiale. Si un programme A est sous licence LA et un programme B est sous licence LB, alors est-il possible de construire un programme C utilisant à la fois A et B ? Le programme C héritera des exigences de LA et de celles de LB, et s’il y a des contradictions entre ces exigences, s’il est impossible de respecter les unes et les autres, alors il faudra renoncer à utiliser A et B.

Etant donné la domination de la licence GPL dans l’open source, la question principale est la compatibilité avec la licence GPL. Un programme open source, qui aurait une licence incompatible avec la GPL, aurait une utilisation plus réduite.

Parmi les licences compatibles on peut citer les licences BSD, MIT, ou la licence Apache (compatible GPL-v3). Parmi les non-compatibles, citons les licences SUN CDDL, Eclipse, Mozilla.

La figure suivante est issue du site gnu.org. Les flèches indiquent la compatibilité des licences.

licence_gnu_gpl-compatibilite_des_licences

Notons qu’une licence LA qui serait de type copyleft, et pratiquement identique à la GPL, mais porterait un autre nom, ne serait pas compatible GPL, puisque l’œuvre dérivée ne pourrait pas être à la fois GPL et LA. C’est le cas par exemple de la licence « réciproque » introduite récemment par Microsoft, la MsRL.

LGPL

La licence LGPL est très proche de la GPL, mais autorise à appeler des fonctions du programme à partir d’un autre programme, sans que ces programmes utilisant le programme sous LGPL soient eux-mêmes open source. Cette licence est donc particulièrement appropriée pour des librairies de fonctions destinées à être appelées par différents programmes, sans poser de conditions trop fortes sur ces programmes.

LGPL signifiait initialement Library GPL, mais l’appellation a été changée en Lesser GPL (Moindre GPL), car Richard Stallman souhaitait minimiser la correspondance « librairie = LGPL » et permettre d’envisager aussi bien des librairies sous GPL. La LGPL est un compromis entre la volonté forte de promouvoir l’open source, et éviter sa récupération au service de logiciels propriétaires, et d’autre part la volonté de rendre le plus grand service par la plus large utilisation.

A noter qu’au delà de la permission de linker, la LGPL introduit quelques conditions un peu subtiles sur le programme linké. Certains programmeurs ont préféré diffuser sous GPL avec en addendum une special linking exception, autorisant l’appel de fonction.

La GPL with special linking exception est plus lisible et plus permissive, ce qui l’a fait choisir par SUN pour le JDK.

GPL-v3

La version 3 de la licence GPL a été achevée courant 2007, et se déploie progressivement.

Elle vise à améliorer la v2, et l’adapter à un contexte qui a évolué, sur les points suivants :

  • Une plus stricte définition juridique des termes, prêtant moins à interprétation.
  • L’interdiction d’empêcher, au moyen de dispositifs physique ou en ne fournissant pas l’information requise, la mise en œuvre du logiciel modifié sur son hardware cible. C’est ce qui avait été appelé tivoisation, du nom de l’entreprise Tivo, fabriquant de magnétoscope, qui y avait recours.
  • Le cas de l’interdiction faite, dans de nombreux pays, de contourner les DRM. Une œuvre dérivée d’un logiciel GPL-v3 ne peut invoquer cette interdiction. C’est à dire qu’il n’est pas interdit d’écrire un programme de DRM en utilisant des composants GPL-v3, mais il est interdit d’interdire de le contourner.
  • Une protection contre les revendications de brevets logiciels : celui qui diffuse son code sous licence GPL-v3 donne tous les droits d’utilisation permis par la licence et s’interdit de poursuivre les utilisateurs au nom des brevets logiciels.
  • La possibilité d’ajouter certaines restrictions particulières à la licence, parmi un nombre limité de possibilités, ce qui donne un peu plus de flexibilité dans les problèmes de compatibilité de licences.

AGPL (Affero)

Comme on l’a vu plus haut, il n’est pas interdit de prendre un programme sous licence GPL, construire sur cette base un programme qui soit œuvre dérivée, et utiliser ce programme pour son propre besoin, y compris en le déployant au sein de son organisation, sans pour autant en diffuser les sources. De la même manière, il n’est pas interdit d’offrir un service accessible sur l’Internet, qui soit construit avec cette œuvre dérivée, sans pour autant en diffuser les sources, car cet usage n’est pas une distribution.

Avec la montée en puissance des offres de services hébergés, de type Software as a Service (SaaS), ce type d’usage risque de s’étendre. Or à bien y réfléchir, rendre le programme accessible directement à ses utilisateurs finaux au travers de l’Internet, est bel et bien une manière d’interdire l’accès aux sources, tout en faisant une exploitation le plus souvent commerciale, qui s’apparente à une distribution.

C’est pour répondre à ce risque de contournement que la société Affero a créé, en coordination avec la FSF, la licence AGPL ou Affero GPL. Elle est identique à la GPL, mais ajoute un article qui dit que si le programme initial permettait un accès par le réseau et diffusait ses sources par le réseau, alors le programme dérivé doit en faire de même.

C’est une mesure fondamentale, et il nous semble qu’elle tendra à se généraliser à l’avenir.

Propriété Intellectuelle et brevets

Le terme général de propriété intellectuelle fait référence à tous les aspects juridiques relatifs à la propriété sur les biens immatériels créés par l’intellect.

Le copyright sur un programme est une notion assez claire. Même si l’on a évoqué plus haut les imprécisions possibles dans la notion d’œuvre dérivée, une chose est sûre : si un programmeur se met à son clavier et écrit du code que son esprit conçoit, il n’est pas en train de violer un quelconque copyright. Lui-même, ou son employeur, est titulaire des droits d’auteur sur son code.

En d’autres mots : on sait quand on enfreint un droit d’auteur.

Au contraire, les brevets logiciels peuvent être violés sans le savoir. Un brevet logiciel peu porter sur l’utilisation dans un programme d’un algorithme, ou d’un procédé. Aux Etats-Unis, où les brevets logiciels sont permis, les grands éditeurs déposent ainsi des milliers de brevets, dont beaucoup portent sur des procédés banals, ou bien déjà connus. Certains de ces brevets peuvent ne pas être recevables, mais on ne le saura au final que s’il y a litige, et donc après un procès extrêmement coûteux.

On comprend donc que les brevets logiciels sont un danger grave pour l’industrie informatique en général. Ils ont pour effet de scléroser le marché, et de maintenir un oligopole de grands éditeurs, qui seuls peuvent supporter des frais de justice à l’américaine. Et qui, quoi qu’il en soit, ne s’attaquent pas entre eux.

On considère parfois que les logiciels open source ont plus à craindre des brevets logiciels, simplement parce que leur code est ouvert. S’ils font usage d’algorithmes couverts par brevet, alors il est facile de le découvrir. A l’inverse, si Microsoft ou Oracle utilise du code qui enfreint un brevet, ou même un copyright, il serait extrêmement compliqué de le démontrer.

Fort heureusement, les brevets logiciels n’ont pas cours en Europe, mais le danger est grand et ses partisans ne désarment pas.