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

Mag Spotify mijn SSD-schijven tot prut reduceren?

| AE 9077 | Internetrecht | 15 reacties

ssd-schijf-opslagOeps. De afgelopen vijf maanden (zo niet langer) heeft de Spotify app zo hard staan schrijven naar de ssd-schijven in telefoons dat deze járen aan levensduur zijn kwijtgeraakt. Dat las ik bij Ars Technica. Frequent schrijven naar ssd schijven is serieus Niet Handig aangezien dat voor grote slijtage zorgt. En nee, het ging niet om overijverig downloadende gebruikers: dit was een oeps foutje bedankt van Spotify. De nieuwste versie lost het op, maar de schade is niet ongedaan te maken. Kan dat zomaar?

We hebben natuurlijk de productaansprakelijkheid in de wet, en die opent met een veelbelovend artikel:

De producent is aansprakelijk voor de schade veroorzaakt door een gebrek in zijn produkt, tenzij: (…)

Alleen gaat dat ‘gebrek’ vervolgens alleen over fysieke veiligheid, zeg maar ontploffingen en dergelijke. Overmatige slijtage is moeilijk te zien als een veiligheidskwestie, behalve misschien bij autogordels. Bovendien is een app zoals Spotify geen ‘product’ (al dan niet met een k), want dat moet een roerende zaak zijn. Dus daarmee komen we er niet.

Wanprestatie dan. De app doet niet wat je ervan mag verwachten, dus geen conformiteit dus herstel & vergoeding van schade. En ja, dit geldt ook voor software – het Beeldbrigade-arrest van de Hoge Raad bepaalde in 2014 expliciet dat standaardsoftware onder de kooptitel valt en daarmee aan de conformiteitseis moet voldoen. Alleen hm: is er wel sprake van een koop? Je koopt immers niet de app, die krijg je gratis. Je betaalt voor de dienst van Spotify, en dat zie ik als wezenlijk wat anders.

Onrechtmatige daad? Strijd met een wettelijke plicht of inbreuk op een recht, die zie ik niet. Dus dan houd ik over de maatschappelijke zorgvuldigheid, zeg maar dit dóe je gewoon niet. Dit is niet netjes, ook al staat het niet als verbod in de wet. Dat kan altijd, maar sterk vind ik ‘m niet.

Oké, er is een oplossing maar helemaal lekker zit het me niet. Ik vermoed dat dit zo’n ding is waar niemand ooit over nagedacht heeft. Sinds wanneer kan software immers hardware pijn doen (HCF daargelaten)

(Ongetwijfeld staat er in de Spotify EULA iets over geen aansprakelijkheid voor welke schade dan ook, maar ongezien mijn juridische hoela voor zo’n voorwaarde.)

Arnoud

Ben ik nog aansprakelijk als ik het IE op mijn software overdraag?

| AE 9038 | Aansprakelijkheid, Software | 8 reacties

software-disc-cd-dvd-dragerEen lezer vroeg me:

Voor een klant heb ik maatwerksoftware ontwikkeld. Zij willen nu het intellectueel eigendom daarop verkrijgen. Op zich prima, alleen wil ik dan geen aansprakelijkheid meer voor fouten. Ik heb er dan immers geen controle meer over. Daar reageerden ze heel verbaasd op. Maar dit is toch geen gekke vraag?

Nee, een gekke vraag is dit niet. Maar ik kan me de verbazing ook wel weer een beetje voorstellen.

Aansprakelijkheid en intellectueel eigendom staan in principe los van elkaar. Aansprakelijk ben je als je een fout maakt in de opdracht, en dat heeft niets te maken met wie eigenaar wordt van de auteursrechten op het resultaat.

De verwarring hier gaat volgens mij over fouten die de opdrachtgever aanbrengt nadat de software klaar is. Wie het auteursrecht verwerft, mag ook zelf gaan knutselen in het geleverde. Maar het is natuurlijk evident dat je de leverancier niet aansprakelijk kunt houden voor je eigen fouten. Dit heeft niets te maken met eigendom op het werk. Als ik een huis laat bouwen, is de aannemer aansprakelijk voor fouten terwijl ik er eigenaar van ben. Hetzelfde gebeurt bij auteursrechten.

Het lijkt me wel verstandig dit even uit te werken in het contract, om bewijsproblematiek te verkleinen. Je zegt dan bijvoorbeeld dat iets alleen een fout is als het ook zit in de code zoals overgedragen. Je hebt dan een manier nodig om vast te leggen exact welke code dat is. Denk aan een hash, een lijst bestandsnamen met datum en grootte of het nummer van een github-repository.

Arnoud

Je bent als bedrijf aansprakelijk voor stiekem geïnstalleerde software door je werknemer

| AE 8865 | Arbeidsrecht, Software | 28 reacties

Een werkgever is aansprakelijk voor illegale software geïnstalleerd door een werknemer, en daarbij maakt het niet uit of dat expliciet verboden was door de werkgever. Dat maak ik op uit een recent vonnis (via) van de rechtbank Rotterdam. Er is sprake van zogeheten risico-aansprakelijkheid: ongeacht wat je doet, je draait op voor eventuele inbreuken op… Lees verder

Mag een browserextensie je waarschuwen voor oplichters?

| AE 8707 | Meningsuiting, Software | 20 reacties

Afgelopen maand heb ik in de avonduren een chrome extensie ontwikkeld die op elke webpagina zoekt naar IBAN, telefoonnummer, e-mailadressen, las ik (dank, tipgever) bij Gathering of Tweakers. De poster was slachtoffer van oplichting geworden en ontdekte dat hij dit had kunnen voorkomen door even dergelijke gegevens door Google te halen. Vandaar de extensie: de… Lees verder

Mag een licentie je verbieden Kwaad te doen?

| AE 8555 | Contracten, Open source, Software | 11 reacties

Een lezer vroeg me: Onlangs vond ik de zogehten Do no evil-licentie. De JSON licentie zegt “The Software shall be used for Good, not Evil”. Is zoiets juridisch afdwingbaar, of wat zou de rechter hiermee doen? De licentie voor JSON (een protocol voor data-uitwisseling in Javascript) is voor 94,9% gelijk aan de bekende simpele MIT… Lees verder

Mag je systemen testen met productiedata met persoonsgegevens?

| AE 8523 | Privacy, Software | 8 reacties

Een lezer vroeg me: Bij mijn laatste klant kreeg ik te horen dat ik bij de update van hun software wel mag testen, maar alleen met nepgegevens. Het argument was dat hun klanten geen toestemming hadden gegeven voor gebruik van hun data voor testdoeleinden. Deed ik dat toch, dan zouden ze de boetes wegens datalekken… Lees verder

Hoe een merkenclaim tijdelijk het internet stukmaakte

| AE 8525 | Auteursrecht, Merken, Open source, Software | 23 reacties

Whoa. Elf regels code weghalen leidde tot een stukgegaan internet, las ik bij BusinessInsider. Dit was het onverwachte gevolg van een merkenclaim van sociaal netwerk Kik tegen softwaremodule Kik. Op basis van die claim werd de module weggehaald, waar de developer zo boos over werd dat hij al zijn code weghaalde. Waaronder dus die ene… Lees verder

Mag de HEMA haar fotosoftware zomaar uitzetten?

| AE 8466 | Aansprakelijkheid, Innovatie, Software | 35 reacties

Deze software wordt op 16 februari 2016 vervangen door een geheel nieuwe versie, las ik in de Google Cache. Want de huidige pagina werkt niet meer, net zo min als de software zelf. En daarmee hadden mensen toch jarenlang fotoalbums opgebouwd. Het haalde onder meer de kranten. Kan de HEMA die software zomaar uitschakelen? Omdat… Lees verder

Mag ik MS Office retourneren omdat Outlook er niet bij zit?

| AE 8272 | Contracten, Software, Webwinkels | 29 reacties

Een lezer vroeg me: Ik heb een download gekocht van Microsoft Office in de “Home and student” editie. Na installatie ontdekte ik dat Outlook geen deel is van deze editie. Heel vervelend, want hier was ik juist op uit. De (zakelijke) verkoper zegt nu dat ik me beter had moeten inlezen en geen geld terug… Lees verder