,
,
,
Repair and OwnershipRepair and Ownership is een project van ASK-Solutions rond de vraag wat eigenaarschap in de praktijk betekent. Wanneer je iets bezit, in hoeverre moet je het dan kunnen begrijpen, gebruiken, onderhouden, repareren, aanpassen en blijven gebruiken zonder daarvoor afhankelijk te blijven van toestemming, diensten of infrastructuur van de oorspronkelijke leverancier?
Reparatie is een belangrijk en zichtbaar deel van die vraag, maar niet het eindpunt. Een product kan technisch volledig intact zijn en toch onbruikbaar worden doordat een account verdwijnt, een server wordt uitgezet, software niet langer wordt ondersteund, een functie achter een abonnement terechtkomt of een digitale aankoop achteraf slechts een herroepbare licentie blijkt te zijn. Repair and Ownership onderzoekt ook die vormen van afhankelijkheid.
De naam van het project is bewust breder dan Right to Repair. Repareren is een van de duidelijkste momenten waarop zichtbaar wordt hoeveel zeggenschap een eigenaar werkelijk heeft. Kun je het apparaat openen? Is documentatie beschikbaar? Kun je onderdelen verkrijgen? Kun je diagnosegegevens uitlezen? Mag en kun je software onderzoeken of vervangen? Kan een onafhankelijke reparateur hetzelfde doen als de fabrikant of een aangesloten dealer?
Maar dezelfde vraag begint vóór een reparatie nodig is en blijft bestaan nadat iets gerepareerd is. Mag je een product anders gebruiken dan de fabrikant oorspronkelijk bedacht? Kun je een onderdeel vervangen door een functioneel passend alternatief? Kun je eigen software installeren? Kun je gegevens uitlezen en meenemen? Blijft een apparaat bruikbaar wanneer de fabrikant een online dienst beëindigt? En kan een functie die aanwezig was toen je het product kocht later afhankelijk worden gemaakt van nieuwe voorwaarden of doorlopende betaling?
Daarom staan Repair en Ownership samen in de projectnaam. De reparatievraag is een praktische test van eigenaarschap; de eigendomsvraag gaat uiteindelijk over de zeggenschap die na aankoop daadwerkelijk bij de eigenaar blijft.
De geschiedenis van Repair and Ownership gaat terug tot vóór de huidige georganiseerde Right to Repair-beweging en zelfs tot vóór de Amerikaanse DMCA van 1998. De onderwerpen werden toen niet noodzakelijk met de termen gebruikt die er tegenwoordig voor bestaan, maar de onderliggende vragen waren dezelfde: wie houdt na verkoop de feitelijke controle, welke kennis blijft beschikbaar en hoeveel macht kan een leverancier via techniek, contracten of regelgeving behouden?
Een vroeg onderwerp was iets eenvoudigs als het werkelijk lezen van de voorwaarden van online diensten. Bij diensten zoals Hotmail keken we niet alleen naar wat een dienst zichtbaar aanbood, maar ook naar wat in de voorwaarden stond over berichten, gegevens en de rechten die een aanbieder zichzelf gaf. De bredere vraag was al herkenbaar: als je een dienst gebruikt om persoonlijke informatie te bewaren of te communiceren, welke zeggenschap heb je daar dan zelf nog over?
In dezelfde periode veranderde ook de relatie met fysieke producten. Bij televisies, radio’s, cv-ketels en andere apparatuur waren schema’s, servicehandleidingen en technische gegevens vroeger geregeld onderdeel van het product of relatief eenvoudig verkrijgbaar. Steeds vaker verhuisde die informatie naar gesloten servicenetwerken van fabrikanten, dealers en erkende monteurs. Een eigenaar bezat het apparaat nog steeds, maar de kennis die nodig was om het zelfstandig te begrijpen en onderhouden werd minder vanzelfsprekend beschikbaar.
Met software en digitale media werd het verschil tussen juridisch bezit, praktisch gebruik en technische zeggenschap nog zichtbaarder. De DMCA en vergelijkbare discussies rond digitale toegangsbeveiliging maakten duidelijk dat een technische beperking meer kon worden dan alleen een beveiligingsmechanisme: het doorbreken van een digitaal slot kon juridisch problematisch worden, ook wanneer de handeling zelf een legitiem doel had.
Daarna volgden in de Verenigde Staten voorstellen om kopieerbeveiliging nog dieper in computers en andere digitale apparaten te verankeren. In discussies rond voorstellen zoals de Security Systems Standards and Certification Act en de latere Consumer Broadband and Digital Television Promotion Act kwam zelfs de vraag op of algemeen inzetbare computers en andere digitale apparatuur technisch verplicht zouden moeten meewerken aan door rechthebbenden bepaalde beperkingen.
Voor Repair and Ownership raakt dat aan een fundamenteel verschil. Een computer is waardevol omdat de eigenaar hem voor nieuwe en onvoorziene doeleinden kan gebruiken. Wanneer hardware of software zo wordt ontworpen dat een externe partij vooraf bepaalt welke informatie verwerkt mag worden, welke programma’s mogen draaien of welke gegevens mogen worden gekopieerd, verschuift de controle van de eigenaar naar degene die het technische slot beheert.
Een duidelijk voorbeeld ontstond rond Adobe’s beveiligde e-books. Digitale beperkingen konden onder meer kopiëren, afdrukken en tekst-naar-spraak blokkeren. Dat laatste was niet alleen een kwestie van gemak: mensen met een visuele of motorische beperking konden afhankelijk zijn van andere screenreaders en toegankelijkheidssoftware dan de functies die Adobe zelf beschikbaar stelde.
In 2001 werd de Russische programmeur Dmitry Sklyarov in de Verenigde Staten gearresteerd vanwege zijn werk aan software waarmee beperkingen van Adobe e-books konden worden verwijderd. De discussie ging daardoor niet alleen over auteursrecht of het ongeoorloofd verspreiden van boeken. Dezelfde techniek maakte het voor een rechtmatige gebruiker ook mogelijk een gekocht boek met andere software te lezen, een reservekopie te maken, het onder Linux te gebruiken of tekst-naar-spraaksoftware te gebruiken die daadwerkelijk bij de behoeften van de gebruiker paste.
Dat raakt een terugkerend uitgangspunt van Repair and Ownership: een beveiligingsmechanisme kan een legitiem doel hebben, maar het bestaan van dat doel maakt niet automatisch iedere beperking van de eigenaar wenselijk of verantwoord. Veiligheid, auteursrecht en bescherming tegen misbruik moeten worden afgewogen tegen toegankelijkheid, onderzoek, interoperabiliteit, reparatie, behoud en normaal gebruik.
De problemen rond digitale sloten en toegankelijkheid staan niet op zichzelf. Een terugkerende vraag binnen Repair and Ownership is wat er gebeurt wanneer één leverancier niet alleen een programma of bestandsformaat levert, maar een compleet ecosysteem probeert te beheersen: de programmeertaal, ontwikkelgereedschappen, runtime, gebruikersinterface, distributie en soms zelfs de keuze van besturingssystemen waarop toepassingen kunnen worden uitgevoerd.
Adobe en daarvoor Macromedia vormen daarvan een belangrijk historisch voorbeeld. Rond Flash en ActionScript ontstond geleidelijk een steeds completere eigen applicatieomgeving. Flex voegde daar een uitgebreider componenten- en applicatiemodel aan toe en met Adobe AIR konden toepassingen uit dat ecosysteem ook buiten de browser als zelfstandige desktopsoftware worden uitgevoerd.
Dat bood ontwikkelaars veel mogelijkheden binnen die omgeving, maar dat is niet hetzelfde als vrijheid. Wie een omvangrijke toepassing in ActionScript, Flex of AIR bouwde, investeerde tegelijk in een runtime, componentmodel en gereedschappen waarvan Adobe de verdere ontwikkeling bepaalde. Een toepassing kon daardoor sterk aan Adobe verbonden raken, ook wanneer zij inhoudelijk helemaal niets met Adobe zelf te maken had.
AIR werd nadrukkelijk als cross-platformomgeving aangeboden. Dat klinkt alsof een applicatie daarmee losser van een bepaald besturingssysteem kwam te staan. In werkelijkheid werd tussen applicatie en besturingssysteem een nieuwe afhankelijkheid geplaatst: de Adobe-runtime moest voor dat platform bestaan.
Zeker in het begin betekende desktopondersteuning vooral Windows en Macintosh. Linux kwam later, maar was afhankelijk van Adobe’s eigen binaire runtime en functioneerde niet vanzelfsprekend op iedere distributie en systeemconfiguratie. Die ondersteuning werd bovendien weer beëindigd; AIR 2.6 bleef de laatste officiële Linux-versie. Voor verschillende andere Unix-systemen waarvoor al jarenlang grafische en programmeeromgevingen bestonden, kwam een vergelijkbare AIR-runtime helemaal niet beschikbaar.
Daarmee kon een zogenaamd platformonafhankelijke applicatie de gebruiker juist opnieuw aan een beperkt aantal platformen binden. Wanneer Adobe een besturingssysteem niet ondersteunde of de ondersteuning beëindigde, moest een gebruiker voor bestaande software soms een oude runtime of een oud besturingssysteem blijven gebruiken, naar een ander platform overstappen of de applicatie opgeven. De keuze van het besturingssysteem lag dan niet meer alleen bij gebruiker en ontwikkelaar, maar mede bij de leverancier van de tussenlaag.
Dat is belangrijk omdat cross-platform toepassingen toen helemaal geen nieuw probleem meer waren. Er bestonden al verschillende veel oudere architecturen die programmatuur van één specifiek besturingssysteem konden losmaken zonder één leverancier tot enige poortwachter van de runtime te maken.
Java bood daarvan een breed voorbeeld. Java werd niet alleen op Windows en Macintosh gebruikt, maar ook op Linux, Solaris, HP-UX, SCO OpenServer, UnixWare en andere systemen. Verschillende systeemleveranciers en implementatoren konden een Java-omgeving voor hun platform beschikbaar maken. De programmeertaal en het uitvoeringsmodel waren daardoor niet uitsluitend afhankelijk van de bereidheid van één bedrijf om voor iedere ondersteunde machine zelf één specifieke gesloten binary uit te brengen.
Ook de grafische interface kende binnen Java verschillende oplossingen. AWT gebruikte in belangrijke mate de native bedieningselementen van het besturingssysteem. Swing gebruikte grotendeels eigen componenten, maar koppelde die aan een expliciete Java Accessibility API. SWT koos later opnieuw voor een model waarin één Java-API op verschillende systemen zoveel mogelijk de native widgets van het betreffende besturingssysteem gebruikte.
Daarmee bestond al een belangrijk architectonisch onderscheid. Cross-platform hoefde niet te betekenen dat een toepassing zich volledig losmaakte van de voorzieningen van het onderliggende systeem. Een grafische toolkit kon juist gebruikmaken van native componenten of via een afzonderlijke toegankelijkheidslaag kenbaar maken dat iets een knop, tekstveld of menu was, welke toestand het had en welke handelingen mogelijk waren.
Java beperkte zich bovendien niet tot klassieke desktopapplicaties. Een als JAR verpakte Java-applet kon vanuit een webpagina worden geladen en binnen de browseromgeving worden uitgevoerd. De browserpagina fungeerde dan als distributie- en integratielaag, terwijl de programmatuur zelf in de Java-runtime draaide.
Met Java Web Start kon dezelfde gedachte ook buiten de browser worden toegepast. Via een klein JNLP-bestand kon een website aangeven welke programmabestanden en Java-versie nodig waren. De applicatie kon worden opgehaald, lokaal worden gecachet en vervolgens als zelfstandige toepassing draaien. Het web kon dus worden gebruikt voor distributie en updates zonder dat de applicatie voor iedere uitvoering aan de oorspronkelijke webpagina verbonden hoefde te blijven.
Op featurephones kreeg een vergelijkbaar model grote praktische betekenis. Java ME en MIDP maakten het mogelijk toepassingen als MIDlets op zeer beperkte mobiele apparatuur uit te voeren. Een klein JAD-bestand kon beschrijven welke JAR nodig was, waarna de telefoon het programma installeerde. De programmatuur bleef vervolgens grotendeels lokaal aanwezig en hoefde via het mobiele netwerk alleen actuele of veranderende gegevens op te halen.
Dat laatste onderscheid is voor Repair and Ownership belangrijk. Mobiele bandbreedte, geheugen en opslag waren toen extreem beperkt. Een programma vooraf installeren en tijdens gebruik slechts kleine hoeveelheden informatie ophalen was daarom geen kunstmatig ingevoerde afhankelijkheid. Het was een redelijke technische oplossing voor werkelijke beperkingen van de beschikbare hardware en netwerken.
Een netwerkafhankelijkheid is dus niet automatisch een aantasting van eigenaarschap. De relevante vraag is waarom zij bestaat. Is zij nodig om binnen de technische mogelijkheden van het moment een bruikbaar systeem te bouwen, of wordt een technisch vermijdbare afhankelijkheid toegevoegd om controle, advertenties, licentiehandhaving of voortdurende betaling af te dwingen?
Ook de latere mobiele ontwikkeling laat zien dat de principes achter Java niet eenvoudig verdwenen. Android gebruikte geen gewone Java-SE-runtime, maar bouwde wel op de Linux-kernel en stelde een groot deel van zijn applicatie-API’s historisch via de Java-programmeertaal beschikbaar. Een nieuwe mobiele omgeving hoefde daardoor niet vanuit het gesloten Adobe-ecosysteem te worden opgebouwd om een omvangrijk applicatieplatform te kunnen vormen.
Java was bovendien niet het eerste voorbeeld. Tcl ontstond al aan het einde van de jaren tachtig op Unix als een uitbreidbare programmeer- en scripttaal die in andere toepassingen kon worden ingebed. Kort daarna werd Tk ontwikkeld als grafische toolkit voor Unix- en X11-systemen.
In de jaren daarna werden Tcl en Tk ook naar Windows en Macintosh geport. Daarmee groeide een omgeving die uit de Unix-wereld kwam uit tot een daadwerkelijk cross-platform model voor grafische desktopsoftware. De toepassing kon voor een groot deel gelijk blijven, terwijl de omgeving zelf voor verschillende systemen beschikbaar kon worden gemaakt en uit broncode verder kon worden aangepast of geporteerd.
Dat maakt Tcl/Tk juist in vergelijking met AIR relevant. Toen Adobe een eigen cross-platform desktopomgeving bovenop Flash en ActionScript introduceerde, bestond het onderliggende concept al vele jaren. AIR vond cross-platform desktopsoftware niet uit; het bracht een bestaand idee naar een door Adobe gecontroleerde runtime en maakte daarmee de beschikbaarheid van die runtime zelf tot een nieuwe afhankelijkheid.
Hetzelfde geldt voor interactieve grafische toepassingen in en rond het web. Flash bestond daar niet in een technisch vacuüm. JavaScript, later gestandaardiseerd als ECMAScript, was niet uitsluitend een taal om vanuit HTML enkele elementen van een webpagina te veranderen. De taal kon in verschillende hostomgevingen worden uitgevoerd en stond als programmeertaal los van HTML.
SVG is daarvoor een belangrijk voorbeeld. Een SVG-document kon zelfstandig bestaan, had een eigen documentstructuur, grafische objecten en events en kon met ECMAScript worden geprogrammeerd. Daarmee konden interactieve grafische toepassingen worden gebouwd waarin JavaScript rechtstreeks het gedrag van de grafische omgeving bepaalde.
Ook hier moet de geschiedenis niet achteraf worden vereenvoudigd tot de gedachte dat Flash een plug-in vereiste terwijl open technologie rechtstreeks in iedere browser werkte. Dat was aanvankelijk niet zo. Voor SVG kon een aparte viewer of browserplug-in nodig zijn en Java-applicaties gebruikten eveneens een browserruntime. Wanneer een SVG-viewer het bijbehorende ECMAScript uitvoerde, draaide ook dat JavaScript feitelijk binnen aanvullende software.
Het relevante verschil lag daarom niet in het bestaan van een plug-in. Een plug-in kan een implementatie zijn van een publiek beschreven standaard die ook door andere partijen kan worden geïmplementeerd. Dat is architectonisch iets anders dan een plug-in die de noodzakelijke uitvoeromgeving vormt voor een door dezelfde leverancier gecontroleerd applicatieplatform.
Juist daar werd een ander fundamenteel probleem van de Adobe-architectuur zichtbaar. Flash-, ActionScript-, Flex- en AIR-toepassingen konden een groot deel van hun gebruikersinterface zelf tekenen en afhandelen. Met AIR kon zelfs de normale vensterbediening van het besturingssysteem worden vervangen door een eigen interface.
Voor een ziende gebruiker kan een getekende knop precies hetzelfde lijken als een native knop. Voor een screenreader of andere ondersteunende technologie is dat verschil enorm. Een native bedieningselement is niet alleen een afbeelding: het besturingssysteem weet dat het een knop is, kent de naam en toestand, weet waar de focus staat en welke actie ermee uitgevoerd kan worden.
Wanneer een applicatie haar eigen grafische wereld bouwt, moet die semantische informatie opnieuw en correct aan ondersteunende technologie worden aangeboden. Gebeurt dat niet, dan kan een toepassing voor een ziende gebruiker volledig functioneel lijken terwijl voor iemand die afhankelijk is van een screenreader, toetsenbordbediening, vergroting of aangepaste invoer nauwelijks een bruikbare interface bestaat.
Adobe hield daarmee hardnekkig een probleem in stand waarvoor andere architecturen al oplossingen boden. AWT kon native elementen gebruiken, Swing had een afzonderlijke Accessibility API en SWT kon via native widgets aansluiten op voorzieningen van het besturingssysteem. Dat betekent niet dat iedere Java-toepassing automatisch toegankelijk was. Het laat wel zien dat het buitenspel zetten van bestaande toegankelijkheidsvoorzieningen geen onvermijdelijke prijs van een cross-platform interface was.
De afhankelijkheid van zo’n gesloten ecosysteem werkt daardoor op meerdere niveaus tegelijk. Een ontwikkelaar kan vast komen te zitten aan een programmeertaal, toolkit, ontwikkelomgeving en runtime waarvan één leverancier de toekomst bepaalt. Een eindgebruiker kan afhankelijk raken van diezelfde runtime en van de besturingssystemen waarvoor de leverancier besluit haar beschikbaar te houden. En iemand die ondersteunende technologie nodig heeft, kan daarbovenop afhankelijk worden van de vraag of een ontwikkelaar binnen die afzonderlijke interfacewereld opnieuw voldoende toegankelijkheid heeft ingebouwd.
Ook economische draagkracht speelt daarin mee. Wanneer nieuwe versies van een applicatie alleen op nieuwere hardware of een beperkt aantal ondersteunde besturingssystemen werken, is overstappen voor gebruikers niet alleen een technische keuze. Iemand moet die hardware, licentie of dienst ook kunnen betalen. Een platform kan daardoor gebruikers uitsluiten die technisch nog over bruikbare apparatuur beschikken maar niet kunnen of willen deelnemen aan de door de leverancier opgelegde vervangingscyclus.
Voor Repair and Ownership zijn toegankelijkheid en economische toegankelijkheid daarom geen losse maatschappelijke toevoegingen aan een technisch onderwerp. Zij horen rechtstreeks bij de vraag hoeveel praktische zeggenschap een gebruiker over zijn eigen apparatuur en software heeft. Een product dat alleen bruikbaar is voor mensen die de door de leverancier gekozen hardware, software, lichamelijke interactievorm en betalingsstructuur kunnen volgen, laat een deel van zijn gebruikers feitelijk buiten het eigenaarschap vallen.
Bij gesloten platformen speelt bovendien niet alleen technische kwaliteit een rol. Een leverancier met voldoende marketingbudget, distributieafspraken, bundeling en commerciële ondersteuning kan zijn eigen oplossing tot het vanzelfsprekende referentiepunt maken. Zodra bijna iedere gebruiker een bepaalde runtime heeft en steeds meer ontwikkelaars ervoor bouwen, wordt het voor anderen steeds duurder om niet mee te doen.
Zo ontstaat een zichzelf versterkend effect. Grote distributie maakt een platform aantrekkelijk voor ontwikkelaars. Meer toepassingen maken het platform belangrijker voor gebruikers. Dat maakt het vervolgens aantrekkelijker voor browsermakers, fabrikanten en andere distributeurs om het opnieuw mee te leveren. De uiteindelijke dominantie kan daardoor gemakkelijk worden aangezien voor bewijs dat de gekozen technologie technisch noodzakelijk of vanzelfsprekend de beste oplossing was.
Daarbij kan zelfs de historische referentierichting veranderen. Bestaande of parallel ontwikkelde oplossingen worden achteraf alternatieven voor het dominante product genoemd. Daarmee ontstaat de indruk dat het dominante product eerst de categorie definieerde en andere oplossingen later verschenen om het te vervangen.
Dat zie je niet alleen bij Flash. Grafische programma’s als GIMP en Paint Shop Pro worden tegenwoordig gemakkelijk als alternatieven voor Photoshop aangeduid. GIMP kwam wel later dan Photoshop, maar ontwikkelt zich inmiddels al sinds het midden van de jaren negentig als zelfstandig project naast Photoshop. Paint Shop Pro verscheen zelfs in hetzelfde jaar als Photoshop. Dat gebruikers zulke programma’s later opnieuw ontdekken vanwege prijs, licentievoorwaarden of andere beperkingen van Adobe maakt ze historisch niet tot pas daarna ontstane vervangers.
Bij AIR is de omkering nog duidelijker. Cross-platform grafische desktopapplicaties bestonden al vele jaren via onder meer Tcl/Tk en Java. Toch kon een nieuwe, veel sterker door één leverancier gecontroleerde implementatie als een nieuwe stap naar platformonafhankelijke applicaties worden gepresenteerd. De grote zichtbaarheid van het nieuwe product kon daarmee het veel oudere technische landschap naar de achtergrond drukken.
Voor Repair and Ownership is dat relevant omdat marktdominantie niets zegt over hoeveel vrijheid een technologie bij andere partijen laat. Een platform kan indrukwekkende functies bieden, breed worden gebruikt en commercieel zeer succesvol zijn terwijl het tegelijkertijd ontwikkelaars, gebruikers en onafhankelijke implementatoren minder mogelijkheden geeft om de technologie zelf beschikbaar te houden, aan te passen of buiten de oorspronkelijke leverancier voort te zetten.
Java, Tcl/Tk, SVG, ECMAScript en andere bestaande omgevingen waren zelf niet volmaakt. Implementaties verschilden, ondersteuning kon onvolledig zijn, licenties veranderden en ook open standaarden konden slecht of ontoegankelijk worden toegepast. Het relevante verschil is niet dat één technisch alternatief ieder probleem oploste.
De belangrijkere vraag is waar de beslissende afhankelijkheid ligt. Kan een andere partij een runtime of viewer implementeren? Kan software naar een ander systeem worden geporteerd? Kan een gebruiker een andere implementatie kiezen? Kan een toepassing onderhouden blijven wanneer de oorspronkelijke leverancier ermee stopt? Kan een ontwikkelaar verder zonder opnieuw te moeten beginnen? Kan iemand met een beperking zijn bestaande hulpmiddelen blijven gebruiken? En kan iemand met beperkte financiële middelen bruikbare apparatuur blijven inzetten in plaats van door software tot vervanging te worden gedwongen?
Een gesloten ecosysteem kan op al die punten tegelijk macht bij één leverancier concentreren. Voor Repair and Ownership is dat een directe eigendomsvraag. Eigenaarschap gaat niet alleen over de bestanden of hardware die iemand heeft betaald. Het gaat ook over de mogelijkheid om die techniek te blijven gebruiken, begrijpen, onderhouden en aanpassen wanneer de oorspronkelijke leverancier andere commerciële of technische keuzes maakt.
Naarmate apparaten vaker met software en netwerken verbonden raakten, werd eigenaarschap minder afhankelijk van alleen de fysieke constructie van een product. Een camera, babyfoon, lamp, televisie, auto of huishoudelijk apparaat kan technisch van de eigenaar zijn en toch voor belangrijke functies afhankelijk blijven van een account, een app, een server, een abonnement of toestemming van de leverancier.
Daarmee ontstaat een ander soort levensduur. Een mechanisch onderdeel kan verslijten en worden vervangen. Een online dienst kan daarentegen door één beleidsbeslissing verdwijnen. Een fabrikant kan stoppen, een overname kan plaatsvinden, licentieafspraken kunnen veranderen of een nieuwe versie van software kan andere voorwaarden opleggen. Het fysieke apparaat kan nog jarenlang functioneren terwijl een externe afhankelijkheid bepaalt of het daadwerkelijk bruikbaar blijft.
Repair and Ownership kijkt daarom niet alleen naar de vraag of iets vandaag werkt. Ook belangrijk is wat er gebeurt wanneer de leverancier morgen niet meer wil, kan of mag leveren. Kan het apparaat dan lokaal blijven functioneren? Kan een andere partij de benodigde dienst overnemen? Is een protocol gedocumenteerd? Kun je gegevens exporteren? Is software vervangbaar? Of verandert een gekocht object feitelijk in elektronisch afval zodra een externe server verdwijnt?
Digitale distributie heeft ook het woord kopen zelf minder vanzelfsprekend gemaakt. Bij een fysieke cd, dvd, boek of apparaat blijft het exemplaar normaal gesproken bestaan wanneer de winkel sluit of de fabrikant een licentieovereenkomst verliest. Bij digitale aankopen kan achter het woord “kopen” een licentie zitten die toegang afhankelijk maakt van een account, platform of overeenkomst tussen bedrijven waar de gebruiker geen partij bij is.
Dat verschil wordt zichtbaar wanneer een aanbieder aankondigt dat eerder als gekocht aangeboden media uit bibliotheken van gebruikers zullen verdwijnen omdat een licentieovereenkomst verandert. Het feit dat zulke aankondigingen mogelijk zijn, roept een eenvoudige vraag op: wat heeft de gebruiker dan precies gekocht?
Een revocable licence is juridisch niet hetzelfde als huur of bruikleen, maar het praktische verschil met traditioneel eigendom kan voor de gebruiker groot zijn. Wanneer een andere partij eenzijdig kan bepalen hoe lang toegang blijft bestaan, lijkt de positie van de gebruiker veel minder op het gewone begrip van iets kopen en blijvend bezitten.
Dat deze kwestie inmiddels breder wordt herkend, blijkt ook uit regelgeving die verkopers van digitale goederen verplicht duidelijker te maken wanneer woorden als “buy” of “purchase” feitelijk betrekking hebben op een licentie die onder bepaalde omstandigheden kan worden ingetrokken. Voor Repair and Ownership is dat geen nieuwe vraag, maar een moderne verschijningsvorm van een veel oudere.
Een vergelijkbare verschuiving vindt plaats bij fysieke producten. Moderne apparatuur kan hardware bevatten die technisch volledig aanwezig en werkend is, terwijl software bepaalt of de eigenaar die hardware daadwerkelijk mag gebruiken. Fabrikanten kunnen daardoor functies na aankoop activeren voor een bepaalde periode, koppelen aan een account of als afzonderlijke digitale dienst verkopen.
Wanneer een fabrikant verschillende uitvoeringen wil aanbieden, hoort een eigenaar daadwerkelijk te kunnen kiezen tussen producten met verschillende mogelijkheden. Een eenvoudiger uitvoering kan minder hardware bevatten en daardoor minder grondstoffen, productie, gewicht en energie vragen. Een andere situatie ontstaat wanneer dezelfde extra hardware in ieder product aanwezig is, maar de eigenaar die alleen na aanvullende betaling of een abonnement mag gebruiken.
Dan is het misleidend om de niet-geactiveerde uitvoering zonder meer als goedkoper te beschrijven. De eigenaar betaalt op dat moment weliswaar minder voor toegang tot de functie, maar de hardware is al ontworpen, geproduceerd, ingebouwd en vervoerd. De grondstoffen en energie zijn dus al gebruikt, ook wanneer de eigenaar het onderdeel nooit kan benutten. Afhankelijk van het soort hardware kan de aanwezigheid ervan bovendien gedurende de levensduur extra gewicht, ruimte, complexiteit of energiegebruik veroorzaken.
Voor Repair and Ownership is daarom niet alleen van belang of een functie optioneel wordt verkocht, maar ook waar die keuze technisch wordt gemaakt. Een werkelijk eenvoudiger product zonder de betreffende hardware is iets anders dan een volledig uitgerust product waarvan delen softwarematig worden uitgeschakeld. In dat laatste geval bezit de gebruiker fysiek meer van het apparaat dan hij daadwerkelijk mag gebruiken, terwijl de fabrikant de praktische toegang tot een deel van het gekochte object behoudt.
Nog ingrijpender is de situatie waarin een functie die bij aankoop gewoon beschikbaar was later door een softwarewijziging, nieuwe voorwaarden of een veranderd bedrijfsmodel afhankelijk wordt van aanvullende betaling. Dan verandert niet alleen wat een fabrikant in de toekomst verkoopt; de praktische eigenschappen van iets dat iemand al bezit worden achteraf beperkt.
Ook interoperabiliteit hoort bij praktisch eigenaarschap. Daarbij gaat het niet alleen om de vraag of verschillende apparaten toevallig technisch van elkaar verschillen. Een veel scherpere eigendomsvraag ontstaat wanneer apparatuur in beginsel dezelfde standaarden gebruikt en technisch met elkaar zou kunnen samenwerken, maar een leverancier of netwerkoperator bewust een extra afwijking introduceert waardoor alleen geselecteerde apparatuur nog functioneert.
Dat was bijvoorbeeld zichtbaar tijdens de overgang naar digitale televisie. De gebruikte televisie-, decoder- en Conditional Access-techniek kon technisch compatibel zijn, terwijl een netwerkoperator toch een kunstmatige blokkade kon toevoegen. Dat kon op zeer eenvoudige manieren gebeuren: een bit anders interpreteren of inverteren, een signaal op een andere aansluiting van een interface aanbieden, vooraf het serienummer van een ontvanger in het netwerk registreren of andere kleine protocolafwijkingen gebruiken. Soms konden zenders of diensten bovendien wisselen tussen een standaardsignaal en een aangepaste variant. De consument had dan niet te maken met een werkelijk noodzakelijke technische incompatibiliteit, maar met een compatibiliteitsgrens die doelbewust was toegevoegd.
Het praktische gevolg was dat iemand hoogwaardige apparatuur met een geschikte Common Interface of andere gestandaardiseerde aansluiting kon bezitten, maar toch verplicht bleef een door de netwerkoperator geleverde ontvanger te gebruiken. De smartcard of toegangsvoorziening kon dan niet rechtstreeks in de eigen apparatuur worden gebruikt, ondanks dat die apparatuur technisch voor precies dat doel was ontworpen. Het signaal moest eerst door de beperkte decoder van de operator en vervolgens bijvoorbeeld via SCART, S-Video of composiet naar een veel betere televisie of installatie worden gevoerd. Daarmee bepaalde niet de technische standaard, maar de netwerkoperator welke apparatuur de eigenaar daadwerkelijk mocht gebruiken.
Dat onderscheid is belangrijk voor Repair and Ownership. Een open standaard of fysiek passende aansluiting betekent weinig wanneer een partij daar bewust een niet-noodzakelijke afwijking aan toevoegt om alternatieve apparatuur buiten te sluiten. Interoperabiliteit gaat daarom niet alleen over connectoren en protocollen, maar ook over de vraag of die standaarden zonder kunstmatige toegangsvoorwaarden werkelijk gebruikt mogen worden.
Dezelfde eigendomsvraag keert later terug bij laders, printeronderdelen, diagnoseapparatuur, smart-homeprotocollen, accessoires en softwareformaten. Wanneer een product technisch met alternatieven kan samenwerken maar software, registratie, cryptografische sleutels of andere artificiële beperkingen dat verhinderen, houdt de eigenaar minder praktische zeggenschap over het product dan de fysieke aankoop doet vermoeden.
Eigenaarschap en behoud spelen niet alleen bij hardware. Al bij vroege browsergames werd zichtbaar dat digitale software volledig uit het bereik van gebruikers kon verdwijnen, ook wanneer daar niet simpelweg een centrale spelserver achter zat die later werd uitgezet. Een belangrijk voorbeeld waren spellen en interactieve toepassingen die waren gemaakt met Macromedia Director en in de browser draaiden via de Shockwave Player, later Adobe Shockwave Player.
Shockwave werkte bovendien met uitbreidingen die Xtras werden genoemd. Een Director-productie kon afhankelijk zijn van specifieke Xtras voor bijvoorbeeld beeld, geluid, 3D of andere functies. Die uitbreidingen hoefden niet allemaal vooraf op de computer aanwezig te zijn: een Shockwave-productie kon aangeven welke Xtras nodig waren en deze wanneer nodig laten downloaden. Daarmee bestond een spel niet noodzakelijk uit één zelfstandig bestand dat je eenvoudig kon bewaren. Om het later nog te kunnen uitvoeren konden ook de juiste Shockwave-versie, de benodigde Xtras en andere onderdelen van de oorspronkelijke omgeving nodig zijn.
Daar kwam nog iets anders bij. Sommige browsergames werden bewust zo gepubliceerd dat het niet voldoende was om het spelbestand uit de browsercache of van de website te bewaren en vervolgens lokaal op de computer te openen. Het bestand kon technisch nog aanwezig zijn, maar de toepassing was ontworpen om alleen goed te functioneren wanneer zij vanuit de bedoelde websiteomgeving werd geladen. Daarmee kon een gebruiker een kopie van het eigenlijke spelbestand hebben en toch geen zelfstandig bruikbare versie bezitten.
Wanneer de aanbieder vervolgens het spel van de website verwijderde, verdween dus niet noodzakelijk een server die tijdens het spelen voortdurend de spelwereld aanstuurde. De toegang verdween doordat de publicatie zelf was weggehaald, benodigde onderdelen zoals Xtras niet meer beschikbaar waren of de software bewust afhankelijk was gemaakt van de oorspronkelijke webomgeving. Tegelijk was juist die webomgeving onderdeel van het bedrijfsmodel: rondom het spel konden advertenties worden getoond zolang de gebruiker het via de website speelde. Een zelfstandig lokaal bruikbare kopie zou die afhankelijkheid verbreken.
Dit maakt het voor Repair and Ownership een belangrijk vroeg voorbeeld. Een digitaal werk kon volledig op de computer van de gebruiker worden uitgevoerd en toch zo worden verspreid dat de gebruiker er geen zelfstandig bruikbare kopie van kon behouden. De technische mogelijkheid om software lokaal uit te voeren betekende dus niet automatisch dat de gebruiker ook de praktische mogelijkheid kreeg om haar te bewaren en later opnieuw te gebruiken.
Flash-games en andere browsertechnologieën kregen later vergelijkbare problemen, maar het Director/Shockwave-model laat al vroeg zien dat digitale vergankelijkheid niet alleen ontstaat wanneer een moderne cloudserver wordt uitgezet. Software kan ook verdwijnen doordat distributie, uitbreidingen en de uitvoeromgeving bewust zo met elkaar zijn verbonden dat een lokaal bewaard bestand op zichzelf niet voldoende is.
Dezelfde vragen raken ook aan privacy en gegevensbeheer. In de jaren rond de opkomst van grootschalige elektronische communicatie, centrale patiëntendossiers en Europese regels rond het bewaren van communicatiegegevens werd steeds zichtbaarder dat technische systemen niet alleen bepalen wat een gebruiker zelf kan doen, maar ook wat organisaties over die gebruiker kunnen verzamelen, bewaren, koppelen en opvragen.
Dat is niet hetzelfde onderwerp als het repareren van een apparaat, maar de onderliggende vraag naar zeggenschap is verwant. Wie bepaalt wat een technisch systeem doet? Welke informatie is beschikbaar voor de gebruiker zelf? Welke informatie gaat juist naar anderen? Welke keuzes zijn technisch noodzakelijk en welke zijn het gevolg van beleid, contracten of ontwerpbeslissingen?
Daarmee komt eigenaarschap dicht bij verantwoordelijkheid. Meer zeggenschap betekent niet alleen meer vrijheid om een systeem te veranderen, maar ook de verantwoordelijkheid om na te denken over veiligheid, privacy, gevolgen voor anderen en de omstandigheden waarin een aanpassing wordt gebruikt.
De huidige Right to Repair-beweging sluit op een belangrijk deel van Repair and Ownership aan. Toegang tot onderdelen, gereedschap, schema’s, diagnosefuncties, firmware en reparatie-informatie is essentieel wanneer eigenaren en onafhankelijke reparateurs producten daadwerkelijk moeten kunnen onderhouden.
De moderne georganiseerde beweging rond digitale elektronica kreeg vanaf de jaren 2010 steeds meer zichtbaarheid en de discussie werd breed herkenbaar bij smartphones, laptops en andere consumentenelektronica. Inmiddels speelt dezelfde problematiek nadrukkelijk bij voertuigen, landbouwmachines, huishoudelijke apparatuur, camera’s en vele andere producten.
Repair and Ownership is daar echter niet uit ontstaan en valt er niet mee samen. Het project stelt een bredere vraag. Een apparaat kan uitstekend repareerbaar zijn en toch weinig praktische zeggenschap bieden wanneer de eigenaar geen eigen software mag installeren, afhankelijk blijft van een cloudaccount, functies op afstand kunnen verdwijnen of gekochte digitale inhoud alleen beschikbaar blijft zolang een derde partij toestemming geeft.
Right to Repair is daarom een belangrijk onderdeel van de eigendomsvraag, maar niet de volledige eigendomsvraag.
Praktisch eigenaarschap betekent voor Repair and Ownership niet dat iedere technische beperking automatisch verkeerd is of dat iedere eigenaar alles zonder kennis, verantwoordelijkheid of gevolgen moet kunnen veranderen. Een remsysteem, medische installatie, hoogspanningsapparaat of beveiligingssysteem stelt andere eisen dan een bureaulamp of mediaspeler.
Veiligheid, aansprakelijkheid, privacy van anderen, interoperabiliteit en wettelijke eisen kunnen legitieme grenzen stellen. Het belangrijke onderscheid is of een beperking noodzakelijk en uitlegbaar is, of vooral wordt gebruikt om afhankelijkheid af te dwingen, concurrentie uit te sluiten of controle te behouden over een product nadat het is verkocht.
Vrijheid en verantwoordelijkheid horen daarbij bij elkaar. Werkelijke zeggenschap vraagt om toegang tot kennis en mogelijkheden, maar ook om voldoende begrip om bewuste keuzes te kunnen maken en de gevolgen daarvan te dragen.
Repair and Ownership is een project van ASK-Solutions. Het project geeft praktische vorm aan vragen die vanaf het begin belangrijk zijn binnen de stichting: wat vrijheid en eigenaarschap betekenen, hoe kennis macht en afhankelijkheid kan beïnvloeden, welke verantwoordelijkheid bij zelfstandigheid hoort en hoeveel zeggenschap mensen en organisaties over de systemen in hun leven moeten kunnen behouden.
Techniek maakt deze vragen bijzonder zichtbaar. Een technisch systeem dwingt abstracte begrippen tot concrete keuzes. Is documentatie beschikbaar of geheim? Kan een onderdeel worden vervangen of alleen door een fabrikant worden gekoppeld? Werkt een apparaat zonder internetverbinding? Wie bezit de sleutel waarmee software wordt toegelaten? Kan iemand een fout onderzoeken? Wie beslist wanneer een product niet meer ondersteund wordt?
Andere projecten van ASK-Solutions kunnen vanuit hun eigen doel en vorm met delen van dezelfde vragen te maken krijgen. In Bōzuki wordt bijvoorbeeld praktisch onderzocht wat het betekent om een complex voertuig te begrijpen, aan te passen en documenteerbaar te houden. Op locaties waar ASK-Solutions het deelbare werkmodel van het project The Owl’s Nest uitvoert, kunnen reparatie, onderzoek en kennisoverdracht praktisch plaatsvinden. Vrije-softwareprojecten zoals Nocterra laten op een ander terrein zien waarom toegang tot broncode, overdraagbaarheid en onafhankelijkheid van één leverancier van belang kunnen zijn.
Die projecten zijn geen onderdelen van Repair and Ownership. Zij kunnen vanuit hun eigen projectdoel wel concrete situaties opleveren waarin dezelfde vragen over kennis, afhankelijkheid, reparatie en eigenaarschap zichtbaar worden.
Repair and Ownership is een doorlopend project. De onderliggende vragen veranderen mee met techniek, wetgeving, contractvormen en bedrijfsmodellen. Waar beperkingen vroeger bijvoorbeeld zichtbaar waren in ontbrekende schema’s of gesloten servicenetwerken, kunnen zij tegenwoordig ook zitten in firmware, accounts, cloudplatforms, cryptografische sleutels, digitale licenties en abonnementen.
ASK-Solutions volgt zulke ontwikkelingen, bespreekt en documenteert voorbeelden, ondersteunt waar passend initiatieven rond gebruikersrechten en reparatie en gebruikt praktische projecten om te onderzoeken wat technische zeggenschap in concrete situaties betekent.
Copyright © 2026, ASK-Solutions
