Internetrecht door Arnoud Engelfriet

In 2010 blogde ik dat het Weens Koopverdrag regelmatig uitgesloten wordt in allerlei algemene voorwaarden. Het duikt echter nog regelmatig op, ook in softwarelicenties. En daarover vroeg een lezer me waarom dat überhaupt nodig is: software is toch niet iets dat je kunt ‘kopen’?

Nou, daar heeft die lezer dus helemaal gelijk in. Software koop je niet maar neem je in licentie. Het is dan ook vooral een stukje copypastejuristerij, al dan niet om de tekst er wat gewichtiger te laten uitzien. De klant verwacht immers een uitgebreide juridische tekst, en een alinea “U mag deze software binnen uw bedrijf gebruiken maar niet verspreiden naar derden, en wij zij niet aansprakelijk voor fouten” voelt niet als een tekst waar je 950 euro voor betaalt. Dus dan maar wat extra uitsluitingen, herformuleringen van wettelijke rechten en beperkingen en opsommingen van dingen die onder “alles” gerekend moeten worden.

Specifiek over het Weens Koopverdrag vond ik echter nog een interessant artikel bij TechEye (waar ik de titel schaamteloos van gejat heb) dat laat zien dat het soms echter nog net iets meer betekent. Men had een stukje software van Broadcom gevonden, waarvan de licentie de bekende clausule bevatte dat

The parties expressly stipulate that the 1980 United Nations Convention on Contracts for the International Sale of Goods shall not apply.

Enig graafwerk van TechEye leidde tot de ontdekking dat er wel iets meer achter zit dan alleen copypastewerk. In Duitsland met name leeft er serieuze discussie of en wanneer dit verdrag relevant is voor software. Daar lijkt de conclusie te zijn dat als je standaardsoftware (geen maatwerk) op fysieke drager verkoopt, er sprake is van een ‘koop’ in de zin van het Koopverdrag. Iets dat ons Arnhems Hof in 2010 ook leek te oordelen, hoewel in een iets andere context. Ook dit paper uit Japan van de Japanse overheid lijkt dit standpunt te onderschrijven.

Ergens wel terecht ook: standaardsoftware wordt verkocht alsof het een fysiek ding is - Borland had al heel lang geleden de opvatting dat hun software was “sold like a book”, oftewel je had één licentie, die mocht je best doorverkopen of weggeven zolang je maar niet ging kopiëren. De nieuwe Consumentenrechtenrichtlijn zal digitale goederen op bepaalde (maar niet alle) punten gelijkstellen met fysieke goederen.

Eigenlijk vind ik het nog jammer dat de Europese Unie niet heeft doorgepakt en gewoon software of digitale goederen algemeen als ‘zaak’ heeft aangemerkt. Dan kun je gewoon alle regels over verkoop van producten ook toepassen op digitale producten. Het Weens Koopverdrag blijft uitsluitbaar in dat geval, dat wel. Maar waarom het maatschappelijk wenselijk is dat software niet kan worden verkocht maar alleen in licentie mag gegeven, heeft nog niemand me kunnen uitleggen.

Arnoud
Afbeelding: Drafting Contracts Under the CISG, Flechtner, Brand en Walter Oxford University Press, USA (December 31, 2007)

Een lezer vroeg me:

Als ik producten inkoop, dan mag ik verwachten dat die voldoen aan de gestelde eisen. Doen ze dat niet, dan gaan ze retour en dan krijg ik vervanging of herstel. Volkomen logisch lijkt me; je koopt iets en dan moet je dat ook krijgen. Maar bij software lijkt dat allemaal anders te liggen. Je vraagt om bepaalde functionaliteit, je krijgt iets dat er een beetje op lijkt maar vol zit met fouten - maar als je die hersteld wilt hebben dan moet je een onderhoudscontract afnemen, oftewel elke maand betalen in de hoop dat je op zeker moment krijgt wat je zoekt. Waarom kan dat zomaar, juridisch?

Dat kan vooral omdat iedereen het accepteert.

Hoofdregel is dat je bij elke overeenkomst recht hebt op nakoming op de manier die je mocht verwachten. Of het nu gaat om levering van een product of van een dienst (zoals ontwikkelen van software), er zijn afspraken en de leverancier moet die nakomen. Doet hij dat niet, dan is het wanprestatie.

Bij software-ontwikkeling is het zeer gebruikelijk om af te spreken (via niet-onderhandelbare clausules in algemene voorwaarden van leveranciers) dat de software zonder garantie komt en dat je maar moet hopen dat het werkt. Een wederpartij die dat accepteert, zit daar aan vast. En ja dat mag, een bedrijf is vrij om af te spreken dat ze veel geld betaalt zonder kwaliteit te hoeven verwachten. (Dit geldt óók voor producten trouwens, je mag als bedrijf je aanspraak op garantie of conformiteit ‘wegtekenen’ als je dat wilt.)

Vorig jaar oordeelde het Gerechtshof dat standaardsoftware als ‘zaak’ aangemerkt kan worden, waarmee je in principe langs dezelfde weg als bij producten kunt eisen dat fouten hersteld of vervangen worden. De Europese Commissie wil een dergelijke aanpak wettelijk vastleggen. Maar dat zal dan alleen voor consumenten gelden, voor bedrijven zal het mogelijk blijven om hiervan af te wijken.

Natuurlijk kun je als bedrijf prima eisen dat je wél kwaliteit krijgt, bijvoorbeeld via een uitgebreide acceptatietest of gratis onderhoud op alle fouten die je binnen $X maanden na levering ontdekt. Ook dat is onderdeel van dat vrije mogen afspreken. Wat er uiteindelijk wordt besloten, hangt dus af van hoe stevig de partijen kunnen onderhandelen.

Dit voorjaar kwam de Hoge Raad met een arrest over melkmachines, dat ook voor ICT-dienstverlening relevant kan zijn. (Met dank aan ITenRecht.) Er waren melkrobots geleverd, maar de robots bleken niet goed te werken. De storingen (”voortdurende stroom van klachten”) bleken zo erg dat de klanten gingen klagen, en op zeker moment zelfs kortingen gingen opleggen vanwege de slechte kwaliteit van de melk. Ook liep een aantal koeien uierontsteking op, wat het bedrijf weet aan de slechte kwaliteit van de machines.

Er was een onderhoudsovereenkomst: 24/7 beschikbaarheid van een storingsmonteur voor € 5.000 per jaar plus kosten per bezoek. En die monteur kwam ook wel, maar een definitieve oplossing bleek niet te kunnen worden gevonden. Het bedrijf ontbond op zeker moment de overeenkomst wegens wanprestatie, waar de leverancier bezwaar tegen maakte. Er was toch een onderhoudsovereenkomst? Daarmee was elke fout gedekt.

De Hoge Raad gaat daar niet in mee, omdat

het systeem ten gevolge van de herhaalde storingen telkens een of meer uren, oplopend tot een of meerdere dagdelen, plat ligt, hetgeen een aanzienlijk negatieve invloed op de bedrijfsvoering (welzijn van de koeien en kwaliteit van de melk) heeft, hetgeen [verweerder] niet behoefde te verwachten.

Het moest daarmee de leverancier duidelijk zijn dat er iets serieus mis was met het systeem. En dat de klant dan op zeker moment er genoeg van heeft, had hij ook moeten begrijpen.

Dat partijen tevens een onderhoudsovereenkomst hadden gesloten op grond waarvan [eiser] verplicht was tot herstel over te gaan, staat aan dat oordeel niet in de weg.

De klant mocht dus de overeenkomst opzeggen wegens wanprestatie, ondanks de onderhoudsovereenkomst en de daarbij behorende afspraken over herstel van fouten. Volkomen terecht, lijkt me.

Arnoud

Een lezer vroeg me:

Ik heb als freelancer een stukje software gemaakt voor een groot bedrijf. Nu melden ze me dat er een bug in zit waardoor ze maanden aan data kwijt zijn, en ze willen mij aansprakelijk stellen voor de schade! Ik werk eigenlijk altijd zonder algemene voorwaarden, omdat ik niet houd van dat formele gedoe, maar nu maak ik me toch wel zorgen. Kunnen ze zomaar een grote claim indienen?

Dat zou zomaar kunnen inderdaad. Wanneer een leverancier geen algemene voorwaarden hanteert, dan geldt de wettelijke regel voor aansprakelijkheid. Die zegt dat de ontwikkelaar aansprakelijk is voor alle schade, als de fout hem te verwijten was. Daarvan is kort gezegd sprake als hij niet de gebruikelijke mate van zorg heeft betracht die een normaal ontwikkelaar in acht zou nemen.

Het zal dus aankomen op de aard van de fout. Was dit een zeer subtiele moeilijke fout of juist een triviale bug die de vraagsteller gewoon had moeten ontdekken bij het testen? En zit de fout wel in de door hem geleverde code, of zit het hem in de interactie tussen zijn code en die van het bedrijf? In het laatste geval is het moeilijk de ontwikkelaar te verwijten dat de fout er zat.

Ik moet zeggen dat ik schrik van hoe veel programmeurs blijken te werken zonder algemene voorwaarden, of met een generiek modelletje van de Kamer van Koophandel of van een op internet gevonden concurrent dat dan net niet de clausules heeft die je wilt. Of die wel aansprakelijkheid uitsluit maar dan zó ver gaat dat de clausules ongeldig zijn (”Leverancier is te allen tijde nergens voor aansprakelijk”).

<reclame style=’schaamteloos’>Het starterspakket voor softwareontwikkelaars van mijn bedrijf zou hier goed geholpen hebben.</reclame> De ICT~Office voorwaarden zijn ook een gratis optie, hoewel die dan weer zó eenzijdig zijn dat grote klanten ze vaak direct afwijzen. Maar in gevallen als deze helpen ze wel: vorig jaar kon een ontwikkelaar een schadeclaim pareren van 300.000 euro dankzij de algemene voorwaarden.

Meelezende ontwikkelaars: Hoe zijn jullie gekomen tot de algemene voorwaarden die je nu hebt?

Arnoud

Volgens mij het eerste vonnis over iPhone apps (via) versus het merkenrecht. Het bedrijf Pardoel had een snelheidsbegrenzer ontwikkeld en deze in de markt gezet onder de naam Ecodrive. Deze naam is ook als woordmerk gedeponeerd. Doel van de begrenzer is te zorgen dat de automobilist milieuvriendelijker (”groener”) gaat rijden.

Het bedrijf Axus had een iPhone applicatie ontwikkeld die “ALD Ecodrive” heette, waarmee je je rijgedrag kunt analyseren en zo milieuvriendelijker kunt gaan rijden. De app was gratis via de Apple Appstore te krijgen, en via www.aldecodrive.nl kun je meedoen aan de “ALD Ecodrive Challenge”, een competitie tegen andere gebruikers.

Pardoel stapte naar de rechter omdat de app hun merk gebruikte, en wel voor sterk gelijkende diensten: een app op een smartphone om milieuvriendelijk te rijden komt immers erg in de buurt van een hardwareapparaat om milieuvriendelijk te rijden.

De rechter oordeelt echter dat geen sprake is van inbreuk, omdat het merk “Ecodrive” naar alle waarschijnlijkheid nietig is. Het is beschrijvend voor snelheidsbegrenzers en -controleapparaten. Axus had namelijk allerlei stukken in het geding gebracht waaruit blijkt dat “ecodrive” een gebruikelijke Engelstalige term is voor milieuvriendelijk rijden, zoals opleidingsinstituut Ecodrive of dit rapport van SenterNovum:

The Dutch Ecodrive programme ‘Het Nieuwe Rijden’ (from hereon “Ecodrive-programme” or “Ecodrive”) is an instrument with the objective of stimulating more energy-efficient purchase- and driving behaviour.

En tsja, als het zó breed gebruikt wordt als algemene term dan heb je geen recht op merkbescherming.

Eerder verloor Pardoel ook een procedure bij de SIDN over de opeising van Ecodrivenederland.nl. De arbiter zei toen:

De termen ‘ecodrive’ en ‘ecodriving’ wordt al sinds vele jaren als beschrijvende aanduiding gebruikt door onder meer de Nederlandse overheid voor activiteiten met betrekking tot zuinig rijden. Ook is de term beschrijvend voor de diensten die de verweerder daadwerkelijk aanbiedt onder de domeinnaam.

In dit vonnis merkt de rechter nog op dat Axus de naam ‘Ecodrive’ niet als handelsnaam gebruikt, ook niet bij de Challenge-site: daar staat die naam alleen als aanduiding van de applicatie, niet als aanduiding van hun bedrijf. En dat is maar goed ook, want als ze wél hun site Ecodrive hadden genoemd, hadden ze het op het handelsnaamrecht waarschijnlijk verloren. Een handelsnaam hoeft namelijk niet onderscheidend of creatief te zijn.

De eis over slaafse nabootsing wordt ook afgewezen, omdat “een software applicatie niet een nabootsing kan vormen van een fysiek product”. In dit geval billijk, maar in zijn algemeenheid lijkt het me wel degelijk mogelijk dat een iPhone app een slaafse nabootsing is van een dedicated hardware kastje. Slaafse nabootsing kán ook tussen websites spelen, zo bleek al eerder. (Kent iemand zulke apps?)

Arnoud

Een lezer vroeg me:

Voor mijn werk moet ik allerlei vragenlijsten invullen die we alleen op papier hebben. Met deze lijsten doorlopen we de workflow, zodat ik weet welke acties ik moet nemen en wat waar geadministreerd moet worden. Nu heb ik als hobby programmeren, dus ik ben op een zaterdagmiddag er eens voor gaan zitten en een applicatie gebouwd die me helpt de lijsten te doorlopen. Nu vroeg ik me af, kan ik deze applicatie nu gaan verkopen aan andere bedrijven in onze branche? Er is vast markt voor, want iedereen werkt met die papieren vragenlijsten.

Ok, dat was niet één specifieke lezer maar diverse: ik krijg zo ongeveer elke drie maanden een vraag van deze aard. Vandaar het gebrek aan specificiteit in wat de vragenlijsten doen en welke acties men onderneemt.

De eerste kwestie waar je tegenaan loopt, is of je wel het auteursrecht kunt claimen op deze software. Wat je maakt in het kader van je dienstverband is volgens de Auteurswet het eigendom van je werkgever. Daarbij maakt het niet uit of je onder werktijd werkt of in het weekend, of dat je een eigen PC gebruikt in plaats van de bedrijfslaptop.

De discussie zal hier dus alleen gaan over de vraag of het deel van je werk was om die applicatie te bouwen. Daarbij geldt als toets: had je werkgever je kunnen verplichten dit te doen? Of zou dat zó ver van je normale werk afliggen dat je dat redelijkerwijs had mogen weigeren? De functie van de werknemer lijkt me daarbij zeer belangrijk.

Een vrachtwagenchauffeur die zo de vrachtbrieven digitaal kan verwerken, kan denk ik zelf wel de rechten claimen. Een programmeur die de intake van nieuwe feature requests stroomlijnt met zo’n programma, zal geen eigen rechten kunnen claimen. Bij een administratief medewerker zit je in een grijs gebied: is verbeteren van de administratieve workflow niet deel van zijn werk?

Sommige vraagstellers hebben dit werk losgelaten op lijsten die van een derde zijn, bijvoorbeeld een leverancier of uitgever. In dat geval kan de applicatie tegen auteursrechten van die derde aanlopen. Daarbij zal het afhangen van wát je gebruikt: alleen de feiten die de leverancier ook gebruikt, of ook de systematiek of opbouw van het formulier? In het laatste geval kan de leverancier namelijk een auteursrecht claimen op die opbouw. Immers, het idee van “als het antwoord JA is, ga naar 5, ga anders naar 4″ is een creatieve invulling. Die opbouw mag je dus niet overnemen.

Arnoud

Een lezer stelde me een vraag over chatclient Jabber. Hij gebruikt deze op het werk inclusief de feature van end-to-end encryptie: OTR. Voor de iPad en iPhone is ook een Jabber-client beschikbaar, OneTeam geheten. Deze had echter geen encryptie. Op zijn verzoek of dat binnenkort dan opgenomen zou worden, reageerde het bedrijf met:

Chances to get encryption in OneTeam on iOS are very low, as we would have to ask permission to US government (as requested by Apple). This is a hassle we would like to avoid.

De vraag is natuurlijk, wat heeft de Amerikaanse regering te maken met encryptie op je iPhone?

In eerste instantie niet per se heel veel, maar Apple voelt zich als Amerikaans bedrijf geroepen de Amerikaanse wet te handhaven. Daarom staat in de voorwaarden voor app-developers dat zij bij gebruik van encryptie moeten bewijzen dat het Ministerie van Handel de export van deze technologie heeft goedgekeurd. Dat proces is een heel gedoe, maar het kan wel.

Deze regels gelden ook voor andere besturingssystemen en software, alleen wordt daar niet heel hard op gelet. Maar reken maar dat Microsoft keurig toestemming heeft gevraagd alvorens Windows met encryptie aan boord uit te leveren.

Vroeger waren er heel strenge regels over encryptie: je mocht als Amerikaan geen sterke encryptie naar buiten het land exporteren, wat inhield dat een sleutel bijvoorbeeld maar 40 bits lang mocht zijn (en niet de 128 bits die het zou moeten zijn om veilig te zijn). Dat geldt niet meer, er is alleen nog een verbod op export naar Libië, Iran en die landen. Voor de rest geldt een meldingsplicht en een paar beperkingen.

Voor open source is ook dat nog een probleem, want je hebt geen idee waar je software naartoe gaat dus je kunt niet garanderen dat de software niet naar Iran zal gaan. Daarom is er een uitzondering in de export control wetgeving opgenomen (art. 740.13 e-CFR), die zegt dat software in broncodevorm die publiek op internet downloadbaar is niet onder de strenge wetgeving valt.

Dat is volstrekt onlogisch gezien doel van de wet maar wel handig voor open source: wie producten met encryptie verkoopt, moet nagaan wie de klanten zijn en goedkeuring voor export hebben, maar wie het gratis op internet zet hoeft dat allemaal niet. Je moet alleen melden dat je cryptografische open source op internet hebt gezet.

In Europa geldt geen eis van melding. Wel is het verboden encryptie opzettelijk te exporteren naar landen als Libië, Noord-Korea of Iran. Want ja, encryptietechnologie wordt nog steeds gelijkgeschakeld met wapens en munitie.

Arnoud

Taiwanese iOS-gebruikers mogen apps 7 dagen testen, las ik bij iPadclub. De Taiwanese wet koop op afstand blijkt ook te gelden voor digitale producten zoals apps voor iPads en Android apparaten. Apple heeft gemeld haar beleid aan te passen, maar Google weigert meer dan 15 minuten retourtermijn te geven en incasseert de boetes vooralsnog.

Bij ons geldt er geen retourrecht voor apps, behalve dan wat je vrijwillig aangeboden krijgt in de algemene voorwaarden. In het Android-geval dus 15 minuten, en bij Apple bij mijn weten helemaal niet. Software wordt wel genoemd in de Wet koop op afstand, maar dan alleen als uitzondering: software mag alleen worden geretourneerd als deze in de originele verzegeling zit. Want die wet komt uit een tijd dat downloaden van software alleen iets voor bebaarde hippies was.

De op stapel staande richtlijn over consumentenrechten moet daar verandering in brengen. De recent goedgekeurde regels kiezen een andere insteek: downloadbare software wordt niet als product gezien en valt dus niet onder de gewone Wet koop afstand. Wel wordt het downloaden van software expliciet als dienst gemarkeerd, en die mag worden geannuleerd binnen 14 dagen (nieuwe regel) mits het downloaden nog niet is begonnen.

Dat lijkt me een iets betere aanpak dan de Taiwanese insteek. Menig app heb je binnen een week wel gezien lijkt me, zeker spelletjes, en de kans op misbruik lijkt me wel erg groot in die situatie. Een app kopen is voor mijn gevoel wat anders dan een boek of een paar sokken. Aan de andere kant, enige mogelijkheid tot uitproberen lijkt me wel een goed idee voor software. Niet voor niets was shareware/trialware lange tijd zeer populair. (Hoewel, wie kócht daadwerkelijk zijn shareware?)

Arnoud

Microsoft moet i4i 300 miljoen dollar betalen voor patentschending, nadat alle bezwaren zijn verworpen, meldde Webwereld vrijdag. Er wordt voor een invasie van patenttrollen gevreesd, omdat de Supreme Court de bewijsregels in patentrechtszaken wel heel pro-patenthouder lijkt te formuleren. Het patent van i4i is geldig, omdat Microsoft geen “helder en overtuigend” bewijs van het tegendeel heeft. Maar i4i hoeft slechts aan te tonen dat het “waarschijnlijk” is dat Microsoft het octrooi schendt om een verbod toegewezen te krijgen.

i4i is een Canadees bedrijf dat software maakt voor documentbeheer. Hun patent (US5,787,449) betreft een techniek om structuur en inhoud van een document apart te kunnen beheren, die gebruik maakt van metacodes in een aparte datastroom. Het patent is uit 1994 en heeft elke aanval weten te overleven. In 2009 werd Microsoft veroordeeld omdat Word inbreuk zou maken met het .DOCX en .DOCM bestandsformaat.

Microsoft had bij de procedure diverse prior art systemen gevonden, maar liep tegen een procedureel probleem aan: de jury(*) kreeg als instructie dat ze alleen het octrooi ongeldig mocht verklaren als de prior art “clear and convincing evidence” bevatte dat de uitvinding al bestond. Dat is een hoge eis, hoger dan de gebruikelijke “preponderance of the evidence”. En die laatste standaard mocht dan weer wél gebruikt worden om te bepalen of Microsoft inbreuk maakte en dus Word van de markt moest halen.

De Supreme Court in haar arrest (pdf) nu dat dit verschil juist is. Dit omdat het USPTO de patentaanvraag heeft onderzocht, en we toch mogen verwachten (hah!) dat deze daarbij zorgvuldig en grondig te werk gaat. Daarom is het terecht om in die situatie een extra hoge eis te stellen aan waar de gedaagde mee komt.

Webwereld vreest dat patenttrollen zich gesterkt zullen voelen door dit arrest. Logisch, de Supreme Court bevestigt hier dat het inderdaad moeilijk is een octrooi aan te vechten. Bovendien kost dat al snel enkele miljoenen Euros. Maar een kenmerk van trollen is dat ze zelden procederen, en liever een relatief laag bedrag eisen om zo snel binnen te lopen. Veel door trollen ingezette octrooien zijn zeer dubieus, maar als je moet kiezen tussen 1 miljoen betalen en 4 miljoen in een rechtszaak steken dan is -zakelijk gezien- de keuze duidelijk.

i4i lijkt me overigens geen patenttrol: zij verkopen eigen producten, en onder trollen worden over het algemeen alleen bedrijven verstaan die octrooien opkopen en licenties gaan eisen zonder zelf iets op de markt te brengen.

(*) In de VS worden octrooirechtszaken door een jury beslist. Daarbij is het gebruikelijk dat alle mensen met technische achtergrond worden uitgesloten van de jury, omdat die bevooroordeeld zouden zijn. Inderdaad betekent dat dat zaken over complexe technologie beslist worden door mensen met per definitie geen verstand daarvan.

Arnoud

Een lezer vroeg me:

Enkele jaren terug hebben wij een softwarepakket laten maken door een leverancier. Eigenlijk hadden wij daar vanaf het begin geen goed gevoel bij. Alles kostte geld, van een extra feature tot corrigeren van taalfoutjes aan toe.

Een maand geleden kregen we echter een nieuwe aankondiging die voor ons de druppel is: we worden verplicht een servicecontract af te nemen van 1200 euro per jaar, en anders wordt de licentie ingetrokken. We hebben 2 maanden om te beslissen, en in de tussentijd krijgen we bij elke keer opstarten een melding dat dit eraan gaat komen. Kan dat zomaar?

Deze vraag is in het algemeen moeilijk te beantwoorden, omdat het antwoord voor 99% afhangt van het contract. Maar het is denkbaar dat het antwoord “ja, dat kan zomaar” luidt.

Hoofdregel bij software is dat de leverancier alle auteursrechten op de software heeft. Alleen als er schriftelijk (en ondertekend) is gezegd dat de rechten naar de opdrachtgever gaan, heeft de opdrachtgever de rechten. En wanneer de leverancier de rechten heeft, bepaalt hij op welke manier de klant gebruik mag maken van de software. Ja, ook als het maatwerk is.

Het wijzigen van het contract kan alleen als in het contract staat dat de leverancier dat mag doen. Maar vrijwel elk contract bevat zo’n beding, ergens verstopt tussen toepasselijk recht, overmacht en de clausule dat kopjes in het contract niet in de interpretatie van de artikelen mogen worden betrokken (wtf?). Daarmee kan de leverancier dus vrij eenvoudig elke nieuwe licentieconstructie doorvoeren.

Het gaat nogal ver om ineens een servicecontract met hoge extra kosten te introduceren, maar in principe kan het dus wel. Wie zijn softwarelicenties dus niet goed leest, kan tegen dit soort verrassingen aanlopen.

Slimme klanten bedingen dus het eigendom op de software (of kiezen open source) zodat ze dit probleem niet hebben.

Arnoud

Als je afspreekt dat je software alleen mag verspreiden in versleutelde vorm, maar er zit open source in, schend je dan de licentie door toch broncode vrij te geven? Jaja, het lijkt er zowaar op dat we een vonnis hebben over de ‘virale’ werking van open source. Maar dat valt vies tegen: de rechtbank doet geen uitspraak (via) over de bindendheid van de ‘open licenties’ omdat de licentienemer deze er eenvoudig uit had kunnen slopen.

Het bedrijf Purple Pigeon had software (’Eigen Chatbox’, ‘WebAgenda Multi-User’, ‘WebEnquete PRO’, ‘Web to Go Personal’ en ‘Web To Go Professional’) ontwikkeld, en met Quinarx een exclusieve distributieovereenkomst gesloten. Die werd later omgezet in een nieuwe overeenkomst, waarbij afgesproken werd dat de broncode te allen tijde gecodeerd (versleuteld) zou moeten worden met een pakket als SourceCop. Ook moest altijd het copyright van Purple Pigeon worden vermeld.

In 2010 constateerde Purple Pigeon dat de software nog steeds werd verkocht, en ook nog eens met vrij beschikbare broncode en zónder auteursvermelding van PP. Volgens Quinarx was daar geen sprake van, waarop Purple Pigeon naar de rechter stapte en een terughaalactie (recall) eiste plus een schadevergoeding.

Eén van de verweren van Quinarx was dat het programma open source bevatte, en dat het daarom niet zomaar versleuteld verspreid mocht worden. Op zich een terecht verweer: de GPL bijvoorbeeld verbiedt zulke distributie, de broncode moet er echt bij zitten (of op verzoek nageleverd worden). Maar de rechter oordeelt dat je als licentienemer niet zomaar eenzijdig mag besluiten om dan de broncode maar openbaar te maken. Als je zo’n compliance probleem signaleert, moet je de rechthebbende benaderen en ze daarop wijzen.

Terecht, maar jammer dat dit punt niet nader is uitgewerkt. Ik had wel eens willen zien wat de rechter zou zeggen van het verweer dat Quinarx (en ook Purple Pigeon) gewoon gebonden was aan de GPL en daarom wel moest handelen op deze manier.

Arnoud