L'extrapolation qui me semble plus pertinente est:
Pendant 5 ans, Microsoft pousse SuSE en avant pour mettre celui-ci en situation dominante dans le monde Linux.
Après 5 ans, à la fin de l'accord, Microsoft négocie un nouvel accord qui lui donne plus de pouvoir sur la communauté Linux.
...
Ce qui est sûr, c'est qu'on est en droit de suspecter Microsoft de vouloir transformer SuSE en cheval de Troie pour contrôler la vague Linux. Et à ce titre, il y a lieu de se méfier de Novell et des technologies posant problème comme Mono et de ne pas mettre tous ses oeufs dans le même panier.
Je ne dis pas de jeter tout ce qui vient de Novell à la poubelle, mais de bien considérer le risque de voir Microsoft sonner la fin de la récré d'ici 5 ans.
"We addressed the proprietary issues through the net up-front payment. The open-source we addressed through the percentage of revenue."
et sur le site de Novell, on voit bien
As part of this agreement, Microsoft will provide a covenant not to assert its patent rights against customers who have purchased SUSE Linux Enterprise Server or other covered products from Novell,
Comment prétendre ne pas reconnaître la présence de code portant atteinte à la propriété intellectuelle et signer un accord dont un des points porte justement sur un accord de non-agression sur le code portant atteinte à la propriété intellectuelle de Microsoft?
On peut en tout cas parler de double langage de la part de Novell selon qu'il s'adresse aux entreprises ou à la communauté libre. De là à dire que Novell prend les développeurs de logiciel libre pour des cons.
Je ne te suis pas là. Quelle importance qu'elle gère tout le protocole si elle s'occupe des calculs crypto?
Soit elle gère la connexion du début à la fin et aucune clef ne passe en clair dans la ram, soit elle ne la gère pas, et il y a forcément un moment où le software prend le relais pour réalimenter les différentes fonctions de la puce tpm afin de l'utiliser dans le processus de cryptage.
Si la puce ne gère pas la session complètement, il y aura forcément un moment où il faudra, par exemple, récupérer le résultat d'une fonction de la puce , le traiter en soft, et le réinjecter dans une autre fonction, ce qui implique un passage par la ram.
J'ignore comment, dans les faits, une puce TPM gère ça
Idem, je ne vois pas comment cette puce pourrait gérer ça, et je ne trouve aucune littérature sur le sujet. Je ne vois donc pas comment prétendre qu'elle le fait.
Le point positif, si le tpm supporte l'algorithme symétrique utilisé lors d'une session, c'est qu'effectivement les attaques de timing ne pourront être utilisées pour faire des statistiques sur la prédiction de branche du cpu puisque les opérations se dérouleront sur un autre cpu, c-à-d la puce tpm. Mais les clefs transitant à l'occasion en ram (sauf preuve du contraire), il y aura toujours d'autres attaques possibles si la machine est déjà compromise au point de faire tourner un outil permettant de faire l'attaque sur la prédiction de branche.
Enfin, qui dit qu'on ne va pas trouver des exploits sur les puces TPM, et si cela se produit, comment y remédier?
Cela pourra-t-il être utilisé sur les serveurs web mutualisés ?
vu que cela requiert un logiciel tournant localement pour faire l'attaque sur la prédiction de branche, c'est à peu près le seul cas de figure où je vois un vrai risque. Ce n'est pas une attaque pouvant être lancée à distance.
Le problème est qu'une puce TPM n'est pas équipée ni conçue pour négocier une session SSL, et que de ce fait, même si elle peut être utilisée pour faire des opérations de cryptage intervenant dans le SSL, elle n'est pas capable de gérer tout le protocole.
Mettre les clefs de cryptage SSL dans la puce et seulement dans la puce est donc une énormité. Au final, même si on met la clef dans la puce, elle sera aussi présente en ram, ce qui la rendra toujours vulnérable à certaines attaques.
Au final, de toutes façons, ce bug est plutôt improbable, à part chez les gens qui installent n'importe-quoi sur leurs machines ou les serveurs web partagés où un webmaster peu scrupuleux essayerait d'espionner le voisin.
Le truc aussi, c'est que ces systèmes n'implémentent pas tous les algorithmes.
Des outils comme le PadLock de VIA accélèrent certaines fonctionnalités, mais les clefs passent en ram et une partie des traitements doit être effectuée par le cpu.
Par contre, question accélération, le padlock accompagné d'un "bête" VIA eden à 1ghz écrase par un facteur ~16 un P4 2,4ghz pour l'AES-256.
Euh, non. L'intérêt de la puce TPM c'est qu'elle fait elle-même tous les calculs cryptographiques
La puce TPM fait les calculs cryptographiques, mais seulement ceux nécessaires au TCPA.
Avec une puce TPM les clés cryptographiques ne sont jamais en RAM!
Faudrait te renseigner sur la manière de gérer les clefs dans le TPM, les clefs qui sont accessibles et celles qui ne le sont pas.
Dans le cas ou les clefs ne seraient pas accessibles aux applications, elles n'auraient de toutes façons aucun intéret à moins que la puce n'intègre tous les protocoles de crypto nécessaires aux opérations (et le SSL/TLS est plutôt spécialisé et complexe) et soit capable de faire du traitement de flux avec une vitesse suffisante.
Par contre, il existe de vrais accélérateurs SST/TLS hardware, qui eux ont une utilité réelle pour les serveurs.
Une fois ta clef générée par le TPM, il faut tout de même qu'elle soit consultable par les logiciels de crypto... et une fois qu'elle est en ram, le risque est exactement pareil que sans TPM...
Le TPM ne sauve pas pour ce genre de situation. Le problème n'est pas la génération de la clef mais bien sa présence en ram.
Tiens, tant qu'on y est. Une autre technique impressionante, qui ressemble à celle dont parle l'article du monde : les processeurs à double coeur isolent au mieux les processeurs exécutés en parallèle (ex: un "core duo" exécute deux programmes à la fois). Mais un chercheur a montré qu'il y a des fuites d'information, (je me souviens plus bien, genre) pouvoir compter le nombre de faute de page. Une taupe peut donc exploiter cette faiblesse pour sniffer les bits d'une clé RSA.
Il me semble que ça ne marche que sur les processeurs à cache partagée (core2 duo), ou les systèmes avec hyperthreading. Si tu utilises des processeurs à cache séparée (p-ex, AMD64) , ces timing attacks doivent être beaucoup plus difficiles.
Au final le problème de ce bug, comme beaucoup d'autres du même genre, c'est le contrôle de ce qui tourne et de ce qui ne tourne pas sur la machine. Si un serveur se fait injecter un programme qui fait des timing attacks, c'est qu'il y a un problème de sécurité déjà ailleurs.
je ne sais pas pourquoi on a moinssé ce post sans argumenter, mais il s'agit d'une réalité dans le monde de l'entreprise: qui dit moins de contacts dit moins de contrats, et qui dit moins de contrats dit contrats plus gros, et donc possibilité d'avoir des prix plus intéressants.
Cela évite aussi que les fournisseurs se revoient trop la balle si il n'y a qu'un seul fournisseur concerné par un domaine.
MS n'attaquera pas les clients de Suse qui utiliseraient un software provenant de Suse et qui violerait l'un de leur brevet, et réciproquement
A la lumière des propos de Steve Ballmer, on peut dire que cela pue pour les autres initiatives commerciales basées sur linux:
"Let me be clear about one thing, we don't license our intellectual property to Linux because of the way Linux licensing GPL framework works, that's not really a possibility,"
"This does not apply to any forms of Linux other than Novell's SUSE Linux. And if people want to have peace and interoperability, they'll look at Novell's SUSE Linux. If they make other choices, they have all of the compliance and intellectual property issues that are associated with that."
Et voilà... déjà des menaces...
Grâce à Novell, on va se retrouver avec un monde linux vraiment à deux vitesses, et l'interopérabilité avec Windows deviendra un monopole de Novell.
En s'associant au géant de Redmond, est-ce que Novell n'a pas vendu son âme au diable ?
Difficile à dire... SCO prétend avoir déjà acheté l'âme de Novell...
Maintenant, le risque est de voir SuSE remplacer RedHat et les autres dans les entreprises qui sont aussi clientes de Microsoft, et de voir une forme de petit monopole Linux émerger par la force commerciale et la menace des brevets Microsoft.
On verrait bien une déclaration du genre "Moi je suis copain avec Microsoft, j'ai le droit d'utiliser ses brevets. Vous n'avez pas le droit d'utiliser ses brevets, mon copain va vous casser la gueule".
L'attitude de Novell d'utiliser des technologies pour lesquelles IL a la license et pas l'ensemble de la communauté est en tout cas peu en phase avec l'esprit du logiciel libre, et vraissemblablement en contradiction avec la GPL.
Au niveau entreprise, ça risque de ne pas faire de bien à RedHat...
Après le coup infligé à RedHat par Oracle (et amplifiée par l'attitude d'HP et d'autres vendeurs) ces derniers jours et qui a provoqué une chute de l'action, c'était le moment idéal pour SuSE pour asséner un coup à la marque au chapeau rouge...
A part ça, la man½uvre de SuSE offre une magnifique tribune pour permettre à Microsoft de rentrer dans le monde du libre et remodeler certains projets selon ses besoins... pas très rassurant.
A titre d'exemple, rappèle toi de l'affaire SCO. SCO avait menacer d'attaquer sur des brevets lui appartenant mais utilisé par Linux. Ça a fait rire beaucoup de mode car ces brevets étaient implantés par SCO dans Linux et diffusé sous GPL aussi par SCO (les sources explicitement sous GPL étaient diponiblent sur leur site ftp).
SCO a vite laissé tombé cette voie.
Le cas SCO a commencé par une affaire de copyright et non par une affaire de brevets. A l'époque, SCO prétendait que IBM avait illégalement inclu du code de Unix SYSTEM V dans Linux.
Par la suite SCO a clamé que linux contenait de sdizaines de milliers de lignes de codes volées... plusieurs années plus tard, SCO n'a toujours pas prouvé quoique ce soit et n'a pas été en mesure de fournir la moindre preuve étayant ses accusations.
Le propriétaire du code s'il y met un brevet lui appartemant dans le code définit aussi les droits d'utilisation de son brevet avec CE code (et seulement celui-ci).
Si le code n'est pas distribué par le détenteur du code, l'application de la GPL est sans guère d'intérêt. Si l'auteur diffuse le code, il accèpte pleinement l'application de la GPL qui définit les conditions d'utilisation de ce code.
Montre moi dans la gpl 2.0 la clause offrant la garantie que la license sur le brevet qui a été offerte à tous ne peut être reprise si l'entreprise détentrice du brevet change d'avis ou si le brevet change de propriétaire.
Les brevets sont une bombe à retardement. tant ceux qui sont élaborés par des companies inamicales que ceux "offerts" à la communauté libre
Autre chose, les brevets mis PAR IBM dans le noyau et sous copyright IBM sont libres d'utilisation car ces sources sont forcément GPL et mis sous GPL par IBM.
Tu confonds brevets et droits d'auteur.
Si une entreprise met du code breveté (dont elle détient le brevet) dans le noyau sous license GPL, ce code devient redistribuable selon les règles du GPL... MAIS l'invention implémentée dans ce code n'est pas concernée par cette de mesure de license puisque celle-ci porte sur le copyright, donc la formulation texte du code, et non l'invention implémentée par ce code.
Ceci crée une situation où on pourrait imaginer qu'une société puisse accepter la redistribution du code concerné par le brevet sous license GPL mais où elle se réserverait le droit d'attaquer, sur base du brevet (et non du droit d'auteur), une entreprise concurrente qui vendrait une application (GPL) dérivée du code distribué.
C'est entre-autres pour pallier à ce type de situation que le GPL3 a été créé, et c'est pour ces raisons que le GPL3 a peu de chances de s'appliquer à du code venant d'entreprises comme IBM.
Pour terminer sur ce point,
si par exemple, demain, une entreprise amie du logiciel libre et détentrice de brevets concernant une technologie clef de linux fait faillite, il est tout à fait imaginable que ses brevets soient revendus par la curatelle et que certains atterrissent entre les mains d'entreprises moins amicales et que l'une ou l'autre décide de rentabiliser son investissement en attaquant les entreprises utilisant la ou les technologies couvertes.
Donc pour le logiciel libre, les brevets, quels qu'ils soient, ne sont que des bombes à retardement.
Donc il ne faut pas confondre les brevets dans Linux (qui sont libres d'utilisation dans un logiciel libre) et les brevets "classiques" (qui ne sont pas libre d'utilisation).
Les brevets portant sur linux ne sont pas différents des brevets classiques sur le plan légal. La différence se situe dans le comportement des sociétés détentrices. En aucun cas il ne s'agit d'un acquis garanti et un changement de politique de l'un ou l'autre acteur peut toujours poser problème.
En outre, il n'y a pas que des sociétés bienveillantes qui détiennent des brevets portant sur le noyau.
Pour le recours il y a le prio art.
Il n'y a pas de prior art aux yeux de l'office américain des brevets si ce prior art n'a pas été créé sur le territoire américain. Toi en temps qu'européen, tu n'as aucun recours si une boîte américaine dépose un brevet sur une de tes inventions si tu n'as pas déposé celle-ci aux usa.
Le jour où les brevets sont reconnus en Europe, la même chose peut arriver chez toi.
Le problème, c'est que les brevets sur le logiciel sont déjà reconnus en europe... par les gens comme toi.
A quoi bon lutter et se mobiliser contre les brevets sur le logiciel si la liberté d'implémentation est contestée par le monde du logiciel libre lui-même?
A quoi bon lutter contre les brevets en europe si la communauté du logiciel libre décide de boycotter ces implémentations et d'appliquer de toutes façons les règles inhérentes à ces brevets partout dans le monde?
S'il te plait, mélanges pas les brevets.
Un brevet dans Linux n'a rien à voir avec le brevet mp3 par exemple.
Il n'y a pas de gentils ou de méchants brevets,
la seule distinction est l'intérêt de l'entreprise détenant le brevet, et il ne faut pas oublier que les sociétés changent parfois de stratégie.
Il y a les brevets compatibles avec le logiciel libre : par exemple ceux de Linux.
Il n'y a pas de "brevets de linux", il n'y a que des entreprises et des particuliers possédant des brevets sur des technologies intégrées dans Linux. Il existe des brevets dont les propriétaires ne se sont pas forcément manifestés et touchant à des technologies de Linux, et si les propriétaires de ces brevets se manifestaient il y aurait de sérieux problèmes.
Il y a les brevets incompatibles avec le logiciel libre : par exemple mp3, gif, etc...
Ces brevets ne posent pas problème en Europe, renoncer à l'usage de ces technologies équivaut à consacrer la victoire des pro-brevets en acceptant leur droit à se faire des monopoles dans des domaines qui sont pourtant non-brevetables.
Non, je refuse d'utiliser des logiciels que leur créateur a choisi de breveter
Ben faut pas utiliser le noyau linux, il est bourré de brevets (les contribueteurs comme Intel, Ibm, Oracles, ... n'hésitent pas à breveter les technologies qu'ils mettent dans le noyau)
De plus, il y a plein de logiciels sur lesquels portent des brevets qui ont été déposés par des personnes qui n'ont rien à voir avec le développement de l'application.
Il suffit que toi, en temps qu'européen, tu développes un soft qu'une start-up américaine trouve intéressant, et tu te retrouves du jour au lendemain avec un brevet déposé aux usa sans ton consentement, sans compensation financière et sans recours.
Refuser les softs contenant des technologies brevetées, c'est punir les développeurs européens qui sont réglos et c'est aussi punir l'utilisateur en acceptant implicitement la validité des brevets et le droit d'une société à monopoliser une technologie logicielle.
Si personne utilise ce qui est breveté, expliques où est l'intérêt de déposer un brevet ?
Les brevets sur le logiciel constituent une forme de capital pour les entreprises, et la possession d'un solide porte-feuille de brevets est devenu de nos jours, aux yeux des investisseurs, une valeur indicatrice de la santé, de la solidité et de la pérennité des sociétés.
Le fait que les logiciels libres n'intègrent pas de technologies brevetées est encore insignifiant aux yeux des investisseurs qui à l'heure actuelle sont encore très peu intéressé par ce monde.
En plus, si on veut vraiment n'utiliser aucune technologie brevetée (ici ou aux usa), il faut se passer du noyau linux tel qu'on le connait et être prêt à se séparer des fonctionnalités de nos logiciels au fur et à mesure que des brevets sont déposés.
La sécurité, c'est le boulot du développeur qui utilise soap... (choix du protocole de transport, système d'authentication et d'autorisation, des librairies utilisées pour encoder et décoder, ...)
Parce que les brevets logiciels c'est Mal, donc il ne faut pas les encourager.
Un peu simpliste comme réaction, sachant que les brevets ne sont pas forcément déposés par les développeurs de telle ou telle fonctionnalité.
Si on veut vraiment boycotter les technologies brevetées, il faut virer le noyau linux, puisque ce dernier serait couvert par près de 300 brevets.
La bonne attitude serait plutôt de permettre aux personnes vivant dans des pays n'ayant pas cédés aux brevets sur le logiciel de dire "les brevets sur le logiciel, on se torche avec, on implémente ce qu'on veut puisque ces brevets sont illégaux" plutôt que "on a pas de brevets sur le logiciel, mais pour montrer notre désaccord on va respecter les brevets déposés illégalement ou dans d'autres pays en les contournant".
Ne pas oublier non-plus que si quelqu'un innove en dehors des usa, sa méthode pourra toujours être brevetée par un tiers aux usa qui s'accaparera donc l'invention: tu inventes un truc ici, une boîte dépose le brevet aux usa, tu l'as dans le cul, il faut le retirer de la distribution.
Plutôt gadget par rapport à un protocole comme SOAP.
Ajax ne fait pas tourner le monde, mais SOAP est bel et bien occupé à se tailler une part gigantesque du monde des transactions intra et inter-entreprises...
En fait, c'est surtout dans des standards comme soap que le xml montre le mieux ses capacités car l'interopérabilité est le maître mot.
Le NNTP est loin d'être répandu chez les hébergeurs classiques, et représente donc une solution peu accessible pour le commun des mortels (tout le monde n'a pas un serveur dédié).
Donc dans la majorité des cas de sites web non-commerciaux, le NNTP n'est pas une possibilité technique, et heureusement que les forums http existent (et puis ça s'insère tout de même mieux dans un site) ...
[^] # Re: L'avenir de Linux
Posté par ragoutoutou . En réponse à la dépêche Microsoft une interopérabilité difficile avec la communauté du logiciel libre. Évalué à 9.
Pendant 5 ans, Microsoft pousse SuSE en avant pour mettre celui-ci en situation dominante dans le monde Linux.
Après 5 ans, à la fin de l'accord, Microsoft négocie un nouvel accord qui lui donne plus de pouvoir sur la communauté Linux.
...
Ce qui est sûr, c'est qu'on est en droit de suspecter Microsoft de vouloir transformer SuSE en cheval de Troie pour contrôler la vague Linux. Et à ce titre, il y a lieu de se méfier de Novell et des technologies posant problème comme Mono et de ne pas mettre tous ses oeufs dans le même panier.
Je ne dis pas de jeter tout ce qui vient de Novell à la poubelle, mais de bien considérer le risque de voir Microsoft sonner la fin de la récré d'ici 5 ans.
[^] # Re: Linux exploite la propriété de Microsoft
Posté par ragoutoutou . En réponse à la dépêche Microsoft une interopérabilité difficile avec la communauté du logiciel libre. Évalué à 7.
et sur le site de Novell, on voit bien
Comment prétendre ne pas reconnaître la présence de code portant atteinte à la propriété intellectuelle et signer un accord dont un des points porte justement sur un accord de non-agression sur le code portant atteinte à la propriété intellectuelle de Microsoft?
On peut en tout cas parler de double langage de la part de Novell selon qu'il s'adresse aux entreprises ou à la communauté libre. De là à dire que Novell prend les développeurs de logiciel libre pour des cons.
[^] # Re: TCPA
Posté par ragoutoutou . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 0.
Soit elle gère la connexion du début à la fin et aucune clef ne passe en clair dans la ram, soit elle ne la gère pas, et il y a forcément un moment où le software prend le relais pour réalimenter les différentes fonctions de la puce tpm afin de l'utiliser dans le processus de cryptage.
Si la puce ne gère pas la session complètement, il y aura forcément un moment où il faudra, par exemple, récupérer le résultat d'une fonction de la puce , le traiter en soft, et le réinjecter dans une autre fonction, ce qui implique un passage par la ram.
Idem, je ne vois pas comment cette puce pourrait gérer ça, et je ne trouve aucune littérature sur le sujet. Je ne vois donc pas comment prétendre qu'elle le fait.
Le point positif, si le tpm supporte l'algorithme symétrique utilisé lors d'une session, c'est qu'effectivement les attaques de timing ne pourront être utilisées pour faire des statistiques sur la prédiction de branche du cpu puisque les opérations se dérouleront sur un autre cpu, c-à-d la puce tpm. Mais les clefs transitant à l'occasion en ram (sauf preuve du contraire), il y aura toujours d'autres attaques possibles si la machine est déjà compromise au point de faire tourner un outil permettant de faire l'attaque sur la prédiction de branche.
Enfin, qui dit qu'on ne va pas trouver des exploits sur les puces TPM, et si cela se produit, comment y remédier?
[^] # Re: TCPA
Posté par ragoutoutou . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 2.
vu que cela requiert un logiciel tournant localement pour faire l'attaque sur la prédiction de branche, c'est à peu près le seul cas de figure où je vois un vrai risque. Ce n'est pas une attaque pouvant être lancée à distance.
[^] # Re: TCPA
Posté par ragoutoutou . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 1.
Mettre les clefs de cryptage SSL dans la puce et seulement dans la puce est donc une énormité. Au final, même si on met la clef dans la puce, elle sera aussi présente en ram, ce qui la rendra toujours vulnérable à certaines attaques.
Au final, de toutes façons, ce bug est plutôt improbable, à part chez les gens qui installent n'importe-quoi sur leurs machines ou les serveurs web partagés où un webmaster peu scrupuleux essayerait d'espionner le voisin.
[^] # Re: TCPA "remote atetstation" et obscurité
Posté par ragoutoutou . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 2.
Des outils comme le PadLock de VIA accélèrent certaines fonctionnalités, mais les clefs passent en ram et une partie des traitements doit être effectuée par le cpu.
Par contre, question accélération, le padlock accompagné d'un "bête" VIA eden à 1ghz écrase par un facteur ~16 un P4 2,4ghz pour l'AES-256.
[^] # Re: TCPA
Posté par ragoutoutou . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 1.
La puce TPM fait les calculs cryptographiques, mais seulement ceux nécessaires au TCPA.
Faudrait te renseigner sur la manière de gérer les clefs dans le TPM, les clefs qui sont accessibles et celles qui ne le sont pas.
Dans le cas ou les clefs ne seraient pas accessibles aux applications, elles n'auraient de toutes façons aucun intéret à moins que la puce n'intègre tous les protocoles de crypto nécessaires aux opérations (et le SSL/TLS est plutôt spécialisé et complexe) et soit capable de faire du traitement de flux avec une vitesse suffisante.
Par contre, il existe de vrais accélérateurs SST/TLS hardware, qui eux ont une utilité réelle pour les serveurs.
[^] # Re: TCPA
Posté par ragoutoutou . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 1.
Le TPM ne sauve pas pour ce genre de situation. Le problème n'est pas la génération de la clef mais bien sa présence en ram.
[^] # Re: Pas si révoluionnaire
Posté par ragoutoutou . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 3.
Il me semble que ça ne marche que sur les processeurs à cache partagée (core2 duo), ou les systèmes avec hyperthreading. Si tu utilises des processeurs à cache séparée (p-ex, AMD64) , ces timing attacks doivent être beaucoup plus difficiles.
Au final le problème de ce bug, comme beaucoup d'autres du même genre, c'est le contrôle de ce qui tourne et de ce qui ne tourne pas sur la machine. Si un serveur se fait injecter un programme qui fait des timing attacks, c'est qu'il y a un problème de sécurité déjà ailleurs.
[^] # Re: Encore un coup dur pour RedHat...
Posté par ragoutoutou . En réponse à la dépêche Novell et Microsoft main dans la main !. Évalué à 4.
Cela évite aussi que les fournisseurs se revoient trop la balle si il n'y a qu'un seul fournisseur concerné par un domaine.
[^] # Re: Mise au point : Groklaw
Posté par ragoutoutou . En réponse à la dépêche Novell et Microsoft main dans la main !. Évalué à 3.
A la lumière des propos de Steve Ballmer, on peut dire que cela pue pour les autres initiatives commerciales basées sur linux:
"Let me be clear about one thing, we don't license our intellectual property to Linux because of the way Linux licensing GPL framework works, that's not really a possibility,"
"This does not apply to any forms of Linux other than Novell's SUSE Linux. And if people want to have peace and interoperability, they'll look at Novell's SUSE Linux. If they make other choices, they have all of the compliance and intellectual property issues that are associated with that."
Et voilà... déjà des menaces...
Grâce à Novell, on va se retrouver avec un monde linux vraiment à deux vitesses, et l'interopérabilité avec Windows deviendra un monopole de Novell.
[^] # Re: FAT32
Posté par ragoutoutou . En réponse à la dépêche Novell et Microsoft main dans la main !. Évalué à 3.
Non, seulement à Novell...
ça n'aura de toutes façons pas d'impact sur la fragmentation...
[^] # Re: Brevet = dissuasion
Posté par ragoutoutou . En réponse à la dépêche Novell et Microsoft main dans la main !. Évalué à 4.
Difficile à dire... SCO prétend avoir déjà acheté l'âme de Novell...
Maintenant, le risque est de voir SuSE remplacer RedHat et les autres dans les entreprises qui sont aussi clientes de Microsoft, et de voir une forme de petit monopole Linux émerger par la force commerciale et la menace des brevets Microsoft.
On verrait bien une déclaration du genre "Moi je suis copain avec Microsoft, j'ai le droit d'utiliser ses brevets. Vous n'avez pas le droit d'utiliser ses brevets, mon copain va vous casser la gueule".
L'attitude de Novell d'utiliser des technologies pour lesquelles IL a la license et pas l'ensemble de la communauté est en tout cas peu en phase avec l'esprit du logiciel libre, et vraissemblablement en contradiction avec la GPL.
# Encore un coup dur pour RedHat...
Posté par ragoutoutou . En réponse à la dépêche Novell et Microsoft main dans la main !. Évalué à 5.
Après le coup infligé à RedHat par Oracle (et amplifiée par l'attitude d'HP et d'autres vendeurs) ces derniers jours et qui a provoqué une chute de l'action, c'était le moment idéal pour SuSE pour asséner un coup à la marque au chapeau rouge...
A part ça, la man½uvre de SuSE offre une magnifique tribune pour permettre à Microsoft de rentrer dans le monde du libre et remodeler certains projets selon ses besoins... pas très rassurant.
[^] # Re: AJAX = ....
Posté par ragoutoutou . En réponse au sondage XML est. Évalué à 2.
et puis question buzzword, au boulot j'entends plus souvent "webservices" et "soap" qu' "ajax".
[^] # Re: Brevets logiciels?
Posté par ragoutoutou . En réponse à la dépêche Sortie de Zod (alias Fedora Core 6). Évalué à 2.
Le cas SCO a commencé par une affaire de copyright et non par une affaire de brevets. A l'époque, SCO prétendait que IBM avait illégalement inclu du code de Unix SYSTEM V dans Linux.
Par la suite SCO a clamé que linux contenait de sdizaines de milliers de lignes de codes volées... plusieurs années plus tard, SCO n'a toujours pas prouvé quoique ce soit et n'a pas été en mesure de fournir la moindre preuve étayant ses accusations.
Montre moi dans la gpl 2.0 la clause offrant la garantie que la license sur le brevet qui a été offerte à tous ne peut être reprise si l'entreprise détentrice du brevet change d'avis ou si le brevet change de propriétaire.
Les brevets sont une bombe à retardement. tant ceux qui sont élaborés par des companies inamicales que ceux "offerts" à la communauté libre
[^] # Re: Brevets logiciels?
Posté par ragoutoutou . En réponse à la dépêche Sortie de Zod (alias Fedora Core 6). Évalué à 3.
Tu confonds brevets et droits d'auteur.
Si une entreprise met du code breveté (dont elle détient le brevet) dans le noyau sous license GPL, ce code devient redistribuable selon les règles du GPL... MAIS l'invention implémentée dans ce code n'est pas concernée par cette de mesure de license puisque celle-ci porte sur le copyright, donc la formulation texte du code, et non l'invention implémentée par ce code.
Ceci crée une situation où on pourrait imaginer qu'une société puisse accepter la redistribution du code concerné par le brevet sous license GPL mais où elle se réserverait le droit d'attaquer, sur base du brevet (et non du droit d'auteur), une entreprise concurrente qui vendrait une application (GPL) dérivée du code distribué.
C'est entre-autres pour pallier à ce type de situation que le GPL3 a été créé, et c'est pour ces raisons que le GPL3 a peu de chances de s'appliquer à du code venant d'entreprises comme IBM.
Pour terminer sur ce point,
si par exemple, demain, une entreprise amie du logiciel libre et détentrice de brevets concernant une technologie clef de linux fait faillite, il est tout à fait imaginable que ses brevets soient revendus par la curatelle et que certains atterrissent entre les mains d'entreprises moins amicales et que l'une ou l'autre décide de rentabiliser son investissement en attaquant les entreprises utilisant la ou les technologies couvertes.
Donc pour le logiciel libre, les brevets, quels qu'ils soient, ne sont que des bombes à retardement.
[^] # Re: Brevets logiciels?
Posté par ragoutoutou . En réponse à la dépêche Sortie de Zod (alias Fedora Core 6). Évalué à 2.
Les brevets portant sur linux ne sont pas différents des brevets classiques sur le plan légal. La différence se situe dans le comportement des sociétés détentrices. En aucun cas il ne s'agit d'un acquis garanti et un changement de politique de l'un ou l'autre acteur peut toujours poser problème.
En outre, il n'y a pas que des sociétés bienveillantes qui détiennent des brevets portant sur le noyau.
Il n'y a pas de prior art aux yeux de l'office américain des brevets si ce prior art n'a pas été créé sur le territoire américain. Toi en temps qu'européen, tu n'as aucun recours si une boîte américaine dépose un brevet sur une de tes inventions si tu n'as pas déposé celle-ci aux usa.
Le problème, c'est que les brevets sur le logiciel sont déjà reconnus en europe... par les gens comme toi.
A quoi bon lutter et se mobiliser contre les brevets sur le logiciel si la liberté d'implémentation est contestée par le monde du logiciel libre lui-même?
A quoi bon lutter contre les brevets en europe si la communauté du logiciel libre décide de boycotter ces implémentations et d'appliquer de toutes façons les règles inhérentes à ces brevets partout dans le monde?
Il n'y a pas de gentils ou de méchants brevets,
la seule distinction est l'intérêt de l'entreprise détenant le brevet, et il ne faut pas oublier que les sociétés changent parfois de stratégie.
Il n'y a pas de "brevets de linux", il n'y a que des entreprises et des particuliers possédant des brevets sur des technologies intégrées dans Linux. Il existe des brevets dont les propriétaires ne se sont pas forcément manifestés et touchant à des technologies de Linux, et si les propriétaires de ces brevets se manifestaient il y aurait de sérieux problèmes.
Ces brevets ne posent pas problème en Europe, renoncer à l'usage de ces technologies équivaut à consacrer la victoire des pro-brevets en acceptant leur droit à se faire des monopoles dans des domaines qui sont pourtant non-brevetables.
[^] # Re: Brevets logiciels?
Posté par ragoutoutou . En réponse à la dépêche Sortie de Zod (alias Fedora Core 6). Évalué à 2.
Ben faut pas utiliser le noyau linux, il est bourré de brevets (les contribueteurs comme Intel, Ibm, Oracles, ... n'hésitent pas à breveter les technologies qu'ils mettent dans le noyau)
De plus, il y a plein de logiciels sur lesquels portent des brevets qui ont été déposés par des personnes qui n'ont rien à voir avec le développement de l'application.
Il suffit que toi, en temps qu'européen, tu développes un soft qu'une start-up américaine trouve intéressant, et tu te retrouves du jour au lendemain avec un brevet déposé aux usa sans ton consentement, sans compensation financière et sans recours.
Refuser les softs contenant des technologies brevetées, c'est punir les développeurs européens qui sont réglos et c'est aussi punir l'utilisateur en acceptant implicitement la validité des brevets et le droit d'une société à monopoliser une technologie logicielle.
[^] # Re: Brevets logiciels?
Posté par ragoutoutou . En réponse à la dépêche Sortie de Zod (alias Fedora Core 6). Évalué à 3.
Les brevets sur le logiciel constituent une forme de capital pour les entreprises, et la possession d'un solide porte-feuille de brevets est devenu de nos jours, aux yeux des investisseurs, une valeur indicatrice de la santé, de la solidité et de la pérennité des sociétés.
Le fait que les logiciels libres n'intègrent pas de technologies brevetées est encore insignifiant aux yeux des investisseurs qui à l'heure actuelle sont encore très peu intéressé par ce monde.
En plus, si on veut vraiment n'utiliser aucune technologie brevetée (ici ou aux usa), il faut se passer du noyau linux tel qu'on le connait et être prêt à se séparer des fonctionnalités de nos logiciels au fur et à mesure que des brevets sont déposés.
[^] # Re: AJAX = ....
Posté par ragoutoutou . En réponse au sondage XML est. Évalué à 3.
La sécurité, c'est le boulot du développeur qui utilise soap... (choix du protocole de transport, système d'authentication et d'autorisation, des librairies utilisées pour encoder et décoder, ...)
# questions...
Posté par ragoutoutou . En réponse au message elections sur internet. Évalué à 2.
Quel est le mode de recensement des utilisateurs?
Comment les utilisateurs sont-ils définis actuellement?
On ne peut pas sécuriser une chaîne si on en attrape pas un bout.
[^] # Re: Brevets logiciels?
Posté par ragoutoutou . En réponse à la dépêche Sortie de Zod (alias Fedora Core 6). Évalué à 3.
Un peu simpliste comme réaction, sachant que les brevets ne sont pas forcément déposés par les développeurs de telle ou telle fonctionnalité.
Si on veut vraiment boycotter les technologies brevetées, il faut virer le noyau linux, puisque ce dernier serait couvert par près de 300 brevets.
La bonne attitude serait plutôt de permettre aux personnes vivant dans des pays n'ayant pas cédés aux brevets sur le logiciel de dire "les brevets sur le logiciel, on se torche avec, on implémente ce qu'on veut puisque ces brevets sont illégaux" plutôt que "on a pas de brevets sur le logiciel, mais pour montrer notre désaccord on va respecter les brevets déposés illégalement ou dans d'autres pays en les contournant".
Ne pas oublier non-plus que si quelqu'un innove en dehors des usa, sa méthode pourra toujours être brevetée par un tiers aux usa qui s'accaparera donc l'invention: tu inventes un truc ici, une boîte dépose le brevet aux usa, tu l'as dans le cul, il faut le retirer de la distribution.
[^] # Re: AJAX = ....
Posté par ragoutoutou . En réponse au sondage XML est. Évalué à 2.
Ajax ne fait pas tourner le monde, mais SOAP est bel et bien occupé à se tailler une part gigantesque du monde des transactions intra et inter-entreprises...
En fait, c'est surtout dans des standards comme soap que le xml montre le mieux ses capacités car l'interopérabilité est le maître mot.
[^] # Re: des PAGES web
Posté par ragoutoutou . En réponse à la dépêche Que peut-on faire avec Zope 3.3 ?. Évalué à 2.
A condition d'avoir ton propre serveur NNTP...
Le NNTP est loin d'être répandu chez les hébergeurs classiques, et représente donc une solution peu accessible pour le commun des mortels (tout le monde n'a pas un serveur dédié).
Donc dans la majorité des cas de sites web non-commerciaux, le NNTP n'est pas une possibilité technique, et heureusement que les forums http existent (et puis ça s'insère tout de même mieux dans un site) ...