Afgezien van de vraag welke sourcecode-editor de beste is, zijn er weinig onderwerpen die onder software-ingenieurs fellere discussies opleveren dan de vraag of software octrooieerbaar moet zijn. Dat geldt vooral in Europa, waar het Europees Octrooiverdrag van 1978 (EOV) octrooien op ‘computerprogramma's als zodanig’ uitdrukkelijk verbiedt.
Arnoud Engelfriet
Mr. ir. Arnoud Engelfriet is ict-jurist, gespecialiseerd in internetrecht. Hij is algemeen directeur bij juridisch adviesbureau ICTRecht en al jaren actief op Tweakers.
Waar onder het Europese octrooirecht strenge eisen gelden ten aanzien van het technisch karakter en de inventiviteit van een uitvinding, kan in de VS overdwars schommelen al worden gepatenteerd. De opvatting daarachter is weliswaar achterhaald sinds de Alice-uitspraak van het Supreme Court, maar het idee dat in de VS veel meer mogelijk is, blijft hardnekkig.
Wat precies een software-octrooi is, blijft een lastige vraag. Velen hebben geprobeerd tot definities te komen, maar omdat het debat rond software-octrooien niet zuiver juridisch is, is dit buitengewoon moeilijk. Zo spreken voorstanders van software-octrooien graag van ‘computer-geïmplementeerde uitvindingen’ om te benadrukken dat software slechts een implementatiedetail is en het uiteindelijk om de uitvinding als zodanig gaat. Tegenstanders classificeren ieder octrooi dat ergens een algoritme of computerprogramma noemt vaak al als een software-octrooi. Pragmatisch kun je spreken van een software-octrooi wanneer de uitvinding voor een belangrijk deel leunt op software of de facto met standaard hardware wordt gerealiseerd. Als je onderzoek leest over softwarepatenten, werken ze meestal met sets trefwoorden en/of geselecteerde octrooiklassen.
Statutory subject matter
De Amerikaanse octrooiwetgeving uit 1952 definieert (in 35 USC 101) vier categorieën zaken die voor octrooi in aanmerking komen: een proces, een machine, een product en een voortbrengsel. Alleen als een octrooiclaim onder een van deze vier categorieën kan worden gebracht, is er sprake van statutory subject matter dat - indien het nieuw en niet voor de hand liggend is - als octrooi kan worden beschermd. Men kent daarbij geen expliciet techniekcriterium: “anything under the sun that is made by man” is in beginsel vatbaar voor octrooi.
De eerste zaak waarin een uitspraak werd gedaan over de vraag of software binnen deze grens valt, was Gottschalk v. Benson (1972). In deze zaak bepaalde het Supreme Court dat software niet octrooieerbaar is omdat het om niet meer gaat dan algoritmes, oftewel abstracte zaken. Vereist was dat de uitvinding een nieuw apparaat opleverde of zorgde voor een transformatie van een product of voortbrengsel in iets anders; de zogeheten “machine or transformation”-test. Deze test werd in de praktijk het handvat om uitvindingen in algemene zin te toetsen aan het criterium van statutory subject matter. Iets later bepaalde de Flook-uitspraak dat een niet voor de hand liggende fysieke implementatie van een algoritme wel voor octrooi in aanmerking kwam. Men had dan immers niet het algoritme zelf geoctrooieerd.
Rond die tijd werd ook gewerkt aan een Europees octrooi. De Europese Economische Gemeenschap bleek niet in staat om hierover tot een compromis te komen, vandaar dat Nederland, België, Duitsland, Frankrijk, Luxemburg, Zwitserland en het VK besloten het apart te regelen: het Europees Octrooiverdrag (EOV) werd geboren in 1973.
Hier moest ook iets in komen te staan over software en algoritmen, maar daar kwam men eigenlijk niet uit. Dankbaar sloot men dan ook aan bij het internationale Octrooisamenwerkingsverdrag (Patent Cooperation Treaty – PCT) dat in die tijd werd opgesteld. De opstellers daarvan hadden een pragmatisch excuus: doordat het terrein van de computerprogrammering nog maar een paar decennia oud was, bestond er weinig documentatie over softwaretechnieken en innovatie. Het doel van het PCT, namelijk een snel wereldwijd onderzoek naar de haalbaarheid, zou dan niet mogelijk zijn. Daarom sloot men software uit. Bij het EOV kwam dit in de tekst te staan als “software als zodanig”, en ik heb nog steeds de schuldige niet kunnen vinden die dat heeft getypt.
:strip_exif()/i/2005058718.jpeg?f=imagenormal)
Het algoritme te boven
Het Europees Octrooibureau, dat de octrooi-aanvragen onder het EOV moest beoordelen, hield het in die tijd nog bij een rechtlijnig standpunt: “Indien de bijdrage aan de stand der techniek uitsluitend door een computerprogramma wordt geleverd, is het onderwerp niet octrooieerbaar, ongeacht de wijze waarop het in de conclusie gepresenteerd wordt.” Er moest echt een hardwarematige verbetering in zitten. Dat sloot aardig aan bij de Amerikaanse beoordeling, de zogeheten Freeman-Walter-Abele-toets. Kort gezegd kwam deze toets erop neer dat men eerst moet kijken of de claim iets abstracts benoemt, zoals een wiskundig algoritme. Als dat zo is, is de volgende vraag of men het algoritme als zodanig te boven gaat en de claim beperkt tot een concrete, praktische toepassing in een proces of fysiek, concreet apparaat. In dat geval is de uitvinding niet slechts het abstracte algoritme maar een concreet statutory process of machine.
Een kleine tien jaar later bleek er toch enige ruimte te zijn voor uitvindingen waarin software een rol speelt. In Amerika bepaalde het Supreme Court in de Diamond v. Diehr-uitspraak (1981) dat een uitvinding ook octrooieerbaar kon zijn wanneer software daar een belangrijk deel van vormde. In deze zaak ging het om een proces voor het uitharden van rubber, waarbij een (op zich bekende) formule werd gebruikt om het beste tijdstip te kiezen om het proces te beëindigen. Deze formule vereiste echter een regelmatige controle van de temperatuur van het rubber, hetgeen volgens de uitvinding werd gerealiseerd door in het uithardvat een aantal sensoren op te nemen. Een computer berekende na elke sensormeting of aan de formule was voldaan.
:strip_exif()/i/2005058726.jpeg?f=imagenormal)
Enkele jaren later volgde het EOB dezelfde route: men besloot dat het beter zou zijn het effect van de uitvinding in z'n geheel te onderzoeken. Als dat effect een technologische vooruitgang vertegenwoordigde, zou de uitvinding in principe octrooieerbaar zijn. Met andere woorden, het maakte niet meer uit of de uitvinding ingebouwde software was of gebruikmaakte van specifieke hardware. Wat er wel toe deed, was het resultaat: was er een ‘technisch effect’? Nu konden software-innovaties geoctrooieerd worden, mits zij deel uitmaakten van een concreet apparaat, bijvoorbeeld een mobiele telefoon, dat van de innovatie profiteerde. Niet gek dus dat in die tijd de gepatenteerde standaarden voor gsm en mpeg opkwamen.
Aankleden met hardware
In de jaren negentig veranderde er veel. Het Federale Beroepshof versoepelde de grenzen voor software fors door te bepalen dat software op een standaardcomputer of andere bekende hardware in beginsel octrooieerbaar was. Een jaar later werd bepaald dat een drager zoals een floppydisk voldoende specifiek was, zodat software op deze drager geoctrooieerd kon worden en dus niet enkel software geïnstalleerd op een computer, telefoon of ander apparaat. Daarmee werd het octrooieren van softwarezaken in feite onbeperkt mogelijk. Een bekende kritiek uit die tijd luidt dan ook dat de octrooieerbaarheid van een software-uitvinding meer afhing van de kwaliteit van de octrooigemachtigde dan van een echt juridisch criterium.
In die tijd werden ook de grenzen van het software-auteursrecht getrokken. In Apple vs. Microsoft (1994) kreeg Apple te horen dat het geen auteursrecht kon claimen op concepten als titelbalken op vensters, iconen voor bestanden en mappen, of een prullenbak voor zaken die verwijderd moesten worden. Kort daarna werd in Lotus vs. Borland (1996) bepaald dat de look and feel van een spreadsheetprogramma eveneens niet auteursrechtelijk beschermd kon worden. Hiermee waren voor bedrijven de mogelijkheden flink beperkt om middels auteursrecht imitatie van hun software tegen te gaan. Het lijkt erop dat deze bedrijven vervolgens op zoek gingen naar alternatieven en uitkwamen bij het octrooirecht, wat mede zou verklaren waarom het octrooieren van software in die tijd sterk toenam.
Tijd voor e-commerce-octrooien
De State Street Bank-uitspraak gooide in 1998 alle remmen los. Niet langer was het nodig een “machine or transformation” te laten zien; voldoen aan het criterium van ‘useful, concrete and tangible’ was voldoende. Zodra een algoritme een uitkomst opleverde die betekenis had in de ‘echte wereld’ - zoals een totaalprijs of de waarde van een aandelenportfolio - kon al gesproken worden van een dergelijk ‘useful, concrete and tangible’ resultaat. En passant merkte het Hof tevens op dat men de ‘ill-conceived’ gedachte dat business methods niet octrooieerbaar zijn bij dezen ten grave droeg. En dat had men misschien niet moeten zeggen.
De uitspraak kwam precies op het goede moment voor de internet-boom, een explosie van nieuwe en innoverende internetdiensten op zoek naar marktaandeel en investeerders. Al deze innovaties waren nieuw en gebruikten software om tot iets concreets te komen, zodat zij onder State Street Bank in beginsel stuk voor stuk voor octrooi in aanmerking kwamen. Daarbij wreekte zich de afwezigheid van de benodigde databases met moderne techniek om hun nieuwheid te toetsen, plus het maximum van zo'n acht uur voor het onderzoeken en beoordelen van een octrooi-aanvraag dat het Uspto zichzelf had opgelegd. De kwaliteit van deze octrooien was dan ook berucht laag. Toch werden veel van deze octrooien in de rechtbank gehandhaafd en actief afgedwongen, waarmee voor velen werd bewezen dat software-octrooien een substantiële bedreiging vormden voor innovatie op het gebied van software.
Ook in Europa werd er stevig op gehamerd dat men meer ruimte wilde voor octrooien op software. Met name IBM, dat in Amerika al jaren een van de grootste portfolio’s op dit gebied had, deed zijn uiterste best. Dit culmineerde in 1998 in twee besluiten van het EOB. Leeswaarschuwing: juridische hoofdpijn. De redenering was dat de uitsluiting van ‘software als zodanig’ gericht was op het voorkomen van octrooien op niet-technische items (omdat het in het EOV was opgenomen in de lijst van niet-technische items), zodat octrooien op software mogelijk waren, mits de software op de een of andere manier een specifiek technisch resultaat opleverde. Bovendien konden die octrooien worden verkregen voor de software zelf, aangezien ‘technische software’ geen ‘software als zodanig’ was, zelfs niet als zij losgekoppeld was van concrete apparaten zoals telefoons of televisies.
Raar, maar of het stand zou houden bij de rechter bleef de vraag. In Europa gold namelijk de regel dat ieder land zijn eigen jurisprudentie en toetsingskader voor octrooien heeft, ook als het EOB het octrooi heeft toegewezen. Met name in Duitsland waren de regels streng. Die gekke IBM-jurisprudentie was daar lijnrecht mee in strijd, maar omdat rechters winnen van octrooiverleners zou dit geen probleem moeten zijn.
Het Europese softwarepatent
In 2002 kwam de Europese Commissie echter plotseling met een voorstel voor een richtlijn die moest vaststellen wanneer ‘in computers geïmplementeerde uitvindingen’ octrooieerbaar zouden zijn. Nogal een verrassing, omdat de Europese Gemeenschap al bijna zolang zij bestond had geworsteld met het octrooirecht. Het EOV was immers geboren uit het ruim dertig jaar durende onvermogen van de Gemeenschap om tot overeenstemming te komen over één Europees octrooi. Het was dan ook op z'n minst opmerkelijk dat de Commissie, die het zelfs niet eens kon worden over de meest fundamentele principes, met een richtlijn kwam om een obscuur gedeelte van het octrooirecht te regelen.
Nog opmerkelijker was de inhoud van het voorstel voor deze richtlijn. De Commissie stelde voor de interpretatie van 1998 van het EOB van ‘software als zodanig’ in regels vast te leggen en zo elke lidstaat van de Gemeenschap te dwingen een interpretatie van het octrooirecht te accepteren die zelfs bij het EOB en in de industrie controversieel was, en die bovendien in verschillende lidstaten in strijd was met de jurisprudentie.
Dat gaf de nodige ophef. De Europese software-industrie had tientallen jaren succesvol kunnen opereren zonder octrooibescherming, zo voerde zij aan. Veel van deze bedrijven waren mkb'ers die niet over voldoende middelen beschikten om octrooien aan te vragen of octrooihouders de royalty's te betalen waar ze voor vreesden. Wetenschappers voerden aan dat het economisch effect van octrooien op software niet bekend was. Het onderwerp raakte vooral een gevoelige snaar bij de opensource-beweging, die was opgericht in de overtuiging dat software voor iedereen vrij te gebruiken moest zijn en dat intellectuele eigendomsrechten die deze vrijheid beperkten, moesten worden uitgebannen. Deze beweging van gewone mensen was in de afgelopen decennia snel op stoom gekomen en had een deel van de beste software geproduceerd die nu in gebruik is, allemaal gratis beschikbaar en met onbeperkte gebruiksrechten.
Zo begon een nog nooit eerder vertoonde intensieve lobby van gewone mensen. De meeste tegenstanders organiseerden zich rondom de zogenoemde Foundation for a Free Information Infrastructure (FFII), een Duitse non-profitorganisatie die enorme hoeveelheden documentatie, juridische argumenten, gespreksonderwerpen en promotiemateriaal voor software-ingenieurs beschikbaar stelde.
Deze beweging boekte een geweldig eerste succes: op 24 september 2003 overtuigde zij het Europese Parlement ervan dat de richtlijn op z'n kop moest worden gezet. Elke uitvinding waaraan gegevensverwerking te pas was gekomen, zou nu worden uitgesloten van octrooieerbaarheid, ongeacht het technologische karakter ervan. Bovendien zouden octrooi-aanvragen voor softwaregerelateerde uitvindingen een volledige implementatie van de uitvinding in sourcecodevorm moeten bevatten, die gratis in licentie zou moeten worden gegeven zodra het octrooi zou aflopen. Er was ook een algemene regel om te voorkomen dat octrooien werden gebruikt om een einde te maken aan de interoperabiliteit tussen computersystemen.
Dit leidde tot protesten van veel Europese octrooihouders, die vreesden dat zo'n twee derde van hun octrooiportefeuille plotseling ongeldig zou worden door die benadering. Gegevensverwerking en interoperabiliteit zijn extreem fundamentele concepten en als die niet door octrooien gedekt kunnen worden, kunnen er net zo goed helemaal geen octrooien zijn. Bovendien keerde het voorstel ook de ‘technisch effect’-leer om, die sinds medio jaren tachtig gold. Innovaties in mobiele telefoons of telefonie, die tegenwoordig bijna volledig vertrouwen op software voor nieuwe features, zouden hun geoctrooieerde status verliezen.
Geen bananenunie
De Europese wetgevingsprocedure is uitermate complex. De Commissie kan richtlijnen voorstellen die van de lidstaten vereisen dat zij hun nationale wetgeving daar op een bepaalde manier op afstemmen. Dergelijke voorstellen moeten worden goedgekeurd door het Parlement en de Raad van Ministers voordat zij van kracht worden. Iedereen richtte zich nu dus tot de Raad van Ministers en nu was het de industrie die een punt scoorde: lobbyisten slaagden erin de Raad ervan te overtuigen dat zij een compromisversie van de richtlijn moesten opstellen die in wezen alle wijzigingen van het Parlement terugdraaide en weer voorzag in octrooien op ‘technische software’.
:fill(white):strip_exif()/i/2005058778.jpeg?f=imagemedium)
Het lobbywerk achter de schermen en geruchten over schaduwafspraken bewogen de FFII-aanhangers ertoe naar een protestbijeenkomst in Brussel te komen met posters met de tekst ‘Geen bananenunie, geen software-octrooien!’, uiteraard met gratis bananen. Het debat en het lobbywerk werd vervolgens gericht op het Europees Parlement, dat nu aan zet was: het compromis van de Raad aanvaarden, nieuwe wijzigingen voorstellen of de richtlijn verwerpen? Het verder lobbyen vanaf beide zijden resulteerde in verschillende inefficiënte voorstellen, e-mailbombardementen aan parlementsleden, wederzijdse beschuldigingen van ondemocratische achterkamerdeals, nationale parlementen die publiekelijk de strijd aanbonden met hun ministers, en ruim 60.000 Google-hits voor ‘software patent’, de meeste erg negatief.
Op 6 juli 2005 besloot het Europees Parlement dat het er genoeg van had en verwees het de hele zaak naar de schroothoop, met 648 stemmen vóór, van de 729 stemmen in totaal. Beide partijen beschouwden het besluit als een overwinning. FFII en collega’s hadden ‘Europese software-octrooien voorkomen’ en voorstanders van het octrooi waren blij dat er geen octrooi-onvriendelijke regels waren gekomen. Ondertussen ging het EOB gewoon door, maar omdat minder dan 0,1 procent van alle octrooien ooit tot rechtszaken kwam, waren er - althans voor juristen - in de praktijk geen noemenswaardige veranderingen.
Alice, of het afschieten van software-octrooien
Dat wil niet zeggen dat alles bij het oude bleef. In de vijftien jaar na State Street Bank nam de kritiek op de octrooiverleningspraktijk van het Uspto steeds meer toe. Software-octrooien zouden (ondanks vele extra prior art-databanken en ingehuurde examiners) veel te makkelijk worden toegekend, een te brede scope kennen en de industrie alleen maar hinderen. Zo worden verleningspercentages van meer dan 80 procent genoemd (dat is driemaal zo hoog als in Europa), tegen zo’n 54 procent in het algemeen. Het ligt voor de hand dat zulke aantallen wel tot slechte kwaliteit octrooien moeten leiden.
Ook van belang was het fenomeen van de octrooitrol. Een octrooitrol is een bedrijf dat niet zelf een uitvinding op de markt brengt en zichzelf beschermt met een octrooi, maar als enige bedrijfsactiviteit het uitoefenen van zijn octrooien tegen derden heeft. Vaak zijn deze octrooien, of de claims jegens derden die men daarmee legt, van dubieuze waarde. De meeste bedrijven schikken echter toch, omdat octrooiprocedures in de VS tot de duurste ter wereld behoren en vele jaren kunnen duren. Bovendien kennen zij in beginsel geen proceskostenveroordeling voor de verliezende partij, zodat een bedrijf zelfs bij een overwinning meer kosten kwijt kan zijn dan het door de trol geëiste schikkingsbedrag.
De druk om iets te doen aan softwarepatenten leidde begin jaren tien tot een aantal rechtszaken die tot aan het Supreme Court werden uitgevochten. Na twee uitspraken die geen duidelijke lijn formuleerden, kwam het hoogste Amerikaanse gerechtshof in 2014 eindelijk met de gewenste harde streep. De uitvinding in deze zaak betrof een procedure om betalingen in het handelsverkeer efficiënter en betrouwbaarder te maken door inzet van een escrow-agent. Inzet van een dergelijke agent (zoals een notaris) is natuurlijk al lang bekend, maar volgens eiser Alice Corporation was de door hem geclaimde computerimplementatie statutory, nieuw en niet voor de hand liggend. De interesse voor de zaak was groot. Nadat de zaak door het Supreme Court was aangenomen, volgden tientallen amicus curiae-petities met diverse betogen waarom dit octrooi ongeldig zou moeten worden verklaard.
Het Supreme Court formuleerde een framework voor octrooieerbaarheid. Allereerst: bevat de claim een abstract idee, algoritme of ander generiek principe? Ten tweede: voegt de claim ‘something extra' toe dat als ‘inventive concept' kan worden gekwalificeerd? Hierbij geldt expliciet dat enkel de toevoeging van een generieke computerimplementatie niet genoeg is, net zo min als een beperking tot een specifiek toepassingsgebied.
Alice heeft geleid tot een ware kaalslag in het softwarepatentgebied. Diverse onderzoeken laten zien dat het aantal dossiers met afwijzingen met een Alice-bezwaar van gemiddeld zo’n 30 procent naar meer dan 85 procent is gestegen. Het aantal verleende octrooien in deze vakgebieden is overeenkomstig gekelderd, tot minder dan 10 procent sinds Alice, tegen 20 tot 30 procent in de drie jaren daarvoor. In sommige deelgebieden worden zelfs vrijwel geen octrooien (<2 procent) meer verleend. Ook bij de rechter heb je echt pech: in meer dan 70 procent van alle octrooirechtszaken waarin op deze grond een octrooi werd aangevochten, werd het octrooi ook daadwerkelijk als non-statutory ongeldig verklaard. In hoger beroep gaat het zelfs om 92 procent van de zaken.
Matter of law
Een belangrijke reden voor dit grote aantal afwijzingen bij de rechter is de procedurele kant van de zaak. Onder het Amerikaans octrooirecht wordt de geldigheid van een octrooi gezien als een matter of fact en derhalve iets voor de jury om te beslissen. Dit is een langdurig en onzeker proces, omdat de jury gewoonlijk weinig kaas heeft gegeten van de techniek en dus moeilijk kan inschatten of een uitvinding iets innovatiefs is ten opzichte van de stand der techniek. Dit is echter anders bij de vraag of een octrooi statutory subject matter betreft. Dit is een matter of law en dus door de rechter zelf te beslissen. Deze beslissing kan al in een (veel) vroeger stadium worden genomen, meer specifiek voordat de kostbare, langdurige en complexe discovery-procedure gevoerd gaat worden die veel partijen afschrikt en doet afzien van een octrooiprocedure. Wie vóór Alice in een octrooiprocedure werd betrokken, moest kiezen tussen een langdurige en kostbare procedure of een schikking. Wie dat ná Alice overkomt, kan kiezen voor de snelle en relatief goedkope tegenaanval op statutory-gronden. Gespeculeerd wordt dan ook al dat Alice een gevoelige slag is voor octrooitrollen, hoewel de cijfers een jaar na Alice lijken te suggereren dat niet elke trol zo makkelijk van tafel is te krijgen.
Een inhoudelijke reden voor het succes van deze tegenaanval is het feit dat veel software-octrooien in de praktijk niet veel meer zijn dan een abstract idee waarbij niet nader gespecificeerde software een generieke implementatie daarvan vormt. Deze praktijk is verklaarbaar door de eerdere jurisprudentie van rechtbanken en het beroepshof, die immers niet veel meer eiste dan een koppeling met hardware (‘een computer voorzien van een opslagmedium met instructies voor het uitvoeren van algoritme X’) en zelden tot nooit ter discussie stelde of het resultaat wel useful, concrete and tangible was - dat was onder State Street Bank immers vrijwel altijd wel het geval. Maar wie zijn aanvraag opstelde conform deze ervaringsregels, zag zijn octrooi (of aanvraag) reddeloos verloren gaan onder de Alice-criteria.
Ondertussen in Europa
Het EOB ging gewoon door, schreef ik daarstraks. Dat zat de octrooi-onderzoekers niet lekker, maar het duurde enkele jaren voordat de benodigde botte bijlen werden ontwikkeld om van de toestroom van software-octrooien-Amerikaanse-stijl af te komen. Het criterium van de ‘inventieve stap’ werd aanzienlijk verscherpt, waardoor de meeste aanvragen voor software- of e-commerce-octrooien gemakkelijk konden worden geweigerd. Hoewel er nog steeds slechte octrooien worden verleend, is het aantal aanzienlijk lager dan begin deze eeuw. Met deze uitspraken lopen Europa en de VS in ieder geval niet erg meer uit de pas.
In de verschillende Europese landen loopt de situatie nogal uiteen. In een paar landen, waaronder met name Duitsland, wordt de EOB-interpretatie door de rechtbanken als rechtsgeldig erkend. De Britse rechtbanken hebben echter voor een andere interpretatie gekozen. De meeste andere landen hebben het onderwerp nog helemaal niet bij de hand gehad, dus niemand weet hoe Europese octrooien op software-uitvindingen daar zullen worden behandeld. Ondertussen zal geen enkele politicus in de nabije toekomst zijn vingers aan het onderwerp willen branden. Wil je weten waarom? Ga dan eens bij je developers langs en vraag hen: ‘Wij zijn voorstander van software-octrooien. Wat vind jij daarvan?'
Bannerfoto: Bubushonok / Getty Images
:strip_icc():strip_exif()/i/2006310574.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2005476196.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2005425482.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2005357176.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2005255846.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2005184338.jpeg?f=fpa_thumb)
:strip_icc():strip_exif()/i/2005121216.jpeg?f=fpa_thumb)
/i/2004997620.png?f=fpa_thumb)
Het monopolie dat Apple daarvoor krijgt is dan ook beperkt tot die toepassing. Hoewel dat vervelend is voor andere smartphone-bouwers, hebben die er zeker ook die Apple pijn (kunnen) doen.
:strip_icc():strip_exif()/u/145751/check-in-minion-small2.jpg?f=community){kind=small}
:strip_icc():strip_exif()/u/140379/Hond_icon.jpg?f=community){kind=icon}
/u/237439/kerstmuts02.png?f=community){kind=small}
/u/1702/crop6457f8805fee9.png?f=community){kind=small}
:strip_icc():strip_exif()/u/417493/crop58174774d1256.jpeg?f=community){kind=small}