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"
Sun et l'open source
15
fév.
2002
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"
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"
# java Su><or et java Ro><or quand meme alors...
Posté par Temsa (site web personnel) . Évalué à 4.
[^] # Re: java Su><or et java Ro><or quand meme alors...
Posté par Pierre Tramo (site web personnel) . Évalué à 10.
Bref, Sun n'a rien compris au logiciel libre.
[^] # Re: java Su><or et java Ro><or quand meme alors...
Posté par Anonyme . Évalué à 10.
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 kalahann . Évalué à -2.
# Ne vous emballez pas ...
Posté par Nelis (site web personnel) . Évalué à 10.
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 Pierre Tramo (site web personnel) . Évalué à 3.
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 Nelis (site web personnel) . Évalué à 10.
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 VACHOR (site web personnel) . Évalué à 10.
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 rouge_ . Évalué à 5.
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 Nelis (site web personnel) . Évalué à 7.
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 fbilhaut . É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 !!
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 Guillaume Rousse (site web personnel) . Évalué à 10.
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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.