You are on page 1of 52

RENDEZ-VOUS SUR

WWW.OPEN-SOURCE-GUIDE.COM
Le rfrentiel web des solutions open source professionnelles

by Smile

Donnez votre avis


sur les solutions open source !

Un site complet
et participatif !!

Des solutions
dtailles, analyses,
notes, classes
et actualises

Des stats,
des commentaires,
des classifications, ...

Bien sr, le livre blanc


est toujours disponible
sur www.smile.fr

Page 2

Politique Open Source - Pourquoi & Comment

[1] PRAMBULE
[1.1] Smile en bref
Smile est une socit dingnieurs experts dans la mise en uvre de solutions open
source et lintgration de systmes appuys sur lopen source. Smile est membre de
lAPRIL, lassociation pour la promotion et la dfense du logiciel libre, de Alliance
Libre, PLOSS, et PLOSS RA, des associations clusters rgionaux d'entreprises du
logiciel libre. Ces associations sont runies au sein du Conseil National du Logiciel
Libre, dont Patrice Bertrand est le porte-parole.
Smile compte 420 collaborateurs en France, 500 dans le monde, ce qui en fait la
premire socit en France spcialise dans lopen source.
Depuis 2000, environ, Smile mne une action active de veille technologique qui lui
permet de dcouvrir les produits les plus prometteurs de lopen source, de les
qualifier et de les valuer, de manire proposer ses clients les produits les plus
aboutis, les plus robustes et les plus prennes.
Cette dmarche a donn lieu toute une gamme de livres blancs couvrant diffrents
domaines dapplication. La gestion de contenus (2004), les portails (2005), la
business intelligence (2006), les frameworks PHP (2007), la virtualisation (2007), et
la gestion lectronique de documents (2008), ainsi que les PGIs/ERPs (2008), ecommerce open source et rseaux sociaux d'entreprise (2010). Parmi les derniers
ouvrages publis, citons galement Les VPN open source , et Firewall est
Contrle de flux open source , et Middleware , dans le cadre de la collection
Systme et Infrastructure . Chacun de ces ouvrages prsente une slection des
meilleures solutions open source dans le domaine considr, leurs qualits
respectives, ainsi que des retours dexprience oprationnels.
Au fur et mesure que des solutions open source solides gagnent de nouveaux
domaines, Smile sera prsent pour proposer ses clients den bnficier sans risque.
Smile apparat dans le paysage informatique franais comme le prestataire
intgrateur de choix pour accompagner les plus grandes entreprises dans ladoption
des meilleures solutions open source.
Ces dernires annes, Smile a galement tendu la gamme des services proposs.
Depuis 2005, un dpartement consulting accompagne nos clients, tant dans les
phases davant-projet, en recherche de solutions, quen accompagnement de projet.
Depuis 2000, Smile dispose dun studio graphique, devenu en 2007 Agence
Interactive, proposant outre la cration graphique, une expertise e-marketing,
ditoriale, et interfaces riches. Smile dispose aussi dune agence spcialise dans la

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 3

Politique Open Source - Pourquoi & Comment


Tierce Maintenance Applicative, le support et lexploitation des applications. Et
Smile a galement une activit d'hbergement.
Enfin, Smile est implant Paris, Lyon, Nantes, Bordeaux, Aix, Montpellier,
Grenoble et Lille. Et prsent galement en Espagne, en Suisse, au Benelux, en
Ukraine et au Maroc.
Ce livre blanc est diffus sous licence Creative Commons Paternit-Pas de
Modification 2.01. Il peut tre redistribu librement. Toutefois si vous l'avez
obtenu ailleurs que sur le site de Smile, il est possible que vous n'ayez pas la
dernire version. Nous vous invitons donc la tlcharger depuis le site de Smile.

[1.2] Ce livre blanc


Ce livre blanc vise expliquer ce qu'est une politique open source, pourquoi les
entreprises doivent entreprendre de dfinir leur politique open source, ce qu'elles y
mettront, quelle sera la dmarche d'laboration et de communication.
Ce livre blanc n'est pas en lui-mme une politique open source, ni mme un modle
de politique open source, mais nous pensons qu'il pourra aider les DSI dfinir la
leur.
Comme on le soulignera plus loin, la politique open source ne vise pas
ncessairement amener davantage d'open source dans le systme d'information,
mme si dans certains cas, ce peut tre l'un des objectifs, pour le plus grand bnfice
de l'entreprise.
Bien entendu, les consultants de Smile sont votre disposition pour vous
accompagner dans votre dmarche et dans vos choix de produits.

http://creativecommons.org/licenses/by-nd/2.0/fr/ .

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 4

Politique Open Source - Pourquoi & Comment

Table des matires


[1] PRAMBULE....................................................................................................1
[1.1]SMILE EN BREF...................................................................................................................... 1
[1.2]CE LIVRE BLANC..................................................................................................................... 2

[2] POURQUOI UNE POLITIQUE OPEN SOURCE ?..................................................4


[2.1]IL Y A DU LOGICIEL OPEN SOURCE DANS VOTRE ENTREPRISE...................................................................4
[2.2]VOUS DEVRIEZ SAVOIR O.......................................................................................................... 4
[2.3]VOUS POURRIEZ GAGNER EN AVOIR DAVANTAGE...............................................................................5
[2.4]DEUX UNIVERS OPEN SOURCE DIFFRENTS.......................................................................................6
[2.5]UNE POLITIQUE OPEN SOURCE..................................................................................................... 7

[3] LA PROPRIT INTELLECTUELLE.................................................................10


[3.1]A QUI APPARTIENT LE PROGRAMME ?............................................................................................ 10
[3.2]LES LICENCES...................................................................................................................... 11
[3.3]POLITIQUE OPEN SOURCE ET LICENCES.........................................................................................12
[3.4]LE DVELOPPEMENT............................................................................................................... 16
[3.5]CONTRATS DE PRESTATION........................................................................................................ 16

[4] CHOIX ET SLECTION DE PRODUITS............................................................18


[4.1]UNE OFFRE PLTHORIQUE, QUELQUES PPITES................................................................................18
[4.2]LA RECHERCHE ET L'IDENTIFICATION DES PRODUITS...........................................................................18
[4.3]DES CRITRES HABITUELS, TOUJOURS D'ACTUALIT...........................................................................19
[4.4]LA PRENNIT...................................................................................................................... 20
[4.5]COMMUNAUT...................................................................................................................... 21
[4.6]LE PROCESSUS DE SLECTION: QUI CHERCHE, QUI CHOISIT ?...............................................................22
[4.7]INTGRER SYSTMATIQUEMENT LES SOLUTIONS OPEN SOURCE LA SLECTION............................................23

[5] LA DMARCHE...............................................................................................24
[5.1]FORMATION & COMMUNICATION................................................................................................. 24
[5.2]UNE FORGE LOGICIELLE.......................................................................................................... 25
[5.3]UN RFRENTIEL.................................................................................................................. 26
[5.4]UNE CELLULE D'EXPERTISE ET DE CONSEIL....................................................................................26
[5.5]LES OUTILS D'AUDIT DE PROPRIT INTELLECTUELLE..........................................................................27

[6] LA CONTRIBUTION ........................................................................................28


[7] LE SUPPORT..................................................................................................30
[7.1]PRODUITS D'DITEURS, PRODUITS COMMUNAUTAIRES.........................................................................30
[7.2]LE SUPPORT SUR LES DIFFRENTES COUCHES..................................................................................31
[7.3]POLITIQUE OPEN SOURCE ET SUPPORT..........................................................................................31

[8] LA DIMENSION COOPRATIVE DE L'OPEN SOURCE......................................33


[9] ANNEXES.......................................................................................................34
[9.1]COPYRIGHT ET LICENCES......................................................................................................... 34
[9.2]L'OPEN SOURCE DANS SA LOGIQUE MUTUALISTE, UN VECTEUR DE COMPTITIVIT.........................................43
[9.3]MMORANDUM DU CIO DEPARTMENT OF DEFENSE.........................................................................46

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 5

Politique Open Source - Pourquoi & Comment

[2] POURQUOI UNE POLITIQUE OPEN SOURCE ?


[2.1] Il y a du logiciel open source dans votre entreprise
Toutes les tudes le confirment, l'open source est prsent dans toutes les entreprises,
grandes et petites. Et ceci, qu'elles l'aient voulu ou non.
Une tude du Gartner de 2009 estimait que 85% des entreprises utilisent dj des
logiciels open source, tandis que les 15% restant envisageaient de le faire. Encore
ne s'agit-il que d'un sondage, et il est vraisemblable qu'un audit sur le terrain aurait
trouv un pourcentage trs suprieur.
Une autre tude, du mme Gartner, prvoit que ds 2011, 80% des logiciels
commerciaux contiendront des composants open source. En d'autres termes, si
l'open source ne rentre pas en tant que tel, les logiciels propritaires vous en
serviront eux-mmes.
De nombreuses entreprises mesurent les bnfices qu'elles peuvent tirer de ces
logiciels, non plus seulement en termes de budgets, mais aussi de robustesse,
d'ouverture, de dynamique de dveloppement et d'indpendance dans les choix.
Et souvent, cet open source officiel n'est que la partie merge de l'iceberg.
Parce qu'il suffit qu'un dveloppeur trouve une librairie sur Internet qui lui fait
gagner du temps, qu'un administrateur trouve un utilitaire open source utile et
performant, qu'un chef de service dploie un produit open source que ses quipes
auront slectionn.
Et, pour l'entreprise, c'est une bonne chose beaucoup d'gards. C'est ainsi que les
produits open source se font connatre: par le bas de l'chelle. Certes, il n'y a
personne pour faire du lobbying en jouant au golf avec le Prsident, mais sur le
terrain, ceux qui dveloppement, administrent, exploitent ou architecturent les
systmes d'information, trouvent des produits de qualit, robustes et srs, et libres
d'utilisation.

[2.2] Vous devriez savoir o


Le constat est le suivant: l'open source est entr dans le systme d'information, dans
certains cas par la porte de service, hors d'un schma directeur, sans politique
formelle. Et une majorit d'entreprises n'ont pas mme un recensement complet de
leurs logiciels open source, des produits utiliss et des composants intgrs leurs
applications.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 6

Politique Open Source - Pourquoi & Comment


Dans beaucoup de cas, les DSI comptent sur le processus d'achat comme ultime
rempart pour faire appliquer leurs choix d'entreprise. Un chef de service peut avoir
des souhaits, peut parler mme tel ou tel fournisseur, mais aucun produit
n'entrera dans le systme d'information sans un bon de commande sign, et c'est au
pire ce stade que la conformit aux orientations de la DSI sera assure. L'open
source se passe de bon de commande et franchit donc ce type de barrire. C'est
d'ailleurs une des qualits souvent apprcies: la rapidit d'acquisition et de mise en
uvre.
Comme nous le dtaillerons plus loin, il y a de nombreuses raisons de vouloir
matriser l'insertion de l'open source dans le systme d'information, pour en tirer le
meilleur bnfice. Et la premire tape d'une politique matrise est souvent de
faire un tat des lieux de ce qui est dj dploy, o, pour quel usage, avec quels
retours.

[2.3] Vous pourriez gagner en avoir davantage


Si l'open source entre dans les entreprises, ce n'est pas juste l'affaire de
programmeurs incontrlables. C'est vritablement que les bnfices sont normes.
Les administrateurs et exploitants le savent: rien n'est plus fiable et performant
qu'un serveur Linux pour faire tourner un serveur d'application java, par exemple,
ou encore une base de donnes.
Depuis longtemps dj, il serait ridicule d'affirmer nous sommes une grande
entreprise, avec un immense systme d'information, critique pour la marche des
affaires, l'open source n'est pas fait pour nous . Car les plus grandes plateformes au
monde sont construites sur des socles open source. Les gants de l'Internet, Google,
Facebook, Amazon et les autres, s'appuient massivement sur des composants et
grands produits open source.
Ils ont des exigences de qualit de service, de
performance et de productivit qui valent bien celles des plus grandes entreprises, et
ils ont choisi l'open source. Ils ont les avocats parmi les plus comptents, les plus
rigoureux et les plus paranoaques du monde. Et a ne les a pas empch de dfinir
une politique open source volontariste.
Dans une tude de Forrester ralise en 2008, puis en 2010, une des tendances qui se
dgage est que les raisons cites pour adopter davantage d'open source dans les
entreprises ont volu, le moindre cot tant moins souvent cit parmi les premires
motivations, tandis que l'indpendance et la libert de choix, la robustesse,
l'ouverture, .. sont plus souvent mentionns.
Nous n'allons pas faire ici le recensement complet des bnfices que peut trouver
l'entreprise dployer des produits open source, ce n'est pas le but. Nous voulons
surtout dmontrer que, puisque toutes les entreprises dploient des produits open
source, il convient qu'elles le fassent de manire encadre.
Parmi les bnfices les plus importants des solutions open source :

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 7

Politique Open Source - Pourquoi & Comment

Prennit nous y revenons plus loin.

Libert de choix: une moindre dpendance (lock-in) vis vis d'un petit nombre
de fournisseurs en situation de monopole ou d'oligopole. Les marges que
procure une position de quasi-monopole sont telles que le march des diteurs
de logiciels se concentre trs rapidement, laissant les clients dans une
situation de dpendances proccupante. Les produits open source de qualit
leur rende un peu de cette libert perdue.

Respect des standards: les logiciels open source sont en gnral plus
respectueux des standards, la fois parce que c'est la condition pour s'appuyer
eux-mmes sur d'autres briques open source, et parce qu'ils ne sont pas dans
une logique de protection.

Dynamique d'volution: les logiciels open source, du moins certains d'entre


eux, ont un dveloppement qui s'appuie en tout ou partie sur une large
communaut de dveloppeurs, ce qui permet un rythme d'volution suprieur.

Standard de fait: certains des grands logiciels open source sont devenus des
standards de fait, de sorte qu'ils concentrent la fois les efforts de
dveloppement et l'expertise disponible.

[2.4] Deux univers open source diffrents


Lorsqu'on parle d'open source, il faut distinguer deux univers assez diffrents:
l'open source des fondations et des communauts d'une part, l'open source des
diteurs d'autre part.
Leur point commun est que leurs programmes sont distribus sous des licences open
source, qui donc donnent le droit d'accder au code source, de l'tudier, de le modifier
et de redistribuer librement le programme. Pour plus d'information sur ces licences
on se reportera l'annexe 9.1 Copyright et licences . Mais pour le reste, leurs
modalits d'utilisation pour l'entreprise sont assez diffrentes.
Dans la catgorie des programmes de fondations et de communauts, on trouve
quelques monstres sacrs, des piliers de l'informatique moderne. Linux soi-mme,
bien sr, ainsi que tous les produits de la fondation Apache (le serveur du mme
nom, mais aussi Tomcat, ActiveMQ, Lucene, SolR, et tellement d'autres qu'on ne
peut les citer ici. Ceux des fondations telles que Eclipse, Mozilla ou la FSF. On
trouve aussi des produits d'origine communautaire, sans fondation, tels que les CMS
Typo3, ou encore Spip.
Dans la seconde catgorie figurent les programmes issus d'diteurs open source. Un
diteur open source est une entreprise commerciale presque ordinaire, but lucratif,
qui a investi dans la ralisation d'un produit, et qui le distribue en tout ou partie
sous une licence open source. Ses motivations pour choisir l'open source peuvent
tre diverses, mais en gnral l'une d'entre elles est d'aider faire connatre et
adopter rapidement le produit. Pour plus d'information sur les diffrents modles
Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 8

Politique Open Source - Pourquoi & Comment


conomiques des diteurs open source, on se reportera notre livre blanc
Comprendre l'open source et les logiciels libre dont un chapitre entier y est
consacr.
La politique open source de l'entreprise devra certainement considrer ces deux
catgories de programmes open source de manire distincte.
Typiquement, en termes de support, les choses sont trs diffrentes. Dans la
catgorie fondations et communautaire, il n'y a pas d'offre de support officielle de
la part de la fondation. Il y a en revanche une communaut de dveloppeurs, des
mailing lists et des forums, qui peuvent tre extrmement ractifs pour certains
produits phares. Pour ces produits, l'entreprise peut s'appuyer sur un prestataire
assurant le support en niveau 1 et 2, et prenant en charge la relation avec les
communauts de dveloppeurs pour le niveau 3. Des distributeurs tels que Redhat
ont une offre de support couvrant l'ensemble de leur distribution.
Pour les programmes d'diteurs open source, la situation est tout fait diffrente: le
support est la base de leurs business models, et ils s'attachent donc avoir une
offre de support de qualit sur tous leurs produits.
En termes conomiques aussi, les deux catgories sont distinguer.
Les
programmes de la premire catgorie sont totalement gratuits d'utilisation: ils n'ont
pas de version autre que la version open source, et la fondation ne demande rien en
change de la libre utilisation de ses programmes, mme si elle apprcie
certainement les dons. Bien sr, le cot total de possession est rarement nul: il
faut bien dployer et configurer ces programmes, puis les exploiter, et dans beaucoup
de cas prvoir une prestation de support.
Dans le cas des programmes d'diteurs open source, il convient en gnral de
financer le dveloppement du produit conduit par l'diteur. Dans certains cas, la
version du produit dont l'usage est recommand en entreprise, et sur laquelle le
support est assur, est une version qui n'est pas sous licence open source. On
entend parfois des critiques envers ce modle, parfois appel freemium, o le logiciel
open source est un produit d'appel pour le vrai logiciel. Mais au final, l'entreprise
fait son choix sur le bilan conomique du logiciel, son rapport service rendu / cot
total de possession. Et les logiciels open source, quel que soit leur modle, sont le
plus souvent gagnants sur ce critre.

[2.5] Une politique open source


Qu'est-ce qu'une politique open source ?
La politique open source de l'entreprise est un document qui dfinit ce que
l'entreprise dcide en matire de dploiement de logiciel open source, quels sont les
critres de slection, les exigences en termes de support, les licences acceptes, les

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 9

Politique Open Source - Pourquoi & Comment


consignes adresses aux dveloppeurs, les processus d'acquisition et de mise en
uvre, les modalits de contribution, etc.
On rencontre parfois le terme de gouvernance open source, pour dsigner la mme
chose. Le terme nous semble moins appropri, la gouvernance faisant davantage
rfrence des processus de dcision. Certes, la dfinition de la politique open
source suit son propre processus, mais elle est fondamentalement de la
responsabilit de la DSI, et le plus important n'est pas de savoir qui en dcide, mais
quelle voie elle montre.
D'autres parlent aussi de schma directeur open source, mais ici aussi, c'est un peu
diffrent. Un schma directeur open source pourrait dfinir une situation cible de
systme d'information appuy sur l'open source, et la voie suivre pour atteindre
cette cible. Il nous semble que la politique open source peut s'intgrer au schma
directeur, mais l'un et l'autre ne se confondent pas.

L'open source cohabite avec le propritaire


Peu d'entreprises sont parvenues tre 100% open source et, il faut l'avouer, pour
une majorit d'entre elles ce ne serait pas ais. Les systmes d'information sont
donc amens voir cohabiter des logiciels open source et des logiciels propritaires.
Ce n'est pas un problme, mais c'est un phnomne qui s'est accentu ces dernires
annes, et qui demande tre bien compris et mieux matris.
Sur le plan technique, bien entendu, cette cohabitation ne prsente pas de difficult
particulire. En rgle gnrale, les solutions open source sont plus respectueuses
des standards, et donc offrent de meilleures possibilits d'interoprabilit. Mais c'est
bien sr au cas par cas que cette question devra tre tudie. L'accs au code source
contribue parfois faciliter cette intgration.
Dans beaucoup de cas, l'open source intervient particulirement sur les couches
basses du systme d'information: OS, virtualisation, serveur d'application,
middleware, annuaire, utilitaires d'infrastructures. Et au dessus de cette pile se
positionneront diffrents produits, propritaires ou bien galement open source.
Sur le plan juridique, les incidences de cette cohabitation sont bien cibles, nous les
dtaillerons plus loin. Lorsque deux produits, l'un open source, l'autre propritaire,
sont installs cte cte et interfacs par des protocoles et changes standards, il n'y
a pas la moindre considration particulire au plan juridique. C'est lorsque open
source et propritaire sont intgrs en un mme programme que des impacts sont
considrer.
Mais, comme on le verra plus loin, open source et propritaire doivent cohabiter
dans d'autres domaines encore: dans le schma directeur, dans la bote outil de
l'architecte, dans les rflexes du dveloppeur, mais aussi dans les processus de
slection et d'achats.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 10

Politique Open Source - Pourquoi & Comment

Pourquoi une politique open source ?


La politique open source est un document qui nonce la politique de l'entreprise vis
vis de l'open source.
Elle permet une DSI de piloter, matriser, organiser et accompagner, le
dploiement de composants et produits open source.
Elle est une condition ncessaire pour (1) tirer tous les bnfices du dploiement de
solutions open source, et (2) matriser les risques, viter les piges.
Elle tablit des directions suivre, des recommandations, des interdits, elle dfinit
des process et dsigne des responsables, mais elle vise aussi former et
accompagner tous les acteurs impliqus dans l'entreprise.

Une politique open source n'est pas une politique en faveur de


l'open source
Notez bien que la question n'est pas de savoir si la DSI apprcie les bnfices
spcifiques de l'open source, ou si au contraire elle s'en mfie. Dfinir une politique
open source ce n'est pas ncessairement dfinir une politique en faveur de l'open
source. A la rigueur, la politique open source de la maison pourra se limiter
dclarer pas de a chez nous ! . Mais mme dans ce cas, il faudra encore expliquer
ce qu'on fait avec tous les produits qui sont dj l, comment on s'en passe ou par
quoi on les remplace, quels sont les budgets allous cette migration hors de l'open
source
Donc encore une fois que l'on veuille plus d'open source, ou que l'on veuille moins
d'open source, il faut dans tous les cas dfinir sa politique open source.
D'autant que, comme nous le verrons ici, la question a de multiples facettes, et ne se
rduit videmment pas plus versus moins .
Notons enfin que l'tude Gartner cite plus haut valuait 31% le nombre
d'entreprises qui avaient dj dict une politique open source. Mais c'tait aux
Etats-Unis, dbut 2009. Il est probable que ce pourcentage a dj augment, mais il
est vraisemblable aussi qu'il serait bien moindre en France.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 11

Politique Open Source - Pourquoi & Comment

[3] LA PROPRIT INTELLECTUELLE


La politique open source a bien sr des aspects juridiques importants, mais elle ne
doit pas pour autant tre laisse entre les mains des seuls avocats. Dans beaucoup
de cas, il s'agit de dfinir, pour le contexte spcifique de l'entreprise, quel est le
meilleur quilibre entre bnfices et risques, et si les avocats sont utiles pour
souligner les risques, ils percevront certainement trs mal les bnfices.
Au chapitre juridique, le plus important est d'apporter aux acteurs un minimum de
formation, teindre les fausses ides, et attirer l'attention sur les vrais impacts.

[3.1] A qui appartient le programme ?


Lorsqu'un dveloppeur crit du code pour son employeur, l'entreprise dtient la
proprit intellectuelle du programme.
Elle est libre d'en faire l'usage qu'elle
choisit, en particulier de l'utiliser comme bon lui semble, de le distribuer sous la
licence qui lui semblera la plus approprie, et galement de revendre son droit
d'auteur en tant que bien immatriel. videmment, pour un produit qui connait un
certain succs, cette proprit intellectuelle peut avoir une valeur chiffre en
dizaines ou centaines de millions d'euros. Ce n'est donc pas anodin.
Et bien sr, l'usage jug le plus appropri peut changer dans le temps: un
programme initialement prvu pour un usage interne peut en fin de compte tre
distribu, puis un jour l'entreprise peut tre mise en vente, et le programme sera
valoris comme un actif.
Il est donc important pour l'entreprise de savoir quel est l'tat des lieux de sa
proprit intellectuelle sur les programmes qu'elle possde, qu'ils aient t
dvelopps en interne ou bien achets. Car la question se pose de la mme manire
pour un programme dvelopp par un prestataire pour l'entreprise. De manire un
peu plus complexe seulement puisqu'il s'agit alors de savoir (a) quelle tait la
proprit du prestataire lui-mme sur le code qu'il a livr, et (b) quel a t le
transfert de proprit dans le cadre du contrat de fourniture.
Il est important de bien comprendre que la proprit intellectuelle se dfinit au
niveau microscopique, sur quelques lignes de code seulement. Si un dveloppeur
trouve 50 lignes de code qui lui simplifient la vie, et les colle dans son programme,
alors il est vraisemblable que son employeur n'a plus la proprit complte du
programme ainsi ralis.
Il n'y a pas de seuil officiel du nombre de lignes qui
puissent tre sujette un droit d'auteur.
Les diteurs de programmes ont bien compris l'importance de la proprit
intellectuelle, non pas juste d'une manire globale, mais au plus fin, jusqu'au plus

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 12

Politique Open Source - Pourquoi & Comment


petit composant. Mais les autres entreprises doivent s'en proccuper galement car,
encore une fois, on ne sait pas toujours quel sera le devenir d'un programme, en
termes de proprit, surtout s'il est de grande qualit.
Soulignons que les considrations cites ici ne sont pas propres aux composants open
source. Encore une fois, la seule particularit est que ceux-ci demandent moins de
permission pour s'insrer dans un programme, ou dans un systme d'information.

[3.2] Les licences


Principes lmentaires
Les programmes open source ne sont pas des programmes sans licences comme on
l'entend parfois. Cest au contraire leur licence qui les fait open source. Ils ne sont
pas non plus dans le domaine public, cest dire nappartenant personne en
particulier, ou du moins exempts de droits patrimoniaux.
Lorsquun dveloppeur crit un programme, il en dtient les droits dauteur, le
copyright. Dans certains cas, ce peut tre lentreprise qui lemploie qui en dtient
les droits.
Et ce copyright peut tre vendu, comme bien immatriel, dune
entreprise une autre.
Le dtenteur du copyright est libre de dfinir lutilisation qui peut tre faite de son
programme :

Il peut le garder pour lui, en interdire lutilisation qui que ce soit.

Il peut vendre ses droits un tiers, personne physique ou morale.

Il peut utiliser son droit dauteur pour prciser les conditions quil pose
lutilisation de son programme. Il crit ces conditions dans les termes de la
licence dutilisation.

A noter quen droit franais, il nest pas ais dabandonner ses droits et de mettre son
programme dans le domaine public de manire irrversible.
Il faut bien expliquer aussi que ce nest pas la diffusion des sources qui fait quun
programme est open source, cest 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 lopen
source il y a la licence, et la licence nexiste qu partir du droit dauteur.
Ainsi tous les logiciels open source ont un propritaire, ils ne sont pas personne ,
ni mme tout le monde .
Dans certains cas, ce propritaire peut tre une
fondation but non lucratif, ou bien ce peut tre une entreprise commerciale

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 13

Politique Open Source - Pourquoi & Comment


ordinaire. Il peut s'agir aussi de plusieurs coauteurs, en particulier la suite de
contributions successives.
Le dtenteur des droits est libre de fixer les conditions de licence, il est libre den
changer mme, et il est libre dy faire des amnagements ou exceptions, ou de
diffuser certains selon une licence, dautres selon une autre licence.
Celui qui reoit le programme, en revanche, nest pas libre. Il est li par les termes
de la licence. Certes il na pas sign de contrat, mais la licence lui a t bien
nonce, et elle stipule quil na le droit dutiliser le programme que sous telles et
telles conditions.
Sil refuse ces conditions, il na pas le droit dutiliser le
programme.

Analyse et impacts des licences


Nous reproduisons en annexe le chapitre Licences de notre livre blanc intitul
Introduction l'open source et au logiciel libre , qui est plus complet sur le sujet.

[3.3] Politique open source et licences


La politique open source devra donc dfinir ce que l'entreprise souhaite et permet en
termes de licences.
On voque les licences le plus souvent concernant un produit complet, et ses
conditions de dploiement et d'utilisation. Et dans le cas d'un produit complet, les
DSI ont gnralement t sensibilises, parfois svrement, par les diteurs
propritaires. Nous verrons que c'est au niveau composant et librairies que l'affaire
mrite plus d'attention.

Programme utilis en l'tat


Lorsqu'il s'agit d'utiliser un produit complet, en l'tat, off the shelf , les produits
open source sont absolument limpides: ils ne prsentent aucune restriction
d'utilisation, ni en nombre d'instances, de serveurs, d'utilisateurs, ni en finalit
d'utilisation. Et ceci quelles que soient leurs licences, du moment qu'elles sont de
nature open source. Cela inclut galement un produit configurable, que ce soit de
manire interactive, ou par le moyen d'un fichier de configuration.
A cet gard, les logiciels open source sont infiniment plus simples, juridiquement,
que n'importe quel produit propritaire, c'est important souligner. La dfinition
mme d'une licence open source implique qu'il n'y a aucune restriction ou condition
l'utilisation du programme.
Et les clauses subtiles des licences open source
concernent uniquement les uvres drives, que l'on voquera plus loin.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 14

Politique Open Source - Pourquoi & Comment


Donc, concernant des produits utiliss en l'tat, la politique open source peut se
proccuper de support, de prennit, de conformit aux standards et de bien d'autres
choses, mais n'a du moins pas se proccuper de risques juridiques.
Du moins, pour tre prcis, il faut ajouter: pour autant que le programme en
question puisse rellement tre sous la licence open source indique. Car on peut
imaginer qu'un dveloppeur assemble des composants de diverses origines pour
constituer un programme, et dclare ce programme disponible sous une licence open
source. Il est reu comme tel par l'entreprise, mais en ralit, l'auteur n'tait pas en
droit de le diffuser sous cette licence. Soulignons ici qu'une telle situation n'est pas
propre aux logiciels open source, elle peut se produire l'inverse pour des logiciels
propritaires utilisant des composants GPL sans le dire. Ainsi en novembre 2009,
Microsoft a du reconnatre qu'un programme distribu, le Windows 7 USB/DVD
Download Tool, utilisait du code GPL et n'en respectait pas les exigences.

Composants logiciels, librairies et morceaux de code source


La question des licences est plus dlicate et plus complexe concernant de petits
composants, intgrs des programmes. Copier quelques dizaines de lignes d'un
programme A pour les coller dans un programme B suffit faire du programme B
une uvre drive du programme A. Et selon les conditions de licence du
programme A, cela peut entraner des exigences particulires quant au programme
B, particulirement dans le cas o il serait distribu.
En gnral, les juristes des entreprises prfrent les licences dj bien connues et
bien analyses, sur lesquelles on trouve une large littrature, et une certaine
jurisprudence. Et a contrario, ils se mfient des licences trop particulires, qui
demanderaient tre tudies.
Les licences dites non-copyleft, telles que BSD, Apache APL, MIT, et quelques
autres, ne prsentent pas de risque juridique particulier, et doivent tre acceptes
sans attention particulire.
La licence GPL, en V2 ou en V3, est une licence dite copyleft, et ce titre prsente
une exigence particulire : si une uvre drive est distribue, alors elle doit l'tre
sous la mme licence. On se reportera l'annexe 9.1 pour plus de prcisions sur ce
que signifient uvre drive et distribuer. Une chose essentielle retenir est que
toute forme d'usage interne l'entreprise n'est pas une distribution et n'est donc pas
concerne par cette exigence. Elle est considrer donc lorsqu'il y a une perspective
de distribution, et particulirement de distribution payante, du programme qui
aurait t construit en intgrant un composant sous licence GPL.
Pour une entreprise qui opre un service en ligne et elles sont de plus en plus
nombreuses la licence AGPL, ou Affero GPL, prsente une exigence semblable. A
la manire de la licence GPL, une uvre drive, c'est dire intgrant un composant
AGPL, si elle est rendue disponible en tant que service en ligne, doit alors donner
accs au code source de l'uvre.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 15

Politique Open Source - Pourquoi & Comment


Enfin, entre copyleft et non copyleft, les licences de type weak copyleft telles que
MPL, CDDL ou EPL, permettent une utilisation commerciale, mais portent
nanmoins quelques exigences importantes.

Synthse juridique
Ainsi, on pourrait dire en synthse:
Licences non open source

En gnral trs restrictives quant aux uvres


drives, parfois totalement interdites, parfois
autorises contre paiement d'un droit d'utilisation
et avec limitations.

Licences non-copyleft connues


(BSD, Apache APL, MIT, etc.)

Peu de contraintes au plan juridique.

Licences weak copyleft connues Intgration possible des uvres drives non
(Eclipse, Mozilla MPL, CDDL open source, mais des exigences particulires
etc.)
considrer.
Licence GPL

Des contraintes en cas de distribution d'une


uvre drive.
N'est pas adapte pour les
diteurs de logiciels non open source.

Licence AGPL

Des contraintes en cas d'offre de service en ligne


sur la base de l'uvre drive. N'est pas adapte
pour les diteurs de services en ligne qui estiment
que leur code driv constitue un atout
concurrentiel.

Licence LGPL

Elle permet qu'un programme appelle les


fonctions d'une librairie LGPL sans qu'il soit
requis que le programme soit distribu sous une
licence particulire.
En revanche, modifier la
librairie elle-mme implique de la redistribuer
sous la mme licence LGPL, si du moins on
choisit de la redistribuer, ou de redistribuer le
programme qui en fait usage.

Autres licences, moins connues

A tudier au cas par cas, en gnral moins


apprcies.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 16

Politique Open Source - Pourquoi & Comment


Enfin, il faut une mention particulire pour les programmes dont une version existe
sous une licence open source, mais qui sont le plus souvent utiliss sous une version
non open source. Dans ce cas, on est ramen en pratique au cas des licences
commerciales ordinaires, c'est dire qu'il y a en gnral des restrictions
d'utilisation, que ce soit en termes de serveurs, d'instances, de processeurs ou
d'utilisateurs.
Ce que l'on peut figurer comme ceci:
Etablissement
public

Editeur d'un
service en ligne

Licence LGPL

Licence GPL

Licence AGPL

Licences non open source

Typologie d'entreprise
Entreprise
Editeur de
commerciale
logiciel

Licences non-copyleft connues


(BSD, Apache APL, MIT)
Licences weak-copyleft (MPL,
CDDL, Eclipse)

Autres licences open source ,


moins connues

Nous n'avons pas voulu mettre ici des marques de type Oui / Non , car ce n'est pas
appropri. Nous ne mettons que des ? , pour indiquer des situations qui mritent
plus ou moins d'attention.
Nous avons distingu les tablissements publics, dans la mesure o la valorisation
de leur proprit intellectuelle sur le logiciel n'est le plus souvent pas dans leurs
perspectives.
Ce tableau, avec toutes ses imperfections, illustre aussi une chose: les licences
propritaires, de leur ct, prsentent toujours d'importantes restrictions juridiques.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 17

Politique Open Source - Pourquoi & Comment

[3.4] Le dveloppement
Comme on l'a vu au chapitre prcdent, c'est dans le processus de dveloppement
que l'on est susceptible de crer une uvre drive, avec les implications que l'on a
voques.

La cible de la politique open source


La cible de la politique open source inclut tous les acteurs du dveloppement, en
particulier chefs de projets et dveloppeurs. Il est important qu'ils soient informs,
d'une part des rgles gnrales rgissant le copyright et les licences, telles que
prsentes plus haut, et d'autre part des directives particulires donnes par la
socit dans le cadre de leur dveloppement.
Il faut bien mesurer que la plupart en sont trs mal informs.

Ne pas rinventer la roue


De tout temps, on a demand aux dveloppeurs de ne pas rinventer la roue, de
concentrer leurs efforts sur ce qui est spcifique, de rutiliser au maximum. Et
aujourd'hui, le dveloppeur applique ces consignes en s'alimentant sur le web, o il
trouve rapidement une librairie ou un morceau de code qui rpond son problme.
C'est grce ce recours gnralis aux composants open source que le
dveloppement moderne est d'une productivit dcuple, et l'entreprise qui voudrait
s'en passer aurait un prix lev payer.
Il ne s'agit pas ncessairement de faire la police, de contrler ce que chaque
dveloppeur utilise. Il s'agit en premier lieu d'expliquer aux dveloppeurs que ces
petits composants, ces quelques lignes de code, ne sont pas sans consquences. Et
d'autre part de leur expliquer la politique open source, leur expliquer ce que
l'entreprise leur demande de faire ou leur interdit de faire. Car une majorit de
dveloppeurs, voire de chefs de projets, est tout simplement ignorante sur la
question.

[3.5] Contrats de prestation


Lorsque des fournisseurs livrent un logiciel ralis dans le cadre d'un contrat de
prestation, les entreprises savent qu'il convient de prciser qu'il y a transfert de
priorit du fournisseur vers le client. Mais cela suppose que le fournisseur ait lui
mme la pleine proprit de la totalit de ce qu'il livre.
Il serait assez rtrograde et fort coteux d'interdire l'intgration de composants open
source une application que l'on fait raliser par un prestataire.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 18

Politique Open Source - Pourquoi & Comment


En fait, il convient de prciser dans le contrat :

Soit que le fournisseur ne peut utiliser que des composants sous telles licences,
ou bien telles catgories de licences, qui conviennent au client

Soit que le fournisseur doit faire valider par le client les composants qu'il
intgre au logiciel.

Et il faut qu'il soit bien entendu pour chacune des parties que composant couvre
galement des portions de code source recopies.
Mais ces dispositions contractuelles ne suffisent pas. Il faut encore s'assurer que le
prestataire prend les mesures ncessaires pour que ses quipes comprennent ces
exigences, leur motivation et leurs implications.
Soulignons encore une fois que ces disposition ne sont en rien spcifiques l'open
source, elles s'appliquent tout fournisseur.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 19

Politique Open Source - Pourquoi & Comment

[4] CHOIX ET SLECTION DE PRODUITS


[4.1] Une offre plthorique, quelques ppites
Il existe 230 000 logiciels disponibles sur le site SourceForge.net, l'une des
plateformes de rfrence des projets open source, et peu prs autant sur Google
Code. Et beaucoup des plus grands projets ne sont pas sur des plateformes globales
de ce genre.
A l'vidence, un grand nombre de ces projets sont encore en cours de dveloppement,
ou sont de pitre qualit. Beaucoup n'ont en fait qu'un seul dveloppeur, et ne
seront jamais vraiment achevs.
Alors comment faire son choix ?

[4.2] La recherche et l'identification des produits


La recherche d'une solution open source rpondant ses besoins suit une dmarche
profondment diffrente de celle habituelle pour les produits propritaires:

On ne peut gure compter sur les salons commerciaux, et encore moins sur des
encarts publicitaires, pour reprer les meilleurs produits open source. Leurs
diteurs concentrent gnralement leurs ressources sur le dveloppement, et
n'ont gure de budget marketing.

On ne doit pas non plus compter sur les recommandations du Gartner ou


d'autres, qui mconnaissent profondment l'open source.

C'est souvent par une simple recherche Google qu'on pourra tablir une
premire liste, au moins sur un critre de notorit. La notorit n'est pas
tout, mais elle est un bon critre pour un premier filtre, car un produit
mdiocre fera gnralement peu parler de lui.

Une fois identifis quelques produits, on pourra chercher encore des avis et
retours d'exprience sur le web.

On trouvera souvent diffrents sites dressant des recensements d'outils dans


une catgorie donne. Il est rare qu'ils soient trs dtaills dans leur analyse,
mais c'est une source complmentaire d'information.

Bien entendu, les livres blancs de Smile peuvent tre de prcieuses aides au
choix. Ils constituent des tudes plus compltes que les simples sites
comparateurs.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 20

Politique Open Source - Pourquoi & Comment

Enfin, une caractristique importante des produits open source est qu'il est
ais de les installer et de les valuer, que ce soit avec des ressources internes,
ou en s'appuyant sur des prestataires spcialiss.

Au travers de cette recherche, on s'attachera bien sr valuer chacun des critres


lists plus haut, que l'on aura pondr sa guise. Dans beaucoup de cas, on mettra
en comptition produits open source et produits propritaires sans a priori, en
laissant l'valuation les dpartager au final.

[4.3] Des critres habituels, toujours d'actualit


L'un des chapitres les plus importants de la politique open source porte sur les
critres de choix et de slection de produits et composants.
Les critres fondamentaux sont bien sr identiques ceux qui concernent les
logiciels propritaires, typiquement:

La rponse fonctionnelle au besoin identifi

La capacit voluer ou accueillir des extensions pour rpondre un besoin


plus large

La capacit accueillir une volumtrie plus importante

Le respect des standards

La robustesse et la qualit technique du produit

L'ouverture et la capacit s'interfacer d'autres composants du systme


d'information

La performance, la tenue en charge, les temps de rponse

L'utilisabilit, l'ergonomie

La disponibilit d'une documentation

La qualit du support

La prennit

La diversit des fournisseurs et prestataires, la concurrence et la libert de


choix

Le cot initial et le cot rcurrent.

L'existence d'une feuille de route d'volutions pour les annes venir

Et bien sr, les modalits de licence et leurs impacts

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 21

Politique Open Source - Pourquoi & Comment


Ce ne sont l que des critres trs habituels. Nous disons que sur bon nombre de
ces critres, les logiciels open source auront des atouts spcifiques. Mais c'est bien
sr dmontrer au cas par cas.
Ce que doit faire la politique open source, c'est au minimum affirmer l'ligibilit et
l'galit des produits open source dans cette recherche, et de s'assurer galement
qu'ils ne sont pas pnaliss par des croyances errones.
L'valuation et la pondration de chacun de ces critres dpendra bien entendu du
contexte particulier de l'entreprise et du projet.
Il y a toutefois quelques petites spcificits des logiciels open source.

[4.4] La prennit
Les produits open source offrent souvent des perspectives suprieures en termes de
prennit. Pour autant, elles n'ont pas une garantie d'ternelle jouvence.
Il faut distinguer en fait diffrents cas de figure:

Les produits phares de fondations et communauts. Lorsqu'il sont devenus


des standards de fait, l'image de Apache, Tomcat, ou encore OpenSSL, mais
des dizaines d'autres encore, leur prennit est assure pour une bonne dizaine
d'annes au moins.

Les produits communautaires moins en vue. Il n'est pas impossible que leur
activit vienne dcrotre progressivement, gnralement au profit d'une
autre solution, qui aura des atouts particuliers et aura russi gagner une
meilleure dynamique de dveloppement.
Mais ce mouvement prend en
gnral quelques annes, et l'on a tout le temps pour organiser une migration.

Dans tous les cas, les produits de fondation ou bien communautaires ne rpondent
pas une logique commerciale, ce qui les rend moins fragiles. Ils dpendent moins
de leurs clients que de leur communaut de dveloppeurs, qui sont moins volatiles.

Les produits d'diteurs obissent une logique diffrente, plus ordinaire. Un


diteur open source peut faire faillite, ou bien tre l'objet d'une acquisition,
comme il y en a eu bon nombre ces dernires annes. Et l'acqureur peut
avoir une politique diffrente vis vis du produit. La prennit de l'diteur
open source s'valuera sur des critres habituels: annes d'exprience, base
installe, fonds levs, etc.

Mais une chose fondamentale en matire de prennit est que, pour un logiciel sous
licence open source, vous avez dans tous les cas le droit d'utiliser (et mme de
modifier et de distribuer) le produit sans limitation, ni de primtre ni de dure.
Un autre point essentiel est la possibilit d'un fork , c'est dire de la poursuite du
dveloppement par une autre entreprise, ou par une communaut de dveloppeurs,
Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 22

Politique Open Source - Pourquoi & Comment


partir d'une certaine version open source. C'est en phnomne relativement rare,
mais qui peut se produire en particulier si un acteur modifie sa politique
commerciale unilatralement.

[4.5] Communaut
Qu'est-ce qu'une communaut ?
La communaut est une notion trs spcifique au logiciel open source.
Le communaut, c'est tout simplement l'ensemble des personnes qui participent la
vie du logiciel. Non pas uniquement les dveloppeurs, mais tous ceux qui sont
disposs faire quelque chose pour aider l'panouissement du logiciel. Celui qui
rpond une question pose sur un forum participe dj la communaut. Celui
qui signale ce qui lui semble tre une anomalie, contribue la validation et donc la
meilleure robustesse du logiciel. D'autres traduisent des interfaces ou bien de la
documentation. A sa manire, le simple utilisateur fait partie de la communaut
aussi; en parlant un ami, ou un collgue, il va contribuer faire connatre le
produit, et lui donner une plus large diffusion.
Ainsi, la communaut est une notion dont les contours ne sont pas dfinis avec
prcision. Et pourtant, tout le monde s'accorde penser qu'elle joue un rle de
premire importance pour un logiciel open source, tant la fois l'indicateur et le
facteur de sa vitalit, donc de sa prennit.

Noyau et extensions
Dans le cas des produits d'diteur open source, mme si l'essentiel du produit, le
noyau, est entre les mains des quipes de l'diteur, la communaut conserve une
grande importance. Les produits modernes ont souvent adopt une architecture de
type noyau-extensions, parfois appele hub and spoke , o le cur du produit est
complt par des extensions dveloppes par d'autres, entreprises ou particuliers.
Lorsque le dploiement du produit dans un contexte particulier requiert des
fonctionnalits supplmentaires, on ne modifie pas directement le code source du
produit, on ajoute une extension, qui apporte la fonctionnalit manquante. Cette
extension peut facilement tre rendue disponible pour d'autres projets. Certains
projets open source mettent disposition plusieurs centaines d'extensions de cette
nature, qui non seulement compltent le produit, mais mme lui donne une toute
autre dimension.

Mesurer la dynamique communautaire


La force de la communaut est donc un des critres de slection d'un produit open
source.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 23

Politique Open Source - Pourquoi & Comment


Pour l'valuer, on peut s'appuyer sur:

Le Page Rank de Google, ou encore des outils tels que Google Trends, ou
encore Alexa, valuant la popularit du produit et de son site, et permettant de
comparer les produits entre eux.

Les forums, le nombre de posts, et plus encore les rponses aux questions
poses, nombre et dlai moyen.

Le nombre de dveloppeurs et de commiters.

Le nombre de tlchargement du produit (mais certains produits gonflent cet


indicateur de manire artificielle).

Pour les produits d'diteurs, le nombre de dveloppeurs qui n'appartiennent


pas la socit ditrice.

Le nombre d'extensions disponibles et l'existence d'un rfrentiel rpertoriant


ces extensions.

[4.6] Le processus de slection: qui cherche, qui choisit ?


Selon les cas, la politique open source peut soit:
1. Centraliser la slection de solutions, entre les mains d'une petite quipe, qui
slectionne et valide les produits, dans une version donne, et laborent une
sorte de catalogue open source de l'entreprise. Les architectes, chefs de
projets et dveloppeurs ne sont autoriss qu' choisir dans le catalogue.
2. Centraliser la slection des produits majeurs, structurants, tels que base de
donnes, middleware, frameworks, outils de dveloppement. Mais laisser
une certaine libert aux dveloppeurs et chefs de projet pour trouver des
outils de niche en complment des premiers.
3. Poser des rgles gnrales de slection de produits et laisser une large
autonomie dans leur mise en uvre.
Il nous semble que la voie (2) est un bon compromis, certains composants devant
imprativement tre unifis au sein du systme d'information, tandis que pour des
petits outils, il peut tre utile de conserver une certaine agilit.
Encore faut-il bien dfinir ces rgles de choix, sur les critres cits plus haut,
incluant en particulier les questions de licences ou de support, et assurer la
formation des quipes sur ces sujets.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 24

Politique Open Source - Pourquoi & Comment

[4.7] Intgrer systmatiquement les solutions open


source la slection
Quelle est la place souhaite des solutions open source dans les achats logiciels de
l'entreprise ?
De nombreux tats et organismes publics ont dict une politique open source qui
nonce que, dans tout processus d'acquisition, les solutions open source doivent tre
considres.
Cela ne signifie pas qu'elles doivent tre retenues, mais que le
processus d'achat doit les mettre dans la course, et qu'en consquence bien sr, si
elles ne sont pas retenues, les raisons doivent en tre bien identifies.
Une telle politique de considration de l'open source est un pas important, et nous
semble tre le minimum. Se priver dlibrment des outils qui constituent le socle
de l'informatique moderne, des outils sur lesquels s'appuient toutes les grandes
plateformes de l'Internet, serait une aberration.
Obliger considrer les offres open source revient affirmer que d'une part il n'y a
pas de problme particulier choisir ces solutions, et d'autre part que, si leurs
qualits intrinsques sont gales, elles peuvent avoir des bnfices spcifiques.
Bien sr, certains vont plus loin, et noncent qu'il convient de prfrer des solutions
open source. C'est prcisment l'un des rles de la politique open source, que de se
positionner entre le minimum, mettre en lice l'offre open source, et une ligne plus
volontariste.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 25

Politique Open Source - Pourquoi & Comment

[5] LA DMARCHE
[5.1] Formation & Communication
En octobre 2009, le CIO Chief Information Officer , c'est dire le DSI, du
Department of Defense (DoD) amricain, adressait l'ensemble de ses services un
mmo qui est une bauche de politique open source. Nous reproduisons en annexe
[9.3] Mmorandum du CIO Department of Defense , le texte de ce court mmo, qui
est particulirement instructif.
L'un des points souligns par le CIO est le suivant:
Il y a une mauvaise interprtation qui voudrait que le Gouvernement soit oblig de
distribuer au public le code source de n'importe quel logiciel open source, et que, en
consquence, le logiciel open source ne devrait pas tre intgr ou modifi pour un
usage dans des systmes classifis ou bien sensibles du DoD. .
a n'est qu'un point parmi d'autres. Ce qu'il illustre, c'est que le CIO a estim
ncessaire de combattre une croyance errone, et de s'assurer que ses services ont
une vision correcte du logiciel open source. C'est absolument fondamental.
Dans le mme mmo, le CIO prcise:
Mme si ces considrations (les bnfices cits des logiciels open source) sont
importantes, elles ne peuvent pas tre les aspects prminents de toute dcision
concernant le logiciel. En fin de compte, c'est le logiciel qui rpond le mieux aux
besoins et la mission du Dpartement qui doivent tre utiliss, qu'ils soient ou non
open source
On est donc typiquement dans une politique open source, qui ne dit pas il faut un
maximum d'open source , mais qui dit vous devez bien mesurer les bnfices de
l'open source, vous ne devez pas laisser une mconnaissance du sujet influer sur vos
dcisions, mais in fine, vous devez prendre le meilleur produit.
Un tel mmo, sign du plus haut responsable informatique, est bien videmment la
premire tape dans la communication sur la politique open source de l'entreprise.
Mais il ne suffit pas, bien entendu, et doit tre complt par:

Le texte intgral de la politique open source, accessible tous et rgulirement


mis jour, avec les diffrents chapitres voqus ici.

Un site interne de rfrence, qui fournisse en particulier

L'information de rfrence en matire d'open source dans l'entreprise

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 26

Politique Open Source - Pourquoi & Comment

Une FAQ, enrichie par des questions/rponses en continu

Un ensemble de bonnes pratiques

Des retours d'exprience de projets ayant dploy des outils et


composants open source

Des liens vers diffrentes ressources externes

Un rfrentiel des solutions et composants dont l'usage est recommand dans


l'entreprise

Un cursus de formation destination des chefs de projets et chefs de service.

La politique open source de l'entreprise devra comporter un volet communication,


destination de tous les acteurs impliqus dans ce dploiement, en particulier :

Dveloppeurs

Chefs de projets

Architectes

Responsables de dpartements

Matrises d'Ouvrage

Achats.

Bien qu'on en parle beaucoup, l'open source est trs souvent mal connu, de
nombreux clichs subsistent et des croyances errones sont combattre.

[5.2] Une forge logicielle


L'open source, c'est aussi une manire diffrente d'aborder le dveloppement, en
particulier dans le contexte de grands projets o interviennent de trs nombreux
dveloppeurs. Il y a assez peu d'entreprises qui ont, en interne, des projets de cette
nature.
Nanmoins, de nombreux aspects des approches modernes du
dveloppement ont pris naissance dans ces projets open source, intgration continue,
par exemple, mais aussi mthodologies agiles. C'est pourquoi, mieux connatre
l'open source, y compris dans ses mthodes, peut apporter beaucoup aux entreprises.
Dans certaines organisation, il existe des projets de cette nature, qu'ils soient open
source ou non, qui font intervenir des dveloppeurs de diffrentes quipes, dans
diffrents pays, travaillant ensemble hors de la hirarchie structure habituelle. Il
existe aussi des projets qui font intervenir des socits partenaires, au sein d'un
consortium, par exemple des projets de recherche.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 27

Politique Open Source - Pourquoi & Comment


Pour ces projets, il est tout fait pertinent de mettre en place une forge logicielle,
runissant un ensemble d'outils d'aide au dveloppement collaboratif.
Et bien sr, c'est d'autant plus pertinent pour un projet open source auquel participe
l'entreprise. D'une manire gnrale, la bonne pratique n'est pas de dvelopper
puis de poser le projet sous Sourceforge, GoogleCode ou ailleurs, il est toujours
prfrable qu'un projet open source soit mis sous une forge le plus en amont possible.

[5.3] Un rfrentiel
Pour une entreprise qui mesure les bnfices qu'elle peut tirer des produits open
source, et qui souhaite en promouvoir l'utilisation, il ne suffit pas de dire ses
quipes: vive l'open source, allez-y, foncez ! Il faut les accompagner et les aider en
particulier faire les bons choix, et des choix cohrents au sein de l'entreprise. Si
les RH ont fait un site en Drupal tandis que la communication a utilis eZ Publish,
ce n'est pas une bonne chose. Si la filiale allemande dploie du PostgreSql tandis
que les anglais prfrent utiliser MySql, ce n'est pas bon non plus. Mme chose si
tel dpartement dveloppe en framework Zend et tel autre en Symfony.
En fait, ces quelques exemples relvent d'un objectif d'harmonisation qui n'est pas
propre l'open source: pour les choix majeurs de plateformes et de frameworks, les
entreprises cherchent dj dfinir des prconisations groupe contraignantes, qu'il
s'agisse ou non de composants open source. Mais rappelons nous encore une fois
que, comme il n'y a pas d'achat, il n'y a pas de contrle, et la connaissance des
recommandations est donc plus encore importante.
Bien sr, la recommandation groupe ne porte pas uniquement sur des produits, mais
bien sur des versions de produit, constituant des plateformes logicielles compltes,
cohrentes et valides.

[5.4] Une cellule d'expertise et de conseil


Les composants open source sont disponibles par centaines de milliers. Et il n'est
pas possible de les rfrencer tous, videmment. Pourtant, il serait dommage
d'tablir un catalogue de quelques dizaines de produits, et de se priver du reste. On
ne peut pas tirer pleinement parti des ressources de l'open source avec un simple
catalogue, mme mis jour rgulirement. C'est pourquoi, dans une entreprise
d'une certaine dimension, il faut qu'un dveloppeur puisse s'adresser une cellule
qui le conseillera.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 28

Politique Open Source - Pourquoi & Comment

[5.5] Les outils d'audit de proprit intellectuelle


Il existe diffrents prestataires et outils permettant des audits de proprit
intellectuelle, tels que en particulier Black Duck Software, Protecode, ou encore
OpenLogic. Ce sont des outils qui scannent les rfrentiels de code, et analysent le
code, source ou compil, afin de reconnatre des composants prsents, et bien sr de
pointer les licences associes ces composants et d'analyser les compatibilits et
impacts de ces licences.
Ces produits sont souvent utiliss dans des contextes de fusions et acquisitions, afin
de valider la valorisation de proprit intellectuelle revendique par le vendeur.
Pour une entreprise qui, justement, a manqu de politique open source, ce peut tre
un bon moyen de commencer par faire un tat des lieux.
Les vendeurs de ces outils d'audit ont parfois t critiqus pour un discours
commercial qui veut faire peur, et qui donc fait du tort l'open source. On peut
imaginer que, sur le terrain, les commerciaux se laissent aller, mais sur le fond, il
est exact qu'une entreprise doit se proccuper de la proprit intellectuelle de ses
programmes.
Du moins s'il s'agit de valoriser le programme, c'est dire de le distribuer, de le
vendre, ou de vendre l'entreprise qui le possde, alors l'analyse fine de la proprit
intellectuelle est importante, car celle-ci peut restreindre les possibilits
d'exploitation commerciale du programme, au travers des licences.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 29

Politique Open Source - Pourquoi & Comment

[6] LA CONTRIBUTION
La politique open source dfinira aussi, et c'est important, ce que souhaite
l'entreprise ou l'organisation en termes de contributions aux produits open source.
Que doit faire un dveloppeur qui a rencontr une anomalie et qui l'a corrige ?
Est-il encourag communiquer sa correction ?
Cela semble videmment un minimum, mais encore faut-il que le dveloppeur ait
des instructions prcises ce sujet. L'entreprise lui accorde-t-elle mme un petit
quota de jours afin de mieux packager et documenter ses contributions ? En retour,
elle peut s'attendre bnficier des contributions de qualit ralises par d'autres
entreprises.
Et s'il commite un peu de code, doit-il le faire de manire anonyme, sous son nom
propre, ou bien au nom de l'entreprise ?
S'il le fait au nom de l'entreprise, ne
serait-ce qu'en indiquant son adresse mail professionnelle, il peut dans des cas
exceptionnels fournir une information confidentielle la concurrence, savoir que
l'entreprise utilise tel produit.
Mais l'inverse, associer le nom de l'entreprise des contributions de qualit, peut
participer favorablement sa rputation, dmontrer son engagement pour un
dveloppement durable des produits.
Beaucoup de projets open source demanderont un responsable de l'entreprise la
signature d'un accord, un contributor agreement, spcifique qui cde les droits de
l'employeur vis vis de la contribution. En effet les fondations qui pilotent les
grands projets open source ne veulent pas grer une proprit intellectuelle
disperse, qui leur interdirait en particulier de changer des clauses de licence le cas
chant.
Nous avons voqu la contribution de quelques lignes de code, mais l'entreprise peut
galement reverser des dveloppements plus importants, par exemple des extensions
ralises autour d'un produit qu'elle utilise.
Ou, mieux encore, elle peut choisir de mettre disposition un produit complet,
qu'elle aurait dvelopp en interne.
La contribution peut tre motive par un sens du devoir, c'est dire une manire
non montaire de payer ce dont on a bnfici gratuitement. Mais elle peut aussi
rsulter d'un calcul rationnel: si je contribue, je peux m'attendre bnficier des
nouvelles contributions apportes par les autres.
Il est trs important que cette logique soit explique par la politique open source, car
elle ne sera pas spontanment comprise par un chef de service, qui percevra l'intrt

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 30

Politique Open Source - Pourquoi & Comment


court terme (ne rien faire, et attendre que les autres contribuent), mais aura du mal
mesurer l'intrt de moyen terme: je contribue et bnficie des contributions des
autres.
Il faut mesurer toutefois que, pour des dveloppements d'une certaine envergure,
poser les sources sur Sourceforge ou quivalent ne sert pas grand chose, si l'on n'a
pas une dmarche plus large de constitution et d'animation d'une communaut.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 31

Politique Open Source - Pourquoi & Comment

[7] LE SUPPORT
Il existe une diversit d'offres de support des produits et composants open source.
Pour une entreprise, ou un tablissement public, le support est en gnral
indispensable, sauf pour certains composants vritablement non critiques.
Ici aussi, on pourra se rfrer au chapitre Support de notre livre blanc
Comprendre l'open source et le logiciel libre , plus complet sur ce sujet.

[7.1] Produits d'diteurs, produits communautaires


D'une manire synthtique, on peut distinguer les cas de figure suivants:

Le produit provient d'un diteur open source.


Dans ce cas, il propose
certainement une offre de support associe, qui constitue sa principale source
de revenus.
En fait, seul l'diteur peut assurer, de manire crdible, un
support de niveau 3, c'est dire avec correction d'une anomalie dans le code.
Nanmoins, un prestataire qui a assur le dploiement du produit peut
assurer le support aux niveaux 1 et 2, ce qui est en gnral une bonne chose
car il connait les spcificits de l'environnement.

Le produit est d'origine communautaire ou de fondation, par exemple le


serveur Tomcat. Dans ce cas, il n'y a pas d'offre de support officielle . Le
support peut tre assur: par un distributeur tel que Redhat, ou bien par un
prestataire ayant une offre de support transverse et se chargeant de grer la
relation avec la communaut des dveloppeurs.

Pour une entreprise intgrant un grand nombre de composants open source de


diffrentes natures dans leurs dveloppements internes, une offre de support
transverse peut tre une bonne solution. Mais les entreprises qui ont une forte
expertise interne choisissent parfois de s'interfacer elles-mmes avec les
communauts. Il est vrai que les produits phares des fondations sont extrmement
robustes.
Pour ce qui est de la politique open source, il conviendra de dfinir justement quelle
est l'exigence de support requise pour l'entreprise. Ceci en distinguant, bien sr,
diffrents cas de figure en termes de criticit dans le systme d'information, et de
typologie de produit.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 32

Politique Open Source - Pourquoi & Comment

[7.2] Le support sur les diffrentes couches

La figure prcdente, extraite de notre livre blanc, fait apparatre les 4 couches
d'une application typique: (1) le noyau Linux, (2) les serveurs d'application,
interprteurs et bases de donnes, (3) un produits open source de haut niveau, de
type CMS, ERP, e-Commerce, par exemple, et (4) des dveloppements spcifiques
construits en complment du produit. La robustesse est en proportion du nombre de
dploiement: les anomalies dans le noyau Linux sont extrmement rares, et celles
dans les couches telles que Apache ou PHP sont trs rares galement. De sorte que
certaines entreprises considrent que, sur ces couches infrieures, on peut vivre sans
support. Il est impossible de dire si c'est un bon calcul ou non: tout dpend de la
consquence d'une anomalie.

[7.3] Politique open source et support


C'est pourquoi la politique open source doit dfinir les diffrents primtres de
criticit au sein du systme d'information, en distinguant par exemple trois
primtres: vital, critique et utile. Chaque application, et donc chaque plateforme
en production, doit tre clairement identifie comme relevant de l'un de ces
primtres.
Pour chaque primtre, on indiquera l'exigence de support voulue par l'entreprise,
qui pourra tre dcline galement selon les typologies de produits et leur niveau de
qualit connu. Ainsi, comme on l'a voqu, dans un contexte qui ne serait pas
rput vital, on peut envisager de ne pas avoir un support contractualis sur le
noyau Linux ou le serveur Http Apache, mais il serait impensable, mme dans un
primtre critique, de ne pas avoir de support sur un dveloppement applicatif
spcifique.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 33

Politique Open Source - Pourquoi & Comment


Ce que l'on peut figurer comme ceci:
Primtre
Configuration ou dveloppement
spcifique
Progiciel applicatif

Utile

Critique

Vital

Stack (LAMP, JEE)

Noyau

O la marque indique l'obligation d'un support contractualis. Soulignons qu'il


ne s'agit ici que d'un exemple, et non d'une recommandation.
Il faut garder l'esprit toutefois que le support produit, quelle que soit sa qualit, et
sa ractivit, ne permet pas d'assurer la continuit de service d'une plateforme.
Aucun problme srieux ne pourra tre rsolu en moins de 24 heures. Du ct des
plateformes en production, la voie de la haute disponibilit est plutt dans la
politique de validation, de secours, de gestion des configurations et de retour arrire.
C'est principalement dans les processus de dveloppement et d'intgration que le
support sera important.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 34

Politique Open Source - Pourquoi & Comment

[8] LA DIMENSION COOPRATIVE DE L'OPEN SOURCE


Sony, Nokia, Samsung, Volkswagen, de trs grandes entreprises contribuent
activement au dveloppement du noyau Linux. Pourquoi Volkswagen payerait ses
salaris amliorer le noyau Linux ?
Pour ces entreprises, Linux fonctionne sur une logique de cooprative agricole, une
logique de mutualisation des moyens donc de division des cots. Une variante de ce
qu'on appelle parfois cooptition , c'est dire que l'intrt bien rflchi de chacun
conduit identifier un terrain de coopration dans un contexte gnral de
comptition.
Crer seul un systme d'exploitation solide et complet serait hors de porte, mme
pour un grand constructeur automobile. Utiliser un systme propritaire serait trop
coteux et pas toujours adapt ses besoins spcifiques. Reste la mutualisation:
chacun "met au pot" quelques dveloppeurs, et ensemble ils disposent d'un OS de
qualit exceptionnelle, sur lequel ils ont une certaine matrise. Bien sr, cela signifie
qu'aucun d'entre eux ne dispose d'un OS meilleur que celui de son concurrent: cet
aspect l de la concurrence a t pratiquement neutralis. Mais il leur reste encore
bien assez de domaines dans lesquels ils peuvent porter le combat, tre meilleur,
craser les concurrents. Au global, ce domaine de coopration apporte bien sr de
moindres cots chacun, et donc une meilleure comptitivit.
Les quelques lignes qui prcdent sont extraites d'un article intitul l'open source
dans sa logique mutualiste, un vecteur de comptitivit , que nous reproduisons en
Annexe, et auquel nous renvoyons le lecteur qui voudra en savoir davantage.
Pour une entreprise qui aurait analys les bnfices d'une telle dmarche
cooprative, ce sera bien videmment un chapitre essentiel du document dfinissant
sa politique open source.
Sony, Nokia, Samsung, Volkswagen, IBM, Oracle, On pourrait citer en exemple
galement le projet Genivi, qui vise dvelopper une plateforme open source pour ce
qui est appel le In-Vehicle Infotainment , c'est dire tout ce qui est information,
amusement et loisirs l'intrieur des vhicules. Participent ce projet: BMW,
Delphi, General Motors, Continental, Nokia, Renault, Valeo, et bien d'autres.
Pas vraiment de doux rveurs, pris seulement d'amour et d'humanisme. On peut
compter que c'est pas un intrt bien compris que ces entreprises s'engagent dans
une dmarche cooprative de cette nature. Et cela devrait donner des ides bien
d'autres entreprises, car les champs de possibilits sont immenses.
Ce peut tre l'un des objets de la politique open source d'noncer la volont de
l'entreprise de s'engager dans une telle dmarche cooprative. Mais il est vrai qu'ici
on est davantage dans des actions stratgiques que dans de la politique.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 35

Politique Open Source - Pourquoi & Comment

[9] ANNEXES
[9.1] Copyright et licences
[Reproduction d'un chapitre du livre blanc de Smile Comprendre l'open source et le
logiciel libre - Pour plus d'information, ce rfrer au livre blanc complet]

Principes lmentaires
Les programmes open source ne sont pas des programmes sans licences comme on
l'entend parfois. Cest au contraire leur licence qui les fait open source. Ils ne sont
pas non plus dans le domaine public, cest dire nappartenant personne en
particulier, ou du moins exempts de droits patrimoniaux.
Lorsquun dveloppeur crit un programme, il en dtient les droits dauteur, le
copyright. Dans certains cas, ce peut tre lentreprise qui lemploie qui en dtient
les droits.
Et ce copyright peut tre vendu, comme bien immatriel, dune
entreprise une autre.
Le dtenteur du copyright est libre de dfinir lutilisation qui peut tre faite de son
programme :

Il peut le garder pour lui, en interdire lutilisation qui que ce soit.

Il peut vendre ses droits un tiers, personne physique ou morale.

Il peut utiliser son droit dauteur pour prciser les conditions quil pose
lutilisation de son programme. Il crit ces conditions dans les termes de la
licence dutilisation.

A noter quen droit franais, il nest pas ais dabandonner ses droits et de mettre son
programme dans le domaine public de manire irrversible.
Il faut bien expliquer aussi que ce nest pas la diffusion des sources qui fait quun
programme est open source, cest 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 lopen
source il y a la licence, et la licence nexiste qu partir du droit dauteur.
Ainsi tous les logiciels open source ont un propritaire, ils ne sont pas personne ,
ni mme tout le monde .
Dans certains cas, ce propritaire peut tre une
fondation but non lucratif, ou bien ce peut tre une entreprise commerciale

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 36

Politique Open Source - Pourquoi & Comment


ordinaire. Il peut s'agir aussi de plusieurs coauteurs, en particulier la suite de
contributions successives.
Le dtenteur des droits est libre de fixer les conditions de licence, il est libre den
changer mme, et il est libre dy faire des amnagements ou exceptions, ou de
diffuser certains selon une licence, dautres selon une autre licence.
Celui qui reoit le programme, en revanche, nest pas libre. Il est li par les termes
de la licence. Certes il na pas sign de contrat, mais la licence lui a t bien
nonce, et elle stipule quil na le droit dutiliser le programme que sous telles et
telles conditions.
Sil refuse ces conditions, il na pas le droit dutiliser le
programme.
Mentions lmentaires des licences
Toutes les licences open source ont en commun quelques clauses de bon sens :

Lidentification claire du propritaire du copyright, y compris au travers des


copies ou travaux drivs.

Lobligation de conserver la notice de licence en ltat, sur le programme et les


travaux drivs. Cest bien sr une ncessit technique : inutile de dfinir des
termes de licence sils sont vacus ds la premire copie.

La protection de lauteur vis vis des utilisateurs de son programme, ses


ventuels dfauts et les consquences de ces dfauts : ce programme est
fourni en ltat ( as is ) .
Cest bien le moins qui puisse tre exig :
lauteur vous laisse utiliser librement son travail, vous nallez pas quand
mme lui rclamer des dommages et intrts.

A noter que dans certains pays, la distribution payante dun programme entrane
des droits inalinables. Dune manire gnrale, la licence ne peut tre contraire au
droit national.
Cest pourquoi elle dit Si vous ne pouvez pas distribuer le
programme en satisfaisant la fois vos obligations lies licence et dautres
obligations applicables, alors vous ne pouvez pas distribuer le programme du tout .
Cest dire que soit lon peut respecter les lois nationales et la licence la fois, soit
on est dans linterdiction de distribuer le programme sous ladite licence.
Dfinition dun logiciel libre
Comme voqu plus haut, le logiciel libre se dfinit par le respect de quatre liberts
fondamentales :

excuter le programme,

tudier le programme et ladapter selon son besoin (ce qui implique bien sr
laccs au code source),

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 37

Politique Open Source - Pourquoi & Comment

redistribuer le programme pour aider son prochain,

et enfin amliorer le programme et distribuer ces amliorations au public (ce


qui de mme implique le libre laccs aux sources).

Comme on la voqu dj, la finalit premire est la libert, laccs au source nest
quun pr requis pour respecter cette libert.
Dfinition dune licence open source
LOSI, Open Source Initiative, a dict une dfinition prcise de ce que signifie open
source, une dfinition qui est aujourdhui reconnue de manire peu prs
universelle.
Avoir une dfinition officielle prcise est trs important, une licence ne doit pas
pouvoir tre plus ou moins open source : elle lest ou ne lest pas, les choses doivent
tre claires.
Et le site de lOSI, opensource.org, indique aussi quelles sont les principales licences
qui se conforment cette dfinition. On y retrouve bien entendu les licences bien
connues, commencer par la GPL, que nous dtaillons plus loin.
La dfinition comporte dix points, dont les trois premiers sont les principaux :
4. Libre redistribution : la licence ne doit pas interdire qui que ce soit de
vendre ou donner le programme.
5. Code source : la licence doit permettre la distribution sous forme de code
source, et si le code source naccompagne pas le programme il doit tre
disponible de manire facile et pratiquement gratuite.
6. Travaux drivs : la licence doit permettre des modifications et des travaux
drivs, et doit permettre que ces travaux soient distribus sous les mmes
termes de licence.
Revenons sur ce point 3 : la licence doit au minimum permettre de redistribuer les
travaux drivs sous la mme licence. Elle ne doit pas ncessairement lobliger.
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 dfinition figurent diffrentes clauses de nondiscrimination : la licence ne doit pas exclure tel groupe dutilisateurs, ni tel
domaine dapplication, ni tel environnement technique. Par exemple, lauteur du
programme ne peut pas, en pacifiste militant, prciser que son programme ne doit
pas tre utilis pour guider des missiles. Du moins sil ajoute cette clause la licence
ne sera plus open source.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 38

Politique Open Source - Pourquoi & Comment


Licences GNU et BSD
Il y a deux grandes familles de licences open source : la famille BSD et la famille
GNU GPL. On parle parfois de licences copyleft pour les secondes et de licences non
copyleft pour les premires. Copyleft est bien sr un jeu de mot en rfrence au
copyright , jeu de mot traduit parfois par gauche dauteur , vs. droit dauteur .
Mais pour autant le copyleft nest pas un abandon de droit.
Pour quil ny ait pas de confusion, prcisons que si la FSF et le mouvement du
logiciel libre prfre les licences copyleft, commencer par la GPL, il ny 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 nimporte quelle
utilisation du programme, de son code source et de travaux drivs. Le code sous
licence BSD peut en particulier tre utilis intgr 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 spcifique est linterdiction de chercher tirer avantage de la
dnomination de lauteur, ici lUniversit de Berkeley.
Cest donc la licence la plus librale, qui entrane le moins de contraintes : les
programmes sous licence BSD sont quasiment dans le domaine public. Cest aussi
peut-tre la plus ancienne, puisquelle remonte 1980. Il nest pas interdit de
modifier le texte de la licence, de sorte que lon rencontre une multitude de versions
drives, quelques mots prs. Cest 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
dernire est dune grande importance puisque utilise dj par la cinquantaine de
projets de la fondation Apache. Les diffrences entre ces diffrentes licences sont de
lordre du dtail.

Licences Copyleft et GNU GPL


La licence GNU GPL
La licence GNU GPL est utilise par 70% des programmes open source. Mais ce
pourcentage en nombre nest pas le plus important puisque certains logiciels phares
de lopen source sont sous dautres licences.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 39

Politique Open Source - Pourquoi & Comment


La licence GNU GPL, GNU General Public Licence , se caractrise principalement
par son article 2, qui nonce le droit de modifier le programme et de redistribuer ces
modifications, qui constituent des uvres drives, la condition que ce soit sous la
mme licence GPL.
Cest ce que certains appellent le caractre viral de la licence : elle se communique
aux travaux drivs. Mais il est plus correct de parler de rciprocit, ou de donnantdonnant.
Bien sr, toute la question est alors de savoir quest-ce exactement quune uvre
drive et quentend-on par distribuer ? Il existe une vaste littrature sur le sujet, et
pourtant les zones dombre subsistent.
Certains estiment mme quil nest pas
mauvais de laisser quelques doutes.
Voyons dj ce qui est clair.
Que signifie uvre drive ?
coup sr, 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, cest une
uvre drive.
De manire 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 drive. Cette liaison entre les programmes peut tre
statique ou bien dynamique, cest dire rsolue lexcution seulement. Il existe
un dbat quant savoir si une liaison dynamique donne une uvre drive.
Dans les environnements techniques modernes, il existe en fait une diversit de
moyens dinvoquer les services dun programme autrement quen appelant une
fonction. Lappel des services dun programme A au moyen de protocoles dchange
rseau standards nimplique pas que le programme B soit une uvre drive. Si
ctait le cas, alors un navigateur adressant une requte un site dont les
programmes sont sous GPL, se trouverait lui-mme oblig dtre GPL.
En fait, il est souvent admis quun programme B est considr uvre drive du
programme A, si B ne peut pas fonctionner de manire utile sans A, ceci
indpendamment des modalits techniques de la liaison.
Quen est-il dun programme qui utilise par exemple une base de donnes MySql,
sous licence GPL ? Si ce programme nutilise pas, pour appeler la base, de librairies
sous licence GPL, alors il ninvoque les services de MySql que au moyen de
protocoles standards, ce qui nimplique pas quil soit GPL lui-mme. Mais si le
programme ne peut fonctionner autrement quavec une base MySql, alors on pourra
considrer quil est uvre drive malgr tout. A noter que la FAQ de MySql sur le
sujet des licences a t critique pour laisser entendre que toute forme dutilisation
commerciale devait tre sous licence commerciale, ce qui est erron.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 40

Politique Open Source - Pourquoi & Comment


Que signifie Distribuer ?
Ici encore, certaines choses sont claires. coup sr, si vous commercialisez votre
programme en tant que progiciel, cela sappelle distribuer.
A linverse, utiliser et dployer un programme au sein dune mme organisation,
nest pas distribuer. Ce qui signifie quune entreprise peut construire une uvre
drive, et lutiliser en interne sur autant de postes ou serveurs quelle juge utile,
sans tre tenue de diffuser les sources de luvre. Cest un point essentiel dans la
sphre conomique.
Une autre question importante est celle de la relation client-fournisseur dans les
mtiers de linformatique. Lorsquun prestataire tel que Smile construit une
application utilisant des composants sous licence GPL, et livre cette application
son client, le prestataire doit livrer lensemble des sources, y compris ajouts. Cette
obligation de distribution des sources ne concerne QUE les personnes qui reoivent
le programme, ici donc le client. Il nest pas requis de les mettre sur la place
publique.
Par ailleurs, le client peut soit garder pour lui le programme (cest--dire au sein de
son organisation), soit le distribuer, mais alors obligatoirement sous licence GPL.
Notons aussi que utiliser ou proposer luvre drive sous forme de service en ligne
(software as a service), mme commercial, nest pas distribuer. Cest ce que fait
Google par exemple. Sur ce point, voir plus loin la licence AGPL.
Lesprit de la GPL
Au del des mots, lesprit de la licence GPL est que, en tant quauteur ou propritaire
dun programme, je vous donne le droit de lutiliser et dutiliser ses sources
condition que vous en fassiez autant. En somme, cest 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 lautre camp, cest dire
que vous ne voulez pas distribuer votre code en donnant aux autres la mme libert
qui vous tait donne, alors vous ne pouvez pas en profiter.
Cest ce quon pourrait appeler du donnant-donnant, que les critiques de cette
licences appellent son aspect viral.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 41

Politique Open Source - Pourquoi & Comment


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 L B, alors est-il possible de
construire un programme C utilisant la fois A et B ? Le programme C hritera
des exigences de LA et de celles de LB, et sil y a des contradictions entre ces
exigences, sil 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 lopen 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 rduite.
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 suivante2 est issue du site gnu.org. Les flches indiquent la compatibilit
des licences.

Notons quune licence LA qui


serait de type copyleft, et
pratiquement identique la GPL,
mais porterait un autre nom, ne
serait pas
compatible GPL,
puisque
luvre
drive
ne
pourrait pas tre la fois GPL et
LA. Cest le cas par exemple de la
licence rciproque introduite
rcemment par Microsoft, la
MsRL.
LGPL
La licence LGPL est trs proche de la GPL, mais autorise appeler des fonctions du
programme partir dun autre programme, sans exigence vis vis de ces
programmes, qui peuvent ne pas tre sous licence open source eux-mmes. Cette
licence est donc particulirement approprie pour des librairies de fonctions
destines tre appeles par diffrents programmes, sans poser de conditions trop
fortes sur ces programmes.
LGPL signifiait initialement Library GPL, mais lappellation a t change en
Lesser GPL (Moindre GPL), car Richard Stallman souhaitait minimiser la
correspondance librairie = LGPL et permettre denvisager aussi bien des
2

Image 2007 Free Software Foundation Inc.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 42

Politique Open Source - Pourquoi & Comment


librairies sous GPL.
La LGPL est un compromis entre la volont forte de
promouvoir lopen source, et viter sa rcupration au service de logiciels
propritaires, et dautre part la volont de rendre le plus grand service par la plus
large utilisation.
A noter quau del de la permission de linker, la LGPL introduit quelques conditions
un peu subtiles sur le programme link.
Certains programmeurs ont prfr
diffuser sous GPL avec en addendum une special linking exception, autorisant lappel
de fonction.
La GPL with special linking exception est plus lisible et plus permissive, ce qui la
fait choisir par SUN pour le JDK.
GPL-v3
La version 3 de la licence GPL a t acheve courant 2007, et s'est
progressivement.

dploye

Elle vise amliorer la v2, et ladapter un contexte qui a volu, sur les points
suivants :

Une plus stricte


interprtation ;

dfinition

juridique

des

termes,

prtant

moins

Linterdiction dempcher, au moyen de dispositifs physique ou en ne


fournissant pas linformation requise, la mise en uvre du logiciel modifi sur
son hardware cible.
Cest ce qui avait t appel tivoisation, du nom de
lentreprise Tivo, fabriquant de magntoscope, qui y avait recours.

Le cas de linterdiction faite, dans de nombreux pays, de contourner les DRM.


Une uvre drive dun logiciel GPL-v3 ne peut invoquer cette interdiction.
Cest dire quil nest pas interdit dcrire un programme de DRM en utilisant
des composants GPL-v3, mais il est interdit dinterdire de le contourner.

Une protection contre les revendications de brevets logiciels : celui qui diffuse
son code sous licence GPL-v3 donne tous les droits dutilisation permis par la
licence et sinterdit de poursuivre les utilisateurs au nom des brevets logiciels.

La possibilit dajouter certaines restrictions particulires la licence, parmi


un nombre limit de possibilits, ce qui donne un peu plus de flexibilit dans
les problmes de compatibilit de licences.

AGPL (Affero)
Comme on la vu plus haut, il nest pas interdit de prendre un programme sous
licence GPL, construire sur cette base un programme qui soit uvre drive, et
utiliser ce programme pour son propre besoin, y compris en le dployant au sein de
son organisation, sans pour autant en diffuser les sources. De la mme manire, il
nest pas interdit doffrir un service accessible sur lInternet, qui soit construit avec

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 43

Politique Open Source - Pourquoi & Comment


cette uvre drive, sans pour autant en diffuser les sources, car cet usage nest pas
une distribution.
Avec la monte en puissance des offres de services hbergs, de type Software as a
Service (SaaS), ce type dusage s'est tendu fortement. Or bien y rflchir, rendre
le programme accessible directement ses utilisateurs finaux au travers de
lInternet, est bel et bien une manire dinterdire laccs aux sources, tout en faisant
une exploitation le plus souvent commerciale, qui sapparente une distribution.
Cest pour rpondre ce risque de contournement que la socit 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 accs
par le rseau et diffusait ses sources par le rseau, alors le programme driv doit en
faire de mme.
L'article est le suivant:
Si le programme tel que vous l'avez reu est prvu pour interagir avec les
utilisateurs au travers d'un rseau, et si, dans la version que vous avez reue, un
utilisateur interagissant avec le programme avait la possibilit de demander la
transmission du code source intgral du programme, vous ne devez pas retirer cette
possibilit pour la version modifie u programme ou une uvre drive du
programme (...)
Cest une mesure fondamentale, et il nous semble quelle tendra se gnraliser
lavenir.

Les weak copyleft


La distinction entre copyleft et non-copyleft n'est en fait pas binaire. Entre la BSD,
qui n'a presque aucune exigence quant aux uvres drives, et la GPL qui exige la
mme licence, il peut y avoir des exigences intermdiaires. Ce sont les licences de
type weak copyleft , copyleft faible, en particulier la MPL, Mozilla Public Licence
et la CDDL de SUN. A la manire de la GPL, la licence MPL oblige le code source
copi ou modifi, s'il est redistribu, l'tre sous les termes de la mme licence MPL.
Mais cette exigence ne va pas au del de la frontire du fichier de code source, de
sorte que l'on peut associer des fichiers source sous MPL d'autres fichiers pour
former un programme sans conditions particulires sur cette uvre drive. MPL
et CDDL ne sont pas compatibles avec la GPL
De mme la licence Eclipse, EPL, autorise des uvres drives commerciales, sous
licences non open source donc, mais a quelques exigences, entre autres d'identifier
les portions d'origine sous EPL et d'indiquer la manire d'obtenir leur source.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 44

Politique Open Source - Pourquoi & Comment

[9.2] L'open source dans sa logique mutualiste, un


vecteur de comptitivit
[Reproduction d'une tribune libre, signe par Patrice Bertrand, publie dans
Progilibre.com en 2009]
Lorsqu'on parle des business models de l'open source, on pense le plus souvent ses
acteurs conomiques, diteurs de logiciel, intgrateurs, distributeurs, prestataires de
support, tous entreprises but lucratif si l'on peut dire.
On imagine que pour le reste, l'open source est affaire de bnvoles, travaillant soirs
et week-ends sur des projets communautaires, pour la gloire ou pour le bien de
l'humanit.
Et on oublie bien souvent le troisime modle de l'open source, celui qu'on pourrait
appeler "coopratif", ou encore "mutualiste". Il a pourtant une importance
extraordinaire, puisqu'on y trouve Linux soi-mme, les projets de la fondation
Apache
ou
de
la
fondation
Eclipse.
Du
beau
monde...
De quoi vivent ces projets ? Principalement de dons en nature, soit de code source
directement, soit de temps de dveloppeurs, pays par leur employeur, et travaillant
sur les projets de la fondation. Pourquoi les entreprises font-elles ces contributions ?
Pour l'essentiel, ce n'est pas affaire de marketing, il ne s'agit pas d'avoir son nom sur
le spi d'un voilier gant. Elles sont au contraire relativement discrtes sur leur
implication. Ce n'est certainement pas non plus par philanthropie ou dans une
logique de mcnat. Leurs motivations sont de diffrentes natures. Participer la
gouvernance des projets, c'est dire avoir son mot dire dans les orientations qui
sont prises, pour les diriger dans le sens de ses besoins. Construire une expertise
interne sur ces projets, qui permettra de bien les intgrer ses propres
dveloppements. Acqurir une lgitimit sur le march. Mais surtout, au final:
disposer pour soi mme d'un outil de qualit en partageant les cots.
Il est trs instructif de regarder la liste des plus grands contributeurs du noyau
Linux.
Sony, Nokia, Samsung, Volkswagen, sont au nombre des contributeurs actifs.
Pourquoi Volkswagen payerait ses salaris amliorer le noyau Linux ?
Pour ces entreprises, Linux fonctionne sur une logique de cooprative agricole, une
logique de mutualisation des moyens donc de division des cots. Une variante de ce
qu'on appelle parfois cooptition , c'est dire que l'intrt bien rflchi de chacun
conduit identifier un terrain de coopration dans un contexte gnral de
comptition.
Crer seul un systme d'exploitation solide et complet serait hors de porte, mme
pour un grand constructeur automobile. Utiliser un systme propritaire serait trop
coteux et pas toujours adapt ses besoins spcifiques. Reste la mutualisation:
Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 45

Politique Open Source - Pourquoi & Comment


chacun "met au pot" quelques dveloppeurs, et ensemble ils disposent d'un OS de
qualit exceptionnelle, sur lequel ils ont une certaine matrise. Bien sr, cela signifie
qu'aucun d'entre eux ne dispose d'un OS meilleur que celui de son concurrent: cet
aspect l de la concurrence a t pratiquement neutralis. Mais il leur reste encore
bien assez de domaines dans lesquels ils peuvent porter le combat, tre meilleur,
craser les concurrents. Au global, ce domaine de coopration apporte bien sr de
moindres cots chacun, et donc une meilleure comptitivit.
On retrouve cette logique cooprative sur la plupart des projets de fondations. Le
moteur de recherche Lucene en est un bel exemple. Depuis 2002, Yahoo a t un
important sponsor des travaux de son crateur, Doug Cutting, qui a ensuite t
salari de Yahoo, de 2006 2008, tout en continuant ses travaux sur ce projet de la
fondation Apache. En 2006, le groupe de mdia CNET donne la fondation Apache
le source de SolR, un outil de recherche initialement usage interne, qui rejoint le
projet Lucene. Et Yahoo continuera de financer les projets qui gravitent autour de
Lucene, en particulier Hadoop, devenu l'outil de rfrence pour la rpartition de
tches trs grande chelle. On est bien ici dans une logique cooprative: CNET
bnficie de produits trs suprieur ce qu'il aurait pu financer seul, et de mme,
pour chaque jour financ par Yahoo, le bnfice est dcupl puisqu'une vingtaine de
commiters entourent Doug Cutting, pays par diffrents employeurs.
C'est un exemple particulirement intressant, qui pourrait tre pris en modle dans
bien d'autres domaines. Dans un nombre extraordinaire de secteurs, des fdrations
interprofessionnelles pourraient dfinir des terrains de coopration logicielle,
stimuler des projets mutualistes...
D'une certaine manire, le modle conomique de l'diteur logiciel traditionnel peut
aussi s'assimiler un financement coopratif: diffrents clients de l'diteur payent
un droit d'usage, et/ou un support, et la somme de ces contributions individuelles
finance le dveloppement du produit. La diffrence entre ce modle diteur standard
et le vritable modle coopratif est dans la prise de risque et dans le partage des
bnfices. L'diteur prend des risques en investissant pour construire son produit,
bien avant d'avoir des clients. En contrepartie de cette prise de risques, il escompte
un profit important si son produit est un succs. Et en particulier, il espre vendre
de nombreuses licences aussi cher que le permettra le march, sans laisser crotre
ses cots de dveloppement en proportion. Dans un dveloppement coopratif, les
clients partagent le risque, et sont assurs en retour de cots au plus bas et surtout,
de tirer eux-mmes les bnfices d'chelle.
Pour autant, l'approche cooprative du dveloppement n'est pas indissociable de
l'open source. Dix entreprises peuvent s'associer et co-financer le dveloppement
d'une application, qui servira chacune d'elles. Elles peuvent crer une petite
structure pour en grer les dveloppements et les volutions. Le domaine des ERP
"verticaliss", des applications qui s'appuient sur un socle ERP pour en adapter les
fonctionnalits aux besoins d'un secteur d'activit particulier, serait typiquement le
domaine de prdilection de cette approche cooprative de l'open source.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 46

Politique Open Source - Pourquoi & Comment


En principe, il n'est pas requis que l'application rsultant de cet effort coopratif soit
open source. Et mme, certains pourraient craindre qu'elle le soit, car elle pourrait
alors tre utile d'autres qui n'auraient pas contribu son financement.
L'open source n'accepte pas de frontire, pas de restriction dans la diffusion: si elle
est open source, l'application ne pourra pas tre rserve ses seuls sponsors
initiaux. Il faut avoir les nerfs solides, pour voir un concurrent non coopratif
reprendre l'application sur laquelle on a investi.
Mais dans la pratique, on sait bien qu'il n'est pas si facile de "prendre" une
application. Ayant dmontis le copyright, l'open source a mis la connaissance,
l'expertise, la matrise, au premier plan. L'entreprise qui n'aura pas particip aux
travaux aura, dans la pratique, beaucoup de mal profiter de l'application sans
avoir construit une certaine matrise, et sans avoir son mot dire quant aux
orientations. En ne contribuant pas, elle se rendrait dpendante vis vis de ses
propres concurrents, qui seuls assureraient la gouvernance, dfinirait la roadmap du
produit.
C'est pourquoi, pour un groupement d'entreprises dans une logique cooprative, la
crainte de voire certains profiter sans avoir contribu, peut passer au second plan.
Ce qui prime, c'est la croyance que d'autres au contraire viendront rejoindre les
rangs des sponsors, apporter leurs propres ides, des moyens renforcs, des cots
encore diviss, pour viser une application encore meilleure. Bien sr, il faut une
certaine foi, mais quelques belles russites ont ouvert la voie.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 47

Politique Open Source - Pourquoi & Comment

[9.3] Mmorandum du CIO Department of Defense


[Note interne adresse par le DSI du Dpartement de la Dfense amricain ses
services, en octobre 2009. Il ne constitue pas une politique open source lui seul,
mais peut en tre le point de dpart. La traduction, non-officielle, est de Smile]
Department of Defense
6000 Defense Pentagon
Washington, DC 20301-6000

Le 16 octobre 2009

Recommandations concernant le logiciel open source

Rfrences: voir annexe I


Pour accomplir sa mission avec efficacit, le Dpartement de la Dfense doit
dvelopper et faire voluer ses capacits en matire de logiciel plus rapidement que
jamais, pour se prparer de nouvelles menaces et faire face des exigences en
permanente volution. L'utilisation de logiciel open source (OSS) peut avoir des
avantages dans cette perspective. Ce mmo apporte des clarifications quant
l'usage de l'open source et remplace le prcdent mmo du DoD en date du 28 mai
2003.
Le logiciel open source est du logiciel dont le code source, lisible par un humain, est
disponible pour tre utilis, tudi, rutilis, modifi, amlior, et redistribu par
ses utilisateurs. En d'autres mots, l'OSS est du logiciel dont le code est ouvert .
Il y a beaucoup de programmes OSS utiliss de manire oprationnelle par le
Dpartement aujourd'hui, tant dans des environnements classs, que non-classs.
Malheureusement il y a eu des incomprhensions et de mauvaises interprtations
des lois, politiques et rglements en vigueur en matire de logiciel, appliques
l'OSS, qui ont frein l'utilisation et le dveloppement effectifs de l'OSS par le DoD.
L'annexe 2 apporte des clarifications afin de rpondre ces difficults.
J'ai demand au Directeur Enterprise Services & Integration, de travailler avec vos
quipes afin d'identifier de nouvelles barrires l'utilisation effective 3 de logiciel
3

L'anglais effective peut avoir deux sens, soit efficace , soit effectif dans le sens de dans la
ralit , ou encore sur le terrain . Nous opt pour ce second sens, qui semble logique aprs le mot

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 48

Politique Open Source - Pourquoi & Comment


open source au sein du Dpartement, de sorte que nous puissions continuer
augmenter les bnfices que nous tirons de l'usage d'OSS. Plus d'information sur
la manire dont les politiques du DoD en vigueur s'appliquent au logiciel open
source seront publies sur
http://www.defenselink.mil/cio-nii/cio/oss/,
Les
questions relatives ce mmo doivent tre adresses Daniel Risacher, Enterprise
Services & Integration, au [tlphone] ou par email [adresse email].

[Signature]
David M. Wennergren
ASD (NII)/DoD CIO

Annexe II

Recommandations concernant le logiciel open source

1. Gnralits
Cette annexe fournit des claircissements et des recommandations complmentaires
concernant l'utilisation et le dveloppement de logiciel open source. Il ne modifie pas ou
ne cre pas une nouvelle politique, mais vise expliquer les implications et la
signification des lois, politiques et rglements existants.

2. Recommandations
a) Dans pratiquement tous les cas, l'OSS entre dans la dfinition de logiciel
commercial et se verra accorder une prfrence statutaire conformment [un
ensemble de rfrences de textes cits].
b) Les tablissements relevant de l'excutif, incluant le Dpartement de la Dfense, ont
l'obligation de mener une tude de march lorsqu'ils prparent l'acquisition de biens ou
de services, selon [rfrence aux textes de rglements]. Les tudes de march
concernant le logiciel doivent inclure le logiciel open source lorsqu'il peut satisfaire aux
besoins de la mission.
(1) Il y a des aspects positifs l'OSS qui doivent tre pris en compte lorsque l'on
mne une tude de march portant sur le logiciel l'usage du DoD, par exemple:
barrire, mme si l'efficacit est cite par ailleurs.

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 49

Politique Open Source - Pourquoi & Comment

(a) Le processus le revue par les pairs, large et permanent, qui est rendu possible
par la disponibilit publique du code source, renforce la fiabilit et les efforts
en matire de scurit, au travers de l'identification et de l'limination des
dfauts qui pourraient ne pas tre dtects dans le cas d'une quipe de
dveloppement rduite.
(b) La possibilit de modifier le code source du logiciel sans restriction permet au
Dpartement de rpondre plus rapidement des situations et des missions
changeantes et aux menaces futures.
(c) La dpendance vis vis d'un dveloppeur ou d'un vendeur particulier, lie aux
restrictions propritaires, peut tre rduite par l'utilisation de l'OSS, qui peut
tre opr et maintenu par de multiples vendeurs, ce qui rduit les barrires
l'entre et la sortie.
(d) Les licences open source ne prsentent pas de restriction quant aux
utilisateurs du logiciel ou les champs d'application possibles. En consquence,
l'OSS apporte un modle de licences net-centric , qui permet un processus
d'acquisition couvrant la fois les utilisateurs identifis et ceux nonidentifis.
(e) Du fait que l'OSS n'a pas, le plus souvent, un modle de licence par
utilisateur, il peut apporter un avantage en matire de cot dans les cas o de
nombreuses copies du logiciel peuvent tre ncessaires, et peut amoindrir le
risque d'augmentation des cots li aux licences, dans des situations o le
nombre total d'utilisateurs peut ne pas tre connu l'avance.
(f) En partageant la responsabilit de la maintenance de l'OSS avec d'autres
utilisateurs, le Dpartement peut tirer un bnfice, en rduisant le cot total
de possession du logiciel, tout particulirement en comparaison de logiciels
dont le Dpartement porte seul la responsabilit de la maintenance.
(g) L'OSS
convient
particulirement
au
prototypage
rapide
et

l'exprimentation, o la possibilit de faire des essais du logiciel des cots


minimaux et des dlais administratifs rduits, peut tre importante.
(2) Ces considrations sont pertinentes, mais elles ne peuvent pas tre les facteurs
prminents d'une dcision concernant le logiciel. Au fin de compte, c'est le
logiciel qui satisfait le mieux les besoins et les missions du Dpartement qui doit
tre utilis, qu'il soit ou non open source.
c) L'instruction 8500.2 du DoD intitule Information Assurance (IA) Implementation
comporte un contrle () qui limite l'utilisation des excutables du domaine public ou
autres logiciels avec une garantie limite ou inexistante du fait que ces composants sont
difficiles ou impossibles vrifier, rparer ou enrichir, tant donn que le Gouvernement
n'a pas accs au code source d'origine et qu'il n'y a pas de propritaire qui puisse
effectuer de telles modifications au nom du gouvernement. Ce contrle ne doit pas tre
interprt comme interdisant l'utilisation de l'OSS, puisque son code source est
disponible des fins de vrification, rparation ou enrichissement, par le gouvernement

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 50

Politique Open Source - Pourquoi & Comment

ou ses prestataires.
d) L'utilisation de n'importe quel logiciel sans maintenance et support prsente un
risque en termes de scurit de l'information. Avant d'approuver l'utilisation du logiciel
(y compris OSS), les chefs de programmes et chefs de systmes, et au final les Autorits
d'Approbation Dsignes, doivent s'assurer que le plan concernant le support du logiciel
() est appropri pour les besoins de la mission.
e) Il y a une mauvaise interprtation qui voudrait que le Gouvernement soit oblig de
distribuer au public le code source de n'importe quel OSS, et que, en consquence, l'OSS
ne devrait pas tre intgr ou modifi pour un usage dans des systmes classifis ou bien
sensibles du DoD. Au contraire, de nombreuses licences open source autorisent
l'utilisateur modifier l'OSS pour un usage interne sans tre oblig de distribuer le code
source au public. Toutefois, si l'utilisateur choisit de distribuer l'OSS modifi en dehors
de son organisation (par exemple un utilisateur du Gouvernement distribue le code en
dehors du Gouvernement), alors certaines licences OSS (telles que GNU General Public
Licence) imposent effectivement la distribution du code source correspondant, au
destinataire du programme. Pour cette raison, il est important de comprendre la fois
les particularits des licences open source en question, et comment le Dpartement
envisage d'utiliser et de redistribuer tout OSS qui serait modifi par le DoD.
f) Le code source du logiciel et les documents de conception associs sont des donnes ,
selon la dfinition du [Rfrence] et en consquence seront partags au sein du DoD le
plus largement possible pour supporter les besoins de la mission. Les licences open
source autorisent une dissmination large du logiciel concern, ce qui permet l'OSS
d'tre partag travers tout le Dpartement. Une des manires de rendre le code
source disponible dans le Dpartement est d'utiliser l'environnement de dveloppement
logiciel collaboratif l'adresse [lien http], mise en place par le Defense Information
Systems Agency.
g) Les composants logiciels, y compris les correctifs et amliorations, dvelopps pour le
Gouvernement doivent tre rendus disponibles au public (par exemple sous une licence
open source) lorsque toutes les conditions suivantes sont remplies:
(1) Le chef de projet ou chef de programme, ou un officiel semblable, estime qu'il est
de l'intrt du Gouvernement de le faire, par exemple parce qu'il s'attend
bnficier des amliorations apportes par d'autres.
(2) Le Gouvernement a les droits relatifs la reproduction et la diffusion des
composants, et peut permettre d'autres d'en faire autant. Par exemple, le
Gouvernement a les droits relatifs la diffusion publique lorsque le logiciel est
dvelopp par du personnel du Gouvernement, lorsque le Gouvernement reoit
des droits illimits sur un logiciel dvelopp par un prestataire financ par le
Gouvernement, ou quand un logiciel OSS pr-existant est modifi par ou pour le
Gouvernement.
(3) La diffusion publique n'est pas restreinte par d'autres lois ou rglements, tels que
le Export Administration Regulations ou le International trafic in Arms
Regulation, et le composant est ligible pour le Distribution Statement A selon

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

Page 51

Politique Open Source - Pourquoi & Comment

[rfrence interne].

Smile Open Source Solutions - Reproduction autorise selon les termes Creative Commons by-nd

You might also like