Discussion :

[Bill Fassinou]

La prochaine mise à jour de sécurité de Java 8 prévue pour le 16 avril 2019 sera payante,
avertit Oracle

Cette semaine, Oracle a envoyé des courriers électroniques à certains utilisateurs de la plateforme Java pour les avertir d’une prochaine mise à jour de sécurité payante de Java 8. Selon la note d’information d’Oracle, cette mise à jour de sécurité critique pour la version 8 de Java sera uniquement disponible pour les utilisateurs qui possèdent une licence d’utilisation active. Bien évidemment, cela a mis en rogne certaines personnes à la manière de Alex Rice, fondateur et directeur technique de HackerOne qui voit en cette mesure d’Oracle une façon d’obliger les gens à posséder une licence. Il a été annoncé depuis l’année dernière que le support public d’Oracle pour la plateforme Java 8 prendrait fin en janvier dernier. Cette décision fait suite à plusieurs changements qui sont survenus dans le cycle de développement de Java SE qui, selon Oracle, était en retard par rapport à ses concurrents.

Oracle publie désormais une nouvelle version de Java avec de nouvelles fonctionnalités tous les six mois, en mars et en septembre. Et ces versions de fonctionnalités (feature release) seront suivies par des mises à jour (update release) chaque trimestre, comme c’est le cas en janvier, avril, juillet et octobre. C'est le nouveau cycle de publication qui a été adopté après la sortie de Java 9 en septembre dernier. L'adoption de ce nouveau rythme de publication a conduit Oracle à prendre d'autres décisions qui pourraient ne pas réjouir autant les développeurs et les entreprises. En septembre 2018, lorsque le JDK 11 (version 18.09) a été publié, il n'y aura plus à l’avenir des mises à jour publiques, y compris les patchs de sécurité pour le JDK 8. Si l'on se fie aux chiffres de Semaphore CI, Java 8 était encore utilisé fin 2017 dans plus de 80 % des projets commerciaux. Il y a donc beaucoup d'utilisateurs qui seront affectés par cette décision.

Le fait est que désormais, quand une nouvelle version de Java sera disponible, la version précédente va immédiatement cesser de recevoir des mises à jour publiques. Pour mieux comprendre ce que cela veut dire, rappelons un peu comment se sont passées les mises à jour jusqu'ici. Lorsque le JDK 6 a été publié, les mises à jour du JDK 5 ont continué à être publiées pendant près de trois ans (deux ans et onze mois pour être précis). Avec le JDK 7, le JDK 6 a continué à avoir des mises à jour publiques pendant un an et neuf mois. Le JDK 7 a ensuite eu treize mois de mises à jour publiques après la sortie du JDK 8. Pour aller plus loin dans l’explication, le nouveau rythme de publication du JDK, Oracle estime que l'effort d'ingénierie pour rendre les mises à jour disponibles pour de nombreuses versions antérieures serait insoutenable.

C'est pour cela qu'à la sortie d'une nouvelle version de fonctionnalités (feature release), la version précédente ne va plus recevoir de mises à jour. Pour atténuer le problème, Oracle a toutefois décidé de passer à un modèle LTS (support à long terme). Des versions spécifiques du JDK seront des versions LTS, ce qui signifie qu'elles auront des mises à jour pendant trois ans (jusqu'à la prochaine version LTS). Toutes les autres versions intermédiaires (les versions de fonctionnalités) ne seront mises à jour que pendant six mois (jusqu'à la prochaine version de fonctionnalités). Et pour synchroniser le nouveau système, le JDK 8 a été classé comme une version LTS, ce qui veut dire qu'après la sortie du JDK 11 (LTS) en septembre, le JDK 8 ne va plus recevoir de mises à jour publiques.

On peut dire que jusque-là, les utilisateurs étaient assez bien informés que le mois de janvier 2019 passé, les mises à jour publiques de Java cesseraient et les prochaines seront désormais à l’endroit de ceux disposant uniquement d’une licence d’utilisation active (ou licence rémunérée). Cependant, Alex Rice, le directeur technique de HackerOne n’a pas du tout apprécié de recevoir ce mail de la part des représentants des ventes d’Oracle. Dans un tweet, il exprime son mécontentement et estime que la personne qui lui a adressé le courrier électronique semble avoir utilisé cette tactique comme stratégie de terreur pour le convaincre d'acheter une licence. Il dit ensuite que HackerOne n’entretient aucune relation avec l’entreprise Oracle et que le courrier était inattendu.

Pour Rice et d’autres personnes, le courrier électronique ressemblerait à une demande de rançon, à une tentative d’extorsion ou à une tactique alarmiste de la part d’Oracle. D’autres commentaires avancent également l’argument selon lequel Oracle avait sans doute constaté qu’une grande majorité des entreprises utilisant les infrastructures Java travaillent encore avec Java 8 et a voulu en profiter pour s’en mettre plein les poches en les invitant à prendre des licences rémunérées pour bénéficier de mises à jour.

Une partie du mail reçu par Rice indique ce qui suit : « … Je vous contacte pour que vous sachiez que la première mise à jour critique trimestrielle non disponible au public pour Java 8 sera publiée le 16 avril. Toutes les applications et tous les serveurs non-oracle exécutant la version 8 de Java ou ultérieure nécessiteront une licence pour pouvoir continuer à recevoir les correctifs et les mises à jour au-delà de la date de publication. Sans licence appropriée en place, les correctifs et les mises à jour ne seront pas disponibles, ce qui risquerait de rendre votre environnement de serveur et de bureau exposé et vulnérable … ».

Cependant, ils sont beaucoup à ne pas être du même avis que Rice. En réponse à son tweet, certains ont estimé qu’Oracle était dans son droit de fournir un service d’assistance ou de mise à jour payant, car le support public étant expiré depuis janvier passé. Cela dit, ils reconnaissent quand même que la nouvelle stratégie d’Oracle vise beaucoup plus à enrichir la firme que d’offrir plus de satisfaction aux développeurs et aux entreprises technologiques. En effet, pour eux, les entreprises devront modifier leur façon de fonctionner en choisissant le format de deux composants qui leur correspondra le plus dans le triangle stabilité-sécurité-gratuité.

Source : tweet

Et vous ?

Quel est votre avis sur le sujet ?
Avez-vous aussi reçu l'email ? Quelle a été votre réaction ?

Voir aussi

Fin prématurée du support gratuit du JDK 8 ? Pas vraiment, Oracle ne va pas cesser de livrer des mises à jour publiques pour JDK 8 avant janvier 2019

Oracle annonce des changements pour Java SE : deux versions par an, licence GPL, des fonctionnalités commerciales du JDK d'Oracle en open source

Semaphore : de nombreux nouveaux projets commerciaux sont développés dans des langages qui ne sont plus supportés, quelles en sont les raisons ?

[Gugelhupf]

Java 8 est tout de même sorti en mars 2014, et ayant moi-même assuré la migration du projet de mon entreprise (une quarantaine de modules Maven) du JDK 8 à OpenJDK 11, je n'ai pas rencontré de très grosses difficultés pour migrer le codebase (suppression d'imports SUN, dépendances JAXB, typage plus strict, correction de tests etc). Et puis Microsoft fait bien payer les entreprises pour le support étendu de Windows 7 non ? Je n'arrive pas à voir où est le problème

[Uther]

A priori, d'après leur site la licence est à 26,05€ par an.
A ce prix là je pense que le choix entre faire une migration ou payer le support étendu sera vite fait pour pas mal de monde.

[Pyramidev]

A priori, d'après leur site la licence est à 26,05€ par an.
A ce prix là je pense que le choix entre faire une migration ou payer le support étendu sera vite fait pour pas mal de monde.

Je suis presque sûr que les prix augmenteront régulièrement.
Ce sera alors un cas particulier du pied-dans-la-porte.

[vohufr]

S'ils n'avaient pas réellement l'intention de tuer Java avant.... Disons qu'ils trouvent de nouvelles solutions pour atteindre cet objectif...

[beenoix]

Ma première réaction a été "Ah ouais c'est pas bien de faire payer une mise à jour de sécurité" après, étant développeur .NET, je me suis que fais Microsoft, par exemple pour le framework 4.5.1 sorti a peu près en même temps que Java 8 soit en mars 2014 et bien la réponse est simple => plus de support (depuis 2016) merci de faire les montées de version.

https://support.microsoft.com/fr-fr/...et%20framework

A mon sens, Oracle passe du temps a supporter des vieilles versions de framework (donc payer des développeurs pour ça) pour que des entreprises ne mettent pas la main à poche (migration de vieilles applis) donc ça ne me paraît pas déconnant de facturer ce service.

Après il faut peut-être partir sur de l'open source et laisser la communauté supportait le framework que vous aurez choisi mais cela implique quoi qu'il en soit des montées de version régulières (sinon c'est la mort assurée) donc au final c'est le chat qui se mort la queue... On veut tout gratos et sans investir en informatique c'est pas une bonne façon de penser...

[dfiad77pro]

Ma première réaction a été "Ah ouais c'est pas bien de faire payer une mise à jour de sécurité" après, étant développeur .NET, je me suis que fais Microsoft, par exemple pour le framework 4.5.1 sorti a peu près en même temps que Java 8 soit en mars 2014 et bien la réponse est simple => plus de support (depuis 2016) merci de faire les montées de version.

https://support.microsoft.com/fr-fr/...et%20framework

A mon sens, Oracle passe du temps a supporter des vieilles versions de framework (donc payer des développeurs pour ça) pour que des entreprises ne mettent pas la main à poche (migration de vieilles applis) donc ça ne me paraît pas déconnant de facturer ce service.

Après il faut peut-être partir sur de l'open source et laisser la communauté supportait le framework que vous aurez choisi mais cela implique quoi qu'il en soit des montées de version régulières (sinon c'est la mort assurée) donc au final c'est le chat qui se mort la queue... On veut tout gratos et sans investir en informatique c'est pas une bonne façon de penser...

Ayant connu les 2 cas , migrer du Framework .net 4.5.1 au 4.7 me semble plus simple que de passer de java 7--> 8 ou de 8 à 11.

[inumerix]

Mais ou diable acheter cette fameuse licence ???
J'ai beau chercher, je ne trouve pas.

[NBoulfroy]

J'avoue ne pas trop comprendre la politique d'Oracle depuis quelques temps : ils s'étonnent que leurs clients partent vers PostgreSQL suite aux déboires de leur SGBD.

Maintenant, je comprends que le support à un moment doit être payant mais ... comment dire ... Je ne sais pas. Je suis développement PHP / Javascript / C# (je n'ai pas mis CSS et HTML mais vous avez compris) et je ne suis pas habitué à ce genre de pratique.

Comme l'a dit quelqu'un, MS est plutôt clair avec C# : à un moment, ils ne garantissent plus la maintenance. C'est assez clair et précis je trouve et on n'est pas non plus pris pour un pigeon, en quelque sorte.

PHP, c'est un peu pareil : une fois une version en fin de LTS, il faut migrer mais de la même façon que le C#, on ne met pas un couteau sous la gorge.

En revanche, j'avais cru comprendre que la prochaine version estampillée "LTS" de Java serait la version 12 mais, elle est déjà sortie va bientôt sortir ? Je n'ai pas vu de mention à ce propos.

[The F0x]

En revanche, j'avais cru comprendre que la prochaine version estampillée "LTS" de Java serait la version 12 mais, elle est déjà sortie va bientôt sortir ? Je n'ai pas vu de mention à ce propos.

Non la LTS après Java 8 est Java 11 (avec un end of primary support pour Septembre 2023, soit 5 ans de support), la suivante devrait être Java 14. cf -> Java SE support roadmap

Sinon Java 12 est bien sorti le mois dernier, le 21 mars il me semble mais ce n'est pas une LTS, donc a réserver aux tests et aux experimentations.

[The F0x]

Ayant connu les 2 cas , migrer du Framework .net 4.5.1 au 4.7 me semble plus simple que de passer de java 7--> 8 ou de 8 à 11.

Le passage de 8 à 11 est moins douloureux je trouve que de 7 à 8. le seul truc un peu sensible c'est la modularisation pour la gestion des dépendances mais avec de bon tests on trouve assez vite les dépendance a reconfigurer.

[NBoulfroy]

Non la LTS après Java 8 est Java 11 (avec un end of primary support pour Septembre 2023, soit 5 ans de support), la suivante devrait être Java 14. cf -> Java SE support roadmap

Sinon Java 12 est bien sorti le mois dernier, le 21 mars il me semble mais ce n'est pas une LTS, donc a réserver aux tests et aux experimentations.

Merci pour la précision, j'avoue suivre de loin ce langage car je ne travail pas dessus (professionnellement comme personnellement).

[thelvin]

Le passage de 8 à 11 est moins douloureux je trouve que de 7 à 8. le seul truc un peu sensible c'est la modularisation pour la gestion des dépendances mais avec de bon tests on trouve assez vite les dépendance a reconfigurer.

Euh, et la douleur du passage en 7 à 8, elle vient d'où, exactement ?

A de très rares exceptions près, passer de 7 à 8 consiste à installer Java 8. Voilà, fini.

[esperanto]

Moi ce qui m'étonne dans cet article, ce n'est pas tant que le support devienne payant (si la version est en fin de vie, ceux qui ont des raisons de la garder doivent payer le support), mais plutôt les parties en gras dans le titre:

La prochaine mise à jour de sécurité de Java 8 prévue pour le 16 avril 2019 sera payante,

Je sais pas vous, mais en général j'ai du mal à prévoir des mois à l'avance quels trous de sécurité vont être trouvés dans mes applications...

Du coup ça ressemble à un prétexte pour faire payer les gens, un peu comme les créateurs d'antivirus qui publient régulièrement des alertes afin de justifier l'achat des mises à jour, quitte à collaborer avec les auteurs de virus pour être sûr qu'il y a bien des raisons de le faire!

Mais je préfère toujours çà à la politique de Microsoft pour Windows, à savoir refuser de voir que personne ne veut de la nouvelle version, et plutôt que de se demander pourquoi, tout faire pour que les ordinateurs deviennent progressivement incompatibles avec l'ancienne, problèmes de sécurité ou pas...

[Uther]

Ca n'a rien de vraiment surprenant. A moins qu'il y ait une faille particulièrement critique et/ou exploitée, les éditeurs ne sortent pas leurs correctifs immédiatement. Ils préfèrent généralement attendre pour les sortir par paquets à date fixe et ainsi éviter la multiplication des installation.

A peu près tous les éditeurs font ça. Par exemple Microsoft a ses "patch Tuesday" tous les premiers Mardi du mois.

[hboutemy]

Boujour,

Il y a confusion : Java en lui-même est Open Source depuis Java 7, disponible en licence GPL, avec de nombreuses distributions de qualité (à jour d'un point de vue sécurité) disponibles gratuitement, et un support payant optionnel de certains éditeurs (si vous voulez pouvoir ouvrir des incidents et bénéficier d'un support direct).

Ce qui est devenu payant ici est la distribution d'Oracle de Java, qui a arrêté la phase de mise à disposition publique et gratuite et passe en mise à disposition des personnes qui ont choisi d'acheter le support Oracle.

Mais de nombreuses autres distributions Java restent mises à jour et mises à disposition gratuitement : je vais me limiter à une seule distribution, AdoptOpenJDK, mais il y en a de nombreuses (justement trop nombreuses pour que je les cite ici)

Je fais un talk sur le sujet lors de Devoxx France dans 2 semaines : https://cfp.devoxx.fr/2019/talk/NST-...atuit_(en_GPL)

N'hésitez pas à venir pour mieux comprendre (et ne pas vous laisser berner par le discours peu clair qui est en train d'être diffusé)

[esperanto]

Ce qui est devenu payant ici est la distribution d'Oracle de Java, qui a arrêté la phase de mise à disposition publique et gratuite et passe en mise à disposition des personnes qui ont choisi d'acheter le support Oracle

Certes mais es-tu certain que la communauté OpenJDK continuera encore longtemps de maintenir la version 8 et d'y apporter des patches de sécurité? Puisqu'en fait ici, seuls ceux qui veulent rester en Java 8, quelle que soit la raison, sont concernés...

[hboutemy]

Certes mais es-tu certain que la communauté OpenJDK continuera encore longtemps de maintenir la version 8 et d'y apporter des patches de sécurité? Puisqu'en fait ici, seuls ceux qui veulent rester en Java 8, quelle que soit la raison, sont concernés...

Deux éléments de réponse :

1. même si Oracle ne distribue plus gratuitement à tous sa distribution binaire mais uniquement à ses clients payants, du fait de la licence GPL, Oracle se doit de redistribuer les modifications des sources : de ce point de vue, Oracle est un membre de la communauté Java comme un autre, donc tant qu'Oracle fait des modification pour le support à ses clients, les améliorations de sources diffusées aux clients Oracle seront disponibles à tous,

2. de leur coté, de nombreux autres acteurs ont publié un plan de support qui dure encore plus longtemps qu'Oracle, que ce soit RedHat, Azul, Amazon, ... Et ces acteurs ont tout autant l'obligation de publier les sources du fait de la licence GPL

La communauté Java est vraiment grande et diverse, et expliciter que la distribution binaire d'Oracle est payante à partir d'une certaine date est le meilleur moyen de stopper l'habitude (prise du temps ou Java n'était pas GPL) d'aller toujours chercher son JDK chez Sun (puis Oracle), même quand la période de fin de mise à disposition publique des mises à jour est révolue (cette "End of Public Update" étant par contre une invention d'Oracle qui n'existait pas avec Sun : avec Sun, on passait directement de "gratuit" à "fin de support" = "End of Support").

Par exemple, pour ceux qui utilisent encore Java 7, qui télécharge encore son JDK 7 chez Oracle ? Sans se rendre compte que c'est une mise à jour 7u80 qui est très vieille et pas du tout à jour d'un point de vue sécurité (ne supporte pas TLS1.2 par exemple), alors que les distributions Linux distribuent des versions parfaitement à jour = 7u221 à ce jour?

Java 8 est strictement comme Java 7, sauf qu'Oracle n'ayant pas communiqué sur la 7 comme il l'a fait sur la 8, tout le monde est resté tranquillement dans ses mauvaises habitudes, sans se rendre compte qu'ont était à coté de la plaque : et je me mets dans le lot, car je faisais pareil... J'ai juste été embêté par le manque de support TLS1.2 avant qu'Oracle annonce son plan pour Java 8, donc j'ai eu le temps de me rendre compte que le problème n'était pas cette clarification du prix des mises à jour des distributions Java chez Oracle, mais bien qu'on téléchargeait chez Oracle des versions non mises à jour, alors que tout était expliqué. En tapant de façon beaucoup plus explicite au portefeuille, Oracle nous force à lire et comprendre ce qui était écrit depuis longtemps : merci Oracle (même si ça leur coute le role du méchant).

Si vous pouvez venir à Devoxx France, mon talk approfondira tout cela : il sera enregistré, donc tout le monde pourra le voir un peu plus tard

[Uther]

1. même si Oracle ne distribue plus gratuitement à tous sa distribution binaire mais uniquement à ses clients payants, du fait de la licence GPL, Oracle se doit de redistribuer les modifications des sources : de ce point de vue, Oracle est un membre de la communauté Java comme un autre, donc tant qu'Oracle fait des modification pour le support à ses clients, les améliorations de sources diffusées aux clients Oracle seront disponibles à tous

Même si l'OpenJDK a été mis sous licence GPL, il appartient tout de même à Oracle à la base. Cela leur permet de distribuer sous licence propriétaire leur JRE et JDK qui repose sur le OpenJDK. Ils sont libres de faire les modifications qu'ils veulent dessus sans obligation de redistribuer les sources.

2. de leur coté, de nombreux autres acteurs ont publié un plan de support qui dure encore plus longtemps qu'Oracle, que ce soit RedHat, Azul, Amazon, ... Et ces acteurs ont tout autant l'obligation de publier les sources du fait de la licence GPL

Ces acteurs n'étant pas propriétaires des source, ils sont eux en effet contraint par la GPL et doivent redistribuer les sources de leur modifications.

[esperanto]

1. même si Oracle ne distribue plus gratuitement à tous sa distribution binaire mais uniquement à ses clients payants, du fait de la licence GPL, Oracle se doit de redistribuer les modifications des sources : de ce point de vue, Oracle est un membre de la communauté Java comme un autre, donc tant qu'Oracle fait des modification pour le support à ses clients, les améliorations de sources diffusées aux clients Oracle seront disponibles à tous

Pas forcément. La mise sous licence GPL est réputée contaminante, mais pas rétro-active. Or, au sens strict, Sun n'a jamais mis le JDK en GPL: ils ont créé une branche distincte appelée OpenJDK qui est en GPL, tout en continuant de maintenir leur propre version sous leur propre licence. Et le portage de la version fermée à la version libre est alors selon leur bon vouloir, et pas systématique.
Ainsi par exemple Swing a été totalement ré-implémenté de façon propriétaire dans le JDK d'Oracle, même si la signature des classes et méthodes n'a évidemment pas changé. Je l'ai découvert l'an dernier quand un client a longtemps cherché un bug dans une de mes applications, avant de s'apercevoir que le bug ne se produisait qu'avec le JDK d'Oracle sous Linux, pas avec l'OpenJDK.
Alors non, les deux JDK sont compatibles mais l'Open JDK est un fork qui n'est pas forcément synchronisé avec celui d'Oracle.

Avant que certains me hurlent dessus "qui utilise encore Swing?" ma réponse: ceux qui maintiennent une application écrite à l'époque où ce framework était maintenu, et dont la migration vers une autre UI prendrait bien trop de temps. Et c'est précisément dans ce genre de cas qu'on risque de rester bloqué sur la version 8 pendant un bon bout de temps.

2. de leur coté, de nombreux autres acteurs ont publié un plan de support qui dure encore plus longtemps qu'Oracle, que ce soit RedHat, Azul, Amazon, ... Et ces acteurs ont tout autant l'obligation de publier les sources du fait de la licence GPL

Là nous pouvons être d'accord, mais il ne faut pas oublier qu'il reste un point où Oracle reste maître: les spécifications, et les logiciels permettant la certification de l'Open JDK. Tous ces acteurs ne prendront jamais le risque de valider une modification qui ne passe plus les tests, qui bien évidemment ne sont pas en GPL. Alors certes ça ne concerne pas les patches de sécurité, mais ça limite quand même ce que la communauté peut faire de l'Open JDK.