Software patents are the lightning rod issue of the moment in free software, because they pose the only
   real threat against which the free software community cannot defend itself. Copyright and trademark
   problems can always be gotten around. If part of your code looks like it may infringe on someone else's
   copyright, you can just rewrite that part. If it turns out someone has a trademark on your project's name,
   at the very worst you can just rename the project. Although changing names would be a temporary in-
   convenience, it wouldn't matter in the long run, since the code itself would still do what it always did.
   But a patent is a blanket injunction against implementing a certain idea. It doesn't matter who writes the
   code, nor even what programming language is used. Once someone has accused a free software project
   of infringing a patent, the project must either stop implementing that particular feature, or face an ex-
   pensive and time-consuming lawsuit. Since the instigators of such lawsuits are usually corporations with
   deep pockets—that's who has the resources and inclination to acquire patents in the first place—most
   free software projects cannot afford the latter possibility, and must capitulate immediately even if they
   think it highly likely that the patent would be unenforceable in court. To avoid getting into such a situ-
   ation in the first place, free software projects are starting to code defensively, avoiding patented al-
   gorithms in advance even when they are the best or only available solution to a programming
   problem.22
   Surveys and anecdotal evidence show that not only the vast majority of Open Source programmers, but a
   majority of all programmers, think that software patents should be abolished entirely.23 Open source
   programmers tend to feel particularly strongly about it, and may refuse to work on projects that are too
   closely associated with the collection or enforcement of software patents. If your organization collects
   software patents, then make it clear, in a public and irrevocable way, that the patents would never be en-
   forced on Open Source projects, and that they are only to be used as a defense in case some other party
   initiates an infringement suit against your organization. This is not only the right thing to do, it's also
   good Open Source public relations.
   Unfortunately, collecting patents for defensive purposes is a rational action. The current patent system,
   at least in the United States, is by its nature an arms race: if your competitors have acquired a lot of pat-
   ents, then your best defense is to acquire a lot of patents yourself, so that if you're ever hit with a patent
   infringement suit you can respond with a similar threat—then the two parties usually sit down and work
   out a cross-licensing deal so that neither of them has to pay anything, except to their intellectual property
   lawyers of course.
   The harm done to free software by software patents is more insidious than just direct threats to code de-
   velopment, however. Software patents encourage an atmosphere of secrecy among firmware designers,
   who justifiably worry that by publishing details of their interfaces they will be giving technical help to
   competitors seeking to slap them with patent infringement suits. This is not just a theoretical danger; it
   has apparently been happening for a long time in the video card industry, for example. Many video card
   manufacturers are reluctant to release the detailed programming specifications needed to produce high-
   performance Open Source drivers for their cards, thus making it impossible for free operating systems to
   support those cards to their full potential. Why would the manufacturers do this? It doesn't make sense
   for them to work against software support; after all, compatibility with more operating systems can only
   mean more card sales. But it turns out that, behind the design room door, these shops are all violating
   one another's patents, sometimes knowingly and sometimes accidentally. The patents are so unpredict-
   able and so potentially broad that no card manufacturer can ever be certain it's safe, even after doing a
   patent search. Thus, manufacturers dare not publish their full interface specifications, since that would
   make it much easier for competitors to figure out whether any patents are being infringed. (Of course,
   the nature of this situation is such that you will not find a written admission from a primary source that it
   is going on; I learned it through a personal communication.)
   Some free software licenses have special clauses to combat, or at least discourage, software patents. The
   22
      Sun Microsystems and IBM have also made at least a gesture at the problem from the other direction, by freeing large numbers
   of software patents—1600 and 500 respectively—for use by the Open Source community. I am not a lawyer and thus can't evaluate
   the real utility of these grants, but even if they are all important patents, and the terms of the grants make them truly free for use by
   any Open Source project, it would still be only a drop in the bucket.
   23
      See http://lpf.ai.mit.edu/Whatsnew/survey.html for one such survey.

   7. If, as a consequence of a court judgement or allegation of patent

Les brevets logiciels sont LE sujet délicat du moment pour les logiciels libres car ils représentent la seule vraie menace contre laquelle la communauté du logiciel libre ne peut pas se défendre. On peut toujours contourner les problèmes de droit d'auteur et de marque. Si une partie de votre code semble empiéter sur les droits d'auteur de quelqu'un il n'y a qu'à la ré-écrire. S'il se trouve que quelqu'un a déjà les droits sur le nom de votre projet, dans le pire des cas vous pouvez toujours changer le nom du projet. Même si cela est un désagrément temporaire, à long terme ça n'a pas d'importance puisque le code en lui-même accomplit toujours ce qu'il a toujours accompli. Mais un brevet vous interdit purement et simplement d'implémenter une idée précise. La manière d'écrire le code ou même la langage utilisé importent peu, dès que quelqu'un accuse un projet de logiciel libre de violer un brevet, le projet doit soit arrêter d'utiliser cette fonctionnalité particulière soit faire face à un procès coûteux en temps et en argent. Puisqu'en général ces procès sont intentés par des firmes aux poches bien remplies, ce sont celles qui ont les ressources et qui tendent à acheter les brevets, les projets de logiciel libre ne peuvent pas se permettre cette dernière solution et doivent immédiatement capituler même s'ils pensent qu'il y a peu de chance que le brevet soit défendable devant un tribunal. Pour tout simplement éviter de se retrouver dans cette situation les projets de logiciels libres se mettent à coder défensivement en évitant les algorithmes brevetés, même s'ils représentent la meilleure voire la seule solution possible à un problème de programmation.[22]

Des sondages ainsi que des preuves anecdotiques montrent que non seulement une vaste majorité des programmeurs Open Source, mais aussi une vaste majorité de tous les programmeurs pensent que les brevets logiciels devraient être abolis purement et simplement.[23] Les programmeurs Open Source les voient d'un très mauvais œil et parfois refusent de travailler sur des projets qui naviguent dans les eaux troubles de la collecte ou de la mise en application des brevets logiciels. Si votre organisation amasse des brevets logiciels, annoncez publiquement, clairement et de manière irrévocable que ces brevets ne seront jamais employés contre un projet Open Source et qu'ils ne seront utilisés qu'à des fins défensives au cas où une tierce partie lancerait une action en justice pour violation de brevet contre votre organisation. Ce n'est pas seulement votre unique alternative, c'est aussi un exemple de bonne communication dans le monde de l'Open Source.

Malheureusement, la collecte de brevets à des fins défensives est une action rationnelle. Le système de brevets actuel, au moins aux États-Unis, est de part sa nature une course à l'armement : si vos adversaires ont acquis de nombreux brevets, alors votre meilleure défense est d'en acquérir beaucoup à votre tour, ainsi, si l'on vous attaque pour violation de brevet, vous pouvez répondre part la même menace et par conséquent les deux parties en question se réuniront à la table des négociations et s'entendront sur un accord de licence croisée, ainsi, personne n'a rien à payer, sauf aux avocats spécialisés en propriété industrielle bien sûr.

Les dommages causés aux logiciels libres par les brevets logiciels sont plus insidieux que la simple menace sur le développement de code. Les brevets logiciels encouragent au secret chez les développeurs de firmware qui craignent, à juste titre, que s'ils publient les détails de leur interface ils fourniront une aide technique à leurs adversaires qui ne cherchent qu'à les attaquer pour violation de brevet logiciel. Ce n'est pas qu'un danger purement théorique, il semble que ça se soit produit pendant un certain temps dans l'industrie des cartes graphiques par exemple. Beaucoup de fabricants de cartes graphiques sont réticents à l'idée de publier les spécifications détaillées de leurs programmes qui sont pourtant nécessaires à la production de pilotes Open Source de très bonne qualité pour leur matériel, rendant de ce fait impossible le support de ces cartes à leur plein potentiel par les systèmes d'exploitation libres. Pourquoi les fabricants feraient-ils cela ? Il n'y a pas de raison pour qu'ils empêchent le support technique de leurs produits, après tout, si leurs cartes sont compatibles avec plus de systèmes d'exploitation cela ne peut que se traduire en une augmentation des ventes. La véritable raison est que derrière la porte de la salle de fabrication, ces vendeurs ne font que violer les brevets de leurs concurrents, parfois sciemment, parfois par accident. Les brevets sont si imprévisibles et potentiellement si vastes qu'aucun fabriquant de carte ne peut jamais être sûr de ne violer aucun brevet logiciel, même après avoir fait une recherche. Par conséquent les producteurs n'osent pas publier les spécifications complètes de leur interface puisque cela aiderait leurs concurrents à déterminer si certains de leurs brevets sont violés (évidemment, de par la nature de la situation vous ne trouverez aucun témoignage écrit d'une source sure vous confirmant cela, je l'ai appris grâce à un contact personnel).

Certaines licences de logiciel libre possèdent des clauses particulières pour combattre ou au moins décourager les brevets logiciels.

La GNU/GPL, par exemple, dit ceci :

7. Si, en conséquence d'un jugement du tribunal ou d'allégations de violation de brevet ou pour toute autre raison (pas nécessairement liée aux brevets), des restrictions vous sont imposées (que ce soit par ordre du tribunal, accord ou pour toute autre raison) qui contredisent les conditions de cette Licence, elles ne vous excusent pas des conditions de cette Licence. Si vous ne pouvez pas distribuer le Logiciel en conciliant vos obligations liées à cette Licence et toutes autres obligations pertinentes, alors, en conséquence, vous ne pourrez plus distribuer le Logiciel du tout. Par exemple, si une licence de brevet ne vous autorisait pas une redistribution libre de droits du Programme par tous ceux qui en reçoive une copie directement ou indirectement par vous, alors le seul moyen de satisfaire à cette obligation et aux obligations de la Licence serait de cesser la distribution du programme complètement.
    [...]
Le but de cette section n'est pas de vous amener à violer un brevet ou tout autre droit de propriété ou de contester la validité d'une telle revendication, le seul et unique objet de cette partie est de protéger l'intégrité des systèmes de distribution de logiciels libres qui sont mis en application par cette licence publique. De nombreuses personnes ont fait de généreuses donations à la grande variété de logiciels distribués par ce système avec confiance en l'application constante de ce système. Il revient à l'auteur/au donateur de décider s'il ou elle désire distribuer le logiciel par un autre système et une licence ne peut pas imposer ce choix.

La Licence Apache, dans sa version 2.0 (http://www.apache.org/licenses/LICENSE-2.0) contient également des pré-requis contre les brevets. En premier, elle stipule que toute personne distribuant le code sous cette licence doit y inclure implicitement une licence de brevet sans redevance pour tout brevet qu'elle pourrait détenir et qui pourrait s'appliquer au code. En deuxième, ce qui est plus ingénieux encore, elle punit quiconque initierai un procès pour violation de brevet sur le travail couvert en rompant automatiquement la licence de brevet implicite dès le moment où une telle revendication est faite :

3. Attribution d'une licence de brevet. Soumis aux termes et conditions de cette licence, chaque Participant, par la présente, Vous accorde un droit d'exploitation de brevet impérissable, universel, non-exclusif, sans frais, sans redevance, irrévocable (à l'exception des conditions décrites dans cette section) pour l'usage présent et passé, l'utilisation, la proposition à la vente, la vente, l'import et pour tout transfert de l'&Oelig;uvre. Cette licence ne vaut que pour les revendications de brevet que le participant peut licencier et qui sont nécessairement violées par leur(s) Contribution(s) seule(s) ou par une combinaison de leur(s) Contribution(s) et de l'&Oelig;uvre à laquelle une (des)telle(s) Contribution(s) a (ont) été soumise(s). Si vous établissez un contentieux contre une tierce partie (demande entre défenseurs ou demande reconventionnelle dans un procès comprises) alléguant que l'&Oelig;uvre ou qu'une Contribution incluse dans l'&Oelig;uvre constitue une violation directe ou contributive de toute licence de brevet Vous ayant été attribuée par les termes de cette Licence pour cette &Oelig;uvre deviendraient nulles à la date où ce contentieux est enregistré.

Bien qu'il soit important, à la fois légalement et politiquement, de construire une défense contre les brevets dans les licences logiciels libres de cette manière, au final ces mesures ne suffiront pas à repousser la menace que font peser les procès sur les logiciels libres. Seuls des modifications dans les textes ou dans leur interprétation des lois internationales sur les brevets pourront accomplir cela. Pour en savoir plus sur les brevets logiciels et comment ils sont combattus rendez-vous sur http://nosoftwarepatents.com/. L'article de Wikipedia (http://fr.wikipedia.org/wiki/Brevet_logiciel) contient également beaucoup d'informations utiles sur les brevets logiciels.

[22] Sun Microsystems et IBM ont aussi fait au moins un geste pour régler le problème du point de vu opposé en libérant un grand nombre de brevets logiciels, 1600 et 500 respectivement, pour que la communauté Open Source puisse en profiter. Je ne suis pas avocat et par conséquent je ne saurai évaluer la porté de ces dons, mais même si ce sont tous des brevets importants et que les termes de cette libération les rendent vraiment libres d'utilisation par n'importe quel projet Open Source, ça resterait toujours une goutte d'eau dans l'océan.

[23] Voir http://lpf.ai.mit.edu/Whatsnew/survey.html pour obtenir un exemple d'un de ces sondages.