Dit is een vertaling van een Engelstalige pagina.

Vrij maar geketend - De Java-valstrik

Mededeling

Sinds publicatie van dit artikel heeft Sun (nu onderdeel van Oracle) het grootste deel van de referentie-implementatie van het Java-platform onder de GNU General Public License uitgebracht, en er is nu een vrij ontwikkelplatform voor Java. Daarmee vormt de Java-programmeertaal niet langer een valkuil.

Oppassen echter, niet ieder Java platform is hiermee vrij. Sun verspreidt ook nog steeds een uitvoerbare versie die niet vrij is, evenals andere bedrijven.

De vrij omgeving voor Java heet IcedTea; dit bevat ook de broncode die Sun vrij heeft gegeven. Die moet je dus gebruiken. Veel GNU/Linux-distributies bevatten IcedTea maar sommigen bevatten niet-vrije varianten. (Opmerking in oktober 2015: de vrije implementatie van Java staat in veel GNU/Linux-distributies bekend als OpenJDK.)

Om te kunnen achterhalen of je Java-programma's goed in een vrije omgeving zullen draaien zul je met IcedTea moeten ontwikkelen. Theoretisch zouden de platformen uitwisselbaar moeten zijn maar dat is nooit voor 100 procent.

Verder zijn er niet-vrije programma's in omloop met “Java” in hun naam, zoals JavaFX, en zijn er niet-vrije Java-pakketten die je wellicht zou willen gebruiken maar dat niet moet doen. Controleer dus altijd de licenties. Wanneer je Swing gebruikt, vergewis je er dan van dat je de vrije versie gebruikt die in IcedTea zit. (Opmerking in oktober 2015: een vrije vervanging voor JavaFX, OpenJFX genaamd, is uitgebracht.)

Desalniettemin blijft het hier beschreven probleem relevant omdat andere niet-vrije programmabibliotheken of platformen hetzelfde probleem zouden kunnen bevatten. Laat deze geschiedenis van Java dus een les zijn om toekomstige valstrikken te voorkomen.

Zie verder: De JavaScript-valstrik.


12 april 2004

Wanneer je programma vrije software is, is het van zichzelf ethisch verantwoord—maar er loert een valstrik waar je voor uit moet kijken. Hoewel je programma zelf vrij is kan het toch beperkingen hebben door andere software waar het van afhankelijk is. Omdat dit probleem vooral speelt bij Java-programma's noemen we het de Java-valstrik.

Een programma is vrije software wanneer gebruikers ervan bepaalde belangrijke vrijheden krijgen. Grof gezegd zijn dit: de vrijheid een programma te gebruiken, de vrijheid het te bestuderen en de broncode te veranderen, de vrijheid de broncode en binaire code opnieuw te verspreiden en de vrijheid om nieuwe, verbeterde versies ervan te publiceren (zie ook de definitie van vrije software). Of een programma vrij is of niet is geheel afhankelijk van de licentie die erop van kracht is.

De vraag of het programma gebruikt kan worden in de vrije wereld, door mensen die in vrijheid behoren te leven, is moeilijker te beantwoorden. Dit wordt niet alleen bepaald door de licentie van een programma, want geen enkel programma werkt in totale isolatie. Ieder programma is afhankelijk van andere programma's. Het moet bijvoorbeeld gecompileerd worden of geïnterpreteerd en is daarmee afhankelijk van een compiler of interpretator. Wanneer het gecompileerd wordt naar byte-code is het ook nog eens afhankelijk van een byte-code interpretator. Verder heeft het programmabibliotheken nodig om te draaien en het zou ook nog andere programma's kunnen starten die in andere processen draaien. Al die programma's vormen afhankelijkheden. Die afhankelijkheden kunnen nodig zijn voor het programma om überhaupt te draaien of alleen voor bepaalde stukjes functionaliteit. Hoe dan ook, het programma, in zijn geheel of gedeeltelijk, kan niet draaien zonder de afhankelijkheden.

Wanneer sommige van die afhankelijkheden van een programma niet vrij zijn, betekent het dat het programma, of een gedeelte daarvan, niet kan draaien op een compleet vrij systeem—het is onbruikbaar in de vrije wereld. Natuurlijk, we kunnen het programma verspreiden en kopieën houden op onze machines maar dat heeft weinig nut als we ze niet kunnen laten draaien. Het programma mag dan vrije software zijn, het wordt bij wijze van spreken geketend door zijn niet-vrije afhankelijkheden.

Dit probleem kan zich voordoen in alle software, geschreven in welke taal dan ook. Een vrij programma bijvoorbeeld dat alleen op Microsoft Windows draait is duidelijk onbruikbaar in de vrije wereld. Maar software op GNU/Linux kan ook onbruikbaar zijn wanneer het afhankelijk is van andere, niet-vrije, software. In het verleden waren Motif (voordat we LessTif hadden) en Qt (voordat de ontwikkelaars het vrije software maakten) grote veroorzakers van dit probleem. De meeste 3D-videokaarten werken alleen volledig met niet-vrije stuurprogramma's die ook een oorzaak van het probleem vormen. Maar de grootste bron van problemen op dit moment is Java, mede doordat veel mensen die vrije software schrijven Java sexy vinden. Verblind door de aantrekkingskracht van de taal zien ze het probleem van de afhankelijkheden over het hoofd en raken verstrikt in de Java-valstrik.

De Java-implementatie door Sun is niet vrij. De standaard Java-bibliotheken zijn ook niet vrij. We hebben echter wel vrije versies van Java, zoals de GNU-compiler voor Java (GCJ) en GNU Classpath, maar die ondersteunen nog niet alle mogelijkheden. We zijn bezig met een inhaalslag.

Wanneer je een Java-programma op het Java-platform van Sun ontwikkelt loop je het risico Sun-specifieke dingen te gebruiken zonder dat je het door hebt. Wanneer je daar maanden later achter komt kan het ook weer maanden kosten voordat je die afhankelijkheid eruit hebt. Je zou dan kunnen verzuchten: “Het is teveel werk om opnieuw te beginnen”. Op dat moment is je programma verstrikt geraakt in de Java-valstrik; het is niet meer bruikbaar in de vrije wereld.

De enige betrouwbare methode om de valstrik te omzeilen is alleen een vrije implementatie van Java op je systeem toe te laten. Wanneer je op die manier iets specifieks gebruikt van Java of een bibliotheek wat nog niet wordt ondersteund, kom je er direct achter en kun je meteen je code aanpassen.

Sun blijft bezig met het ontwikkelen van nieuwe “standaard” Java-bibliotheken en ze zijn bijna allemaal niet-vrij; in veel gevallen is zelfs de specificatie van de bibliotheek een handelsgeheim en de meest recente versie van de licentie van Sun voor deze specificaties verbiedt zelfs publicatie van implementaties die niet volledig zijn. (Zie Java Specification Participation Agreement en J2ME™ Personal Basis Profile Specification voor voorbeelden).

Gelukkig laat die licentie wel toe dat er een vrije implementatie uitgebracht kan worden; anderen die deze bibliotheek dan ontvangen mogen hem dan wel veranderen en hoeven niet volledig aan de specificatie te voldoen. Maar deze vereiste beperkt wel de mogelijkheid om via een samenwerkingsmodel een vrije implementatie te maken. In een dergelijk model moet je onvolledige versies publiceren wat diegenen die de specificatie hebben gelezen niet mogen doen.

In de begintijd van de vrije software beweging was het onmogelijk om geen afhankelijkheden te hebben met niet-vrije programma's. Voordat we de GNU C-compiler hadden was ieder C-programma (vrij of niet), afhankelijk van een niet-vrije C-compiler. Voordat we de GNU C-bibliotheek hadden was ieder programma afhankelijk van een niet-vrije C-bibliotheek. Voordat we Linux hadden, de eerste vrije kernel, was ieder programma afhankelijk van een niet-vrije kernel. Voordat we Bash hadden moest ieder script geïnterpreteerd worden door een niet-vrije shell. Deze beperkende afhankelijkheden waren onvermijdelijk maar dit was acceptabel omdat ons plan was ze in de toekomst hiervan te redden. Ons hogere doel, een zelfstandig besturingssysteem, zou een vrije vervanging hebben voor al deze afhankelijkheden; wanneer we dit doel zouden bereiken zouden al onze programma's gered zijn. Aldus geschiedde: met het GNU/Linux-systeem kunnen we deze programma's laten draaien op een vrij platform.

Vandaag de dag is het anders. We hebben krachtige vrije besturingssystemen en een hoop vrije programmeer-hulpmiddelen. Wat je ook wilt doen, je kunt het op een vrij platform doen; er is geen reden meer om een niet-vrije afhankelijkheid te accepteren, zelfs niet voor even. Mensen raken voornamelijk nog verstrikt omdat ze er niet goed over nadenken. De simpelste oplossing voor deze Java-valstrik is door mensen aan te leren dit te vermijden.

Om je Java-code te beschermen tegen de Java-valstrik moet je een vrije Java-ontwikkelomgeving installeren en die gebruiken. Meer in het algemeen, wat voor taal je ook gebruikt, let op en controleer de vrije status van de afhankelijkheden van je programma. De makkelijkste manier om dit na te gaan is door te kijken of het programma in de lijst van vrije software staat. Als hij niet in die lijst voorkomt dan kun je altijd nog zijn licentie nagaan op de lijst van vrije licenties ( http://www.gnu.org/licenses/license-list.html).

We proberen nu de verstrikte Java-programma's te redden dus als je een zwak hebt voor Java wordt je van harte uitgenodigd om te helpen bij de ontwikkeling van GNU Classpath. Het testen van je programma met de GCJ-compiler en GNU Classpath en problemen met reeds gebouwde klassen rapporteren is ook nuttig. Het afmaken van GNU Classpath vergt echter tijd; indien er meer niet-vrije programmabibliotheken toegevoegd blijven worden zullen we wellicht nooit bij raken. Dus keten je vrije software alsjeblieft niet. Wanneer je nu een applicatie gaat schrijven, doe het dan zo dat het vanaf het begin op vrije voorzieningen draait.

Zie ook:

Het Merkwaardige Incident van Sun in de Nacht