Moeten we echt elk jaar de copyrightvermelding in onze broncode updaten?

| AE 9248 | Software | 23 reacties

Een lezer vroeg me:

Alle broncodes binnen ons bedrijf hebben een copyrightvermelding, als volgt:
Copyright © 2016 $NAAM
THIS SOURCE CODE IS THE UNPUBLISHED AND CONFIDENTIAL PROPERTY OF $NAAM<
AND MAY NOT BE COPIED, MODIFIED OR DISTRIBUTED WITHOUT PRIOR WRITTEN AUTHORIZATION.
(Iets ingekort in verband met leesbaarheid.) Nu moet ik al die notices aanpassen want het is 2017. Kan dat echt niet anders?

Vrijwel alle broncode heeft een copyright notice, maar juridisch is dat eigenlijk nergens voor nodig. Heel formeel bestaat een copyrightvermelding uit drie elementen, in deze volgorde:

  • Het woord "copyright", de afkorting "copr." of het C-in-een-cirkel symbool ©. Allebei is dus eigenlijk dubbelop, en wie "(C)" doet is eigenlijk fout bezig.
  • Het jaar van eerste publicatie van het werk. Als het gaat om een aangepaste versie, dan moeten de jaren van elke wijziging ook worden vermeld. Zo geeft "1985, 1987-1989" bijvoorbeeld aan dat het werk gemaakt is in 1985 met wijzigingen in 1987, 1988 en 1989. Onze vraagsteller hoeft dus niet álle bestanden aan te passen, maar alleen bij de eerste wijziging in 2017 dat jaar toe te voegen.
  • De naam van de auteur. Dit mag een afkorting of pseudoniem zijn, zolang de auteur maar te identificeren is. In dit geval mag de statutaire naam worden gevoerd, of een andere handelsnaam die het bedrijf gebruikt.

Het punt is alleen dat geen enkele wet een copyrightvermelding eist als voorwaarde om auteursrecht te hebben op die software. Auteursrecht ontstaat namelijk enkel door het werk te maken, ongeacht wat er bij staat aan naams- of copyrightvermeldingen.

In de VS was het tot 1978 wél verplicht om zo'n vermelding te doen, anders was je werk niet beschermd. Maar juristen zijn een conservatief stel mensen, en bovendien het stáát heel juridisch dus laten we het maar doen. Cargo culting dus. Hetzelfde geldt voor all rights reserved.

Een naamsvermelding van de rechthebbende is natuurlijk wel zo handig, en een waarschuwing dat zonder licentie deze broncode niet mag worden verspreid kan ook geen kwaad. (Alleen graag zonder hoofdletters, dat leest beter.) Het is dus prima om vanaf nu "Copyright $NAAM" zonder jaartal te doen, dan hoef je er nooit meer aan te komen (tenzij je de auteursrechten verkoopt uiteraard.)

Arnoud

Deel dit artikel

  1. Oplossing: leer gestructureerd programmeren. Heb je zo’n copyright notice stringetje op meerdere plekken nodig, dan maak je dus een functie die die string voor je aanmaakt en hoef je dus altijd maar op 1 plek (die ene functie) je code aan te passen. Indien nodig, want die functie kan natuurlijk gewoon het geldende jaartal verwerken zodat aanpassen eigenlijk nooit nodig is.

    Vraagje uit nieuwgierigheid: is iets als “copyright 1980-today” houdbaar? Of vallen juristen over dat woordje ‘today’? De bedoeling lijkt me duidelijk…

  2. Volgens mij heeft een copyright notice in de VS wél nut. Zonder notice mag enkel de werkelijke schade (incl. gederfde inkomsten) worden verhaald. Met notice mag ook statutory damages en advocaatkosten worden verhaald.

    En ik meen me te herinneren dat een notice (in andere vorm) in Nederland ook weer nut had. Iets met “alle rechten voorbehouden” om de persexceptie dood te verklaren…?

  3. Het lijkt me dat de belangrijkste functie van het toevoegen van de datum is om aan te geven wanneer het copyright verloopt. Dus als code in 2016 geschreven en gepubliceerd is (door een rechtspersoon), verloopt het auteursrecht 70 jaar later, in 2086. Zou het dan niet onrechtmatig zijn om code te publiceren met een copyrightmelding (C) 2017, als die code in 2016 voor het laatst gewijzigd is? Daarmee lijk je immers te suggereren dat je code langer beschermd is dan het daadwerkelijk het geval is.

    • Lijkt me sterk dat er snel een tijd komt dat dit relevant gaat zijn. Immers 70 jaar geleden (1947) was er nog geen sprake van software. Ook al zou dat er wel zijn, die code is zo oud dat je waarschijnlijk niet eens een (moderne) machine zou kunnen vinden die dit kan draaien. (zonder aanpassing in ieder geval). De houdbaarheid van software is vaak niet meer dan een aantal jaar. Het is dus een ‘waste of resources’ om een Copyright melding op te nemen in je bron code. Een begin datum zou kunnen maar heeft ook maar beperkt nut (behalve voor je eigen administratie). Copyright werkt nu eenmaal op ieder werk dat je creëert en je kunt volgens mij als originele houder hier alleen (gedeeltelijk) van af zien.

      • Er zijn best oude stukken software die nog steeds (veel) gebruikt worden; vanaf eind jaren ’60 begon software significant genoeg te worden dat hergebruik interessant begon te worden; tegelijkertijd begon men in platform-onafhankelijke hogere programmeertalen te schrijven.

        Ik heb even nagedacht over je opmerking, en als privé-persoon (dus niet als bedrijf) heb je toch bescherming tot 70 jaar na je dood (OK, je nabestaanden dan)? Dan doet het moment van schrijven van de software er toch niet toe? Alleen jouw identiteit moet ontdekbaar zijn, zodat men niet alleen weet wie het auteursrecht heeft, maar ook de duur van het auteursrecht (al kan dat laatste pas vanaf je overlijden bepaald worden).

        Hoe groot schat je de kans dat het auteursrecht na al die jaren nog steeds in de huidige vorm zal bestaan? Ik heb wel eens een artikel van een futuroloog gelezen die stelde dat je eigenlijk niet verder dan 20 jaar in de toekomst kunt kijken. Even controleren: 20 jaar geleden, 1997, nog niet iedereen had internet, maar men kende het al wel en had de trend door kunnen trekken; de politieke ontwikkelingen van na 9/11 waren niet te voorzien; de economische crisis wellicht wel. 30 jaar geleden, 1987, bestond de Sovjet-Unie nog, en niemand behalve echte kenners had door dat die op instorten stond. De computer was aan een opmars bezig, maar internet kende bijna niemand, en mobiele telefonie bestond uit autotelefoons en dingen met grote accu-koffers.

Laat een reactie achter

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

(verplicht)

Volg de reacties per RSS