Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 36 reacties
Bron: DesktopLinux

Zoals eerder geruchten al suggereerden, heeft Sun vandaag officieel bekendgemaakt dat Java zal worden vrijgegeven onder de gpl. Hiermee geeft Sun Microssystems gehoor aan de roep vanuit de opensourcegemeenschap om de broncode van Java volledig vrij te geven.

Java mannetjeNaast de standaard editie van Java wordt ook de Micro Edition, bedoeld voor de ontwikkeling van mobiele applicaties, van het ontwikkelplatform vrijgegeven onder de tweede versie van de gpl. Het eerder al onder Sun's eigen Common Development and Distribution License vrijgegeven Java Platform Enterprise Edition (JEE) wordt ook onder de General Public License uitgebracht, die meer garanties biedt voor de beschikbaarheid van de broncode. De eerste stukken broncode voor J2SE en J2ME zijn reeds beschikbaar gemaakt door Sun via de site van Project GlassFish. Volgens Sun is de vrijgave van het Java-platform een van de grootste bijdragen vanuit het bedrijfsleven aan de verzameling broncode die is beschikbaar is onder de gpl.

Met het open source maken van Java lijkt Sun een nieuwe poging te doen om zijn imago als 'opensource-onderneming' te versterken. Eerder gaf Sun de broncode van het besturingssysteem Solaris al vrij, maar dit gebeurde nog onder de CDDL-licentie die de nodige beperkingen met zich meebrengt en het in praktijk onmogelijk maakt om delen van dit besturingssysteem te gebruiken in bijvoorbeeld Linux. Het was al langer bekend dat Sun de broncode van Java vrij zou gaan geven, maar de verwachting was dat dit eveneens onder een tamelijk restrictieve licentie zou gebeuren, zoals de CDDL. Volgens kopstukken van de opensourcegemeenschap, zoals Richard Stallman en Eric S. Raymond, is de gpl een van de weinige echte opensourcelicenties. De keuze voor de gpl maakt het bijvoorbeeld mogelijk om Java nu standaard in Linux-distributies te integreren, wat zeer waarschijnlijk op korte termijn dan ook zal gebeuren. Daarnaast verplicht de gpl dat de broncode van programma's die gebruikmaken van broncode die onder de gpl is vrijgegeven, eveneens publiekelijk beschikbaar moet zijn.

Moderatie-faq Wijzig weergave

Reacties (36)

De code is ook beschikbaar onder de commerciele CDDL licentie (gebaseerd op de Mozilla Public License). Meer informatie over de CDDL.

Wat ik voornamelijk mis, is wanneer de (merk) naam 'Java' wel of niet mag worden gebruikt.
Ik neem aan dat de voorwaarden die daar nu voor staan niet direct zullen wijzigen. Dus een fork van de Sun Java VM mag zich alleen Java VM noemen als het nog aan de bestaande voorwaarden voldoet.

Zie ook http://www.java.com/en/about/brand/

En hier: http://www.sun.com/software/opensource/java/faq.jsp#g14
Tja twee verschillende zaken he... Trademark (de naam Java) en Copyright (de Java implementatie van Sun).
Wanneer je aan alles tests van de TCK voldoet mag je het product Java noemen, dit blijft verder gelijk aan de huidige situatie.
Daarnaast verplicht de GPL dat de broncode van programma's die gebruikmaken van broncode die onder de GPL is vrijgegeven, eveneens publiekelijk beschikbaar moet zijn.
Hmmm ik had liever gezien dat het onder de LGPL of de Apache License was uitgebracht. Mijn ervaring is namelijk dat GPL veel bedrijven ervan weerhoud het project te gebruiken, omdat dan hun investering direct open source moet zijn. LGPL is wat dat betreft beter; bedrijven kunnen verbeteringen teruggeven aan de community, en toch zelf hun eigen stukje closed source er bovenop bouwen waar geld mee te verdienen is.

In het artikel is weer niet direct duidelijk dat het om de VM gaat. Ik mag aannemen dat de standaard development kit van Java niet onder GPL uitgebracht gaan worden, _dat_ zou pas impact hebben.... :Y)

Dan zou namelijk elk java programma open source moeten worden... uh oh...
Dan zou namelijk elk java programma open source moeten worden... uh oh...
Het is toch ook niet zo dat iedere website de bronccode (in het geval van serverside apps) hoeft te publiceren wanneer het mogelijk is dat deze gebruik wordt in een browser die mogelijk onder een GPL license zou kunnen vallen?
Nee dat is zo. Maar stel je voor dat de class java.lang.String onder de GPL zou vallen. Dat zou betekenen dat alle source code die gebruik maakt van java.lang.String, ook onder de GPL moet vallen.

Dit is wat anders dan een Virtual Machine onder GPL. Een VM onder GPL kan heel goed source code met een andere licentie runnen, zonder dat er licentieproblemen ontstaan.

Het gaat hier om het gebruik van licensed source code, niet het gebruik van een executable.
Het is dan ook niet de GPL waaronder Java vrijgegeven wordt, maar de GPL + Classpath exceptie!

Een _heel_ belangrijk verschil, wat zeker in het artikel moet staan! En voor de volledigheid: het gaat om de VM, compiler, en bijbehorende libraries (met uitzondering van een aantal 3rd party proprietary ones).
Dan zou namelijk elk java programma open source moeten worden... uh oh...
Als je dit serieus meent heb je totaal geen idee wat GPL inhoudt.

Java wordt onder GPL vrijgegeven. Dit wil zeggen dat als jij wijzigingen aan de java code maakt jij deze wijzigingen vrij moet geven onder GPL licentie. Als jij een java-applicatie maakt hoeft deze niet onder GPL vrijgegeven te worden, je mag zelf de licentie bepalen.

Dit is iets wat veel mensen op de een of andere manier nog steeds niet snappen van GPL |:(
@KoeNijn: Erm, nou, dat is in dit geval alleen maar zo omdat Java vrijgegeven wordt onder de "GPL + Classpath exceptie" licentie.

Was dit niet zo, dan was het _wel degelijk_ zo dat elke applicatie die tegen het ge-GPL-de Java (beter: class libraries) aanlinkt OOK GPL moet worden!

Voor wie niet weet wat de classpath exceptie is: http://www.gnu.org/software/classpath/license.html

Vergelijkbare excepties bestaan er natuurlijk ook voor bijvoorbeeld libstdc++.
@MBV: OMG, snapt nou niemand de GPL? Ik heb het niet over "iets maken of runnen met behulp van tool X", maar over LINKEN tegen library X, in dit geval classpath. Ffs, lees eerst de GPL eens. Een waarom denk je uberhaupt dat Sun de classpath exceptie toegevoegd heeft?</abiword developer>
Jij praat poep. Als ik met GCC een commercieel programma wil maken, kan dat gewoon. Ik heb dan namelijk gebruik gemaakt van een GPL programma om iets te doen, wat ik ermee doe moet ik zelf weten. Zelfde geldt voor Gedit, Eclipse enzo.

Wat GPL doet: Als jij iets aanpast in, of toevoegt aan, een stuk GPL code, dan moet dat weer vrijgegeven worden aan jouw klanten, zodra die erom vragen.

En wat jij nu voorstelt is helemaal idioot: als ik met een commercieel gekochte JDK mijn java-code compileer naar .class (bytecode), dan zou ik dat moeten vrijgeven onder GPL omdat jij hebt gekozen om die bytecode met een GPL programma uit te voeren 8)7. De JVM leest een stuk code in, en voert dat uit. De input en output valt niet onder GPL, alleen de code zelf.

Op die manier krijg je wel paniekerige reacties van commerciele bedrijven ja :z

Nog mooier: ik kan een site maken voor het gpl-pakket PHP, zou jij dan de code kunnen opvragen als je daar zin in hebt? Dacht het niet.
Hmmm ik had liever gezien dat het onder de LGPL of de Apache License was uitgebracht.
Hoezo? Jij wil wel de Java code gebruiken maar wil niet dat anderen jouw code ook weer kunnen gebruiken?
Mij persoonlijk maakt het niet zoveel uit. Maar er zijn heel veel bedrijven die closed source applicaties leveren die gebouwd zijn met java. Niet elk bedrijf werkt met de open source aanpak.

Stel je voor dat java.lang.String onder de GPL zou vallen, dan betekent dit volgens mij dat praktisch elk met java gebouwd programma open source zou moeten wezen.

Dit zou tot gevolg hebben dat bedrijven die een closed source applicatie willen ontwikkelen (en geloof me, dit zijn er heel veel), geen java meer zullen gebruiken. Dit zou dus enorm in het nadeel van java gaan werken.
Volgens mij is het zo dat wanneer jij bv java.lang.String gebruikt (en deze is GPL) dat je dat gewoon mag doen in je colsed source toepassing mits je java.lang.String niet aanpast.

Kan me natuurlijk vergissen, lijkt me namelijk sterk dat je alle software die gemaakt wordt mbv GPL tools ook GPL moet zijn. Anders is het natuurlijk als je een GPL tool pakt en deze verbeterd (aanpast) en hem vervolgens uitbrengt onder een andere licentie.
Uh-uh, iemand heeft volgens mij niet begrepen wat er staat. Alles wat meegeleverd met Sun Java moet opensource zijn en natuurlijk is java.lang.String opensource, doh, dat is onderdeel van Java en dus opensource tegenwoordig.
Echter, pakketen die op Java worden gebouwd hoeven helemaal niet onder de GPL te worden vrijgegeven, alleen programma's die ermee gebundelt worden.
euh volgens mij gaat 't zowiso de verkeerde kant op,

Want ' java zelf' is opensource, dat betekend dat als jij veranderingen maakt aan java (wat voorheen dus niet kon) je die veranderingen moet publiceren,

het is NIET zo dat alle programma's gemaakt IN java, nu ook GLP'ed moete worden, net zo min als dat alle programma's die in Microsoft Visual Studio gemaakt zijn, geen Opensource mogen zijn...

overigens weet ik niet precies wat de gpl zegt over add-ons want, bijv unreal ircd staat ook toe dat 3rd party modules gewoon closed source zijn...
dus kwablijkelijk als je (in geval dat nog niet zo was) java modulair maakt moet je de aanpassing in java wel publiceren maar de modules op zicht niet...

kortom een hoop geblaat maar, volgens mij valt 't wel mee.
En wat is daar mis mee? Er zijn zat Open Source licenties die dat toestaan. Hangt allemaal sterk van de omstandigheden af. Zoals Grub al aangeeft zijn er veel bedrijven die bewust GPL software mijden, enkel en alleen om deze virale eigenschap van de GPL.
Dat was het eerste waar ik aan dacht bij het lezen van dit bericht. Is het niet zo dat je de broncode vrij moet geven onder GPL als je afhankelijk bent van vrijgegeven GPL broncode?
Naast de standaard editie van Java wordt ook de Micro Edition, bedoeld voor de ontwikkeling van mobiele applicaties, van het ontwikkeplatform vrijgegeven onder de tweede versie van de GPL.
Ik lees hier niet uit dat het alleen om de VM's gaat gezien het stukje "bedoeld voor de ontwikkeling".. Uh oh! ^_^
Ik mag aannemen dat de standaard development kit van Java niet onder GPL uitgebracht gaan worden, _dat_ zou pas impact hebben...
Ja dus :)

Het gaat om alle Java producten, Java SE en Java ME (Java EE is was open source, maar krijgt nu ook de GPL erbij als extraatje).
Dan zou namelijk elk java programma open source moeten worden...
Daar hoef je je door de "Classpath exception" niet druk om te maken. In feit wordt de GPL daardoor een soort LGPL voor Java programma's. (Dit heeft voor zover ik weet te maken met het feit dat de LGPL is opgesteld voor traditionele gecompileerde talen en de bewoording is daardoor niet geschikt voor Java)
"De eerste stukken broncode voor J2SE en J2ME zijn reeds beschikbaar gemaakt door Sun".

Iemand een idee wanneer J2SE volledig is vrijgegeven?

Erg prettige ontwikkeling trouwens :).
Dit is wel een applaus waard. :)


Nu zal Java ook aan populariteit winnen voor gebruik bij OSS projecten.
Ik denk dat het tijd is voor een nieuwe Ubuntu versie:
Iets met releasenaam Flashy Java ofzo....
Dat zal dan meer iets worden als Jolly Java ofzo (in de trant van Edgy Eft, Breezy Badger, Dapper Drake :D)
En dan Fleshy Flash zodra Flash onder de GPL wordt vrijgegeven. (as if... ;))
Ik denk dat dit gewoon in Feisty Fawn komt. Die komt pas in april volgend jaar uit, dus kan me bijna niet voorstellen dat er niet genoeg tijd is om te testen.

En sowieso kan je het voor 6.06 (Dapper Drake) en 6.10 (Edgy Eft) zo in de standaard repositories (standaard, want geen vage of gesloten licentie) verwachten, dan kan je het met +/- 10 muisklikken installeren.

Lijkt me niet dat ze hiervoor tussendoor een compleet nieuwe versie releasen.

Maar ik neem aan dat je geen serieuze reactie verwachtte? :+ Is Java Joker wat? :+
observatie: het wordt vrijgegeven onder GPL v2 en niet onder "GPL v2 or later".
Sun zie de GPL v3 blijkbaar niet zitten.
Q:
What about GPL v3? Have you considered using that license?
A:
While Sun has been working with the Free Software Foundation as an active participant in the development and review of the GPL v3 license, this license is not yet complete. It is Sun's strong desire to complete the open sourcing of its Java technology implementations in a timely manner, so we made the decision to use an existing, established license paradigm rather than wait for GPL v3 to be completed. Using GPL v2 does not indicate anything negative about GPL v3. Sun continues to be very actively and positively involved in this new license's development.

http://www.sun.com/software/opensource/java/faq.jsp#g24
Sorry, maar dat is niet waar:

https://openjdk.dev.java....e=text/vnd.viewcvs-markup

daarin staat heel duidelijk de standaard GPL clausule:
This program is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2 of the License, or (at your option)
any later version
.
En zoals Luctius hierboven al aangaf schijnt Sun zelf best tevreden te zijn met de v3, zie ook hier: http://blogs.sun.com/jonathan/
And yes, we picked GPL version 2 - version 3 isn't available, but we like where the FSF is headed.
Maar, ik vind deze opmerking van de directeur van Sun nog veel interessanter:
By admitting that one of the strongest motivations to select the GPL was the announcement made last week by Novell and Microsoft, suggesting that free and open source software wasn't safe unless a royalty was being paid. As an executive from one of those companies said, "free has to have a price."
Blijkbaar is er toch nog iets goeds gekomen uit die MS - Novel deal.
De Javaposse heeft een goede (engelstalige) podcast speciaal over het opensourcen van Java: http://www.javaposse.com/index.php?post_id=151153
A small step for sun...

...a giant leap for free software
Mooi, nu kan de native VM technologie van Sun ook in Mono worden gestopt.
Inderdaad, en alle interesante toevoegingen die het MONO team daar dan weer op maakt kan Sun weer in de JVM stoppen. :)
nu hopen dat het snel geport word naar de GP2X :> dat C++ programmeren ligt me niet zo :+

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True