'Java-source krijgt GPL-licentie'

Dat Sun Microsystems de broncode van Java openbaar ging maken was al enige tijd bekend. Over de te gebruiken licentie bestond echter nog geen duidelijkheid: andere Sun-software, zoals het besturingssysteem Solaris, is gepubliceerd onder Suns eigen CDDL, maar Jonathan Schwartz had al in mei duidelijk gemaakt dat voor Java ook de GPL een optie zou zijn. Volgens CRN zal het bedrijf 'zeer binnenkort' bekend maken dat het voor de standaard- en mobile versie van Java zowel CDDL- als GPL-voorwaarden zal toestaan. Ook de Enterprise-versie en GlassFish, die nu nog uitsluitend met een CDDL-licentie te krijgen zijn, zouden te zijner tijd onder GPL gebruikt mogen worden.

Het gebruik van de GPL houdt in dat ontwikkelaars die varianten van Suns Java-code publiceren, de broncode van hun werk openbaar moeten maken. Daarmee zou commerciële forks van het platform de wind uit de zeilen worden genomen. Zo heeft IBM een eigen versie van de Java Virtual Machine, waarvan de source openbaar zou moeten worden gemaakt als de Java-broncode alleen op basis van de GPL gebruikt zou mogen worden. Met de keuze voor het dubbele licentiemodel zorgt Sun dat het commerciële licenties op de code kan blijven verkopen, terwijl het tegelijk de opensourcegemeenschap te vriend kan houden. Uit die hoek was eerder veel kritiek op het 'pseudo-opensourcebeleid' van Sun gekomen: een onderzoekje op Suns Java.net-site liet zien dat een ruime meerderheid van de ontwikkelaars de voorkeur gaf aan (L)GPL- of Apache-licenties boven Suns eigen CDDL. Het bedrijf zal het nieuwe licentiemodel vermoedelijk volgende week bekendmaken.

Reacties (24)

[Shaggy_NL]

Dus nu kan Microsoft weer verder gaan met een eigen Java? Zoals MS Virtual Machine...

[Gerco]

Dat zouden ze inderdaad kunnen doen ja, more power to them!

Ze zouden daar echter ook de sourcecode van openbaar moeten maken, dus enige on ethische praktijken zouden meteen aan het licht komen en door anderen opgelost.

Microsoft heeft geen voordeel te behalen bij het releasen van Yet Another Java, anders hadden ze lang geleden al een eigen VM kunnen blijven maken. Ze zijn daar mee opgehouden om .NET te promoten (en om Sun te pesten).

[Verwijderd]

Volgens mij zijn ze ermee gestopt omdat ze de rechtzaak tegen SUN hadden verloren...

[Gerco]

Ze zijn ermee gestopt omdat ze van de rechter geen brakke/eigen Java mochten meeleveren. MS zei toen: "Als we niet onze eigen Java mogen meeleveren, dan leveren we helemaal geen Java meer."

Natuurlijk hun goed recht, maar in beide gevallen heeft MS niets (meer) te winnen bij het meeleveren van Java. Elk Java programma is er weer 1 wat niet in .NET is geschreven, dus het laatste wat MS zal doen is Java promoten.

[Verwijderd]

Java zit ook in .Net, en dat noemen we J#.

[Mike2k]

Dit vind ik nou een goeie oplossing.

Wil je je broncode openbaar maken mag je het gratis gebruiken, wil je dit niet dan moet je ervoor betalen...

Veel makkelijker dan dat andere gezeik over draadloos een emailtje versturen...

[Soze]

Enige nadeel, althans volgens sommigen, is nu dat er dus wel allerlei verschillende varianten van Java worden toegestaan omdat je dus eigen forks kan beginnen.

[Gerco]

Inderdaad, maar dat mag je dan geen Sun Java noemen, want dat is het niet. Als we dus allemaal Sun Java gaan gebruiken, heb je geen last van brakke forks.

Dit zorgt er gelukkig wel voor dat alle Linux distributies (zelfs debian) Java kunnen gaan meeleveren en dat de Java Trap niet meer bestaat. Tenminste niet meer met Java als hoofdpersoon.

Ik voorspel een rooskleurige toekomst voor Java in de Open Source wereld. Ik ben vast niet de enige die naar een Free (as in speech) high level taal met de features van Java zoekt.

[killercow]

Hopelijk wordt de invloed van .net via mono weer wat ingeperkt door deze move.

Java zal nu gewoon native meegeleverd kunnen zijn, zonder gezeur, en 100% compatible.

Daarnaast vertrouw ik dat hele mono gedoe van geen kant.

[Gerco]

Daarnaast vertrouw ik dat hele mono gedoe van geen kant.

Er is niets mis met mono op zich. Helaas leidt Mono compatibiliteit tot .NET en .NET leidt weer tot Windows, wat weer tot vendor lock-in leidt.

Ik heb niets tegen Mono, het is een prima manier om cross-platform apps te maken. Je moet alleen heel erg uitkijken dat je niet per ongeluk iets platform specifieks gebruikt als je met Microsoft.NET werkt en later op Mono wil draaien. Winforms is zo'n voorbeeld en er zijn er nog een stuk of 100 te vinden in de MS.NET wereld.

Als je ontwikkelt op Mono gaat het beter, dan weet je zeker dat je app op MS.NET en op Mono werkt.

[Gerco]

Ik vind het idee van mono wel erg mooi, dat je meerdere talen kunt compileren naar dezelfde VM-taal.

Er zijn tientallen, zo niet honderden talen die op de Java VM draaien. In ieder geval veel meer dan er momenteel voor de CLR (.NET) zijn. Zie ook Languages for the Java VM.

Voor mijn laatste project heb ik voor mono gekozen, omdat ik een GTK GUI wilde hebben, en geen swing/awt.

Dat heb je dan niet zo handig gedaan. Je had net zo goed voor Java/SWT kunnen gaan, wat native op Windows en Linux/GTK draait. GTK onder Windows vind ik niets, het is het allemaal "net niet". SWT onder Windows is niet van native te onderscheiden, want het is namelijk native.

Ik denk dat ik in de toekomst voor java zal kiezen, omdat ik meer Qt wil programmeren.

Ook niet zo handig, aangezien de eerste bruikbare Qt bindings voor Java net pas zijn ontwikkeld. Java en Qt zijn tot zeer recentelijk geen goede vriendjes geweest.

[smokalot]

Ik vind het idee van mono wel erg mooi, dat je meerdere talen kunt compileren naar dezelfde VM-taal. de cultuur bij .NET en mono is dat cross-platform minder belangrijk is, en dat vind ik jammer.

De kritiek op J2EE van Miquel D'Icaza is dat het erg ingewikkeld is, en ergens heeft ie daar wel gelijk in. In java moet je iets vaker zelf opnieuw het wiel uitvinden, vaker dan in mono.

Voor mijn laatste project heb ik voor mono gekozen, omdat ik een GTK GUI wilde hebben, en geen swing/awt. Ik denk dat ik in de toekomst voor java zal kiezen, omdat ik meer Qt wil programmeren.

[MBV]

@smokealot: leuke aan Qt is dat je, als je C++ gebruikt, al direct (grotendeels) cross-platform bent: even opnieuw compileren en je bent klaar . Dingen als com-poorten zitten er niet in, maar dat zit in Java vziw ook niet voor linux.

[onox]

@smokalot
Er bestaat zoiets als http://java-gnome.sourceforge.net/ waarmee je gtk, glib, glade, gconf en/of gnome in java kunt gebruiken.

[Verwijderd]

de cultuur bij .NET en mono is dat cross-platform minder belangrijk is, en dat vind ik jammer.

Ja, cross-hardware wel (x86, x64, Itanium...), als het maar Windows draait
Vind ik op zich ook wel interessant, omdat we momenteel enorm met 'vendor lock-in' zitten qua processors. Je kunt de meeste software op alle processors draaien, als het maar x86 is (geldt trouwens voor linux bijna net zo hard als voor Windows, veel applicaties zijn al nauwelijks voor x64 aan de praat te krijgen, laat staan voor een compleet andere CPU).

Nadeel is dus dat de CPU-ontwikkeling een beetje belemmerd wordt door het feit dat het x86-compatible moet zijn. Je kunt wel een geniaal nieuwe CPU bedenken, maar als ie niet efficient x86-code kan draaien, is hij gedoemd te mislukken.
Wat dat betreft zou .NET voor CPUs kunnen betekenen wat HLSL voor GPUs betekent: je krijgt een redelijk flexibele bytecode aangeleverd... die compileer je met je eigen driver/virtual machine naar je eigen formaat, en verder ben je er helemaal vrij in hoe je dit implementeert.

Persoonlijk vind ik dit een interessantere ontwikkeling dan cross-platform software. De hardware bepaalt namelijk voor het grootste deel hoe goed een applicatie presteert. Tussen linux en Windows (en andere OSen) zitten doorgaans maar marginale verschillen qua prestatie... en ook qua userinterface scheelt het weinig... Of ik bv Firefox nou op Windows of linux (met bv KDE) draai, ik merk het verschil nauwelijks.
Politieke zaken als 'free software' en dergelijke interesseren me eigenlijk niet zo. Als het maar goed werkt, en niet te duur is.

[xx77qq]

Je kunt de meeste software op alle processors draaien, als het maar x86 is (geldt trouwens voor linux bijna net zo hard als voor Windows, veel applicaties zijn al nauwelijks voor x64 aan de praat te krijgen, laat staan voor een compleet andere CPU)

Welke applicaties werken er dan niet goed in linux op x64? Ik kom alleen maar op Flash voor in de browser.

edit: typo

[Verwijderd]

Ik zou zo zeggen: tijd voor een feestje. Dit is een erg positieve stap van Sun. Dit zal er zeker toe leiden dat er in OS land meer de standaard Sun Java meegeleverd zal worden ipv de IBM Java. Dit houd tevens in dat in vergelijking met .net het een taal is die ondersteuning vind op alle platformen en onder een GPL licentie (die ik toch beschouw de echte OSS-licentie) draait. Iets wat met een .net waarschijnlijk nooit zal gebeuren (het draait wel op verschillende platformen, maar dan zijn het wel verschillende projecten).

[delenn]

De meest open licence is nog altijd de BSD/MIT licence...

GPL heeft een fiks aantal beperkingen in zich om te voorkomen dat de code in non-free applicaties word gebruikt. (onder anderen)

[PHiXioN]

De GPL is niet de echte OSS licentie, de auteur ervan is helemaal geen OSS voorstander.


Verder hoop ik dat de GPL geen effect gaat hebben op de in java geschreven programmatuur? Als dit het geval is ben ik meer een voorstander van de LGPL.

[iKiddo]

De GPL is niet de echte OSS licentie, de auteur ervan is helemaal geen OSS voorstander.

Wat is dan 'de echte OSS licentie'? Als er een licentie aan te wijzen is als 'de OSS licentie' dan is het wel GPLv2!
En de auteur van de GPL is geen OSS voorstander?

Laat me niet lachen.

Hahhaa!
...
Te laat.

(Ga hier maar even lezen over Richard Stallman. Of hier over de GPL.)

Verder hoop ik dat de GPL geen effect gaat hebben op de in java geschreven programmatuur? Als dit het geval is ben ik meer een voorstander van de LGPL.

Hmm. Jammer dat ze geen cursusjes auteursrecht geven bij het LOI...


(Dit heeft niks te maken met schrijven in de taal Java, maar schrijven aan de taal Java. Met andere woorden: als jij niet werkt aan de Java VM zelf, heeft dit geen gevolgen voor jou.)

[Verwijderd]

En de auteur van de GPL is geen OSS voorstander?

Richard Stallman is voorstander van Free Software, niet van OpenSource Software.

Subtiel verschil, maar het is er wel

[merethan]

Zo heeft IBM een eigen versie van de Java Virtual Machine, waarvan de source openbaar zou moeten worden gemaakt als de Java-broncode alleen op basis van de GPL gebruikt zou mogen worden.

Ze hebben em onder de ouwe licentie gekregen.

Dus dit is alleen waar als ze code van SUN in hun Java willen gaan gebruiken die al onder de GPL valt. En momenteel valt er nog niets onder de GPL.

En als ze dus de hele zooi onder GPL gaan uitgeven, dan pas kan IBM geen nieuwe code meer van ze overnemen zonder dat die van hun ook GPL wordt.

[Little Penguin]

En als ze dus de hele zooi onder GPL gaan uitgeven, dan pas kan IBM geen nieuwe code meer van ze overnemen zonder dat die van hun ook GPL wordt.

Zo lang de copyright van de code nog bij Sun bericht kan ze (Sun dus) deze code onder iedere gewenste licentie uitbrengen. Dus zowel onder de GPL als ook proprietairy aan IBM licencieren.

(Veel mensen vergeten wel eens dat de GPL de ontvanger extra rechten greeft, maar daarbij de originele verzender [en dus copyright houder] alle rechten laat behouden....)

[Little Penguin]

Dat Sun voor Java zou kiezen voor de GPL is helemaal niet gek overigens, er is namelijk geen enkele concurrent die nu beter wordt van het werk dat Sun reeds verricht heeft en ze laten weer een goede indruk achter bij de OSS comunity.

Dezelfde redenen gelden voor de keuze van de OpenSolaris licentie, ook nu is er (bijna?) geen enkele concurrent die deze code kan gebruiken. Linux is namelijk GPL en die is dus niet compatible en Windows is closed source en die is ook niet compatible met de CDDL.

Overigens is het wel goed dat men een zo open mogelijke licentie gekozen heeft (naja zou hebben) voor de Java SE JVM - op die manier is de kans groot dat het een standaard onderdeel wordt van de diverse Linux distro's....