30 décembre 2004

White paper contre les brevets logiciels

ObjetctWeb propose un mémo sur les brevets logiciels : les problèmes que ça pose, pourquoi il faut l'éviter.

http://wiki.objectweb.org/Wiki.jsp?page=CWP_SoftwarePatents_French

D'abord, ils expliquent que le brevet n'est pas forcément une chose mauvaise, intrinsèquement. Si cela apporte des bénéfices à la communauté, pourquoi pas. (c'est donc bon pour des domaines techniques, concrets).

Mais ils mettent en cause les brevets pour les idées, les algorithmes, les structures de données en programmation. D'une part ce n'est pas concret, ça bloque l'innovation, et le temps pour passer au domaine publique ne devrait pas être le même que pour les autres domaines, puisque tout bouge plus vite en informatique.

Je quote 2 paragraphes importants.

Le 1er qui décrit comment ça se passe aux EU *avec* les logiciels brevetables :
Le Parlement Européen a récemment confirmé que le logiciel en tant que tel doit demeurer hors du champ du brevetable. Force est de constater qu'outre-Atlantique, la possibilité d'obtenir des brevets de logiciels a surtout des effets négatifs, de plus en plus décriés.

L'analyse économique montre que 10% des budgets de la R&D sont maintenant capturés par les problèmes juridiques. Par ailleurs, on voit apparaître de plus en plus de « racket au brevet », typiquement contre des PME qui préfèreront payer de petites sommes plutôt que d'aller à un contentieux plus coûteux.

La récente affaire Eolas contre Microsoft, où Eolas prétend détenir des droits sur des mécanismes fondamentaux du web, est aussi caractéristique que scandaleuse. C'est une excellente illustration d'un abus courant qui consiste à déposer les brevets discrètement, laisser les tiers utiliser indépendamment les même techniques, et clamer ses droits une fois le travail de popularisation achevé par d'autres.

Cette pratique, manifestement de mauvaise foi, est possible car le degré d'innovation réelle dans les brevets obtenus ne cesse de décroître. Il faut donc craindre l'apparition de systèmes quasi mafieux où la tranquillité judiciaire des petites entreprises serait achetée à des gros bonnets de la propriété intellectuelle.

Le 2ème qui montre le problème institutionnel Européen, car il y a un réel combat de 2 organisations, le Parlement Européen, résolument anti-brevet, et l'Office Européen des Brevets, qui lui suit les désirs des grosses boites, cad des brevets à gogo.

Face à ces constats, il faut s'étonner et s'inquiéter de l'activité de l'Office Européen des Brevets. Au mépris des lois existantes, l'OEB cède au mercantilisme et prône la brevetabilité sans limite. Dans une approche marchande, l'OEB ne rencontre que des industriels soucieux d'obtenir des brevets. L'opinion d'autres acteurs d'avis contrastés semble purement ignorée par l'Office.

Mais l'OEB ne devrait pas être au service de ses « clients », acheteurs de brevets, mais au service de l'économie européenne. A ce titre, il est très surprenant que l'OEB ait fait évoluer sa jurisprudence sans procéder à aucune étude économique (du moins qui ait été rendue publique) sur l'opportunité d'une telle évolution.


Voila, je suis resté assez longtemps loin de ce pb, me disant ça ne me concerne pas, mais je crois que toute personne qui touchent de près ou de loin à l'informatique doit se sentir concerné...

29 décembre 2004

Retour vers le futur

Je crois que j'ai trouvé mon langage idéal : en gros, imaginez Java avec une syntaxe améliorée, plus souple et plus pratique, et vous aurez une idée de ce qu'est Groovy (http://groovy.codehaus.org).

Ses caractéristiques marquantes :
  • Groovy est un langage interprété, donc il est rapide à écrire et à tester
  • il peut être compilé et donc gagner en performance.
  • il s'interface facilement avec du code Java, et réciproquement.
  • il peut utiliser n'importe quelle classe Java (même du Swing!).
  • Bref, on peut imaginer que ce code serve de prototypage, masi jamais si votre code vous satisfait, que les performances sont correctes, vous pouvez purement et simplement l'utilisez dans le reste de votre application Java.

    Sa principale caractéristique est la closure : ça ressemble à une inner classe java anonyme, mais cela peut se définir au moment même de son application.

    ex :
value = [1, 2, 3].collect { it * 2 }
assert value == [2, 4, 6]
      (à noter que si la notion est aussi pratique qu'on peut le croire ce principe des closures et aussi possible avec Java, grâche aux API de Jakarta Commons Functor)
    • un plugin Eclipse est disponible (pour Eclipse 3 malheureusement pour moi, qui doit rester avec Eclipse 2 pour des questions de compatibilités avec d'autres plugins...)
    • Une JSR envoyé au JCP demande à ce que Groovy fasse partie de Java standard :-)

    Le principal point négatif, c'est que le produit n'est pas encore finalisée...
    Je n'ai pas réussi à le faire fonctionner avec l'utilitaire groovyconsole (qui est le même genre que l'éditeur IDLE de Python), mais seulement en configurant Ultraedit. (mais bon, si ça marche bien avec Eclipse 3, ça n'est pas rédhibitoire).

    L'auteur donne d'ailleurs une bonne idée pour commencer à utiliser Groovy : l'établissement des tests JUnit pour votre dernière appli Java!

    Liens :