Damien Clauzel

Isabelle Vodjdani, enseignante-chercheuse, a participé à la conception d'une exposition sur la contrefaçon; sa contribution était sous la forme d'une présentation du Libre. Mais l'INPI l'a censurée. Je reprends ci-dessous sa contribution à l'exposition.

« Une exposition aux intentions pédagogiques sur la Propriété Intellectuelle, décrit toutes les formes de contrefaçon mais censure les informations se rapportant aux pratiques licites du Libre et de l’Open-Source. Si on avait voulu faire l’apologie des pratiques illicites on ne s’y serait pas mieux pris ! »

Texte sous Licence Art Libre

Le libre, un phénomène en expansion

Dans le cadre du droit d’auteur qui protège les créations littéraires et artistiques, un nombre croissant d’auteurs choisissent de mettre leurs œuvres à la disposition du public avec un type de contrats bien spécifiques qu’on appelle des licences libres. Ces licences autorisent quiconque à diffuser des copies de l’œuvre. Elles l’autorisent également à publier sous sa propre responsabilité d’auteur des versions modifiées de l’œuvre. Ces autorisations sont assorties de deux conditions :

• Premièrement, il faut mentionner l’auteur de l’œuvre initiale et donner accès à ses sources
• Deuxièmement, les copies ou versions modifiées de l’œuvre doivent être publiées avec les mêmes autorisations.

Les œuvres libres sont nécessairement divulguées avec une licence qui garantit ces conditions. Parmi ces licences, on peut citer la GNU GPL, pour les logiciels, et la Licence Art Libre, pour les œuvres culturelles. Le domaine des œuvres libres n’est donc ni une zone de non droit ni assimilable au gratuit. D’ailleurs les anglo-saxons associent le mot français « libre » au mot « free » pour écarter toute confusion, car il y a des œuvres gratuites qui ne sont pas du tout libres, et il y a des œuvres libres payantes.

On parle aussi du « monde du libre » pour désigner l’ensemble des acteurs qui participent à la promotion et au développement du domaine du libre. Ce mouvement s’inspire des usages qui régissent la circulation des connaissances dans les milieux académiques. Mais depuis 1983, ce sont les développeurs de logiciels qui sont à l’avant-garde de ce mouvement et de sa formalisation juridique, car dans ce secteur d’activité la nécessité d’innovation est constante et les utilisateurs ont tout intérêt à mettre la main à l’ouvrage pour améliorer les défauts d’un logiciel ou l’adapter à leurs besoins. Ainsi, ils deviennent à leur tour auteurs.

Ce modèle de développement correspond aux aspirations d’une société démocratique composée de citoyens qui apportent une contribution constructive à la vie publique et ne se contentent pas d’être seulement gouvernés. L’intérêt que suscite le Libre est donc d’abord d’ordre politique. Cet intérêt est exacerbé par le fait que les législations de plus en plus restrictives sur le droit d’auteur évoluent à contresens de l’intérêt du public et deviennent des freins pour la création. Dans ce contexte, les licences libres apparaissent comme une issue légale et pragmatique pour constituer un domaine dans lequel les obstacles à la diffusion et à la réutilisation créative des œuvres sont levés.

Dans le domaine de la création artistique et de la publication scientifique, le modèle du libre correspond aussi à une réalité sociale. C’est l’émergence d’une société d’amateurs qui, à la faveur d’un meilleur accès à l’éducation, au temps libre, aux moyens de production et de communication, s’invitent sur la scène en bousculant parfois les positions établies. Ces amateurs sont les vecteurs, les acteurs et les transformateurs de la culture, ils en sont le corps vivant ; sans eux les œuvres resteraient « lettre morte ».

Depuis le 19ème siècle, avec la création des musées et la naissance du droit d’auteur, notre culture a privilégié les moyens de la conservation pour assurer la pérennité des œuvres. Aujourd’hui, les supports numériques et internet sont en train de devenir les principaux moyens de diffusion des œuvres. Certes, internet est un puissant moyen de communication, mais il n’a pas encore fait ses preuves en tant que moyen de conservation. Ce qui se profile avec le modèle du libre, c’est que parallèlement aux efforts de conservation dont le principe n’est pas remis en cause, une autre forme de pérennisation retrouve sa place dans notre culture ; il s’agit de la transmission, qui fonde aussi la tradition. Or, l’acte de transmission passe par un processus d’appropriation (on ne peut transmettre que ce qu’on a déjà acquis ou assimilé), et cela implique des transformations qui font évoluer les œuvres. C’est la condition d’une culture vivante, une culture portée par des acteurs plutôt que supportée par des sujets.

Une fois de plus revient ce vieux serpent de mer qu'est la question de l'ordre des auteurs d'un article rédigé à plusieurs mains. On aurait pu croire le problème simple, mais manifestement ce n'est pas le cas (pour tous). Je ne peux pas résister au plaisir de faire un billet rapide sur la question (juste pour vous faire réagir :)

Illustration tirée de Cham, Jorge : Author List, dans Piled Higher and Deeper, 13/3/2005

Quand il s'agit de déterminer l'ordre des auteurs d'un article, les gens sont capable d'une imagination débordante : simple ou double tris imbriqués selon le poste, l'âge, le domaine ou encore la météo du jour, ou bien par importance de contribution, de besoins administratifs ou encore de positionnement. Chaque fois qu'on pense avoir tout vu, on tombe sur une nouvelle fantaisie.

Au final, si c'est très distrayant à regarder, c'est surtout très casse-pied à démêler. Surtout quand on est face à un discours multiple :

• d'un côté, il y a (quasi ?) unanimité sur l'absurdité de la bibliométrie telle qu'elle est pratiquée par les agences gouvernementales en charge de la recherche;
• d'un autre côté, quand on regarde la liste des auteurs d'un article inconnu, on ne peut faire aucune déduction sur l'intention qu'ont eu les auteurs en adoptant un ordre précis. Est-ce que Machin est plus respectable que Truc, ou a encore plus contribué que Bidule ? Impossible à savoir;
• et bien sur, il y a également l'aspect de déterminer quel ordre va adopter un groupe de personnes quand il s'agira, pour elles, de publier.

La solution est à mes yeux évidente : affirmer ses idées et n'utiliser que l'ordre alphabétique ^[1], au besoin en mentionnant ce détail pour plus de clarté.

Comme de toute façon personne ne peut en déduire quoi que ce soit, et que tout le monde s'en fout, autant faire simple. Honnêtement, vous faites l'effort de suivre des auteurs pour savoir si leur position dans la liste des rédacteurs de leurs publications augmente ou régresse ? Moi pas.

L'ordre alphabétique est simple, compréhensible par tous, « juste » (quand on connait l'importance de ce critère...) et permet surtout de se débarrasser d'un problème humain empoisonnant.

Régulièrement, je reçois des courriers me demandant des précisions sur mes billets, ou des conseils en relation avec mes activités sur le net. Je prend toujours le temps d'y répondre en longueur, mais certains messages gagneraient à être plus largement diffusés, car les mêmes questions reviennent régulièrement.

Ainsi, les mails concernant la protection de la vie privée tournent souvent autour de deux thèmes : comment protéger sa vie privée dans telle ou telle activité, et est-ce légal de vouloir la protéger avec un outil précis. Voici le dernier message que j'ai reçu à ce sujet.

Je vous écrit suite au fait que vous soyez noté comme adresse de contact du noeud de sortie Tor "rebelZ".

Ce dernier est à priori hébergé en France sur une machine chez GANDI. Vu que je m'intéresse à la situation actuelle de Tor vis-à-vis de la législation autour des télécommunications qui a tendance à se durcir en France, je me demandais si vous aviez eu le moindre problème légal jusqu'ici.

Par ailleurs, quelles sont vos relations avec GANDI ? Leur avez-vous demandé avant de démarrer ce relai ? Vous ont-ils déjà transmis des plaintes concernant ce service ?

Merci d'avance si vous preniez le temps de répondre à mes quelques questions.

PS : Je vous joint ma clé GnuPG si vous désiriez me chiffrer votre réponse.

Je suis effectivement un client de Gandi, sans rien de particulier : je leur confie la gestion de plusieurs DNS, utilise leurs systèmes de blog, d'hébergement et de courrier. Bien que je trouve leurs prix élevés depuis quelques temps (principalement à cause de l'augmentation de la concurrence) je reste chez Gandi car la qualité de service est élevée : uptime correct, interfaces web efficaces, et une bonne assistance en cas de soucis.

Ainsi, lorsque j'ai besoin de déployer rapidement un petit serveur pour héberger un projet ou tester quelques outils, j'utilise l'hébergement mutualisé de Gandi. La machine rebelz (rebelz.Clauzel.nom.fr) est l'une d'entre elles. Elle n'a rien d'extraordinaire, si ce n'est le fait qu'elle n'accepte que des connexions chiffrées (https, ssh, svn+ssh, etc) et que ses volumes sont eux aussi chiffrés. En effet, elle sert actuellement de plate-forme communautaire à un petit groupe de chercheurs de mon laboratoire. Pour parler technique, il s'agit d'un serveur headless mutualisé Debian constitué d'une seule part (1/64e).

En ce qui concerne TOR (couplé à outils comme privoxy, socat et tsocks), je l'utilise depuis ses débuts, et j'ai pour habitude de mettre en place des relais là où je le puis afin de renforcer son usage. C'est donc tout naturellement que j'ai mis en place un nœud sur rebelz.

À ma connaissance, TOR n'a jamais été impliqué dans le cadre d'une enquête judiciaire en France, aussi bien en simple relais qu'en nœud de sortie. Mais le mieux serait d'interroger directement des juristes spécialisés. Néanmoins, comme il s'agit là d'assurer le rôle d'opérateur technique permettant l'interconnexion de systèmes informatiques, je ne vois pas la possibilité pour un juge de mettre en cause l'administrateur : en effet, rendre responsable l'administrateur de l'usage qui est fait du relais obligerait également à rendre responsable France Télécom des appels circulant par ses lignes. Inconcevable, quoi qu'en disent les ayatollahs de LOPPSI.

En ce qui concerne l'utilisation des machines virtuelles de Gandi, les conditions générales de l'hébergement (article 3) ne font aucune mention de la mise en place de relais de services. Les seules contraintes sont le respect de la législation française (droit d'auteur, diffamation, etc) et la gestion en « bon père de famille ».

En résumé : TOR, yabon.

Non, non, ne hurlez pas; je vous vois venir avec vos mais qu'est-ce qu'il va encore nous inventer cette fois-ci ? :)

Lisez, vous allez voir, ça va vous intéresser.

Avant-propos

Je travaille depuis maintenant un bon moment à mettre en place une partie de nos idées sur les traces, concernant la visualisation d'activité (individuelle ou collaborative, a/synchrone, ici on s'en fout). Architecture, conception de modèles, instrumentation d'application, couche réseau, formats de données, parsers, etc; vous l'avez compris, tout passe entre mes mains excepté le SGBT qui est pour moi une boîte noire. Si vous pouvez imaginer quelque chose relatif aux traces (RàPC excepté), alors je me suis certainement penché dessus à un moment durant ces six derniers mois.

Je vous présente ici un retour sur l'expérience que j'ai développé, à base de réflexions personnelles. Le constat est plutôt mitigé, je vous préviens d'avance. Rien de dramatique, mais il faudra en tenir compte pour la suite de nos travaux car ça a des conséquences importantes. Je vais essayer de faire un découpage propre, mais vous allez voir que tout est lié.

Ma réflexion est orientée sur le transfert vers l'entreprise (non, ce n'est pas un gros mot) de nos travaux de recherche. C'est à dire : « qu'est-ce qu'il faut prendre en compte lorsqu'on va essayer de vendre la trace modélisée à un industriel ».

La conception de modèle

La première étape de l'enrichissement d'une situation informatique par les traces (sous-entendu, après tout le blabla d'analyse) est la conception d'un modèle de traces de logiciel(s). Cela :

Demande des compétences très spécialisées

Soyons réalistes, comprendre la théorie de la trace modélisée et être capable d'expliciter des interactions dans son formalisme n'est pas à la portée de tout le monde. Non pas que cela soit particulièrement complexe, mais cela exige un certain nombre de connaissances et de compétences qui ne se trouvent pas partout.

Que ce soit par une méthode ascendante ou descendante, concevoir des modèles de trace d'applications ne peut être fait que par un petit nombre de personnes. Or, ce qui est rare est cher. Il va donc falloir convaincre l'entreprise de réaliser cet investissement. Cela peut passer par une mission d'un expert extérieur, la formation d'une personne déjà en place, un partenariat avec une structure compétente, etc. Plusieurs possibilités existent, mais toutes ont un coût qui n'est pas négligeable.

Nécessite beaucoup de temps

Un logiciel, même très simple, est riche en possibilités d'interactions. On peut retenir l'utilisation de menus, de boutons, de paramètres, de zones de saisie, de fonctions, etc, ainsi que des opérations plus globales impliquant les périphériques d'entrée et de sortie.

Au final, on se retrouve à manipuler un très grand nombre d'observés et de relations, ce qui nécessite plusieurs jours semaines de travail. La richesse en observés étant exponentielle par rapport à la complexité d'un logiciel, essayez de visualiser ce à quoi pourrait ressembler le modèle de trace d'OpenOffice. Oui, c'est plus que gros : c'est énorme. Et on ne peut pas se permettre de laisser de côté certaines parties du modèle car cela impliquerait de ne pas être capable de représenter correctement les interactions de l'utilisateur sur ce logiciel.

L'entreprise ayant besoin de tracer une activité, un environnement ou que sais-je encore, va devoir y passer du temps (qui est aussi de l'argent, comme nous le rappel le célèbre adage). Ce temps sera pris au dépend d'autres activités, peut-être plus facilement et rapidement rentables.

Comprend aussi la conception des règles de transformations usuelles

Tout comme sans maîtrise, la puissance n'est rien, des traces qu'on ne peut pas manipuler sont tout de suite moins intéressantes. La conception de jeux de règles de transformations adaptées aux modèles de traces est un des à-côté du travail conceptuel de la trace.

En effet, on ne peut pas simplement donner un modèle de trace à une entreprise en lui disant « voilà, tu as ton modèle, à toi de te débrouiller pour faire ce que tu veux avec ». Il faut donc en parallèle du modèle construire les règles de transformations qui vont les utiliser, afin d'obtenir un résultat final qui corresponde aux attentes de l'entreprise. L'entreprise pourra certes produire en interne de nouvelles règles de transformations (par une tactique de copie/adaptation), mais il faudra lui préparer le terrain. Et qui est-ce qui va se taper le travail ? Gagné, c'est l'expert qui s'occupe déjà du modèle. Cela augmente sensiblement sa charge de travail, et donc le coût pour l'entreprise.

Instrumentation des logiciels

Selon le logiciel à instrumenter, le travail technique pour réaliser la collecte d'observés varie grandement. J'ai identifié 3 catégories d'instrumentation :

• édition en profondeur du code source : méthode qui nécessite d'avoir accès au code source du logiciel, et d'être en mesure d'y apporter des modifications;
• création de greffons présentant des interfaces pour interroger le contenu de variables d'état : ici, on ajoute des fonctionnalités à l'application en s'appuyant sur ses API. On est limité par ce que propose l'application en terme d'accès aux ressources internes.
• création de préparateurs de traces qui récupèrent des données exportées par l'application pour produire des observés : cette approche consiste à récupérer des informations sorties de l'application via ses méthodes standard (par exemple, flux RSS ou AppleEvent). Cette méthode apporte le découpage le plus fort dans le tandem application/traçage, et est limitée par l'application elle-même.

Selon les applications à instrumenter et les méthodes utilisées, le coût de l'adaptation logicielle varie énormément. Malheureusement, il n'est pas possible d'identifier un petit nombre de critères précis permettant de quantifier simplement ce coût. C'est uniquement en prenant en compte une combinaison de nombreux facteurs qu'on peut le déterminer. À titre d'idée, on peut citer sans s'y restreindre :

• la complexité du travail;
• la durée du travail;
• le langage de programmation (allez trouver quelqu'un qui fait encore du COBOL, tiens :)
• la documentation disponibles (humain, référentiel de développement, etc);
• l'urgence;
• etc.

Il y a également les coûts liés; par exemple, les structurels : achat d'un serveur pour le SGBT, mise à jour des matériels, adaptation de l'architecture réseau...

Les cycles de vie logiciel dans environnements tracés

Un logiciel peut être vu comme quelque chose de « vivant », évoluant au fur et à mesure des versions. Ces évolutions sont nécessaires pour de nombreuses raisons : changement dans l'environnement d'accueil (le système d'exploitation), sécurité, nouvelles fonctionnalités, etc.

Tout naturellement, il faut que les éléments du traçage accompagnent ces évolutions. Tout s'enchaînent très rapidement de façon implacable :

1. modifier le logiciel tracé (peut) oblige(r) à modifier la collecte
2. modifier le logiciel tracé oblige (pas moyen d'y échapper, là) à modifier le modèle de traces
3. modifier le modèle de traces oblige à modifier les transformations de traces (et oui...)
4. modifier les transformations de traces impacte sur la visualisation des traces (j'y reviendrais plus tard)

On se rend compte alors que la mise à jour est coûteuse car il faut de nouveau faire appel à notre expert. Vous souvenez de lui, celui de la 1e étape, qui avait conçu les modèles ? Et bien il va falloir retourner le voir pour lui demander de se pencher sur les modifications. Ceci dit, ça tombe bien car il pourra tout traiter d'un seul coup : l'évolution des modèles et celle des transformations. Et si en plus derrière il peut assurer la formation ça ne sera pas perdu.

Le plus problématique est qu'il faut répéter ce cycle à chaque nouvelle version du logiciel. C'est réellement un surcoût, car la rentabilité n'est pas évidente à dégager (comptablement parlant).

Mentalement, insérez ici un joli schéma de traces complet d'une application, montrant côte à côte les modèles de traces pour la version N et la version N+1. Imaginez de gros, gros (mais alors gros), graphes avec des nœuds et des arcs dans tous les sens, qui seraient différents de seulement quelques détails : observés en plus ou en moins, déplacement de relations, changement d'attributs, etc.

Je mettrais les schémas quand je les aurais fini, le but est ici de vous faire prendre conscience du volume de travail que ça représente.

Pratiques des utilisateurs liées aux traces

En ce qui concerne l'utilisateur final, c'est plus simple pour lui. Une évolution de son environnement tracé se traduit non seulement par une modification de sa pratique métier, mais également de sa pratique réflexive via les traces. Ben oui, vous ne croyez quand même pas qu'au final rien ne change ? Et comme nous le savons, tout ce qui change les habitudes de l'utilisateur le fait râler (sauf si c'est Génial, mais ça seul Apple arrive à le faire :)

De petites modifications dans un logiciel peuvent avoir de grandes répercutions sur le modèle de trace, et donc sur la visualisation interactive de la trace par l'utilisateur. Il va donc lui falloir un temps d'adaptation (ce qui influera sur sa productivité), voir même une formation.

Également, les changements dans les traces et modèles pourront se propager à d'autres environnements, tracés ou non. C'est le cas lors de la documentarisation de traces en vue de générer des productions (textes, hypermédia, etc.) Même si ces outils ne sont pas tracés, ils sont impactés par les changements sur les données d'entré.

Que retenir au final ?

On peut dire qu'instrumenter un environnement pour lui faire générer des traces est long, pas toujours simple, et n'est pas nécessairement faisable de façon clairement rentable.

Les problèmes apparaissent à tous les niveaux : conceptuel (modèles), technique (instrumentation) et humain (usage). Les principaux étant le coût (je crois l'avoir suffisamment répété :) de la mise en œuvre de la trace dans un système existant, et les compétences spécialisées requises dans chacune des étapes de la réalisation.

Convaincre un industriel d'investir dans la trace est alors réellement un problème, car les gains à dégager sont difficilement calculables, et la mise initiale est élevée.

Au final, pour moi la théorie de la trace est attirante sur le papier, mais les difficultés liées à la réalisation sont vraiment rebutantes.

Pistes envisageables

Tout n'est pas perdu ! Maintenant que nous avons regardé le problème droit dans les yeux, on peut louvoyer en évitant ce qui justement nous embête.

Ainsi, on peut songer à cibler en priorité les systèmes figés, qui n'évoluent pas ou très peu :

• machine-outil : une chaîne de production change rarement, car son utilisation est planifiée en amont. Du coup, pas besoin non plus de faire évoluer les trucs-de-la-traces \o/
• systèmes critiques : les outils comme ceux du contrôle aérien n'ont pas le même cycle de vie que les logiciels grand public; on ne passe pas son temps à les mettre à jour. Il sont conçus pour durer, et c'est au contraire les autres systèmes qui s'adaptent pour interagir avec eux. En gros, une fois le traçage dedans, il n'en bouge plus.
• logiciels arrivés à maturité; ils peuvent être complexes (Lotus Notes) ou très simples (calepin de Windows). De par leur nature, rôle ou histoire, certains logiciels sont intouchables; on se contente au plus de les recompiler, mais en veillant à ne rien changer afin de ne pas provoquer d'effets de bord (comme par exemple un changement de modèle de trace).

Une autre approche est de se poser la question de savoir qui a suffisamment d'argent à dépenser pour se lancer dans un projet pareil, sans que le responsable risque de se faire virer après la réception de la facture par le service compta :

• les grands comptes : la Poste, EDF (eh, ça tombe bien :), etc;
• la fonction publique : quand l'administration investie, elle ne le fait pas à moitié; souvenons-nous du « Plan informatique pour tous »;
• les Décideurs Pressés qui imposent contre l'avis de leurs DSI des solutions qu'ils jugent intéressantes. Avec un joli PowerPoint®™©, on arrive à vendre des glaçons au Pôle Nord.

Vous l'avez compris, j'exclus tout ce qui est grand public dans les cibles potentielles. Il y a éventuellement le monde du Libre qui pourrait mettre en place et maintenir des utilisations de traces modélisées, mais il faudrait vraiment que ça soit pertinent.