Oracle verplicht licentie voor commercieel Java in 2019?

[Daanoz]

(niet direct een programming vraag, maar gezien het hier gaat over Java toolchain, misschien de beste doelgroep?)

Vandaag bij het updaten naar de laatste JDK kreeg ik een mooie melding dat indien ik commercieel gebruik maak van de JDK tooling hier (mogelijk?) een licentie voor moet worden aangeschaft. Het linkje van de melding brengt je naar deze pagina: https://www.oracle.com/java/java-se-subscription.html.

Ik probeer er achter te komen wat nu precies de regels worden, mag het wel met beperkte functionaliteit (met name profiling/performance tools lijken onder commercieel te vallen)? Heeft dit alleen betrekking tot de JDK? Is het alleen van toepassing bij distributie? Als we een verouderde versie (8 of lager) gebruiken lijkt die vrijgesteld te zijn?

Een aantal andere reads:
- https://www.aspera.com/en...or-java-starting-in-2019/
- https://www.reddit.com/r/...mercial_licenses_in_2019/
- https://www.infoworld.com...ption-to-use-java-se.html

Doel van mijn topic? Java wordt natuurlijk bij veel bedrijven gebruikt, wat wordt de policy bij jullie op de werkvloer? Iedereen en alle servers een licentie? Blijven steken op een oude versie? Over op bijvoorbeeld OpenJDK?

Daanoz

[Lethalis]

*oude reactie verwijderd*

Dit gaat alleen over support op oude versies van Java?

Vanaf versie 11 kun je OpenJDK gebruiken, omdat deze hetzelfde is als de OracleJDK minus enterprise features.

Dus mijn insteek zou zijn om te upgraden naar OpenJDK 11 waar mogelijk.

[Voor 157% gewijzigd door Lethalis op 07-11-2018 23:17]

[Gerco]

Bij ons gaan we volledig over naar OpenJDK 8. Dat werkt prima voor onze doeleinden.

[Hydra]

Oracle is al een paar jaar (alsin; meer dan 8 ) iedereen richting OpenJDK aan het pushen. Java is al een tijdje volledig open source, met een aantal vendors die JDKs aanbieden. Sommige gratis (OpenJDK), sommige betaald (Oracle, IMB, etc.).

Java IS OpenJDK.

Lethalis schreef op woensdag 7 november 2018 @ 22:57:
Vanaf versie 11 kun je OpenJDK gebruiken, omdat deze hetzelfde is als de OracleJDK minus enterprise features.

Nee. Je kunt al sinds een hele lange tijd gewoon OpenJDK gebruiken. De services hier die nog op 8 zitten gebruiken ook de 8 OpenJDK. Dit hele proces is echt al heel lang geleden in gang gezet.

Gerco schreef op donderdag 8 november 2018 @ 00:44:
Bij ons gaan we volledig over naar OpenJDK 8. Dat werkt prima voor onze doeleinden.

Afgezien van dat 11 de nieuwe LTS is en 8 uit de support loopt. Begin volgend jaar.

[Lethalis]

Hydra schreef op donderdag 8 november 2018 @ 08:32:
Nee. Je kunt al sinds een hele lange tijd gewoon OpenJDK gebruiken. De services hier die nog op 8 zitten gebruiken ook de 8 OpenJDK. Dit hele proces is echt al heel lang geleden in gang gezet.

Okee

Ik baseerde me vooral op dit:

https://blogs.oracle.com/...ses-for-java-11-and-later

Starting with Java 11, Oracle will provide JDK releases under the open source GNU General Public License v2, with the Classpath Exception (GPLv2+CPE), and under a commercial license for those using the Oracle JDK as part of an Oracle product or service, or who do not wish to use open source software.

From Java 11 forward, therefore, Oracle JDK builds and OpenJDK builds will be essentially identical.

Wat mij het gevoel geeft / gaf dat deze dingen nog niet voor eerdere versies gelden.

[Hydra]

Oracle is goed in het vaag verwoorden van dingen Er zat in de Oracle JDK nog wat spul dat vrijwel niemand gebruikt wat ze nu ook naar OpenJDK overgezet hebben.

Je kunt voor Java 8 spul en later prima gewoon OpenJDK gebruiken. Alle projecten waar ik op gezeten heb de laatste 4 jaar zaten al op OpenJDK.

[Gerco]

Hydra schreef op donderdag 8 november 2018 @ 08:32:
Afgezien van dat 11 de nieuwe LTS is en 8 uit de support loopt. Begin volgend jaar.

Buiten dat, ja. We hebben letterlijk nog nooit Java support nodig gehad en geen van deze applicaties is internet-facing. Vendors van de applicaties (waarvan sommige intern) ondersteunen echter nog geen Java versies die nieuwer zijn dus we hebben weinig keuze.

Zodra de vendors support hebben voor Java 9, 10, 11 of hoger zullen we daar naartoe overstappen, maar voorlopig werkt OpenJDK 8 prima.

[Hydra]

Gerco schreef op donderdag 8 november 2018 @ 16:10:
Zodra de vendors support hebben voor Java 9, 10, 11 of hoger zullen we daar naartoe overstappen, maar voorlopig werkt OpenJDK 8 prima.

Ik kan je wel echt vanuit mijn ervaring as Java dev aanraden om die migratie (mits vendors e.d. het supporten) wel te gaan doen en het ook bij te gaan houden. Hoe groter het 'gat' wordt hoe groter de pijn gaat worden. Je moet je realiseren dat er best een paar dingen veranderd zijn die 9+ niet backward compatible maken. Dit betekent ook dat je problemen gaat krijgen met versies van libraries e.d. die niet werken. 11 is de nieuwe LTS versie en gaat voorlopig wel gesupport worden, ook door vendors.

[ACM]

Hydra schreef op donderdag 8 november 2018 @ 08:32:
Nee. Je kunt al sinds een hele lange tijd gewoon OpenJDK gebruiken. De services hier die nog op 8 zitten gebruiken ook de 8 OpenJDK. Dit hele proces is echt al heel lang geleden in gang gezet.


[...]


Afgezien van dat 11 de nieuwe LTS is en 8 uit de support loopt. Begin volgend jaar.

Wat wellicht wel een belangrijk punt is, is dat dat LTS-aspect bij OpenJDK wat Oracle betreft niet echt bestaat.
Althans, als ik het goed heb begrepen. Dus het impliceert dat je moet hopen dat anderen dat overnemen (zoals RedHat), of je moet steeds naar een nieuwe 'major' versie upgraden.

Dat major tussen aanhalingstekens omdat ze ook gedurende het bestaan van Java 8 vergelijkbare aanpassingen hebben gedaan wat daar dan als 'minor' versie gold (maar dan bijvoorbeeld de subversie wel naar het volgende 20-tal).

Ik blijf overigens zelf op mijn workstation voorlopig nog wel de Oracle-versie gebruiken, die op jdk.java.net heeft geen installer en is daarmee toch net wat meer gedoe om te gebruiken

Hydra schreef op donderdag 8 november 2018 @ 16:47:
Ik kan je wel echt vanuit mijn ervaring as Java dev aanraden om die migratie (mits vendors e.d. het supporten) wel te gaan doen en het ook bij te gaan houden. Hoe groter het 'gat' wordt hoe groter de pijn gaat worden. Je moet je realiseren dat er best een paar dingen veranderd zijn die 9+ niet backward compatible maken.

Ze zijn er vast, maar onze applicaties zijn vooralsnog zonder moeilijkheden vanaf versie 1.5 oid t/m de huidige 11 gegroeid. Nou hebben wel steeds bij praktische gelegenheden de JDK geupgrade, maar we zijn van 8 naar 10 gegaan door domweg alleen de JDK te veranderen

Dit betekent ook dat je problemen gaat krijgen met versies van libraries e.d. die niet werken. 11 is de nieuwe LTS versie en gaat voorlopig wel gesupport worden, ook door vendors.

Dat LTS is dus wel met een zekere korrel zout als 'iedereen' naar OpenJDK gaat.

[Voor 30% gewijzigd door ACM op 09-11-2018 08:52]

[Hydra]

ACM schreef op vrijdag 9 november 2018 @ 08:45:
Dat LTS is dus wel met een zekere korrel zout als 'iedereen' naar OpenJDK gaat.

Oracle is zelf de grootste contributer he. OpenJDK is Java. OracleJDK is daarvan afgeleid. Het is een community effort (https://adoptopenjdk.net/) maar de 'community' is Oracle, IBM, Microsoft, etc.

[ACM]

Hydra schreef op vrijdag 9 november 2018 @ 12:36:
[...]


Oracle is zelf de grootste contributer he. OpenJDK is Java. OracleJDK is daarvan afgeleid. Het is een community effort (https://adoptopenjdk.net/) maar de 'community' is Oracle, IBM, Microsoft, etc.

Natuurlijk is Oracle een grote partij achter OpenJDK.

Maar Oracle heeft vziw vrij duidelijk aangegeven dat ze bij OpenJDK alleen de nieuwste versie ondersteunen/ontwikkelen. Dus als zij zeggen 'Java 11 is LTS', dan bedoelen ze daar niet mee 'OpenJDK 11 is LTS'. Maar dan hebben ze het alleen over hun eigen distributie.

't Kan wel zijn dat anderen, zoals Redhat, aangeven dat zij ervoor zorgen dat OpenJDK alsnog wel ook LTS is. Maar dat is wat ik met die korrel zout bedoelde mbt LTS.

[Killemov]

Het staat me bij dat de verschillen nagenoeg verwaarloosbaar zijn ... totdat je van de crypto-engine gebruik wil maken en ontdekt dat alleen de lichtere/zwakkere varianten beschikbaar zijn. (Iets met internationale verdragen?) Daar zijn ook oplossingen voor, zie bouncycastle, maar het zijn dingen die je niet verwacht als je de standaard documentatie volgt.