Bibliothèque : (Souvent appelé « librairies [1] » en raison du faux ami anglais En informatique, une bibliothèque ou librairie logicielle (ou encore, bibliothèque de programmes) est un ensemble de fonctions utilitaires, regroupées et mises à disposition afin de pouvoir être utilisées sans avoir à les réécrire. Les fonctions sont regroupées par leur appartenance à un même domaine conceptuel (mathématique, graphique, tris, etc). Les bibliothèques logicielles se distinguent des exécutables dans la mesure où elles ne représentent pas une application. Elles ne sont pas complètes, elles ne possèdent pas l'essentiel d'un programme comme une fonction principale et par conséquent ne peuvent pas être exécutées directement. Les bibliothèques peuvent regrouper des fonctions simples (par exemple le calcul d'un cosinus, ou l'inversion d'une matrice) comme des fonctions complexes, avec de nombreuses fonctions internes non accessibles directement. L'intérêt des bibliothèques réside dans le fait qu'elles contiennent du code utile partageable que l'on ne doit pas avoir à réécrire à chaque projet.
Composant [2] : Matériau constituant le logiciel
Code source [3] : Suite d’instructions en un langage informatique. Ce programme est compilé sur la machine en un code objet, puis lié avec des bibliothèques en un code exécutable aussi appelé programme exécutable.
Le code source [3] (ou les sources, voire le source) est un ensemble d'instructions écrites dans un langage de programmation informatique de haut niveau, compréhensible par un être humain entraîné, permettant d'obtenir un programme pour un ordinateur.
Composants : http://fr.wikipedia.org/wiki/Composants_communs [4]
CPI [5] : Code de la Propriété Intellectuelle
Documentation [6] : Ensemble de documents élaborés par l’Éditeur de progiciel et le fournisseur de système et comprend notamment le guide utilisateur et la documentation [6] technique.
Forge [7] : En informatique, une forge [7] désigne un système de gestion de développement collaboratif de logiciel (cf [8] Wikipedia [9]).
Fork [10] : Parfois nommé embranchement. L'utilisation, parfois critiquée à bon escient, de l'anglicisme fork [10] dans le contexte de projet informatique est une utilisation imagée du mot fork [10] utilisé en programmation : on crée un nouveau projet à partir d'un autre à l'identique, sans détruire celui-ci. Cela suppose que les droits accordés par les auteurs le permettent : ils doivent autoriser l'utilisation, la modification et la redistribution du code source [3]. C'est pour cette raison que les embranchements se produisent facilement dans le domaine des logiciels libres (voir Wikipedia [11]).
Gouvernance [12] : Ensemble de méthodologies, méthodes et outils utiliser pour contrôler un processus
Licence compatible [13] : Est dite compatible toute licence de logiciel qui se substitue à une autre en respectant l'ensemble de ses termes lors de la distribution du logiciel ; elle permet généralement de distribuer un ensemble de composants logiciels sous une seule licence.
Licences copyleft (« gauche d’auteur » jeu de mots par opposition à droits d’auteur) : l’auteur d’une adaptation s’engage à ce que son adaptation soit elle-même libre de droits. Alors que l’auteur d’une adaptation d’un logiciel non copylifté peut protéger le programme dérivé sans avoir à reverser quoi que ce soit à la communauté du logiciel premier.
Module [14] : Un module [14] en programmation désigne un espace de noms. Chaque module [14] peut exporter ou importer certains symboles comme des variables, des fonctions ou des classes. Les modules peuvent se regrouper en package éventuellement hiérarchique (voir Wikipedia [15]).
Référentiel : « Ensemble de bases de données contenant les « références » d'un système d'information » (voir Wikipedia [16]).
Versions [17] : Un logiciel est susceptible de changer de forme, car il connaît différentes versions [17], par traduction de langage, par évolution de ses fonctionnalités, par adaptation à son environnement matériel et aux besoins des utilisateurs. Tant que la création originale est reconnaissable sous les évolutions, il s’agit d’une seule et même œuvre.
Licence X |
||
Informations |
||
|
Auteur |
|
Date de création |
|
|
Langue |
|
|
Version |
|
|
Traduction |
|
|
Domaine (logiciel, documentation [6], etc.) |
|
|
Liberté |
||
|
Libre |
|
Interdit la commercialisation |
|
|
Interdit la modification |
|
|
Obligations |
||
|
Obligation de céder les mêmes droits (Copyleft) |
|
Marques |
|
|
Brevets |
|
|
Paternité |
|
|
Autre |
|
|
Obligations additionnelles tolérées |
|
|
Portée de la licence |
||
|
Type |
|
Exceptions |
|
|
Licence de redistribution |
||
|
sous la même licence |
|
Possible sous une autre licence |
|
|
Sous certaines licences mentionnées |
|
|
Condition de réutilisation |
||
|
Mention du copyright |
|
Citation des auteurs |
|
|
Conditions relatives à la marque |
|
|
Autre |
|
Il s’agit ici de mentionner :
Le nom du logiciel ou de l’application livrée
Le niveau de version (ou d’état technique, niveau de tag, etc.) livré
Une description fonctionnelle sommaire (laquelle pourra renvoyer aux spécifications fonctionnelles)
La liste des principaux modules ou composants, surtout quand ces modules font l’objet d’une facturation additionnelle. Cette liste doit correspondre notamment aux éléments de facturation pour limiter les risques de litige en matière de recette et donc de règlement. Cette liste pourra également comprendre un tableau de correspondance avec la liste des répertoires et fichiers de la livraison, si le nommage des répertoires de sources et/ou de livrable de ces modules n’est pas le même que celui utilisé dans les contrats de licence/maintenance/fourniture.
Remarque : Il arrive fréquemment que le nommage des sources diffère du nommage « marketing » des modules, pour des raisons d’historique, parce qu’à un module [14] commercial correspondent plusieurs modules techniques, etc.
Toute information complémentaire éventuellement nécessaire pour préciser le périmètre de cette livraison.
Remarque : Dans la mesure où ce logiciel/application est l’objet principal du contrat de licence, d’utilisation et/ou de maintenance, il mérite d’être soigneusement décrit.
Remarque : la quasi-totalité des applications livrées à des utilisateurs finals comporte un minimum de composants non propriété du prestataire : Open Source, composants d’infrastructure nécessaire au déploiement ou à l’exécution (librairies [1] « run-time”…). Il convient de les lister précisément, tout particulièrement quand le contrat de fourniture prévoit transfert total ou partiel de propriété au client.
Liste des composants utilisés par le processus de build en précisant :
Nom et niveau de version du composant [2], nom du propriétaire pour les logiciels propriétaire (le propriétaire pouvant être le prestataire lui-même qui réutilise des composants d’autres applications et dont il veut absolument conserver la pleine propriété),
Type de logiciels : Open Source, propriétaire
Statut des licences : licence propriétaire, GPL, LGPL, etc.
Remarque : « licence gratuite » n’est pas un statut au sens juridique…
État technique de ces composants : état natif ou modifié, corrigé, complété par le prestataire…
Liste des composants utilisés par le prestataire dans le processus d’intégration en précisant :
Nom et niveau de version du composant [2], nom du propriétaire pour les logiciels propriétaire (le propriétaire pouvant être le prestataire lui-même qui réutilise des composants d’autres applications et dont il veut absolument conserver la pleine propriété)
Type de composant [2] : documentation [6], données insérées en base (par exemple données cartographiques, liste des codes postaux, images, etc.), logiciels…
Statut des licences : licence propriétaire, GPL, LGPL…
Support de livraison : fourniture sur CD [18], téléchargement avec nom du site…
État technique de ces composants : état natif ou modifié, corrigé, complété par le prestataire…
Liste des pré requis de déploiement pour tous matériels et composants non fournis par le prestataire mentionnant :
Environnement matériel y compris des dispositifs spéciaux tels que lecteurs de cartes, configuration de disques et plus généralement tout ce qu’il incombera au client de préparer pour la phase de déploiement (que celle-ci soit faite par lui-même ou par le prestataire)
Nom de chaque composant [2] logiciel : système d’exploitation, moteur de bases de données, dispositifs de connexion à distance pour la télémaintenance…
Niveau de version de chaque composant [2] logiciel
Le cas échéant, procédure spécifique d’installation et de paramétrage pour être compatible avec la livraison…
Remarque : Cette partie pourra faire référence à la documentation [6] d’installation ou en reprendre les éléments concernés. Rappelons que cette annexe est un document contractuel qui fera foi en cas de contestation, de litige, d’arbitrage.
Remarque : Cette information est nécessaire quand l’application est installée chez le client utilisateur. Mais elle peut être également « rassurante » quand l’application est fournie en mode SAAS [19]/ASP [20] et déployée chez un hébergeur.
Remarque : environnement matériel doit être précisé. D'autant plus important qu'il y a de plus en plus de logiciels. En terme d'inventaire, il faut avoir les mentions des micrologiciels (tBIOS) : indissociable du matériel (ne peuvent fonctionner sans). Ces informations doivent aussi être conservées.
Il s’agit ici de donner l’arborescence du contenu du support de livraison en listant les principaux répertoires, sous répertoires et fichiers, avec une description sommaire de leur contenu, de telle sorte que le client puisse raisonnablement rapidement identifier :
Les composants externes qui lui sont fournis avec la livraison et nécessaires pour le déploiement et/ou le fonctionnement de l’application (ceux-ci ayant été décrits ci-dessus),
Les modules livrables correspondant aux modules listés dans son contrat de licence,
Tout ce qui concerne le déploiement, le peuplement et le paramétrage initial des bases de données,
Des jeux de tests à dérouler après déploiement pour s’assurer que la procédure d’installation s’est déroulée normalement (que ces jeux de test soient déroulés par le prestataire ou par le client lui-même),
Les documentations techniques dont il aura besoin : pour le déploiement, pour l’exploitation, la maintenance, le support, etc. (par exemple : manuel utilisateur, manuel d’exploitation, …)
Remarque : Il ne s’agit pas d’une liste exhaustive de tous les répertoires et fichier, mais d’une description de la livraison permettant au client d’y retrouver rapidement l’essentiel des informations et éléments dont il aura besoin, soit pour déployer et valider, soit pour prononcer sa recette.
Remarque : Il arrive parfois que le client ne respecte pas scrupuleusement les procédures de déploiement et de test, parce qu’il ne prend pas la peine de lire les documentations fournies, parce qu’il fait des économies sur la formation de son personnel etc. Il peut être intéressant pour le prestataire d’apporter alors la preuve de la qualité, complétude et validité des documentations, procédures, informations fournies au client lors de la livraison.
Un certain nombre de contrats de fournitures logicielles prévoient une clause dite « de séquestre/défaillance » par laquelle le fournisseur s’engage à déposer sous séquestre les éléments nécessaires à la reprise de maîtrise en maintenance de l’application livrée par toute personne compétente, en cas de défaillance en maintenance du fournisseur initial.
Cela suppose que soit ajoutés à la liste fournie ci-dessus, un certain nombre de composants et documentations non fournis normalement à l’utilisateur, mais nécessaires à cette reprise de maîtrise en maintenance dans des conditions raisonnables.
La liste de ces éléments complémentaires peut varier en fonction des objectifs des parties, des types de déploiement ou de commercialisation. On pourra donc trouver les cas suivants (non exhaustifs) :
Solutions financières avec un leaser.
Fourniture à un intégrateur,
Système de preuve vis-à-vis d’une autorité de tutelle (sanitaire, sécurité, fiscale, traçabilité, Objectif patrimonial,
Système de preuve en matière de droits d’auteur.
Commercialisation en mode SaaS [19]/ASP [20] :
Ce cas est également assimilable aux solutions outsourcing. En pareil cas, l’utilisateur est dépendant de son fournisseur, non seulement en ce qui concerne la maintenance évolutive, mais également toute la production (exploitation, sauvegardes, sécurité...). Dans la plupart des cas, le fournisseur utilise les services d’un « hébergeur ». En cas de besoin, l’utilisateur aura besoin d’informations et de composants complémentaires tels que :
Nom et coordonnées de l’hébergeur,
Descriptif détaillé des composants fournis par l’hébergeur : type de machine (dédiée ou partagée), système d’exploitation (nom, niveau de version, procédure d’installation et de paramétrage), mots de passe d’accès au serveur, nature des composants spécifiques matériels et logiciels complémentaires fournis par l’hébergeur, dispositifs de sécurité, etc.
Procédure détaillée de déploiement et de paramétrage de l’application client sur l’environnement d’hébergement, mots de passe d’accès, de redirection de noms de domaines, etc.
Procédures complémentaires d’exploitation utilisées par le fournisseur (gestion de profils utilisateurs, purge des bases de données, procédures de mises à jour de l’application, etc.)
Systèmes de sauvegarde (miroring), localisation des back-up…
Plus généralement, toute information permettant au client comme au fournisseur de basculer la production sur un autre site en cas de défaillance de l’hébergeur, par exemple.
Ce cas est assez proche de celui du déploiement en mode SaaS [19], à ceci près qu’une société financière s’intercale entre le fournisseur et le client final et que c’est elle qui perçoit les mensualités couvrant la licence, la maintenance applicative, l’hébergement et même souvent le matériel installé en local. Cette société financière peut alors se trouver engagée à millions sur une application et a besoin de sécuriser ses encaissements (autant par des procédures de secours et de sécurité que par des contrats d’assurance). Le « financier » à alors besoin d’être assuré de disposer de tous les moyens pour relancer la production en priorité puis la maintenance applicative dans des délais compatibles avec ceux couverts par son contrat d’assurance par exemple ou dans les délais prévus avec les clients et au-delà desquels des pénalités de retard pourraient lui être imposées. Il peut alors avoir besoin d’informations complémentaires telles que :
Liste complète des mots de passe de redirection des noms de domaine des clients concernés,
Liste des mots de passe d’accès aux machines locales des clients pour intervention en maintenance et mise à jour des applications déployées en local,
Copie des factures de vente et/ou bons de garantie des matériels financés …
L’intégrateur a a priori vocation à reprendre la maintenance et le développement en cas de défaillance du fournisseur d’origine. C’est souvent pour cette raison qu’un « grand compte » préfère travailler avec un intégrateur, même s’il lui impose d’intégrer telle ou telle solution qu’il a validée comme correspondant à ses besoins. En pareil cas, les contraintes de reprise de la maintenance peuvent imposer des délais plus courts et des pénalités de retard.
L’intégrateur doit alors disposer de toutes les informations techniques lui permettant de reprendre la maîtrise de l’application dans les délais impartis. Il devra alors disposer des informations telles que :
Normes internes de développement et de nommage,
Spécifications fonctionnelles et techniques,
Dossiers d’architecture,
Scripts de création peuplement et paramétrage initial des bases de données, descriptions des tables, index, etc.
Quand il y a des composants hardware tels que des cartes spécifiques, nom des sous-traitants, dossiers de conception et environnements de développement correspondants (y compris ceux utilisés par les sous-traitants et dont les licences peuvent être très coûteuses), sources, documentations de conception, fichiers résultants, etc.
A la demande d’une autorité de tutelle, il peut être demandé de produire des sources, des plans de test et dossiers de validation, que ce soit pour des raisons fiscales, de santé publique, de risques humains ( logiciels embarqués sur des matériels roulants ou volants) etc. Le fournisseur aussi bien que son intégrateur peuvent être amenés à fournir solidairement des informations complémentaires telles que ;
Dossiers et plans de test,
Dossier de validation pour mise en conformité avec les exigences de la CNIL [21], de la FDA, de normes aéronautiques, etc.
Systèmes de traçabilité,
Systèmes de sécurisation des données et des transmissions, etc.
Dans le but de prouver qu’ils ont respecté les normes imposées et/ou qu’ils ont testé leurs applications de façon professionnelle et à la hauteur des risques potentiellement encourus pas leurs utilisateurs
En matière de « Droits d’auteur » et pour autant que cela soit nécessaire en matière de « logiciels libres », l’administration de la preuve est dite « de libre parcours ». En d’autres termes, tout ce qui contribue à renforcer le « faisceau de preuves de propriété » est utile. Dans ce cadre, le propriétaire de l’application (notamment quand il s’agit de code source [3] interprété et donc fourni à l’utilisateur) pourra ajouter un certain nombre d’informations complémentaires telles :
Justification des choix d’environnements de développement et de déploiement, articulation de ces composants, etc. En effet ; si le fournisseur n’est pas propriétaire des environnements qu’il a utilisé, le choix qu’il en a fait n’est pas dû au hasard et sa cohérence d’avec le contenu de son patrimoine en renforcera nécessairement le système de preuve.
Bases de données de sources (CVS [22], VSS, Perforce, etc.) donnant l’historique détaillé de tout ce qui a été développé, modifié, ajouté au fil des mois et des années à une application initiale ou entre deux versions [17] de cette application,
Documents préparatoires au développement, etc.
Ce document est licencié cumulativement sous licences GNU FDL 1.3< [23] et CC-BY-SA 3.0< [24].
La GNU FDL [25] est une licence libre copyleft calquée sur la GNU GPL [26], parfaitement adaptée aux documentations et qui nécessite que soit annexé systématiquement le texte de la licence.
La CC [27]-BY-SA est une licence libre copyleft parfaitement adaptée aux contenus multimédias. Sa grande modularité permet de mixer les réalisations.
Le contenu sous licence est dès lors compatible avec la totalité des licences qui lui sont adjointes ;
L’étendue de la double licence est limitée à celle de la licence la plus permissive ;
L’utilisation d’au moins une licence française sécurise la double licence au regard des dispositions françaises.
Par dérogation au paragraphe précédent, certaines exceptions peuvent être apportées à la cession de droits telle que consentie par la licence. Les éléments concernés par ces limitations sont les suivants :
Élément |
Titre et/ou description |
Licence |
Remarques |
---|---|---|---|
|
|
|
|
|
|
|
|
Par dérogation aux paragraphes précédents, la diffusion du document est limitée de la manière qui suit :
Mention de diffusion :
Nom |
Organisme |
Pour |
Média |
Tous les collaborateurs |
X |
Information |
GED, Wiki |
|
|
|
|
Prénom NOM, Prénom NOM, Prénom NOM.
Exemple de référent : le « Responsable Open Source » d'Orange Labs (transverse à une organisation)
L’utilisation grandissante de logiciels issus de ___________ dans les nouveaux produits et services a un impact positif sur les coûts des développements, mais augmente les risques sur la propriété intellectuelle, à la fois en terme juridique, en terme de capacité de protection des services France Télécom et de potentiel de valorisation. Dans l’objectif de favoriser l’utilisation de l’Open Source tout en maîtrisant les risques associés et minimisant les impacts sur la propriété intellectuelle, la division R&D [28] a défini sa politique de l’Open Source.
La mission du responsable Open Source est de piloter la mise en œuvre de cette politique dans la production et l'utilisation des logiciels à la Division R&D [28]. Cette mission s’exerce en coopération avec la Direction de la Propriété Industrielle et Valorisation et la Direction Juridique.
Contribuer à décliner la politique Open Source dans le processus de production de la Division R&D [28]. La politique Open Source doit être intégrée en amont du processus et suivie tout au long du cycle de vie du logiciel.
Diffuser la connaissance des pratiques et des règles dans l’utilisation et la production de logiciels dans le contexte de l’Open Source, faire connaître la politique Open Source de la Division et la politique de propriété intellectuelle et leur déclinaison dans le processus.
Apporter, en amont, un soutien aux projets dans les décisions liées à l’Open Source pour :
Attention : ressource distribuée à titre purement indicatif
Partant du principe que toutes les licences Open Source se rejoignent sur le plus grand nombre de leurs clauses, ce tableau vise à les distinguer par les obligations à la charge du licencié qui diffèrent.
Par ailleurs, les licences Open Source consacrent l'existence d'une sphère privée dans laquelle les licenciés bénéficient de tous les droits sans être contraints de respecter d'obligation
NB : les Creative Commons sont déconseillées pour un usage sur des logiciels notamment parce qu’elles sont modifiées pour chaque système juridique (on perd cette notion d’internationalisation) et la dernière version (3.0) n’est justement pas encore d’actualité en France.
Lecture du tableau : Peut-on, à partir d'une licence A (licence d'origine), distribuer sous une autre licence B (licence de distribution)
→ OSI [29] (Open Source Initiative) : Cette définition centrée sur l'objet de droits, le logiciel, a ensuite été développée dans l'Open Source Definition< [30]< qui définit les critères qu'une licence doit vérifier afin d'assurer à chacun et sans discrimination ce partage du monopole d'exploitation. Est donc Open Source une licence qui vérifie :
La libre redistribution du logiciel — elle ne peut, par exemple, exiger le paiement d'une redevance supplémentaire ;
Le code source [3] doit être fourni ou être accessible ;
Les dérivés des œuvres doivent être permis ;
L'intégrité du code doit être préservée — un tiers ne peut pas s'approprier le travail d'un autre et les contributions de chacun sont clairement attribuées (les modifications peuvent n'être éventuellement distribuées que sous forme de patch, séparément : distinguo que ne tolère pas la FSF [31]) ;
Pas de discrimination entre les personnes ou les groupes — toute personne détentrice d'une copie du logiciel bénéficie des termes de la licence tant qu'il s'y conforme lui-même ;
Pas de discrimination entre les domaines d'application — la licence se limite à la propriété intellectuelle : elle ne peut en aucun cas réguler un autre domaine « politique » ;
La licence s'applique sans dépendre d'autres contrats — ex : on ne peut pas ajouter un NDA (accord de confidentialité) lors de la cession du logiciel ;
La licence ne doit pas être propre à un produit — elle est attachée au code et non à un logiciel particulier : un composant [2] peut resservir dans un logiciel différent, voire concurrent ;
La licence d'un logiciel ne doit pas s'étendre à un autre — Remarque : la large étendue de la GPL (et c'est la raison pour laquelle certains utilisent le terme de viralité ou de propagation) est conforme à ce critère puisqu'elle ne s'étend qu'au programme envisagé comme un tout ;
La licence doit être neutre technologiquement — c'est-à-dire ne pas dépendre d'une technologie.
« GUIDE OPEN SOURCE : RÉFLEXIONS SUR LA CONSTRUCTION ET LE PILOTAGE D’UN PROJET OPEN SOURCE », réalisé sous la direction de Benjamin Jean et Olivia Flipo — Copyright © 2010
Ce document est licencié cumulativement sous licences GNU FDL 1.3< [23] et CC-BY-SA 3.0< [24].
La GNU FDL [25]< est une licence libre copyleft calquée sur la GNU GPL [26], parfaitement adaptée aux documentations et qui nécessite que soit annexé systématiquement le texte de la licence.
La CC [27]-BY-SA est une licence libre copyleft parfaitement adaptée aux contenus multimédias. Sa grande modularité permet de mixer les réalisations.
Cette double licence permet un usage du document qui soit conforme à l’une ou l’autre des licences. Plusieurs avantages peuvent être avancés :
Le contenu sous licence est dès lors compatible avec la totalité des licences qui lui sont adjointes ;
L’étendue de la double licence est limitée à celle de la licence la plus permissive ;
L’utilisation d’au moins une licence française sécurise la double licence au regard des dispositions françaises.
Première brique d'un guide Open Source dont nous sommes certains de l'utilité, ce document sera amené à évoluer. Chaque nouvelle version fera l'objet d'une numérotation distincte.
N'hésitez pas à nous contacter si vous êtes intéressés et que vous souhaitez rejoindre le groupe de travail.
Liens:
[1] http://guideopensource.info/glossary/term/2
[2] http://guideopensource.info/glossary/term/3
[3] http://guideopensource.info/glossary/term/4
[4] http://fr.wikipedia.org/wiki/Composants_communs
[5] http://guideopensource.info/glossary/term/5
[6] http://guideopensource.info/glossary/term/6
[7] http://guideopensource.info/glossary/term/7
[8] http://guideopensource.info/glossary/term/26
[9] http://fr.wikipedia.org/wiki/Forge_%28informatique%29
[10] http://guideopensource.info/glossary/term/8
[11] http://fr.wikipedia.org/wiki/Fork#Embranchement_d.27un_projet_informatique
[12] http://guideopensource.info/glossary/term/9
[13] http://guideopensource.info/glossary/term/10
[14] http://guideopensource.info/glossary/term/12
[15] http://fr.wikipedia.org/wiki/Module_%28programmation%29
[16] http://fr.wikipedia.org/wiki/R%C3%A9f%C3%A9rentiel_%28BDD%29
[17] http://guideopensource.info/glossary/term/14
[18] http://guideopensource.info/glossary/term/20
[19] http://guideopensource.info/glossary/term/62
[20] http://guideopensource.info/glossary/term/16
[21] http://guideopensource.info/glossary/term/24
[22] http://guideopensource.info/glossary/term/28
[23] http://www.gnu.org/licenses/fdl-1.3.html
[24] http://creativecommons.org/licenses/by-sa/2.0/fr/
[25] http://guideopensource.info/glossary/term/34
[26] http://guideopensource.info/glossary/term/33
[27] http://guideopensource.info/glossary/term/19
[28] http://guideopensource.info/glossary/term/61
[29] http://guideopensource.info/glossary/term/57
[30] http://www.opensource.org/docs/definition.php
[31] http://guideopensource.info/glossary/term/43