Sun: Az év végére teljesen nyílt forrású lehet a Java

Címkék

Rich Sands, a Sun fejlesztői marketingjéért felelős munkatársa pénteken megerősítette, hogy a Sun azt tervezi, hogy a 2008-as év végére nyílt forrásúvá teszi a Java utolsó zárt forrású részeit is. A lépéssel a Sun megkönnyítené a Java-t szállító Linux disztribútorok munkáját.

A Sun 2006 végén kezdte nyílt forrásúvá tenni a Java-t. A cég azonban akkoriban nem tudta 100%-ban megnyitni, mindegy 96%-át tudta nyílt forrásúvá tenni. A fennmaradt 4% megnyitásáról - amelyben titkosítási, grafikai könyvtárak, hang engine és SNMP-vel kapcsolatos kódok vannak - azonban tárgyalnia kell(ett), mert nem birtokol(j|t)a a nyitáshoz szükséges jogokat.

A részletek itt.

Hozzászólások

Nem jó ez a "nyílt forrású" kifejezés, mert -sajnos tapasztalat, innen a hupról- a legtöbb OSS-fan azzal azonosítja, hogy a Java eddig zárt forrású (azaz csak bináris terjesztésű) volt, pedig nem:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/java/jdk12/Attic/Makefile

Mi tehát akkor a "closed source", azaz zárt forrás ellentéte? Az open source nem, pedig az lenne logikus.

Zárt forrás: nincs forráskódod.
Nyílt forrás: van forráskódod.
Szabad szoftver: van forráskódod és csinálhatsz is vele valamit (szabadabbtól (pld. PD) a korlátosabbig (pld. GPL és tsai)).

Az "I accept" gomb megnyomása aláírásnak számít? Különbséget érzek például a nyílt forrású Microsoft Windows között (amelynek a forrását bizonyos körülmények között megkaphatod, és ott valóban alá kell írni) és a Java között, amelynek a forrását ennél jóval könnyebben megszerezheted.

Az a baj ezzel a felosztással, hogy a linkelt open source definíció nem csak annyit mond, hogy van forráskódod, hanem még 9 másik tényezőt is. Vagyis olyan, mint egy ogre: több rétegű :). Így az, hogy "nyílt = van kód", nem igaz, kell még ahhoz más is, pontosan az, amit nagyvonalúan a szabad szoftver alá soroltál.

A szabad szoftvert ugyanakkor nem kéne így összemosni a mindenféle "szabadabb" licencekkel, mert az FSF definiálta hogy mit hív szabadnak, az OSI meg hogy ő mit hív nyíltnak (ne menjünk bele az okokba, meg ádám-éváig vissza), jól van ez így, plusz a szabadságot eltérően értelmező csoportok TdR-től RMS-ig egy emberként kezdenének téged miatta flamelni, az meg kinek hiányzik :).

Igazából arra a helyzetre kéne kitalálni egy kifejezést, ami korábban a javanál is volt, hogy van ugyan forráskód, de nincs se belepofázás a fejlesztésbe, se forkolhatóság, se semmi komolyabb jogosítvány, ami miatt az OSI nyíltnak nyilváníthatná (vagy mint pl. az MS-féle shared source és hasonlók). Lehetne mondjuk "látható forrású"-nak nevezni :).

A "nyilt forras" vs "szabad szoftver" szerintem alapvetoen egy "minek nevezzuk a gyereket" tipusu kerdes. RMS es ESR (azaz az FSF es az OSI) alapvetoen egyetertenek abban, hogy melyik licenceket tartjak nyilt forrasunak / szabad szoftvernek (PD, BSD, (L)GPL, CC-xx, Apache, Mozilla, ...), csak mindketto a sajat szaja ize szerint hivja oket. ESR ezt le is irta, pl. a Homesteading the Noosphere-ben, hogy azert "open source"-nak nevezi, mert az OSI inkabb a szabad szoftverek uzleti hasznalatat propagalando jott letre ("rationale, rationale"), mig RMS free sw-jenek az ideologiai toltete inkabb maganszemelyeknek szolt. ("help your neighbour", "your freedom") Az "open source" egy szandekosan semlegesebb (es laposabb) kifejezes, ami persze tud elonyos lenni, akkor is ha a "free sw" kifejezobb. Nem mindegy, hogy az egyszeri usernek, vagy egy cegnek akarod elmagyarazni, miert jo neki az altalad propagalt sw.

Az, hogy ezek milyen szepen kibekulnek, jol latszik azon, hogy mindketto elnevezesei benne vannak a F(L)OSS roviditesben, amirol - ha majd meg csavarnak egy-kettot rajta - mar a jo isten se fogja tudni, minek is volt a roviditese. (No meg aztan jottek meg tobben is, akik megint egy kicsit mast mondtak - BSD-sek, DFSG, Lessig, etc. - mondjuk ezekbol a MIT licenc (es valtozatai) valojaban inkabb meg RMS kortarsai)

ESR, RMS es az antikommercialitas:
http://catb.org/~esr/writings/homesteading/homesteading/ar01s02.html

Tisztabbak ezek a dolgok, ha a zart-nyilt-szabad harmas helyett tobb mindent is megkulonboztetunk, pl:

open-closed
public-private
free-proprietary

juhú, mehet majd a
CFLAGS="-09 -march=s6000 -pipe=65536 -funroll-every-loop -mrice -mabi=rice -omg-optimized --disable-all-instructions -DREENABLE_FAST_EXECUTION" emerge sun-jdk :)

Megértem, sajnos a javának (sem) elsődleges platformja a FreeBSD. Pedig mennyivel könnyebb lenne az életem (meg a kollegáké is)...
Mivel próbálod egyébként? (natív, linuxos, 1.5, 1.6, stb)

Apropó, ha már Solaris. :)
Ki, hogy menedzsel nagy számú Solaris farmokat? (az "egyenként" nem érdekel)
OS/csomagfrissítés, tesztelés, telepítés, terjesztés, rollback, konfigurációkezelés stb....

nincs nagy számú farmom sajnos. Az egyes rendszerek annyira egyediek, különböző cégek nyúlkálnak hozzá, stb, hogy nincs is ilyen igény. Ennyi van:

- helyi patch repository
- patch-elés txt fileban lévő patch lista alapján (előre meghatározott, tesztelt)
- ahol ugyanazt csinálja több gép, ott szarakodás helyett mindig jumpstart + flash archívból újratelepítés
- ezeken egyébként pont SJWS van ami saját maga deploy-olja a konfigurációt a node-okra stb., nem nagyon számít ami alatta van, ha nagyon változik valami pl. új NFS mount akkor arra vannak scriptek, vagy reinstall.
- van egy rakás el****-tt kereskedelmi szoftver amihez jobb nem nyúlni. :)
- jellemzően ügyfeleknek dolgozunk ahol a rakás windows, linux PC közt van "A" Sun vas, amin valami nagyon fontos dolog fut, és nem hogy automatizálva, de sehogy nem szeretnék túlságosan bolygatni, mert "tavalyelőtt is a józsiék elrontották aztán milyen sokba került" (no comment)
- sun cluster + HA zone jó kombináció, amióta tud ilyet. igaz ezt is meg kell támogatni scriptekkel.
- linux alatt hogy csinálják ezt? a hardver menedzsment része nem érdekel, arra itt is vannak teljesen más megoldások.

A legnagyobb rendszerem 200 gépből állt de az FreeBSD volt és mind ugyanazt csinálta. 15:00 - 19:00 közt kész volt az egész, hardver telepítéssel együtt :) Csak a telepítő anyagot kellett előtte tesztelni, azt hiszem a sysinstall-ba is bele kellett nyúlni mert nem lehetett mindent automatikusan megcsinálni, amit szerettünk volna. Ehhez még volt néhány script az egyszerűbb dolgokhoz, ha túl nagy változás volt akkor itt is reinstall. :)

> "A" Sun vas, amin valami nagyon fontos dolog fut, és nem hogy automatizálva, de sehogy nem szeretnék túlságosan bolygatni, mert "tavalyelőtt is a józsiék elrontották aztán milyen sokba került"

Ez mindig nagy dilemma: supportosok 3 napi dija vs. 6 hét eü. szabi + gipsz Józsinak kézre szivlapáttal való rácsapásból kifolyólag. :))

--
Debian - The "What?!" starts not!
http://nyizsa.uni.cc

Pár dolgot érdemes tisztázni... :)

A Java, mint fogalom előírja a nyelv alapvető jellemzőit. A JVM, mint fogalom, előírja a virtuális gép jellemzőit. A J2SE, a J2ME és a J2EE előírja a szükséges osztályokat és azok funkcionális működését. A Sun nem zárta be a Java platformot soha, csak közzétette a specifikációt és - igaz pénzért - de adhat egy pecsétes papírt, hogy az adott implementáció kompatibilis.

A fentiekből adódóan az OpenJDK előtt is volt egy csomó Java implementáció, kezdve a nagy kék termékével, az IBM JDK-val, amely mondjuk nem nyilt forrású (az lesz valaha? :), folytatva az Apache Harmonyi projekttel, amely egy nyilt forrású JDK volt, aztán jól megszívták, amikor a Sun elindította az OpenJDK-t (azóta is hadban vannak egymással az Apache és a Sun, a JSR szavazásokon rendre a Sun ellen szavaznak). A Harmony ugye Apache licenc, ezért megjelentek a Harmony alapú JDK-k. Ezek többé-kevésbé kompatibilisek voltak a Sun JDK-val, de pénz vagy politikai elhatározás hiányában nem kaptak pecsétes papírt, ilyen a FreeBSD-s Java is.
--
http://www.javaforum.hu

LICENSE="dlj-1.1"
sun-jdk -rol a legutobbi nyitas ota eltunt a fetch restriction. (Nem kell honlapjarol kezzel letolteni a csomagot es elfogadni licenset)

LICENSE="sun-j2sl-6"
java-sdk-docs
Ezt meg mindig le kell tolteni kezzel, marhara tud idegesiteni.

LICENSE="GPL-2-with-linking-exception sun-prerelease-jdk7"
openjdk
java-experimental overlay-bol.