Re: [TRAD GNU] stallman-mec-india découpé en 5 morceau - 1er morceau traduit

[Therese Godefroy <godef.th AT free.fr>]

Bonjour,

Pour faire avancer le schmilblick, je viens de découper le .pot en 5
morceaux. Le premier est traduit mais je ne l'ai qu'en html parce qu'il
y a trop de modif (re-découpage de paragraphes, sommaire, sous-titres,
listes à puce, ancres etc). Il a été vérifié dans Firefox. Pour en
refaire un .po, ça a l'air plutôt galère.

J'ai ajouté les sous-titres (en français bien sûr) dans les .pot 2 et
3.  

stallman-mec-india_1.html en pj. Les autres suivent.

Cordialement,
Thérèse


Le lundi 25 juillet 2011 à 20:07 +0200, Therese Godefroy a écrit :
> Bonjour,
> 
> Je commence à m'intéresser à stallman-mec-india. Comme dit B. Bayart, il
> y a de bons morceaux dedans. (Mais il y a peut-être plus urgent ?)
> 
> C'est un fichier énorme !  Il pèse 121 ko, et sera 2 fois plus gros une
> fois traduit. Pour comparer, digital-inclusion-in-freedom (traduit)
> pesait 113 ko et j'ai été obligée de le zipper pour l'envoyer.
> 
> Il faudrait sûrement le découper et en partager la traduction. 
> 
> Le texte est en 2 parties à peu près égales : la conférence et les
> questions. La conférence est amusante et assez facile à traduire, mais
> pour les questions c'est une autre paire de manches. Certaines sont
> incompréhensibles (et l'étaient d'ailleurs pour Stallman).
> 
> Je pense que pour ne pas se décourager (et pour donner à plusieurs
> personnes le plaisir de traduire ce texte) il faudrait découper le pot
> en morceaux de 30 ko au maximum. 
> 
> Sans même m'en rendre compte j'ai traduit 280 lignes sur 2856
> (directement à partir de la page web, sans passer par le .po, ce qui
> fait que je ne sais pas combien cela fait de chaînes). Je réserve donc
> le premier morceau.
> 
> Autre problème : c'est la transcription d'une conférence et quelquefois
> les paragraphes (les chaînes) sont mal découpés et la ponctuation pas à
> sa place. Cela serait bien aussi de mettre une liste à puces au moins à
> un endroit. Est-ce qu'on peut mettre des balises de formatage dans les
> chaînes traduites ?
> 
> Encore une fois, ce n'est peut-être pas de première urgence. Il me
> semble que les textes à traduire pourraient être classés par ordre de
> priorité. Est-ce déjà le cas ?
> 
> Cordialement,
> Thérèse
>

Title: Conférence de Stallman à l'école-modèle d'ingénieurs sur le danger des brevets logiciels

Le danger des brevets logiciels

conférence de Richard M. Stallman
au « Model Engineering College » (école modèle d'ingénieurs) du Gouvernement de Kerala, Inde

Présentation du conférencier

Conférence de Stallman

« Propriété intellectuelle » est une _expression_ erronée

Copyright et brevet sont deux notions différentes

Comment fonctionne le système des brevets

Il faut demander conseil à un avocat

Les stratégies en matière de brevet

Contourner les brevets qui vous menacent

Obtenir des licences d'exploitation

Les licences croisées

Contester la validité d'un brevet

On ne peut pas tout réinventer

L'invention logicielle n'a pas les contraintes pratiques de l'invention matérielle

L'invention logicielle est freinée par les brevets

Certains brevets couvrant à la fois du logiciel et du matériel sont acceptables

Les brevets purement logiciels doivent être refusés partout dans le monde

Questions de l'auditoire

Présentation du conférencier

Le Professeur Jyothi John, responsable du département d'informatique, présente Stallman :

C'est pour moi un privilège et un devoir que d'introduire l'hôte le plus illustre qui ait jamais rendu visite à ce collège.

M. Richard Matthew Stallman a lancé le développement du système d'exploitation GNU en 1984, avec pour but de créer un système d'exploitation de type Unix, qui soit complètement libre. L'organisation qui a été fondée en 1985 pour poursuivre cet objectif est la Fondation pour le logiciel libre.

Stallman est un visionnaire de l'informatique moderne. C'est le génie qui a conçu des programmes tels qu'emacs, gcc, le dégoguer GNU et bien d'autres. Surtout, il est l'auteur de la GNU General Public License, la licence sous laquelle plus de la moitié du logiciel libre est distribué et développé. L'association de GNU avec le noyau Linux, appelée « système d'exploitation GNU/Linux », a maintenant 20 millions d'utilisateurs dans le monde, selon les estimations.

La manière dont Stallman envisage le logiciel libre nous parle de liberté, plutôt que de prix. Ses idées contribuent grandement à créer les conditions du développement de logiciels destinés au bien-être de la société, par des programmeurs travaillant collectivement, sans « verrouiller » leur travail mais au contraire en le laissant à la disposition des autres pour l'étudier, le modifier et le redistribuer.

Stallman a reçu le prix Grace Hopper de l'Association for Computing Machinery (association pour le développement des outils informatiques) en 1991. En 1990, une bourse de la fondation MacArthur lui a été attribuée - parmi les autres lauréats de cette bourse prestigieuse, on trouve Noam Chomsky et Tim Berners-Lee. En 1996, il a été fait docteur honoraire en technologie par l'Institut royal de Suède. En 1998, il a reçu le prix Pioneer de l'Electronic Frontier Foundation, en même temps que Linus Torvalds. En 1999 il a reçu le prix créé en mémoire de Yuri Rubinski.

Aujourd'hui, Stallman nous parlera des dangers des brevets logiciels. En fait c'est l'un des aspects les plus importants de la liberté de programmer, parce que cette question de brevets logiciels fait courir à tous les programmeurs le risque d'enfreindre la loi. Ils pourraient en effet, sans le savoir, être en train de violer quelques-uns des brevets détenus par d'autres sociétés.

Conférence de Stallman

Après cette introduction, je suis sûr que beaucoup d'entre vous veulent en savoir plus sur le logiciel libre. Mais malheureusement ce n'est pas de cela que je suis censé parler. En fait, la question que je vais aborder, celle des brevets logiciels, est un peu éloignée de la question du logiciel libre : les brevets logiciels sont un danger pour tous les programmeurs et pour tous les utilisateurs d'ordinateurs. Je m'en suis rendu compte dans mon travail sur le logiciel libre, parce qu'ils sont un danger pour mon projet aussi bien que pour chacun des autres projets de développement logiciel à travers le monde.

« Propriété intellectuelle » est une _expression_ erronée

Il y a une _expression_ malheureuse que vous avez probablement déjà entendue. C'est l'_expression_ « propriété intellectuelle ». D'abord il y a 2 choses qui ne vont pas dans cette _expression_. La première : elle préjuge d'une question politique très importante, à savoir comment traiter telle ou telle catégorie d'idée, de pratique, ou de travail. Elle ne fait pas le détail, elle suppose que toutes seront traitées comme une propriété quelconque. Maintenant, c'est une décision de politique publique et on devrait pouvoir examiner les différentes alternatives et choisir la meilleure. Ce qui veut dire qu'on ne devrait pas désigner l'ensemble du sujet, désigner cette question, par un terme qui préjuge de quelle sorte de réponse on lui donne.

Deuxième problème, encore plus fondamental : ce terme recouvre en fait une collection de lois couvrant des domaines totalement différents tels que le copyright, les brevets, les marques déposées, les secrets de fabrication et encore d'autre choses. Maintenant, ces domaines de la loi n'ont en fait presque rien en commun. Ce qu'elles disent est totalement différent d'une loi à l'autre. Leurs origines sont complètement indépendantes et les questions de politique publique qu'elles soulèvent sont complètement différentes. Aussi, la manière intellligente de les regarder est d'en regarder une seule à la fois ; de les regarder séparément.

Ainsi la manière intelligente d'en parler est de ne jamais faire de généralisation, mais au contraire de parler d'une loi spécifique. Vous voyez ce que je veux dire : parler des copyrights, ou bien parler des brevets, ou bien parler des marques déposées, mais ne jamais les mettre toutes dans un même sac étiqueté « propriété intellectuelle », parce que c'est la meilleure façon d'arriver à des conclusions simplistes. Il est presque impossible de réfléchir intelligemment à la propriété intellectuelle, et je refuse de le faire. Je dis seulement aux gens pourquoi je pense que cette _expression_ est erronée, et ensuite si vous me demandez mon opinion sur les copyrights, ou mon opinion sur les brevets, ça me prendra une heure pour vous la donner. Mais ce sera deux opinions différentes, et mon opinion sur les marques déposées est encore quelque chose de complètement différent.

Copyright et brevet sont deux notions différentes

Donc pour commencer, le plus important pour vous est de ne jamais mélanger le sujet des copyrights avec le sujet des brevets. Ils n'ont rien à faire l'un avec l'autre. Permettez-moi de vous dire quelles sont les différences fondamentales entre les copyrights et les brevets :

• Un copyright s'applique à un travail particulier, la plupart de temps sous forme écrite, et il concerne les détails de ce travail. Les idées en sont complètement exclues. Les brevets, au contraire... Eh bien, un brevet protège une idée. C'est aussi simple que ça. Décrivez-moi n'importe quelle idée... C'est une idée qu'un brevet pourrait vous empêcher de mettre en oeuvre.
  

Ensuite, les copyrights ont à voir avec la copie ; si vous avez écrit quelque chose qui est mot pour mot identique à un certain roman à succès, et que vous puissiez prouver que vous l'avez fait alors que vous étiez enfermé dans une pièce, sans avoir jamais vu ce roman, ce ne serait pas une infraction au copyright parce que ce n'est pas de la copie. Mais un brevet est un monopole absolu sur l'utilisation d'une idée particulière. Même si vous pouvez montrer que vous y avez pensé tout seul, cela ne servirait à rien ; cela ne vous aiderait pas.

Ensuite, la mise sous copyright est automatique. Dès lors que l'on a écrit quelque chose, c'est copyrighté. Les brevets, par contre, sont octroyés à la suite d'un coûteux processus de demande. Il y a une redevance onéreuse, et même des frais supplémentaires pour payer les avocats, ce qui naturellement favorise les grosses sociétés. L'office des brevets dit qu'il n'octroie de brevets que pour les choses non-évidentes. Mais en pratique, dans beaucoup d'offices de brevets, ce critère est non-évident pour une personne ayant un QI de 50. Et ils donnent toutes sortes d'excuses pour ignorer le fait que, lorsqu'un programmeur regarde le brevet, sa première réaction est « c'est absurde, c'est évident ». Ils disent « oh, cela semble évident après coup ». Ainsi ils ont une excuse pour ignorer le jugement de toute personne ayant vraiment des compétences en programmation.

Ensuite, les copyrights sont valables pendant un temps extrêmement long. Aux États-Unis de nos jours, la durée de validité d'un copyright peut aller jusqu'à 150 ans environ, ce qui est absurde. Les brevets, eux, ne durent pas aussi longtemps ; ils durent seulement pendant longtemps - 20 ans, ce qui dans le monde du logiciel est un temps très long, vous l'imaginez bien.
 
Il y a beaucoup d'autres différences. En fait ils diffèrent dans tous les détails.

Aussi la pire chose que vous puissiez jamais faire si vous apprenez quelque chose à propos des copyrights, c'est de supposer que cette chose est vraie pour les brevets. Non, il est plus que probable que ce n'est pas vrai pour les brevets. Si c'est vrai pour les copyrights, ce n'est pas vrai pour les brevets ; voilà un meilleur principe, si vous ne savez pas.

Comment fonctionne le système des brevets

La plupart du temps, les personnes qui décrivent comment fonctionne le système de brevets ont un intérêt personnel dans le système. Et ainsi ils décrivent le système des brevets du point de vue de quelqu'un qui veut obtenir un brevet, pour ensuite le présenter aux programmeurs en leur disant « donnez-moi votre argent ». C'est naturel, vous savez. Ceux qui vendent des billets de loterie parlent des gens qui gagnent, pas de ceux qui perdent. Naturellement, la plupart des gens perdent, mais les vendeurs de billets ne veulent pas que vous pensiez à eux, aussi ils parlent des gens qui gagnent. C'est la même chose avec les brevets.

Le système des brevets est une loterie coûteuse pour les participants. Mais naturellement, les personnes qui gèrent le système veulent que vous pensiez à la petite chance que vous avez de gagner. Aussi, pour rétablir la balance, je vais vous expliquer à quoi ressemble le système des brevets du point de vue d'une personne qui pourrait être victime d'un brevet. C'est-à-dire d'une personne qui veut développer du logiciel. Donc je suppose que vous êtes dans un pays qui a des brevets logiciels. Comment allez-vous vous en sortir avec le système des brevets ?

Eh bien, la première chose que vous devez chercher à savoir, c'est comment les brevets vont affecter votre champ d'activité. C'est une tâche impossible car les projets en cours d'examen par l'office des brevets sont secrets. D'accord, dans certains pays ils sont publiés 18 mois plus tard, mais cela leur laisse encore un temps appréciable pour rester secrets. Ainsi vous pourriez développer un programme cette année, qui serait parfaitement légal et sans danger cette année. Et puis l'année prochaine, un brevet pourrait être accordé et tout d'un coup vous pourriez être poursuivis. Cela arrive. Ou bien vos utilisateurs pourraient être poursuivis.

Par exemple, en 1984 nous avons développé le programme compress, et comme c'était un logiciel libre il a été distribué par beaucoup de sociétés avec les systèmes Unix. Eh bien, en 1985, un brevet a été pris aux États-Unis sur l'algorithme de compression LZW utilisé par compress. Et au bout de quelques années, Unysys a commencé à soutirer de l'argent à diverses sociétés.

Comme nous avions besoin, au projet GNU, d'un algorithme de compression, et puisque nous ne pouvions plus utiliser compress, nous avons commencé à chercher un autre programme de compression. Il s'est trouvé que quelqu'un s'est présenté et nous a dit : « j'ai travaillé sur cet algorithme pendant un an et maintenant j'ai décidé de vous l'offrir. Voici le code ». Nous étions à une semaine de sortir ce programme quand je suis tombé par hasard sur un exemplaire du New-York Times (ce qui ne m'arrive pas très souvent). Il se trouve qu'il contenait la rubrique hebdomadaire des brevets, que je l'ai remarquée, et que je l'ai lue. Elle disait que quelqu'un avait obtenu un brevet pour l'invention d'une nouvelle méthode, une meilleure méthode de compression. (Bon, ce n'était pas vraiment le cas.)

Quand j'ai vu cela, j'ai pensé que nous ferions mieux de nous procurer une copie du brevet et de voir si c'était un problème. Et... il couvrait exactement l'algorithme que nous étions sur le point de publier. Ainsi ce programme a été tué une semaine avant sa sortie. Et en fait, la méthode que cette personne (le détenteur du brevet) avait inventée n'était pas meilleure, parce qu'elle n'était pas nouvelle. Mais cela n'a pas d'importance, il en avait le monopole.

Puis finalement nous avons trouvé un autre algorithme de compression qui est utilisé dans le programme connu sous le nom de GISA. Mais ceci illustre le danger auquel vous êtes confrontés : même si vous aviez des moyens illimitées, vous ne pourriez pas vous renseigner sur tous les brevets susceptibles de mettre en danger votre projet. Mais vous pouvez vous renseigner sur les brevets déjà accordés parce qu'ils sont publiés par l'office des brevets. Donc en principe yous pourriez tous les lire, et voir lesquelles restreignent votre activité. En pratique, cependant, à partir du moment où il existe des brevets logiciels, il y en a tant que vous ne pouvez pas soutenir le rythme.

Aux États-Unis il y en a plus de cent mille, peut-être deux cent mille. C'est juste une estimation. Je sais qu'il y a 10 ans ils en accordaient 10.000 par an et je suppose que le rythme s'est accéléré depuis. C'est trop pour que vous puissiez vous tenir au courant, sauf si c'est votre métier. Ce que vous pouvez faire, c'est rechercher ceux qui ont rapport avec ce que vous faites ; cela marche quelquefois. Si vous faites des recherches par mot-clé ou suivez des liens, vous trouverez des brevets qui se rapportent à ce que vous faites, mais vous ne les trouverez pas tous.

Il y a quelques années, quelqu'un avait un brevet aux États-Unis - peut-être le brevet a-t-il expiré depuis - sur le recalcul en ordre naturel dans les tableurs. Maintenant, qu'est-ce que ça veut dire ? Cela veut dire que les tableurs, à l'origine, calculaient toujours les cellules de bas en haut. Ce qui veut dire que si une cellule dépendait d'une cellule d'indice inférieur [(n.d.t.) placée plus haut dans la feuille de calcul], elle n'était pas prise en compte au premier calcul. Vous deviez faire le calcul à nouveau pour la prendre en compte. C'est clair qu'il vaut mieux faire les calculs dans le bon sens, voyez-vous. Si A dépend de B, alors calculez B d'abord, puis calculez A. De cette façon un seul calcul fera tout coller.

Eh bien, c'est ce que ce brevet couvrait. Si vous aviez fait une recherche sur le mot « tableur », vous n'auriez pas trouvé ce brevet parce que le mot n'y figurait pas. La phrase « recalcul en ordre naturel » n'y figurait pas non plus. C'est l'algorithme que le brevet couvrait, c'est-à-dire essentiellement tous les moyens imaginables de le coder. Cet algorithme est appelé tri topologique, et ce terme n'apparaissait pas non plus dans le brevet. Le brevet était présenté comme se rapportant à une technique de compilation. Ainsi une recherche raisonnable n'aurait pas trouvé ce brevet. De ce fait, vous auriez pu être poursuivi.

En réalité vous ne pouvez pas savoir, même approximativement, ce qui est couvert par un brevet, à moins de l'étudier soigneusement. C'est différent pour les brevets couvrant d'autres domaines, parce que dans d'autres domaines quelque chose de physique se produit, et les détails de cette chose physique vous donnent un moyen de savoir à peu près si le brevet concerne votre projet, ou non. Mais dans le logiciel, il n'y a rien de tel. Ainsi il arrive facilement que deux descriptions totalement différentes recouvrent, en fait, le même calcul. Il faut les étudier en détail pour s'en rendre compte. A cause de cela, même l'office des brevets ne peut pas suivre. Ainsi il n'y a pas un, mais deux brevets sur la compression de données LZW. Le premier a été attribué en 1984 et le second, je pense, en 1989, mais celui-là avait été demandé encore plus tôt. Un de ces brevets appartient à Unisys et l'autre à IBM.

En fait, ce type d'erreur n'est pas si rare. Celle dont je vous ai parlée n'est pas unique, voyez-vous. Les personnes qui examinent les demandes de brevets n'ont pas beaucoup de temps à consacrer à chaque brevet ; aux États-Unis, ils ont en moyenne 17 heures. Ce n'est pas suffisant pour étudier en détail tous les autres brevets du même domaine d'activité, pour savoir si vraiment il n'y en aurait pas un qui décrit la même chose. C'est pourquoi ils répéteront ces erreurs indéfiniment. Au final, vous ne trouverez pas tous les brevets qui pourraient vous menacer. Mais vous avez tout de même une chance d'en trouver quelques-uns.

Il faut demander conseil à un avocat

Maintenant qu'est-ce que vous faites ? Vous devez essayer de découvrir précisément ce que ces brevets couvrent. C'est très difficile parce qu'ils sont écrits dans un langage juridique tortueux qui est très difficile à comprendre pour des ingénieurs. Il va vous falloir y travailler avec un avocat.

Dans les années 80, le gouvernement australien a commandé une étude sur le système des brevets ; le système des brevets en général, pas seulement les brevets logiciels. Cette étude concluait que l'Australie ferait mieux d'abolir ce système parce qu'il rendait très peu service à la société et causait pas mal d'ennuis. La seule raison pour laquelle les auteurs ne recommandaient pas de le faire était la pression internationale. Parmi les motifs de leur conclusion, il y avait le fait que les brevets, pourtant censés divulguer l'information pour qu'elle ne reste pas secrète, n'atteignaient pas leur but. Les ingénieurs ne lisent jamais les brevets pour apprendre quoi que ce soit parce qu'ils sont trop difficiles à lire. Le rapport citait par exemple un ingénieur qui disait : « je n'arrive pas reconnaître mes propres inventions dans les brevets ».

Il y a quelques années aux États-Unis un ingénieur nommé Paul Heckel a poursuivi Apple. Il avait pris deux brevets logiciels à la fin des années 80 pour un ensemble de logiciels. Quand il a vu sortir le brevet d'hypercard, il l'a regardé de près et a dit : « cela ne ressemble pas à mon programme ». Il n'y a plus pensé, mais plus tard son avocat lui a expliqué qu'en lisant le brevet d'hypercard avec attention, on constatait qu'hypercard tombait dans le domaine réservé de son brevet. Donc il a poursuivi Apple, pensant que ce serait peut-être l'occasion de gagner un peu d'argent. Eh bien, alors que je donnais une conférence comme celle-ci, il était dans la salle et a dit : « oh, ce n'est pas vrai, c'est seulement que je ne savais pas jusqu'où mon invention était protégée ». Et j'ai répondu : « oui, c'est ce que je viens de dire ».

Ainsi, vous allez devoir passer beaucoup de temps à travailler avec un avocat, à lui expliquer sur quels projets vous travaillez pour que l'avocat puisse vous dire quels brevets ils emploient. Cela va coûter cher. Et quand vous aurez fini, l'avocat vous dira : « si vous faites quelque chose dans ce domaine-ci, vous êtes presque sûr d'avoir un procès ; si vous faites quelque chose dans ce domaine-là, vous êtes considérablement en danger et si vous voulez être en sécurité vous feriez mieux d'en rester à l'écart ; et naturellement il y a un facteur chance considérable dans tout procès ».

Les stratégies en matière de brevet

Maintenant que vous avez un terrain prévisible pour mener vos affaires, qu'est-ce que vous faites ?
Vous devez envisager trois possibilités :

• essayer de contourner le brevet ;
• essayer d'en obtenir une licence d'exploitation ;
• essayer d'en contester la validité devant les tribunaux.

Chacune de ces options est quelquefois une alternative viable, d'autres fois elle ne l'est pas.