Souscrire via RSSInterview : Assefa Yewondwossen, développeur MapServer
1. Peux tu faire une présentation de ton parcours professionnel et ce qui t’a amené à travailler dans la géomatique open source ?
J’ai commencé ma carrière dans une compagnie de cartographie a Gatineau, QC, LSC 2+1. Cette compagnie faisait essentiellement la production de cartes topographiques canadienne de façon traditionnelle. J’ai joint LSC 2+1 en 1993 en tant que programmeur lorsqu’elle a amorçait un virage technologique dans le but de produire les cartes de façon entièrement digitale. On utilisait dans ce temps les produits LAMPS de la compagnie britannique Laser Scan. On a par la suite développé à l’interne un logiciel de cartographie numérique ACE (Automated Cartography Edition). Ce logiciel est intégré aujourd’hui dans le logiciel Geomatica de PCI Geomatics qui a racheté LSC 2+1. En 2000, j’ai joint l’équipe de DM Solutions qui venait tout juste de commencer à regarder des solutions Open Source pour pouvoir bâtir des applications de Web Mapping pour ses clients existants.
Interview : Tyler Mitchell, au service de la communauté spatiale open source
Voici la première interview d’une série dont l’objectif est de présenter des acteurs du monde de la géomatique open source. Acteurs parfois méconnus des utilisateurs, ils contribuent souvent d’une manière importante et régulière, à différents projets majeurs.
Ce premier article est une interview de Tyler Mitchell, directeur et unique salarié de la Fondation OSGeo, vous le verrez souvent intervenir dans les différents sujets des listes de l’OSGeo. Auteur d’un livre que je recommande à tous pour vous plonger dans les différentes applications de base du monde de la géomatique open source, personnage ouvert sur le monde qui l’entoure, il représente à lui seul cette communauté open source.
Esri se met à l’Open Source (pour une API)
arcOrama, un blog sur les SIG, et ceux d’Esri en particulier, a publié un billet appelé « Le Toolkit de l’API Silverlight en Open-Source« . Donc Esri publierait une de leur API en Open Source ?
La réponse semble oui : le dépôt et toutes les informations sont disponibles sur le site du projet : http://esrisilverlight.codeplex.com/. Il est possible de soumettre un patch, retourner un bug, etc. Un premier pas pour Esri mais un grand pas pour l’utilisateur !
Bon la licence est la Microsoft Public Licence… Mais n’a t-elle pas été reconnus comme une licence Open Source par l’OSI, consortium qui définie les licences en tant que licence Open source ?
Un nouvel éditeur OpenStreetMap
La version 1.2.0 de QGIS (nommée Daphnis) qui ne devrait pas tarder à sortir, l’équipe de développeur ayant freezé la version en court de développement (c’est à dire qu’ils ont bloqué l’ajout de nouvelles fonctionnalités), affiche une nouveauté intéressante pour les cartographes du projet OpenStreetMap.
En effet un nouveau plugin permet de télécharger les données d’une zone, de la modifier et de renvoyer ses modifications vers le serveur OSM. Il est également possible de charger une couche au format OSM locale pour édition.
Le plugin est constitué de 6 boutons dans la barre d’outils et d’une fenêtre pour les paramètres :
La 3eme icône en parant de la gauche (flèche bleu vers le bas) permet de récupérer les données à partir du serveur OSM. La fenêtre de récupération des données ressemble à ceci :
Voici ce que donne la récupération de données OSM à l’Est du Jardin des tuileries à Paris :
Dernière chose qu’il me semble important de signaler est la possibilité d’importer des données à partir d’une couche vectorielle vers la couche OSM.
Liens :
Géolocalisation des visite du site FOSS4G 2009
Suite à un article de Cameron Shorter sur son blog à propos des visites géolocalisées sur le site http://foss4g2009.org je me suis amusé à reprendre les données et à les pondérer par la population de chaque état. Cameron a également blogué sur ces résultats (en anglais) sur son blog.
TileCacheConfig : une interface web graphique pour configurer TileCache
Je viens de découvrir en parcourant le site de TileCache, qu’une interface web existait pour configurer TileCache ! Celui s’appelle en toute logique TileCacheconfig, bien que succint, a le grand mérite d’exister et d’être très facilement installable.
Sortie de la version 1.4.0 de PostGIS
L’équipe de développement de PostGIS vient d’annoncer la sortie d’une nouvelle version (la 1.4.0) après une « période de médidation et de recherche intérieure » (je cite l’annonce). La version est téléchargeable ici : http://postgis.refractions.net/download/postgis-1.4.0.tar.gz
Cette nouvelle version de PostGIS inclus une augmentation importante de la performance, une documentation améliorée, un nouveau format en sortie (GeoJSON) et un système interne amélioré de teste. PostGIS 1.4 gère la version récente de PostgreSQL 8.4.
Compatibilité minimale :
- PostgreSQL 8.2 et supérieure sur toutes les plateformes ;
- GEOS 3.0 et supérieure seulement ;
- PROJ4 4.5 et supérieure seulement.
Nouvelles fonctionnalités :
- ST_Union() utilise l’union rapide en cascade lorsqu’il est compilé avec GEOS 3.1+ (Paul Ramsey) ;
- ST_ContainsProperly() nécessite GEOS 3.1+ ;
- ST_Intersects(), ST_Contains(), ST_Within() utilise les géométries préparées en cache super rapide en fonction de GEOS 3.1+ (Paul Ramsey) ;
- amélioration importante de la documentation et du manuel de référence (Regina Obe & Kevin Neufeld) ;
- exemples de figures et de diagrammes dans le manuel de référence (Kevin Neufeld) ;
- ST_IsValidReason() renvoi des explications explicites sur l’échec de la validité (Paul Ramsey) ;
- ST_GeoHash() renvoi une signature geohash.org pour les géométries (Paul Ramsey) ;
- Interface multi-plateforme pour le chargement de Shape (Paul Ramsey) ;
- ST_LineCrossingDirection() renvoie des directions de passage (Paul Ramsey) ;
- ST_LocateBetweenElevations() renvoie des sous-chaînes basé sur Z-ordonnées (Paul Ramsey) ;
- le parser de géométrie renvoi des messages d’erreur explicites sur l’endroit des erreurs de syntaxe (Mark Cave-Ayland) ;
- ST_AsGeoJSON() renvoie un format JSON ;
- Populate_Geometry_Columns() — ajoute automatiquement les enregistrements dans les tables geometry_columns pour les TABLES et les VIEWS (Kevin Neufeld) ;
- ST_MinimumBoundingCircle() — renvoie le plus petit polygone circulaire qui peut entourer une géométrie (Bruce Rindahl).
Amusez vous bien !
Des logiciels libres aux données libres (partie 3 sur 3)
Les données libres
Les licences, ces modèles économiques, ces outils et cette organisation présentés dans les sections précédentes sont adaptés et ont été conçu pour des projets logiciels. La problématique pour les projets de données sont un peu différente. Cette section a pour but de tenter de proposer une définition pour chacun d’eux.
Licences
Il existe plusieurs licences de données libres :
- la probable future licence de OSM ;
- la Public Geodata Licence ;
- mais d’autres existent.
Les licences libres doivent permettre :
- la liberté d’utiliser les données — pour tous les usages ;
- la liberté de voir les données brutes — ce qui suppose l’accès aux données brutes ;
- la liberté de redistribuer des copies, mapshup, cartes, etc. (travaux dérivés) — ce qui comprend la liberté de vendre des copies et travaux dérivées ;
- la liberté d’améliorer les données et de publier ses améliorations — ce qui suppose, là encore, l’accès aux données brutes.
Les travaux dérivés constituent une modification telle que l’accès aux données brutes n’est plus possible. Il en résulte selon les droits décrits plus haut, que le diffuseur doit fournir un accès aux données libres utilisées. Mais cela est un peu plus complexe qu’il n’y parait …
OpenStreetMap utilise jusqu’à présent la licence « Creative Common CC-BY-SA ». Cela signifie que vous avez le droit de copier et de diffuser le document en gardant l’auteur et les conditions originels. Cette licence pose un certain nombre de problème :
- elle n’a pas été conçu pour des données !
- elle n’est pas clair sur les possibilités de réutilisation des données (mapshup, cartographie, etc.).
La nouvelle licence proposée par la Fondation OpenStreetMap (en réalité composée de deux licences : Open Data Licence combiné à l’ODL Factual Info Licence) est une licence adaptée aux bases de données et aux données. Ce projet de licence a été initiée en 2007 par Jordan Hatcher et Dr. Charlotte Waelde de l’Université d’Édimbourg et a proposé ces deux types licences complémentaires offrant une grande flexibilité d’utilisation. Elle est maintenant hébergée et gérée par l’Open Knowledge Foundation qui propose également d’autres projets.
La problématique des licences des données libres est donc non seulement différente de celle des logiciels libres mais beaucoup plus complexe. Comment définir un travail dérivé ? Des traitements spatiaux complexes sur les données devront elles être diffusés sous une licence libre ou bien pourrait on considérer ce travail de la même manière qu’écrire un document avec un logiciel de bureautique tel qu’OpenOffice ? Ces licences se doivent de préciser clairement ce qui est un traitement dérivé, les droits et devoirs qui s’y appliquent. D’autre part, est il souhaitable de faire la différence entre la structure de la table et son contenu ? Mais comment définir le « contenu » d’une base de données ?
D’autres parts, de nombreuses protections existent concernant les bases de données et les données : directive européenne, droit d’auteur, contrat, etc. L’auteur de la licence Opendatacommons explique : que
ce maquis de droits protégeant les bases de données et les données peuvent constituer un obstacle important pour l’utilisation et la réutilisation des données. Cela est vrai tant pour la communauté scientifique, qui souhaitent élargir sa connaissance grâce à l’utilisation des autres données et pour la communauté de la recherche et d’Internet avec pour ambition le Web sémantique.
[source : Jordan Hatcher, http://www.osbr.ca/ojs/index.php/osbr/article/view/516/475]
Mais comme nous venons de le voir, un travail est mis en place tant du côté d’OpenStreetMap que du côté de l’OSGeo ou d’autres groupes de travail. Ceci peut être préjudiciable car une licence ne sera adoptée que si elle correspond aux besoins du plus grand nombre tout en étant la plus lisible possible. Auxquels cas nous verrons le jour à une multitude de licences de données libres, chacune avec ses imperfections.
Les modèles économiques
Les modèles économiques des projets libres sont basés sur les services. Autant en matière de logiciels, ceux-ci ont pu être testé et ont pas mal évolué, en matière de données libres, tout reste à faire. Certaines sociétés ont tenté il y a quelques années de créer de la valeur ajoutée sur les données libres malheureusement la société n’a pas pu continuer à les proposer. Si on se réfère aux modèles économiques des logiciels libres, ceux-ci sont basées :
- sur les services ;
- sur la valeur ajoutée ;
- sur la double licence ;
- sur la mutualisation.
Peut-on se baser sur ces modèles pour élaborer ceux des données libres ? Quels services de données peut proposer une société ?
Une société peut proposer dans le cadre d’un modèle économique basé sur les services :
- des webservices WMS, WCS, WFS, SLD dont les données sont mis à jour fréquemment ;
- stockage de données en base de données PostGIS ou MyGIS ;
ou d’un modèle économique basé sur la valeur ajoutée :
- un travail de mise à jour et de validation des données ;
- des changements de projections et de formats.
Si son modèle économique est basé sur la double licence, elle peut proposer la mise à jour et la validation des données avec possibilité d’utiliser les données sous une licence commercial sans obligation de fournir les données brutes.
Enfin si son modèle économique est basée sur la mutualisation, elle peut proposer des améliorations qui seront financé par une communauté. Le projet OpenStreetMap peut être considéré comme étant basé sur un tel modèle économique dans le mesure où la fondation reçoit des dons et des financements en nature (matériel ou temps disponible des bénévoles) ou en argent (campagne de don). Aujourd’hui aucune société ne peut démarrer un projet de création de données libres concurrent à OSM à partir de zéro. Elle devra se focaliser sur d’autres type de données ou bien avoir déjà des données disponibles (libération de données).
Quelques sociétés ont commencé à proposer des webservices sur des données libres comme la société allemande WhereGroup. Deux solutions sont proposées : une gratuite, mise à jour deux fois par an, et une autre payante, mise à jour tous les jours. D’autres webservices peuvent être mise en place, comme les services WFS et WCS, mais également des services SLD de définition de style pour les couches proposées en WMS, des GeoDRM (accès à la données en fonction d’une identification).
Les communautés et leurs outils
Il existe peu d’outils, à ma connaissance, adaptés à la gestion des données (historique notamment). OpenStreetMap gère l’historique au moyen d’une table maître (master table) qui contient tout l’historique des éditions et d’une table « actuelle » (current table), en plus des tables d’administration et utilisateurs. OpenStreetMap est le projet de référence en matière de communauté de données libre bien qu’elle soit focalisée sur les données routières principalement, seul une société éditrice ayant déjà des données pourrait arriver à rivaliser avec elle (mais on a déjà vue des projets leader perde tout leadership suite à des mauvaises décisions comme par le changement de licence).
OpenSteetMap propose ainsi toute une suite de logicielle (Merkaator, potlach, etc.), une API, une bases de données avec des snapshots ou nightly build réguliers, des listes de diffusions, un wiki, etc. Nous retrouvons tout ce qui compose un projet de logiciel libre.
À noter deux applications web intéressantes. J’ai parlé de l’application web TRAC plus tôt. Application qui permet de gérer des tickets qui constituent des rapports de bugs relatif aux logiciels. L’équivalent existe pour les données, cela s’appelle OpenStreetBug ou RIPart (Remontée d’Informations Partagées) ou bien des tests « unitaires » pour vérifier la qualité des données. L’application RIPart n’est pas libre et se base sur l’API du Geoportail. Elle a pour objectif de faire remonter les informations qui sont incorrectes vers le fournisseur de données (l’IGN).
Vous trouverez quelques informations supplémentaires sur la base de données d’OpenStreetMap dans ces liens :
- Explication du schéma de la base de données d’OpenStreetMap ;
- Schéma de la base de données d’OSM ;
- Pile applicative d’OSM.
Quelles données publiques doivent être libres et comment ?
Le Power of Information Taskforce Report a réalisé 7 recommandation sur les données libres :
- les données géographiques basique telles que les limites électorales et administratives, La localisation des établissements publiques, etc doivent être disponible pour libre (ré)utilisation ;
- il doit y avoir un accès aisé et libre aux données adresses ;
- les organisations bénévoles et communautaires poursuivant des objectifs de politique publique doivent bénéficier de dispositions standard simples pour assurer l’accès aux données géospatiales à tous les niveaux d’utilisation ;
- les licences doivent être simplifiée et harmonisées [..] et ne devrait pas dépendre de la destination ou du modèle économique de l’utilisateur ;
- l’API d’OpenSpace (l’équivalent anglais de notre géoportail), similaire mais plus contraignant que la version de Google Maps, doit devenir le point principal de diffusion pour les services de l’Ordnance Survey (l’IGN anglais) ;
- la création et la disponibilité des adresses et des codes postaux pour l’Angleterre libre pour (ré)utilisation.
Conclusion
La donnée et l’information sont le moteur de l’économie de la connaissance. Les recommandations du rapport sur la libéralisation des informations non personnelles du gouvernement pourrait fournir un stimulus de l’information si elle est appliquée.
[Source : http://poit.cabinetoffice.gov.uk/poit/2009/02/introduction-to-the-taskforce-final ]
Une réflexion doit avoir lieu sur les données libres publiques et la possibilité d’innovation qu’elles permettent. En Angleterre, la task force a permis d’initier une telle réflexion avec les utilisateurs. Citons les une dernière fois :
Il y a maintenant un besoin urgent de réformer l’Ordnance Survey. Actionnaires exécutifs et ministère du Trésor sont actuellement en train de mettre en place un examen du modèle économique. Elles devraient saisir l’occasion de la refonte de l’Ordnance Survey en agence cartographique du 21e siècle. Les progrès technologiques ont modifié les fondements traditionnels du modèle d’entreprise de l’Ordnance Survey et il existe un risque réel qu’il se retrouve lui-même anachronique, il est dépassé par des alternatives ouvertes telles que OpenStreetMap, soutenue par des technologies bon marché comme appui à la création de carte.
Des études ont montrées la pertinence des modèles économiques pour l’édition de logiciels libres, en France comme à l’étranger de nombres sociétés ont basées leur fonctionnement sur de tel modèle. D’ailleurs la France tient une place importante dans le monde de l’open source. Concernant les données libres, on voit ici et là, quelques initiatives mais très peu de véritable modèle économique sont mis en place, et un organisme public a toute sa pertinence pour mettre en place un tel modèle. Quelle sera la place de la France en terme de données libres ? Quel organisme public ou privé libérera le premier ses données et basera son fonctionnement sur un modèle économique innovant et original ?
Enfin comme la task force pour l’Angleterre, nous (communauté de la géomatique en France) devons être source de propositions et agir pour informer nos représentants politiques de la pertinence de ce modèle comme service publique. Agir non pas sur l’IGN mais directement sur les politiques et sur la tutelle de l’IGN qui définisent les missions et objectifs de l’IGN.
Bibliographie
- La cathédrale et le bazar de Eric Raymond, http://seddisoft.kelio.org/cathedrale-bazar.htm ;
- Veni, Vidi, Libri : l’association Veni, Vidi, Libri a pour objectif de promouvoir les licences libres ainsi que de faciliter le passage de créations sous licence libre, http://www.venividilibri.org ;
- OSGeo – Public Geospatial Data Committee : comité Données Geospatial publiques de l’OSGeo, http://www.osgeo.org/geodata ;
- Portail de diffusion de données libres au Canada, http://www.geobase.ca/geobase/fr/index.html ;
- http://www.punkish.org/Licensing-Geographic-Data ;
- http://interactive.dius.gov.uk/innovationnation/ ;
- http://poit.cabinetoffice.gov.uk/poit/ ;
- Comité Données Geospatiales Publiques, http://wiki.osgeo.org/wiki/Public_Geospatial_Data_Committee ;
- http://www.opendefinition.org/ ;
- Open Source Business Resource, http://www.osbr.ca/ojs/index.php/osbr/index.
Des logiciels libres aux données libres (partie 2 sur 3)
Modes de fonctionnement
Parmi la multitude de projet libre les plus connus sont sans aucun doute les projets de logiciels libres. Cette section présente le fonctionnement des projets en tant que projet de logiciels libres. Ce qui me semble définir un projet de logiciel libre est l’existence d’une communauté de développeurs dont des règles écrites ou tacites régissent les comportements et les relations en toute transparence. Les utilisateurs ont la possibilité d’échanger ou de suivre les échanges avec ou entre les développeurs.
Le mode de fonctionnement des projets libres est directement lié aux modèles économiques choisis ainsi qu’aux libertés fondamentales (voir plus haut). Les mots-clés sont les termes communautaire, transparence et indépendance.
Une communauté
Un projet libre a pour vocation de réunir des contributeurs d’horizon divers autour du projet. La licence autorisant les utilisateurs à modifier et diffuser leurs modifications, il est de l’intérêt du projet d’accepter les modifications des utilisateurs et de l’intérêt des développeurs extérieurs à retourner leur développements les plus génériques. Et ce pour différentes raisons :
- le projet évolue ainsi plus facilement et plus rapidement (correction de bugs, nouvelles fonctionnalités, etc.) ;
- les développeurs extérieurs n’auront pas à ré-adapter leurs modifications à chaque nouvelle version (adaptation de leur code aux évolutions du coeur du projet, évolution et adaptation des fonctionnalités qu’ils ont développés par la communauté).
Un travail gagnant-gagnant en somme.
Pour que les contributions puissent être acceptées il faut que le projet se soit réunit autour d’une communauté d’utilisateurs et de développeurs prêt à contribuer. Mais il faut également des règles définies pour que tout utilisateurs et développeurs puissent connaître le processus d’acceptation des contributions au projet et connaître les besoins.
Des outils
Pour une bonne communication entre les développeurs et les utilisateurs, des outils sont mis en place. On trouve généralement :
- des listes de diffusion ;
- un serveur de dépôt de code source, svn ou subversion est généralement utilisé ;
- une interface de gestion de bug et de demande de nouvelle fonctionnalité, appelé bugtracker ;
- un canal irc ;
- un site Internet (avec le minimum vital parfois) ;
- un wiki (mais pas toujours).
Le serveur de dépôt de code, les listes de diffusion et le bugtracker sont le minimum que propose un projet. Ces outils ont chacun une fonction précise dans le processus de développement.
Listes de diffusion et canal IRC
Il existe généralement plusieurs listes, mais toutes celles qui sont présentées ici n’existent pas toujours :
- dev (toujours) ;
- users (toujours) ;
- commit (souvent) ;
- release (souvent);
- listes locales (fr, de, etc.).
La liste dev permet de discuter entre les développeurs : quelles sont les nouvelles fonctionnalités qui vont être ajoutées, discussion sur leur conception, sur les bug et leur résolution, définition du planning des prochaines versions, etc. C’est aussi l’endroit pour poser vos questions si vous désirez ajouter une nouvelle fonctionnalité.
La liste user vous permet de poser vos questions lié à des problématiques d’utilisation du logiciel. Les développeurs y répondent directement et rapidement assez souvent.
La liste commit vous permet de suivre de près (de très près même) les développements qui sont « commité » (d’où le nom de la liste) dans le serveur de dépôt de code source.
La liste release vous permet de vous tenir au courant des sorties des nouvelles versions.
Les listes locales vous permettent de poser votre question dans votre langue. Très peu de ce type de liste existe. Il en existe pour GRASS (grass-fr par exemple).
Un serveur de dépôt de code source
Un serveur de dépôt de code source est un serveur qui permet à plusieurs développeurs de travailler ensemble sur le développement d’un logiciel sans que leurs modifications du code source soient écrasées par celles des autres développeurs. Ce serveur gère également un historique des modifications :
- qu’est ce qui a été modifié ?
- qui a modifié ?
- quand le fichier a t-il été modifié ?
Voici quelques exemples :
- le svn de MapServer ;
- voir les sources de MapServer ;
- un diff entre deux versions du fichier HISTORY.TXT dans lequel une ligne a été rajoutée, cliquez ici.
Bugtracker
Un système de rapport de bug permet au projet de gérer les problèmes et les demandes de fonctionnalités. Il permet d’affecter ceux-ci à une version spécifique et permet de connaître la roadmap des futures versions. Voici celles pour QGIS. Vous trouverez sur cette page la liste des bugs actifs, classés par type de bug.
Site et wiki
Bien sur, un projet a toujours son site, parfois une page, parfois plus, il présente le projet, rassemble la documentation, liste les liens pour télécharger les versions (source et binaires). Parfois un wiki est proposé. De plus en plus souvent les projets utilisent une application appelée Trac qui rassemble un wiki, un bugtracker, une navigation du svn, la roadmap et la timeline ((page qui liste les envois de code sur le serveur de dépôt effectués par les développeurs)).
Des règles écrites ou tacites
Dans le cas un peu spécial où le projet est hébergé par l’OSGeo, le projet se doit d’avoir un minimum de règle écrite pour définir le fonctionnement du comité en charge du projet. Ce n’est pas souvent aussi formalisé au sein d’un projet Open Source. L’OSGeo impose un certain nombre de règle lors de la phase d’incubation : révision du code concernant le copyright, ajout d’en en-tête dans tous les fichiers pour indiquer la licence et bien sur des règles écrites concernant le fonctionnement du projet. Voici par exemple celui du projet OpenLayers.
Vous trouverez chaque Comité de pilotage du projet pour les projets de l’OSGeo sur cette page.
Des logiciels libres aux données libres (partie 1 sur 3)
Introduction
«Il est, je crois, un principe élémentaire du droit d’auteur que l’auteur n’a pas de droit d’auteur des idées, mais seulement dans l’expression de celles-ci. La loi du droit d’auteur ne lui donne pas tout monopole de l’utilisation des idées avec lesquelles il traite ou de toute propriété, même si elles sont originales. Ses droits d’auteur se limitent à l’œuvre littéraire dans laquelle il les a exprimées. Les idées sont des biens publics, l’œuvre littéraire est la sienne.» Justice Thorson P. in Moreau v. St. Vincent
Ce document, constitué de 3 billets dont celui-ci est le premier, a pour ambition de démontrer l’intérêt des données libres en partant d’une description du microcosme des projets libres (communauté, licence, modèle économique, etc.).
Le premier billet décrit les projets libres : liberté, modèles économiques, etc. La plupart des utilisateurs de Firefox, Linux, ou OpenOffice.org etc., ne connaissent ni les principes ni les implications d’un projet libre ou open source et pourtant celles-ci ont des implications sur le logiciel et leur utilisation. Le deuxième billet expliquera le mode de fonctionnement des projets en logiciels libres et open source : communauté, outils utilisés, organisation. Enfin le dernier billet traitera des données libres : quelles licences ? Quels modèles économiques ? Quelles organisations ? Quelles données doivent être libérées ?
Le lecteur notera que je parle ici de “projet libre” et pas de logiciel libre ! Pourquoi ? Parce que le concept du libre a aujourd’hui largement dépassé le cadre des logiciels pour toucher à tout ce qui se créer : logiciel bien sur mais aussi données, document, dessin, musique et vidéo.