Van wie is samen geschreven software eigenlijk?

Een lezer vroeg me:

Samen met een kennis werk ik al geruime tijd aan een stuk software, dat we gebruiken voor een betaalde webdienst. Nu overweeg ik ermee te stoppen, want ik heb privé andere prioriteiten. Ik heb de bulk van het werk gedaan, maar mijn partner ook best aardig wat. Hoe moeten wij dit regelen, aan wie komen deze rechten toe?

Hoofdregel van de Auteurswet is dat de rechten liggen bij de partij die het creatieve werk heeft gedaan. Als twee mensen werk doen, dan ontstaan er dus twee auteursrechten naast elkaar. Ieder van de ontwikkelaars mag dan beslissen wat hij of zij daarmee doet.

Althans in principe, want je moet in alle redelijkheid wel rekening houden met de belangen van de ander. Dit is altijd een heel gedoe om achteraf recht te trekken, zeker als mensen met ruzie uit elkaar gaan. Het is dus veel beter dit vooraf te regelen, of zoals deze vraagsteller het netjes op het moment zelf te willen uitzoeken.

Iets ingewikkelder wordt het als het werk van de twee niet goed los te weven is. Er is dan namelijk sprake van een gemeenschappelijk auteursrecht, één recht dat aan beide ontwikkelaars toekomt. Dat kun je niet zomaar verdelen, je bent er samen eigenaar van. Hier moet dus worden afgesproken wie van de twee het recht meeneemt – en natuurlijk wat de ander er dan nog mee mag doen.

Als een van de twee ermee stopt, dan is het makkelijk. Je spreekt dan af (schriftelijk en met handtekening) dat alle rechten naar de voortzettende partner gaan, en waarschijnlijk zal de stoppende partner dan een afkoopsom ontvangen of een laatste winstuitkering. Je hoeft je dan denk ik geen zorgen te maken over licenties aan de stoppende partner, hij ging immers stoppen.

Willen beiden uit elkaar en apart hetzelfde gaan doen, dan wordt het ingewikkelder. Degene met de rechten staat net wat sterker dan degene die alleen een licentie krijgt om onder die rechten óók te opereren. Je kunt natuurlijk keiharde afspraken maken, maar wat doe je dan als er toch ruzie komt of de partij met rechten verkoopt die aan een derde? Om die reden kan het interessant zijn om in dat geval alle rechten gemeenschappelijk te verklaren, zodat je beiden van elkaar afhankelijk blijft.

Arnoud

19 reacties

  1. Zou iets van een royalties niet ook een optie zijn? Als je hier geld mee verdient, krijg ik 20% van de winst, tot een maximum van x per jaar, of zo? Gezien de verhalen op het internet van partners die uit een project stapten voordat het groots werd, lijkt me dat een interessante optie, maar misschien not done?

    Niet dat ik in zo’n situatie zit trouwens.

    1. Als de doorgaande partner aan de code blijft werken en na een paar jaar word de software een succes, hoeveel van de code op dat moment is dan nog van de gestopte partner. Mogelijk is de hele code meerdere keren over de kop gegaan of is er van grond af een nieuwe versie geschreven. De ervaring en kennis opgedaan met het maken van de eerste versie (waar de gestopte parner ook aan heeft gewerkt) kan dan de basis zijn voor de nieuwe versie.

      Stel dat ik samen met iemand een email programma heb geschreven, ik stop ermee en we leggen vast dat ik 20% van de opbrengsten van het programma krijg. Als dan na 5 jaar het email programma langzaam is veranderd in een chat programma en vervolgens in de opvolger van twitter dat miljoenen verdient. Heb ik dan recht op 20% van die miljoenen, omdat dit een doorevolutie is van een programma waar ik aan meegewerkt heb?

      Hoewel royalties eerlijk lijken, is het volgens mij heel lastig goed vast te leggen op 20% van welke opbrengsten de stoppende partner recht heeft.

      1. Ik heb een keer precies dit in het contract opgenomen. De uittredende partner kreeg 20% van de winst, jaarlijks werd dat naar rato bijgesteld conform de verhouding van zijn code in het gehele project, en sowieso met een stop van ik meen tien jaar. Dat was nog wel even een discussie want hoe definieer je ‘verhouding’ van één module in een groot project? Aantal regels code is natuurlijk fraudegevoelig, lappen commentaar kunnen een word count beïnvloeden en functiepunten voelden wat complex om te berekenen. Uiteindelijk kwam men op een bijstelling naar redelijkheid, met bindend advies van een deskundige als ze er samen niet uitkomen. Nooit meer wat van gehoord.

    1. “Beste vroegere klant, u bent bij deze uitgenodigd om voor de rechter te versch… Grapje, ik wil graag weten of u nog problemen heeft ondervonden met het contract dat we samen hebben opgesteld. Ik hoor graag in onderstaande enquete of het allemaal goed is gegaan.”

  2. Ik heb altijd wat moeite gehad met het beschermen van software onder het auteursrecht. Ik weet wel dat dit algemeen aangenomen wordt, en ben er ook niet op tegen omdat dit eigenlijk het enige middel is om software te beschermen.

    Maar een grote vraag is: wat is er nu eigenlijk beschermd?

    De regels sourcecode, naar analogie met een boek? Dat is mogelijk, maar dat begint te wringen om twee redenen: 1) omdat die nauwelijks voor zinvolle zintuigelijke waarneming vatbaar zijn. Immers, er is maar een idioot klein percentage van de mensen dat het eigen en oorspronkelijke karakter kan beoordelen, zeker als je de keuzes die om technische redenen gemaakt nog moet wegdenken ook. Zelfs een ervaren medeprogrammeur zal een serieuze studie moeten doen alvorens de sourcecode, en de al dan niet creatieve aspecten daarin, zintuigelijk waarneembaar zijn voor hem 2) Is het wel de sourcecode die vermenigvuldigd wordt, in de praktijk? Volgens mij is het eerder een gecompileerde versie van de sourcecode, en die is onherkenbaar

    Is dan misschien het uiteindelijke resultaat op het scherm beschermd? De combinatie van functionaliteiten en uiterlijke look? Mogelijk, maar die kan ook identiek gemaakt worden met andere software. En er zijn ook vele softwaremodules die potentieel beschermd zijn maar die helemaal geen bijzondere output leveren, maar bijvoorbeeld alleen een Ja/Nee beslissing. Dus dit zal het ook niet zijn, wat er nu echt beschermd is.

    De bescherming van software op basis van het auteursrecht is dun, omdat de wet maar als randgeval past op software. Voor zover ik weet zit er alleen auteursrecht op een concrete versie van software, niet op de onderliggende concepten.

    En die bescherming, die al zo dun is, zou je dan ook nog eens willen laten slaan op de opgesplitste delen? Nee, dat gaat me een stap te ver.

    Zodra de doorgaande programmeur 1 regel verandert, is de software anders, en is er een nieuw werk gecreeerd. Het oude werk is niet meer relevant, en wie daar het auteursrecht op heeft is ook niet meer relevant.

    Ja, er zitten oude regels code in, en ja, misschien zijn die auteursrechtelijk beschermd, maar waarschijnlijk voldoen ze individueel niet aan de eis dat ze het resultaat zijn van creatieve keuzes. Net zoals de individuele penseelstreken in een schilderij dat niet doen. En zo wel, dan zijn de makkelijk opnieuw te schrijven, maar dan anders.

    Kortom: Het auteursrecht mag misschien zijn nut hebben om een producent van een kant en klaar softwareproduct tegen kopierende klanten te beschermen, maar meer niet. Het is een ongeschikte basis om een eigendomsrecht tussen twee ontwikkelaars mee te regelen.

    Naar mijn smaak worden in deze case twee dingen door elkaar gehaald: historisch ontwikkelwerk (en hoe daar een eerlijke waarde aan toe te kennen), en auteursrecht (dat geen link heeft met de hoeveelheid historisch werk, en geen intrinsieke waarde heeft, alleen ‘wat de gek ervoor geeft’)

    Ik denk dat het beter is deze zaak niet te bekijken vanuit een auteursrecht standpunt (dat leidt alleen maar tot extreme extrapolaties van het auteursrecht) maar gewoon als zakenpartners die uit elkaar gaan maar waarbij een van beide de activiteiten wil doorzetten, en er gewoon op basis van een zo objectief mogelijke waardebepaling (maar dat zal moeilijk zijn) in combinatie met een simpele onderhandeling een deal gesloten moet worden.

    De rest is kunstmatig.

    1. Ben het met je eens dat in dit geval het gewoon ging om uit elkaar gaan en een realistische waardebepaling voor de eindafrekening verzinnen. Maar het gaat mij te ver om auteursrecht op software categorisch als kunstmatig af te doen. Natuurlijk heb je deskundigen nodig om te bepalen wát het creatieve werk was, maar ik vind dat geen onwerkbare maatstaf. Voor complexe wetenschappelijke papers zul je ook even moeten zoeken voor iemand die kan zeggen wat nu echt het creatieve is en wat ‘slechts’ het doen van berekeningen. Dat is iets waar rechters gewoon mee om kunnen gaan.

      Verder vind ik het veel te snel om te stellen dat één regel wijzigen het gehele softwarewerk anders maakt. Bij grote werken is dan echt niet gelijk het hele karakter anders. Een nieuwe op AI gebaseerde spellchecker in Word maakt die tekstverwerker niet ineens een spreadsheet. De bijdragen vanuit andere hoek (de tabel-invoegmodule en de Clippy assistent) zijn niet van waarde veranderd doordat de spellchecker slimmer werd. Dus de auteursrechten op die modules vind ik na de nieuwe spellchecker nog net zo sterk als er voor.

      1. Goed, als je het niet kunstmatig vindt, leg mij dan eens uit welke vorm waarin software zich kan manifesteren onder het auteursrecht vallen. Met andere woorden, wat is dat auteursrechtelijk, ‘software’?

        Sourcecode? Zou kunnen, maar heb je niet veel aan in de praktijk (tenminste als mijn aanname klopt dat de meeste software niet in de vorm van sourcecode verspreid worden). EN bovendien…. ik weet als leek echt niet waar ik die sourcecode moet vinden. Als ik Word installeer (of een illegale kopie), dan is de sourcecode (als die er al is) goed verborgen. En iets wat DOOR DE AUTEURSRECHTHEBBENDE bewust goed verborgen is, is dat nog wel ‘voor zintuigelijke waarneming vatbaar’? Grijs gebied hoor, als je het mij vraagt.

        Je vergelijking met de wetenschappelijke papers gaat niet op. Dat zijn gewoon zinnen in menselijke taal, bedoeld om wetenschappelijke concepten aan andere mensen uit te leggen. Dat uitleggen kan op veel verschillende goede manieren en op veel matig-goede manieren, en de omvorming van die uitleg naar leesbare zinnen draagt per definitie het stempel van de maker. Daar hoeft geen specialist aan te pas te komen om daarvan het creatieve vast te stellen.

        Natuurlijk hebben alle modules van Word hun eigen auteursrecht, en mag je daarop geen inbreuk maken. Maar op een gegeven moment houdt het op. Niet iedere regel code heeft zijn eigen auteursrecht, dat zul je toch met me eens zijn. Ik zou zelfs durven stellen: Ik kan me geen individuele regel code voorstellen waar auteursrecht op rust.

        Maar ik blijf erbij dat iedere nieuwe versie van Word, als is er maar 1 regel verschil, een nieuw auteursrechtelijk beschermd werk oplevert. Wel een werk dat honderden of duizenden andere auteursrechtelijk beschermde modules omvat, maar daar ging het niet om.

        Ik vind, gevoelsmatig, dat software beschermd moet kunnen worden. Maar het auteursrecht past erop als een vierkant deksel op een rechthoekige doos, maar het is het beste deksel wat we momenteel voor handen hebben.

        Het lijkt er een beetje op dat de wens om software te beschermen ervoor gezorgd heeft dat de juridische en technische precisie die eigenlijk nodig is, een beetje losgelaten is.

        Als die precisie er wel is, is mijn vraag ‘welke manifestatievorm van software is dan precies auteursrechtelijk beschermd’ simpel te beantwoorden.

        1. Software is een werk dat bestaat uit instructies voor een computer, geschreven in een programmeertaal. Als je geluk hebt, inclusief documentatie in gewone taal. Je moet inderdaad goed onderlegd zijn dit werk te kunnen vatten, maar principieel vind ik dat geen argument – genoeg kunst die ik niet snap zonder uitleg, en voor wetenschap heb je soms ook jarenlange studie nodig om de echte teksten van de random text generator output te onderscheiden.

          Meer algemeen gaat het bij auteursrecht om een ‘werk’ en niet perse waar het in gevat is. Een roman is dus auteursrechtelijk het verhaal, het werk, en niet perse de bundel papier waar deze in afgedrukt is. De pocketversie of de op de radio voorgelezen audio-editie is dus gewoon een kopie van de roman. Bij software gaat het dus precies om hetzelfde. Maak jij een app met mijn library erin (en mijn library was voor server-side tools) dan is dat gewoon een kopie.

          Het klopt dat 1 regel veranderen kan leiden tot een nieuw werk, trivialiteiten als het op een nieuwe regel zetten van { even daargelaten. Maar dat tast de auteursrechten in de delen niet aan. Als ik een foto aanlever voor een boek, en men herschrijft later hoofdstuk 1, dan blijft mijn auteursrecht op mijn foto gewoon intact.

          Je hebt gelijk dat men software het auteursrecht in geduwd heeft en gezegd, zoek het lekker uit samen. Software is primair een utilitair werk, een set instructies, een algoritme. Dat hoort onder het octrooirecht, dat hebben we voor vernieuwende utilitaire werken. Alleen 95% van de software is niet innovatief genoeg voor octrooi (en over de rest krijg je dan héél verhitte debatten over softwarepatenten en de functie van het octrooirecht) dus om de lobbyisten ter wille te zijn is dan maar voor auteursrecht gekozen.

          1. Auteursrecht is toch een prima oplossing voor software*. Alleen hadden ze er net even wat meer duidelijkheid bij moeten geven. Je source code is auteursrechtelijk beschermt, dus een ander kan geen kopie hiervan maken en deze verkopen. De binary is een ‘vertaling’, net als bij boeken zijn de vertalingen een ‘afgeleid’ werk met het oorspronkelijke auteursrecht erop. Bij boeken is een vertaling creatief en ontstaat er aanvullend een auteursrecht voor de vertaler, bij software is de vertaling puur functioneel en ontstaat er door compileren dus geen nieuw auteursrecht.

            Waar gaat het dan wel fout? Bij gebruik van dynamische bibliotheken en APIs. Het linken aan een dynamische bibliotheek creëert geen afgeleid werk aangezien het werk geen onderdeel wordt van de software en apart verspreid kan worden. Je kan zelfs een complete nieuwe implementatie schrijven die de zelfde functies aanbiedt en alles blijft werken.

            En dat brengt me bij APIs. Jarenlang is iedereen ervan uit gegaan dat die functioneel zijn en er dus geen auteursrecht op rust. En toen kwamen Oracle en een hele slechte rechter die bepaalde dat een API toch creatief was. Opvallend dat een eerdere rechter, die de moeite had genomen om te leren programmeren om een goed oordeel te kunnen vellen het tegenovergestelde vond. Maar niet gehinderd door gebrek aan kennis van de materie dacht een hogere rechter daar anders over. En nu is auteursrecht dus in ieder geval in de VS net zo shit geworden voor software als dat het octrooirecht al was.

            • Natuurlijk kunnen we dan ok weer de discussie gaan voeren of het huidige auteursrecht nog wel redelijk is, maar die voerden we elders al.
            1. Jarenlang is iedereen ervan uit gegaan dat die functioneel zijn en er dus geen auteursrecht op rust.

              Vreemde redenering. Waarom zou iets functioneels (API) geen auteursrecht kunnen hebben? (Software is ook functioneel, toch?) Het definieren van een goede API of interface kan erg complex en creatief werk zijn, en in veel situaties belangrijker dan het uitwerken daarvan naar een implementatie, wat some zelfs ‘mechanisch’ kan.

              1. Het idee dat je geen auteursrecht op API’s kunt hebben vloeit voort (in de VS) uit de “merger doctrine.” Je heb een auteursrecht op een specifieke uitdrukking van een idee, niet op het onderliggende idee zelf, dat blijft vrij en moet vrij blijven (omdat je anders het gebied van het octrooirecht betreedt, en dat is daarvoor gemaakt; al kent dat een vergelijkbaar onderscheid tussen ‘idee’ en ‘uitvinding’.) Als nu, om wat voor reden dan ook, een idee alleen op een specifieke manier uitgedrukt kan worden, dan is het onredelijk om op die unieke uitdrukking een monopolie te gegeven (los daarvan is in het auteursrecht onafhankelijke schepping een geldig verweer).

                Stel nu dat je een API maakt waarin een handshake met een gedicht als onderdeel van een handshake protocol wordt gebruikt, dan kun je dus niet meer met die specifieke API praten zonder inbreuk te maken op de rechten op dat gedicht. Er is echter geen andere manier om met de API te praten en dan moet het auteursrecht dus wijken (omdat je anders auteursrecht kunt misbruiken om octrooi-achtige rechten te bemachtigen zonder de bijbehorende procedures en kosten). Door die beruchte uitspraak in de VS (waar de rechter niet alleen geen kaas had gegeten van programeren, maar ook van niet van auteursrecht) is dat daar nu ondermijnd.

            2. Apis in Europees recht zijn duidelijk. In de wet (richtlijn) is het duidelijk geregeld en er is een uitspraak van het Europees Hof van Justitie in de SAS zaak die het herhaald. De Oracle zaak speelt in de VS onder dat recht (inclusief minder zware antitrust rechtgeving)

          2. Je moet inderdaad goed onderlegd zijn dit werk te kunnen vatten, maar principieel vind ik dat geen argument – genoeg kunst die ik niet snap zonder uitleg, en voor wetenschap heb je soms ook jarenlange studie nodig om de echte teksten van de random text generator output te onderscheiden.

            Toch is er een verschil: Als je een kunstwerk niet snapt, wat snap je dan niet? Dan snap je niet wat de kunstenaar ermee bedoelde en/of je snapt niet wat er, kunsthistorisch gezien, bijzonder aan is, waarom het kunst is.

            Maar je kunt nog steeds wel het hele werk zien, en het mooi vinden of niet, en beoordelen of een ander werk een kopie is.

            De kunstenaar krijgt immers geen auteursrecht op die aspecten die in een kunsthistorische context een stijlbreuk met de vorige generatie kunstenaars is, maar op het werk als geheel.

            Ook de wetenschapper krijgt geen auteursrecht op zijn wetenschappelijke theorie, maar alleen op de zinnen waarmee hij die uitlegt. Je hoeft de theorie niet te snappen, de theorie kan volledige fake science zijn, en zelfs de zinnen kunnen gibberish zijn, de wetenschapper heeft nog steeds het auteursrecht op zijn paper (als er enige creativiteit in zit, maar dat is al snel het geval), maar niet op de onderliggende theorie, zelfs als er niemand in de wereld is die de theorie kan begrijpen.

            ‘Snappen of niet’ door anderen is inderdaad niet het criterium. Of er creatieve elementen zitten in het werk onder discussie (NIET: in de onderliggende gedachte) en of het werk vatbaar is voor zintuigelijke waarneming, dat is het criterium. En dat kun jij prima bepalen, ook als je het kunstwerk of de wetenschappelijke theorie niet begrijpt.

            Juist daarom is het zo belangrijk te definieren wat het werk is. Een programma werkend in een computer is niet vatbaar voor zintuigelijke waarneming. Alleen een uitgeschreven versie is dat (OK, laten we dan ook zeggen: een versie geregistreerd op een uitleesbare drager)

            Maar waar moet je dan naar kijken? Naar de vorm of naar de functie. Naar de vorm natuurlijk. OP de functie kun je geen auterusrecht krijgen.

            Van die vorm kan ik een kopie maken en een futiliteit aanpassen zodat het programma niet meer werkt, maar objectief is het visueel voor 99.9999% hetzelfde, dus inbreuk.

            Aan de andere kant kan ik de vorm grondig aanpassen (door lappen niet-executerende tekst op te nemen, of door (groepen) instructies om te wisselen zonder functioneel iets te doen. Dan kan ik geen inbreuk plegen.

            Juist doordat je zit met de eis ‘zuintuigelijk waarneembaar’ is het concept van een set instructies niet auteursrechtelijk beschermd, maar alleen de zintuigelijk waarneembare versies daarvan. En die zijn poepsimpel zintuigelijk waarneembaar verschillend te maken, zonder de functionaliteit te veranderen.

            Net als een andere wetenschapper, die dezelfde theorie van zijn collega op een andere manier schriftelijk uitlegt.

    1. Je kunt een software licentie (ook als je de GPL gebruikt voor jouw software) niet zomaar intrekken. Ten eerste zul je alle verspreiders en bezitters van een kopie moeten aanspreken of aanschrijven met de mededeling dat ze de software niet verder mogen verspreiden en/of mogen gebruiken. In hoeverre je dat kunt afdwingen zonder een schadevergoeding te betalen wordt een juridisch verhaal, afhankelijk van het land waarin de gebruiker of verspreider woont. Ik verwacht dat het verbieden van verdere distributie wel juridisch mogelijk is (maar praktisch onuitvoerbaar). Verder gebruik verbieden is lastig te bereiken want dat is volgens de hoogste EU-rechter een inbreuk op een vermogensrecht.

      En ja, als je ooit software bijgedragen hebt aan de Linux kernel of een ander Open Source project, dan zul je rekening moeten houden met de belangen van de andere auteurs van het stuk software. Je zult dan een heel goed verhaal moeten hebben waarom het intrekken van de toestemming om jouw bijdrage te gebruiken zoveel zwaarder weegt dan het (collectieve) belang van de andere auteurs om een compleet en werkend programma te leveren. De kans dat je daarin slaagt is miniem.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.