Clean room softwareontwikkeling versus het auteursrecht

Regelmatig 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

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

Kent u onze boekenserie Deskundig en praktisch juridisch advies al? Webwinkels, hosting, software, security en meer!

Gerelateerde berichten:

• Wat mag ik met snippets van Stack Overflow? (13/01/20 08:12)
• Voorintekenen: ons nieuwe boek “Software: Deskundig en praktisch juridisch advies” (27/05/11 08:05)
• Wordle door New York Times gekocht, maar wat dan precies? (04/02/22 08:13)
• Mag je licentie-incompatibele dependencies meeleveren met je software? (04/01/17 08:16)
• Auteursrecht op programmeertalen kan niet (of je moet wel heel creatief zijn) (04/05/12 08:16)

Reacties:

Er zijn nog geen reacties op dit bericht.