Tag: Software

About Software

Subscribe Feeds

Oracle’s Java API auteursrechtelijk beschermd in VS, Android maakt inbreuk

Geplaatst op in Intellectuele rechten, 21 reacties

aapje-api.pngEen Amerikaans gerechtshof heeft vrijdag in hoger beroep bepaald dat Google met zijn Android-besturingssysteem het copyright van Oracle heeft geschonden, las ik bij Tweakers. Nadat eerder nog was bepaald dat er geen auteursrecht zat op de API’s van Oracle’s Java, beslist het Hof van Beroep nu anders: de aangeboden code en de structuur, volgorde en organisatie van de api-packages zijn wel degelijk creatieve keuzes die de resulterende api een beschermd werk maken. Daarom schendt Google met Android het auteursrecht van Oracle door namen, headers en functiedeclaraties over te nemen.

Het geschil speelt al sinds 2012. Google had in Android een aantal elementen overgenomen uit de Java API en Oracle startte daarop een rechtszaak wegens auteursrechtinbreuk. In eerste instantie won Google: een API en functiedeclaraties zijn vergelijkbaar met een inhoudsopgave, en bovendien kun je in software vaak dingen maar op één manier uitdrukken. Daarmee is er geen sprake meer van het overnemen van creatieve elementen.

In hoger beroep wordt anders beslist. Allereerst wordt vastgesteld dat het máken van een API best creatief werk kan zijn. Nadenken welke functies je gaat aanbieden, hoe je die noemt, welke argumenten ze moeten krijgen en wat voor soort resultaat er komt, vereist creatieve arbeid. En die arbeid wordt beschermd door het auteursrecht. Een ander mag dan niet zomaar de integrale resultaten van die arbeid overnemen.

Amerikaans auteursrecht verbiedt auteursrecht op methods of operation. Al in 1995 speelde dit: mocht Borland met spreadsheetprogramma Quattro de menustructuur van concurrent Lotus overnemen? Ja, zo oordeelde men destijds, want een menu is dé manier van het opereren/gebruiken van een stuk software. En in eerste instantie won ook Google het met dit argument, omdat het nabootsen van een menu hetzelfde werd geacht als het aanroepen van een API. Dat wijst het Hof af: het kopiëren van API declaraties is wat anders dan het kopiëren van labels uit een menu.

Bovendien is de Lotus-uitspraak uit een ander circuit en in de VS geldt zo’n uitspraak dan niet als bindende jurisprudentie. Het Hof valt terug op een eigen precedent dat wél bindend is: de manier waaróp je een method of operation vormgeeft, kan wel auteursrechtelijk beschermd zijn. Mits er maar meer dan één manier is om dat te doen. En dat is hier het geval: de Java-ontwikkelaars hadden de vrije keuze om hun API te maken zoals zij wilden.

In Europa ligt het compleet anders. In de SAS-zaak werd bepaald dat de functionaliteit, de programmeertaal en de bijbehorende bestandsformaten geen deel van de beschermde code zijn, maar meer achterliggende ideeën of uitgangspunten waarmee je die code maakt.

… neither the functionality of a computer program nor the programming language and the format of data files used in a computer program in order to exploit certain of its functions constitute a form of expression of that program and, as such, are not protected by copyright in computer programs for the purposes of that directive.

Hiermee zou een API dus wél vrij bruikbaar zijn omdat het dan enkel gaat om de functionaliteit die in de API ligt. Het ging in de SAS-zaak om het gebruik van een programmeertaal waarop auteursrecht werd geclaimd. Het schrijven in die taal zou dan inbreuk opleveren, omdat een programma in die taal immers de beschermde functionaliteit aanroept. En dát wijst het Hof van Justitie af. Dit lijkt mij 1-op-1 door te trekken naar API’s van een programma. Immers wat is het verschil tussen een instructie in een taal en een aanroep van een API?

Google krijgt nog een kansje in de tweede ronde: de zaak is terugverwezen naar de rechtbank om Googles verweer op grond van fair use te beoordelen. Onder fair use mag je in het Amerikaans auteursrecht iemands werk gebruiken mits dat billijk (fair) is. Daarbij spelen zaken mee als hoe concurrerend je bent, hoe commercieel je bent en hoe transformatief of juist letterlijk je gebruik is. Dat is dus een moeilijker zaak om te bewijzen dan wanneer de Java API niet auteursrechtelijk beschermd zou zijn verklaard.

Dit kan nog wel eens heel hinderlijk worden want heel veel internet-API’s worden beheerd door Amerikaanse bedrijven. En als die nu allemaal auteursrechtelijke voorwaarden gaan koppelen aan gebruik daarvan, dan gaat me dat nog flink wat juridische hoofdpijn opleveren.

Arnoud

Microsoft verbiedt Office op Windows RT voor werk

Geplaatst op in Intellectuele rechten, Ondernemingsvrijheid, 27 reacties

office-rt.pngWie een tablet met daarop Windows RT aanschaft, mag de Office RT-applicaties die daarop standaard aanwezig zijn, niet zomaar in zakelijke omgevingen gebruiken. Dat meldde Tweakers (ahh nieuw design). Eerder had ZDnet ontdekt dat de licentie inderdaad “use in commercial, nonprofit, or revenue-generating activities” verbiedt.

Handig bedacht van Microsoft, want ze weten dat mensen die tablets kopen, die graag meenemen naar het werk en daar in willen zetten als bring-your-own-device. En in dat geval behoort de device dus voor revenue-generating activities gelicentieerd te zijn.

Oké, dus de werkgever moet de duurdere versie aanschaffen. Maar wat nu als hij dat niet doet, bijvoorbeeld omdat hij niet doorheeft dat er mensen aan het byod’en zijn? Dan zou de BSA eens op de thee kunnen komen en leuke boetes kunnen claimen .

Als bedrijf heb je dan best een probleem. Maar dit afschuiven op je werknemer, oftewel de boete verhalen, kun je vergeten. De werknemer is naar de werkgever toe nooit aansprakelijk, tenzij de schade een gevolg is van zijn opzet of bewuste roekeloosheid (art. 7:611 BW).

Of compleet niets met het werk te maken heeft, maar enkel “de werkgever gaf er geen opdracht toe” of “het was niet onder werktijd” is niet genoeg. Zo werd de werkgever aansprakelijk gehouden toen een groep werknemers bij een personeelsuitje lampolie op de barbecue gooiden, waardoor het partycentrum afbrandde

Dit geldt ook naar derden toe (art. 6:170 BW) – als een glazenwasser bij mij een vaas omschopt, is het bedrijf aansprakelijk voor mijn schade en niet die specifieke glazenwassende medewerker als persoon. Net zo is de werkgever aansprakelijk als een werknemer een auteursrecht schendt tijdens het werk.

Van opzet of bewuste roekeloosheid is zelden sprake. Je moet dan als werknemer concreet hebben gewéten dat je fout bezig was, maar bewijs dat maar eens als werkgever. Het negeren van instructies of waarschuwingen is dan ook nog eens niet per se genoeg:

Van bewust roekeloos handelen door Pollemans zou eerst sprake zijn, indien deze zich tijdens het verrichten van zijn onmiddellijk aan het ongeval voorafgaande gedraging, te weten het naast de aanwezige beveiliging lopen, van het roekeloos karakter van die gedraging daadwerkelijk bewust zou zijn geweest.’ Voor dat oordeel is niet voldoende, ‘… dat Pollemans van de zijde van Hoondert herhaaldelijk en in krachtige termen ervoor is gewaarschuwd niet bui­ten de steigerdelen te lopen.

Je vraagt je dan af wat wél genoeg zou zijn. Een reglement waarin gewoon staat “Werknemer is aansprakelijk bij BYOD” of “Alle schade door onjuiste licenties op een BYOD apparaat wordt verhaald op werknemer” is in ieder geval niet genoeg: de wet bepaalt dat een van de wet afwijkende afspraak alleen mag als de werknemer daarvoor verzekerd is (art. 7:661 lid 2 BW).

Het snelste ben je klaar als werkgever door gewoon die extra licenties te kopen. En dat is natuurlijk precies waar Microsoft op hoopt.

Arnoud<br/> PS: willen jullie allemaal even mijn broer Richard feliciteren? Hij is jarig vandaag 🙂

Clean room softwareontwikkeling versus het auteursrecht

Geplaatst op in Intellectuele rechten, 26 reacties

clean-room-warning.pngRegelmatig krijg ik vragen van mensen die software willen ‘imiteren’: eigen software schrijven die qua functionaliteit sterk lijkt op andermans software. Of men wil zelfs eigenlijk in de broncode van die andere software kijken om te zien hoe het nu precies werkt. Dat is natuurlijk riskant, want je weet dat die ander daar een claim over kan gaan leggen. De gebruikelijke reactie is dan “we moeten clean room gaan werken”, maar wat houdt dat nu precies in?

Op software rust auteursrecht. De broncode mag niet worden gekopieerd of gepubliceerd, ook niet in gewijzigde vorm. Maar de functionaliteit als zodanig valt buiten het auteursrecht op de software. De user interface imiteren is een ander verhaal, dat ik nu even buiten beschouwing laat.

Kopiëren, overnemen, publiceren etcetera van een werk vereisen allereerst dat je toegang had tot het origineel. Het is immers onmogelijk iets te kopiëren als je het origineel niet hebt. Natuurlijk, je kunt toevallig iets sterk gelijkends maken, maar dat is niet genoeg om van inbreuk op auteursrecht te spreken. Je moet echt overgetypt of gecopypaste hebben.

Alles begint dus bij de rechthebbende die moet aantonen a) dat de gedaagde toegang had tot de software en b) dat er concrete creatieve stukken uit de software zijn overgenomen. Als twee stukken software erg op elkaar lijken, mag de rechter de bewijslast omkeren. De gedaagde moet dan bewijzen dat alles zélf gemaakt is, en dat de overeenstemming toeval is.

“Clean room” werken is een manier om dergelijk tegenbewijs te kunnen leveren. Heel algemeen zorg je er dan voor dat je ontwikkelaars geen toegang tot de na te maken software hebben, zodat het onmogelijk is dat ze er stukken uit overnemen. En inderdaad, bij algemeen beschikbare software heeft clean room dus geen zin. Bij open source bijvoorbeeld is het argument “ik kon niet bij de broncode” meteen van tafel te vegen.

Als het onmogelijk is om de software te zien, heb je het probleem dat de ontwikkelaars niet weten wát ze moeten bouwen. Daarom introduceer je dan een ander team dat wél toegang krijgt tot de broncode, deze uit elkaar trekt en documenteert welke functionaliteit gewenst is. Dat is toegestaan. En vervolgens gaat die documentatie – en alléén die documentatie – naar de ontwikkelaars, zodat die software kunnen bouwen die deze functionaliteit realiseert, maar zonder dat ze ook maar een letter broncode kunnen overnemen. Vanwege de scheiding tussen deze twee teams heet dit ook wel de chinesemuurmethode: er zit een Chinese Muur tussen waar geen informatie langs kan gaan.

Deze techniek werkt en is legaal, althans dat is op te maken uit de Amerikaanse uitspraak Sony vs. Connectix uit 2000. In Nederland ken ik geen rechtszaken hierover.

Het is natuurlijk wel een hele berg gedoe, dus je moet je afvragen of je écht zo bang moet zijn voor claims dat je naar dit paardenmiddel gaat grijpen. Zeker nu we die SAS-uitspraak hebben van het Hof van Justitie. Die stelt immers duidelijk dat er echt broncode (of object code) overgenomen moet zijn, dat de functionaliteit identiek is, is niet genoeg. En ik kan me dan weer moeilijk voorstellen dat een bona fide programmeur dát gaat doen.

Arnoud<br/> PS: wie meer over software en met name open source software, schrijf je in voor onze open source workshop van 4 oktober!

Gedownloade software mag worden doorverkocht

Geplaatst op in Intellectuele rechten, 47 reacties

software-tweedehands.jpgBaanbrekende uitspraak zeggen ze bij ITenRecht, en terecht. Gedownloade gekochte software mag worden doorverkocht, en kopers van tweedehands software hebben een wettelijk gebruiksrecht. Ongeacht wat in de licentie staat. Lekker puh. Ok, dat laatste is mijn mening maar de rest is de opvatting van het Hof van Justitie in de UsedSoft zaak (C-128/11) waarbij Oracle dit Duitse tweedehandssoftwarelicentieverkoopbedrijf had aangeklaagd.

De Softwarerichtlijn, die auteursrecht op software regelt, bepaalt dat de auteursrechten zijn uitgeput op een exemplaar van software wanneer dat door de rechthebbende in de handel wordt gebracht via verkoop. Dat exemplaar mag worden doorverkocht, ongeacht wat er in de licentie staat. Logisch, zo werkt het met boeken ook. Pardon, met auto’s want het is in de ICT verplicht om vergelijkingen met auto’s te maken. Maar hoe dit nu uitpakt met gedownloade software, wist eigenlijk niemand. Is dat ook “verkoop”? Of sluit je dan alleen een contract?

Net als ik krijgt het Hof hoofdpijn van het onderscheid tussen de software en de licentie daarop. Een kopie hebben van software is zinloos als je niet ook een gebruiksrecht daarop hebt, begint het dus. En vervolgens constateert men dat uit diverse wetten en richtlijnen volgt dat een download eigenlijk hetzelfde is als een CD kopen: je krijgt een kopie en toestemming voor gebruik. Of de kopie materieel of immaterieel is, maakt niet uit. Zo staat er in de Softwarerichtlijn dat de bescherming van software in alle media hetzelfde moet zijn. Hoewel dat ongetwijfeld opgeschreven is om te voorkomen dat men ergens mínder bescherming zou kunnen krijgen dan ergens anders, werkt die zin natuurlijk ook omgekeerd: als uitputting fysiek een grens is, dan ook op internet.

Ook stelt het Hof dat auteursrechthebbenden recht hebben op een redelijke bescherming (en vergoeding) maar niet méér. Dat bepaalden ze al eerder in de Premier League-uitspraak, over het mogen ontvangen van satelliettelevisie en de handel in decoders daarvoor. Het Hof vond de beperkingen die de voetbalauteursrechthebbenden daar aanlegden, ingaan tegen het vrij verkeer van goederen en niet noodzakelijk voor een redelijke exploitatie van het auteursrecht. Dus nee, je hebt geen recht op geld voor alles dat mensen met je software kunnen doen.

Wel moet het gaan om “verkoop”, en niet elke licentieovereenkomst is een verkoop. Er moet sprake zijn van een licentie die onbeperkt is in de tijd, en er moet een redelijke vergoeding tegenover staan die in overeenstemming is met de economische waarde van de software. Dat laatste is ter onderscheid van huur: wie 3 euro per maand betaalt, huurt de software, maar wie 300 euro in één keer betaalt en daarna nooit meer, koopt de software.

Tevens moet de verkoper zijn kopie van de software onbruikbaar maken. Dus wissen, ook de backups. Wederom logisch.

En voor het geval bijdehante rechthebbenden in de licentie doorverkoop willen hinderen: dat mag niet, lekker puh. Oeps, doe ik het weer. In de Softwarerichtlijn staat namelijk dat je het een rechtmatige verkrijger niet mag verbieden om normaal gebruik van de software te maken. En daaronder valt dus ook het mogen doorverkopen van de software met licentie, dat is ook normaal.

Tussen neus en lippen door schopt men nog even tegen de schenen van de fijnslijpers die altijd zeiden dat “rechtmatig verkrijger” iemand is die een geldige licentie bezit. Daarmee wordt dat begrip eigenlijk zinloos. De wetgever wilde een juridische positie voor afnemers scheppen, en niet een synoniem voor “contractuele wederpartij”. Als je tegen een verkrijger van een tweedehands kopie kunt optreden met je auteursrecht, is het onmogelijk om software door te verkopen.

Als beperking geldt wel dat een gekochte licentie niet mag worden gesplitst. Koop je 23 licenties in één contract, dan mag je ze alleen als bundel van 23 doorverkopen. Dat lijkt net wat strenger dan in de fysieke wereld, maar ergens klopt het wel. Als je een 23-delige encyclopedie (een papieren Wikipedia) koopt, word je geacht die alleen met z’n 23-igen door te verkopen. Niet per stuk. Dat beperkt wel de handelsvrijheid van UsedSoft, waar je wel gesplitste licenties kon kopen.

En men “beklemtoont” nog even dat Oracle wél het recht heeft om te auditten of doorverkochte software wel echt gewist is bij de eerste koper. Dat is ongetwijfeld bedoeld als een soort goedmakertje: we pakken je wel het recht af om tegen UsedSoft op te treden maar je staat niet helemaal met lege handen hoor. Hoewel ik me goed kan voorstellen dat Oracle hier in de praktijk weinig aan heeft.

Ik ben heel benieuwd wat de reactie in de markt zal zijn. In eerste instantie zet ik m’n geld op “compleet negeren en heel hard LALALA roepen als iemand erover begint”. Volhouders gaan blafbrieven van advocaten krijgen met kulargumenten als “dat was een Duitse zaak, dat geldt niet bij ons” of “ons licentiemodel is wezenlijk anders dan Oracle”. Of met het iets-minder-kulargument “onze licenties zijn 5 jaar geldig” en/of “u moet elk jaar betalen dus is het huur”. Maar dat lost zich vanzelf op als ook de eerste Nederlandse rechtszaken uitgevochten zijn. Een arrest als dit van het Europese Hof wordt echt niet zomaar genegeerd bij de rechter.

Wél pijnlijk zou zijn als rechthebbenden nu veel zwaarder in gaan zetten op technische beperkingen, zoals activatie die maar éénmalig mag worden uitgevoerd. Dan kan software doorverkopen wel maar wérkt ie gewoon niet meer bij de nieuwe verkrijger. En dáár tegenin gaan vereist vrees ik weer wel een gang naar de Europese rechter.

Arnoud<br/> Foto: Drazz, Flickr, CC-BY-SA 2.0

Mag een softwareleverancier geld vragen voor patches?

Geplaatst op in Intellectuele rechten, Ondernemingsvrijheid, Security, 43 reacties

Adobe heeft kritieke beveiligingslekken in Photoshop, Illustrator en Flash gedicht, maar de patch is er alleen voor klanten die upgraden naar Photoshop CS6, meldde Tweakers onlangs. Daarna ontstond er geheel voorspelbaar de nodige ophef, waarna Adobe op haar aankondiging terugkwam.

De kritiek kwam min of meer neer op “we zijn gewend dat security patches gratis zijn”, plus “het is heel dom om juist securitypatches niet gratis weg te geven want dat zorgt alleen voor meer ongepatchte systemen”. En die kritiek is zeer terecht.

In Nederland kunnen we daar nog een argument aan toevoegen: software móet veilig zijn want anders is deze niet conform de gewekte verwachtingen. Net zoals een magnetron veilig moet zijn. Dat is namelijk het logisch gevolg van het Hoge Raad arrest van begin deze maand, dat bepaalde dat software gekocht kon worden.

Dat was wenselijk “omdat de kooptitel een uitgewerkte regeling geeft inzake conformiteit, klachtplicht en verjaring”, zo formuleerde onze hoogste rechter het. En deel van die conformiteitsregel is dat de verkoper gratis tot herstel of vervanging van het product moet overgaan als het product fouten blijkt te bevatten die je niet hoefde te verwachten.

Wel vraag ik me al langer af hoe ver dat precies gaat. Je hebt immers geen recht op een foutloos product. Als je moet weten dat bepaalde dingen mis kunnen gaan, dan is dat deel van de verwachting. Een bank verkleurt over de jaren. De letters op je toetsenbord slijten eraf. En software wordt gehackt.

Arnoud

Auteursrecht op programmeertalen kan niet (of je moet wel heel creatief zijn)

Geplaatst op in Intellectuele rechten, 36 reacties

little-sas-boek.jpgOp programmeertalen (en dataformaten) rust geen auteursrecht. Ietwat kort door de bocht, maar dat is wel zo ongeveer wat het Hof van Justitie bepaalde in haar arrest van gisteren. Kort door de bocht, want het kán wel, maar het is zeker geen automatisme.

In deze zaak ging het om een interpreter voor de SAS taal. Deze taal is ooit door SAS ontwikkeld als onderdeel van hun analysesoftware, en het bedrijf WPL besloot een eigen interpreter (emulator) te maken die programma’s in die taal kon verwerken zonder dat je SAS nodig had. Dat vond SAS niet leuk, en dus werden de advocaten losgelaten: een beetje iemands taal interpreteren, dat is auteursrechtschending, wat zullen we nou krijgen. (Ok, én de handleidingen overtypen, dat ook, maar daar ging het bij het Hof niet om.)

Het Hof grijpt de gelegenheid aan om er eens goed voor te gaan zitten: wat betekent dat nu eigenlijk, auteursrecht op software. Want software is altijd een probleemkindje geweest in het auteursrecht. Vanaf het begin waren de meningen verdeeld of software -toch een nogal utilitair product- wel onder het auteursrecht -toch voor creatieve kunstzinnige uitingen- gerekend moest worden. Het octrooirecht lag meer voor de hand, alleen dan zou 95% van de software niet beschermbaar zijn en dat was dan ook weer niet de bedoeling. Uiteindelijk is het opgelost door gewoon te zeggen “software is een creatief werk, punt”.

Maar ja, in het recht is “punt” nóóit het einde van een discussie. We gaan gewoon vrolijk verder over wat die punt dan betekent, hoe je ‘m kunt oprekken, of het eigenlijk geen puntkomma had moeten zijn en welk punt ermee gemaakt wordt.

Auteursrecht op software geldt niet voor de user interface, weet u nog? Het Hof kwam in 2010 tot die conclusie met het argument dat software een werk is dat de computer iets laat dóen, en de interface als zodanig dóet niets. De interface is alleen beschermd als ‘ie kunstzinnig is (overigens heb ik een *****-hekel aan kunstzinnige interfaces want de knoppen zitten nooit waar ik wil en keyboard shortcuts heb je al helemaal niet), en niet enkel omdat ‘ie aan een computerprogramma hangt.

Die lijn trekt het Hof nu door: het moet echt gaan om de broncode en/of objectcode als zodanig (argh), en van inbreuk kan dus pas sprake zijn als een van die twee ergens terug te vinden is in het werk van de ander. Letterlijk of niet-letterlijk, maar het moet er wel zijn.

De functionaliteit, de programmeertaal en de bijbehorende bestandsformaten zijn geen deel van de code, maar zijn meer achterliggende ideeën of uitgangspunten waarmee je die code maakt. En dus vallen ze buiten het werk als zodanig.

En ja, dat is ook de bedoeling, aldus het Hof:

to accept that the functionality of a computer program can be protected by copyright would amount to making it possible to monopolise ideas, to the detriment of technological progress and industrial development.

Wat daarmee niet kan, is mensen verbieden om dit formaat of de taal te achterhalen middels reverse engineeren. Dit kan niet op grond van het auteursrecht, en ook niet op grond van een licentiecontract. Want dat is namelijk de truc: je geeft een licentie op de software zelf (de broncode of objectcode dus) en daarin bepaal je dat je oh ja de programmeertaal niet mag reverse engineeren.

Eventueel is het mogelijk dat een creatief uitgewerkt dataformaat als zodanig wél beschermd is, maar dan moet er dus in dat formaat zélf iets creatiefs aan te wijzen zijn. Net als die kunstzinnige interface. Dat kan, maar is niet eenvoudig. Ik herinner me van lang geleden een anti-spam truc waarbij je een licentie op een haiku moest nemen om je mail geaccepteerd te krijgen (met als algemene voorwaarde “ik verstuur geen spam”). Dat is dus op zich een auteursrechtelijk houdbare constructie, maar wel redelijk gezocht. Ik durf dus wel te zeggen “auteursrecht op programmeertalen en -concepten kan niet”, maar ik ben heel benieuwd welke argumenten softwareauteursrechthebbenden gaan verzinnen om hier toch tegenin te gaan.

Arnoud

Ja, software kun je kopen!

Geplaatst op in Intellectuele rechten, 20 reacties

Software is geen zaak, maar je kunt het toch kopen. Ook als de leverancier het een licentie noemt. Dat bepaalde onze Hoge Raad gisteren in cassatie van een arrest uit 2010. Wel is het arrest beperkt tot standaardsoftware die je voor onbepaalde tijd verkrijgt, dus maatwerkregelingen en tijdelijke licenties zijn en blijven licenties.

De zaak was aangespannen omdat een stuk standaardsoftware niet goed werkte. De licentienemer had daarover geklaagd, en de softwaremaker beriep zich op de wettelijke regel die bepaalt dat je bij een aankoop van een product “binnen bekwame tijd nadat hij dit heeft ontdekt” dit moet melden (art. 7:23 BW), wat de klager dus niet gedaan had. Maar wacht eens even, software (standaard of maatwerk) is toch helemaal geen product? Een product moet voor menselijke beheersing vatbaar zijn (pijn doen als ’t op je voeten valt, zeg maar) en software is dat niet.

De Hoge Raad vindt het echter zinvol om de regels over koop ook door te trekken naar software. De wetgever heeft immers ‘koop’ echt niet specifiek bedoeld voor fysieke zaken. Ook vermogensrechten kun je kopen (art. 7:47 BW), en die zijn ook bepaald niet stoffelijk. Wel moet je dan even kijken in hoeverre het recht rond koop ‘past’ bij dat vermogensrecht.

Meer algemeen rechtvaardigt de Hoge Raad dit standpunt met een erg fijne schop tegen de schenen van de “nee het is slechts een licentie en uw aanspraken op juistheid zijn contractueel uitgesloten”-softwarelicentiegevers:

Deze toepasselijkheid is ook wenselijk omdat de kooptitel een uitgewerkte regeling geeft inzake conformiteit, klachtplicht en verjaring, en omdat met die toepasselijkheid de rechtspositie van de koper wordt versterkt (met name in het geval van consumentenkoop en koop op afstand). In al deze opzichten bestaat geen aanleiding de aanschaf van standaardsoftware te onderscheiden van de koop van zaken en vermogensrechten.

Oftewel, het is de bedoeling dat mensen de regels rond koop kunnen gaan inzetten bij het betrekken van standaardsoftware. Dank u.

Op grond van dit arrest kun je dus bij defecte software net zo goed als bij een defecte auto (sorry, die vergelijking móet gewoon) eisen dat de leverancier tot herstel of vervanging opgaat. En bij consumentensoftware kan dat niet worden uitgesloten of beperkt.

Wel kom je dan meteen uit bij de vraag wannéér sprake is van defecte software. Software moet immers voldoen aan de redelijkerwijs gewekte verwachtingen, en probleemloze software mag je écht niet verwachten.

Arnoud

Waarom zit er een Weens Koopverdrag in mijn softwarelicentie?

Geplaatst op in Intellectuele rechten, Iusmentis, 7 reacties

uncisg.pngIn 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<br/> Afbeelding: Drafting Contracts Under the CISG, Flechtner, Brand en Walter Oxford University Press, USA (December 31, 2007)

De onderhoudsovereenkomst als vrijbrief om prutswerk te leveren

Geplaatst op in Intellectuele rechten, 8 reacties

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

Amerikanen gooien (eindelijk) octrooirecht op de schop

Geplaatst op in Intellectuele rechten, 10 reacties

Zo, dat werd tijd. De America Invents Act (voorheen Patent Reform Act of 2011) is door de Senaat goedgekeurd en door Obama getekend. Dit is de belangrijkste aanpassing aan de Amerikaanse patentwet in decennia, hoewel het dan ergens wel weer jammer is dat het weinig van de problemen met patenten oplost.

De belangrijkste wijziging is dat men afstapt van het “first to invent”-principe en naar “first to file” gaat. Dat wil zeggen dat het niet langer uitmaakt wanneer de uitvinding is gedaan, beslissend voor wie octrooi krijgt is wie als eerste de aanvraag heeft ingediend. Daarmee wordt eindelijk aansluiting gezocht bij de rest van de wereld, die dit al decennia heeft. Het is namelijk veel eenvoudiger te controleren: een datumstempel van de octrooiraad is genoeg. Bij first to invent moet je naar logboeken gaan kijken, getuigen horen en wat al niet meer.

Natuurlijk zijn er aparte regelingen voor als persoon A een beschrijving van diens uitvinding steelt en gauw indient. Een aparte “derivation” regeling biedt de bestolene een mogelijkheid zijn recht te halen. Dit was een gevoelig punt voor kleine uitvinders, die in de VS permanent klagen dat grote bedrijven (het liefst uit Japan of Europa, want dan kun je de Stars and Stripes wapperen) hun uitvindingen afkijken en gauw patenteren. Met first to invent zou men daartegen beschermd zijn, hoewel uit onderzoek regelmatig blijkt dat 99% van de rechtszaken over wie de eerste uitvinder was, gewonnen worden door degene die als eerste de aanvraag had ingediend.

Er komen geen specifieke regels over wanneer software of business methods octrooieerbaar zouden moeten zijn. De enige uitzondering hierop is een verbod op het octrooieren van tax strategies, oftewel manieren om belastingaangiftes te doen of belastbaarheid te beperken. Dergelijke technieken zijn nu per definitie niet meer octrooieerbaar. Ik heb géén idee waarom dit specifieke punt nu zo belangrijk was dat het in de wet moest.

Over inventiviteit (de mate van innovatie) komen er geen nieuwe regels. Men vertrouwt hier op het proces bij de rechtbank, dat de betreffende criteria moet toetsen en uitwerken naarmate de techniek voortschrijdt. Jammer: het is niet ongebruikelijk om in een wet op zeker moment het voortschrijdend inzicht uit de rechtspraak vast te leggen, dus dat had hier mooi gekund. Maar het formuleren van een criterium op dit punt is bijzonder lastig.

Ook het niet gehaald heeft het innovatieve puntje van schadeberekeningen: het oorspronkelijke voorstel bevatte een regeling dat een externe expert moest inschatten welke toegevoegde waarde de geoctrooieerde technologie had voor het inbreukmakende product, waarna de schadevergoeding als percentage daarvan zou worden vastgesteld. Daarmee zou een halt zijn toegeroepen aan de vele miljoenenclaims gebaseerd op de waarde van het product, zonder rekening te houden met de waarde van de uitvinding (je kunt nu een percentage van de waarde van een oceaancruiseschip claimen als het patent op je stoomfluitje is geschonden.)

Wel zijn er nieuwe procedures om de geldigheid van patenten aan te vechten bij het USPTO, zodat dure en lange rechtszaken minder vaak nodig zouden moeten zijn. Geen slecht idee, maar ik vermoed dat het nog wel even duurt voor mensen deze procedure gaan gebruiken. Iedereen zal de kat uit de boom willen kijken hoe octrooihoudervriendelijk deze procedure gaat uitpakken.

Arnoud