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<br/> PS: wie meer over software en met name open source software, schrijf je in voor onze open source workshop van 4 oktober!
wil weten? Moet dat niet nog ergens in je laatste zin over de workshop staan? 😉
Natuurlijk zijn er veel methodes om van een programma zonder broncode toch nog een soort broncode te genereren. Decompileren van applicaties is vooral goed mogelijk omdat compilers code volgens vaste patronen aanmaken. Deze patronen zijn weer te herkennen en weer terug om te zetten naar code, mits je maar weet welke compiler is gebruikt. En een ander nadeel is dat je meestal moet gokken naar namen van variabelen. Het probleem echter van software nabouwen is dat de meeste ontwikkelaars geneigd zijn om dezelfde naamgeving te hanteren, waardoor de kans bestaat dat de nieuwe code lijkt op de oude code, ook al heeft de programmeur de oude code nooit gezien. Maar er zijn natuurlijk alternatieve methodes om een applicatie na te bouwen, namelijk door een andere ontwikkel-omgeving te gebruiken dan de originele code. Als het oorspronkelijke programma in C++ was geschreven dan kun je een variant daarop in Delphi (Object-Pascal) schrijven en dan is er eigenlijk geen sprake meer van kopieren. (Of misschien wel, maar probeer dat maar aan te tonen bij twee omgevingen die syntactisch anders zijn.) Leuk hierbij is hoe vroeger Lotus 1-2-3 een populaire spreadsheet was, geschreven in C++, waarna Borland met Quattro Pro aan kwam zetten als alternatieve spreadsheet geschreven in Delphi. Natuurlijk kwamen daar de nodige problemen van, maar ja… Andere syntax, he? Het resultaat was een vrij interessante rechtspraak in 1996 die Borland uiteindelijk won, maar toen was Quattro Pro al doorverkocht aan Novell. En later aan Corel.
Is het eerste IBM-compatibele BIOS niet ook zo ontstaan? Kan me zo’n verhaal herinneren uit het HCC-blad van vroeger. Toen IBM nog de grootheerser op de PC-markt was (begin jaren ’80 vzviw) kon je als fabrikant voor ontzettend veel geld hun BIOS in licentie nemen. De bedragen waren astronomisch, waarbij IBM ook nog een behoorlijke vinger in de pap wilde houden. Een team van analisten is vervolgens in opdracht het BIOS van IBM uitgebreid gaan documenteren en uit elkaar gaan trekken, waarna een nieuw team met die documentatie een nieuw BIOS is gaan bouwen.
Ik vond dat vroeger wel een interessant verhaal. 🙂
Hoewel de Pear computer duidelijk een parodie is op de Apple computers, waren er in de tijd dat de eerste Apple computers de markt begon te veroveren best veel bedrijven die een Apple-cloon aanboden onder een andere naam. Er is tussen 1986 en 1991 een behoorlijke Clone War geweest tussen Apple en diverse cloon-fabrikanten. Daarvan heeft PsyStar als een der laatsten het onderspit gedolven. En ja, bij de IBM PC was rond diezelfde tijd ook een vergelijkbare strijd gaande maar IBM was slimmer en accepteerde de cloon-computers omdat ze er zelf ook populairder door werden. Indien Apple zelf ook meer open had gestaan dan zou Windows nooit zo’n groot marktaandeel hebben gehad.
@Kaijuu: Dat lijkt inderdaad waar te zijn, Wikipedia noemt deze offline referentie als bron daarvoor: ^ Mills, H.; M. Dyer and R. Linger (September 1987). “Cleanroom Software Engineering”. IEEE Software 4 (5): 19–25. doi:10.1109/MS.1987.231413.
Kaijuu | 6 september 2012 @ 16:38:
Misschien bedoel je dit?: http://en.wikipedia.org/wiki/DR_DOS
Geen BIOS- maar DOS-kloon, maar beetje hetzelfde idee. Onafhankelijk ontwikkeld vanuit CP/M, dat ook min of meer de bakermat was voor PC/DOS en later MS/DOS.
Windows NT (of was het 2000 en XP?) is min of meer ontwikkeld uit VMS van Digital, d.w.z. de makers daarvan waren overgekocht en hebben dezelfde ontwikkeling nogmaals gedaan, maar dan anders. Zoiets.
@Ruud, het is juist geen cleanroom als je ontwikkelaars inzet die toegang hebben gehad tot de code van het te vervangen programma. Windows NT was een nieuwe ontwikkeling, met andere requirements dan VMS of “compatibel zijn met VMS”.
Arnoud, lees nog even reactie #1: er staat een fout in de laatste zin van je blogpost.
Is het toegestaan om 1 van beide kanten van de “Chinese muur” methode te automatiseren? Of allebei misschien? Ik kan me voorstellen dat die “documentatie” die door de muur heen gaat heel goed geschreven kan worden in een machine-leesbare declaratieve Turing-complete taal.
Er zijn allerlei gradaties in hoe zo’n proces geautomatiseerd kan worden. Het is gebruikelijk om het maken van object-code te automatiseren met een compiler, maar ook de analyse van objectcode kan gedeeltelijk geautomatiseerd worden met een de-compiler. Wat je verder nog nodig hebt is een “documentatie-taal” waarin je aangeeft aan welke requirements het programma moet voldoen: * welke interfaces heeft het? * hoe zit het protocol op de interfaces in elkaar? * welke toestandsvariabelen heeft de software? * wat is het gedrag van de software (bijv. input-event + state -> output-event + state)? Ik dacht zo dat een declaratieve taal het dichtst ligt bij wat je nog specificaties/documentatie zou kunnen noemen. Maar misschien kom je ook wel weg met een imperatieve taal? Dan wordt het helemaal makkelijk…
@Corné: Je gebruikt een “clean room” methode om te documenteren dat de ontwikkelaars alleen inzage hebben gehad in de (functionele) interfacebeschrijving. Uit een “high-level” interfacebeschrijving automatisch code genereren is de “Heilige graal” van de software-ontwikkeling. Om vergelijkbare redenen is het automatisch reverse-engineeren van software tot een leesbare functionele specificatie lastig; maar in de meeste gevallen is dat ook niet nodig: de ontwikkelaars mogen de gebruikersdocumentatie gebruiken als naslag bij het bouwen. Wat je vaak ziet is dat je in de “vuile kamer” maar een klein team aan reverse engineers nodig hebt om specifieke vragen over hoe de code randgevallen behandelt te beantwoorden.
@MathFox: Ik begrijp je opmerking over de “Heilige graal”: het probleem is daarbij vooral dat “begrijpelijk voor de computer” en “begrijpelijk voor mensen” verschillende dingen zijn. Je hebt op dit moment nog een software-engineer nodig om het verschil te overbruggen.
“Menselijke” taal geeft voor computers de volgende problemen: * er wordt veel voorkennis verwacht (al was het maar de betekenis van woorden) * mensen geven meestal geen volledige specificaties (je moet je “gezonde verstand” gebruiken om de ontbrekende specificaties in te vullen)
“Computer”-taal geeft voor mensen de volgende problemen: * beschrijvingen zijn formeel, maar daardoor ook cryptisch en vaak tegen-intuïtief * beschrijvingen zijn compleet, maar maken geen mentaal onderscheid tussen hoofd- en bijzaken
Mijn voorstel was om de “documentatie” die wordt doorgegeven van de dirty room naar de clean room op te stellen in een “computer”-taal. Dan hoef je de “heilige graal” (het vertalen tussen “mensen-taal” en “computer-taal”) niet te vinden, en kan je het proces toch effectief automatiseren.
@11:
Daarmee maak je effectief de dirty-room personen programmeurs met toegang tot de broncode. En dat mag dus niet. Aan de andere kant, waarom niet? Als een programmeur de werking van een programma opmaakt uit de broncode, en hij/zij schrijft vervolgens nieuwe code die voldoende afwijkend is (andere programmeertaal (Corné++)), hoe illegaal is dat?
Het is volstrekt legaal om als reverse engineer ook te werken aan de nieuwe software. Waar het om gaat is dat je niets overtypt, ook niet in gewijzigde vorm, uit de originele broncode. Clean room is een techniek om sterk bewijs te verkrijgen dat je niets overgetypt hebt (ook niet onbewust, vanwege code in je achterhoofd). Immers wat je nooit kunt hebben gezien, kun je ook niet hebben overgetypt. Enige gelijkenis móet dan wel toeval zijn.
Ja precies dus clean-room en chinese wall zijn middelen om te bewijzen dat wat je gedaan hebt wel legaal moet zijn, geen doelen op zich. Bedankt voor de verheldering.
@Corné: Eén van de juridische ficties is dat er in een machinevertaling (door de machine) geen creativiteit wordt toegevoegd en dat het eindresultaat van de vertaling dus een afgeleid werk van de invoer is. Zelfs als er programma’s zouden bestaan die volledig geautomatiseerd een functionele beschrijving kunnen genereren uit objectcode, dan zou die functionele beschrijving een afgeleid werk zijn van de objectcode. Als je aan de andere kant van “de muur” deze beschrijving weer door een automatisch vertaalprogramma haalt levert dat een programma op dat een 100% afgeleid werk is van het origineel en daarmee heb je het hoofddoel van clean room ontwikkeling gemist.
Als je succesvol clean room ontwikkeling wil doen moet je ervoor zorgen dat je voldoende (menselijke) creativiteit in het nieuwe werk stopt én dat je niet meer uit het originele werk overneemt dan strikt noodzakelijk is voor het bereiken van de interoperabiliteit. Bij de definitie van een publieke externe interface ben je beperkt in hoeveel creativiteit je kunt toepassen. Er zijn niet zoveel manieren om een functie sin te declareren met één floating point parameter en een floating point resultaat.
Betekent ‘fictie’ hier iets anders dan wat ik denk dat het betekent?
@Matthijs: return denkt(Matthijs, “aanname”) ? “nee” : “ja”;
Het was een serieuze vraag, eigenlijk. Je begint met te zeggen dat X fictie is, en vervolgens onderbouw je dit in mijn ogen perfect. Wel of geen fictie dus? Vandaar dus dat ik me afvroeg of het woord fictie nog een andere betekenis heeft.
Of een machine wel of niet creativiteit kan toevoegen weet ik niet (nu nog niet iig), maar de vraag is of dat wenselijk is, in dit geval. Je wilt immers functioneel gelijke software bouwen en niet iets anders, maar dat wel heel ‘creatief’ is 🙂
Matthijs, De term fictie wordt in juridische kringen gebruikt als term voor “aanname gebaseerd op wettelijke gronden.” Een rechter moet zijn uitspraak op een fictie baseren als de wet dat zo voorschrijft.
@MathFox: Ik gebruik zelf eerder de term “axioma”, een niet-bewezen maar toch als grondslag gebruikte stelling. Het gaat er niet zozeer om dat het in de wet staat, maar dat in de wet staat dat het verplicht op die manier is ongeacht de werkelijkheid.
Zo is bijvoorbeeld mensen stilzwijgend verlengen met een jaar onredelijk volgens het axioma uit 6:236 sub j BW. “Wordt geacht onredelijk bezwarend te zijn”. Dus welk bewijs je ook hebt dat het in jouw geval toch redelijk is (je levert kerstbomen met korting, dat kán toch maar eens per jaar, en je korting is gigantisch, de consument wil het zo graag), je hebt ongelijk want het axioma zegt dat je dat hebt.
Er zijn ook wetten die geen axioma maar slechts een vermoeden opleveren (een nulhypothese?). Daarmee verschuift de bewijslast. Zo staat in 6:237 sub f BW dat het vermoedelijk onredelijk is om je aansprakelijkheid uit te sluiten of te beperken naar consumenten. Daarmee ligt de bewijslast bij het bedrijf: leg maar uit dat het nu wél redelijk is. Lukt dat, dan mag hij aansprakelijkheid beperken.
@19,20: Beiden bedankt voor de heldere uitleg!
@15: Ik snap niet waarom het nieuwe werk extra creativiteit moet bevatten. Is het niet de enige eis dat het niet de creativiteit van het oorspronkelijke werk bevat?
Ik weet niet zeker of conceptuele keuzes (bijv. hoe je een sinus precies berekent) vallen onder het auteursrecht of het octrooirecht of geen van beide, maar volgens mij bestaat een computerprogramma uit niets meer dan het volgende: A: volledige specificaties, op basis waarvan een nieuwe “drop-in-replacement” implementatie gemaakt kan worden. B: concept-keuzes, tot op het kleinste detail-niveau C: triviale keuzes (zoals de volgorde van dingen als de volgorde niet uitmaakt), en bij broncode: intern gebruikte variabele-namen, whitespace en commentaar
A is: wat moet de software precies doen B is: hoe doet de software dat precies C is: wat zit er nog meer in de software, dat niet strikt logisch valt af te leiden uit A en B
Als je (A, B, C) allemaal overneemt, dan heb je een kopie, en dat mag duidelijk niet. Voor zover ik begrijp is het toegestaan om alleen A over te nemen. De vraag is eigenlijk of het ook is toegestaan om (A, B) over te nemen: dat is namelijk makkelijk te automatiseren.
Ik vermoed dat dat verboden is. Ofwel: je mag wel kijken naar hoe de software iets doet om een beter beeld te krijgen van wat het geacht wordt te doen, maar het “hoe” mag niet van de dirty room naar de clean room. Klopt dit een beetje?
Een interessante complicatie hierbij is dat “hoe” en “wat” soms in elkaar overvloeien. Om het voorbeeld van de sinus-functie maar eens te gebruiken:
Stel, de mensen van het Wine-project hebben een “sin”-functie, die wordt aangeboden aan windows-programma’s als drop-in replacement voor de “sin”-functie van windows. Op een kwade dag blijkt een windows-programma te crashen in Wine, terwijl het wel goed werkt in windows. Nadere analyse maakt duidelijk dat het windows-programma slecht geprogrammeerd is, en een race-conditie bevat. In windows wordt de race-conditie niet getriggerd, maar doordat de timing van de Wine-versie van “sin” net iets anders is, gebeurt dat wel in Wine, met de crash als gevolg.
Oorspronkelijk was er geen timing-specificatie was voor de “sin”-functie: de exacte timing volgt uit de keuzes bij B, en niet uit de specificaties bij A. Door het bestaan van dit slecht geprogrammeerde windows-programma komt er wel een timing-specificatie bij: de timing-informatie verplaatst zich dus van B naar A. Om windows-compatibiliteit te bereiken moet Wine nu precies de zelfde timing imiteren, en dus waarschijnlijk precies het zelfde algoritme gebruiken als windows.
Extremer voorbeeld: stel een kopieerbeveiliging van een windows-programma controleert de secure hashes van bepaalde windows-DLLs, en weigert dienst als die hashes niet kloppen. De enige manier voor Wine om windows-compatibiliteit te bereiken is om de inhoud van die DLLs exact gelijk te maken als in windows. Ofwel: de complete inhoud van de DLLs is onderdeel geworden van de specificaties (A). Het zou dan toegestaan moeten zijn voor Wine om die DLLs letterlijk, ongewijzigd over te nemen.
@Arnoud, 20: Ik gebruik de term axioma alleen voor consistente logische systemen.
@Corné, 22: Als je enige doel is om een programma vrij beschikbaar te maken, hoef je er geen eigen creativiteit in te stoppen. Commerciële partijen willen graag een eigen auteursrecht om nog iets te verdienen aan de reverse-engineer-inspanning. Je mag kennis van “hoe doet een programma iets” overnemen voor zover het nodig is om de interoperabiliteit te bewerkstelligen. (Een van de wettelijke uitzonderingen op het auteursrecht.) En ja, het auteursrecht zit in de punten B en C die je noemt. Er is juridische steun voor je extreme standpunt dat code die essentieel is om voorbij DRM te komen letterlijk gekopieerd mag worden. Daar is door een Amerikaanse rechter ooit een uitspraak over gedaan in een zaak over game cartridges.
Beste Arnoud, ik lees onderaan dat je een open-source workshop gaat geven. Waarom staan in de hoofdtekst dan twee vreemde zaken? Te weten:
“Op software rust auteursrecht.” (Vraag: is dit ALTIJD zo, of is er ook software waarop geen auteursrecht rust, bijvoorbeeld omdat het triviaal is, of omdat de maker expliciet afziet van auteursrechten en de zaak dus in het publieke domein plaats?)
“De broncode mag niet worden gekopieerd of gepubliceerd, ook niet in gewijzigde vorm.” (Vraag: dat is toch lang niet altijd het geval? Onder auteursrechtelijke licenties als de GLP, MIT, BSD, Apache enzovoorts, mag er wel degelijk worden gekopieerd, gewijzigd, gepubliceerd en dergelijke, mits aan de voorwaarden van die licenties wordt voldaan).
Jij bent hier de expert in, vertel ons hoe het zit! Nu leest de tekst bijna als een BREIN-slogan (“voor alle software die u download moet u betalen” – eh…..ik heb net, zonder te betalen, volledig legaal een nieuwe Linux-distro op mijn laptop gezet……sterker zelfs, al mijn computers zijn 100% FOSS).
PRINT “Hello, World.” De vraag is of daar wel of geen auteursrechten op zitten. En ja, Brian Kernighan is de auteur van de C variant van deze regel code! Hij schreef de tutorial die uiteindelijk tot een boek over C leidde. Maar er schijnen oudere voorbeelden hiervan te bestaan en mijn variant hierboven is in een soort BASIC dialect. Deze regel code zou dus auteursrechtelijk beschermd kunnen zijn, maar het idee om voorbeeld-code te schrijven die hetzelfde doet is niet te beschermen. En de groet “Hello, world.” is ook niet te beschermen omdat het te weinig creatief is. En C heeft geen andere, practische methodes om hetzelfde resultaat te genereren, dus zou je kunnen stellen dat er niet genoeg creativiteit in deze code zit om deze te beschermen.
Desalniettemin is er nog wel een auteur die deze regel code als eerste schreef. Die kan de rechten claimen en dan is het maar te bezien of een rechter deze ook zal toekennen. Ik denk het niet, maar na de uitspraak van Sanoma tegen Geenstijl gelezen te hebben denk ik dat die auteur in Nederland een enorme kans heeft…Ik denk dat ik weet waar Arnoud morgen over gaat bloggen… 🙂
@24 Pieter, je moet twee keer “tenzij” toevoegen. Arnoud noemt de ‘default’ situatie.
Volgens mij zit het zo:
Op software rust auteursrecht tenzij de rechthebbende afstand heeft gedaan van die auteursrechten. Overigens heet het dan ‘public domain’ software.
Broncode mag niet worden gekopieerd etcetera, tenzij je de licentievoorwaarden accepteert (en voor zover het verbod niet beperkt door wetgeving zoals bijvoorbeeld het recht op thuiskopie).
Correct me if I’m wrong 🙂