Java licensing basics

Tento článek shrnuje praktické minimum k licencování Java runtime ve firmě – zejména rozdíly mezi Oracle JDK / Oracle Java SE a komunitními či vendor buildy OpenJDK. Cílem je zorientovat se, snížit auditní riziko a nastavit rozumný provozní standard.

Poznámka: Jde o informační shrnutí pro technické a manažerské rozhodování. Pro finální licenční závěry vždy pracujte s aktuálními licenčními podmínkami výrobce a smluvní dokumentací.

1) Co ve firmě reálně „licencujete“

V praxi se typicky řeší:

Jaký runtime běží v produkci (Oracle JDK vs OpenJDK build).
Kde všude je Java nainstalovaná (servery, VM, kontejnery, desktopy, CI build agenty, bastiony).
Kdo a jak Java používá (interní aplikace, zákaznické řešení, embedded distribuce).
Zda máte nárok na bezpečnostní aktualizace (a jak dlouho) bez placené podpory.

2) Oracle Java: dvě klíčové licence, které se pletou nejčastěji

OTN (Oracle Technology Network License)

Typicky historicky relevantní pro Oracle JDK 8/11 (a související varianty). OTN je často bezplatná jen pro omezené účely – typicky osobní použití, vývoj, test, prototypování, demonstrace apod. Pro „běžný firemní provoz“ to obvykle není to, co chcete mít jako základ.

Praktický dopad: Pokud máte ve firmě Oracle Java pod OTN a běží vám to jako součást standardních interních systémů, je nutné velmi pečlivě ověřit soulad použití.

NFTC (No-Fee Terms and Conditions)

Novější model pro Oracle JDK 17 a novější, který dovoluje bezplatné použití i komerčně a v produkci – nicméně je potřeba rozumět politice aktualizací (viz níže).

Praktický dopad: Oracle JDK 17+ může být „legálně zdarma“ pro produkci, ale zdarma nemusí znamenat „dlouhodobě zdarma pro update stream“ u konkrétní LTS větve.

3) Aktualizace a „bezplatné období“ u Oracle JDK (důležité pro bezpečnost)

Licenční oprávnění je jedna věc, dostupnost bezpečnostních aktualizací druhá.

Typický provozní problém:

Firma zůstane na LTS (např. 17),
chce pravidelné CPU/PSU security updaty,
a po určitém čase zjistí, že bez subscription už nedostává updates ve stejném režimu.

Doporučení pro praxi:

Pokud chcete dlouhodobě stabilní a předvídatelné aktualizace bez auditního stresu, zvažte OpenJDK distribuci s LTS update politikou (Temurin, Azul Zulu, Corretto, Microsoft Build of OpenJDK apod.) nebo placenou podporu.

4) Java SE Subscription / Universal Subscription: kdy a proč vzniká potřeba

Ve firmách se subscription nejčastěji objeví, když:

potřebujete dlouhodobé bezpečnostní aktualizace pro starší major verze,
používáte Oracle Java v režimu, který není kryt „free“ licencí,
chcete mít support a právní jistotu,
nebo řešíte auditní připravenost a potřebujete jasné licenční krytí.

U „universal“ modelu je zásadní pochopit metriky (např. employee-based). To je častý zdroj překvapení v rozpočtu.

5) OpenJDK v kostce: proč je to často jednodušší

OpenJDK není jeden konkrétní produkt – je to upstream projekt. Ve firmách se typicky nasazuje vendor build OpenJDK.

Obvyklé výhody:

předvídatelnější compliance model (v závislosti na vendorovi),
možnost LTS patchingu bez vazby na Oracle licenční režim,
snížení auditního rizika při standardizaci a governance.

Pozor:

vždy ověřte podmínky konkrétní distribuce (licence, support, LTS cadence).

6) Rychlá orientační tabulka (pro rozhodnutí „co prověřit“)

Situace	Typické riziko	Co udělat hned
Oracle JDK 8/11 v produkci	vysoké licenční riziko	zjistit přesnou distribuci + právní režim + plán migrace
Oracle JDK 17+ v produkci	nízké až střední (hlavně updates)	ověřit update policy a termíny, rozhodnout se pro vendor LTS
Směs různých JDK vendorů	governance chaos	standardizovat (1–2 schválené distribuce), interní repozitář
Java na CI/build agentech	skryté instalace / compliance mezera	inventarizace build infrastruktury, policy pro images/agents
Kontejnery s base image „někde z internetu“	supply-chain + licensing	SBOM, allowlist image, pinování digestů, interní registry

7) Praktický checklist pro firmu (doporučený postup)

Inventarizace
- servery / VM / kontejnery / desktopy / CI
- vendor + verze + umístění + účel (prod/dev/test/build)
Normalizace a deduplikace
- sjednotit názvy vendorů, cest, runtime variant
Klasifikace použití
- produkce vs neprodukce
- interní provoz vs distribuce zákazníkům
Vyhodnocení licenčních dopadů
- kde je Oracle Java a v jakém licenčním režimu
- update nároky a support požadavky
Remediace / optimalizace
- standardizace na OpenJDK (nebo subscription tam, kde dává smysl)
- governance: interní repozitář runtime balíčků, schvalování, hardening

8) Doporučení na závěr

Pokud chceš rychle snížit riziko:

Zaveď “approved JDK list” (např. 1–2 distribuce).
Zablokuj ad-hoc stahování Oracle JDK do produkčních prostředí.
Nastav CI pravidla (SBOM, allowlist images, kontrola vendor stringů).
Připrav management report: kde je Oracle Java, jaké je riziko, kolik to stojí, jaký je plán.