Introduction aux logiciels libres

Logiciels libres
Olivier Berger,
TELECOM & Management SudParis -
Département INF
<olivier.berger@it-sudparis.eu>

TELECOM SudParis
CSC4522 / DSI - 2009/06/17

<hype mode="pipo">

Le libre
c'est bon.
Mangez-
en !
O. Berger 2/9

Dans le
libre, on
se fait
vite plein
d'amis !
O. Berger 3/9

Mettez votre
logiciel sous
GPL
succès assuré !
O. Berger 4/9

Les failles de
sécu sont
corrigées
super vite !
patch#45678
O. Berger 5/9

Les
contributeurs
travaillent
gratuitement
vite et
bien
O. Berger 6/9

La solution à
tous les
problèmes de
développement
...
O. Berger 7/9

Le
logiciel libre

</hype> O. Berger 8/9

Foutaise ?
O. Berger 9/9

Plus sérieusement...

Page 10 / 93 Dpt. INF O. Berger

Présentation personnelle
 Ingénieur de Recherche au département INF à
TELECOM & Management SudParis (B 303)
 Projets de R&D sur le logiciel libre (CALIBRE,
PFTCR, COCLICO, ...)
 Adepte et « évangéliste du libre » de longue
date, mais en « congé sabbatique »
 Contributeur à la distribution Debian
 Recherche : plate-formes de développement
collaboratif de logiciels (forges) :
• Projet Helios (GTLL de System@tic)
 Google est mon ami, mais au cas où :
http://www-public.it-sudparis.eu/~berger_o/
http://www-public.it-sudparis.eu/~berger_o/weblog/


Sondage rapide

 Déjà eu des cours sur le sujet ?
 Logiciel libre ?
 Linux ?
 GNU ?
 FSF ?
 APRIL, AFUL, etc. ?
 Firefox ?
 Ubuntu ?
 Creative Commons ?
 SourceForge ?
 Bugzilla ?


Objectif de cette conférence

 Donner une idée des enjeux liés à la
collaboration dans les projets libres
 Rappel des fondamentaux du modèle libre
 Démythifier un modèle loin d'être magique
 Quelques pistes permettant d'intégrer le libre
dans les projets industriels


Contenu

Introduction générale


Introduction générale sur le libre

 Principes
 Historique
 Aspects juridiques
 Aspects économiques
 Projets / Communautés
 Evaluation outils libres
 Guidelines

Dpt. INF

Définition du logiciel libre
« La liberté d'exécuter le programme, pour tous
les usages (liberté 0).
 La liberté d'étudier le fonctionnement du
programme, et de l'adapter à vos besoins (liberté
1). Pour ceci l'accès au code source est une
condition requise.
 La liberté de redistribuer des copies, donc d'aider
votre voisin, (liberté 2).
 La liberté d'améliorer le programme et de publier
vos améliorations, pour en faire profiter toute la
communauté (liberté 3). Pour ceci l'accès au code
source est une condition requise. »
Définition de la Free Software Foundation (FSF)


Terminologie

 Logiciel Libre ~= OpenSource
 Liberté !
 Coût ?
 Autres :
freeware, domaine public, shareware, shared
source, etc.
 Libre = ouvert ?
 Ne pas se fier aux déclarations : vérifier les
licences


Libre vs. non-libre

 En théorie, identification facile :
droit d'utilisation : OK - NOK
droit d'étudier : OK - NOK
droit de modifier : OK - NOK
droit de diffuser copies (modifiées) : OK - NOK
 En pratique, parfois complexe (jargon licences)
 Demander aux experts
• Free Software Foundation (http://www.fsf.org/),
• OpenSource initiative
(http://www.opensource.org/).


Logiciel libre


Logiciel non-libre (Propriétaire)


Exemples de logiciels libres

 GNU/Linux, FreeBSD, OpenBSD
 Apache
 Perl,PHP, Python
 Java (récent)
 Eclipse
 GNOME, KDE, etc.
 Jonas, MySQL, PostgreSQL
 Asterisk
 Videolan
 Firefox, OpenOffice, Thunderbird
 etc.


Le libre est partout

 Internet: Apache, Bind, etc.
 Serveurs (Samba, MySQL, etc.)
 Groupware, CMS, ERP, ETL, etc.
 Appliances, embarqué, grand public
• Nokia 8x0
• Freebox, Easybox, routeurs, etc.
• Téléphones (Google Android, etc.)
• GPS, ...
 Impots
 Poste de travail des gendarmes
 ...


ValeurS : mouvement logiciel libre

 Philosophie : Liberté, Egalité, Fraternité
• Liberté : faire des copies, améliorer, distribuer
• Égalité : mêmes droits pour tout le monde
• Fraternité : Co-opération pour construire des
biens communs
 Mouvement « politique »
• Éthique, philosophie, activisme politique
• Richard M. Stallman et la FSF (Free Software
Foundation : http://www.fsf.org)
• APRIL, en france http://www.april.org/


« Mouvement » Open Source ?

 Approche orientée vers le marché (créé en
réaction au mouvement du libre)
 Bénéfices pratiques
 Coûts (ambiguïté free)
 « Mouvement »
• Open Source Initiative
(http://www.opensource.org)
• La plupart des industriels de l'informatique, les
SS2I, etc.


Impact global dans la société

 Impact sur tous les aspects de la production et
de la diffusion du savoir, et plus largement tous
les artefacts immatériels :
• Publications et données scientifiques (open
archives, etc.)
• OpenStreetmap, Wikipedia
• Création artistique : creative commons (CC)
• Entertainment - gratuité ?
• Débat public, démocracie, régulation de
l'utilisation des ressources, etc.
 Nouveau paradigme : Commons (Lessig)
 Des biens publics aux biens communs ?

Dpt. INF

Résistances

 Copyright / droit d'auteur
 Brevets
 DRM
 FUD
 Hadopi
 ...

Dpt. INF

 Principes
 Historique
 Guidelines


Chronologie

 Au début était le code source (< 80) Unix, BSD (> 80)
 GNU project & Free Software Foundation créés par
Richard M. Stallman (> 83/84)
 Noyau Linux créé par Linus Torvalds (> 91)
 Distributions GNU/Linux ( > 95)
 Création de l'APRIL (96)
 IBM entre en jeu (2001)
 Sun rachète StarOffice et création de OpenOffice.org
(2002)
 Ubuntu, Firefix 1.0 (2004)
 OpenOffice.org 2.0 (2005)
 Google sponsorise
 Java sous GPL (2007)
 Android...

Aujourd'hui incontournable

 20/25ans plus tard
 La partie est en voie d'être gagnée

 Mais au fait, comment ça marche !?!


Qu'est-ce que le logiciel libre ?

Juridique/ Licences
Organisationnel / Communautés
Economique / Modèles d'affaires

Pas un seul modèle !


 Principes
 Historique
 Guidelines


Protection vs. Contrôle

 Comment bien exercer un contrôle ?
 Le Copyright contrôle si
• Utiliser
• On peut copier pour donner ou vendre
• (essayer de) Modifier
• Toute autre chose non prévue dans un contrat
de licence
 Le libre rééquilibre la donne en faveur des tiers,
utilisateurs, concurrents


Droit d'auteur, licences

 Droit d'auteur :
• Prérogatives de l'auteur, faibles
• Conditions d'exploitation (employeur ?), fortes
 Attaché à :
• au fichier source, d'abord
• œuvres dérivées (y compris exécutable)
 Régime par défaut : restrictions des droits
 Licence libres établissent des exceptions
 Œuvres composites : compliqué
 Mixibilité des licences ?


Brevets sur les logiciels

 Le droit d'auteur/copyright ne controle pas si
un programme similaire peut être écrit par un
tiers
 Le brevet protège une idée
 Au départ destiné à protéger l'intérêt général
 Dérive
 Controverse législative en Europe


Licences libres


Catégories de licences libres

 Deux grandes catégories :
• Façon « domaine public » (BSD, X11)
• Façon « Copyleftées »
 Copyleftées (GPL, LGPL):
• Liberté de changer le logiciel
• Impossibilité de changer la licence sur oeuvres
dérivées
 Un même logiciel + plusieurs licenses =
segmentation des « marchés » (dual license)
 Modèles économiques des éditeurs de logiciels
libres


Points clés

 Question d'oeuvres dérivées
 Edition de liens, etc.
 Pas questions modèle éco, mais seulement
copyright
 Compatibilité des licences
 Éviter la prolifération des licences
 Qui est titulaire des droits ?
 SAAS, Cloud computing ? (Affero GPL)


 Principes
 Historique
 Guidelines


Économie du logiciel

 Non rivalité
 Valeur augmente quand on s'en sert (effets de
réseau)
 Monopôles
 Création d'un « bien commun »
 Faciliter la réutilisation
 Mutualisation de l'investissement
 Logiciel libre == gratuit (une fois qu'il a été
payé)


Software Wars


« Bataille » immense

 Réduire les coûts (commoditisation)
 Effets de réseaux pour établir des standards
 Mutualiser la R&D
 « Co-opétition » :
• coopération
• compétition
 Prendre position dans le libre pour maîtriser
son évolution
 Modèles économiques ?


« Commoditisation » du logiciel


Valeur du libre ?
 Exemple: Debian 2.2 GNU/Linux (2001)
 Lignes de code source :
• 55 201 526
• dont noyau Linux < 6%
• x 2 tous les 2 ans
 Si applique métriques traditionnelles du
développement en entreprise :
• Effort estimé : 14 005 hommes x années
• Délai estimé : 6,04 ans (équipe de 2 318 p.)
• Coût développement : US$ 1 891 990 000
(Source: "Counting potatoes" par Gonzalez-Barahona et al)
 Cf.http://ohloh.net pour d'autres chiffres
(Méthodologie discutable)

ROI utilisateurs

 Profusion d'études
 Libre != gratuit ... heureusement ;-)
 Économie gestion des licenses
 Transfert de coût entre licences et formation
 Paradoxes

 Aufinal coût des licences souvent marginal
dans les coûts d'un projet


Modèles d'affaires pour fournisseurs

 Service
« Valeur ajoutée » couches hautes
 Editeur
 Double licence

 Marché en croissance

 Positions stratégies industrielles

 Linagora (fondée par ancien INT Management)


Qui participe

 Bénévoles
• Parfois très isolés
• Parfois de façon organisée (Apache, GNU
project, etc.)
 Compagnies
 Pas un seul profil d'activités :
• Utilisation, tests, rapports de bugs
• Support communautaire (forums, listes, etc.)
• Code
• Vendre du libre
• etc.


Rapide panorama d'un écosystème

Debian
Debian
s
rs ion
ve gs packages
bu

Développeurs versions Utilisateurs
amont RedHat
RedHat
bugs
(“upstream”)
bugs
ve
rsi
bu ons
gs
OpenSuse

Éditeurs SSII
distributions

Le libre est global


Où sont ces développeurs ?

Par pays (SourceForge) :

Rang Pays Developpeurs
1. United States 425620
2. Germany 95800
3. United Kingdom 60768
4. Canada 49109
5. France 44587
6. China 36517
... ... ...
(source : Gregorio Robles and Jesús M. González Barahona -
2006)


Où sont ces développeurs ? (2)

Par continent :

Continent Développeurs
Africa 12 560
Asia 127 275
EU 401 845
Europe 466 792
North America 485 679
Oceania 46 422
South America 36 330

(source : Gregorio Robles and Jesús M. González Barahona –
2006)


 Principes
 Historique
 Guidelines


Comment le libre est-il développé ?

 Outilsde travail collaboratif :
• Internet, CVS, SubVersion, mailing-lists, chat
IRC
• « Forges » publiques (ou privées) :
- SourceForge
- FusionForge, ...
 Structure projets (caricature)
• old-style traditional model : Cathedral
• new unexpected style : Bazaar
"The Cathedral and the Bazaar" (Eric Raymond)
 Projet == réseau social


Communautés, résaux sociaux

Linux 1.0
(1994)
Developers linked by
common authorship to
same files
source [Robles]


Bon sang, mais c'est le bazar !

Classical analysis of Apache modules feb. 2004 (source [Robles])

Amélioration de la visualisation

Reshaped with Girvan-Newman algorithm (source
[Robles])

Apache 01/01/1999


Apache 01/01/2000


Apache 01/09/2000


Apache 01/01/2002


Apache 01/02/2004


Prendre part à une nouvelle communauté

 Rencontrer des hommes (et des femmes), pas
seulement des compagnies ou des services
marketing
 Construire un projet où différents modèles
peuvent cohabiter
 Apprendre les règles des communautés
 Méritocratie
 De nombreux mode d'organisation sociale
 Comme dans la « vie réelle » c'est souvent plus
subtil que ce qu'on en dit dans les
présentations ou les publicités !
 Communiquer pour construire la confiance


« HOWTO » projets
basés sur le libre


 Principes
 Historique
 Guidelines


Qualités

 Prépare l'avenir
 Sécurité
 Adaptabilité
 Indépendance
 Faiblecoût
 Portabilité
 ...

 Encore faut-il vérifier ?
 Qui fait vraiment ce travail ?


Annuaires

 Freshmeat http://freshmeat.net/ (> 39000
projets)
 FSF/Unesco : http://directory.fsf.org/ (> 5800
projets)
 Framasoft : http://framasoft.net/ (> 1400)
 Ohloh : http://ohloh.net/ (> 300 000 projets ??)


Sélection d'un produit

 Facilité à tester
 Ne pas confondre vitesse et précipitation
 Sous-traiter ce qui peut l'être
 Identifier les éléments critiques et monter en
compétence
 Préférer les solutions déjà packagées
(distributions)
 Éléments de dépendance sur des tiers non-
contractualisés


Nombreuses qualités

 Qualités génériques ... déjà connues

 Qualités particulières d'un logiciel libre
=> à évaluer
• sa licence
• sa communauté
• son code (sa doc, son langage, etc.)

 Méthodes d'évaluation (QSOS, OpenBRR, ...)

http://fr.wikipedia.org/wiki/Méthode_d'évaluation_de_logiciels_libres

Méthode QSOS (http://www.qsos.org/)


Fiche QSOS


Analyse des besoins
Conduite de projet

Spécification

Architecture

Conception détaillée

Codage

Tests

?
Déploiement


Maintien en condition opérationnelle

 Réactivitépour les mises à jour
 Diminuer l'adhérence dans les composants
spécifiques


Stabilisation impossible

 Mises à jour de sécurité permanentes
 Répétition des mises à jour
 Automatisation souhaitable
 Diminuer la taille du code spécifique


Reverser au projet

 Rendre générique les éléments spécifiques
 Maintenus à l'extérieur
 Améliorés à l'extérieur
 Pas besoin de les repackager

 Plus facile à dire qu'à faire

 Participer aux projets externes ASAP


Compétences pour le développement

 Rendre générique ce qui peut l'être
(bibliothèques, sous-projets)
 Méthodologie d'intégration (versions dérivées,
customisations)
 Support de certains matériels (distributions
supportées)
 Virtualisation (Xen, etc.)
 Savoir packager (exemple : Debian)
 Traditionnels : doc, specs, tests, etc.
 Animation de communauté


Repackager i810switch

Page 75 / 93 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=374638#15
Dpt. INF O. Berger

Repackager i810switch (suite)
$ apt-get source i810switch
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Nécessité de prendre 32,3ko dans les sources.
Réception de : 1 http://ftp.fr.debian.org testing/main i810switch 0.6.5-3 (dsc) [593B]
Réception de : 2 http://ftp.fr.debian.org testing/main i810switch 0.6.5-3 (tar) [24,3kB]
Réception de : 3 http://ftp.fr.debian.org testing/main i810switch 0.6.5-3 (diff) [7376B]
32,3ko réceptionnés en 0s (271ko/s)
gpg: Signature made ven 22 déc 2006 00:06:16 CET using DSA key ID 0917A9E4
gpg: Can't check signature: public key not found
dpkg-source : extraction de i810switch dans i810switch-0.6.5
dpkg-source : extraction de i810switch_0.6.5.orig.tar.gz
dpkg-source : mise en place de ./i810switch_0.6.5-3.diff.gz

$ cd i810switch-0.6.5/

$ wget "http://bugs.debian.org/cgi-bin/bugreport.cgi?
msg=15;filename=i810switch_macbook_support.patch;att=1;bug=374638"

$ patch -p1 <i810switch_macbook_support.patch
patching file debian/changelog
patching file i810switch.c

$ dpkg-buildpackage -rfakeroot
dpkg-buildpackage: source package i810switch
dpkg-buildpackage: source version 0.6.5-4
dpkg-buildpackage: source changed by Thomas Perl <thp@perli.net>
dpkg-buildpackage: host architecture i386
fakeroot debian/rules clean
dh_testdir
dh_testroot

...

dpkg-deb : construction du paquet « i810switch » dans « ../i810switch_0.6.5-4_i386.deb ».


Comment bien intégrer un projet libre

 Guides nouveaux contributeurs
 Être de bonne volonté (commencer petit pour
se faire connaître)
 Pas magique (le diable est dans les détails)
 Identifier la roadmap
 Stratégie de stabilisation de versions
 Système d'Assurance Qualité
 Identifier les acteurs clé
 Rencontres physiques
 Canaux temps réel (IRC, etc.)


Spécificités du projet

 Pas que la licence
 Communauté
• développement
• utilisatrice
 Personnes, rôles
 Acteurs économiques
 But, objectifs
 Méthodologie


Règles de vie en communauté

 Bénévoles (motivations)
 Professionnels
 Contractualisation ?
 Confiance
 Leadership
 Barrières à l'entrée
 Humour, culture et autres folklores


Enjeux sociaux plus que techniques

 Comprendre les règles du jeu
 Identifier les éléments influents
 Motiver des bénévoles
 Faire accepter ses contributions
 Impact sur les décisions
 Prouver son implication
 Se faire (re-)connaître
 Anticiper les alea


Contribuer : une nécessité

 Cercle vertueux des contributions
 Quasi-obligation du fait des licences
 Externalisation de la maintenance
 Se faire plaisir et apprendre en vraie grandeur
 Se faire connaître et reconnaître
 Influer sur le pilotage d'un projet


C'est l'histoire d'un bug
* From: Olivier Berger < olivier.berger@int-edu.eu>
* To: " Sympa-dev@cru.fr" < Sympa-dev@cru.fr>
* Subject: [sympa-dev] Re: Re: authenticateAndRun for createList not working in SOAP server in 5.3.3 ?
* Date: Fri, 21 Sep 2007 16:58:26 +0200

Le vendredi 21 septembre 2007 à 16:29 +0200, Olivier Berger a écrit :
> >
> > I'm using the soap client in Perl in which I did something like :
> > $reponse =
> > $soap->authenticateAndRun($user_email,$md5,'createList',
['essai5','essai5','picoforge_publicproject_members','List
> > essai4 of project essai4','essai4'])
> > &print_result($reponse);
> > called with the listmaster user...
> >

Having a look at the createList() code in sympasoap.pm, I see :

...
unless ($reject){
&Log::do_log('info', 'create_list
%s@%s
from %s refused, missing parameter(s) %s', $listname,$robot,$sender,$reject);
die SOAP::Fault->faultcode('Server')
->faultstring('Missing parameter')
->faultdetail("Missing required parameter(s) : $reject");
}

Wouldn't it be :
*IF* ($reject){
&Log::do_log('info', 'create_list
%s@%s
from %s refused, missing parameter(s) %s', $listname,$robot,$sender,$reject);
die SOAP::Fault->faultcode('Server')
->faultstring('Missing parameter')
->faultdetail("Missing required parameter(s) : $reject");
}
instead of unless ?


Bug Sympa dans Debian

J+5

/ 93 Dpt. INF O. Berger
J+6

Committed upstream (branch in SVN)

J+6

Migration vers Debian

J+7
Accepted sympa 5.3.3-5 (source i386)

Date: Fri, 26 Oct 2007 11:56:09 +0200
Source: sympa
Binary: sympa
Architecture: source i386
Version: 5.3.3-5
Distribution: unstable
Urgency: low
Maintainer: Stefan Hornburg (Racke) <racke@linuxia.de>
Changed-By: Stefan Hornburg (Racke) <racke@linuxia.de>
Description:
sympa - Modern mailing list manager
Closes: 443802 444188 444304 447721 447945
Changes:
sympa (5.3.3-5) unstable; urgency=low
.
* fix createList not invoked from authenticateAndRun on SOAP server
(Closes: #444188)

J+35

/ 93 Dpt. INF O. Berger

Comment bien contribuer

 Iln'y a pas besoin de savoir coder
 Assurer une veille régulière
 Beaucoup d'effort même pour des choses
simples
 Minimum légal : faire vivre la base de bugs
dans le bugtracker du projet


Comment bien contribuer (suite)

 Accepter des usages sociaux différents
 Communiquer avant tout
 Jouer le jeu selon les règles
 Eviter l' « abandonware » non déclaré
 Contribuer un nouveau module au bon endroit
 Investir dans une forge pour un nouveau
logiciel
 Aspects contractuels (reversement
communautaire, publication)
 Respecter des licenses
 Respecter copyright


Conclusion

 Loin de l'exhaustivité

 Le libre est un changement extrèmement positif
 Plein d'oportunités

 Pas un seul modèle : mais quelques bonnes
pratiques générales

 Contribuer est nécessaire pour la survie du
modèle, mais aussi concrètement dans les
effets utiles aux projets locaux.


 Merci à:
• Jean-Christophe Becquet / APITUX
• Roberto Di Cosmo / Paris 7 – PPS
• Gregorio Robles
 Aller plus loin :
• http://www.apitux.org/index.php?2009/05/25/199-cours-logiciel-libre-standards-ouverts-et-interoperabilite
• http://loli.fsa.ulaval.ca/index.php?id=9
• http://dpt-info.univ-littoral.fr/mediawiki/index.php/I2L:Accueil
• http://www.dicosmo.org/CourseNotes/LogicielLibre/


Conditions d'utilisation

 Thiswork is Copyright 2009 by Institut
TELECOM and Olivier Berger, published under
a Creative Commons ShareAlike license


Merci de votre attention

http://www-public.it-sudparis.eu/~berger_o/weblog/


Introduction aux logiciels libres

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (17)

Andere mochten auch

Andere mochten auch (7)

Ähnlich wie Introduction aux logiciels libres

Ähnlich wie Introduction aux logiciels libres (20)

Mehr von olberger

Mehr von olberger (17)

Introduction aux logiciels libres