Busybox is een kleine handige tool waarmee embedded software omgevingen snel allerlei standaardfunctionaliteit kunnen realiseren. De tool is zeer populair (onder meer omdat er geen echte alternatieven zijn en de tool gewoon goed werkt) maar is dus onder de GPL gelicentieerd. En die eist dat je alle daarvan “afgeleide werken” onder GPL moet plaatsen als je deze verspreidt.

Productmakers negeren massaal de GPL, dus vonden de Busybox-mensen het tijd voor harde aktie, oftewel rechtszaken. Maar naar goed Amerikaans gebruik wordt er eigenlijk vooral geschikt, en het zijn de schikkingsvoorwaarden waar nu gedoe over is:

if you settle with SFC, they want you to provide them with copies of new products that contain Free Software before you release them, for a period of three years after you settle. You pay them about $5000 per product to audit the product (which is really cheap). If they say it’s infringing, you have to fix the infringement before you release the product. If you and SFC can’t agree, you can fall back on the court.

De SFLC controleert daarbij het gehele product op GPL-schendingen, en niet alleen op GPL-schendingen bij Busybox. En dat is iets waar productontwikkelaars dan weer moeite mee hebben. Zoals de ontwikkelaar van het alternatief het formuleert:

Litigants have sometimes requested remedies outside the scope of busybox itself, such as review authority over unrelated products, or right of refusal over non-busybox modules. This causes concern among chip vendors and suppliers.

Natuurlijk zal het gebruiken van dit alternatief niet betekenen dat je de GPL mag negeren. Alleen, afgezien van Busybox procedeert er bijna niemand, dus de praktische risico’s op betrapt worden zijn wel een stuk kleiner.

Helaas wordt de discussie dan bepaald onzuiver gevoerd: “You’ll be able to violate licenses with impunity” wordt de stromantekst van boeroepende GPL-promotors. En meneer is nog van Sony ook, weet u nog van die rootkit? Nee dat heeft hier niets mee te maken maar het is wél dat Sony. Dus tsja.

Persoonlijk zou ik zeggen: zolang Busybox het beste tooltje is voor je product, dan moet je echt Busybox blijven gebruiken. En de GPL naleven is helemaal niet zo moeilijk, dus wat exact is het probleem?

Open source is niet meer weg te denken in bedrijven en producten. Maar aan de naleving van de betreffende licenties schort het vaak helaas nog. Diverse rechtszaken hebben laten zien dat GPL en collega’s wel degelijk tanden hebben. Hoe kunt u nu uw cliënten het beste adviseren over hoe te handelen?

1. Arnoud Engelfriet; Vier typen uiteengezet
2. Armijn Hemel; Consumentenelektronica en overtredingen opsporen en
3. Stellingen

Lees de volledige recensie bij ITenRecht.

Regelmatig worden wij geconsulteerd door – voornamelijke kleine – softwarebedrijven die in goed vertrouwen een samenwerking zijn aangegaan die op een bepaald ogenblik toch ontspoort. Op dat ogenblik krijgen wij een verbouwereerde ICT-er aan de lijn, die ofwel niet betaald krijgt voor zijn diensten, ofwel het vertrouwen zodanig kwijt is dat hij of zij onder de overeenkomst uit wil.

Onze eerste vraag is steeds welke afspraken werden gemaakt bij aanvang van de samenwerking. Een gedetailleerde offerte, beantwoord door een orderbevestiging, een SLA of servicevoorwaarden kunnen dan soelaas bieden. Helaas pindakaas, net die contractuele afspraken ontbreken vaak. Wat we dan wel krijgen zijn mails, die uit hun aard eenzijdig zijn en vaak niet gedetailleerd.

Het geschil tussen Centric en Lizatec - waarover Webwereld.nl afgelopen vrijdag berichtte – maakt duidelijk dat ook grotere partijen nalaten duidelijke afspraken te maken. Centric, marktleider op het gebied van gemeentesoftware, daagde de specialistische ontwikkelaar Lizatec voor de kortgedingrechter, nadat de modernisering van gemeentelijke applicaties voor de registratie van vergunningen was vastgelopen. Het bedrijf Lizatec had in 2008 de opdracht ter waarde van bijna 1 miljoen euro gekregen om de broncode van de bestaande software, geschreven in de programmeertaal Delphi, om te zetten in .NET programmatuur.

Na wederzijdse verwijten zegde Centric de overeenkomst op. Na opzegging eiste Centric van Licatec de tools en ondersteuning te krijgen om zelf de klus af te maken. Hoewel partijen arbitrage waren overeengekomen, heeft Centric zich toch met succes tot de kortgedingrechter gewend. Die beval als ordemaatregel (noodoplossing) betaling van de openstaande facturen en vervolgens oplevering van de software een dag na ontvangst van de betaling én ondersteuning door Lizatec gedurende drie dagen. Daarbij liet de rechter in het midden of er ook voor de ondersteuning moet worden betaald. De stopzetting van de samenwerking krijgt na uitwerking van de nooodmaatregel dus nog een staartje.

Ook als de afspraken bij aanvang van de samenwerking niet helder waren, verdient het de voorkeur om over stopzetting duidelijke afspraken te maken. Zet de wederzijdse wrevel overboord en bepaal in een overeenkomst wat de gevolgen zijn van de stopzetting van de samenwerking. Maak afspraken over betalingen en/of oplevering die nog zal gebeuren. Besluit u de trekker eruit te trekken en elkaar niets meer verschuldigd te zijn, dan kunt u in een overeenkomst elkaar wederzijdse kwijting verlenen. Vertaald: u zegt tegen elkaar dat de stekker eruit is en dat partijen elkaar niets meer verschuldigd zijn. Zo vermijdt u dat er nog een staartje aan komt.

In deze middagworkshop leert u wat de belangrijkste knelpunten zijn en hoe u daarmee omgaat. Welke eisen stellen licenties als de GPL en hoe worden deze in de praktijk nageleefd? Middels een interactieve demo laat Armijn u zien hoe schendingen van de GPL worden opgespoord. De workshop is alleen toegankelijk voor advocaten en bedrijfsjuristen.

Het cursusprogramma:

13:30 Deuren open, ontvangst

14:00 Introductie: OSS licenties, theorie (Arnoud Engelfriet)

Open source licenties en hun compliance-aandachtspunten. Welke broncode moet
worden vrijgegeven, welke teksten moeten in de handleiding en waar moet nog
meer rekening worden gehouden? En wat zijn de consequenties als dat niet
gebeurt?

14:45 OSS compliance in de praktijk (Armijn Hemel)

De meeste opensourceproblemen doen zich voor bij software in
consumentenelektronica, die vaak in het Verre Oosten wordt gefabriceerd. Armijn
Hemel deelt zijn praktijkervaring met handhaving van GPL bij deze leveranciers.

15:15 Pauze

15:30 Detectie van OSS non-compliance (Armijn)

Hands-on demo: Met de door Armijn ontwikkelde Binary Analysis Tool wordt de embedded software in enkele apparaten geanalyseerd. Natuurlijk mag u meedoen!

16:30 Hoe nu verder? (Armijn en Arnoud)

Plenaire discussie: aan de hand van enkele stellingen en veel gehanteerde
vuistregels zoeken we naar best practices om open source compliance in de
praktijk te realiseren.

17:30 Netwerkborrel

Deelname aan deze workshop kost E 175 per persoon. Een tweede persoon van hetzelfde kantoor betaalt slechts E 150. (Bedragen zijn ex. BTW.) Voor dit bedrag ontvangt u tevens het boek Software: Deskundig en praktisch juridisch advies van ICTRecht en de GPL Compliance Manual van Armijn Hemel.

U kunt zich opgeven voor deze workshop per mail: info@ictrecht.nl. Tot twee werkdagen voor de datum van de cursus heeft u het recht om uw deelname kosteloos te annuleren. Bij annuleren binnen twee werkdagen blijft de prijs verschuldigd. U mag altijd een vervanger aanmelden; dit geldt niet als annulering.

Locatie: Igluu Utrecht, Jansdam 2a, 3512 HB Utrecht.

Permanente Educatie
U kunt zelf opleidingspunten voor deze workshop rekenen als u van mening bent dat deze uw vakbekwaamheid ten goede komt. Op grond van de Regeling vakbekwaamheid van de Orde van Advocaten kunt u dan aanspraak maken op 3 punten.

Over de docenten
Armijn Hemel is lid van het kernteam van GPL-Violations.org, dat met succes Europese schendingen van de GPL bestrijdt. Tevens is hij ontwikkelaar van de Binary Analysis Tool, waarmee schendingen van opensourcelicenties kunnen worden opgespoord.

Arnoud Engelfriet is ICT-jurist, gespecialiseerd in softwarelicenties. Hij is partner bij ICTRecht.nl. Daarvoor werkte hij negen jaar bij Philips, waar hij onder meer het open source beleid van het bedrijf ontwikkelde en implementeerde.

In de bewerkersovereenkomst die u als bewerker sluit met een verantwoordelijke (uw klant dus) kunt u veel vastleggen over wat wiens verantwoordelijkheid is. Zo kunt u vastleggen dat u niet aansprakelijk bent wanneer de opgeslagen gegevens auteursrechten schenden. Echter u kunt niet uw volledige aansprakelijkheid uitsluiten. Vooral niet tegenover de betrokkene, degene van wie de persoonsgegevens zijn.

Uit de Wet Bescherming Persoonsgegevens (Wbp) volgt dat uw klant verantwoordelijk is (hij wordt in de Wbp niet voor niets ‘de verantwoordelijke genoemd’) voor de verwerking van de door hem verzamelde persoonsgegevens. Dit betekent dat hij verantwoordelijk is voor alles wat er met die persoonsgegevens gebeurt, ook wanneer de persoonsgegevens door een ander – u dus – en niet op zijn eigen servers worden opgeslagen.

Wanneer er nu persoonsgegevens (zoals creditcardgegevens) van de klanten van uw klant op straat komen te liggen waarmee daarna wordt gefraudeerd, kan de betrokkene uw klant aanspreken om de geleden schade te vergoeden. Deze klant moest op grond van de Wbp immers voldoende maatregelen nemen om te waarborgen dat de persoonsgegevens van zijn klanten voldoende beveiligd waren voor een dergelijke onrechtmatige verwerking.

Het zou kunnen dat de fout feitelijk bij u lag (door bijvoorbeeld het ontbreken van voldoende beveiliging). Op grond van de gesloten bewerkersovereenkomst diende u immers ervoor zorg te dragen dat de persoonsgegevens voldoende beveiligd waren. De Wbp bepaalt dan ook dwingend dat de bewerker aansprakelijk is voor de schade voor zover deze door zijn schuld is ontstaan.

In de praktijk kan dit erop neerkomen dat de betrokkene u ook (of in plaats van de verantwoordelijke) rechtstreeks aansprakelijk stelt voor de geleden schade. Daarnaast kan het echter ook zo zijn dat de klant de schadevergoeding die hij heeft uitgekeerd op u gaat en kan verhalen. Deze regeling is dwingend: er mag in geen geval ten nadele van de betrokkene van worden afgeweken

Om niet voor verrassingen te komen staan is het dan ook verstandig in de bewerkersovereenkomst bepalingen op te nemen over aansprakelijkheden en verhaalsrechten over en weer. U kunt bijvoorbeeld afspreken dat indien er – ondanks dat u alle door de klant geëiste beveiligingsmaatregelen heeft genomen – toch een onrechtmatige verwerking van de persoonsgegevens heeft plaatsgevonden, uw klant de daardoor geleden schade niet op kan verhalen.

Hiermee kunt u echter niet beletten dat de betrokkene alsnog u aansprakelijk kan stellen. Tegen een dergelijke claim zou u nog kunnen inbrengen dat de schade niet aan u kan worden toegerekend omdat u naar uw weten het, naar uw en uw klant zijn mening, meest passende beveiligingsniveau voor de gegevens heeft gegarandeerd. Mocht een betrokkene dan toch een claim bij u indienen, dan kunt u contractueel afspreken dat uw klant die aan u zal compenseren.

De Wet Bescherming Persoonsgegevens (hierna: Wbp) stelt regels voor het opslaan, verzamelen, verstrekken en combineren (kort gezegd: het verwerken) van persoonsgegevens. Daarbij gelden verschillende regels voor de verantwoordelijke en de bewerker, zoals de Wbp ze noemt. De verantwoordelijke is degene die de doelen van en de middelen voor de verwerking van de persoonsgegevens vaststelt. De bewerker is degene door de verantwoordelijke wordt ingeschakeld om de verwerking uit te voeren.

Omdat uw klant bepaalt met welk doel, bijvoorbeeld facturatie, de persoonsgegevens worden opgeslagen en met welk middel (uw systeem) de persoonsgegevens worden verwerkt, wordt uw klant als verantwoordelijke voor de gegevensverwerking aangemerkt. Logischerwijs bent u dan de bewerker van de persoonsgegevens. U doet namelijk niets anders dan de persoonsgegevens opslaan voor de klant. U heeft geen zeggenschap over de gegevens. U kunt bijvoorbeeld niet zelfstandig besluiten een nieuwsbrief uit te sturen aan de klanten van uw klant. Maar als de klant opdracht geeft, dan moet u die nieuwsbrief versturen.

De klant is daarmee degene die door de betrokken personen aangesproken kan worden op schendingen van de Wbp. Maar u staat niet volledig hierbuiten. Uw klant moet namelijk op grond van de Wbp passende technische en organisatorische maatregelen ten uitvoer leggen om de persoonsgegevens te beveiligen tegen verlies of tegen andere vormen van onrechtmatige verwerking van de persoonsgegevens. Deze maatregelen kan uw klant uiteraard niet nemen wanneer de gegevens niet bij hemzelf, maar bij u op de server worden opgeslagen.

De Wbp bepaalt daarom dat uw klant ervoor zorg dient te dragen dat u een passend beveiligingsniveau biedt om een onrechtmatige verwerking te voorkomen van de persoonsgegevens die hij gaat opslaan in uw software. De klant moet dus bij u nagaan hoe u de opslag van persoonsgegevens heeft geregeld. Worden bestanden bijvoorbeeld versleuteld opgeslagen en wordt er gebruik gemaakt van een SSL-verbinding wanneer er gegevens vanuit de applicatie naar uw server worden verzonden?

Indien er geen sprake is van een passend beveiligingsniveau kan de klant besluiten naar een andere aanbieder te gaan of u verplichten strengere beveiligingsmaatregelen te nemen. Het is immers zijn verantwoordelijkheid hoe de gegevens bij u worden opgeslagen. Voor u geldt dan de vraag of u daarmee in wilt stemmen. Formeel gelden voor u namelijk op grond van de Wbp geen beveiligingseisen, behalve diegene waar u mee akkoord bent gegaan. De kans is echter groot dat wanneer u hier niet in mee wenst te gaan, of standaard geen goede beveiliging van de gegevens biedt, uw klant voor een andere aanbieder zal kiezen.

Indien u hiertoe wel bereid bent – of indien u reeds een passend beveiligingsniveau biedt – en de klant besluit zijn gegevens bij u op te slaan, moet er altijd een overeenkomst tussen u en de klant worden gesloten waarin de afspraken en verplichtingen over een weer worden vastgelegd. In deze zogeheten bewerkersovereenkomst wordt afgesproken

• voor welke doelen u de gegevens gaat verwerken,
• met welke middelen u de gegevens gaat verwerken,
• aan wie u de gegevens mag afstaan,
• welke beveiligingsmaatregelen u heeft genomen (of gaat nemen) om de opgeslagen gegevens te beveiligen,
• hoe aan de controle- en correctierechten van de betrokkene wordt voldaan,
• dat de klant u vrijwaart van aanspraken van derden met betrekking tot de persoonsgegevens.

Het is ook weer de verantwoordelijkheid van uw klant dat deze overeenkomst daadwerkelijk met u wordt gesloten. U zou kunnen overwegen om als extra dienstverlening naar uw klanten toe altijd een standaard bewerkersovereenkomst paraat te hebben die zij kunnen ondertekenen. Veel van uw klanten zijn er waarschijnlijk niet van op de hoogte zijn dat zij verplicht zijn een bewerkersovereenkomst met u te sluiten.

De IFOSS Law Review is een internationale samenwerking van vrijwilligers dat regelmatig hoogstaande juridische artikelen over open source publiceert. Een aantal van deze vrijwilligers heeft nu gezamenlijk een boek ontwikkeld dat als min of meer tijdloze publicatie moet dienen. Dit boek is een mooie aanvulling op onder meer het Nederlandse boek van de NVvIR (uit 2004 alweer).

Ik schreef voor het boek het inleidende hoofdstuk, A History Of FOSS Law And Licensing:

Companies such as IBM that provided these computers as part of what we today would call “solutions”: businesses were provided with specially-programmed computers to support certain business activities. Customers would pay for continued support and new programs as part of the deal, but no one would consider buying or selling computer programs by themselves. Users would get together to share their in-house software developments with others, eventually leading to the building of pools of software. This was actually encouraged by most vendors, as it stimulated the sale of hardware that could use this software. One might thus say that the idea of free and open source is as old as the computing business itself.

Lees het hele boek op IFOSSlawbook.org.

Het grootste juridische struikelblok is dat opdrachtgevers in een IT-project maar laatste kansen blijven geven. De wet biedt je namelijk pas de gelegenheid een project te staken als de wederpartij “in verzuim” is, en daarvan is pas sprake als hij een fatale deadline heeft gemist of als hij in gebreke is gesteld. Beide opties zijn juridisch tot op alle punten en komma’s uitgeprocedeerd, en het verbaast dan ook niet dat het héél lastig om te bewijzen is dat hiervan sprake is. In een helder artikel (PDF) legt IT-advocaat Polo van der Putt duidelijk uit waar de juridische valkuilen liggen.

Eerst maar eens die “fatale termijn”. Daarmee wordt een deadline bedoeld die écht deadline is, oftewel missen daarvan is jou(w bedrijf) fataal. Essentieel daarbij is dat de wederpartij wist dat het om een fatale termijn ging. Dat de termijn belangrijk was voor jou, is niet belangrijk. Het klassieke voorbeeld van een fatale termijn is de bruidstaart: de bakker moet weten dat die voor de trouwdag wordt besteld, en een dag te laat is echt onaanvaardbaar.

Bij IT-projecten ligt dat iets anders. Daar is uitstel of iets latere levering eigenlijk altijd wel mogelijk. Immers, geen IT-project dat per se op je trouwdag af moet zijn. En werkt de IT-er met een beetje toegesneden algemene voorwaarden, dan is er nooit sprake van een fatale termijn, hoe belangrijk die voor de klant ook is. De voorwaarden definiëren dan simpelweg elke termijn als zijnde niet fataal, ongeacht mededeling van de klant. (Toegegeven, zulke voorwaarden schrijf ik ook.)

Van der Putt signaleert een vonnis waarbij de rechter het droogjes als volgt samenvat waarom IT-deadlines nimmer van niveau trouwdag kunnen zijn:

Dit te meer nu feit van algemene bekendheid is dat automatiseringsprojecten kunnen uitlopen, en uitlopen ook vaak plaats vindt.

Een rechter met IT-clue. Iedereen weet dat IT-projecten altijd uitlopen, dus iedereen moet snappen dat deadlines slechts bedoeld zijn als indicatieve termijnen - “ergens rond 27 mei zou leuk zijn, maar 19 september mag ook hoor”. Van een falende leverancier kom je dus niet af met het argument “u had 27 mei moeten opleveren en dat is niet gebeurd”.

De andere juridische boeg waar je het over kunt gooien is dat er niet correct geleverd wordt. De leverancier schiet tekort, juridisch gezegd. Dat kan een grond zijn om te ontbinden, maar dat bewijzen is moeilijker dan je denkt. Zeker als het gaat om toekomstige tekortkomingen, het “dit komt nooit meer goed”-argument:

Het zal in de praktijk niet eenvoudig zijn om voldoende aannemelijk te maken dat tekort zal worden geschoten. Doorgaans zal het de afnemer aan voldoende expertise en wetenschap ontbreken om aan te kunnen tonen dat correcte nakoming onmogelijk zal zijn. Bovendien zal, zeker bij langlopende projecten waar de leverancier nog een lange termijn heeft om te presteren, altijd wel een gezaghebbende expert gevonden kunnen worden die met kracht van argument kan betogen dat correcte nakoming wel mogelijk is.

Kun je wel bewijzen dat sprake is van een daadwerkelijke tekortkoming, dan is het mogelijk om het project te annuleren. Eis is dan wel dat de IT-er in verzuim is. De wet eist dan als hoofdregel dat hij in gebreke is gesteld. Dat wil zeggen: er is een tekortkoming gesignaleerd, de IT-er heeft een laatste kans gehad om het recht te zetten en ook daarna blijft het tegenvallen. In dat geval mag je als opdrachtgever opzeggen. Maar ook dat is moeilijker dan je denkt. Twee struikelblokken:

1. Er moet een schriftelijke ingebrekestelling zijn verstuurd. Dat is een brief (geen mail) met daarin de toverformule “ik stel u bij deze in gebreke en eis dat u de hierboven gesignaleerde fouten herstelt”.
2. De ingebrekestelling moet een redelijke termijn stellen voor het herstel van de fouten.

Te vaak denken opdrachtgevers dat het genoeg is te constateren dat er gefaald is en dat ze daarmee mogen opzeggen. Dat is dus expliciet niet zo. Evenmin is sprake van een ingebrekestelling als men geen uiterlijke termijn stelt, maar bv. alleen aanbiedt te gaan overleggen om te kijken wat er nog te redden valt.

Of te wel: zachte heelmeesters maken stinkende wonden. Een afnemer die meent dat er sprake is van een tekortkoming doet er verstandig aan om ook een termijn te stellen. Praten kan altijd nog.

Er zijn uitzonderingen op deze regel. Zo is een ingebrekestelling niet nodig wanneer de leverancier heeft gemeld dat hij niets meer gaat doen of als er lange tijd helemaal géén reacties komen op klaagmails. Of als de enige oplossing is om maar helemaal opnieuw te beginnen. Maar ik zou er niet op durven vertrouwen als ik de jurisprudentie erop nalees.

Met deze samenvatting doe ik Polo’s artikel nauwelijks recht, dus lees graag het gehele artikel: (Dreigende) tekortkoming en verzuim van IT-dienstverleners bij IT en Recht.nl.

Waar ik zelf dan nog benieuwd naar ben: waarom laten IT-klanten het altijd zo gierend uit de hand lopen met die projecten? Is het omdat IT moeilijk is en je geen idee hebt wat ze aan het doen zijn? Omdat je (vanwege de auteursrechten op de code) vast zit aan deze leverancier en je dus alle gelden kwijt bent als je opzegt? Of hebben IT-ers betere komtwelgoedpraatjes dan aannemers?

Arnoud
PS: de voor mij ergste openingszin is “u bent mijn laatste hoop”, en ja die krijg ik zo eens per week.

Het Hof komt hiermee terug op een vonnis uit 2009 waarin de rechtbank juist wél oordeelde dat een licentienemer van software gerechtigd is deze door te verkopen. Tenminste, als hij de software op de originele dragers doorverkoopt natuurlijk. De basis daarvoor was de regel uit het auteursrecht die zegt dat legaal op de markt gekomen “exemplaren” vrijelijk mogen worden doorverkocht. Het Hof zegt nu dat die regel niet geldt voor software, omdat daarbij de licentie (EULA) vérgaande beperkingen stelt aan het gebruik. Meer precies: uitputting geldt niet wanneer

1. De auteursrechthebbende expliciet het woord “licentie” gebruikt.
2. De licentie “significantly restricts the user’s ability to transfer the software” (oftewel gebruikt een standaardzin dat de licentie niet overdraagbaar is).
3. De licentie “imposes notable use restrictions” (zoals dat maar één gebruiker de software mag gebruiken).

Als aan die drie eisen is voldaan, dan zou volgens het Hof duidelijk moeten zijn dat je géén eigenaar bent van het exemplaar maar slechts een gebruiker. Je zou dit kunnen vergelijken met een huurder - die weet ook duidelijk dat hij huurt en niet koopt, en dat zijn gebruik aan de nodige beperkingen onderworpen is.

De zorg van OSNews, en ook van Ars Technica, is dat het Hof hiermee lijkt te zeggen dat rechthebbenden alles in zo’n EULA mogen zetten en dat dat dus bindend is. Dat gaat me wat te ver. Het Hof zegt in het arrest alleen dat áls aan die drie items voldaan is, er geen sprake is van uitputting. Men ontkent niet dat er ontoelaatbare eisen in een licentie kunnen staan.

In Nederland lijkt uitputting voor voorgeinstalleerde software juist wel te bestaan, tenminste volgens de rechtbank Dordrecht. Die oordeelde:

Er zijn dus exemplaren van de CAD-software geïnstalleerd op dragers (werkstations) in het verkeer gebracht door middel van eigendomsoverdracht aan Nelcon door de exclusief distributeur Han Dataport, en dus met toestemming van de auteursrechthebbende. … Dit heeft tot gevolg dat Han Dataport zich niet kon verzetten tegen de verdere verspreiding van deze software(…).

De inhoud van de licentie was daarbij irrelevant.

Deze aanpak van de rechtbank Dordrecht spreekt me wel aan, maar hij gaat alleen op voor verkoop van software op fysieke dragers. En daarvan is steeds minder sprake natuurlijk vandaag de dag. Meer en meer software (maar ook andere content, zoals muziek en films) gaat digitaal, en daarbij geldt de uitputtingsregeling sowieso niet. Wat mij betreft wordt het tijd om hier expliciete regels over te maken (wat ook in het Ninth Circuit-arrest gezegd wordt.)

Arnoud