Vlákno názorů k článku Java jako open source: sen se stává realitou od Ladislav Thon - No a když teď teda ta džáva bude...

  • Článek je starý, nové názory již nelze přidávat.
  • 10. 11. 2006 8:52

    Ladislav Thon (neregistrovaný)
    No a když teď teda ta džáva bude dží-pí-el, jak to bude s odvozenými díly? Pokud bude pod GPL i standardní knihovna, zejména tedy věci z java.lang (resp. z jeho tranzitivního uzávěru), pak každý software napsaný v Javě bude odvozeným dílem už kvůli použití třeba java.lang.String?
  • 10. 11. 2006 10:05

    Jirka (neregistrovaný)
    Sun ji evidentne vyda pod dvoji licenci. Ale me by opravdu zajimalo, jak do budoucna bude kombinovat otevrene a zavrene kody tretich stran.
  • 10. 11. 2006 12:12

    Pavel Tišnovský
    Zlatý podporovatel
    Ne, proc by byl? Java ma trosicku vyhodu v tom, ze se v ni neprovadi staticke linkovani. Tj. vy sice budete vytvaret objekty typu String (z java.lang.String), nebo volat nejake staticke metody z tohoto baliku, ale to neznamena, ze do sve aplikace java.lang.String zahrnujete.

    Proste ve vyslednem .class (pripadne zabalenem do .jar, .ear, .war atd.) je pouze odkaz na to, ze _runtime_, tj. JRE ma dynamicky prilinkovat java.lang.String, ale jeho implementace uz muze byt uplne jakakoli - treba pod LGPL nebo komercni licenci (jak je tomu dnes). Nebo taky java.lang.String neexistuje a JRE vyhodi vyjimku. Ono java.lang.String existovat bude, ale treba nemusi existovat nektere "enterprise" baliky nebo veci z J2ME apod.

    Konkretni prilinkovani v case behu aplikace je to veci konkretni JRE na konkretnim stroji a vy jako vyvojar toto neresite a vlastne ani nemuzete.
  • 12. 11. 2006 17:17

    Zdenek Henek
    Ahoj,
    to ano, ale ve chvíli, kdy začneš dědit od nějaké třídy, která bude pod GPL licencí, tak musíš celý program uvolnit pod GPL licencí.
    Toto se třeba děje, pokud využíváš Adaptéry z AWT knihovny, nebo pokud vytvoříš nějakou speciální Map třídu a založíš ji na AbstractMap ...
  • 12. 11. 2006 19:16

    Pavel Píša (neregistrovaný)
    Podle mého chápání věci mi z Vašeho výkladu vychází, že se jedná o dynamické linkování funkcí (ať knihovny nebo interpretru), což není podle GPL přípustné. Java by musela být, aby to šlo, pod LGPL. Existuje ale i druhý pohled, že se jedná o běhové prostředí, které má přesně definované API, které je považované za hranici působnosti licence. Stejně jako je v Linuxu systémové volání (INT 80, System Entry instrukce, ...). GPL je možné i rozvolnit upřesněním, že využití runtime se nepovažuje za linkování, viz například RTEMS. Takže bude nutné počkat na oficiální verzi textu a výklad SUNu.
  • 13. 11. 2006 9:25

    Pavel Tišnovský
    Zlatý podporovatel
    Ano, myslel jsem to právě s ohledem na API. Vždyť já můžu (teoreticky) vyvinout SW v Javě bez toho, abych měl k dispozici tu třídu, například String. Linkování proběhne až při běhu na straně klienta a v tomto případě bude jedno, zda půjde o java.lang.String vytvořenou pod GPL, LGPL či nějakou komerční licencí (jak to vlastně děláme dneska se Sunovskou Javou).

    Samozřejmě otázkou je, jakým způsobem bude Sun vydávat svoji verzi Javy. Pokud k ní dodá i dokumentaci, není problém knihovnu se stejnou funkcí implementovat.
  • 13. 11. 2006 21:43

    Zdenek Henek
    Podle interview na Javaposse (dil 93) se nemame prej niceho bat. GPL se bude vztahovat jen na vlastni knihovny a rozsirovani knihoven nebude podlehat GPL.
  • 13. 11. 2006 22:00

    Pavel Píša (neregistrovaný)
    Pokud je něco pod GPL, tak ani likování za běhu není ve směru zavřená alikace -> otevřená knihovna přípustné. Proto nelze bez komerční licence psát uzavřené aplikace nad Qt. Čisté GPL pouze připouští interakci s nesvobodným kódem, když se jedná o běhové prostředí cílového systému. Na hraně přípustnosti zůstává závislost na zcela od aplikace nezávislé avšak uzavřené knihovně. Jsem ale přesvědčený, že Váš příklad s využitím třídy String je v rozporu s pravidly GPL. Naopak s LGPL je zcela v pořádku. Je možné, že SUN vydá Javu včetně knihoven pod GPL, tím poláme ostny OS kritiků a pro komerční použití bude vývojové prostředí dále šířit pod původní licencí. Pro začlenění změn od kontributorů do primárního stromu pak bude žádat souhlas s dvojí licencí. Také je možné, že bude nějak ošetrřena hranice působnosti licence. Píši to sem jen pro upřesnění, zauvažování nad věcí a můj výklad je také čistě amatérský. Nemám k této věci moc vyhraněný vztah, ale spíš mě těší, že bude Java průhlednější a půjde kód lépe studovat a třeba i vylepšovat (i když pro mě osobně je Java zatím mimo rozsah mého radaru). Loučím se spráním poslušně promenujích se bytů na drátech.
  • 14. 11. 2006 9:14

    Pavel Tišnovský
    Zlatý podporovatel
    Ono se ukazuje, že je škoda, že Java není nějakým rozumným způsobem standardizována. Pokud by byla, tak by můj příklad se Stringem byl samozřejmě správný. Já bych totiž napsal program, ve kterém bych použil String, tuto třídu však nemusím na svém počítači ani mít, stačí mi pouze znalost rozhraní (v případě rozumné standardizace Javy by to rozhraní bylo přesně popsáno). Jak se bude program spouštět, tj. zda bude JRE a příslušné knihovny pod GPL či ne, mě nemusí zajímat.

    Mimochodem, pokud existují komerční distribuce Javy, nejsou přechodem Sunu ke GPL nijak dotčeni, takže moje aplikace může klidně využívat tyto non OS knihovny.

    Máte pravdu v tom, že Java (implementace překladače, JRE a JVM) bude pod GPL průhlednější a i kluci od Sunů budou pod vyšším tlakem, jak psát rozumně spravovatelný kód. Osobně si myslím, že hlavně hot-spot může být pro studium velmi zajímavé.