jeudi 04 septembre
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Journal : Java, .NET et les logiciels libres

Posté par boubou (page perso, ) le 16 juin 2005
0
Voilà, c'est fait, mon article paru dans GNU/Linux Magazine France 67 (http://www.ed-diamond.com/produit.php?produit=375(...) ) sur Java, .NET et les logiciels libres est enfin disponible en ligne à l'url http://apiacoa.org/publications/2004/lm-java-dotnet-free.pdf(...) . Merci à Denis Bodor et aux Editions Diamond pour avoir autorisé cette publication.

Ce journal est destiné aux discussions concernant l'article. J'espère le faire évoluer et l'améliorer. Bonne lecture !

> Lire le journal (82 commentaires, moyenne: 2).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

héhé

Posté par TImaniac (page perso, ) le 16/06/2005 à 15:20. (lien). Évalué à 5.

Microsoft et ses co-inventeurs (Intel et HP) ´etaient prˆets `a
offrir des licences Royalty Free ou RAND pour les brevets concernant C# et la CLI
pas "ou" mais ET. Cf http://web.archive.org/web/20030609164123/http://mailserver.di.unip(...)

alors que Microsoft a demand´e une protection de l’API de .NET par brevet, ce qui signifie que toute impl´ementation
de .NET sera n´ecessairement couverte par le brevet en question
Source ? D'où provient l'affirmation que les brevets en questions concernent l'ensemble des APIs et qu'il est impératif de les implémenter ? Que je sache le projet DotGNU a fait un tableau récapitulant les éventuelles parties concernées par ces fameux brevets. Visiblement les juristes de Novell ont procédés de même. Bizzarement ils ne sont absolument pas arrivé à la même conclusion que toi.

Par contre, l’affaire Kodak vs Java ne sera pas n´ecessairement sans cons´equence pour les impl´ementations libres de .NET. En effet, les brevets concern´es sont si
larges qui couvrent tr`es certainement .NET
Tout à fait d'accord. Mais il faut faire le même raisonnement pour de nombreuses plateformes de développement. Tu supposes que .NET est sûrement concerné, je ne vois pas pourquoi tu supposerais que seul cette plateforme l'ai.


Il me semble qu’il est possible (mais difficile) de faire une impl´ementation libre l´egale de
Java
Kodak et Sun ont passé un accord. Les implémentations alternatives n'ont pas cet accord auprès de Kodak. J'ai donc beaucoup de mal à comprendre en quoi tu arrives à conclure de manière "positive".

D'une manière générale j'ai vraiment du mal à te suivre. Tu arrives toujours à dire qu'il y a un problème sur telle plateforme et à montrer qu'il y a le même problème sur l'autre plateforme. Pourtant tu arrives à conclure que Java ne semble pas trop problématique alors que Mono représente un véritable danger pour les logiciels libres.

Enfin dans l'ensemble c'est plutôt pertinent. Dommage que tu refuses d'essayer d'analyser le pourquoi en te contentant plutôt de détails pratiques et juridiques, avec beaucoup de "suppositions" et de tentative de découverte d'intentions.

Que cherchent à faire Microsoft et Sun ? Protéger leur plateforme contre toutes utilisations qui casserait la compatibilité, bref ils veulent faire respecter leurs "standards" pour que personne ne s'en écarte. Evidemment que Sun ne fera pas chier Classpath s'ils sont pas parfaitement compatible : Classpath ne le fait pas exprès et ce n'est pas leur objectif.

Maintenant que penses Microsoft de Mono ?
Le créateur du langage C# chez Microsoft :
" InfoWorld: What is your take on Mono?

Hejlsberg: Oh, I think it's great, I think it's proof that standardization works, that the work that we've done in ECMA to standardize CLI [Common Language Infrastructure] and C# actually has [results] and we have seen completely independent third-party implementations of the infrastructure. So I think it's a good thing. I think it's more good for us than bad for us. "
( http://www.infoworld.com/article/05/06/10/HNhejlsberg_1.html?source(...) )
Là on apprend POURQUOI MS a cherché à standardiser sa plateforme.
Que cette citation reflète ou non une position officielle, elle s'ajoute aux nombreuses autres avis et faits qui montre clairement que leur objectif est la standardisation en vu de voir apparaître d'autres implémentations, sur de nombreuses plateformes.
Tes rapprochements avec Samba ou les formats ASF sont donc tout à fait incongru puisque là les objectifs de Microsoft sont clairement une absence totale d'ouverture. Cherchez à démontrer ce que MS va faire en se basant sur cet "existant" me paraît donc totalement foireux. Dans ce cas précis MS cherche à protéger sa propriété intellectuelle (codec entre autre) qui fait ici la différence avec la concurrence.

Pour .NET c'est totalement différent, même sans brevets accordés ils ont mis à disposition le projet Rotor. Même si celui-ci n'a que peut d'intérêt du point de vu des logiciels libres, Microsoft ne cherche pas à cacher des "secrets technologiques" comme il le fait avec ses formats vidéos par exemple (qui constituent le nerf de la guerre).

Microsoft a clairement chercher à ce que naisse Mono. Ils ont même pousser Icaza à de nombreuses reprises, et Novell a joué le jeu en choisissant des licences que Microsoft "accepte".

Maintenant ce que je ne comprends pas non plus c'est que reviens sans cesse dans ton argumentation le fait que les futurs brevets couvrirons forcement l'ensemble des API de .NET. Marrant tout de même que le service juridique de Novell n'ai pas vu cet éventuel danger.

Bref tout ca me pousse à être optimiste, au moins autant que pour Java.

Maintenant tu oublies le principal : proposer une alternative ou une solution.
Pourtant il y aurait également eu matière à analyse. Il est évident que le monde des logiciels libres a besoin d'une plateforme "moderne" du type de celles de Sun et MS. Il n'existe rien de tel d'"indépendant" mais déjà de nombreuses briques existent (que ce soit au nivaeu des APIs, des langages ou des VM). Maintenant poursuivons l'analyse. Si on suit avec quel brio tu arrives à démontrer que les brevets Kodak s'appliqueront forcement à .NET, on peut sans trop d'imagination se dire qu'ils seront applicables à cette hypothétique plateforme. D'ailleur cela s'applique déjà surement à des briques existentes. Bref, tous les projets de plateforme et/ou langage est un danger pour les logiciels libres si je fais la même conclusion que toi.

Les violations multiples de brevets logiciels dans le noyau est un autre parfait exemple.

Tu as raisons en disant que l'épée de Damoclès des brevets logiciels reposent sur la tête des logiciels libres. Mais affirmer que seuls .NET (ou Java) posent problème est vraiment se moquer du monde. Le problème est omniprésent. Le problème c'est les brevets logiciels dans leur ensemble.

Après je suis d'accord avec toi qu'il est bien dommage que ces plateformes soient dirigés par des entreprises privées, mais cela a aussi des avantages : ces entreprises savent imposer des standards (tu l'as parfaitement démontrer), ce qui fait aussi en grosse partie le succès de Java et .NET, savent les répendre (et donc les faire adopter) et aussi protéger leurs utilisateurs : Microsoft Sun ou Novell ont les moyens de riposter contre une éventuelle attaque de brevet, alors qu'un pauvre petit projet parfaitement libre qui en viole un "par hasard" va se faire bouffer tout cru.

Une dernière pensée (en totale contradiction avec le fait que je suis contre les brevets logiciels) mais qui pousse à réfléchir :
"Ahhh si seulement le HTML avait été breveté, MS nous auraient pas péter les couilles avec Internet Explorer..."
(en même temps grâce à IE on a un superbe vecteur de promotion des LL à travers Firefox actuellement...)

--
MonoFrance

  • [^]Re: héhé

    Posté par boubou (page perso, ) le 16/06/2005 à 16:38. (lien). Évalué à 5.

    pas "ou" mais ET. Cf http://web.archive.org/web/20030609164123/http://mailserver.di.unip(...)

    Non. Il est indiqué royalty-free and otherwise RAND, ce qui ne se traduit pas par et, mais par "et dans d'autres cas", ce qui veut dire ou.

    D'où provient l'affirmation que les brevets en questions concernent l'ensemble des APIs et qu'il est impératif de les implémenter ?

    Tu as lu mon texte, mais tu n'as pas lu les documents pointés, c'est ça ? Lis les références et on rediscute. Cf donc
    http://www.theregister.co.uk/2003/02/11/ms_patents_everything/(...) et http://news.com.com/2100-1001_3-984052.html(...)

    Kodak et Sun ont passé un accord. Les implémentations alternatives n'ont pas cet accord auprès de Kodak. J'ai donc beaucoup de mal à comprendre en quoi tu arrives à conclure de manière "positive".

    Parce que Sun a indiqué explicitement que l'accord couvrait les licences officielles de Java et qu'une implémentation légale a nécessairement une licence officielle. Lis les documents donnés en référence.

    Et pout finir, une citation de Steve Ballmer, traduite de l'allemand (pas par moi) :
    Responding to questions about the opening-up of the .NET framework, Ballmer announced that there would certainly be a "Common Language Runtime Implementation" for Unix, but then explained that this development would be limited to a subset, which was "intended only for academic use". Ballmer rejected speculations about support for free .NET implementationens such as Mono: "We have invested so many millions in .NET, we have so many patents on .NET, which we want to cultivate."

    Et ouai, ça fout la trouille, hein ? (source http://swpat.ffii.org/players/microsoft/(...) ).

    • [^]Re: héhé

      Posté par TImaniac (page perso, ) le 16/06/2005 à 18:01. (lien). Évalué à 3.

      ce qui ne se traduit pas par et, mais par "et dans d'autres cas", ce qui veut dire ou.
      Bizzarement les juristes anglais de chez Novell ne font pas la même interprétation que toi :
      "Basically a grant is given to anyone who want to implement those components for free and for any purpose."
      Chacun sa traduction hein.

      Lis les documents donnés en référence.
      Oué mais justement j'ai pas trouvé, d'où ma demande.

      Lis les références et on rediscute.
      A part dire que MS ne peut avoir un brevet valide sur tous ses API (puisqu'une grande partie n'a strictement rien d'innovant et de nombreux "prior-art" comme cherche à montrer le tableau de DotGnu, voilà quoi.
      Evidemment que MS peut obtenir des brevets qui peuvent être "génant" pour Mono. Mais les APIs de MS n'innovent quasiment pas, alors soient d'autres plateformes seront impactés (autour des web services comme le laisse entendre une des tes sources), soient un prior-art sera démontré.

      Et ouai, ça fout la trouille, hein ?
      Kedal. Le directeur de MS dit seulement qu'ils ne comptent pas offrir de support pour Mono. Autrement dis : "implémenter les spécifs si vous voulez [même si un brevet est payant, Novell pourra obligatoirement obtenir une licence ou le contourner], mais vous vous démerder."
      Enfin bizzarement c'est l'inverse qui s'est produit, les ingénieurs de MS ont aimablement aidés les dev de Mono, etc. L'avis que je t'ai donné du créateur de C# date de ce mois ci, les mentalité ont visiblement évolué depuis ta référence allemande qui date de 2002.
      Ta citation foutait surement les boules y'a 3 ans. Depuis de l'eau a coulé sous les ponts : Mono a atteind maturité, Novell a étudié les brevets en question, MS a fait la promotion de Mono (invitant Icaza, argument marketing multiplateforme dans les slides PowerPoint), le fameux mail, le discours du créateur de C#, bref toutes les sources plus récentes vont à l'encontre de ce que tu essais de nous faire gober.
      S'ils ne souhaitaient pas voir apparaître d'autres implémentation, pourquoi ce seraient-ils enmerder à normaliser leur plateforme ?

      Plus sérieusement, je penses surtout que MS va chercher à proteger ses technos spécifiques comme ASP.NET ou les WinForms. Si un problème de brevet apparaît, ca sera sur ces parties (qui n'ont pas été normalisé, montrant clairement que MS ne souhaitait pas d'ouverture de ce côté). Mais Mono n'a besoin de ces parties que par compatibilité pour assurer la transition d'applications Windows. En aucun cas ces parties ne sont indispensable au fonctionnement de Mono qui peut rester une plateforme complète.

      Enfin comme je l'ai déjà dis à plusieurs reprises, il faut :
      - que MS ai effectivement ces brevets de validés : ce qui ne couvrira certainement pas tous les APIs, surtout pas les APIs normalisés sujettes à prior-art. Si des APIs sont couverts, cela ne peut être que ceux spécifiques à MS et donc à sa plateforme Windows. On va pas breveter la classe string hein ?

      - que MS décide de faire payer des licences pour les brevets couvrant la CLI. (ce que je doute fortement, tout l'argumentation commerciale de MS sur le côté multiplateforme s'éffondrerait). Je dis pas qu'ils ne feraient pas payer pour ce qui n'est pas normalisé).

      - que Novell ne puisse les contourner (en informatique il est quand même difficile de ne pas trouver 2 algos différents pour arriver au même résultat.

      - que personne ne fork en dehors des US.

      Pourquoi tu ne reprends pas mon argumentation, la 2ème partie de mon post ?

      En espérant que cela reste constructif.

      --
      MonoFrance

      • [^]Re: héhé

        Posté par M_Skylight2 () le 16/06/2005 à 20:25. (lien). Évalué à 2.

        Java pose exactement les mêmes problèmes que .Net, dire que l'un est plus dangereux que l'autre, c'est de la trollerie.
        Globalement l'article est intéressant mais la conclusion biaisée pas étonnant vu que l'auteur est un expert Java, donc sa position est tout aussi valable que celle de mr Timaniac, je dirais match nul.

        Amicalement votre, Michael.

        --
        le méchant de service :-)

        • [^]Re: héhé

          Posté par boubou (page perso, ) le 17/06/2005 à 07:34. (lien). Évalué à 2.

          la conclusion biaisée pas étonnant vu que l'auteur est un expert Java

          Quelle puissance dans l'argumentation ! Si j'avais aujourd'hui à choisir un langage et une plateforme sur des arguments exclusivement techniques, je prendrais C# et .NET car je pense que c'est ce qui se fait de mieux. Je suis d'autant plus dégouté que Mono pose potentiellement des problèmes légaux que c'est pour moi une superbe réalisation logicielle. Contrairement aux projets open source Java, Mono a dès le début pris ses distances avec les API canoniques en proposant des choses très intéressantes comme gtk#. Oui, je suis un expert Java (merci), mais je n'ai rien contre le framework de MS, au contraire.

          Concernant le caractère biaisé de ma conclusion, je vois que tu te contentes d'une affirmation pour seule critique d'une argumentation de 20 pages et je ne vois donc pas l'intérêt de te répondre.

          • [^]Re: héhé

            Posté par TImaniac (page perso, ) le 17/06/2005 à 08:04. (lien). Évalué à 2.

            i j'avais aujourd'hui à choisir un langage et une plateforme sur des arguments exclusivement techniques, je prendrais C# et .NET car je pense que c'est ce qui se fait de mieux.
            Faut aussi prendre en considération l'existant et les APIs utilisables, Java a quand même une large gamme d'API et bibliothèques plus mature par rapport à .NET ;)

            Par contre j'aurai aimé que tu reprennes mes arguments :

            - tu te bases sur des exemples de MS (Samba, SenderID, ASF) où MS fait preuve d'un manque flagrant d'ouverture, pour conclure sur .NET alors que là MS a fait preuve depuis 3 ans d'ouverture en exprimant clairement le pourquoi de la standardisation. Bref ce n'est pas du tout les mêmes objectifs.

            Si tu tenais à faire une comparaison, pourquoi n'as tu pas par exemple pris en considération tout le travail de Microsoft autour des formats XML qui favorisent largement l'interopérabilité (même si l'a encore les brevets logiciels font chier) : il y a eu normalisation de nombreux standards où Microsoft s'est activement impliqué, comme XML, XSL, XSD, XPath & Co. Je trouves l'exemple beaucoup plus pertinent et plus proche de des objectifs qu'ils ont avec .NET : proposer une base technique favorisant l'interopérabilité (d'où mon affirmation qu'ils n'ont aucun intérêt à chercher à faire chier ceux qui utilisent les mêmes bases techniques), tout en protegeant leurs valeurs ajoutées, dans le cas de .NET il s'agit bien entendu de ASP.NET, WinForms et autres EnterpriseServices.

            - tu affirmes que tout les API .NET (je carricature) seront couverts par les brevets, alors que tu sais pertinement (tu le rappelles toi même) que les APIs normalisés non rien d'innovant et qu'ils sont relativement basique (mais indispensable à l'interopérabilité). Bref, impossible à breveté entièrement, il y aurait forcement prior-art. Cela rejoint l'idée de la FAQ Mono qui dit clairement que les parties pouvant poser problème sont les parties non normalisées. Et c'est en parfait adéquation avec mon premier argument qui tend à dire que MS cherchera à protéger sa valeur ajoutée, mais pas la partie normalisé (à part pour assurer le respect des standards, comme le fait Sun d'une autre manière).

            - tu ne prend en considération que quelques brevets non encore validés et tu "oublies" les autres brevets, eux validés. Je penses que tu seras d'accord pour dire que des projets de l'empleur de Mono ou Java violent sûrement d'autres brevets, au même titre que le noyau Linux en viole des centaines. Bref, les 2 sont sûrement dans l'illégalité (aux US) comme toutes les plateformes un tant soit peut conséquentes, et tu ne proposes pas de solution. Moi je dis : c'est aussi dangereux d'utiliser telle ou telle plateforme, mais ce n'est pas plus dangereux d'en utiliser plus qu'une autre.

            - tu démontres avec force que les brevets Kodak s'appliquent surement à Mono, je te renvoi là encore l'ascenseur : pourquoi ne supposes-tu pas que les brevets, éventuellement validés, sur .NET ne s'appliqueraient-ils pas non plus à Java ou tout autre plateforme ?

            Bref même si dans l'ensemble tes arguments sont pertinents et ton argumentation bien construite, le tout est vraiment biaisé de par le choix des arguments. C'est un bon article mais loin d'être exhaustif et ne peut pas à mon avis faire office de référence et synthèse du problème.

            Les brevets logiciels ca puxorise.

            --
            MonoFrance

            • [^]Re: héhé

              Posté par boubou (page perso, ) le 17/06/2005 à 09:03. (lien). Évalué à 2.

              il y a eu normalisation de nombreux standards où Microsoft s'est activement impliqué, comme XML, XSL, XSD, XPath & Co.

              Les standards que tu cites sont développés dans le cadre du W3 qui exige des licences royalty free. Donc soit MS collabore et fait du royalty free, soit MS ne collabore pas. Je ne vois pas ici d'argument montrant que .NET sera sous licence royalty free, même pour la partie CLI/C#.

              De plus, tu sembles ne pas vouloir lire et comprendre les licences MS. Va voir par exemple la licence pour les schémas d'Office. Cette licence n'inclue pas le droit à la sous-licence. C'est le même problème que pour le sender-id. Ms veut bien l'interopérabilité (contraint par les procès anti-trust, je te le rappelle), mais ne veut pas vraiment du logiciel libre car les licences libres sont incompatibles avec l'interdiction de faire des sous-licences.

              Et c'est en parfait adéquation avec mon premier argument qui tend à dire que MS cherchera à protéger sa valeur ajoutée, mais pas la partie normalisé (à part pour assurer le respect des standards, comme le fait Sun d'une autre manière).

              Il y a des innovations dans la partie normalisée, au coeur de celle-ci (en gros, ce qu'on ne retrouve pas dans d'autres langages comme les parties unsafe).

              pourquoi ne supposes-tu pas que les brevets, éventuellement validés, sur .NET ne s'appliqueraient-ils pas non plus à Java ou tout autre plateforme ?

              Cf autre réponse. L'expérience montre que Sun est prêt à défendre Java et les licences officielles. Ceci dit, je n'ai pas accès au texte exact de l'accord Kodak/Sun et il est possible que Kodak attaque un jour JBoss. En tout cas, c'est une hypothèse pas totalement débile.

              Bref même si dans l'ensemble tes arguments sont pertinents et ton argumentation bien construite, le tout est vraiment biaisé de par le choix des arguments. C'est un bon article mais loin d'être exhaustif et ne peut pas à mon avis faire office de référence et synthèse du problème.

              Ba voyons. Et pourquoi ce n'est pas une synthèse ? Il y a tous les faits que je connais. Tu voudrais ajouter quoi ?

              • [^]Re: héhé

                Posté par TImaniac (page perso, ) le 17/06/2005 à 09:31. (lien). Évalué à 2.

                Je ne vois pas ici d'argument montrant que .NET sera sous licence royalty free, même pour la partie CLI/C#.
                C'est pas ca que j'ai essayé de montrer. J'ai essayer de montrer que MS cherchait à utiliser des "standards" technique pour faciliter l'interopérabilité (tous leurs discours actuels vont dans ce sens). Après ils cherchent à protéger leur valeur ajoutée, ce qui fait leur spécificité. D'où la comparaison avec .NET.

                Va voir par exemple la licence pour les schémas d'Office.
                Pour moi Office c'est la valeur ajoutée aux normes XML au même titre que WinForms/ASP.NET est la valeur ajoutée aux normes CLI/C#. Donc de ce point de vue je te rejoins.

                en gros, ce qu'on ne retrouve pas dans d'autres langages comme les parties unsafe
                Oué mais là j'ai pas vu de brevet à ce sujet.

                L'expérience montre que Sun est prêt à défendre Java et les licences officielles.
                Bof même pas besoin de le supposer. MS et Sun ont passé des accords pour ne pas s'attaquer mutuellement donc de ce côté y'aura pas de problème. Par contre MS pourrait attaquer une implémentation libre de Java au même titre que Kodak pourrait attaquer JBoss. Bref c'est aussi dangereux.

                Il y a tous les faits que je connais. Tu voudrais ajouter quoi ?
                Je voudrais virer les exemples sur SenderID ASF et Samba alors que les objectifs et intérêt de MS ne sont pas du tout les mêmes. C'est un exemple parfait de comparaison foireuse pour conclure sur autre chose.

                Je voudrais que tu conclues en disant que le vrai problème est dans l'utilisation des API spécifiques à Microsoft non normalisés, que c'est cette partie que MS cherchera à protéger. Cela enlèvera à Mono un atout : la compatibilité avec de nombreux API MS. D'où l'idée de n'encourager l'utilisation que des parties normalisées et des API spécifiques à Mono.

                --
                MonoFrance

                • [^]Re: héhé

                  Posté par boubou (page perso, ) le 17/06/2005 à 09:46. (lien). Évalué à 2.

                  Je voudrais virer les exemples sur SenderID ASF et Samba alors que les objectifs et intérêt de MS ne sont pas du tout les mêmes. C'est un exemple parfait de comparaison foireuse pour conclure sur autre chose.


                  Et pourquoi les objectifs et intérêts ne sont pas les mêmes ? Qu'est-ce que tu en fais ? Le Sender-ID est typiquement comparable à la partie normalisée de .NET. C'est un standard qui n'a d'intérêt que s'il est utilisé par le plus grand nombre, MS l'apporte (en partie) dans une discussion ouverte de l'IETF (encore plus ouvert que l'ECMA et l'ISO) et boum, la licence royalty free proposée est incompatible avec une implémentation open source. Je ne comprends pas la différence avec .NET.

                  Pour Samba, le parallèle est justifié pour les bibliothèques "serveur" de .NET, nous sommes d'accord sur ce point. Et la comparaison avec Java n'est pas flatteuse pour .NET puisque que c'est justement sur l'aspect serveur que Java est le plus ouvert.

                  Je voudrais que tu conclues en disant que le vrai problème est dans l'utilisation des API spécifiques à Microsoft non normalisés, que c'est cette partie que MS cherchera à protéger. Cela enlèvera à Mono un atout : la compatibilité avec de nombreux API MS. D'où l'idée de n'encourager l'utilisation que des parties normalisées et des API spécifiques à Mono.


                  Mais c'est totalement incomplet ! Le vrai problème c'est qu'on n'a pas d'engagement à valeur légale de MS sur la partie standardisée et que les engagements du passé sur d'autres technologies sont soit incompatible avec toutes les licences libres, soit incompatibles avec la GPL.

                  • [^]Re: héhé

                    Posté par TImaniac (page perso, ) le 17/06/2005 à 10:06. (lien). Évalué à 2.

                    Oué pour SenderID effectivement le rapprochement est valable vu comme ca.

                    Pour Samba c'est quand même nettement plus tiré par les cheveux.

                    Le vrai problème c'est qu'on n'a pas d'engagement à valeur légale de MS sur la partie standardisée et que les engagements du passé sur d'autres technologies sont soit incompatible avec toutes les licences libres, soit incompatibles avec la GPL.
                    Oué enfin en l'occurence seul le compilo est sous GPL, et je vois pas quel brevet va empêcher Mono de parser un fichier C# pour produire du code...

                    Le vrai problème c'est qu'on n'a pas d'engagement à valeur légale de MS sur la partie standardisée
                    Là on est d'accord, c'est pourquoi on discute justement des intentions :)
                    Enfin ce que raconte un MSkyLight2 à propos des engagements à propos de l'ECMA est intéressant je trouve. Novell faisant parti du commité de normalisation ils sont je penses bien placés pour connaître les risques éventuels. Ce qu'ils traduisent dans leur FAQ.

                    Enfin ca me fait bien marrer quand même le coup de "c'est pas compatible avec la GPL". De toute façon beaucoup s'accordent à dire que les brevets logiciels sont incompatibles avec la GPL, alors même si Sun "autorise" l'utilisation de ses brevets j'ai des doutes sur la réelle "immunité" des programmes sous GPL. Il est intéressant de noter que même si Sun autorise actuellement l'utilisation de ses brevets ils peuvent à tout moment changer de licence, les implémentations actuelles seront toujours valides (une licence acquise l'est définitivement) mais elle remet en cause de nouvelles implémentation ou des travaux dérivés des implantations existantes (ce qu'autorise la GPL).
                    N'oublions pas que Sun a passé des accords avec MS, que Sun a toujours fait preuve de grandes contradictions quand à leur soutien aux logiciels libres. Un changement de licence est donc tout à fait possible, même si je n'y crois pas trop à court terme.

                    Enfin n'empêche que tous ces brevets peuvent s'appliquer à d'autres plateformes, et que ces autres plateformes sont donc toutes aussi dangereuses à utiliser, pas moins que ne l'ai Mono.

                    --
                    MonoFrance

          • [^]Re: héhé

            Posté par M_Skylight2 () le 17/06/2005 à 08:34. (lien). Évalué à 2.

            Je reconnais que l'argument ressemblait plus à du FUD qu'autre chose mais bon. ;-)
            AU sujet de Mono, on peut distinguer 3 parties, la première étant la partie standardisé par ECMA, l'ECMA pose comme condition à ses membres de renoncer à l'exercice de leur brevet sur tout les standards qu'ils ont déposé et à les licencier selon le principe RAND. EN théorie, Microsoft aurait le droit de demander par exemple 1$ sur chaque copie de Mono, ce qui serait tout à fait raisonnable et aussi incompatible avec le libre, mais vous oubliez le fait que l'ECMA demande aussi au dépositaire du standard de statuer définitivement sur leur politique de licences et dans le cas ou le standard utilise un brevet connu au moment du vote venant d'une tierce partie , d'un accord écrit. Donc sur cette partie, Microsoft a joué le jeu, je doute que Novell ait poursuivi le projet Mono sans s'etre assuré qu'il n'y avait aucun risque, de plus, Novell participe activement aux travaux de l'ECMA avec Microsoft et HP. Donc le coeur de Mono ne pose pas plus de problème que Java, même si la politique de Microsoft reste obscure pour le grand public.
            La seconde partie est elle bien plus problèmatique, car elles concernent les API non standardisés comme ADO.net, ASP.net et les winforms, or ce sont le fer de lance de Microsoft dans le developpement de webservices, donc potentiellement une source de revenu importante, jusqu'à Mono, ASP.net ne tournait que sur IIS donc sur du windows, donc de juteuses licences serveurs. Désormais, il y a un mod apache permettant de faire tourner asp.net sous n'importe quel serveur unix-like. C'est là le véritable coeur du problème, ces APIs sont celles ou Microsoft n'a aucun engagement, soit on brise la compatibilité, soit on casse Mono, soit on joue le jeu. Soyons pessimiste et que Microsoft veuille casser Mono, Novell a 2 possibilités: faire passer ces APIs sous licence proprio et payer une licence à Microsoft, soit contourner les brevets Microsoft, dans aucun cas, le coeur de Mono n'est touché, ça génera sa progression en entreprise, sur la plateforme win32.
            Quant à la 3ème partie, les APIs particulières de Mono: gtk#, gnome#, cocoa#, gecko# .....etc, elles ne posent pas plus de problèmes que la plupart des projets libres.
            Avec Java, on a le même problème GCJ, Kaffe et cie, aucune n'implémentent entièrement Java2, malgré que ces implémentations soient largement diffusés dans le monde du libre, SUN pourrait tout à fait les écraser si il le voulait, je suis sur qu'écraser GCJ leur ferait très plaisir, surtout que ça ferait bien chier RH, leur véritable concurrent.
            D'un coté, on a une implémentation fonctionnelle entièrement libre d'une techno proprio à demi-standardisé, qui malgré les risques de brevets, a de bonnes chances de perdurer notamment sur le desktop, les APIs visant les entreprises étant elles sérieusement menacés. Et de l'autre, des implémentations incomplétes sur le desktop, jusqu'à très récemment inutilisable, qui risque potentiellement à tout moment d'etre stoppé par SUN , et des implémentations des APIs visant les serveurs certifié donc qui n'ont rien à craindre de Sun.
            Bien entendu, on peut aussi supposer que Novell bluffe et que Microsoft dans sa politique de licence n'autorise pas les implémentations libres du coeur de .Net, mais je doute que les devs qui travaille dessus l'ait accepté aussi facilement.

            --
            le méchant de service :-)

            • [^]Re: héhé

              Posté par boubou (page perso, ) le 17/06/2005 à 09:10. (lien). Évalué à 2.

              Donc sur cette partie, Microsoft a joué le jeu, je doute que Novell ait poursuivi le projet Mono sans s'etre assuré qu'il n'y avait aucun risque, de plus, Novell participe activement aux travaux de l'ECMA avec Microsoft et HP.

              Où est l'accord écrit ? Tout ça est un ensemble de suppositions.

              Avec Java, on a le même problème GCJ, Kaffe et cie, aucune n'implémentent entièrement Java2, malgré que ces implémentations soient largement diffusés dans le monde du libre, SUN pourrait tout à fait les écraser si il le voulait, je suis sur qu'écraser GCJ leur ferait très plaisir, surtout que ça ferait bien chier RH, leur véritable concurrent.

              Ouai, suppositions que tout ça. Les faits c'est que Sun a permis et faciliter la standardisation officielle de JBoss et Jonas alors que les deux produits lui bouffent énormément de parts de marché. Donc je ne vois pas pourquoi ils attaqueraient GCJ. Et de plus, la licence d'implémentation (avec le point sur le brevet) est disponible depuis des années sur le site de Sun donc on connaît les conditions légales pour implémenter Java et elles sont compatibles avec l'open source.

              • [^]Re: héhé

                Posté par M_Skylight2 () le 17/06/2005 à 12:09. (lien). Évalué à 0.

                1.1
                In case the proposed Standard is covered by issued patents of Ecma members only: Members of the General Assembly are asked to state the Company licensing policy with respect to these patents.

                L'ECMA est claire, pour que les propositions ECMA-334 et ECMA-335 soient accepté, Microsoft en tant que membre ayant droit de vote à l'assemblée Générale a du statué sur sa politique de licence vis à vis des brevets couvrant ces normes. Novell en tant qu'associate member n'a pas le droit de vote à l'AG mais participe aux comités techniques dont ceux couvrant la CLI et C# et ont accès à toute la documentation nécessaire.
                Donc Microsoft a bel et bien une position claire au sujet des brevets lui appartenant couvrant Mono et autres implémentations du framework .Net, c'est un problème de communication. En l'absence de déclaration publique de Microsoft, doit-on croire le service juridique de Novell qui s'est penché sur la question et a eu accès à toutes les données ou RedHat qui justement n'a pas intérêt à ce que .Net se developpe et pousse Java sur lequel repose toute leur stratégie ?
                Je rappelle que comme SUN, dans les faits Microsoft n'a rien fait contre les implémentations libres de son framework bien au contraire, Novell participe activement à l'élaboration des specs et il y a de nombreux échanges entre l'équipe dotnet et Mono alors que les implémentations libres de Java sont condamnés à suivre les specs de SUN, contrairement à l'ECMA, les travaux du JCP sont controlé par un seul acteur et loin d'etre ouvert. Donc je pourrais vous retourner la balle en vous disant que votre opinion au sujet de SUN et des implémentations libres de Java ne sont que des suppositions car rien ne garantit que SUN fasse stopper la distribution de GCJ.
                Si je me rappelle bien , la licence de SUN oblige à fournir une implémentation complète de ses specifications, or avec GCJ on est loin du compte pour qu'elle soit légale. Pour JBoss et Jonas, on est dans un cas différent car ce sont des implémentations complètes et qui pour le moment ont toujours besoin d'utiliser une implémentation proprio de Java pour tourner en production dans les faits. COntrairement à Mono qui porte réellement atteinte à .Net , GCJ ne porte nullement atteinte au business plan de SUN, quant à JBoss et Jonas, ils auront toujours un train de retard sur l'implémentation de SUN qui est passé à Java 1.5.

                --
                le méchant de service :-)

                • [^]Re: héhé

                  Posté par TImaniac (page perso, ) le 17/06/2005 à 14:00. (lien). Évalué à 2.

                  Héhé boubou ca tu peux je rajouter dans ton document ;)

                  --
                  MonoFrance

                • [^]Re: héhé

                  Posté par boubou (page perso, ) le 17/06/2005 à 17:13. (lien). Évalué à 2.

                  In case the proposed Standard is covered by issued patents of Ecma members only: Members of the General Assembly are asked to state the Company licensing policy with respect to these patents.

                  L'ECMA est claire, pour que les propositions ECMA-334 et ECMA-335 soient accepté, Microsoft en tant que membre ayant droit de vote à l'assemblée Générale a du statué sur sa politique de licence vis à vis des brevets couvrant ces normes.

                  Oui et alors ? Qui te dis que la politique en question n'est pas "royalty free and otherwise rand", ce qui ne veut rien dire et ne garantit rien ? Pourquoi faut-il que je répète encore et encore que même royalty free n'implique pas comptible avec une implémentation libre (cf ASF, Sender-Id, etc.). Et en plus, tu ne cites que le point 1.1 de la politique général de l'ECMA (cf http://www.ecma-international.org/memento/codeofconduct.htm(...) pour le texte complet). Si tu lis attentivement le réglement complet, tu trouveras très clairement que rien n'est exigé à part du RAND et qu'aucune déclaration formelle n'est obligatoire car ne rien dire implique RAND (cf le point 2.4).

                  Novell en tant qu'associate member n'a pas le droit de vote à l'AG mais participe aux comités techniques dont ceux couvrant la CLI et C# et ont accès à toute la documentation nécessaire.

                  Quelle documentation ? La déclaration de MS sur les brevets ? Mais il suffit à MS de dire RAND pour que tout soit terminé. Il n'est indiqué nulle part que MS doit proposer un modèle licence complèt ! De plus on trouve à l'URL http://www.ecma-international.org/memento/guidance.htm(...) des modèles de déclaration pour les brevets qui ne donnent aucune précision autre que RAND.

                  Bref, rien dans le processus de l'ECMA ne permet d'affirmer que MS fera autre chose que du RAND (ce qu'il est obligé de faire pour la partie couverte par les standards).

                  En l'absence de déclaration publique de Microsoft, doit-on croire le service juridique de Novell qui s'est penché sur la question et a eu accès à toutes les données ou RedHat qui justement n'a pas intérêt à ce que .Net se developpe et pousse Java sur lequel repose toute leur stratégie ?

                  Ni l'un, ni l'autre. Novell s'est contenté d'une déclaration qui dit "on a regardé, il n'y a pas de problème" et d'un lien vers un mail sans aucune valeur juridique. Si Novell publie un rapport complet, avec une analyse détaillé des brevets qui démontre que Mono les contourne, je commencerais à croire Novell. Pour l'instant, c'est du vent.

                  Je rappelle que comme SUN, dans les faits Microsoft n'a rien fait contre les implémentations libres de son framework bien au contraire, Novell participe activement à l'élaboration des specs et il y a de nombreux échanges entre l'équipe dotnet et Mono

                  C'est vrai, j'ajouterais ça dans mon texte dans une prochaine révision.

                  lors que les implémentations libres de Java sont condamnés à suivre les specs de SUN, contrairement à l'ECMA, les travaux du JCP sont controlé par un seul acteur et loin d'etre ouvert.

                  N'importe quoi. Relis mon texte et sa description complète du JCP. Apache est membre du JCP, par exemple. Et le JCP standardise TOUT Java, contrairement à l'ECMA qui n'a qu'une petite partie de .NET sous sont contrôle.

                  Donc je pourrais vous retourner la balle en vous disant que votre opinion au sujet de SUN et des implémentations libres de Java ne sont que des suppositions car rien ne garantit que SUN fasse stopper la distribution de GCJ.

                  Sun peut faire stopper la distribution de GCJ tant que celle-ci n'est pas compatible avec la spec 1.4. Tous les jours, l'écart diminue et Sun est de moins en moins en position de stopper la distribution de GCJ. Mais c'est une éventualité, en effet. Et je l'ai largement indiqué dans mon texte.

                  COntrairement à Mono qui porte réellement atteinte à .Net , GCJ ne porte nullement atteinte au business plan de SUN,

                  Donc Sun n'a aucun intérêt particulier à stopper GCJ.

                  quant à JBoss et Jonas, ils auront toujours un train de retard sur l'implémentation de SUN qui est passé à Java 1.5.


                  Totalement ridicule. J2EE 1.5 n'existe pas ! Tout le monde utilise J2EE 1.4 avec en sous jacent une JVM 1.5. JBoss et Jonas ne sont absolument pas en retard sur le serveur de Sun. Comme la spécification de J2EE 1.5 se fait de façon relativement ouverte, JBoss et Jonas contiennent déjà des briques de cette future version. De plus, certains gros morceaux de JBoss et de Jonas tournent sur des versions libres de la JVM. C'est le cas de Tomcat, par exemple.

      • [^]Re: héhé

        Posté par boubou (page perso, ) le 17/06/2005 à 08:45. (lien). Évalué à 2.

        Chacun sa traduction hein.

        Mais bien sûr. La phrase complète est But Microsoft (and our co-sponsors, Intel and Hewlett-Packard) went further and have agreed that our patents essential to implementing C# and CLI will be available on a "royalty-free and otherwise RAND" basis for this purpose.

        Explique moi un instant pourquoi l'ingénieur de chez MS n'a pas utilisé le mot "and" seul ? Parce que ça ne veut rien dire ! On ne peut pas être à la fois royalty-free et RAND, sauf si on interprète RAND comme royalty-free, ce qui n'est évidemment pas le cas. La présence du otherwise est cruciale puisqu'elle montre qu'il y a justement une différence. Et on ne sait pas au final quels seront les critères de décision de MS pour le choix entre ces alternatives.

        De plus, ce mail n'a AUCUNE valeur légale. Ne trouve tu pas étrange que le site web de MS qui contient de nombreux modèles d'accord de licence n'en propose aucun pour .NET ?

        Enfin, obtenir une licence royalty-free ne signifie en aucun cas que tu pourras redistribuer une implémentation open source, comme je le démontre par des exemples de chez Microsoft dans le texte.

        Oué mais justement j'ai pas trouvé, d'où ma demande.

        Et bien va lire le brevet : http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HIT(...) (et c'est seulement un des brevets). Il est possible que certaines API ne soient pas couvertes, ceci dit. Dans une révision de mon article, je remplacerais toute l'API par une grande partie de l'API, ça sera plus prudent.

        Evidemment que MS peut obtenir des brevets qui peuvent être "génant" pour Mono. Mais les APIs de MS n'innovent quasiment pas, alors soient d'autres plateformes seront impactés (autour des web services comme le laisse entendre une des tes sources), soient un prior-art sera démontré.

        En effet, tout est possible dans le monde des Bisounours. Le problème est qu'il suffit de ne pas pouvoir implémenter UN appel de méthode ou UNE classe pour que tout tombe à l'eau.

        De plus, je ne considère pas les professions de foi des ingénieurs (même hauts placés) de MS comme des engagements. MS est une entreprise privée, dirigée par ses chefs. Il y a chez MS des gens très bien qui aimeraient faire plus d'open source, qui ne sont pas contre la GPL, etc. La direction les laisse collaborer avec l'extérieur et même produire de l'open source. Mais à la fin, c'est la direction qui décide, comme dans les autres entreprises. Je ne vois pas en quoi .NET n'est pas stratégique pour MS. Au contraire, je pense même que c'est un des projets les plus stratégiques pour Microsoft qui veut s'imposer de plus en plus au niveau serveur. Contrairement à ce que tu racontes, il n'y a aucune raison pour que MS ne défende pas très fortement .NET. Et d'ailleurs tu le dis toi même au sujet des API non standardisées. Et au fait, ASF n'est pas un codec mais un format de fichier...

        Pourquoi tu ne reprends pas mon argumentation, la 2ème partie de mon post ?

        Parce que ça n'a aucun intérêt. Le bla bla sur Mono n'est pas plus dangereux que le noyau linux parce qu'il existe pleins de brevets logiciels n'apporte rien à la discussion et nie la spécifificité de .NET (ou de Java, c'est pourquoi je n'ai pas utilisé ce "non argument" au sujet de Java). Les brevets sur .NET on pour but explicite de protéger .NET, alors que les brevets qui peuvent toucher linux ont pour but de protéger certaines fonctionnalités qu'on peut être ammené à inclure dans un noyau. Ce n'est pas la même chose.

        Quant à la solution, elle est toute trouvée, obtenir l'accord officiel de Microsoft ou de Sun pour les implémentations open source de leur technologie. Et alors que tu te gargarises de documents sans valeur légale (comme le fameux mail tant cité), dans le monde Java, des accords officiels ont déjà été passés. C'est le point que les gens de mauvaise foi comme toi passent toujours sous silence : une partie de Java est implémenté en open source de façon officielle, avec l'accord signé de Sun. Il s'agit bien sur de la partie J2EE en version 1.4 implémentée par JBoss et par Jonas. C'est ces faits qui prouvent que la situation est différente : SUN est officiellement d'accord pour qu'au moins certaines parties de Java soient implémentées sous forme libre.

        Enfin, le bla bla sur la protection des utilisateurs est comique. Où sont les versions forkées de Perl et de Python, pour ne prendre que ces exemples ?

        En conclusion, je ne te trouve pas très constructif. Tu ne cesses de t'abriter derrière de supposition, en ne retenant des documents disponibles sur le web que les moins officiels et en refusant d'apprendre du passé. Tu te caches derrière Novell qui "a étudié les brevets en question", etc. N'es tu pas capable de lire les brevets et de te faire une opinion ? Puisque que tu aimes les arguments d'autorité, pourquoi croire plus Novell que RedHat ?

        • [^]Re: héhé

          Posté par TImaniac (page perso, ) le 17/06/2005 à 09:21. (lien). Évalué à 2.

          Mais bien sûr.
          Blablabla, je préfères m'en tenir à l'interprétation de Novell. Eux n'ont pas le problème de la traduction et sont surement plus compétent que moi (toi je sais pas) pour interprêter ce mail.

          Ne trouve tu pas étrange que le site web de MS qui contient de nombreux modèles d'accord de licence n'en propose aucun pour .NET ?
          Y'a rien d'étrange, ils ne vont pas faire un document officiel sur un brevet qui n'existe pas encore.

          Enfin, obtenir une licence royalty-free ne signifie en aucun cas que tu pourras redistribuer une implémentation open source
          Là encore je me réfère à la FAQ de Mono : eux ont compris "any purpose". Là encore je préfère m'en tenir à leur interprétation.

          Dans une révision de mon article, je remplacerais toute l'API par une grande partie de l'API, ça sera plus prudent.
          Il serait tout de même judicieux que tu précises que cela concerne sûrement les API non normalisés, en précisant qu'il est impensable de protéger par un brevet les API normalisés (prior-art, pas innovant, etc.)

          Le problème est qu'il suffit de ne pas pouvoir implémenter UN appel de méthode ou UNE classe pour que tout tombe à l'eau.
          Pour peux que la méthode soit aussi présente dans son cousin Java et t'as exactement le même problème. A l'exception que MS pourrait attaquer les dev de cette implémentation car n'étant pas dans le cadre de la mise en place d'une CLI/CLR. Là l'implémentation Java serait même plus risquée ;)
          Au pire Novell l'a dit : on vire le truc en question et basta.

          il n'y a aucune raison pour que MS ne défende pas très fortement .NET. Et d'ailleurs tu le dis toi même au sujet des API non standardisées.
          Tout à fait, je penses comme toi que le problème viendrait surement de la partie non normalisée. Au pire on s'en passe et basta Mono perdra une bonne partie de la compatibilité mais on aura toujours une plateforme complète avec l'interopérabilité technique de base, essentielle au développement d'API multi-plateforme. Tant pis si ceux de MS ne le sont pas.

          Et au fait, ASF n'est pas un codec mais un format de fichier...
          Oué oué oué enfin ASF c la plupart du temps associé aux codecs WMV, et si mes souvenirs sont bons VirtualDub s'est fait enmerder pour l'ensemble, pas juste le format d'encapsulation.

          Ce n'est pas la même chose.
          mais ca rend tout de même l'utilisation du noyau illégale et une entreprise (au pif MS) peut y voir une concurrence et attaquer. Pour .NET si les brevets sont utilisés pour implémenter les standards MS n'y a que des avantages, par contre ils peuvent attaquer en qu'à d'utilisation dans une autre utilisation (genre dans Java ?)...

          Et alors que tu te gargarises de documents sans valeur légale
          Genre les tiens sont légals :)

          Tu te caches derrière Novell qui "a étudié les brevets en question", etc. N'es tu pas capable de lire les brevets et de te faire une opinion ?
          Ben j'avoue que le jargon technique voilà quoi. y'a aussi la barrière de la langue qui fait que c'est facile de donner un autre sens en traduisant. Je préfère traduire la vulgarisation qu'en a fait Novell qui a au moins virer la barrière du jargon juridique.

          Puisque que tu aimes les arguments d'autorité, pourquoi croire plus Novell que RedHat ?
          Parcque Novell dit : "on a étudié, on a rien trouvé d'enmerdant"
          RedHat : "oué on sait pas trop ce qu'il en est, dans le doute on fait pas".
          A noter qu'en plus il n'y a pas de position officielle de RedHat, seulement d'un ou 2 développeurs, alors que la position de Novell est la position officielle. Autant dire que pour moi cela n'a pas du tout la même valeur.

          Enfin tu ne m'expliques toujours pas pourquoi MS a normalisé et standardisé les bases techniques de sa plateforme, tu ne m'expliques pas pourquoi ils ont diffusé une implémentation pour montrer comment faire, tu ne m'expliques pas pourquoi MS n'a jamais râlé sur Mono et l'a au contraire encensé.
          Tu dis que je refuses d'apprendre le passé. Toi tu prends des citations d'il y a 3 ans et tu refuses de constater les faits.

          Moi je cherche juste à montrer qu'il n'est pas plus dangereux d'utiliser Mono qu'autre chose.

          --
          MonoFrance

          • [^]Re: héhé

            Posté par boubou (page perso, ) le 17/06/2005 à 09:40. (lien). Évalué à 2.

            Il serait tout de même judicieux que tu précises que cela concerne sûrement les API non normalisés, en précisant qu'il est impensable de protéger par un brevet les API normalisés (prior-art, pas innovant, etc.)

            Putain, mais va lire le brevet ! Tu es borné ou quoi ? System.Collections c'est pas dans le standard, peut être ?

            Genre les tiens sont légals :)

            Je parle de valeur légale du document. Tu ne comprends pas le français ? Le texte d'accord de licence disponible sur le site de Sun est un document à valeur légale qui correspond à un engagement entre Sun et le signataire. Ce document indique explicitement qu'une implémentation de Jave en open source est possible, sans enfreindre les brevets associés. Il n'y a pas de document équivalent sur le site de Microsoft au sujet de .NET. Il n'y a que des documents sans valeur légale comme le fameux mail ou des interviews.

            Parcque Novell dit : "on a étudié, on a rien trouvé d'enmerdant"
            RedHat : "oué on sait pas trop ce qu'il en est, dans le doute on fait pas".
            A noter qu'en plus il n'y a pas de position officielle de RedHat, seulement d'un ou 2 développeurs, alors que la position de Novell est la position officielle. Autant dire que pour moi cela n'a pas du tout la même valeur.


            La position officielle de RedHat est de ne pas distribuer Mono. On ne sait pas officiellement pourquoi.

            tu refuses de constater les faits.

            Quels faits ? Que les développeurs de MS aident ceux de Mono ? Et alors, pendant combien de temps Linus a-t-il utilisé bitkeeper ?

            Moi je cherche juste à montrer qu'il n'est pas plus dangereux d'utiliser Mono qu'autre chose.

            On a bien compris. Je ne parle pas de danger mais de risque. Il est possible aujourd'hui de réaliser une implémentation Open source de Java, des documents qui engagent Sun sont disponibles sur le site correspondant. On ne sait pas si une implémentation complète existera un jour et on ne sait pas si d'autres brevets n'empêcherons pas cette implémentation. La situation est radicalement différente pour .NET : on ne sait pas si une implémentation open source est possible car aucun document en valeur légale n'est disponible publiquement concernant ce point. Tu peux raconter tout ce que tu veux à ce sujet, je ne vois pas comment contourner ce fait.

            • [^]Re: héhé

              Posté par TImaniac (page perso, ) le 17/06/2005 à 10:12. (lien). Évalué à 2.

              System.Collections c'est pas dans le standard, peut être ?
              Euh System.Collections n'a strictement rien d'innovant, ils peuvent toujours essayer et obtenir un brevet, un prior art sera facile à démontrer.

              Ce document indique explicitement qu'une implémentation de Jave en open source est possible, sans enfreindre les brevets associés
              Aujourd'hui mais demain ?

              On ne sait pas officiellement pourquoi.
              C'est bien pour ca que je prends pas leur avis en compte :) La plupart des autres distributions ont intégrés Mono, seul RedHat fait de la résistance sans donner d'explication.

              La situation est radicalement différente pour .NET : on ne sait pas si une implémentation open source est possible car aucun document en valeur légale n'est disponible publiquement concernant ce point.
              Ah non !
              A l'heure actuelle il n'y a absolument rien qui empêche une implémentation libre de Mono, MS n'a pas donné son autorisation et n'a pas à la donner : il n'a pas encore les brevets pour le protéger.
              Donc peut être que demain MS fera chier. Aussi vrai que peut être que demain Sun fera chier. Donc c'est exactement pareil. Surtout que les brevets MS peuvent s'appliquer à Java.

              Imaginons qu'un des brevets soient violer dans Java par Sun, Sun et MS ayant passé un accord ils ne s'attaquent pas mutuellement, mais MS demande à Sun de plus autoriser l'utilisation des brevets en question dans des implémentations libre. que pasa ?

              --
              MonoFrance

              • [^]Re: héhé

                Posté par bobefrei () le 19/06/2005 à 09:55. (lien). Évalué à 4.

                Euh System.Collections n'a strictement rien d'innovant, ils peuvent toujours essayer et obtenir un brevet, un prior art sera facile à démontrer.


                Les entreprises comme Microsoft et Sun détiennent des brevets pour lesquels il est possible de démontrer un "prior art". Seulement qui dans le monde libre va leur faire un procès? Un procès est un processus long, couteux et pénible. En plus sur ce genre de problème, il faudrait faire un procès dans chaque pays ou zone juridique. Mêmes les multinationales qui ont des services juridiques capables de le supporter réflechissent à deux fois avant de faire un procès.


                A la lecture de tes posts, tu sembles convaincu que Microsoft ne posera pas de problème par rapport à un projet libre comme Mono. En plus des divers liens donnés ici, j'aimerai rajouter une petite histoire:

                Lorsque j'étais membre du bureau de la Junior Entreprise de mon école, j'ai eu à remplacer quelqu'un pour aller chez Microsoft. Je ne savais pas trop de quoi il s'agissait et une fois là bas je me suis retrouvé dans un brainstorming sur un projet de site web destiné à faire la promotion de Microsoft aux élèves d'écoles d'ingénieurs. Tout d'un coup la discussion a dérivé sur les licences et sur les logiciels libres. Je leur ai dis que je pensais qu'il était inutile pour eux de se justifier sur un tel site. Les employés de Microsoft sont devenus hargneux et m'ont fait clairement comprendre que le libre était l'enemi a abattre. Ils avaient presque la bave aux lèvres en disant que c'était "franco-français" (l'insulte suprême chez eux apparemment...) de penser qu'on pouvait tout avoir gratuitement et que ça allait détruire l'industrie du logiciel. Microsoft considère que les logiciels libres sont des concurrents et comme tout concurrent, ils doivent être soit écrasés soit réduit à une part de marché négligeable.

                • [^]Re: héhé

                  Posté par M_Skylight2 () le 20/06/2005 à 13:49. (lien). Évalué à 1.

                  C'est le but de la FSF, c'est pour cela qu'ils demandent aux devs de leur céder leur copyright afin de pouvoir protéger efficacement les LL en cas de procès.

                  --
                  le méchant de service :-)

licence du doc

Posté par baud123 (Jabber id, page perso, ) le 16/06/2005 à 15:34. (lien). Évalué à 2.

Sans vouloir passer pour un intégriste, ta phrase m'a fait réfléchir :
"J’ai pour objectif de faire évoluer l’article dans les mois qui viennent afin de le maintenir à jour."

Je ne vois pas comment c'est compatible avec la licence retenue pour le document :
"Cette création est mise à disposition selon le Contrat Paternité - Pas d’Utilisation Commerciale - Pas de Modification disponible en ligne http://creativecommons.org/licenses/by-nc-nd/2.0/fr/(...) "

La licence précise "Chacune de ces conditions peut être levée si vous obtenez l'autorisation du titulaire des droits."

A chaque page du PDF apparaît le copyright commun entre GMLF et toi-même, tu ne peux pas décider unilatéralement de faire une modification. ça c'est un 1er point.
Perso, ce qui me gêne un peu plus c'est que si (à tout hasard) je souhaitais en faire une traduction en anglais, l'article pouvant intéresser un public plus large, je n'en ai pas la possibilité : seul toi et GLMF. ça m'empêche aussi de le mettre à dispo sur un wiki pour se mettre à plusieurs à le traduire (toutes les personnes n'étant pas forcément identifiées...).

Si c'était l'effet souhaité, après ça te regarde (et GLMF).
Y-avait-il un point bloquant à le mettre en CC-BY-SA par exemple ? Voire Art Libre ? (c'est une vraie question)

  • [^]Re: licence du doc

    Posté par boubou (page perso, ) le 16/06/2005 à 16:24. (lien). Évalué à 4.

    J'ai l'autorisation de Denis pour faire évoluer le document. Effectivement, personne d'autre ne peut faire des modifications et/ou des traductions. Comme j'ai vendu ce texte aux Editions Diamond, je trouve ça parfaitement normal. Cependant, il est tout à fait possible que j'obtienne un jour le droit de passer le texte en vraiment libre, ce que j'aimerais. Mais un refus des Editions Diamond me semblerait aussi parfaitement légitime. Bref, ce document, financé par les Editions Diamond, est mis à disposition du public gratuitement et si j'en ai le temps sera maintenu. C'est le mieux que je puisse faire actuellement.

  • [^]Re: licence du doc

    Posté par boubou (page perso, ) le 17/06/2005 à 07:27. (lien). Évalué à 1.

    Au fait, j'ai oublié un point très important : il est très peu probable que j'autorise la diffusion de versions modifiées. Ce texte comporte une grande partie factuelle, mais aussi mon opinion et je ne veux pas qu'une version modifiée reprenne les faits et propose une conclusion différente. Pour que j'autorise ça, il faudrait que le texte change de titre, et que ma conclusion reste présente verbatim (ou presque).

    • [^]Re: licence du doc

      Posté par baud123 (Jabber id, page perso, ) le 17/06/2005 à 10:08. (lien). Évalué à 3.

      Tu peux lire cette analyse de la GFDL qui répond à quelques unes de tes craintes :
      http://home.twcny.rr.com/nerode/neroden/fdl.html(...)

      => oui tout texte, aussi factuel qu'il soit exprime ton opinion, mais :
      - la déformer constitue un faux que ta version en ligne permettra de corroborrer/infirmer
      - du fait du copyright, un texte dérivé porte le nom de l'auteur ayant fait les modifications... ce n'est plus seulement ton opinion qui est exprimée...

      Après faut choisir d'assumer de faire du libre ou pas : oui cela se passe sur le net visible de tout le monde, oui c'est beaucoup plus difficile à rattrapper quand par mégarde ou inattention on dit une bêtise, oui les rumeurs peuvent se propager à vitesse grand V... m'enfin faut pas être parano non plus je crois ;-)

      Ton article est de bonne facture et avait été salué à sa sortie si je me rappelle bien (je ne réussis plus à mettre la main sur une URL) néanmoins ça me paraît bizarre de choisir une licence à l'image même de ce que tu analyses (troll intended ;-) ).

      • [^]Re: licence du doc

        Posté par boubou (page perso, ) le 17/06/2005 à 11:47. (lien). Évalué à 2.

        Je comprends bien ton point de vue (j'espère ;-) et je vois bien ses justifications. Je ne sais pas trop quelle licence choisir pour un texte qui à la fois protège mon opinion et d'un autre côté permette une liberté maximale pour les utilisateurs et/ou éventuellement adaptateur et traducteur. Il est clair par exemple que si Timaniac prenait mon texte et l'adaptait à sa sauce, je serais vert et donc je ne veux pas ça. Par contre, une traduction, ça serait très bien. Je vais réflechir et en discuter de nouveau avec Denis Bodor.

Alternative

Posté par bobefrei () le 16/06/2005 à 16:15. (lien). Évalué à 3.

Si tu comptes faire évoluer, une piste serait peut être de parler des autres plateformes capables de concurrencer Java et .NET et de vérifier si elles sont vraiment libres.

Personnellement, j'en vois deux: Erlang et Python.

  • [^]Re: Alternative

    Posté par boubou (page perso, ) le 16/06/2005 à 16:39. (lien). Évalué à 3.

    C'est effectivement une bonne piste, mais les langages sont très différents du couple Java/C# et les API beaucoup moins riches. Il est donc assez difficile de comparer, à mon avis.

    • [^]Re: Alternative

      Posté par norbs () le 16/06/2005 à 22:13. (lien). Évalué à 2.

      Au moins pour Python, l'API est tout aussi riche qu'en java...

      • [^]Re: Alternative

        Posté par TImaniac (page perso, ) le 17/06/2005 à 06:54. (lien). Évalué à 2.

        T'as tout ca dans Python :
        http://java.sun.com/j2ee/1.4/docs/api/index.html(...)
        ?

        --
        MonoFrance

        • [^]Re: Alternative

          Posté par golum () le 17/06/2005 à 10:00. (lien). Évalué à 1.

          Non mais tu as ça
          http://www.python.org/doc/2.4.1/modindex.html(...)
          et ca
          http://twistedmatrix.com/(...)
          ou encore ca
          http://www.zope.org/Documentation/Books/ZopeBook/2_6Edition/Appendi(...)

          et si tu insistes tu as même ton api avec des structures de plus haut niveau
          http://www.onjava.com/pub/a/onjava/2002/03/27/jython.html(...)


          Jython also has features that allow nearly transparent usage of existing Java code. Java packages can be imported into Jython as though they were Jython modules, and Java objects can be created using Jython object creation syntax. For the most part, you can use the Java objects in your Jython program exactly as though they were Jython objects

          • [^]Re: Alternative

            Posté par boubou (page perso, ) le 17/06/2005 à 11:52. (lien). Évalué à 2.

            Oui, enfin, comme alternative à Java, Jython n'est pas très pertinent ;-)

            Il y a bien des choses très intéressantes qui tournent autour de Python mais franchement, l'API Java est tellement énorme que je doute vraiment qu'on trouve en Python tout ce qu'on trouve en Java. Par exemple, quid d'un moniteur transactionel à la JTA ?

            D'autre part et vraiment sans vouloir troller, existe-t-il en Python un IDE du nieavu d'Eclipse (ou de netbeans) ? Et les performances ? Je pense qu'on peut dire sans trop exagérer que les programmes Java sont tout de même plus performants en général que leur équivalent Python, non ?

            • [^]Re: Alternative

              Posté par TImaniac (page perso, ) le 17/06/2005 à 12:17. (lien). Évalué à 2.

              Sans parler des perfsn, on peut aussi parler du langage en soit : question sécurité Python n'offre rien du tout : pas de typage fort, la possibilité de modifier dynamiquement une classe, pas de notion d'interface, que des trucs rigolos mais parfaitement inutile dans un cadre industriel.

              Python est avant tout un langage de script, il n'a pas la même vocation que Java ou C#. On aura beau proposer des API similaires à Java il y aura toujours ses choix de conceptions qui en feront un mauvais choix dans des contextes ou la qualité et la sécurité sont prédominants.

              --
              MonoFrance

              • [^]Re: Alternative

                Posté par vrm (page perso, ) le 17/06/2005 à 12:42. (lien). Évalué à 3.

                bon au lieux de troller comme des veaux allez coder des API pour Eiffel ou ADA ;)

                • [^]Re: Alternative

                  Posté par boubou (page perso, ) le 20/06/2005 à 09:11. (lien). Évalué à 2.

                  Du calme ! On me suggère de parler dans mon article d'alternatives à .NET et à Java, et on me suggère Python et Erlang. Je ne connais pas le second. Pour le premier, je pense que la comparaison n'est malheureusement pas valide. Je dis bien malheureusement car je trouve que Python est un très beau langage. Ceci dit, c'est une question de maturité avant tout.

                  Quant à Eiffel et Ada, ce sont deux merveilleux langages, mais comme tu le dis indirectement, ils manquent énormément d'API et je ne vois pas ce qu'un pauvre développeur peut faire pour changer ça...

                  • [^]Re: Alternative

                    Posté par golum () le 20/06/2005 à 09:51. (lien). Évalué à 1.

                    Peut-être une autre alternative en vogue en ce moment
                    Ruby on Rails
                    http://linuxfr.org/2005/06/18/19160.html(...)

                    Si tu as un avis eclairé là dessus?

              • [^]Re: Alternative

                Posté par golum () le 17/06/2005 à 13:14. (lien). Évalué à 2.

                Visiblement le monde de l'industrie evolue sur l'option de l'alternative faist son chemin
                http://www.zdnet.fr/actualites/informatique/0,39040745,39233250,00.(...)

                Le typage fort n'est pas forcément la panacée.
                La philosophie de python est celle du unit testing qui est AMHA nettement plus sûr que le typage fort tout en luimitant les inconvénients au niveau du refactoring.
                Certains projets proposent même d'introduire du typage fort progressivement dans ton code ce qui laisse la possibilté de prototyper rapidement et d'introduire plus de sécurité ensuite.

                De même, il y a possibilté de faire de la programmation par contrat
                de l'AOP, les decorator, bref Python n'a pas à rougir à cpté des dernières features Java.


                Les interfaces: Python supporte l'heritage multiple mais mieux que ca on dispose du "duck typing" qui est encore plus souple. Si ton animal nage, court et fait coin coin c'est que c'est un canard, inutile de le préciser.


                Les performances ne sont pas les seuls critères à prendre en compte dans le cadre d'un dévelopement, il y a aussi la productivité , la maintenabilité, la liberté, .....
                Mais même sur ce point c'est contestable (J'avais vu des benchs surprnant sur ce point nottamment avec Psycho)
                En outre il est toujours possible d'optimiser des parties de codes avec du compilé natif et les passerelles sont beaucoup plus aisée qu'avec du JNI.

                Bref nous voilà parti dans un beau troll des familles.

                Pour la conception, il suffit de voir les alternatives à J2EE qui fleurissent un peu partout y compris dans le monde Java pour comprendre que ce n'est pas la panacée notamment à cause de sa lourdeur. Et à la différence de Java ou C# , les évolutions y compris en terme de conception sont plus rapides avec Pyhton notamment en raison de son faible typage et de ses structures de haut niveau.

                Que vous argumentiez en disant qu'il s'agit d'une technologie encore immature OK mais réduire Python à un simple langage de script alors là STOP.

              • [^]Re: Alternative

                Posté par bobefrei () le 17/06/2005 à 13:30. (lien). Évalué à 3.

                Tu mélanges un peu tout:

                - le typage fort est bien pour détecter les erreurs à la compilation, mais le typage de Java n'est pas non plus super contraignant: pour cela il faudrait regarder du côté d'ADA ou d'Eiffel avec la programmation par contrat...
                - ce n'est pas parce que tu n'as pas trouvé d'usage "industriel" de la modification dynamique d'une classe qu'il n'y en pas. (Moi j'en vois un: mettre à jour un programme sans l'arrêter.)
                - quel est le rapport entre la notion d'interface et la sécurité?


                • [^]Re: Alternative

                  Posté par TImaniac (page perso, ) le 17/06/2005 à 13:50. (lien). Évalué à 2.

                  Tu mélanges un peu tout:
                  Je mélange pas, je prends plusieurs caractéristiques.

                  le typage fort est bien pour détecter les erreurs à la compilation, mais le typage de Java n'est pas non plus super contraignant
                  C'est toujours mieux que Python, même si ce n'est pas aussi bien que les contrats en Effel. Seulement Effel n'a pas tous les APIs de Java. Tout est une histoire de compromis. Je demande un concurrent à Java ou C#, il faut choisir, tu ne peux pas dire une fois : Python gnagna et une autre fois Effel gnagna.

                  (Moi j'en vois un: mettre à jour un programme sans l'arrêter.)
                  Ah parcqu'en Java on est obligé d'arrêter le programme ?
                  Désolé mais d'une manière générale cela n'a quand même que peu d'utilité dans la pratique, et pourtant quand je demande : et qu'apporte Python ? On me ressort systématiquement cette possibilité. Pourtant moi j'y vois surtout des inconvénients.

                  - quel est le rapport entre la notion d'interface et la sécurité?
                  Avec les interfaces tu peux déjà mettre en place une première notion de contrat : une interface n'est rien d'autre qu'un contrat quand aux APIs exposés par une classe. C'est loin de Effel mais c'est déjà fort pratique. Il suffit de lire un bouquin de design pattern pour s'apercevoir que beaucoup de collaboration font appelle à des interfaces. Les interfaces font cruellement défaut à Python.

                  --
                  MonoFrance

                  • [^]Re: Alternative

                    Posté par bobefrei () le 17/06/2005 à 14:10. (lien). Évalué à 3.

                    Tu cherches un concurrent ou une copie? Ou alors pour toi un concurrent crédible doit être obligatoirement un Java amélioré?

                    >Ah parcqu'en Java on est obligé d'arrêter le programme ?

                    Tu fais comment? Je n'ai pas vu cette possibilité dans Java...

                    >Pourtant moi j'y vois surtout des inconvénients.

                    Lesquels? Si tu n'utilises pas cette possiblité, elle ne va pas te manger!

                    >il suffit de lire un bouquin de design pattern pour s'apercevoir que beaucoup de collaboration font appelle à des interfaces.

                    Tu veux dire "un bouquin de Design Pattern appliqué à Java"? Si tu en lis un consacré à Python, ils implémenteront ça d'une autre façon.

                    • [^]Re: Alternative

                      Posté par TImaniac (page perso, ) le 17/06/2005 à 14:47. (lien). Évalué à 2.

                      Tu cherches un concurrent ou une copie?
                      Je cherche quelque chose qui me propose de répondre aux mêmes solutions.
                      Donc un concurrent à Java doit me fournir une plateforme avec des API tout aussi garnies, des perfs décentes et un langage "productif".

                      Tu fais comment? Je n'ai pas vu cette possibilité dans Java...
                      Bah si tu modifies un .class lors des prochains chargements de cette classe cette nouvelle version sera pris en compte, même si des instances existent déjà.

                      Lesquels? Si tu n'utilises pas cette possiblité, elle ne va pas te manger!
                      Ca c sûr. Mais du coup je me demandes toujours quel intérêt à le langage Python, puisqu'on m'avance toujours cet argument.

                      Si tu en lis un consacré à Python, ils implémenteront ça d'une autre façon.
                      Euh désolé j'ai jamais lu de bouquin de DP appliqué à Java. Le plus fameux, le GoF fait référence au C++.
                      Trouve moi un livre consacré aux DP en Python. Le modèle objet de python est vraiment pas beau à voir, on sent bien que c'est un "rajout" bricolé.

                      --
                      MonoFrance

                    • [^]Re: Alternative

                      Posté par boubou (page perso, ) le 20/06/2005 à 09:23. (lien). Évalué à 2.

                      Tu fais comment? Je n'ai pas vu cette possibilité dans Java...

                      On utilise une astuce basée sur les classloaders. Quand tu charges une classe, elle est en fait chargée par une classe spéciale, le classloader. Si tu veux charger une nouvelle version de cette classe, il suffit de changer de classloader. Ca marche très bien, mais ce n'est quand même pas automatique, ça demande une certaine programmation, contrairement à ce que semble dire Timaniac.

              • [^]Re: Alternative

                Posté par boubou (page perso, ) le 20/06/2005 à 09:07. (lien). Évalué à 3.

                Python est avant tout un langage de script

                De même que Java est un langage destiné à faire des applets. Tu n'en as pas marre de passer ton temps à troller ?

                • [^]Re: Alternative

                  Posté par TImaniac (page perso, ) le 20/06/2005 à 09:49. (lien). Évalué à 2.

                  De même que Java est un langage destiné à faire des applets.
                  Et ? Quel est le rapport avec ma phrase ?
                  Je dis que Python est un langage de script, c'est un fait. L'utilisation que tu fais d'un langage comme Java dépend de ses API et peut fluctuer.
                  Je vois pas où est le troll, j'essai de montrer que les avantages de Python réside dans ses choix de conception "dynamique", et qui sont tout à fait pertinent dans un contexte de langage de script. Dans un contexte d'application côté serveur où l'on recherche les perfs mais aussi la sécurité, Python n'a plus aucun intérêt face aux autres solutions.
                  C'est pas parcque tu vas réussir à manger un steack avec une cuillère que c'est pertinent.

                  --
                  MonoFrance

            • [^]Re: Alternative

              Posté par bobefrei () le 17/06/2005 à 13:14. (lien). Évalué à 3.

              Je ne connais pas bien JTA, mais je suis en train d'écrire un utilitaire de synchronisation de bases de données en Erlang et je m'en passe très bien, car ce langage a toutes les API nécessaires pour implémenter des transactions.

              Pour Python, il me semble qu'il existe plusieurs solutions de persistence et donc il doit y avoir de quoi gérer les transactions.

              Côté performance, c'est difficile de comparer, mais on peut voir que Java et Python sont assez proche sur ce test: http://shootout.alioth.debian.org/benchmark.php?test=all&lang=all&sort=fullcpu&calc=Calculate&xfullcpu=1&xmem=0&xloc=0&ackermann=1&binarytrees=5&wc=3&fannkuch=3&fasta=3&harmonic=1&knucleotide=4&mandelbrot=4&nbody=3&nsieve=3&nsievebits=2&methcall=0&pidigits=2&random=3&raytracer=5&regexmatch=4&revcomp=3&spectralnorm=2&spellcheck=4&hello=0&sumcol=3&takfp=1&tcpecho=2&tcprequest=4&tcpstream=3&process=2&message=5&wordfreq=5

              Erlang est bien en dessous, mais il n'y a pas de comparaison en environnement distribué...

              Au niveau IDE, qu'il y a des plugins Python et Erlang pour Eclipse.

              • [^]Re: Alternative

                Posté par TImaniac (page perso, ) le 17/06/2005 à 13:21. (lien). Évalué à 2.

                Pour Python, il me semble qu'il existe plusieurs solutions de persistence et donc il doit y avoir de quoi gérer les transactions.
                Vois pas le rapport. Java propose un ensemble d'API standards pour serveur d'application qui gère tout de A à Z. Il n'y a rien de comparable en Python.
                Quand au bench Python vs Java, Python utilise plus de mémoire mais est nettement plus lent, plus de 15x plus lent dans certains tests. Ca se passe de commentaire. Fait le même temps en comparant Python à C# pour rire.
                Erlang n'en parlons pas.
                Php encore moins.

                Même si tu vas trouver des API à droites à gauche pour tel ou tel langage, ce qui fait la force des plateformes associés à C#/Java c'est l'uniformité et l'intégration de ces APIs : ce n'est pas un assemblage de briques hétéroclyte mais un ensemble cohérent.

                Pour ce qui est des IDE, il existe aussi un plugin C# pour Eclipse, mais autant dire qu'il n'y a aucun rapport entre faire du Java avec Eclipse et utiliser un autre langage dans Eclipse.

                --
                MonoFrance

                • [^]Re: Alternative

                  Posté par bobefrei () le 17/06/2005 à 13:47. (lien). Évalué à 2.

                  Que tu trouves que l'intégration de Java/C# soit un point positif rend-t-il impossible l'utilisation de plateforme plus hétéroclyte comme alternative?

                  • [^]Re: Alternative

                    Posté par TImaniac (page perso, ) le 17/06/2005 à 13:52. (lien). Évalué à 2.

                    Ecoutes, j'essai de montrer que l'intégration est un atout, je dis pas qu'il n'y a pas d'autres solutions. Donc quand je dis qu'il n'y a pas de plateforme équivalente à C#/Java je parle aussi de l'intégration.

                    --
                    MonoFrance

              • [^]Re: Alternative

                Posté par boubou (page perso, ) le 20/06/2005 à 09:27. (lien). Évalué à 2.

                Le benchmark que tu cites est totalement merdique et débile. Les micro benchmark défavorisent fortement les langages comme Java et Python (et C#, d'ailleurs). Ca ne prouve rien du tout, ni dans un sens, ni dans l'autre.

    • [^]Re: Alternative

      Posté par bobefrei () le 17/06/2005 à 12:59. (lien). Évalué à 3.

      Concurrencer ne veut pas dire faire la même chose avec les mêmes solutions. Ce n'est pas parce que Python, Erlang ou PHP ne sont pas identiques de C# et Java que leur utilisation n'est pas pertinente pour les mêmes types d'applications.

      Pour la réalisation de sites webs, par exemple, toutes ces plateformes proposent des approches différentes adaptés à leurs langages, leurs API...

      • [^]Re: Alternative

        Posté par TImaniac (page perso, ) le 17/06/2005 à 13:05. (lien). Évalué à 0.

        C'est pas pour autant que c'est pertinent.
        Python est lent, pour un site web j'espère que tu n'as pas 100000 utilisateurs avec gestion de transactions. Et dans ce genre de cas tu aimes bien avoir un minimum de sécurité et de qualité. Désolé mais le côté "laxiste" du langage Python ne va pas du tout dans ce sens.

        Que je sache en PHP tu peux te toucher pour espérer faire un serveur d'application. PHP ne se suffit pas lui-même il lui faut communiquer avec un autre langage.

        Tous les langages ont pratiquement des APIs dans tous les domaines, c'est pas parcque les APIs sont dispos que la plateforme qu'il est pertinent de les utiliser.

        --
        MonoFrance

        • [^]Re: Alternative

          Posté par golum () le 17/06/2005 à 13:29. (lien). Évalué à 1.


          Python est lent, pour un site web


          Ca va faire plaisir à tous ces gens ce que tu dis
          http://www.zope.org/Resources/Testimonials(...)
          http://www.weblmi.com/manage_copyright(...)

          Bon d'accord y'a peut-être pas de transactionnel là-dedans mais il faut laisser le temps au temps, l'API J2EE ne s'est pas créée en un jour que je sache.

          En plus ce sont peut-être pas les mêmes niches de marché.
          Une PME n'a pas forcément les moyens de payer des millions pour une solution B2C de la mort qui tue en J2EE.

          • [^]Re: Alternative

            Posté par TImaniac (page perso, ) le 17/06/2005 à 13:42. (lien). Évalué à 1.

            Ca va faire plaisir à tous ces gens ce que tu dis
            Ma phrase n'avait de sens que dans son intégralité. Je vois même pas l'intérêt de ta remarque puisque tu est d'accord quand je te parle de transactionnel.

            En plus ce sont peut-être pas les mêmes niches de marché.
            C'est ce que j'explique : Python est loin d'être pertinent dans toutes les utilisations, et de ce fait ne couvre pas la même chose que Java ou C#, et donc ne boxe pas dans la même catégorie. CQFD.

            --
            MonoFrance

            • [^]Re: Alternative

              Posté par golum () le 17/06/2005 à 14:01. (lien). Évalué à 1.

              Sauf que ce que j'explique c'est que c'est en train de changer.
              Je ne prétends pas pas que la technologie Zope/Python peut encore se mesurer aux grand comptes mais elle est en train de monter et ca pourrait changer.

              Zope est un véritable serveur d'application et supporte le transactionnel.
              La charge, je ne sais pas, je ne suis pas "Zope architect" ;-)

              En tout cas je n'ai pas l'impression que l'audience de Gnu linux magazine (cf. sujet du journal) correspondent principalement à des "daicideurs" de grands comptes donc pour moi Zope/Plone/Python est une bonne alternative qui aurait pu figurer dans cette étude.

              C'est tout.

              • [^]Re: Alternative

                Posté par TImaniac (page perso, ) le 17/06/2005 à 14:06. (lien). Évalué à 2.

                Sauf que ce que j'explique c'est que c'est en train de changer.
                Zope ca fait des années qu'on en parle, n'empêche que le soufflé est vite retombé. J'ai du mal à voir comment il va remonter :)

                Pour la charge, ben c'est pas le langage Python qui va aider, ca n'a jamais été une foudre de guerre hein ;)

                Zope/Plone/Python est une bonne alternative qui aurait pu figurer dans cette étude.
                Cela dit que je suis d'accord qu'il aurait été intéressant d'avoir d'autres plateformes dans cette comparaison. Mais ne perdons pas de vu que le document vise avant tout à apprécier l'impact des brevets logiciels sur des implémentations libre de framework proprio.

                --
                MonoFrance

          • [^]Re: Alternative

            Posté par golum () le 17/06/2005 à 13:49. (lien). Évalué à 1.

            Et juste pour montrer qu'il y a tout ce qui faut avec Zope en tant que serveur d'application

            une petite table de comparaison
            http://www.boddie.org.uk/python/web_modules_enterprise.html(...)

            • [^]Re: Alternative

              Posté par TImaniac (page perso, ) le 17/06/2005 à 13:58. (lien). Évalué à 2.

              un tableau qui montre clairement que Python n'a pas du tout de plateforme unifiée pour faire serveur d'application.

              Ton document reprends point par point les technos J2EE en tantant de trouver un équivalent en Python. On s'en fou qu'il y est un remplacant point par point, il faut un remplacant global capable de remplacer l'ensemble. Le jour où y'aura une plateforme complète et unifiée capable de faire tout ce que fait Java alors je dirais ok.

              Enfin visiblement le marché me donne raison : les parts de marché de Zope (qui existe quand même depuis un certain temps) sont ridicules.

              Ah oui au fait c'est quoi l'équivalent de RMI en Python ?

              --
              MonoFrance

              • [^]Re: Alternative

                Posté par golum () le 17/06/2005 à 14:29. (lien). Évalué à 1.

                RMI pas besoin, tu as Corba pour ca au moins c'est multilangage mais en cherchant un peu je suis sûr qu'on peut trouver.

                Bref tu considères que le tout intégré c'est la panacée mais c'est aussi la contrainte d'où le succès grandissant des solutions LAMP

                Concernant la table , les equivalences sont sur la plateforme Zope ce qui montre que cette plateforme est quasi- complète et donc intégrée.

                Il faut aussi comprendre que la plateforme est dédiée au langage donc qu'il est nullement obligatoire de respecter le JSR??? pour proposer un serveur d'application équivalent.

                L'avantage de python c'est qu'il est versatile et ne cible pas uniquement le monde du Web il s'exprime pleinenent sur le poste de travail car il s'intègre bien avec tout un tas de toolkit.

                Quand t'as un programme qui doit effectuer des manips sur le poste, des fois le modèle de sécurité de Java, il est pesant

                Quant aux parts de marché, Zope n'est pas soutenu par les mastodontes commme IBM BEA Sun & Co donc forcément ca ce ressent mais les entreprises appéecient de plus en plus la liberté y compris de technologie.

                • [^]Re: Alternative

                  Posté par TImaniac (page perso, ) le 17/06/2005 à 14:33. (lien). Évalué à 1.

                  RMI c'est bien parcque c'est intégré au langage et ca supporte complètement Java. Corba c'est rigolo mais c'est intégré dans rien du tout. C'est tellement bien que c'est c'est une des raisons qui a poussé Icaza à faire Mono.

                  Bref tu considères que le tout intégré c'est la panacée mais c'est aussi la contrainte d'où le succès grandissant des solutions LAMP
                  Tout à fait : ca boxe pas dans la même catégorie, pour certains trucs Java est pas adapté et inversement, mais à par C# j'en connais aucun qui rivalise Java dans son domaine de compétence.

                  il s'exprime pleinenent sur le poste de travail car il s'intègre bien avec tout un tas de toolkit.
                  Oué mais là ca n'a pas plus d'intérêt que C#/Mono qui a les mêmes avantage. Désolé mais je n'arrive vraiment pas à voir ce que Python a de plus. Je vois très bien ce qu'il y a en moins mais pas en plus.

                  Quant aux parts de marché, Zope n'est pas soutenu par les mastodontes commme IBM BEA Sun & Co donc forcément ca ce ressent
                  S'il Zope n'est pas soutenu il y a peut être aussi une raison. IBM aurait très bien pu se tourner vers autre chose que Java.

                  --
                  MonoFrance

                  • [^]Re: Alternative

                    Posté par golum () le 17/06/2005 à 15:08. (lien). Évalué à 1.

                    Oui mais Corba ne te limite pas à l'usage d'un langage.
                    Corba c'est un protocole et un standard. Ce sont les impléméntations qui divergent.

                    Mono implémente son propre protocole dans son coin (.net remoting je suppose) tout comme RMI


                    Oué mais là ca n'a pas plus d'intérêt que C#/Mono qui a les mêmes avantage. ....
                    Et là ca ne te dérange plus de changer de techno et de langage, bizarre.


                    S'il Zope n'est pas soutenu il y a peut être aussi une raison. IBM aurait très bien pu se tourner vers autre chose que Java.
                    Ou peut être qu'il y a pas assez de business à se faire et qu'il ont déjà pas mal investi dans java au moment ou zope a démarré. Python a surtout évolué ces denières années.

                    D'ailleur c'est pas les mêmes qui on créé un tk graphique pour concurrencer un autre parce qu'il le trouvait "inadapté".
                    Qui sait ? ils finiront peut être par comprendre que c'est la même chose avec Java

                    Quant aux performance le JITs c'est récent et il n'est pas exclu que des progrès soient accompli avec python aussi. Ppour ;l'instant ce n'était pas la priorité mais chaque nllle version de Cpython améliore les perforamances sans compter le projet Psyco.
                    L'engouement de la communauté du libre est assez récent..
                    L'avantage avec python c'est son coté dynamique lui permet d'evoluer très vite.

                    Bref on est dans du plus pur troll.
                    Merci pour ton point de vue mais je crois que chacun campera sur ses positions
                    ===> [ ]

                    • [^]Re: Alternative

                      Posté par TImaniac (page perso, ) le 17/06/2005 à 15:18. (lien). Évalué à 1.

                      Corba c'est un protocole et un standard. Ce sont les impléméntations qui divergent.
                      Oué bah c'est aussi le but de Mono/.NET : proposer un standard indépendant des langages...

                      Et là ca ne te dérange plus de changer de techno et de langage, bizarre.
                      Oué bon ok. En fait il manque quelques trucs à Mono pour être à la hauteur de Java côté fonctionnalité. Même si Python a des fonctionnalités proche de Mono il reste un fossé énorme côté performances. Et même fonctionnalités. Que je sache il n'y a a aucune équivalent à ce que propose ASP.NET chez Python.

                      Quant aux performance le JITs c'est récent et il n'est pas exclu que des progrès soient accompli avec python aussi. Ppour ;l'instant ce n'était pas la priorité mais chaque nllle version de Cpython améliore les perforamances sans compter le projet Psyco.
                      Le plus rigolo c'est que l'implantation de Python la plus rapide tourne sur .NET/Mono :-p
                      Psycho c'est gagné en perf pour perdre en portabilité. Désolé mais ca vaut pas un bon vieux JIT.

                      Bref on est dans du plus pur troll.
                      Je crois surtout que tu n'as jamais programmer une application pour J2EE ou une application pour Mono/.NET. Tu cernerais tout seul les différences et tu aurais conclus par toi même qu'il y a un fossé entre les catégories même si certaines utilisations peuvent se recouper.

                      --
                      MonoFrance

        • [^]Re: Alternative

          Posté par bobefrei () le 17/06/2005 à 13:51. (lien). Évalué à 2.

          Si tu as 100000 utilisateurs avec gestion de transactions, Erlang n'est-il pas plus pertinent que Java?

          • [^]Re: Alternative

            Posté par TImaniac (page perso, ) le 17/06/2005 à 14:03. (