Auteursrecht op programmeertalen kan niet (of je moet wel heel creatief zijn)

little-sas-boek.jpgOp programmeertalen (en dataformaten) rust geen auteursrecht. Ietwat kort door de bocht, maar dat is wel zo ongeveer wat het Hof van Justitie bepaalde in haar arrest van gisteren. Kort door de bocht, want het kán wel, maar het is zeker geen automatisme.

In deze zaak ging het om een interpreter voor de SAS taal. Deze taal is ooit door SAS ontwikkeld als onderdeel van hun analysesoftware, en het bedrijf WPL besloot een eigen interpreter (emulator) te maken die programma’s in die taal kon verwerken zonder dat je SAS nodig had. Dat vond SAS niet leuk, en dus werden de advocaten losgelaten: een beetje iemands taal interpreteren, dat is auteursrechtschending, wat zullen we nou krijgen. (Ok, én de handleidingen overtypen, dat ook, maar daar ging het bij het Hof niet om.)

Het Hof grijpt de gelegenheid aan om er eens goed voor te gaan zitten: wat betekent dat nu eigenlijk, auteursrecht op software. Want software is altijd een probleemkindje geweest in het auteursrecht. Vanaf het begin waren de meningen verdeeld of software -toch een nogal utilitair product- wel onder het auteursrecht -toch voor creatieve kunstzinnige uitingen- gerekend moest worden. Het octrooirecht lag meer voor de hand, alleen dan zou 95% van de software niet beschermbaar zijn en dat was dan ook weer niet de bedoeling. Uiteindelijk is het opgelost door gewoon te zeggen “software is een creatief werk, punt”.

Maar ja, in het recht is “punt” nóóit het einde van een discussie. We gaan gewoon vrolijk verder over wat die punt dan betekent, hoe je ‘m kunt oprekken, of het eigenlijk geen puntkomma had moeten zijn en welk punt ermee gemaakt wordt.

Auteursrecht op software geldt niet voor de user interface, weet u nog? Het Hof kwam in 2010 tot die conclusie met het argument dat software een werk is dat de computer iets laat dóen, en de interface als zodanig dóet niets. De interface is alleen beschermd als ‘ie kunstzinnig is (overigens heb ik een *****-hekel aan kunstzinnige interfaces want de knoppen zitten nooit waar ik wil en keyboard shortcuts heb je al helemaal niet), en niet enkel omdat ‘ie aan een computerprogramma hangt.

Die lijn trekt het Hof nu door: het moet echt gaan om de broncode en/of objectcode als zodanig (argh), en van inbreuk kan dus pas sprake zijn als een van die twee ergens terug te vinden is in het werk van de ander. Letterlijk of niet-letterlijk, maar het moet er wel zijn.

De functionaliteit, de programmeertaal en de bijbehorende bestandsformaten zijn geen deel van de code, maar zijn meer achterliggende ideeën of uitgangspunten waarmee je die code maakt. En dus vallen ze buiten het werk als zodanig.

En ja, dat is ook de bedoeling, aldus het Hof:

to accept that the functionality of a computer program can be protected by copyright would amount to making it possible to monopolise ideas, to the detriment of technological progress and industrial development.

Wat daarmee niet kan, is mensen verbieden om dit formaat of de taal te achterhalen middels reverse engineeren. Dit kan niet op grond van het auteursrecht, en ook niet op grond van een licentiecontract. Want dat is namelijk de truc: je geeft een licentie op de software zelf (de broncode of objectcode dus) en daarin bepaal je dat je oh ja de programmeertaal niet mag reverse engineeren.

Eventueel is het mogelijk dat een creatief uitgewerkt dataformaat als zodanig wél beschermd is, maar dan moet er dus in dat formaat zélf iets creatiefs aan te wijzen zijn. Net als die kunstzinnige interface. Dat kan, maar is niet eenvoudig. Ik herinner me van lang geleden een anti-spam truc waarbij je een licentie op een haiku moest nemen om je mail geaccepteerd te krijgen (met als algemene voorwaarde “ik verstuur geen spam”). Dat is dus op zich een auteursrechtelijk houdbare constructie, maar wel redelijk gezocht. Ik durf dus wel te zeggen “auteursrecht op programmeertalen en -concepten kan niet”, maar ik ben heel benieuwd welke argumenten softwareauteursrechthebbenden gaan verzinnen om hier toch tegenin te gaan.

Arnoud

36 reacties

  1. > ik ben heel benieuwd welke argumenten softwareauteursrechthebbenden gaan verzinnen om hier toch tegenin te gaan

    Ehh, slaafse nabootsing, merken op instructies, databank bescherming, onrechtmatig profiteren, aanhakings jurisprudentie, eenlijnsprestaties, derde werking licentie contracten, TV-format bescherming, sweat-of-the-brow doctrine.

    Vergeet ik nog wat?

  2. Dezelde discussie is nu bezig rondom Java. Dat op een taal geen auteursrecht kan rusten is vrij evident, maar een taal komt met een standaard library voor device toegang, kernel functies en utility functies. En dat die vrij is van rechten is wat meer omstreden.

    http://computerworld.nl/article/13682/copyright-op-api-s-een-gevaarlijke-claim

    Leuk detail is dat deze discussie twee kanten heeft. Als Oracle dit probeert dan zijn ze gemeen (overigens ben ik het daar mee eens) maar als WordPress claimt dat hun API open source is en dat dit zelfs doorwerkt in alle plugins die tegen deze API aan zijn geprogrammeerd dan zit bijna niemand daarmee (wat ik weer vreemd vind).

    http://mixergy.com/chris-pearson-matt-mullenweg/

  3. als WordPress claimt dat hun API open source is en dat dit zelfs doorwerkt in alle plugins die tegen deze API aan zijn geprogrammeerd dan zit bijna niemand daarmee (wat ik weer vreemd vind).

    Nouja, daar is al menig discussie over gevoerd binnen de FOSS gemeenschap.

    Ik had de indruk dat de rechtzaak in hierover in de US duidelijk was: de rechter had de jury instructie gegeven aan te nemen dat API’s copyrightable was, en daarmee was voor mij de uitkomst van de rechtzaak duidelijk (meende ik als betrekkelijke noob).

    Echter, er blijken verstandige rechters te zijn in de US, zoals deze. Deze lijkt bereid te kijken naar zijn collega’s van het Europese Hof van Justitie. De beste man stelt beide partijen enkele (m.i.) zeer legitieme vragen, en het speelveld lijkt inmiddels weer open te liggen. Los daarvan hint de jury er op dat zij geen unaniem besluit gaan kunnen nemen (dan krijg je alsnog je juryvergoeding neem ik aan?).

    Overigens ben ik benieuwd of wanneer Oracle in het gelijk gesteld zou worden zij ook niet een probleem gaat krijgen. Er zijn ongetwijfeld overeenkomsten tussen Java en een taal als C. Zeker op gebieden van I/O, networking sockets, etc. Ben benieuwd of er niet legio partijen zijn die vervolgens weer bij Oracle kunnen aankloppen voor een miljarden grote schadeclaim (welke uiteindelijk gereduceerd wordt tot een paar tientjes + een punitieve boete van een paar miljoen).

  4. @Richard: het argument dat als je plugin tegen aan API praat, deze automatisch de licentie van de library achter die API moet overnemen vind ik weerzinwekkend. Maar elke discussie daarover lijkt door de FSF de kop ingedrukt te worden, want als dit niet zo zou zijn verdwijnt de “virale” werking van de GPL en staat het hele idee achter de GPL op losse schroeven. Ik ben Richard Stallman erg dankbaar voor zijn activisme en voor de GPL, maar persoonlijk zou ik liever willen dat er iets minder bezitterig met intellectuele eigendomsrechten om zouden gaan.

    Ik ben zelf erg benieuwd of het hof een dergelijke redenering ook zou ophouden over data formaten, netwerkprotocollen en andere standaarden. Ik ben zelf actief in wat standardisatieorganisaties met een vrij open cultuur, maar er zijn nog genoeg standardisatieorganisaties die erg krampachtig proberen tegen te houden dat je hun standaard kan lezen, meestal met beroep op auteursrechten, tenzij je ze een lieve som geld betaald. Dat ergert me mateloos, en ik vraag me af of dat auteursrecht alleen op de tekst van toepassing is of ook op de uitgewerkte ideeën die er in staan.

    Arnout heeft geloof ik wel eens gepleit voor het argument dat een standaard geen auteursrecht zou hebben, omdat het geen creatief werk is. Ik ben het daar niet mee eens (ik mag hopen dat het geen kunstzinnig werk is, maar denk dat er wel een creatief process aan ten grondslag ligt). Desalnietemin zou het me positief lijken als auteursrecht niet van toepassing verklaard zou worden op data formaten, netwerkprotocollen en andere standaarden.

  5. Freeaqingme; in de VS beslist een jury over de feiten in een zaak en de rechter over toepassing van de wet. De vraag “Heeft Google een API gekopieerd?” is een vraag voor de jury, maar de vraag “Is het kopiëren van een API auteursrechtinbreuk?” is een vraag voor de rechter.

    Een van de lastige vragen voor de jury: Is de betwiste API een voldoende substantieel deel van het geregistreerde werk “java” dat het niet meer onder “fair use” valt?

  6. persoonlijk zou ik liever willen dat er iets minder bezitterig met intellectuele eigendomsrechten om zouden gaan
    Helemaal met je eens, en tot zover de ‘free software’. Vrijheid duurt blijkbaar zo lang als tot het moment dat het niet meer goed in het plaatje van de vrijheidsbevechters past.

    Offtopic, als een samenleving waarin een groepering is die het voorlezen van bepaalde gedichten verbiedt voorafgaand aan het vieren van de vrijheid.

  7. @Richard, 2:

    Leuk detail is dat deze discussie twee kanten heeft. Als Oracle dit probeert dan zijn ze gemeen (overigens ben ik het daar mee eens) maar als WordPress claimt dat hun API open source is en dat dit zelfs doorwerkt in alle plugins die tegen deze API aan zijn geprogrammeerd dan zit bijna niemand daarmee (wat ik weer vreemd vind).
    Je moet een onderscheid maken tussen interface specificatie en interface implementatie. Het is mogelijk dat je verschillende implementaties van een specificatie hebt en ieder van de implementaties kan een eigen licentie hebben. Waar het programmeren tegen een specificatie geen invloed heeft op de licentie van jouw code, heeft de licentie van de implementatie van de interface invloed op hoe je het gecombineerde werk kunt gebruiken. @Macfreak, 4; dat is iets genuanceerder dan jij de positie van de FSF weergeeft; er zijn een heleboel subtiele punten waar je op moet letten als je GPL bibliotheken wilt gebruiken in commerciële programma’s.

  8. Het volgende citaat bevreemdt mij:

    to accept that the functionality of a computer program can be protected by copyright would amount to making it possible to monopolise ideas, to the detriment of technological progress and industrial development.

    Maar “to monopolise ideas” is toch het hele idee van octrooien, die juist geacht worden (hoewel wellicht ten onrechte) ’technological process’ juist te bevorderen? Het lijkt me sterk dat de rechtbank zich zou uitspreken tegen octrooien, maar daar lijkt het dus wel op…

  9. @André: ook onder het octrooirecht kun je een idee niet monopoliseren. Het idee moet zijn uitgewerkt tot een concreet product of proces. Wél kun je dan functionaliteit monopoliseren, maar in theorie is dat dan beperkt tot jouw realisatie daarvan. Je patenteert jouw verbrandingsmotor, niet het idee “benzine gecontroleerd laten ontploffen zodat een zuiger in beweging komt”. En een ander kan dan een andere verbrandingsmotor ontwikkelen die om jouw patent heen gaat.

  10. @MathFox, 8:

    Je moet een onderscheid maken tussen interface specificatie en interface implementatie. Het is mogelijk dat je verschillende implementaties van een specificatie hebt en ieder van de implementaties kan een eigen licentie hebben.
    Beetje off-topic inmiddels, maar leuk gedachte-experiment. Stel je hebt library GXYZ met API xyz.h, die beide onder GPL licentie vrijgegeven worden. Als ik nu een programma ABC schrijf en dynamisch link naar GXYZ dan nog claimt FSF dat er sprake is van een afgeleid werkt, dat ik niet mag verspreiden. Ook als verspreid ik in feite GXYZ niet, maar alleen xyz.h. Stel er komt een andere library, BXYZ onder BSD licentie, die precies hetzelfde doet als GXYZ, en ook dezelfde API heeft, en derhalve dezelfde xyz.h: is BXYZ dan een afgeleid werk van GXYZ? En als ik ABC verspreid dynamisch gelinkt met BXYZ? Dat is immers precies hetzelfde als ABC dynamisch gelinkt met GXYZ. Ik betwijfel of er in een API (xyz.h) voldoende creativiteit zit om onder het auteursrecht te vallen.

  11. Het lijkt mij met dit arrest uitgemaakt dat het enkele aanroepen van functies uit een of andere .h niet leidt tot auteursrechtinbreuk ten aanzien van een implementatie van de functies. (En je komt pas aan “u zit aan de GPL vast” als er auteursrechtinbreuk is; als ik geen auteursrechten schend bij gebruik van GPL code kunnen ze het dak op met hun GPL.)

    Ik denk dat de grens zou komen te liggen bij situaties waarin je je specifiek richt op die implementatie, en niet op de API als zodanig. Je zou dan feiten moeten vinden waaruit blijkt dat jouw applicatie rekent op gedrag van de GPL-library en niet alleen maar op de API als zodanig.

    Wél denk ik dat het kan uitmaken of op het moment van maken van het werk er maar één implementatie van de API is. Als dat zo is, dan is dat volgens mij een dergelijk feit. Een applicatie die Linux kernel API’s aanroept is evident bedoeld om op Linux te werken en om Linux functionaliteit te gebruiken. Dat is dus een afgeleid werk van de kernel (maar gelukkig heeft Linus dit gewaived).

    Dat er láter een alternatieve implementatie van de API komt, maakt niet uit. Iets kan niet met terugwerkende kracht geen afgeleid werk/geen inbreuk meer zijn. Of je hebt ontleend aan het werk of niet.

    Dit leidt tot gekke situaties: een vroege .NET applicatie is een afgeleid werk van Microsofts code, want zij waren de enigen met een .NET runtime framework. Maar nu is er ook Mono, dus een .NET applicatie is nu geen inbreuk meer op Microsofts code. Dit is oneerlijk voor de vroege ontwikkelaar, maar juridisch vind ik het wel logisch.

  12. Je zou dan feiten moeten vinden waaruit blijkt dat jouw applicatie rekent op gedrag van de GPL-library en niet alleen maar op de API als zodanig.
    Dat zou betekenen dat een ongedocumenteerde API op meer bescherming kan rekenen dan een gedocumenteerde API.

    En terwijl ik dit schrijf besef ik me dat dat niet eens zo gek is.

  13. Er is met betrekking tot C en C++ header files het detail dat deze bestanden een deel van de interface implementatie (in de vorm van functionele macro’s en inline functies) kunnen bevatten. Wat dat betreft is het veiliger om met .Net of java bibliotheken te werken.

    Voor Linux geldt als complicerende factor dat de systeemaanroepen geïnspireerd zijn door de POSIX standaard… wie zou het auteursrecht kunnen claimen op de (tig keer) uitgebreide Unix interface?

  14. @Richard: Inderdaad. Vergelijk de stijlen in de toegepaste kunst. Iedereen mag aansluiten bij een bepaalde stijl voor zijn meubels en gebruiksvoorwerpen, daar zit geen auteursrecht op. Strak, klassiek, van steigerhout, met ronde bolpoten, etcetera. Maar ga je een specifiek meubel van een ander imiteren, of zelfs bijpassende eigen meubels maken (een Rietveld-bijzettafeltje) dan loop je tegen auteursrechten aan. (Mits natuurlijk het origineel een auteursrecht hééft.)

  15. Hoe verhoudt deze uitspraak zich tot de softwarerichtlijn? Want daarin wordt het volgende gezegd:

    Een computerprogramma wordt beschermd wanneer het in die zin oorspronkelijk is, dat het een eigen schepping van de maker is. Om te bepalen of het programma voor bescherming in aanmerking komt mogen geen andere criteria worden aangelegd. (artikel 1 lid 3)

    Een computerprogramma zou dan dus gelezen moeten worden als de objectcode of de broncode?

  16. Ja, het Hof legt hier uit dat onder “computerprogramma” moet worden verstaan “de instructies die een computer iets laten doen”. De broncode en objectcode dus. Een GUI of programmeertaal valt daar niet onder want die laten op zich een computer nog niets doen.

  17. @5

    De jury in de Oracle vs Google zaak vroeg trouwens ook of de indirecte inkomsten relevant zijn bij de vraag of iets fair use is (fair use is non-commercieel).

    Dat duidt er op dat de jury in ieder geval al van mening is dat er gekopieerd is door Google. En de rechter heeft geantwoord dat ook indirecte inkomsten daarbij relevant zijn.

    Dat antwoord van de rechter is slecht voor Google want die hebben voornamelijk indirecte inkomsten uit Android (uit bijvoorbeeld advertenties)en deze vraag duidt erop dat hun fair use theorie wel eens zou kunnen stranden. Maar met jury’s weet je het nooit. Dit soort grote en ook nog technische zaken is waarschijnlijk te complex voor een jury dus de kans is groot dat de jury er niet uitkomt en dan deels de rechter en deels een beroepszaak over deze onderwerpen zal moeten beslissen.

  18. @hAl, de jury is geïnstrueerd om aan te nemen dat de API auteursrechtelijk beschermd is; de rechter neemt zelf de beslissing of API’s in het algemeen auteursrechtelijk te beschermen zijn. Dit betekent dat de jury de “fair use” factoren serieus neemt.

    Op zich was de zaak (relatief) simpel, totdat de advocaten zich ermee gingen bemoeien. Dat krijg je met twee multinationals en teveel advocaten. Auteursrechtelijke bescherming voor API’s gaat lijnrecht in tegen de algemeen geaccepteerde richtlijnen voor “cleanroom” herimplementatie van software.

  19. @19 Je kunt als Google geen cleanroom implementatie van Java API’s hebben als a) een deel van je android developers voorheen voor Sun aan de Java code heeft gewerkt b) je developers de Java site met documentatie en code als referentie gebruiken (volgens hun getuigenissen) c) er copyrighted Java object code gedecompiled is in je implementatie.

    Dus een cleanroom situatie is sowieso al niet aan de orde.

  20. @20, ik heb niet beweerd, noch gesuggereerd dat Dalvik cleanroom was.

    Het gebruik van publiek beschikbare documentatie (jouw punt b) in de cleanroom is normaal; decompileren en reverse engineering (punt c) in de “dirty room” ook. Ik weet niet waar jij je bezwaren op baseert; zeker nu we het arrest van het hof dat bepaalt dat to accept that the functionality of a computer program can be protected by copyright would amount to making it possible to monopolise ideas bespreken.

    (Heel interessant is dat Oracle na lang zoeken maar 9 regels code heeft kunnen aanwijzen die uit java gekopieerd zouden zijn.)

  21. Met technologische vorderingen en betere browserondersteuning kun je een webpagina veel meer laten doen dan informatie tonen. Veel websites bevatten niet alleen maar statische pagina met informatieverstrekking, maar zijn eigenlijk dynamische applicaties met interacties (comments, admininstratie schermen met CRUD acties, twitterknoppen etc.).

    Een HTML website design is toch auteursrechterlijk beschermd?

    Een HTML applicatie user interface design (GUI) is nu niet auteursrechterlijk beschermd?

    Hoe kan je dat rijmen?

    Of het geval van een hele basic sandbox spelprogrammeertaal SDK of JavaScript library (Of zelfs Photoshop/Mathlab). Zonder instructies doet het niets. Maar met 30 minuten aan eigen instructies tover je een spel, programma of plaatje op het scherm. De oorspronkelijke programmeertaal / SDK is dan maar lastig auteursrechterlijk te beschermen?

    Ik snap denk ik de gedachtengang niet. Mij doet het denken aan verf en de schilder. De verf doet op zichzelf niets, het zijn de instructies van de schilder die het kunstwerk maken. Maar programmeertalen gaan veel dieper dan alleen verf, of een hex kleur code. Wat doe je met de Mona Lisa-verf (de SAS datasteps manipuleren data, creeeren en updaten tabellen)? Of de ronde wolken-kwast (De SAS procedures die data analyseren en klaar maken voor rapportage)? Dat gaat toch een stukje verder dan een specificatie voor een Turing-complete programmeertaal als JavaScript?

  22. @Arnoud:

    Wél denk ik dat het kan uitmaken of op het moment van maken van het werk er maar één implementatie van de API is. Als dat zo is, dan is dat volgens mij een dergelijk feit. Een applicatie die Linux kernel API???s aanroept is evident bedoeld om op Linux te werken en om Linux functionaliteit te gebruiken. Dat is dus een afgeleid werk van de kernel (maar gelukkig heeft Linus dit gewaived).
    Hier kan ik je niet helemaal volgen. Computerprogramma A is auteursrechtelijk een afgeleid werk van computerprogramma B als A code bevat afkomstig uit programma B (misschien een beetje te simpel gesteld, maar laten we het niet te moeilijk maken). Dat is niet het geval in jouw voorbeeld.

    Wat WordPress betreft moet ik aan deze post denken (en in de comments daaronder wordt weer verwezen naar deze discussie).

    Onder de eerste post leg ik trouwens uit waarom ik van mening ben “afgeleid werk” in de zin van de GPL niet breder kan zijn dan “afgeleid werk” in de zin van het auteursrecht. Misschien zie jij dit anders en heb je het in bovenstaande quote over afgeleid werk in de zin van de GPL?

  23. Door een API call te doen vanuit A, roep je code aan in B. Dat kán genoeg zijn om van een verveelvoudiging in gewijzigde vorm te spreken, wanneer het uit de omstandigheden evident is dat jij die specifieke implementatie uit B wilde gebruiken. Het is niet noodzakelijk dat er letterlijk gecopypaste is, ook niet-letterlijk overnemen telt als overnemen.

    Het is inbreuk op auteursrechten om je eigen verhaal over Suske & Wiske te maken, ook al verwijs je slechts bij naam naar de karakters. Die karakters zijn als uitgewerkte personages beschermd, en ze noemen is “aanroepen” in programmeertaal. (Natuurlijk geldt er dan citaatrecht, parodie etcetera als uitzondering vaak, maar daar gaat het even niet om.)

    Ik zie geen principieel verschil tussen “Piet ging voetballen met Suske en Wiske, en toen kwam Krimson in een snelle auto…” en sysvfork((*ptregs) myprocreg). In beide gevallen verwijs je naar een creatief werk op zo’n manier dat het deel wordt van je eigen werk.

    Anders wordt het m.i. wanneer je een algemeen bekende API aanroept. Ik zie dat als hetzelfde als een stijl of vaste uitdrukking gebruiken. De klare lijn die onder meer door Vandersteen is gepopulariseerd, is niet auteursrechtelijk beschermd want slechts een stijl. Dus ik mag tekenen in die stijl, zolang ik maar niet Suske & Wiske (of Kuifje, ook bekend uit die stijl) nateken. Net zo goed als ik de standaard C API’s mag aanroepen.

    Twijfelgevallen alom: als ik een POSIX call doe, is dat dan een stijl / algemeen bekende uitdrukking of toch een specifieke uiting (namelijk van de POSIX jongens)? Doet me een beetje denken aan de discussie over auteursrechten op standards/normen. Maar dat lijkt me hetzelfde als de vraag of “Tom Poes, verzin een list” een afgeleid werk oplevert van de Bommel-werken. Poes is immers een beschermd karakter en met die zin verwijs ik daar toch duidelijk naar. Of is het ondertussen een ingeburgerde standaarduitdrukking?

    define afgeleid_werk verveelvoudiging in gewijzigde vorm

  24. @Arnoud:

    Door een API call te doen vanuit A, roep je code aan in B.
    Misschien begin ik je te begrijpen. Gaat het je om de code van A tijdens de executie van het programma?

    Ik zat te denken aan de source code en/of object code van A op de harde schijf. Tenzij er statisch is gelinkt maakt de code van B daar geen deel van uit en zie ik niet hoe A inbreuk kan maken op het auteursrecht op computerprogramma B. (Als er statisch is gelinkt natuurlijk wel, maar als ik het goed begrijp beperk jij je niet tot dat geval.)

    Hoe ik over draaiende programma’s en auteursrecht denk, moet ik nog even bedenken…

    Het is inbreuk op auteursrechten om je eigen verhaal over Suske & Wiske te maken, ook al verwijs je slechts bij naam naar de karakters. Die karakters zijn als uitgewerkte personages beschermd, en ze noemen is ???aanroepen??? in programmeertaal.

    Een enkele verwijzing bij naam naar Suske & Wiske lijkt inderdaad op een aanroep, maar lijkt mij toch vooral te vergelijken met bijv. een voetnoot of een URL. Een voetnoot levert geen inbreuk op.

    Ik zie geen principieel verschil tussen ???Piet ging voetballen met Suske en Wiske, en toen kwam Krimson in een snelle auto?????? en sys_vfork((*pt_regs) myprocreg). In beide gevallen verwijs je naar een creatief werk op zo???n manier dat het deel wordt van je eigen werk.

    Ik zie auteursrechtelijk echt geen probleem in het enkele aanhalen van Suske en Wiske, of willekeurig welk ander personage uit de wereldliteratuur ook. Het wordt anders als je karakters te zeer gaat baseren op Suske en Wiske. Jouw post heeft geen beroep op het citaatrecht nodig om legaal te zijn.

    Maar met programma’s die samen met een library in het geheugen zitten en die library tijdens hun executie aanroepen zit het misschien anders…

  25. Nee, het gaat me niet uitsluitend om de situatie tijdens executie. Een vervolgverhaal op Harry Potter hoeft ook niet Goblet of Fire ingenaaid te hebben om inbreuk te zijn.

    Ik zie het echt principieel: een aanroep van een functie is gebruik maken van die functie, en daarmee een verveelvoudiging in niet-letterlijke vorm. Je programma is gebouwd op die functie van de ander, en of je dan copypaste of via een dynamisch opgeloste link de functie aanroept behoort niet uit te maken.

    Het gaat me niet om een verwijzing op het niveau “Ik zou wel eens in een Suske & Wiske avontuur willen voorkomen”. Daar zie ik inderdaad geen overname van creatieve elementen. Maar let wel, we weten van Infopaq dat ook het overnemen van 11 woorden al inbreuk kán zijn, zolang het maar 11 creatieve woorden zijn. Een iets langere passage kan dus wél inbreuk zijn:

    Arnoud en Piet liepen over straat, toen zij een snelle sportwagen voorbij zagen flitsen. Het was Krimson! De crimineel met sik had duidelijk snode plannen, want hij werd op de hielen gezeten door Jerom en Lambik. Ruziemakend zoals alleen zij dat kunnen, probeerden ze de auto van Krimson klem te rijden. Uiteindelijk beslechtte Jerom het pleit door een passerende tram een zetje te geven en voor de auto te gooien. Gelukkig raakte niemand gewond!

    Dit verhaaltje ‘werkt’ alleen maar omdat de karakters van Krimson, Jerom en Lambik al voorgedefinieerd in je hoofd zijn. Ik doe hier dus een dynamische link naar de reeds in jouw hersenen aanwezige bibliotheek van Sus en Wis.

    Anders gezegd: een tekstverhaal over S & W is net zo goed inbreuk als een stripverhaal waarin ik ze nateken (copypaste).

    Hoe zou jij dit verhaaltje auteursrechtelijk kwalificeren? Geen inbreuk want parodie? Citaat? Onvoldoende overname van creatieve elementen? Vrije meningsuiting want karakters uit wereldliteratuur mogen niet op slot?

  26. Hoe zou jij dit verhaaltje auteursrechtelijk kwalificeren?

    @26: Pure diefstal! Niet alleen moet Arnoud publiek terechtgesteld worden voor deze onmenselijke broodroof van eerlijke artiesten als wijlen Vandersteen. Dit is zo erg dat als er ook maar een enkele pagina naar deze subversieve discussie verwijst, die hele site on-mid-de-lijk geheel geblokkeert dient te worden.

  27. @Arnoud, in de USA zou je verhaal onder “Fair use” vallen omdat je het gebruikt bij een artikel om je standpunt mee te verduidelijken. 🙂 Alleen kent Nederland geen “Fair use” maar een citaatrecht en jij citeert niet. Inbreuk dus. De nabestaanden van Vandersteen sturen nu vast de Rode Ridder op je af om te gaan claimen. 🙂

  28. @Arnoud:

    Nee, het gaat me niet uitsluitend om de situatie tijdens executie. Een vervolgverhaal op Harry Potter hoeft ook niet Goblet of Fire ingenaaid te hebben om inbreuk te zijn.
    Een vervolgverhaal op Harry Potter met verschillende karakters erin uit de Harry Potter-serie is natuurlijk een heel ander verhaal. Dat kan natuurlijk inbreuk opleveren, ook als er hier en daar wat wordt veranderd.

    Waar ik het niet mee eens ben, is dat het bij naam aanhalen van Harry Potter in een heel ander verhaal inbreuk op kan leveren op het auteursrecht op de Harry Potter-boeken. Het enige wat je dan overneemt is de naam “Harry Potter” en die is niet auteursrechtelijk beschermd.

    Ik zie het echt principieel: een aanroep van een functie is gebruik maken van die functie, en daarmee een verveelvoudiging in niet-letterlijke vorm. Je programma is gebouwd op die functie van de ander, en of je dan copypaste of via een dynamisch opgeloste link de functie aanroept behoort niet uit te maken.

    Waarom is het publiceren van een URL naar een beschermd werk dan geen inbreuk op het auteursrecht op dat werk? Of ben je op dat punt van mening (terug)veranderd? Een inline-link naar een plaatje op de server van de rechthebbende maakt geen inbreuk op het auteursrecht op de plaatje, een torrent-link maakt geen inbreuk op het auteursrecht op het gelinkte bestand, daar is men het in de rechtspraak nu toch wel over eens.

    Het schrijven of publiceren van source code met een functieaanroep is op geen enkele manier een verveelvoudiging of openbaarmaking van de code die die functie implementeert. Op die code rust het auteursrecht (niet op de functionaliteit, die je inderdaad door zo’n aanroep integreert in je programma). De analogie met URLs en voetnoten lijkt mij 100%?

    Dit verhaaltje ???werkt??? alleen maar omdat de karakters van Krimson, Jerom en Lambik al voorgedefinieerd in je hoofd zijn. Ik doe hier dus een dynamische link naar de reeds in jouw hersenen aanwezige bibliotheek van Sus en Wis. Anders gezegd: een tekstverhaal over S & W is net zo goed inbreuk als een stripverhaal waarin ik ze nateken (copypaste).

    De voorgedefinieerdheid / bekendheid van de karakters bij het publiek lijkt mij auteursrechtelijk irrelevant. Meeliften op succes kan onder omstandigheden onrechtmatig zijn, maar levert op zichzelf geen inbreuk op auteursrecht op (waarbij ik even niet denk aan portretrecht). Een auteur heeft geen (auteurs)rechten op de “ideeën” / culturele bagage aanwezig in de hersenen van het publiek. De literatuur bevat tal van voorbeelden van verwijzingen naar het werk van andere auteurs die slechts “werken” als de lezer zijn klassiekers kent. Het auteursrecht komt daar niet bij kijken.

    Of jouw verhaaltje inbreuk maakt staat dus los van de vraag of je verhaal “werkt”. De vraag is of het auteursrechtelijk beschermde creatieve expressie bevat overgenomen uit het werk van Vandersteen. Het enkele overnemen van een naam is daarvoor zeker niet voldoende. Het schrijven van een verhaal vol met elementen ontleend aan Suske en Wiske-verhalen en de uitgewerkte karakters van de personages is natuurlijk wel inbreuk. Jouw verhaaltje zit daar tussen. Ik wil best aannemen dat het inbreuk maakt, maar erg relevant voor de inbreukmakendheid van API-calls is dat niet.

    Want wat neem je over als je gebruik maakt van een API: – de namen van de aangeroepen functies; – de types en volgorde van de argumenten; – de functionaliteit van de aangeroepen functies.

    Auteursrecht op softwarecode ziet niet op de functionaliteit. Daar hoeven we dus niet verder naar te kijken, ook al is de functionaliteit nu juist dat wat het “doet werken”.

    De functienamen en argumenten zullen doorgaans weinig creatief zijn, maar vooral zijn gedicteerd door de functionaliteit van de functies. Wat door functionaliteit wordt gedicteerd is niet auteursrechtelijk beschermd.

    (Ik begin nu trouwens het idee te krijgen dat, ook gelet op C-393/09, het auteursrecht op de achterliggende software sowieso de API niet beschermd, maar dat je moet gaan kijken of de API op zichzelf als “werk” moet worden aangemerkt. Functionele bepaaldheid en vermoedelijk gebrek aan creativiteit in functienamen zal hierbij echter van belang blijven.)

  29. Inderdaad, daar heb je een goed punt. Auteursrecht gaat niet over functionaliteit, en dat is een wezenlijk verschil met een Suske&Wiske-verhaal. Daar importeer je creativiteit (het uitgewerkte personage Sidonia met haar hysterische aanvallen en bezorgdheid). Even afgezien waar de grens ligt bij slechts verwijzen (“wat een Sidonia ben je toch”, lijkt me inderdaad geen auteursrechtelijk relevant overnemen, maar 300 pagina’s “Het dagboek van tante Sidonia” met eigen invullingen van hoe zij dat zou schrijven wel. Ook zonder tekening van de bonenstaak-dame met maat 48.)

    Bij API calls wil je uitsluitend de functionaliteit importeren. En de wijze waarop je die functionaliteit creatief invult, is voor jou meestal irrelevant.

    Een torrent is een bronverwijzing, dat vind ik heel wat anders dan een functiecall. Een functiecall is direct het mechanisme waarmee de functie aangeroepen wordt, meer dan een hyperlink die nog een actie vereist van de gebruiker. Plus, de hyperlink roept het originele werk in de originele context op.

    Ja precies, bij inline links en framing is dat anders en juist dáár is de (lagere) rechtspraak anders. De paar vonnissen over inline linken van plaatjes komen neer op “dat is een nieuwe openbaarmaking want je plaatst het in je eigen nieuwe context ook als je geen byte overneemt”. En dit is ook waarom Buma/Stemra stelt dat embedden een openbaarmaking is (ook vanwege het “nieuw publiek” argument, dat bij software minder opgaat want je hád die library al, in tegenstelling tot de gestreamde muziek of film).

  30. Het auteursrecht beschermd natuurlijk niet, maar beschermt.

    En nu ik toch schrijf, kan ik nog een poging doen om te verduidelijken waarom jouw S&W-voorbeeld niet te vergelijken is met een programma dat een API aanroept. In je verhaaltje neem je namen over uit S&W, en combineer je die op een manier die je ontleent aan S&W. Behalve de letterlijke namen, neem je dus ook niet-letterlijke elementen over uit S&W. Op een bepaald moment zul je dan inderdaad inbreuk maken.

    Een computerprogramma combineert API calls natuurlijk óók om tot een geheel te komen. De keuze en arrangering van API calls kan heel goed onder het auteursrecht op de software vallen. Die keuze en arrangering wordt echter juist niet ontleend aan de library die je aanroept. De arrangering zal deels functioneel bepaald zijn, en deels een (beschermde) uitdrukking zijn van de creatieve vrijheid van de auteur van het aanroepende programma (en niet die van de auteur van de library).

    Overigens: C-406/10 maakt duidelijk dat je zonder te kijken in de sourcecode en/of objectcode van de library per definitie geen inbreuk kunt maken op het auteursrecht op die library. Je zult het dus moeten zoeken in inbreuk op de API “als werk”, maar ook dat gaat zoals gezegd heel lastig worden, als zoiets al een “werk” kan zijn.

    Ik vraag me verder af of je met enerzijds “inbreuk door incorporatie via aanroeping” en anderzijds “inbreuk door het overnemen van niet-letterlijke elementen” niet een beetje op twee gedachten hinkt? Inbreuk door incorporatie via aanroeping valt af, zie de URL-jurisprudentie. De andere mogelijkheid valt af, zie C-406/10 (tenzij de API op zichzelf een auteursrechtelijk beschermd werk is en er sprake is van inbreuk op die API… misschien mogelijk als de functienamen gedichtjes vormen).

  31. Misschien was mijn vorige bijdrage een beetje overbodig, maar ik had de reactie van Arnoud nog niet gezien.

    Ja precies, bij inline links en framing is dat anders en juist dáár is de (lagere) rechtspraak anders. De paar vonnissen over inline linken van plaatjes komen neer op ???dat is een nieuwe openbaarmaking want je plaatst het in je eigen nieuwe context ook als je geen byte overneemt???. En dit is ook waarom Buma/Stemra stelt dat embedden een openbaarmaking is (ook vanwege het ???nieuw publiek??? argument, dat bij software minder opgaat want je hád die library al, in tegenstelling tot de gestreamde muziek of film).

    Er is inderdaad wat (ik dacht vooral oudere) lagere rechtspraak in die richting, maar die lijkt me onjuist. Misschien ben ik inderdaad te snel als ik zeg dat dit al een geheel uitgemaakte zaak is.

    Het “nieuw publiek”-argument wordt volgens mij in de rechtspraak gebruikt om te bepalen of het verder doorgeven van materiaal een nieuwe openbaarmaking oplevert. Als je het materiaal zelf niet doorgeeft, maar slechts een link openbaarmaakt, kom je niet in een context waarin dat argument van toepassing is. Maar ik heb nu geen hoge rechtspraak bij de hand die dit bevestigt (en die is er misschien ook niet).

  32. @Piet: Zie deze blog over een opmerkelijk arrest van Hof Den Bosch dat opmerkt “In de rechtspraak en juridische literatuur wordt betrekkelijk eensgezind aangenomen dat een embedded link wel een openbaarmaking inhoudt.” Ik kon en kan niet vinden hoe men hierbij komt, afgezien van een tijdschriftartikel van de advocaat van gedaagde waar die zin uit overgetypt was(!).

    Tevens haal ik daar Visser aan die zegt

    Het is dus mogelijk om ???embedden???, evenals hyperlinken, niet als auteursrechtelijk relevant openbaar maken aan te merken. Het is ook mogelijk, bijvoorbeeld via een bepaalde invulling van het begrip ???nieuw publiek???, ???embedden??? wél als (secundaire) openbaarmaking aan te merken, waarbij men uit moet gaan van een functionele benadering van het openbaar- makingsrecht, waarbij vermoedelijk de indruk van het publiek over wie openbaar maakt van belang is. Het Hof van Justitie der EG zal hierover uiteindelijk moeten beslissen.

    Een en ander zie je ook terug in het Airfield-arrest van het HvJ, r.o 72:

    Vervolgens volgt uit de rechtspraak van het Hof dat deze toestemming moet worden verkregen door met name de persoon die deze mededeling opstart of die daarin een interventie uitvoert zodat door middel van deze mededeling de auteursrechtelijk beschermde werken toegankelijk worden voor een nieuw publiek, dat wil zeggen een publiek dat de auteurs van de be-schermde werken niet voor ogen hadden toen zij aan een andere persoon toe stemming verleenden
    De discussie gaat vervolgens over wanneer je die “interventie” uitvoert. Ook wordt er wat gekronkeld rond “nieuw publiek” en hoe je dat meet. Moet je kijken in het hoofd van de rechthebbende? Moet je zijn wil objectiveren om dit criterium te kunnen toepassen?

  33. Ik kon en kan niet vinden hoe men hierbij komt, afgezien van een tijdschriftartikel van de advocaat van gedaagde waar die zin uit overgetypt was(!).

    Gelukkig voor de rechter en zijn werkgever vormt deze schaamteloze kopieeractie dankzij art. 11 Aw geen inbreuk op enig auteursrecht 🙂

    Het Airfield-arrest kende ik nog niet. Het criterium dat ik gaf is blijkbaar niet juist. De HvJ lijkt het te gooien op de vraag of er sprake is van “opentrekken van de kring van personen die toegang tot [het werk] hebben”. Voor software en API calls lijkt dit inderdaad niet zo heel relevant, maar BUMA/Stemra geeft dit wel een argument.

    Ik denk vooralsnog niet dat het argument opgaat. Een embedded link creëert geen nieuwe toegang: die link werkt alleen als de gebruiker sowieso al toegang had.

    Het is wellicht anders als de link ook een wachtwoord of decryptiesleutel bevat. Dan lijk je dicht in de buurt te komen van de situatie in het arrest. Je geeft mensen toegang die dit nog niet hadden.

    Nou ja, het HvJ lijkt hard op weg te zijn om al dit soort vragen van een antwoord te voorzien.

  34. Moet je kijken in het hoofd van de rechthebbende? Moet je zijn wil objectiveren om dit criterium te kunnen toepassen?

    Goede vraag, en als je die arresten leest zou je bijna zeggen dat je in zijn hoofd moet kijken.

    Maar… wat als de oorspronkelijke mededeling zonder toestemming van de rechthebbende is gedaan, bijv. in de vorm van een webpagina. Is dan iedere verwijzing naar die pagina een mededeling van het werk aan een nieuw publiek? De rechthebbende heeft immers nooit ingestemd met de ontvangers van die verwijzing als publiek.

    Dat lijkt mij niet te kloppen. Het “publiek” van een in een bepaalde vorm gedane mededeling moet je volgens mij dus naar objectieve maatstaven vaststellen.

  35. Bij de comparitie in het hoger beroep van de FTD/Eyeworks zaak kwam Dirk Visser (die van het artikel en de advocaat van Eyeworks toen) met de casus waarin partij A het signaal doorgeeft in versleutelde vorm, en partij B de sleutel verkoopt. Aangenomen dat er geen formele band tussen A en B is: wie maakt nu openbaar?

    A biedt het werk niet aan want je kunt het niet zien, het is versleuteld. B biedt het werk niet aan want een sleutel is toch niet “het werk”. En als die formele band er niet is, kun je ook geen mede-openbaarmakingsfiguur of zo construeren.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.