Une licence plus permissive pour Java

Posté par  (site web personnel) . Modéré par Florent Zara.
Étiquettes :
0
17
mai
2006
Java
Sun a annoncé hier au cours de la conférence JavaOne, qui se déroule cette semaine à San Francisco, un changement de licence du Java SE 5.0 Java Development Kit (JDK) et Java Runtime Environment (JRE) afin d'aider leur distribution dans les systèmes libres, comme GNU/Linux ou OpenSolaris.

Cette nouvelle licence, nommée « Distro Licence for Java » (DLJ), permet aux distributions de proposer des paquets (.deb, .rpm, etc..) contenant les JDK et JRE, ce qui posait problèmes avec la licence précédente (« Binary Code License » - BCL).
En particulier, la DLJ permet :
  • d'utiliser le JDK sur n'importe quel OS pour créer, développer, tester et utiliser des programmes Java, comme auparavant,
  • de distribuer le JDK sur tout type de média et le pré-installer dans des distributions,
  • de distribuer le JDK directement ou indirectement à travers des distributeurs, revendeurs et en OEM.


À cette annonce, de nombreuses communautés se sont montrées enthousiastes et ont déjà commencé la création de paquets, notamment pour Debian, Ubuntu et Gentoo pour GNU/Linux et BeleniX, NexentaOS et Schillix pour OpenSolaris.

Notons qu'il ne s'agit absolument pas d'une licence libre puisqu'elle ne garantit que le droit de redistribution verbatim du JDK. De plus, elle ajoute des contraintes à cette redistribution (la compatibilité totale doit être assurée par le distributeur pour respecter le principe du "write once, run everywhere"). Cette annonce ne met donc pas fin aux projets libres gravitant autour de l'environnement Java, tels que Gcj, GNU Classpath et les "runtimes" tels que CACAO, JamVM, Jikes RVM, Kaffe et SableVM.

NdM: à noter également que Jonathan Schwartz, nouveau CEO de Sun Microsystems, a également déclaré : « La question n'est pas si nous allons rendre Java open source, mais comment ». Sun ne précise pas de date et ne fait pas de promesse ferme, mais il lance une consultation auprès des développeurs sur « comment open-sourcer Java » à travers le Java Community Process.
NdM 2 : merci à fredx pour avoir proposé la nouvelle. Les utilisateurs de Debian unstable et d'Ubuntu Dapper Flight 8 (pour amd64 ou i386) qui ont choisi d'utiliser les paquets non-free pourront dès maintenant installer ce JRE en utilisant la commande :

# apt-get install sun-java5-jre (29,5Mo en tout).
N'oubliez pas ensuite de mettre à jour vos alternatives en utilisant :
# update-alternatives --config java
et choisissez l'alternative '/usr/lib/jvm/java-1.5.0-sun/jre/bin/java'

Aller plus loin

  • # Fin d'un troll

    Posté par  . Évalué à -3.

    Java ca pue plus, c'est presque libre.

    • [^] # Re: Fin d'un troll

      Posté par  (site web personnel) . Évalué à 10.

      Moua pas encore. C'est juste un coup de deo, là, c'est tout.

      "La première sécurité est la liberté"

    • [^] # Re: Fin d'un troll

      Posté par  . Évalué à 2.

      C'est très, très, très loin d'être libre. C'est à peu près aussi libre qu'un Windows gratuit.

      • [^] # Re: Fin d'un troll

        Posté par  (site web personnel) . Évalué à 2.

        Pas si loin... aujourd'hui même :

        Rich Green, EVP, Sun Software, Sun Microsystems, Inc.
        (when asked if he was going to open source Java):
        "It's not a question of whether, it's a question of how. So we'll go do this."

        http://blogs.zdnet.com/Burnette/index.php?p=106

        http://about.me/straumat

        • [^] # Re: Fin d'un troll

          Posté par  . Évalué à 4.

          C'est marqué dans la news (mais c'est attribué à Schwartz, comme le reporte la news source). C'est même moi qui ai rajouté cette NdM, donc j'ai suivi.

          Cependant, la réponse est alambiquée et ne signifie clairement pas que le JDK va être publié sous une licence Open Source sous peu. Sun n'annonce pas plus que « on consulte les développeurs pour savoir comment faire », sous-entendu : ensuite on voit. Ça peut encore prendre des années, et ça peut ne pas se faire du tout. Mieux vaut ne pas crier victoire.

          Cependant, pour reprendre le sens originel de mon post, la licence actuelle est loin, très loin d'être une licence de logiciel libre (ou Open Source).

          • [^] # Re: Fin d'un troll

            Posté par  . Évalué à 3.

            Le CEO rassure : on va demander comment 'open sourcer' java. Il ne dit pas quand ni sous quelle license. Pendant ce temps, java continuera sa croissance, on l'adoptera encore plus, le dernier reproche était sa license.

            J'espère que les produits alternatifs continueront aussi à gagner du terrain, évitons le monopole.

            Aujourd'hui Java est aussi libre qu'un graticiel, pas plus. Et un graticiel n'est pas libre, seulement gratuit

      • [^] # Commentaire supprimé

        Posté par  . Évalué à 1.

        Ce commentaire a été supprimé par l’équipe de modération.

        • [^] # Re: Fin d'un troll

          Posté par  . Évalué à 1.

          Disons que je considérais qu'à partir du moment où il était gratuit, Microsoft s'emmerderait pas trop à interdire la redistribution. C'est possible que ça ne soit pas le cas, mais bon.

          Mais bon, visiblement d'autres ont des arguments "percutants" pour dire que c'est "presque libre", puisque je suis à 0. Dommage qu'ils ne les disent pas.

      • [^] # Re: Fin d'un troll

        Posté par  . Évalué à 9.

        ou qu'un driver nvidia proprio

  • # Plop

    Posté par  . Évalué à 3.

    Je rajoute ce lien qui donne (à mon avis) une bonne idée de la vision du projet JDK Distros de l'intérieur : http://weblogs.java.net/blog/robogeek/archive/2006/05/distri(...)

    Pour éviter les trolls comme sur Slashdot, on peut dores et déjà dire que distribuer le JDK et JRE de Sun par ce biais n'empêche absolument pas de distribuer les autres implémentations libres.
    La DLJ interdit par contre de faire et de distribuer un produit 'batard' mélangeant l'implémentation de Sun et une autre : Sun se pose encore la question de savoir comment libérer Java sans permettre à des concurrents "hostiles" (au hasard IBM ou Microsoft) de se baser dessus pour le concurrencer.

    • [^] # Re: Plop

      Posté par  . Évalué à 3.

      Si les implémentations concurrentes commencent à ne plus être compatibles entre elles, on peut les comprendre, ça mettrait sérieusement à mal le principe fondamental de Java. Je dois donc bien dire que cela ne me dérange pas plus que ça que Sun prenne son temps en la matière.

      • [^] # Re: Plop

        Posté par  . Évalué à 3.

        la belle affaire, quand on regarde le bazar apporté par les changements de versions de Java SE par Sun lui même...

      • [^] # Re: Plop

        Posté par  . Évalué à 2.

        Ce n'est pas si évident que cela.

        Tout d'abord le fait qu'il existe plusieurs implémentations de machine virtuelle ne remet pas nécessairement en cause le principe "write once, run anywhere".
        Je m'explique en prenant un exemple : J2EE. Il n' y a pas d'implémentation par Sun de serveur J2EE, juste une spécification. Les produits qui implémentent cette spécification peuvent être certifiés par Sun ce qui garanti qu'une application J2EE développée peut être déployée (simplement) sur n'importe quel serveur certifié.

        Secondement le fait d'ouvrir le code souce, permettra certainement d'augmenter la qualité du code, et donc l'efficience de la machine virtuelle (Sans vouloir remettre en cause les qualités des developpeurs de Sun) Là encore un exemple (mais je ne retrouve plus la source :(, si quelqu'un sait ). IBM a commencé à s'interesser fortement à l'open-source, lorsque pour aider au developpement de leur machine virtuelle java, ils ont décidé de mettre à disposition leur code source, et de demander à la communité d'apporter des améliorations. En 1 week-end les modifications modifiaient tellement le coeur du programme, que les ingénieurs de chez IBM ont du se pencher un certain temps sur le code pour comprendre l'ensemble des modifications.


        • [^] # Re: Plop

          Posté par  (Mastodon) . Évalué à -2.

          Le principe "write once, run anywhere", il n'y a bien que Sun qui y croit parce que ceux qui font du Java tournant sur plusieurs systèmes savent quel merdier monstrueux il faut faire pour que ça marche vraiment...

          • [^] # Re: Plop

            Posté par  (site web personnel) . Évalué à 6.

            Je m'insurge contre ce genre de propos :)
            On ne fait pas de swing mais pour tout le reste (dev web, xml, webservices, serveur applications....) on développé sous linux et c'est aussi déployé sous Windows et on a jamais eu AUCUN problème.

            http://about.me/straumat

            • [^] # Re: Plop

              Posté par  . Évalué à 2.

              Je me souviens d'un bete application bateau en java mais écrite visiblement par des gens qui ne connaissait que windows. Elle ne marchait pas sous linux parce que... elle cherchait un fichier avec le chemin en \ et pas en /. C'est idiot non.

              Donc à mon avis, il est aussi facile en java de faire une application qui marche partout que dans n'importe quel langage. Donc il n'y a pas à s'embêter avec des histoires de compatibilité.

              • [^] # Re: Plop

                Posté par  . Évalué à 3.

                Je me souviens d'un bete application bateau en java mais écrite visiblement par des gens qui ne connaissait que windows. Elle ne marchait pas sous linux parce que... elle cherchait un fichier avec le chemin en \ et pas en /. C'est idiot non.

                C'est prévu:
                http://java.sun.com/j2se/1.5.0/docs/api/java/io/File.html#se(...)
                mais même avec le langage le mieux conçu pour être indépendant de la plateforme, si tu ne veux pas l'être tu y arrivera toujours.

              • [^] # Re: Plop

                Posté par  . Évalué à 1.

                Dans le même genre, il y a encore plus con. Je me souviens, lors du test sous Linux d'une application développée sous MS-Windows, d'avoir eu un problème avec un fichier de configuration... dont le nom figurait tout en minuscules dans mon code et, sur le système de fichiers, avait sa première lettre en majuscule. Evidemment ça ne posait aucun problème sous MS-Windows, mais ça générait une erreur sous Linux.

                • [^] # Re: Plop

                  Posté par  . Évalué à -1.

                  tiens, si quelqu'un peut m'expliquer pourquoi ces foutus FS sous linux sont case sensitive?

                  Ca m'a pourrit la vie aussi au boulot, et apres un test rapide, on ne peut pas creer 2 fichiers avec le meme nom dans des casses differentes (ce qui serait de toutes facons une connerie sans nom qu'il faut interdire a l'utilisateur).

                  Sinon, pour l'histoire des \ a la place des /, par experience, ca ne gene pas le constructeur de File qui s'en tamponne a allegrement et retrouve ses petits sans problemes.
                  Bon, c'est sur que si tu lui donnes un c:\\Program Files et que tu lance sous linux, il va tirer la gueule...

                  • [^] # Re: Plop

                    Posté par  . Évalué à 3.

                    bon ok, j'ai parle trop vite :
                    j'ai reussi a creer deux fichiers avec des casses differentes (je mantiens que c'est une connerie sans nom ce truc).

                    et effectivement la classe file se vautre avec un \\ a la place du / (dans l'autre sens ca marche bien, ie / a la place de \\ sous windows).

                    Excusez le derange.

                    /me inconditionnel de File.pathSeparator et surtout des classes static utilitaires pour manipuler les paths

                  • [^] # Re: Plop

                    Posté par  . Évalué à 2.

                    Tien, si quelqu'un peut m'expliquer pourquoi ces foutus FS à la windows s'emmerdent à faire une conversion sur chaque nom de fichier pour faire une comparaison case-insensitive alors que ce serait plus facile de comparer caractère par caractère.
                    En plus il y a plein de caractères qu'ils n'acceptent pas dans les nom de fichier (bon, OK, pour les caractères de contrôle c'est judicieux).

                  • [^] # Re: Plop

                    Posté par  . Évalué à 3.

                    tiens, si quelqu'un peut m'expliquer pourquoi ces foutus FS sous linux sont case sensitive ?

                    Sans doute pour des raisons historiques de compatibilité avec Unix (tout comme pour NTFS sous MS Windows et HFSX sous Mac OS X) et parce que quand Unix a été créé, c'était plus simple de faire comme ça.

          • [^] # Re: Plop

            Posté par  . Évalué à 4.

            Je ne sais pas comment vous développez, mais je n'ai jamais eu de problèmes pour faire des applis portables.
            La compilation d'un .jar sous windows et son déploiement sur un Unix quelconque a toujours réussi.

            • [^] # Re: Plop

              Posté par  (site web personnel) . Évalué à 2.

              Moi y a pas trop longtemps, ma ptite amie qui est en médecine viens avec un cd qu'elle à «reçu» (fallais le payer quand même) à la fac et me demande si elle peu voir ça sur mon laptop. Donc bien sur, première réaction, est ce que ce truc va marcher sur ma debian? Donc je monte le cd, je regarde un peu, et la je vois des archives jar! Génial me dis-je, du java! Donc je lance l'appli, ouais, ça marche et... ha bein non, tiens un message d'erreur! Ha oui il trouve pas le fichier "images\trucmuch.jpg"...
              Et oui, un jolie chemin avec un bon gros "\" bien gras. Bien entendu, l'image était le principale intéret de l'appli (photo de coupes de cellules avec possibilité de "zoomer" [chargement d'une autre image] sur certaines zones). Bon voyant que ma copine s'impatienter à me voir trafiquer tout ça, j'ai rebooté sous win... Quand même c'est con, à un chemin de fichier prêt c'était bon, je maudit le gars qui a pondu cette appli.

              D'ailleurs détail amusant, bien que les photos étaient accessible directement au lancement de l'appli, pour avoir la description de se qui était visible sur l'image (le plus interessant donc), il fallais taper un mot de passe! (fourni lors de l'achat)
              Franchement trop con XD

              • [^] # Re: Plop

                Posté par  (site web personnel) . Évalué à 3.

                Oui... ça arrive, certaisn font des bétises, j'en ai meme vu faire un exec de la commande env pour récupérer des infos systèmes... faut pas pousser non plus :)

                Pour le slash, c un peu pareil... il faut utiliser File.separator

                http://about.me/straumat

              • [^] # Re: Plop

                Posté par  (site web personnel) . Évalué à 3.

                En même temps, le problème du "\" ne vient pas de Java mais des codeurs incompétents du soft en question. Les chemins vers les fichiers dans Java sont transparents par rapport au système sous-jacent; après évidemment, rien n'empêche un développeur un peu porc de mettre ses chemins en dur... Mais c'est porc.

              • [^] # Re: Plop

                Posté par  . Évalué à 1.

                Euh... normalement les objets utilisés pour accéder aux fichiers en java acceptent '/' et '\' comme séparateur de fichier. En tout cas, je n'ai jamais vu ce problème, et pourtant je mets systématiquement des '/' dans mon code et au boulot je suis sous windows :-(

                En revanche, le problème peut venir, soit d'un chemin absolu qui commence par "D:\", soit d'une erreur minuscule/majuscule. Le problème de casse sur les noms de fichiers est le problème majeur que l'on rencontre lorsque nos applications au boulot sont déployées sur des *NIX. Dans l'autre sens, quand je code chez moi sous linux, il faut que je fasse attention de ne pas avoir deux fichiers qui ne diffèrent que par la casse du nom... sinon ça ne passe pas sous windows.

        • [^] # Re: Plop

          Posté par  . Évalué à 1.

          IBM a commencé à s'interesser fortement à l'open-source, lorsque pour aider au developpement de leur machine virtuelle java, ils ont décidé de mettre à disposition leur code source, et de demander à la communité d'apporter des améliorations. En 1 week-end les modifications modifiaient tellement le coeur du programme, que les ingénieurs de chez IBM ont du se pencher un certain temps sur le code pour comprendre l'ensemble des modifications.
          Il me semble que c'était pour jikes, le compilateur d'IBM écrit en C++. Je n'ai pas retrouvé la source, mais je sais que je l'ai lu il n'y a pas longtemps...

        • [^] # Re: Plop

          Posté par  . Évalué à 2.

          Je m'explique en prenant un exemple : J2EE. Il n' y a pas d'implémentation par Sun de serveur J2EE, juste une spécification. Les produits qui implémentent cette spécification peuvent être certifiés par Sun ce qui garanti qu'une application J2EE développée peut être déployée (simplement) sur n'importe quel serveur certifié.

          Desolé de te contredire, mais il y a bien une implémentation de J2EE par Sun: Sun Java System Application Server (ou JSAS pour les intimes) [1] qui maintenant est même distribué en Open Source (CDDL) sous le nom du projet GlassFish [2].
          Wikipedia en francais ecrit ceci [3]:
          En juin 2005, Sun a annoncé le lancement d'un projet open-source pour créer la prochaine version de Java System Application Server dans sa version destinée aux développeurs, sous le nom de projet GlassFish


          Je confirme avoir lu la même chose que toi sur la libération du code source de Jikes par IBM, et les modifications intenses que la communauté leur a apporté par la suite.

          [1] http://en.wikipedia.org/wiki/Sun_Java_System_Application_Ser(...)
          [2] http://en.wikipedia.org/wiki/Glassfish_Application_Server
          [3] http://fr.wikipedia.org/wiki/Java_et_logiciel_libre

          • [^] # Re: Plop

            Posté par  (site web personnel) . Évalué à 1.

            Ce qu'il veut dire, c'est que J2EE est une norme et pas un produit fini comme peut l'être PHP. PHP, c'est PHP, un point c'est tout, il peut ya voir des forks mais à vos risques et périls.
            J2EE est une norme, donc, il y a des implémentations, (JBoss, JOnAS, Websphere, weblogic...) et du moment que la norme est respectée, peu importe l'lmplémentation choisie.

            http://about.me/straumat

  • # petite erreur dans les noms de paquet

    Posté par  . Évalué à 1.

    J'imagine que c'est une faute de frappe, mais bon: le paquet sun-java5-jre n'est pas le JDK mais juste le runtime. Pour installer le JDK c'est le paquet sun-java5-jdk.

    voilà...

  • # dapper flight 8??

    Posté par  (site web personnel) . Évalué à 1.

    elle est deja dispo la dapper flight 8? je crois pas ou alors j'ai été enduis d'erreurs

  • # Dans d'autres nouvelles de Sun...

    Posté par  . Évalué à 5.

    http://www.zdnet.com.au/news/software/soa/Sun_flirts_with_Ub(...)

    Jonathan Schwartz, patron de Sun annonce à la presse son intention de supporter "agressivement" Ubuntu...

    ...bon on verra dans les faits, mais on dirait que Sun opère un changement d'attitude face à Linux assez radical ces derniers jours.

    Mort de Solaris à l'horizon ou juste manoeuvre pour la presse?

    • [^] # Re: Dans d'autres nouvelles de Sun...

      Posté par  . Évalué à 7.

      Pas si simple.

      Il ne s'agit pas d'une soudaine prise de sympathie pour Linux.
      Il s'agit plutôt d'un revirement stratégique de Sun qui souhaite se concentrer sur les services, plus que sur les produits en basculant tout en opensource.

      Ils perdent du terrain sur la bataille des Os (OpenSolaris)
      Il y a la mise sous licence opensource de tous les produits au dessus de Netbeans, en perte de vitesse face à Eclipse ... http://www.01net.com/article/314820.html

      Dans le mag "Programmez" de ce mois -ci, Emmanuel Obadia (directeur marketing de Sun) evoque aussi ce revirement.

      Bizarrement ca coincide avec avec le départ de Scott Mac Nealy de la direction de l'entreprise et l'arrivé de Mr Scwartz.
      http://www.01net.com/article/315279.html

      En tout cas! c'est de bon augure pour le libre

      • [^] # Re: Dans d'autres nouvelles de Sun...

        Posté par  . Évalué à 2.

        C'est certain, c'est depuis le départ de Mc Nealy qu'on a un regain d'annonces genre "linux est mon ami" de la part de sun alors qu'avant le changement j'avais l'impression que le ton allait plutôt se durcir... et non-seulement des paroles, mais déjà un act concrétisé...

        maintenant, vu la déclaration comme quoi Ubuntu était "une des plus importantes, si pas la plus importante distribution linux", accompagnée de la présence de Mark Shuttleworth et les déclarations concernant Ubuntu pour Sparc, on peut se demander si il va y avoir un réel rapprochement Ubuntu/Sun, et sous quelle forme.

        • [^] # Re: Dans d'autres nouvelles de Sun...

          Posté par  . Évalué à 1.

          Mc Nealy disait peut-être que Linux (le kernel) n'était pas bien, mais il y a OpenSolaris ; ça ne veut pas dire qu'il était contre la libération de produits Sun.

    • [^] # Re: Dans d'autres nouvelles de Sun...

      Posté par  . Évalué à 7.

      Le rapprochement d'Ubuntu semble assez logique. Sun a une bonne crédibilité sur les serveurs mais assez peu pour le bureau malgré OpenOffice et une grosse contribution à Gnome. Et Linux semble plus pret pour le desktop que Solaris, faire un OS pour le bureau demande par exemple une liste de compatibilité matérielle bien plus large que pour un serveur.

      Et si on regarde les grandes distribs qui sont très impliquées dans Gnome il y'a :
      - Red Hat
      - Suse
      - Ubuntu

      Seul Ubuntu n'est pas en concurence frontale avec Solaris sur les serveurs.

      Mort de Solaris, je ne pense pas, mais attaque du marché du bureau avec un Linux dérivé d'Ubuntu plein de Java et de star office sous AMD... ça ne serait pas forcément dénué de sens.

      • [^] # Re: Dans d'autres nouvelles de Sun...

        Posté par  . Évalué à 2.

        Justement non, Shuttleworth a indiqué à JavaOne 2006 la sortie d'Ubuntu server pour juin. Une de ses particularité étant d'intégrer le Java de Sun.

        Le petit astronaute aura réussi à convaincre Sun.

  • # Euh...

    Posté par  . Évalué à 1.

    Avant d'être trop content, est-ce que quelqu'un peut m'expliquer ça dans le point 2 de la licence :

    provided that: [...] (c) you do not combine, configure or distribute
    the Software to run in conjunction with any additional software
    that implements the same or similar functionality or APIs as the
    Software


    En gros, si je comprends bien, c'est soit JDK, soitGCJ, classpath, jikes...

    C'est moi qui me goure ou quoi ?

    • [^] # Re: Euh...

      Posté par  . Évalué à 6.

      "to run in conjunction with". Et non "distribute the Software in conjuction with". Il est donc tout à fait permis de distribuer à la fois gcj et le JDK. Le but de cette clause est d'interdire les "mélanges", c'est à dire de combiner le compilateur Sun avec les classes de classpath (quoique je vois pas forcément trop l'intérêt ;-) ou l'inverse.

      Non, IANAL, mais en lisant cette licence je ne vois pas où l'on pourrait avoir de grosses surprises. C'est une licence non libre assez simple, globalement. Excepté la question de la clause de compatibilité qui est un peu tordue (qu'il faut entendre par "faites gaffe à ce que vous faites sur les systèmes qu'on ne supporte pas nous officiellement", je pense - mais entre le droit et la politique commerciale...).

  • # Et BSD

    Posté par  . Évalué à 2.

    Je rêve d une version native pour FreeBSD et consorts en particulier et libre en général...doux rêve...PAF ah mince suis encore tombé du lit :)...

    • [^] # Re: Et BSD

      Posté par  (site web personnel) . Évalué à 2.

      http://www.freebsdfoundation.org/downloads/java.shtml

      La version native de java pour freebsd (i386).

      • [^] # Re: Et BSD

        Posté par  . Évalué à 2.

        Natif certes, mais non libre...

      • [^] # Re: Et BSD

        Posté par  . Évalué à 1.

        Connaissait pas, on dirait un enfant illégitime :-)...

    • [^] # Re: Et BSD

      Posté par  . Évalué à 4.

      Les gens de chez FreeBSD ont obtenu le droit de faire et distribuer un port.

      Par contre il semblerait que l'ouverture dont parle la dépeche, le droit d'intégréer Java dans un OS (de le patcher légèrement, le packager et le redistribuer) ne soit accordé qu'aux distros de Linux et Solaris.

      En effet la nouvelle licence http://download.java.net/dlj/DLJ-v1.1.txt dit:
      « "Operating System" means any version of the Linux or OpenSolaris operating systems »

      Ce qui ne fait pas nos affaires, pour les autres *BSD (et d'autant moins que même Sun ne distribue pas d'implem native pour ces OS).

  • # Gentoo

    Posté par  . Évalué à 1.

    Un paquet sun-jdk est déjà dispo depuis longtemps mais avec la "Fetch Restriction".
    Bref fallait télécharger le tar.gz sur le site de sun, le copier dans /usr/portage/distfiles et emerger sun-jdk.

    Ça va être plus simple maintenant :)

Suivre le flux des commentaires

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