Sun et l'open source

Posté par . Modéré par oliv.
Tags : aucun
0
15
fév.
2002
Java
Il y a quelques temps le serveur d'applications Enhydra a dû abandonner l'open source pour que Sun daigne le certifier "J2EE".

L'article discute de la relation ambigüe entre Sun et l'open source. D'un coté Sun ouvre les sources de StarOffice/OpenOffice, de Forte/NetBeans, de l'autre il contraint JBoss (un serveur J2EE open-source) à se passer de l'"A.O.C. J2EE"

Aller plus loin

  • # java Su><or et java Ro><or quand meme alors...

    Posté par (page perso) . Évalué à 4.

    Chez SUN ils ont des gens qui doivent pas tous etre d'accord sur la stratègie de la société...
    • [^] # Re: java Su><or et java Ro><or quand meme alors...

      Posté par (page perso) . Évalué à 10.

      c'est juste une stratégie opportuniste : quand un produit ne marche pas et coûte de l'argent, on le libère ou on l'ouvre ; quand c'est une techno prometteuse, on impose sa vision des choses et on emmerde les partisans du libre.
      Bref, Sun n'a rien compris au logiciel libre.
    • [^] # Re: java Su><or et java Ro><or quand meme alors...

      Posté par . Évalué à 10.

      Dans un sens, leur démarche est plutôt logique de leut point de vue. Java est libre d'utilisation. Tu peux, comme JBoss, faire un serveur d'application libre J2SEE. Mais pour la certification, il faut passer par Sun.

      Ils contrôlent le langage dans le but de le laisser cohérent. Même si, comme le dit l'article, on a des langages libres dont les implémentations restent complètement compatibles entre elles (Python, Perl, Ruby), Sun fournit une certification compétitive. Certifier Weblogic et JBoss avantagerait JBoss, et ça SUN veux pas le faire, certainement pour des raisons économiques.

      Maintenant, c'est vrai qu'il est plus que dommage que Sun ne veuille pas certifier une version de JBoss. Rien ne l'empêche d'un point de vue technique, mais d'un point de vue plus politique, si ils ne le font pas, c'est qu'ils ont de bonnes (selon eux) raisons. Nous n'avons certainement pas la même vision qu'eux là dessus.
  • # Avertissements

    Posté par . Évalué à -2.

    A partir de maintenant, dès que Sun fera des trucs comme vendre ses Sobalts sous linux, ou autre chose de se genre, j'espère que *tout le monde* se posera à deux fois la question: "Est-ce que Sun est un ami ou un ennemi?" avant de crier victoire...
  • # Ne vous emballez pas ...

    Posté par (page perso) . Évalué à 10.

    Ne pas s'emballer trop vite. J'ai suivi +- cette affaire et ce qui en resort c'est que le changement de licence de Enhydra vient plus d'une volonté de leur part que d'une quelconque pression de Sun. Sun s'en fout de certifier un serveur d'applications open source du moment que la boite paie pour ça (comme n'importe quel autre serveur d'app).
    D'ailleurs Marc Fleury (de JBoss) l'a dit clairement, ils pourraient se faire certifier par Sun, mais ils ne le font pas car ça coute trop cher. Mais jamais Sun ne leur interdirait la certification parce qu'ils sont open source.

    Il faut voir les choses platement :
    - Sun est une boite commerciale.
    - J2EE peut etre implémenté *gratuitement* par n'importe qui.
    - Eux, vendent des certifications (faut bien rentabiliser, c'est pas des mécènes).
    - BEA, IBM & co paient une fortune pour ces certifications.
    - Si jamais Sun donne les certifs gratuitement à des projets open source, ceux qui paient vont faire la gueule (normal aussi).

    Bref voilà, c'est pas plus compliqué ...
    • [^] # Re: Ne vous emballez pas ...

      Posté par (page perso) . Évalué à 3.

      Sun s'en fout de certifier un serveur d'applications open source du moment que la boite paie pour ça (comme n'importe quel autre serveur d'app).

      Au moment du changement de license d'enhydra, les gars de lutris disaient qu'une clause du contrat de certification imposait de mettre le code sous une license spéciale (peut-être open source, je ne sais plus, mais en tous cas pas libre) et interdisait le dual-licencing.
      • [^] # Re: Ne vous emballez pas ...

        Posté par (page perso) . Évalué à 10.

        Ce qui est ressortit des débats là-dessus sur des sites comme theserverside et javalobby c'est que ça avait bien arrangé Lutris de se servir de ces rumeurs pour changer de licence ... Marc Fleury (de JBoss) a assuré que rien n'empêcherait JBoss de se faire certifier (JBoss est sous LGPL je pense) si ce n'est qu'ils ne veulent pas payer autant ...

        Mais bon, je ne connais pas les conditions de certifications de chez Sun, je n'y connais rien en droit, donc je me trompe peut etre ....
        • [^] # Re: Ne vous emballez pas ...

          Posté par (page perso) . Évalué à 10.

          300% d'accord avec l'analyse de nelis.
          Qu'ajouter ?
          Que j'ai constaté moi-même la dérive "commerciale" de Lutris bien avant la remontée de ce genre de rumeur. Et qu'il est logique effectivement que SUN protège des acteurs qui payent pour obtenir une certification... Le fric rulez. Et l'attitude de SUN en découle, comme pour les autres boites.

          Notons que le JCP (http://jcp.org/(...)) Java Community Process pour l'évolution du langage est quand même pas mal.
    • [^] # Intéret de la certification

      Posté par . Évalué à 5.

      Il y a une question que je me pose :

      Quel est l'intéret de la certification ?

      Dans le cadre des personnes, ca n'apporte pas grand chose. J'avais un copain qui s'était fait certifier Microsoft (des gouts et des couleurs, il ne faut pas discuter). Celà ne l'empêchait pas d'être notoirement incompétant. De plus étant donné que le logiciel n'était pas très stable derrière, ca ne devait pas l'aider.

      Dans le cadre d'une application je ne sais pas trop ce que cela peut apporter. Peut être le fait qu si ca marche sur une application qui est certifiée pour respecter un standard ca marchera sur les autres.

      Ca c'est si on se limite au premier abord.

      Les différents forunisseurs d'application même s'il respectent des standard proposent toujours des extensions. Quel est le but recherché. La non compatibilité au final. C'est très simple. Le développeur étant fait néant dans la plupart des cas, il va utiliser les extensions :
      exemple le developpeur VisualC++ va utiliser des CString plutot que de faire "use std::" pour pouvoir utiliser les String de la STL. Il va donc aller contre la portabilité de son prog. J'en ai fait l'expérience cet été. Coder pour deux compilos différents c'est très dur (meme si ils sont sensé être compatibles aux dernières normes). Coder pour respecter un framework c'est encore plus dur.

      Je n'est jamais essayé WebSphere, mais je ne doute pas qu'il y ait des extentions bien propriétaires de derrière les fagots.

      Le developpeur va doc les utiliser en pensant d'abord à la facilité. Puis lorsqu'il va vouloir passer son appli sous un autre serveur, certifié lui aussi, BADABOOOOOMM. Ca ne marchera pas sans modification.

      Donc IMHO, la certification ne sert pas à grand chose. Bien que Sun certifie aussi les développeurs, je ne pense pas qu'ils aillent vérifier qu'ils ont bien compris qu'il ne fallait pas utiliser les extension pour guarantir la portabilité. Meme si c'était fait j'aimerai bien savoir quel était l'intervalle entre les piqures de rappel, parce que chassez le naturel et il reviens au galop.
      • [^] # Re: Intéret de la certification

        Posté par (page perso) . Évalué à 7.

        C'est clair que les certifications, c'est plus un argument commercial qu'une preuve de qualité !

        Sinon pour les apps J2EE, l'année passé j'ai développé une application J2EE assez complexe avec EJBs, JMS, Servlet/JSP et tout le bazar. Et bien je l'ai testée avec ceci, et elle fonctionne sans aucuns problèmes :
        App Server :
        BEA WebLogic et Orion
        DB :
        Oracle et Interbase
        JMS :
        Weblogic JMS et SwiftMQ

        Donc qd on fait un peu attention, l'indépendance de l'implémentation est une réalité ...
  • # Attention à la confusion entre Netbeans et Forte !!

    Posté par . Évalué à 10.

    On peut observer à longueur de temps, et en particulier sur linuxfr (cf. la news sur je jdk 1.4), une confusion présentant Netbeans comme une version open-source de Forte, dont Sun aurait ouvert les sources... CECI EST TOTALEMENT FAUX!!!
    En fait, Forte est bien basé sur Netbeans, mais ce n'est pas Sun qui est à l'origine de ce soft, et il ne risque donc pas d'en avoir ouvert les sources puisque ce ne sont pas les siennes !!
    Je crains que cette confusion fasse beaucoup de mal à Netbeans, ce qui est dommage vu la très bonne qualité de ce produit, qui ne doit rien à Sun...
    • [^] # Re: Attention à la confusion entre Netbeans et Forte !!

      Posté par (page perso) . Évalué à 10.

      >En fait, Forte est bien basé sur Netbeans, mais ce n'est pas Sun qui est à l'origine de ce soft, et il ne risque donc pas d'en avoir ouvert les sources puisque ce ne sont pas les siennes !!
      Si, c'est bien Sun qui a racheté NetBeans, alors distribué sous une license commerciale, qui l'a rebaptisé Forte for Java pour l'intégrer à sa propre gamme d'environnements de developpement, et qui décidé peu de temps après d'en distribuer également une version sous une license libre, rebaptisée pour l'occasion de son nom d'origine. Exactement de la même façon que pour StarOffice, qui n'était pas libre, et qui l'est devenu sous l'appellation d'OpenOffice dans les même conditions. La stratégie de Sun à ce sujet à l'avantage d'être cohérente.
      Celle suivie vis-à-vis des développeurs du projet Apache l'est beaucoup moins, et certains commencent à en avoir un peu marre de l'"Open Debugging" :-) Leur prise de position à ce sujet est assez explicite (voir à http://jakarta.apache.org/site/jspa-position.html(...))

Suivre le flux des commentaires

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