Sun a annoncé en août dernier que son implémentation de référence de Java, sous la forme du JDK (runtime et kit de développement) serait libéré d'ici la fin de l'année 2006, avec une licence open source au sens de l'OSI (donc en tant que logiciel libre).
Selon un article de Dr. Dobb's (http://ddj.com/dept/java/193600404 ) Sun aurait choisi la GPL ! En ces temps d'alliance contre nature entre Microsoft et Novell, la nouvelle serait pour le moins agréable si elle était confirmée. Une des plateformes de développement les plus populaires et les plus modernes passerait enfin dans le monde du libre (ce qui est acquis) et avec une licence dont le caractère engagé ne fait pas l'ombre d'un doute. Sun trouverait aussi dans ce choix un moyen de conserver un avantage commercial clair, à l'image de Trolltech et de MySQL.
Prions, mes soeurs et mes frères (pour moi, ce sera la Licorne Rose Invisible).
Selon un article de Dr. Dobb's (http://ddj.com/dept/java/193600404 ) Sun aurait choisi la GPL ! En ces temps d'alliance contre nature entre Microsoft et Novell, la nouvelle serait pour le moins agréable si elle était confirmée. Une des plateformes de développement les plus populaires et les plus modernes passerait enfin dans le monde du libre (ce qui est acquis) et avec une licence dont le caractère engagé ne fait pas l'ombre d'un doute. Sun trouverait aussi dans ce choix un moyen de conserver un avantage commercial clair, à l'image de Trolltech et de MySQL.
Prions, mes soeurs et mes frères (pour moi, ce sera la Licorne Rose Invisible).
> Lire le journal (97 commentaires, moyenne: 2,5).
Vous avez demandé le commentaire #773682.
Run by 
Cette page a été générée par Templeet en 0.0725s (dont 0.0073 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
.
Si ils choisissent la GPL, il va falloir qu'ils soient tres clairs sur ce qu'on peut ou ne peut pas faire. Les boites qui font du java proprio sans bien connaitre les licences risquent de pas etre rassurées quand on va leur dire que leurs developpements devront aussi etre en GPL. Et si il y'a une double licence GPL + licence commerciale payante, ca va pas plaire non plus : je faisais du java proprio et ça me coutait rien et maintenant il faut que je paye ? je passe à .NET !
[^]Re: .
Perso, je trouve que c'est tout à fait normal.
Tu tires des bénéfices d'une application, c'est normal de payer.
Je ne comprends pas les gens qui ralent parcequ'ils doivent payer des applis, alors qu'eux font payer les leurs. C'est un choix, mais il faut l'assumer.
[^]Re: .et aussi.
Ben passe à .Net, mais attention tu vas faire trembler SUN !
[^]Re: .
Mon interprétation est que ce sera du GPL+ exception de link, comme dans classpath. En gros, un programme construit sur la plateforme Java n'aura bien sûr pas besoin d'être GPL. Ce qui sera GPL, c'est une modification de la plateforme elle-même, par exemple un portage embarqué, exactement ce que Sun vise avec la Micro Edition.
[^]Re: .
Surtout que globalement, du fait qu'il existe de nombreuses VM Java, comment pourrait-on déclarer que tous les softs doivent obligatoirement passé sous GPL parcqu'une seule VM est sous GPL et permet donc de faire tourner tous ces programmes ?
MonoFrance
[^]Re: .
Remarque très pertinente. Je pense cependant que ce qui fait peur c'est plutôt la diffusion "jointe" d'une application avec le JRE qui réalise une sorte d'oeuvre composite, avec toutes les complications juridiques que cela entraîne...
[^]Re: .
Ah je capte mieux pourquoi cet été ils ont changés les conditions de redistributions de leur runtime ! ;)
Troll mis à part, ne peut on pas dire qu'une appli écrite en Java, à partir du moment où elle n'utilise pas une particularité de certains APIs, est plutôt dépendante d'une norme plutôt que d'une implémentation particulière ? Je trouve que la GPL est un peu trop flou de ce point de vue... Le plus logique serait finalement d'utiliser la LGPL, qui elle est adaptée aux bibliothèques "générales" comme celles que peuvent constituer un J2RE.
Après le runtime/VM peut très bien être en GPL, il n'est là que pour "interpréter" des données externes, il n'y a pas de dépendance des données et donc pas d'obligation vis-à-vis du programme qui tourne (Si j'ai bien compris la FAQ de www.gnu.org ).
MonoFrance
[^]Re: .
linux est sous GPL et on ne se pose aucune question (à juste titre) quand au fait d'écrire des softs proprios pour lui. Pourquoi s'en poser pour des softs tournant sous la jvm ?
[^]Re: .
exactement,
de même heureusement que tous les document qui sont réalisé par OOo ne doivent pas être sous licence GPL ! :)
[^]Re: .
Euh, c'est pas comparable. Théoriquement (je ne suis pas juriste), tout le code qui lie avec du code GPL doit lui même être GPL.
Pour répondre au commentaire un cran plus haut, il me semble que la GPL de Linux a une clause spéciale pour autoriser l'exécution de programmes propriétaires.
[^]Re: .
je ne suis pas juriste non plus, mais bon, autant je comprends bien le "qui lie" quand il s'agit d'eviter que quiconque fasse un bibliotheque d'un soft GPL qui serait lié dans une appli proprietaire.
mais là, il ne s'agit pas de celà, c'est juste un language et son interpreteur ou sa machine virtuelle... dont il pourrait exister une implementation non libre d'ailleur.
dans le cas d'une liaison type "bibliotheque" que l'on souhaite eviter, il s'agit d'une utilisation détournée. or là il s'agit de l'essence même d'une machine virtuelle, elle est faite pour celà. la machine virtuelle ne se suffit pas a elle même.
vouloir par principe que l'utilisateur fasse du GPL sous pretexte que l'outil qu'il utilise soit GPL c'est : au mieux puéril, au pire du dogmatisme flagrant.
il m'arrive de pondre du php dans le cadre de mon boulot, le bout de code ne m'appartiens pas (c'est mon patron qui me paye), php est libre mais pas ce que je ponds... je serais dans l'ilegalité ? :)
[^]Re: .
Sauf que justement la GPL ne parle nul part de liaison. Elle parle de "travail basé sur", et de "raisonnablement indépendant". On s'en fout un peu finalement de la liaison elle même.
Est ce que ton programme java est un travail basé sur les sources de java ? est ce qu'il est raisonnablement indépendant du programme java lui même ?
[^]Re: .
Ben le problème, c'est que Java est une techno objet et fournit un framework objet destiné à être utilisé par les programmes, notamment en héritant des classes du framework. Hors la FAQ du site GNU est clair sur ce point : c'est un travail "dérivé". Je pense que Sun choisira une clause particulière pour lever toute ambiguité, comme le fond de nombreuses plateformes. Sinon ca sera le vrai bordel juridique.
MonoFrance
[^]Re: .
les modules noyaux sont obligatoirement sous gpl ?
Pourtant le noyau est sous gpl et fournit une api destiné à être utilisé par les modules ...
Le byte code ce n'est QUE des données pour la jvm. Ensuite ces données ont un sens particulier, et utilise des fonctions codés en gpl.
Comme si je disais 'si dans mon binaire il y a un structure toto, alors tu appelle "do_it(toto.get_data); trampoline(&toto);" et que les fonctions do_it et trampoline soit codé en gpl.
a moins qu'utiliser du code gpl dans de la mémoire oblige que toute la mémoire soit sous gpl ... (ca serait pratique par contre :-d )
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: .
les modules noyaux sont obligatoirement sous gpl ?
Il semblerait que oui :
http://www.oreillynet.com/linux/blog/2006/08/why_binaryonly_(...)
[^]Re: .
Pourtant c'est pas si simple et evident :
Quand tu fais un
#include<fichier gpl.h>
et que ce fichier contient des macros/ ...
Tu mets directement du code GPL dans ton soft.
Bref, interfacer avec un soft GPL sans etre GPL n'est pas forcement evident.
[^]Re: .
Fais une recherche sur lwn pour en apprendre plus sur la controverse EXPORT_SYMBOL_GPL.
Ils veulent entre autres bloquer totalement l'accès à l'usb du kernel vers 2008 pour tous les drivers proprio.
Il y avait une "tolérance" légère envers les modules proprio mais plus le temps passe et plus le code du kernel tournera autour d'une api qui ne sera accessible que par des modules GPL. Certains développeurs du kernel pensent que tous les modules proprio sont illégaux, tous.