Internetrecht door Arnoud Engelfriet

In een artikel over Noord-Korea’s Red Star Linux meldde Webwereld:

Zoals valt te verwachten wordt de broncode niet gedeeld, en schendt de Noord-Koreaanse staat dus de GPL-licentie die aan Linux gekoppeld is

Waarom dat te verwachten was, ontgaat me. Maar ik vroeg me toen wel af, kan de GPL in Noord-Korea wel geschonden worden? In ieder geval wat Linux betreft dan.

Bestaat auteursrecht in Noord-Korea? Jazeker: de North Korea Copyright Act (vertaling door KoryoPAT). Software wordt genoemd (artikel 9 sub 8).

Geldt dat ook voor plutocratische imperialistenbuitenlanders? Jazeker, de Democratische Volksrepubliek Korea is lid van de Berner Conventie sinds 2003. En daarmee erkent het land buitenlandse auteursrechten.

Dat biedt dus hoop voor Linus en zijn medeprogrammeurs. Maar in de wet op auteursrecht op software staat een opmerkelijke bepaling (artikel 2):

Registration of software is the prime process in the protection of software.

Software wordt dus alleen beschermd na registratie. Ook als de software uit het buitenland komt:

The copyright of a software that has been developed by a foreign legal person or an individual and registered first in the DPRK shall be protected by this law.

Nu is dat een probleem, want de Berner Conventie verbiedt registratie als eis alvorens auteursrechten toe te kennen. Je zou dus als Linux-auteursrechthebbende in een Noord-Koreaanse rechtbank op grond van de Berner Conventie kunnen eisen dat je auteursrechten direct worden erkend, ook zonder registratie. Ik ben heel benieuwd wat de reactie zal zijn.

Verder staat er nog in artikel 35 een leuke bepaling die heel relevant voor open source lijkt te zijn:

One may copy and use a software without the permission of the copyright holder in the following cases; … * When the software has been distributed free of charge.

Linux wordt zonder vergoeding verspreid en zou daarmee onder deze uitzondering kunnen vallen. (Natuurlijk, je mag geld vragen voor Linux maar er staat “has been distributed” en dat is zeker het geval bij Linux.) In feite staat hier dat het concept van open source niet kan bestaan in Noord-Korea, want alle software die eenmaal legaal gratis in omloop is gekomen, valt onder deze uitzondering.

Alles bij elkaar lijkt de conclusie dat Red Star de GPL schendt ietwat prematuur.

Arnoud

Via-via kwam ik op het Alientrap forum waar een interessante discussie liep over het mixen van GPL code met anders gelicentieerde code. Meer specifiek: kun je plaatjes die onder Creative Commons zijn, eigenlijk wel laten verschijnen in een programma dat onder GPL uitgebracht is?

Hoofdregel van de GPL open source licentie is dat “verveelvoudigingen in gewijzigde vorm” of ook wel “afgeleide werken” alleen mogen worden verspreid onder diezelfde GPL voorwaarden. Hoe je precies een “afgeleid werk” herkent, is al jaren een lastige vraag voor juristen. Er zijn allerlei theorieën, variërend van “alleen gewijzigde bestanden” tot “alles dat je meelinkt” tot zelfs “alles waarbij de intentie is dat het nauw samenwerkt”. Ik besprak dit een tijd geleden in de context van plugins (Joomla of phpBB).

Het bijzondere in deze discussie is dat het nu eens niet gaat over combinaties van software met software, maar over combinaties van software met data zoals plaatjes of muziek. Kun je bijvoorbeeld een icoon laten verschijnen in de interface van een GPL programma dat zelf onder Creative Commons uitgebracht is? Of een helptekst uit Wikipedia halen?

De discussie werd kernachtig samengevat als:

Whether it is allowed to mix licenses in such a way has not been decided in any court yet, so both views may be possible. However, think about this: if it WERE allowed to mix GPL code with non-GPL data, why wouldn’t it be allowed to link GPL code against non-GPL libraries (and vice versa)? The library is just as dynamically loaded as the content. Yet still it is the common legal opinion that GPL code can NOT be linked against non-GPL libraries. The engine loads the data just like it loads its libraries (DLLs). Why should these be considered different, legally?

Het verschil zit hem niet zozeer in het laden, maar in het gebruik van de materialen nadat deze geladen zijn. Code wordt uitgevoerd, en mixt daar met de code die al geladen is. Een plaatje wordt geladen en doorgegeven, dat blijft in principe geïsoleerd van de code die aan het draaien is. Het lijkt me moeilijk om te betogen dat het plaatje op welk moment dan ook onderdeel van de applicatie is.

De enige mogelijkheid die ik zie is dat alles dat in de context van die applicatie op het scherm verschijnt, daar onderdeel van is. Een icoontje verschijnt als onderdeel van de knoppenbalk, en een kaart voor een spel verschijnt in het gebied waar je met je avatar rondloopt. Maar dan is de tekst die ik nu in dit editvenster typ, ook een afgeleid werk van mijn blogsoftware Wordpress. En de webpagina’s die in mijn Firefox verschijnen zijn afgeleide werken van die browser. Nee, dat wil er bij mij niet in.

Het zou misschien anders worden als de plaatjes echt als onderdeel van de applicatie worden geïntegreerd, bv. zoals Windows-applicaties het icoontje voor op de desktop met zich meedragen. Dat icoon zit echt fysiek in de applicatie zelf, en zou dus als onderdeel daarvan kunnen worden gezien. Maar een icoon dat los in een map op de harde schijf staat? Nee.

Arnoud

Bij Wikipedia vond ik een discussie over het kunnen intrekken van een Creative Commonslicentie. De aanleiding was zo te lezen dat iemand zijn CC-foto ergens op zag duiken zonder de verplichte naamsvermelding erbij. Daar wilde hij actie tegen ondernemen, maar heeft dat veel nut als de foto als Creative Commons online staat? De inbreukmaker kan immers achter zijn rug om snel de naam erbij zetten en dan heel onschuldig kijken.

Een oplossing kan zijn gauw je foto overal verwijderen (of in ieder geval de Creative Commonslicentievermelding weghalen) en dan pas gaan klagen. Het juridische idee hierachter is namelijk dat de Creative Commonslicentievermelding (Creativecommonslicentievermelding? Creative-Commonslicentievermelding? Argh.) een aanbod is. Als je dat aanbod intrekt voordat de wederpartij het heeft kunnen aanvaarden, dan is het niet meer geldig.

Ene Wimmel vat mij samen:

[A]ls ik een aanbod doe een afbeelding aan jouw te licenseren onder bijvoorbeeld CC-BY, kan ik dat aanbod intrekken zolang jij dat nog niet hebt aanvaard. Heb je het wel aanvaard (en gebruik je die afbeelding dus onder de CC-BY voorwaarden), kan ik dat niet intrekken. Als een afbeelding op wikipedia zelf gebruikt wordt, kan ik dat dus ook niet stoppen. Maar wel verdere verspreiding voorkomen, waardoor het niet meer aan de doelstellingen van wikipedia voldoet.

Op zich klopt dat helemaal. Er is echter één angel hier: wat gebeurt er als iemand de foto plus de Creativecommons-licentievermelding (argh) van een derde ontvangt en dan mijn aanbod aanvaardt, terwijl ik net bezig ben overal die vermeldingen te verwijderen? Dan zit ik er toch gewoon aan vast, lijkt me zo. Ik heb het aanbod gedaan, en iemand die dat aanbod aanvaardt, mag de foto verspreiden. In mijn licentie staat dat die iemand dan alle ontvangers erop moet wijzen dat de Creative Commons-licentievermelding (argh) van toepassing is. Daarmee nemen al die ontvangers ook kennis van mijn aanbod.

Oftewel: ik kan mijn aanbod wel willen intrekken, maar zolang er ook nog maar één kopie ergens legaal online staat, is het altijd mogelijk de creativeCommonsLicentieVermelding (ARGH) alsnog te aanvaarden. Ik kan van een licentienemer niet verlangen dat hij de foto offline haalt, of dat hij die ARGH intrekt. Ik kan het vriendelijk vragen maar hij is niet verplicht mee te werken zolang hij zich netjes aan de voorwaarden uit de ARGH houdt.

En noodzakelijk gevolg van dat netjes de voorwaarden naleven is dat anderen mijn aanbod te zien krijgen en het daarmee kunnen aanvaarden. Ik krijg dus nooit meer de kans om tijdig aan hen te melden dat het aanbod is ingetrokken.

Arnoud

Een lezer mailde me:

Wij gebruiken al een flink aantal jaren een bepaald softwarepakket voor onze bedrijfsvoering. De leverancier heeft het onderhoud vorig jaar gestaakt, en dat begint nu een probleem te worden. We zouden nu graag een ander wat noodzakelijk onderhoud laten uitvoeren, en een paar nieuwe features inbouwen. Maar kan dat zomaar?

Nee, dat kan niet zomaar. De auteursrechten op het pakket liggen nog steeds bij die leverancier, en dat betekent dat je zijn toestemming nodig hebt om het pakket te mogen wijzigen. En dat gaat geld kosten, zeker als je ook nog eens de broncodes wilt hebben. In de meeste gevallen vermeldt het contract niets over de mogelijkheden van onderhoud nadat de leverancier ondersteuning heeft beëindigd.

Het is wel toegestaan dat de nieuwe ontwikkelaar de API’s en interfaces achterhaalt en op basis daarvan eigen modules maakt. Daarvoor heb je geen medewerking van de huidige leverancier nodig. Ik hoop voor je dat de software dergelijke interfaces heeft op een eenvoudig te achterhalen manier.

Er is bar weinig jurisprudentie op dit gebied. Als het gaat om maatwerksoftware, dan is er het arrest Van Genk/De Wild kun je dan aanspraak maken op de broncodes om zo onderhoud te verrichten. Wel moet het contract dan bepalen dat je de volledige eigendom krijgt van de maatwerksoftware (een gebruikelijke bepaling overigens). Maar bij standaardsoftware kun je het vergeten.

Er zijn genoeg bedrijven die dan maar de code afschrijven en een nieuwe codebase laten bouwen waarbij ze wel de gewenste rechten hebben. Steeds meer kiezen daarbij voor open source, omdat je dan per definitie dit probleem niet hebt.

Arnoud

Al eerder gemeld, maar nu is het definitief: de nieuwe open source licentie voor open en vrije databanken. Databanken bevatten vooral feitelijke data, en er komt zelden creativiteit aan te pas. Bestaande open source licenties zijn eigenlijk vooral bedoeld voor software, en ook de Creative Commons-licenties passen niet goed bij databanken. Vandaar deze nieuwe licentie.

De licentie noemt expliciet drie rechten: auteursrecht, databankenrecht en het recht op toegang tot de databank. Recht op toegang? Ja, wie een database publiceert, of algemener gezegd wie een dienst aanbiedt met een server, kan op grond van zijn eigendomsrecht op die server regels stellen over het gebruik van die dienst. Daar hoef je uiteindelijk helemaal geen intellectueel eigendomsrecht voor te hebben. Slim gevonden dus.

Ik heb al een paar keer (deel 1, deel 2, deel 3) aandacht besteed aan de vraag hoe het zit met afgeleide werken, kaarten die gemaakt worden op basis van de OpenStreetmap-databank. Ik kom volgende week met deel 4 trouwens, beloofd.

De ODBL is speciaal geschreven voor dit soort situaties. De definities bevatten de term “Produced Work”, en die luidt als volgt:

a work (such as an image, audiovisual material, text, or sounds) resulting from using the whole or a Substantial part of the Contents (via a search or other query) from this Database, a Derivative Database, or this Database as part of a Collective Database.

En het is natuurlijk de bedoeling dat zo’n Produced Work net zo vrij beschikbaar is als de oorspronkelijke brondatabase. Vandaar:

If You Publicly Use a Derivative Database or a Produced Work from a Derivative Database, You must also offer to recipients of the Derivative Database or Produced Work a copy in a machine readable form of:

a. The entire Derivative Database; or
b. A file containing all of the alterations made to the Database or the method of making the alterations to the Database (such as an algorithm), including any additional Contents, that make up all the differences between the Database and the Derivative Database.

Onder “Use” wordt dan weer verstaan “alles wat normaal onder auteursrecht of databankenrecht valt, maar in ieder geval kopiëren, verspreiden, openbaar maken etcetera”. En “publicly” wil hier zeggen “naar personen die niet voor jou werken”.

Kort gezegd: wie een kaart maakt van een ODBL-databank, en deze kaart online aanbiedt aan het publiek, moet de databank erbij doen inclusief alle wijzigingen die hij op de databank heeft doorgevoerd.

En dat geldt zelfs als blijkt dat je helemaal geen recht hebt op grond van je auteurs- of databankenrecht om zoiets te eisen: het is immers een gebruiksvoorwaarde om toegang te krijgen tot de site. Op zich is dat slim bedacht, hoewel ik me afvraag in hoeverre dat ook echt werkt. Tegenover de persoon die dit accepteert en de site bezoekt lijkt het me wel rechtsgeldig. Die gaat het contract aan, en kan daar in principe aan gehouden worden. Uit het XS4All/Ab.Fab-arrest van de Hoge Raad blijkt dat je als eigenaar van een site in principe elke voorwaarde aan het gebruik mag stellen die je wilt. Maar tegenover derden? Dat kan nog een hele interessante worden.

Arnoud

En daar waren we dan weer met deel drie van de vraag welke rechten er op de databank van het vrijelandkaartenproject Openstreetmap zitten. Al in deel 1 bleek dit een lastige kwestie. Want: wat wordt nu precies waarvan afgeleid? (Waar vanaf geleid? Waar van afgeleid? Argh.) In deel 2 leek de tussenconclusie te zijn dat de kaarten gemaakt uit de OSM-database een afgeleid werk lijken te zijn van de stylesheet.

Kaarten uit OpenStreetmap worden namelijk gemaakt door een grote hoeveelheid GPS-coördinaten in een databank te stoppen en te voorzien van verbindingen die labeltjes krijgen met bijvoorbeeld “fietspad” of een straatnaam. Op basis van die databank kun je dan kaarten genereren voor elk oppervlak en op elke schaal die je wilt. Die stylesheet bepaalt welke kleuren en dergelijke er in die kaarten terechtkomt. Een voorbeeld uit de OSM-documentatie:

Het lijkt me dus zeker verdedigbaar dat een stylesheetmaker een auteursrecht kan claimen op de stijlkeuzes. Maar is een kaart een afgeleid werk van de stylesheet?

Ik vermoed van wel, al zal het afhangen van welke elementen uit de stylesheet zelf in de kaart terechtkomen. Want een afgeleid werk moet wel op een of andere manier concrete beschermde elementen uit het werk overnemen waar het van afgeleid is. Nu hoeft dat niet letterlijk - een toneelstuk is een afgeleid werk van een boek bijvoorbeeld, zelfs als de spelers geen woord letterlijk zeggen zoals het in het boek staat. In die situatie zijn zaken als het plot, de karakters, uiterlijk, verloop en dergelijke van het verhaal overgenomen, en dat is al genoeg.

Maar: wat neem je over uit de stylesheet in de kaart die uiteindelijk gegenereerd wordt? De kleurkeuzen in ieder geval, en de kleur en positionering van teksten zo te zien ook. De derde kaart uit dit voorbeeld heeft bijvoorbeeld veel duidelijker aanduidingen van plaatsnamen dan de andere drie.

Opvallend (voor mij dan) is dat ik geen enkele stylesheet kan vinden waar een expliciete licentie bij staat. De meest gebruikte stylesheet is Mapnik maar zelfs daarvan zie ik nergens wat daarmee mag. Ik neem aan dat ze onder dezelfde Creative Commonslicentie horen te vallen als de rest van het project, maar het staat nergens.

Nou, en nu eens inlezen in het databankenrecht zoals dat geldt voor kaarten.

Arnoud

Google Chrome, de minimalistische browser van het advertentie- en zoekmachinebedrijf bevat veel open source. Recent bleek de browser echter ook de open source FFMPEG videosoftware te bevatten om zo filmpjes op webpagina’s beter te kunnen afspelen. En dat is opvallend, omdat FFMPEG onder de LGPL 2.1 open source licentie is uitgebracht. De verhouding tussen LGPL 2.1 en de MPEG-octrooilicenties is op zijn zachtst moeilijk te noemen.

Wie MPEG-functionaliteit aan zijn product wil toevoegen, heeft octrooilicenties nodig. Organisaties als MPEG-LA verstrekken dergelijke licenties, uiteraard tegen betaling. Daarbij geldt de eis dat je alleen voor je eigen producten kunt betalen: maakt de klant een kopie, dan moet die zelf een nieuwe licentie komen halen. Iets dat moeilijk ligt bij open source software, omdat het daar juist de bedoeling is dat klanten het ook weer kopiëren en verspreiden.

De LGPL bevat namelijk een aantal clausules die bedoeld zijn voor deze situatie. De belangrijkste is artikel 10:

You may not impose any further restrictions on the recipients’ exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties with this License.

Oftewel: u mag anderen geen beperkingen opleggen op de rechten die u zelf krijgt van de LGPL. Deze clausule maakt het, zo werd altijd aangenomen, erg moeilijk om open source te gebruiken als daarvoor betaalde octrooilicenties van derden nodig zijn. Maar, wat zegt nu Google’s open source program manager Chris DiBona:

(a) Party A gives Party B a library licensed under the LGPL 2.1
(b) Party B gets a patent license from Party C
(c) Party B then distribute the library under the LGPL 2.1

This situation is *not* prohibited by the LGPL 2.1 (see the LGPL 3.0 for a license that does deal with this situation). Under the LGPL 2.1, the fact that Party B may have a patent license with an unrelated third-party is irrelevant as long as it doesn’t prevent Party B from granting people the rights LGPL 2.1 requires they grant them (namely, only those rights it in fact received from Party A).

Oftewel (ik krijg er ook hoofdpijn van): het “further restrictions” gaat om restricties die de verspreider van de software oplegt, terwijl de MPEG-licentie een restrictie van een derde is. Google kan er niets aan doen dat derden een betaald licentieprogramma hebben op de software die zij van FFMPEG hebben gekregen.

Meer to-the-point is DiBona’s collega Daniel Berlin verderop:

Nowhere in the LGPL 2.1 are we required to grant you patent rights that we may have.

Dat is op zijn minst een originele interpretatie te noemen. In artikel 11 van de LGPL staat namelijk:

If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Library at all. For example, if a patent license would not permit royalty-free redistribution of the Library by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Library.

De gebruikelijke interpretatie van dat voorbeeld is dat een octrooilicentie gratis voor de hele wereld moet zijn, wil de licentienemer in staat kunnen zijn de software onder LGPL te mogen verspreiden. Maar Google komt nu met de creatief gevonden interpretatie dat de MPEG-licentie haar niet verbiedt de software onder de LGPL te verspreiden. Helaas krijgen afnemers geen MPEG-licentie, maar dat is niet verplicht volgens de LGPL.

In Google’s visie moet de MPEG-licentie zeggen “U dient ervoor te zorgen dat uw afnemers geen kopieën maken van de MPEG-software” voordat haar verspreiding de LGPL zou overtreden. Maar dat doet deze niet - er staat alleen “u moet betalen per kopie die u verspreidt”. En zolang Google dat maar braaf doet, is er weinig aan de hand. Chrome-gebruikers mogen de MPEG-functionaliteit gebruiken. Alleen, als ze kopieën gaan maken is dat geheel op eigen risico.

Helaas loopt de discussie een beetje snel dood nadat Håkon Lie zich erin mengt met terechte en kritische vragen - Lie is van Chrome-concurrent Opera. Het is namelijk een zeer fundamentele vraag.

Persoonlijk zou ik het Google-standpunt niet snel durven verdedigen, hoewel ik er niet meteen grote gaten in kan schieten. Het is evident de bedoeling van de LGPL om dit soort uitzonderingsposities tegen te gaan. Maar aan de andere kant, er waren hele lappen tekst GPLv3 nodig om het op te schrijven dus het staat er niet expliciet. En als de bedoeling er niet staat, heeft over het algemeen de licentiegever pech.

Arnoud

Op het NedLinux forum mailde men mij over een interessante vraag:

De vraag is alleen (wat me bezig houdt), in hoevere is de codecs die niet officieel aangeschaft zijn illegaal ? Ik bedoel…. hoe is dat geregeld in Nederland ? Ik zie dat Frankrijk al erg moeilijk doet als je VLC gebruikt of Mplayer.

Een codec is een stuk software waarmee audio of video ge(de)codeerd kan worden. Wie alleen naar de radio luistert en DVD’tjes koopt in de winkel en die afspeelt op zijn DVD-speler, heeft daar niet zo veel mee te maken. Maar als je muziek en films gaat downloaden dan kom je allerlei rare formaten tegen en moet je de bijbehorende codecs gaan installeren. Sommige codecs zijn makkelijk te vinden, voor anderen moet je op vage Russische sites rondspeuren.

Maar mag dat nou zomaar? Dat is een moeilijke vraag, want er spelen een heleboel aspecten mee.

Auteursrecht op de codec
Ten eerste is er de vraag of die codec zelf (de DLL dus) wel legaal verspreid mag worden. Er zijn gevallen genoeg bekend van simpelweg gestolen codecs: mensen kopen software waar codecs bij zitten en zetten die gewoon op internet. Zo zijn er complete collecties met Windows Media A/V codecs, die echter gewoon uit de C:\Windows\System directory van iemands Windows-PC afkomstig zijn. Ook enkele Quicktime-codecs zouden op die manier verkregen zijn.

Wordt een codec op die manier verspreid, dan is het niet toegestaan om die te downloaden en te gebruiken. De thuiskopie-uitzondering geldt niet voor software en dus ook niet voor codecs. Dat je toevallig ergens een Windows-licentie hebt liggen, verandert daar niets aan lijkt mij; die hoort bij jouw aangeschafte Windows en kun je niet zomaar van toepassing verklaren op alle Microsoft-software die je downloadt.

Octrooien op de algoritmen
Ten tweede implementeren veel codecs namelijk beschermde algoritmen. De octrooihouders hebben geen licenties gegeven voor die codecs, zodat vrije verspreiding niet zomaar mogelijk is. Voor persoonlijk niet-commercieel gebruik hoef je je geen zorgen te maken, octrooi-inbreuk is alleen mogelijk als je commercieel bezig bent.

Ik hoor nu een aantal mensen “jamaar softwarepatenten zijn niet geldig in Europa” denken. Nou is dat een heel grijs gebied, maar als we het hebben over audio/video-coderen zit je toch aan de witte kant van dat gebied. Het manipuleren van audiovisuele signalen is een vorm van technologie en valt daarmee onder de octrooiwetgeving. Er zijn dan ook genoeg octrooien op dit gebied, die in rechtszaken ook gewoon overeind blijven. Het verkopen van audio/video-afspeelsoftware of apparaatjes met zulke codecs erin betekent dus dat je een octrooilicentie moet kopen.

En ja, open source codecs hebben daar een probleem. Want de meeste van die octrooilicenties voorzien niet in de mogelijkheid dat de licentienemer de codec gaat doorleveren aan derden die ook weer kopieën van de codecs gaan maken. En de GPL heeft weer een bepaling dat die octrooilicentie daar wél toestemming voor moet geven, anders mag je de software in het geheel niet verspreiden. Een soort van Mexican standoff dus.

Kopieerbeperkingen omzeilen
Ten derde willen sommige codecs nog wel eens kopieerbeperkingen negeren. Het beroemdste voorbeeld is DeCSS, waarmee de beveiliging op DVD-inhoud omzeild kan worden. Nu is dat strikt gesproken geen codec, maar als je een codec voor DVD content wilt gebruiken, kom je niet ver zonder deze functionaliteit.

Het omzeilen of uitschakelen van “effectieve” kopieerbeveiligingen is verboden, net als het verspreiden van hulpmiddelen die daar speciaal voor gemaakt zijn. Volgens een Finse rechtbank zou DVD-beveiliging CSS niet effectief zijn omdat het zo eenvoudig te breken bleek. Daarom was DeCSS niet verboden.

Oh ja, dat verbod geldt zowel in Amerika (onder de DMCA) als bij ons in Europa onder de Auteursrechtenrichtlijn en artikel 29a Auteurswet.

Sommige codecs voor Windows Media (WMV/WMA) omzeilen de DRM-functies die Microsoft er in gebouwd heeft. Dat was in één geval in ieder geval aanleiding voor Microsoft om een rechtszaak te beginnen, maar een jaartje later trokken ze die weer in. Overigens zonder uit te leggen waarom, dus dat schiet niet erg op.

Er is dus niet een duidelijk ja/nee-antwoord te geven op deze vraag. Het hangt af van de codec, waar deze vandaan komt en welk algoritme er gebruikt wordt. Codecs die bv. bij Fluendo te koop zijn, mag je legaal gebruiken. Die zijn door het bedrijf zelf ontwikkeld, zodat je voor auteursrechtschendingen niet bang hoeft te zijn. Die codecs komen ook met een octrooilicentie en omzeilen geen kopieerbeveiligingen.

Ook de Ogg Vorbis- en Theora-codecs zijn legaal, om dezelfde redenen. Al heeft niemand ooit kunnen bewijzen dat deze technieken octrooivrij zijn.

Download je van voornoemde vage Russische site een gratis exemplaar van de commercieel verkochte DivX-codecs, dan zit je in het donkergrijs tot zwarte gedeelte van dat grijs gebied. En heb je waarschijnlijk ook een Trojan of drie op je PC.

Arnoud

Bij de discussie van vorige week over het vrijelandkaartenproject Openstreetmap vroeg een oplettende lezer in de comments:

Er zijn mensen (zoals ik) die er niet van overtuigd zijn dat het genereren van tiles een creatief werk is en je er dus ook geen CC-licentie op kan plakken. Heeft iemand daar wel eens serieus naar gekeken?

De auteurswet noemt expliciet “aardrijkskundige kaarten” als auteursrechtelijk beschermde werken (art. 10 lid 1 sub 7 Auteurswet). Je zou dus zeggen dat die kaart van OpenStreetmap gewoon beschermd is, ook als ze die voor het gemak aanleveren als “tiles”, blokjes van 256×256 pixels.

Alleen, de makers van de auteurswet dachten daarbij volgens mij meer aan cartografen die met de hand een kaart tekenden (hoi pap!). En dat is natuurlijk niet hoe OpenStreetmap werkt: men gebruikt een database met punten en verbindingslijnen gebaseerd op GPS-coördinaten die mensen aanleveren. Die kunnen voorzien zijn van tags met bijvoorbeeld de naam van een weg of de aanduiding ‘waterway=river’ om aan te geven dat iets een rivier is.

Het proces om van die getagde punten en lijnen een kaart te maken heet renderen. Dat kan op verschillende manieren, afhankelijk van je eigen smaak: wil je rode wegen en steden geel, of liever het water in een lichtere tint blauw? Geen probleem, verander de instellingen en render opnieuw.

Dat proces is op zichzelf volledig geautomatiseerd en dus niet creatief. De uitvoer kan echter wel creatief zijn - wanneer de invoer dat ook is. Een OpenStreetmap kaart, of een individuele tile daaruit, kan dus beschermd zijn maar het hoeft niet.

De hamvraag is dus: is een verzameling getagde punten en lijnen auteursrechtelijk beschermd?

Het probleem daarbij is dat de OSM-mensen streven naar een zo accuraat mogelijke kaart. Accuratesse is de doodsvijand van creativiteit en daarmee ook van auteursrecht. Wie zomaar drie rode strepen trekt, heeft een beschermd werk, maar wie een hele middag zorgvuldig noteert hoe het fietspad achter zijn huis loopt, heeft dat niet.

Een twee jaar oud voorbeeld uit de rechtspraak:

Voor zover een kaart het resultaat is van de selecties en keuzes die een persoonlijke visie van de maker weergeven is sprake van een werk met een eigen, oorspronkelijk karakter dat het stempel van de maker draagt en is het als zodanig auteursrechtelijk beschermd. De bescherming van de kaart is derhalve beperkt tot de eigen niet voor de hand liggende vormgeving van de betrokken kaart.

De kaart in kwestie was een zeekaart, waarbij de grenzen op zee zo te lezen naar eigen inzicht van de maker werden getrokken. En dat was een belangrijke reden om de kaart beschermd te achten.

De keuze van die indeling houdt deels verband met de functionaliteit van het systeem dat bij de informatiedienst hoort, en is deels gebaseerd op de persoonlijke keuze van de heer Svensson, die ondermeer is ingegeven door het streven naar gebruiksvriendelijkheid van de informatiedienst.

De vraag is dus: hoe worden in het OpenStreetmap project de punten en lijnen getrokken, en welke mate van eigen persoonlijke keuzes van de OpenStreetmappers?

Arnoud

Op de discussielijst van het OpenStreetmap project een interessante discussie over het mixen van kaartgegevens uit verschillende bronnen. Een bedrijf had data uit het Nationaal Wegenbestand (NWB) en data uit de OpenStreetmap kaartgegevens gebruikt om kaarten mee te maken. OpenStreetmap gegevens zijn beschikbaar onder Creative Commons BY-SA, zodat afgeleide werken ook Creative Commons moeten worden. Hier vallen heel wat blogs over te schrijven, maar deze vond ik wel interessant om mee te beginnen:

Freek wrote:
> Ik heb het niet over jouw opmerking m.b.t. de accuraatheid van de NWB data. Ik
> heb het over mijn observatie dat de NWB laag OSM data bevat. Niet de straten
> voorzover ik kan zien, maar wel landuse e.d.
Dat is interessant want hiermee hebben ze het NWB CC-BY-SA gemaakt

Zo eenvoudig gaat dat niet. Ten eerste is mij niet duidelijk waarom deze combinatie een afgeleid werk zou zijn van de OSM-data. En ten tweede: zelfs al is dat het geval, dan is het niet zo dat die afgeleide werken automatisch ook onder de ShareAlike voorwaarden vallen. ShareAlike wil zeggen alleen dat wanneer je een afgeleid werkt maakt, je het resultaat alleen maar mag verspreiden onder diezelfde voorwaarde. Doet iemand dat niet, dan pleegt hij contractbreuk (of licentieschending, hoe je het maar wilt noemen). Maar het is geen automatisme dat CC-BY-SA dan op het resultaat ‘plakt’. ShareAlike is geen virus.

Overigens is het Nationaal Wegenbestand al enkele jaren terug gewobt: deze overheidsinformatie is vrij beschikbaar dankzij de Wet Openbaarheid van Bestuur. Alleen is de beslissing over hergebruik destijds aangehouden tot 2009. Nu is het volgens mij al een tijdje 2009, dus hopelijk komt daar snel een uitspraak over.

Arnoud