Les déviances que tu cites ne viennent pas du fait que l'on puisse breveter une idée, mais du fait que les critères fondamentaux ne sont pas définissables.
A partir de là je peux considérer que je suis le premier qui utilise l'algorithme de Bresenham pour le tracé de droite à l'envers et déposer un brevet dessus. Je peux considérer que les hommes du métiers sont les mathématiciens de haut vol dans leur université, et dans ce cas mon implémentation en Python sur OpenGL n'aura probablement rien d'évident ou de trivial pour eux. D'un autre coté il est facile de démontrer que mon brevet n'apporte rien et n'a pas lieu d'être.
Le véritable ennui est qu'un juge non technicien ne va pas pouvoir trancher entre les différents points de vue lequel est juste. Et pour cause aucun des deux ne l'est. La notion de même de brevetabilité n'est pas applicable, et il est aussi absurde de chercher à démontrer la brevetabilité d'un logiciel que sa non brevetabilité. Et c'est cette absence de garde fou qui rend le brevet logiciel dangereux, parceque sans cette barrière il peut arriver tout et n'importe quoi.
Mais le but de mon postes n'était pas tant de mettre en évidence le vrai problème des brevets logiciel, que d'attirer l'attention des gens sur le fait que les exemples qu'ils donnent ne sont pas bons. Que ce soit une machine, un algorithme mathématique pur, une norme internationale, une facon de percer des trous dans un mur etc. la démonstration de brevetabilité ou de la non brevetabilité est généralement très rapide en elle même. Le seul point qui pose problème sur un brevet classique est la recherche d'antériorité.
[^] # Re: Il va falloir arreter les anneries très vite.
Posté par Jerome Herman . En réponse à la dépêche Lettre du président de la FSF Europe à l'EICTA au sujet des brevets logiciels. Évalué à 2.
A partir de là je peux considérer que je suis le premier qui utilise l'algorithme de Bresenham pour le tracé de droite à l'envers et déposer un brevet dessus. Je peux considérer que les hommes du métiers sont les mathématiciens de haut vol dans leur université, et dans ce cas mon implémentation en Python sur OpenGL n'aura probablement rien d'évident ou de trivial pour eux. D'un autre coté il est facile de démontrer que mon brevet n'apporte rien et n'a pas lieu d'être.
Le véritable ennui est qu'un juge non technicien ne va pas pouvoir trancher entre les différents points de vue lequel est juste. Et pour cause aucun des deux ne l'est. La notion de même de brevetabilité n'est pas applicable, et il est aussi absurde de chercher à démontrer la brevetabilité d'un logiciel que sa non brevetabilité. Et c'est cette absence de garde fou qui rend le brevet logiciel dangereux, parceque sans cette barrière il peut arriver tout et n'importe quoi.
Mais le but de mon postes n'était pas tant de mettre en évidence le vrai problème des brevets logiciel, que d'attirer l'attention des gens sur le fait que les exemples qu'ils donnent ne sont pas bons. Que ce soit une machine, un algorithme mathématique pur, une norme internationale, une facon de percer des trous dans un mur etc. la démonstration de brevetabilité ou de la non brevetabilité est généralement très rapide en elle même. Le seul point qui pose problème sur un brevet classique est la recherche d'antériorité.