Bonjour,
J'ai récemment entendu dire que Sun allait rendre sa plateforme java libre.
Sans vouloir rentrer dans les polémiques concernant cette soi-disant liberté
menées par Richard Stallman (et j'avoue, en fait, ne pas complétement être
au fait des subtilités tournant autour de ces concepts), j'étais seulement
curieux sur l'objet du débat.
Peut-être que je retranscris mal les termes de ce que j'ai entendu, mais je
ne saisis pas bien ce que peut vouloir dire rendre la plateforme de Sun
libre.
De part ma perception des choses, la plateforme java de Sun consiste
essentiellement en un ensemble de spécifications que doivent implémenter des
vendors tiers (ca c'est plus pour la partie J2EE), d'un ensemble de
librairies dont les sources java étaient déjà disponibles (seules les
parties natives, gros moceaux effectivement, ne l'étaient pas) (ca c'est
plus pour la partie J2SE) et enfin d'un ensemble d'outils (compilateurs,
etc...) pour lesquelles les source n'étaient effectivement pas disponibles
non plus.
Donc qu'est-ce qui est censé devenir libre finalement? Est-ce les sources
des parties natives des API et des outils dans les implémentations de
référence de Sun?
Merci d'avance, en espérant avoir été suffisamment clair dans ma question.
Julien
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Cédric Chabanois
Actuellement, les sources de la plateforme Java de Sun ne sont pas libres. Elles sont certes disponibles (y compris les parties natives à ce que je sache ou au moins une partie) mais personne n'a le droit de les modifier et de les redistribuer (aucun intérêt donc sauf pour comprendre ...) : ce n'est pas opensource. Cela a pour conséquence : - Le JDK/JRE ne peuvent pas être distribuées sur certaines distributions Linux. Elles doivent être chargées par l'utilisateur - Il n'y a pas de machine virtuelle Sun sur beaucoup de plateformes parceque Sun ne l'a pas portée et que personne ne peut le faire étant donné la licence (sauf en cas d'accord comme pour Blackdown mais Blackdown n'est pas opensource) - en cas de bug, quel que soit sa gravité, on doit attendre la bonne volonté de Sun pour le corriger (certains bugs présents sont présents depuis des années car jugés non prioritaires par Sun)
Certes, il y a des implémentations open-source de la VM Java et des librairies standards (GNU Classpath pour les librairies standards) mais elles sont incomplètes : les programmeurs doivent implémenter les librairies à partir de rien sans surtout regarder le code de Sun ...
Ce qui va changer c'est donc que l'implémentation de Sun (VM, librairies, compilo, java et parties natives) va passer à priori en opensource. Reste à voir la license.
Cédric
Bonjour, J'ai récemment entendu dire que Sun allait rendre sa plateforme java libre. Sans vouloir rentrer dans les polémiques concernant cette soi-disant liberté menées par Richard Stallman (et j'avoue, en fait, ne pas complétement être au fait des subtilités tournant autour de ces concepts), j'étais seulement curieux sur l'objet du débat. Peut-être que je retranscris mal les termes de ce que j'ai entendu, mais je ne saisis pas bien ce que peut vouloir dire rendre la plateforme de Sun libre. De part ma perception des choses, la plateforme java de Sun consiste essentiellement en un ensemble de spécifications que doivent implémenter des vendors tiers (ca c'est plus pour la partie J2EE), d'un ensemble de librairies dont les sources java étaient déjà disponibles (seules les parties natives, gros moceaux effectivement, ne l'étaient pas) (ca c'est plus pour la partie J2SE) et enfin d'un ensemble d'outils (compilateurs, etc...) pour lesquelles les source n'étaient effectivement pas disponibles non plus. Donc qu'est-ce qui est censé devenir libre finalement? Est-ce les sources des parties natives des API et des outils dans les implémentations de référence de Sun? Merci d'avance, en espérant avoir été suffisamment clair dans ma question. Julien
Actuellement, les sources de la plateforme Java de Sun ne sont pas
libres. Elles sont certes disponibles (y compris les parties natives à
ce que je sache ou au moins une partie) mais personne n'a le droit de
les modifier et de les redistribuer (aucun intérêt donc sauf pour
comprendre ...) : ce n'est pas opensource.
Cela a pour conséquence :
- Le JDK/JRE ne peuvent pas être distribuées sur certaines distributions
Linux. Elles doivent être chargées par l'utilisateur
- Il n'y a pas de machine virtuelle Sun sur beaucoup de plateformes
parceque Sun ne l'a pas portée et que personne ne peut le faire étant
donné la licence (sauf en cas d'accord comme pour Blackdown mais
Blackdown n'est pas opensource)
- en cas de bug, quel que soit sa gravité, on doit attendre la bonne
volonté de Sun pour le corriger (certains bugs présents sont présents
depuis des années car jugés non prioritaires par Sun)
Certes, il y a des implémentations open-source de la VM Java et des
librairies standards (GNU Classpath pour les librairies standards) mais
elles sont incomplètes : les programmeurs doivent implémenter les
librairies à partir de rien sans surtout regarder le code de Sun ...
Ce qui va changer c'est donc que l'implémentation de Sun (VM,
librairies, compilo, java et parties natives) va passer à priori en
opensource. Reste à voir la license.
Cédric
Bonjour,
J'ai récemment entendu dire que Sun allait rendre sa plateforme java libre.
Sans vouloir rentrer dans les polémiques concernant cette soi-disant liberté
menées par Richard Stallman (et j'avoue, en fait, ne pas complétement être
au fait des subtilités tournant autour de ces concepts), j'étais seulement
curieux sur l'objet du débat.
Peut-être que je retranscris mal les termes de ce que j'ai entendu, mais je
ne saisis pas bien ce que peut vouloir dire rendre la plateforme de Sun
libre.
De part ma perception des choses, la plateforme java de Sun consiste
essentiellement en un ensemble de spécifications que doivent implémenter des
vendors tiers (ca c'est plus pour la partie J2EE), d'un ensemble de
librairies dont les sources java étaient déjà disponibles (seules les
parties natives, gros moceaux effectivement, ne l'étaient pas) (ca c'est
plus pour la partie J2SE) et enfin d'un ensemble d'outils (compilateurs,
etc...) pour lesquelles les source n'étaient effectivement pas disponibles
non plus.
Donc qu'est-ce qui est censé devenir libre finalement? Est-ce les sources
des parties natives des API et des outils dans les implémentations de
référence de Sun?
Merci d'avance, en espérant avoir été suffisamment clair dans ma question.
Julien
Actuellement, les sources de la plateforme Java de Sun ne sont pas libres. Elles sont certes disponibles (y compris les parties natives à ce que je sache ou au moins une partie) mais personne n'a le droit de les modifier et de les redistribuer (aucun intérêt donc sauf pour comprendre ...) : ce n'est pas opensource. Cela a pour conséquence : - Le JDK/JRE ne peuvent pas être distribuées sur certaines distributions Linux. Elles doivent être chargées par l'utilisateur - Il n'y a pas de machine virtuelle Sun sur beaucoup de plateformes parceque Sun ne l'a pas portée et que personne ne peut le faire étant donné la licence (sauf en cas d'accord comme pour Blackdown mais Blackdown n'est pas opensource) - en cas de bug, quel que soit sa gravité, on doit attendre la bonne volonté de Sun pour le corriger (certains bugs présents sont présents depuis des années car jugés non prioritaires par Sun)
Certes, il y a des implémentations open-source de la VM Java et des librairies standards (GNU Classpath pour les librairies standards) mais elles sont incomplètes : les programmeurs doivent implémenter les librairies à partir de rien sans surtout regarder le code de Sun ...
Ce qui va changer c'est donc que l'implémentation de Sun (VM, librairies, compilo, java et parties natives) va passer à priori en opensource. Reste à voir la license.
Cédric
Bonjour, J'ai récemment entendu dire que Sun allait rendre sa plateforme java libre. Sans vouloir rentrer dans les polémiques concernant cette soi-disant liberté menées par Richard Stallman (et j'avoue, en fait, ne pas complétement être au fait des subtilités tournant autour de ces concepts), j'étais seulement curieux sur l'objet du débat. Peut-être que je retranscris mal les termes de ce que j'ai entendu, mais je ne saisis pas bien ce que peut vouloir dire rendre la plateforme de Sun libre. De part ma perception des choses, la plateforme java de Sun consiste essentiellement en un ensemble de spécifications que doivent implémenter des vendors tiers (ca c'est plus pour la partie J2EE), d'un ensemble de librairies dont les sources java étaient déjà disponibles (seules les parties natives, gros moceaux effectivement, ne l'étaient pas) (ca c'est plus pour la partie J2SE) et enfin d'un ensemble d'outils (compilateurs, etc...) pour lesquelles les source n'étaient effectivement pas disponibles non plus. Donc qu'est-ce qui est censé devenir libre finalement? Est-ce les sources des parties natives des API et des outils dans les implémentations de référence de Sun? Merci d'avance, en espérant avoir été suffisamment clair dans ma question. Julien
TestMan
Bonjour, J'ai récemment entendu dire que Sun allait rendre sa plateforme java libre. Sans vouloir rentrer dans les polémiques concernant cette soi-disant liberté menées par Richard Stallman (et j'avoue, en fait, ne pas complétement être au fait des subtilités tournant autour de ces concepts), j'étais seulement curieux sur l'objet du débat. Peut-être que je retranscris mal les termes de ce que j'ai entendu, mais je ne saisis pas bien ce que peut vouloir dire rendre la plateforme de Sun libre. De part ma perception des choses, la plateforme java de Sun consiste essentiellement en un ensemble de spécifications que doivent implémenter des vendors tiers (ca c'est plus pour la partie J2EE), d'un ensemble de librairies dont les sources java étaient déjà disponibles (seules les parties natives, gros moceaux effectivement, ne l'étaient pas) (ca c'est plus pour la partie J2SE) et enfin d'un ensemble d'outils (compilateurs, etc...) pour lesquelles les source n'étaient effectivement pas disponibles non plus. Donc qu'est-ce qui est censé devenir libre finalement? Est-ce les sources des parties natives des API et des outils dans les implémentations de référence de Sun? Merci d'avance, en espérant avoir été suffisamment clair dans ma question. Julien
Bonjour,
Effectivement on passera sur les délires de RMS qui est ouvertement anti-java depuis ça création. Pour ce concentrer sur le débat: le code source de l'implémentation de Sun de Java SE doit-il être libre ?
Un petit rappel, tout ce qui gravite autour de Java est spécifié au sein du JCP chapeauté par Sun qui pour chaque spécification un collège d'experts qui vont définir une future spécification qui va être soumise au vote du commité des membres éxécutifs (Sun, IBM, Oracle, Apache ...).
NB: Il y a régulièrement des éléctions ouverte à tous pour élire certains des exécutifs, voir par ex le vote de 2005 : http://minilien.com/?xntdcooa32
Si la proposition de spécification est acceptée, il en sortira trois choses: - Une spécification (complètement publique) : la spec :o) - Une implémentation de référence (sous license particulère) : la RI, elle montre que la spec est viable et joue le rôle de juge de paix en cas d'imprécision de la spec. - Un kit de test de compatibilité : le TCK, c'est lui qui permet d'apposer le logo "compatible" si une autre implémentation est réalisée (opensource ou commerciale).
Si l'on prend le cas de la spec Java EE 5, le RI est disponible en license libre CDDL (approuvée OSI) sous le nom de Glassfish.
Mais pour des raisons historiques, le Java SE est en license "complexe" (pleins de licenses suivant ce que tu veux faire et qui complique tout : pour utiliser, pour contribuer, pour faire de la recherche ... c'est trop compliqué). Pour ce qui est de l'aspect financier, ça a pas mal changé au fil de l'histoire de Java, mais en gros, il n'y a plus beaucoup de gens qui payent qqch à Sun. Si je ne me trompe pas, je crois seul les editeurs qui désirent personaliser le JDK payent quelquechose.
Le TCK, quand à lui est disponible auprés du JCP moyenant finances (sauf pour les organisations à but non lucratif comme Apache Group par exemple pour qui celà est gratuit). C'est lui qui permettra d'apposer le logo "compatible avec la spec" dans le cas précis "compatible Java SE X". Pour celà il suffit d'exécuter le TCK sur son implémentation pour obtenir la "certification".
Ainsi, il est complètement possible de réaliser une VM Java libre (cf. Projet Harmony de Apache par exemple), mais dans la pratique, vu la complexité de la plateforme, celà demande beaucoup de ressources et de tems.
Tout le débat porte donc sur la license que doit avoir le RI du Java SE pour l'avenir afin d'eviter de "doubloner" la plateforme (une version Sun, le RI et une ou plusieurs autres libre).
La crainte de mettre le RI en license libre est la fragmentation de la plateforme. Mais pour moi, dés qu'il y a de multiple implémentations il y a forcement déjà un certain niveau de fragmentation accepté. Tout repose donc sur la qualité de la spécification et la complétude du TCK dans tous les cas.
C'est pour ces raisons que je suis vavorable à voir le RI publié sous license GPL avec comme nom le projet en cours par exemple "Dolphin" pour le prochain.
Gràce à sa viralité, la GPL est pour moi la seule license qui gardera MS loint de Java (sauf à "tuer" .net en le dépouillant de sont point fort stratégique : être spécifique aux OS de Microsoft). De plus, Seul les instances exitantes seront en charge de décider si telle ou telle fonctionalité du "projet" passe dans le RI.
Pour ce qui est de l'organisation des contributions du "projet", une structure proche de ce que Glassfish a adopté me semble efficace et pragmatique comme transition. A plus longue échéance il est nécessaire que Sun délègue une partie de ce travail à une comunauté libre stable (Apache ?) afin de pouvoir focaliser ses efforts sur le développement de fonctionalités.
A+
TM
Bonjour,
J'ai récemment entendu dire que Sun allait rendre sa plateforme java libre.
Sans vouloir rentrer dans les polémiques concernant cette soi-disant liberté
menées par Richard Stallman (et j'avoue, en fait, ne pas complétement être
au fait des subtilités tournant autour de ces concepts), j'étais seulement
curieux sur l'objet du débat.
Peut-être que je retranscris mal les termes de ce que j'ai entendu, mais je
ne saisis pas bien ce que peut vouloir dire rendre la plateforme de Sun
libre.
De part ma perception des choses, la plateforme java de Sun consiste
essentiellement en un ensemble de spécifications que doivent implémenter des
vendors tiers (ca c'est plus pour la partie J2EE), d'un ensemble de
librairies dont les sources java étaient déjà disponibles (seules les
parties natives, gros moceaux effectivement, ne l'étaient pas) (ca c'est
plus pour la partie J2SE) et enfin d'un ensemble d'outils (compilateurs,
etc...) pour lesquelles les source n'étaient effectivement pas disponibles
non plus.
Donc qu'est-ce qui est censé devenir libre finalement? Est-ce les sources
des parties natives des API et des outils dans les implémentations de
référence de Sun?
Merci d'avance, en espérant avoir été suffisamment clair dans ma question.
Julien
Bonjour,
Effectivement on passera sur les délires de RMS qui est ouvertement
anti-java depuis ça création. Pour ce concentrer sur le débat: le code
source de l'implémentation de Sun de Java SE doit-il être libre ?
Un petit rappel, tout ce qui gravite autour de Java est spécifié au sein
du JCP chapeauté par Sun qui pour chaque spécification un collège
d'experts qui vont définir une future spécification qui va être soumise
au vote du commité des membres éxécutifs (Sun, IBM, Oracle, Apache ...).
NB: Il y a régulièrement des éléctions ouverte à tous pour élire
certains des exécutifs, voir par ex le vote de 2005 :
http://minilien.com/?xntdcooa32
Si la proposition de spécification est acceptée, il en sortira trois choses:
- Une spécification (complètement publique) : la spec :o)
- Une implémentation de référence (sous license particulère) : la RI,
elle montre que la spec est viable et joue le rôle de juge de paix en
cas d'imprécision de la spec.
- Un kit de test de compatibilité : le TCK, c'est lui qui permet
d'apposer le logo "compatible" si une autre implémentation est réalisée
(opensource ou commerciale).
Si l'on prend le cas de la spec Java EE 5, le RI est disponible en
license libre CDDL (approuvée OSI) sous le nom de Glassfish.
Mais pour des raisons historiques, le Java SE est en license "complexe"
(pleins de licenses suivant ce que tu veux faire et qui complique tout :
pour utiliser, pour contribuer, pour faire de la recherche ... c'est
trop compliqué).
Pour ce qui est de l'aspect financier, ça a pas mal changé au fil de
l'histoire de Java, mais en gros, il n'y a plus beaucoup de gens qui
payent qqch à Sun. Si je ne me trompe pas, je crois seul les editeurs
qui désirent personaliser le JDK payent quelquechose.
Le TCK, quand à lui est disponible auprés du JCP moyenant finances (sauf
pour les organisations à but non lucratif comme Apache Group par exemple
pour qui celà est gratuit). C'est lui qui permettra d'apposer le logo
"compatible avec la spec" dans le cas précis "compatible Java SE X".
Pour celà il suffit d'exécuter le TCK sur son implémentation pour
obtenir la "certification".
Ainsi, il est complètement possible de réaliser une VM Java libre (cf.
Projet Harmony de Apache par exemple), mais dans la pratique, vu la
complexité de la plateforme, celà demande beaucoup de ressources et de
tems.
Tout le débat porte donc sur la license que doit avoir le RI du Java SE
pour l'avenir afin d'eviter de "doubloner" la plateforme (une version
Sun, le RI et une ou plusieurs autres libre).
La crainte de mettre le RI en license libre est la fragmentation de la
plateforme. Mais pour moi, dés qu'il y a de multiple implémentations il
y a forcement déjà un certain niveau de fragmentation accepté. Tout
repose donc sur la qualité de la spécification et la complétude du TCK
dans tous les cas.
C'est pour ces raisons que je suis vavorable à voir le RI publié sous
license GPL avec comme nom le projet en cours par exemple "Dolphin" pour
le prochain.
Gràce à sa viralité, la GPL est pour moi la seule license qui gardera MS
loint de Java (sauf à "tuer" .net en le dépouillant de sont point fort
stratégique : être spécifique aux OS de Microsoft).
De plus, Seul les instances exitantes seront en charge de décider si
telle ou telle fonctionalité du "projet" passe dans le RI.
Pour ce qui est de l'organisation des contributions du "projet", une
structure proche de ce que Glassfish a adopté me semble efficace et
pragmatique comme transition. A plus longue échéance il est nécessaire
que Sun délègue une partie de ce travail à une comunauté libre stable
(Apache ?) afin de pouvoir focaliser ses efforts sur le développement de
fonctionalités.
Bonjour, J'ai récemment entendu dire que Sun allait rendre sa plateforme java libre. Sans vouloir rentrer dans les polémiques concernant cette soi-disant liberté menées par Richard Stallman (et j'avoue, en fait, ne pas complétement être au fait des subtilités tournant autour de ces concepts), j'étais seulement curieux sur l'objet du débat. Peut-être que je retranscris mal les termes de ce que j'ai entendu, mais je ne saisis pas bien ce que peut vouloir dire rendre la plateforme de Sun libre. De part ma perception des choses, la plateforme java de Sun consiste essentiellement en un ensemble de spécifications que doivent implémenter des vendors tiers (ca c'est plus pour la partie J2EE), d'un ensemble de librairies dont les sources java étaient déjà disponibles (seules les parties natives, gros moceaux effectivement, ne l'étaient pas) (ca c'est plus pour la partie J2SE) et enfin d'un ensemble d'outils (compilateurs, etc...) pour lesquelles les source n'étaient effectivement pas disponibles non plus. Donc qu'est-ce qui est censé devenir libre finalement? Est-ce les sources des parties natives des API et des outils dans les implémentations de référence de Sun? Merci d'avance, en espérant avoir été suffisamment clair dans ma question. Julien
Bonjour,
Effectivement on passera sur les délires de RMS qui est ouvertement anti-java depuis ça création. Pour ce concentrer sur le débat: le code source de l'implémentation de Sun de Java SE doit-il être libre ?
Un petit rappel, tout ce qui gravite autour de Java est spécifié au sein du JCP chapeauté par Sun qui pour chaque spécification un collège d'experts qui vont définir une future spécification qui va être soumise au vote du commité des membres éxécutifs (Sun, IBM, Oracle, Apache ...).
NB: Il y a régulièrement des éléctions ouverte à tous pour élire certains des exécutifs, voir par ex le vote de 2005 : http://minilien.com/?xntdcooa32
Si la proposition de spécification est acceptée, il en sortira trois choses: - Une spécification (complètement publique) : la spec :o) - Une implémentation de référence (sous license particulère) : la RI, elle montre que la spec est viable et joue le rôle de juge de paix en cas d'imprécision de la spec. - Un kit de test de compatibilité : le TCK, c'est lui qui permet d'apposer le logo "compatible" si une autre implémentation est réalisée (opensource ou commerciale).
Si l'on prend le cas de la spec Java EE 5, le RI est disponible en license libre CDDL (approuvée OSI) sous le nom de Glassfish.
Mais pour des raisons historiques, le Java SE est en license "complexe" (pleins de licenses suivant ce que tu veux faire et qui complique tout : pour utiliser, pour contribuer, pour faire de la recherche ... c'est trop compliqué). Pour ce qui est de l'aspect financier, ça a pas mal changé au fil de l'histoire de Java, mais en gros, il n'y a plus beaucoup de gens qui payent qqch à Sun. Si je ne me trompe pas, je crois seul les editeurs qui désirent personaliser le JDK payent quelquechose.
Le TCK, quand à lui est disponible auprés du JCP moyenant finances (sauf pour les organisations à but non lucratif comme Apache Group par exemple pour qui celà est gratuit). C'est lui qui permettra d'apposer le logo "compatible avec la spec" dans le cas précis "compatible Java SE X". Pour celà il suffit d'exécuter le TCK sur son implémentation pour obtenir la "certification".
Ainsi, il est complètement possible de réaliser une VM Java libre (cf. Projet Harmony de Apache par exemple), mais dans la pratique, vu la complexité de la plateforme, celà demande beaucoup de ressources et de tems.
Tout le débat porte donc sur la license que doit avoir le RI du Java SE pour l'avenir afin d'eviter de "doubloner" la plateforme (une version Sun, le RI et une ou plusieurs autres libre).
La crainte de mettre le RI en license libre est la fragmentation de la plateforme. Mais pour moi, dés qu'il y a de multiple implémentations il y a forcement déjà un certain niveau de fragmentation accepté. Tout repose donc sur la qualité de la spécification et la complétude du TCK dans tous les cas.
C'est pour ces raisons que je suis vavorable à voir le RI publié sous license GPL avec comme nom le projet en cours par exemple "Dolphin" pour le prochain.
Gràce à sa viralité, la GPL est pour moi la seule license qui gardera MS loint de Java (sauf à "tuer" .net en le dépouillant de sont point fort stratégique : être spécifique aux OS de Microsoft). De plus, Seul les instances exitantes seront en charge de décider si telle ou telle fonctionalité du "projet" passe dans le RI.
Pour ce qui est de l'organisation des contributions du "projet", une structure proche de ce que Glassfish a adopté me semble efficace et pragmatique comme transition. A plus longue échéance il est nécessaire que Sun délègue une partie de ce travail à une comunauté libre stable (Apache ?) afin de pouvoir focaliser ses efforts sur le développement de fonctionalités.
