Mag ik code snippets overnemen?

snippets.pngEen meelezende programmeur vroeg me:

Ik heb een hash implementatie gemaakt in C++. Daarbij heb ik een hash functie gebruikt die ik op wikipedia heb gevonden. Maar mag dat wel zomaar?

Dit soort vraag krijg ik wel vaker. Het gaat dan vaak over snippets, korte stukjes code die her en der op internet te vinden zijn en vaak makkelijk te hergebruiken zijn in je eigen software. Zo ook hier:

ub4 one_at_a_time(char *key, ub4 len) { 
  ub4 hash, i; 
  for (hash=0, i=0; i < len; ++i) { 
    hash  = key[i]; 
    hash  = (hash <<  10); 
    hash ^= (hash >> 6); 
  } 
  hash  = (hash << 3); 
  hash ^= (hash >> 11); 
  hash  = (hash << 15); 
  return (hash & mask); 
} 

Zit hier nu auteursrecht op? Dat lijkt me niet. Voor auteursrecht moet sprake zijn van een creatief werk, een werk waar het stempel van de maker uit te herkennen is. En dat gaat hier niet op. De code is niets meer dan een rechtstreekse implementatie van een eenvoudig hash-algoritme. Daar is niets creatiefs aan. Alle gemaakte programmeerkeuzes zijn functioneel en technisch ingegeven. Dus nee, ik zie hier geen auteursrecht op zitten.

Andere meelezende programmeurs: vinden jullie van wel? Is dit gebruik van bitwise operators creatief en origineel?

Arnoud<br/> (Mijn overname hierboven is trouwens één van die weinige situaties waarin citaatrecht voor software te claimen valt.)

18 reacties

  1. De ontbrekende creativiteit is er idd niet altijd. Sommige snippets zijn juist goede snippets omdat ze bestaande functies op een creative manier in iets nieuws omzetten. Soms ook gaat het om performance of bijvoorbeeld veiligheid.

    Veel dingen kunnen gemaakt worden door een oneindige hoeveelheid coderegels onder elkaar te zetten. Sommige programmeurs vinden echter een systeempje om iets in enkele regels op te lossen.

  2. Vooropgesteld vind ik dat het uitoefenen van auteursrecht, en met name dan de bestraffing van ongeoorloofde reproductie, op code snippets (of iedere andere technische beschrijving) die op het internet gepubliceerd is contraproductief en ook niet bepaald van deze tijd is. Als je wel de kennis wil overdragen van de werking van een (computer) algoritme en dit tevens aan een willekeurig publiek wil tonen (wat het gevolg is van publicatie op het Internet), maar vervolgens niet wil dat iemand uit dat publiek het algoritme kopieert, dan denk ik dat er iets fundamenteels schort aan het willen publiceren van de informatie.

    In tegenstelling tot bijvoorbeeld een literair werk, waarbij gesteld kan worden dat een lezer dit nuttig kan consumeren zonder het te hoeven kopi?ren, denk ik dat het publiceren van een algoritme in de meeste gevallen alleen nut heeft wanneer het vervolgens door iemand wordt toegepast. Uiteraard zou je nog kunnen stellen dat het gepubliceerde algoritme enkel ter illustratie dient, maar persoonlijk vind ik dat niet een sterk argument omdat bij een publicatie van technische informatie de literaire vorm (die mogelijk copyright bezit) nagenoeg overeenkomt met de technische inhoud (die uiteraard geen copyright bezit).

    Verder denk ik dat er nog wel een uitzondering bestaat. Sommige mensen beweren dat broncode een kunstwerk is. In een symbolische zin kan dit zeker waar zijn. Het kost namelijk (meestal) veel tijd en creativiteit om code tot een overzichtelijk leesbaar en begrijpelijk document te maken. Het is een “kunst” die ook niet iedere programmeur beheerst. Toch valt het me op dat veel van de programmeurs die zich beroepen op copyright omdat hun code “a work of art” zou zijn, dit in de regel voornamelijk voor het ophemelen van hun eigen ego doen en meestal ook nog eens op code die eerder ondermaats dan kunstzinnig genoemd kan worden. Dit neemt niet weg dat wanneer je een unieke opmaak gebruikt voor het presenteren van broncode, je zou kunnen stellen dat de broncode inderdaad een kunstwerk is. Daarbij moet de gebruikte opmaak echter wel zeer persoonlijk en uniek zijn en dat doet de leesbaarheid in de praktijk meestal niet veel goeds. daarmee denk ik dat de “kunst” in de code niet echt een toegevoegde waarde vormt wat vervolgens het uitoefenen van copyright dan ook niet echt rechtvaardigt.

    Tot slot denk ik dat het verstandig is dat je je als programmeur af vraagt of de code die je van Wikipedia overneemt auteursrechtelijk beschermt is. Het lijkt mij daarentegen onwaarschijnlijk en onverstandig dat iemand die een code snippet op het Internet publiceert zich vervolgens op copyright zal/kan beroepen. Het druist volgens mij in tegen het doel en de Intentie van het Internet als een bron van (technische) kennis en informatie. Zelfs als zou blijken dat er wel degelijk copyright op code snippets zit, denk ik dat de wet hier simpelweg geen aansluiting meer heeft met de hedendaagse werkelijkheid van het Internet. Dit zal in de toekomst vermoedelijk alleen maar toenemen. Op de keper beschouwd zal het er, de wet ten spijt, in de toekomst waarschijnlijk op neer komen dat wanneer je niet wil dat anderen jou werk kopi?ren, je het niet op het internet moet publiceren. In ieder geval niet zelf althans. Als iemand anders (en tevens voor het eerst) je werk op het Internet publiceert, is het uiteraard een andere zaak en denk ik dat je met recht van plagiaat kunt spreken.

  3. “Alle gemaakte programmeerkeuzes zijn functioneel en technisch ingegeven.”

    Dat is zeker niet het geval. Als programmeur maak je constant beslissingen, die wel degelijk meer of minder creatief kunnen zijn.

    Zeker bij het aangehaalde voorbeeld van een hashfunctie zijn niet alle keuzes vooraf ingegeven. Het doel is duidelijk, maar er komen kan op ontelbare manieren.

    En voor sommige, betere oplossingen moet je net iets creatiever zijn.

  4. Arnoud, hoe zit het met patenten die van toepassing zouden kunnen zijn?

    Er is bijvoorbeeld veel commotie geweest over mp3, ik meen bedacht door het fraunhofer instituut. Ook voor het gebruik van lzh compressie, veel gebruikt in GIF bestanden zou ooit een licentie vereist zijn.

  5. Ja, er is een grens waaronder een code fragment niet meer vatbaar is voor auteursrechtbescherming; maar waar deze grens ligt en welke criteria toegepast worden is onduidelijk. Voor zover ik weet is er geen jurisprudentie die specifiek de vraag “Wanneer is een code fragment creatief genoeg voor auteursrechtbescherming?” beantwoordt. Ik durf het aan om de stelling te verdedigen dat een goede hash functie (zoals die van Jenkins) bescherming verdient als zelfstandig werk.

    Een ander argument is “Met welk doel is de code gepubliceerd?” De auteur moet hierbij een educatief doel in gedachten hebben gehad. Helaas zijn de auteurs niet altijd even duidelijk in de licentievoorwaarden die ze aan dit soort “voorbeeldcode” hangen; een expliciete licentie maakt het allemaal veel helderder. Dit leidt tot een vraag van mijn kant: Mag je aannemen dat je toestemming voor hergebruik van code-fragmenten hebt die je in een boek of artikel aantreft, als er geen licentie genoemd is?

  6. @casper: Octrooien staan helemaal los van auteursrecht. Het feit dat er geen auteursrecht op code zit, betekent nog niet dat er ook geen octrooi op het algoritme kan zitten. Auteursrecht beschermt een creatieve uitwerking, een kunstzinnige fiets bijvoorbeeld. Octrooirecht beschermt een technische vinding, zoals het trapmechanisme van een fiets, ongeacht hoe kunstzinnig of saai die gebouwd is.

  7. Dit specifieke stukje code zou ondanks zijn compactheid wel degelijk beschermd kunnen zijn, het is een innovatieve, nieuwe implementatie van een zelf-verzonnen hash-functie, die eigenschappen heeft die andere, meer gebruikte hashes niet hebben (dan gaat het om eigenschappen als snelheid, goede mixing, weinig collisions, etc).

    Gelukkig, als je wat doorklikt op dat Wikipedia artikel, kom je op een pagina waar expliciet vermeld wordt dat alle code daar in het ‘public domain’ valt.

  8. Ik heb het stukje code even doorgelopen, en ontdekte dat dat nooit een goede hash-functie op kon leveren. Gelukkig stond er een link bij naar het artikel uit Wikipedia, waar het orgineel stond. Een paar plustekens lijken te zijn weggevallen. Dus als iemand een hashfunctie zoekt, neem die dan rechtstreeks uit Wikipedia over en niet uit dit citaat.

  9. De eis van “persoonlijk stempel van de maker” geldt niet voor software; zie Artikel 1(3) van de EU richtlijn 91-250 over de juridische bescherming van software: “A computer program shall be protected if it is original in the sense that it is the author’s own intellectual creation. No other criteria shall be applied to determine its eligibility for protection.”

  10. Het komt mij voor dat het criterium dat het computerprogramma een eigen schepping van de maker is, een lagere drempel inhoudt dan het voor andere auteursrechtelijk beschermde werken geldende criterium dat het werk een eigen oorspronkelijk karakter heeft en het persoonlijk stempel van de maker draagt. Met Artikel 1(3) heeft de richtlijngever immers bedoeld om een eigen maatstaf vast te leggen, anders dan de divergerende nationale criteria, waaronders ons bovengenoemde NL criterium. M.i. betekent “een eigen schepping” alleen dat je het zelf gemaakt hebt, dus niet overgeschreven hebt van iemand anders.

  11. Ik heb even zitten zoeken. Jouw opvatting zie ik terug in de <a HREF=”http://books.google.nl/books?id=1qWDCBipQLwC&pg=PA372&lpg=PA372&dq=auteursrecht+stempel+maker+”own+intellectual+creation” rel=”nofollow”>noot bij Van Dale/Romme (NJ 1991, 608):

    Wat computerprogramma’s betreft zij nog aangetekend dat op 14 mei 1991 is uitgevaardigd EEG-Richtlijn 91/250 (Pb. L 122 van 17 mei 1991), die auteursrechtelijke bescherming voorschrijft. Daarin lijkt geen plaats meer voor een criterium van “persoonlijk stempel” of “persoonlijke visie”. Vgl. art. 1 lid 3: “A computer program shall be protected if it is original in the sense that it is the author’s own intellectual creation. No other criteria shall be applied to determine its eligibility for protection.” Vgl. ook de 8e considerans. Dat wordt in onze Aw dus straks een werk-categorie met een eigen drempelcriterium.

    Spoor/Verkade/Visser (p. 592) vertalen het begrip echter met “eigen schepping van de maker” en stellen dat dit overeenkomt met het persoonlijk-stempelcriterium van de Hoge Raad.

  12. Andere meelezende programmeurs: vinden jullie van wel? Is dit gebruik van bitwise operators creatief en origineel?

    Dit is natuurlijk wel een groot deel van programmeren in bv PHP. Dus als ik een bestandje maak waar bijv. veel optellingen worden gedaan, dan ga ik er niet vanuit dat deze wijdverspreid wordt (tenzij ik zoals in dit geval de code gewoon op internet plak).

  13. Arnoud,

    Op zich denk ik dat je kunt stellen dat het citaatrecht ook voor software geldt. Eigenlijk is alleen de auteursrechtelijke beperking van de thuiskopie en de reproductie expliciet kalltgestellt door de wetgever. Citeren uit broncode kan denk ik nog wel, mits daar geen vertaling van de codevorm mee gepaard gaat. De softwarerichtlijn zit door die constructie vol valkuilen. Heel ongenuanceerd ga ik er eigenlijk altijd van uit dat de traditionele beperkingen op het auteursrecht praktisch gezien niet of nauwelijks opgaan voor software.

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.