Vrij maar geketend - De Java-valstrik

door Richard Stallman

---

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