Hoe bescherm ik mijn idee tegen claims van mijn werkgever?

Photo by Nick Fewings on Unsplash

Via Reddit:

Mijn werk ligt in het bedenken, ontwerpen en het begeleiden van de productie & testen van “klantspecifieke toepassingen”. Het duurt gemiddeld meer dan 8 jaar bij de werkgever voordat iemand zelfstandig zo’n toepassing kan ontwerpen vanwege de hoge complexiteit op meerdere technische disciplines. … Ik ben er van overtuigd dat ik een generator kan programmeren die 80% van de ontwerpen kan afvangen en een reductie van 60% van het jaarlijks aantal engineeringsuren kan bewerkstelligen. … Als ik in mijn eigen tijd deze generator ontwerp en het toch anders loopt dan verwacht als ik hiermee aan kom bij werkgever. Hoe zorg ik er dan voor dat werkgever deze niet opeist mits het tot een rechtsgang komt?
Het komt vaker voor dat mensen ergens werken waar een bepaald proces handmatig gebeurt en al jaren nooit de moeite is genomen om dit te automatiseren. Dat kan zijn omdat men niet weet hoe, er geen tijd/geld voor heeft of de meerwaarde er niet van inziet. Maar dat wil niet zeggen dat als jij dat dan ineens ongevraagd gaat bouwen, het je “eigen” idee is.

Basisregel uit het IE-recht is dat wat werknemers bedenken of maken, eigendom wordt van de werkgever. Althans, als het redelijkerwijs verbonden is met het werk. Nadrukkelijk niet relevant is of je het onder werktijd dan wel in eigen tijd maakte, op eigen hardware dan wel de werklaptop of op instructie dan wel eigen initiatief.

Wat is dan “redelijkerwijs verbonden”? Dat hangt een beetje van het recht af, maar grofweg komt het er op neer of de werkgever je hád kunnen instrueren dit te gaan maken. Als dat een rechtmatige instructie was, dan is het ook van de werkgever als je het zonder had gemaakt.

Deze poster werkt aan het ontwikkelen van bepaalde toepassingen, en dat moet handmatig gebeuren. Een generator die je eigen werk versnelt, ligt voor mij zó dicht bij het eigenlijke werk dat ik altijd wel die verbinding zie. Er is dus geen ruimte om te claimen dat zo’n generator auteursrechtelijk (of octrooirechtelijk) van jou is.

Natuurlijk kun je je werkgever vragen of je dit als eigen hobbyproject mag doen. Ik blogde in 2020 over hoe je dat afspreekt, maar de voorvraag is natuurlijk waarom je werkgever dat zou willen toestaan. Van iets dat automatiseert dat nu (kennelijk) 8 jaar handwerk is, kan ik me voorstellen dat de werkgever niet wil dat de concurrent er toegang tot heeft.

Arnoud

 

 

25 reacties

  1. Dat waarom zou natuurlijk kunnen zijn omdat de werkgever geen zin heeft een gok te nemen met die investering. Ik zou als werknemer dan ook niet te veel in detail gaan treden over de mogelijke winsten voor enkel die werkgever…

  2. Ideeën zijn niet beschermd. Wat het auteursrecht betreft geldt dat programmeren moet dan wel tot je werk behoren (art. 7 Aw). Dat de betrokken werknemer de werkzaamheden handmatig uitvoert is onvoldoende (vgl. ECLI:NL:RBAMS:2022:2927, r.o. 4.5 en ECLI:NL:RBAMS:2024:2240, r.o. 4.2). Een werknemer die een schilderij maakt maakt een heel ander werk dan een werknemer die een programma maakt dat een schilderij kan produceren.

    1. In menige arbeidsovereenkomst staat een geheimhoudingsclausule die de specifieke bedrijfskennis moet beschermen. Gebruiken van “bedrijfsgeheimen” buiten (na) je arbeidsovereenkomst kan je in de problemen brengen, zeker als jouw (ex-)werkgever vermoedt dat je de concurrentie een handje helpt.

      Het is mij niet duidelijk waarom in het beroep van de vraagsteller zo’n acht jaar ervaring nodig is om competent te worden; welk deel van de complexiteit veroorzaakt wordt door openbare normen en standaarden en welk deel werkgever-specifiek is. Een optie voor een werknemer met voldoende spaargeld is ontslag nemen en de applicatie als zelfstandig ondernemer te ontwikkelen.

    2. Het “moet tot je werk behoren” komt in de praktijk neer op de vraag “kon je werkgever je hier opdracht toe geven”.

      In deze zaak maakte een docent opgaven en bundelde deze, hoewel ze daar geen opdracht toe had gekregen en het maken van boeken met opgavenbundels niet in haar functie-omschrijving stond. Rechtbank:

      Gelet op de omstandigheden waaronder de Boeken tot stand zijn gekomen is de rechtbank van oordeel dat de werkzaamheden van [eiser] die hebben geleid tot het vervaardigen van de Boeken geacht moeten worden te zijn verricht in het kader van de functie en de dienstbetrekking van [eiser] . Dat zij de werkzaamheden grotendeels in vrije tijd zou hebben verricht, geen instructies van Fontys heeft gekregen en Fontys daar geen kennis van heeft gedragen, doet daar niets aan af. Het samenstelling van de Boeken paste immers binnen de onderwijstaak die [eiser] met een grote mate van zelfstandigheid in kon vullen.

      Ik ben het met je eens dat er wel iets van een binding moet zijn tussen je functie en dat ‘vrijwillige’ werk. Bij het automatiseren van je eigen werk ben ik geneigd dat al snel te zien, zeker als het om tools gaat die voor mensen van jouw functieniveau eenvoudig inzetbaar zijn, zoals Microsoft Excel.

      In ECLI:NL:RBAMS:2022:2927 ging een eindredacteur (“maken, begeleiden en monteren van afleveringen”) zelf nieuwe formats ontwikkelen. Dat had haar niet opgedragen kunnen worden, dus is dat geen deel van haar werk. Dit bevestigt mijn stelling. In ECLI:NL:RBAMS:2024:2240 gaat het niet over de positie van de werknemer ten opzichte van de werkgever.

      1. Het vonnis waar je naar verwijst overtuigd niet. De opdrachten die de werknemer maakte behoorde tot haar taak. Het bundelen niet, maar dat ligt in het verlengde van het maken van de opdrachten en het doel was zodat andere werknemers van de opdrachten gebruik konden maken.

        Programmeren is doorgaans echt een andere tak van sport en daarom niet opgedragen kan worden.

        1. Dat gaat me véél te ver als algemene uitspraak. Als je het kunt, en het past binnen je werkzaamheden, dan kan het je best opgedragen worden. Als ik weet dat jij goed kan fotograferen en ik draag je op foto’s te maken van de afscheidsreceptie van collega Steven, dan zijn die foto’s echt van mij als werkgever.

            1. Terecht punt. Ik zou zeggen dat het wel mag als je het duidelijk als vrijwillige vraag stelt, en de werknemer dus mag weigeren. Het punt was vooral: áls je het doet, dan is het van je werk. Het zou al te raar zijn dat die foto’s ineens privé-eigendom zijn van de werknemer in zo’n situatie.

                1. Nitpicking, maar die laatste ontbreekt als weigeren een optie is. Het is prima mogelijk dat de werkgever de receptie onder werktijd houdt of dat iedereen de tijd van de receptie als werktijd kan boeken. Dan is het dus betaald werk.

                2. Dat is totaal irrelevant voor de vraag die gold. De vraag is: behoort het tot je werk als je werkgever je een tijdelijke eenmalige uitbreiding van je werk voorstelt en jij daarmee instemt? Dit is totaal niet controversieel.

                  Als jij kassamedewerker ben en ik zeg “wil je even helpen de vrachtwagen uit te laden, Wim is ziek”, dan sta jij daar als deel van je werk uit te laden. Ook als in je contract echt alleen over kassawerk gesproken wordt. Krijg je dan een ongeval, dan is dat een werk-kwestie.

                  Als in je contract staat “doet alleen kassa” dan sta je in je recht als je zegt “sorry, uitladen is niet mijn werk”. Maar zeg je “ja prima” dan is dat uitladen deel van je werk geworden.

                  1. De eerste vraag is of partijen het opvatten of moeten opvatten als een uitbreiding van hun werkzaamheden. Ik denk niet dat partijen dat over het algemeen zodanig zullen beschouwen.

                    De werknemer die een keertje helpt de vrachtwagen uit te laden zal dat m.i. niet opvatten als uitbreiding van zijn arbeidscontract, maar wel als werk. De werknemer die op een receptie een foto maakt, zal dat m.i. niet opvatten als werk.

          1. Arnoud

            Bij je voorbeeld stel ik me dan wel de vraag of dit ook het geval is als de betrokkene zijn eigen fotoapparatuur gebruikt, terwijl het bedrijf de apparatuur niet heeft en de werkzaamheden zeer ver van fotografie liggen. Laat staan als de betrokkene ook inkomsten van fotografie heeft buiten het werk. Ik heb het dan niet over enkele kiekjes met een werkgsm.

            1. In principe is het niet relevant wie de eigendom heeft op de hulpmiddelen waarmee jij je werk uitoefent. Of je nou dat rapport op je eigen laptop schrijft of de bedrijfslaptop, dat rapport is je werk en dus auteursrechtelijk van de werkgever.

              Inderdaad kan het onduidelijk worden als iemand die andere activiteit ook naast het werk doet, zoals de accountant die bijverdient als bruidsfotograaf en nu de afscheidsreceptie fotografeert. Of de business solution programmeur die in het weekend een open source library onderhoudt of apps voor Facebookspelletjes maakt. Dit moet je niet laten gebeuren zonder afspraken want daar kom je gewoon niet uit.

            2. Laat staan als de betrokkene ook inkomsten van fotografie heeft buiten het werk

              Dit triggerde mij.

              Ik ken een leraar die parttime werkt als leraar op een school en de rest van de tijd als zzp-er examentraining geeft. Dat laatste verdient veel beter maar is enigzins seizoensarbeid. De school weet daar ook van, want door die trainingen is hij gevraagd te soliciteren.

              Wat als hij een bundel maakt. Ja de school kan hem opdracht geven. Maar voor zijn andere werk is het ook iets passend. Het lijkt mij dat er dan gekeken moet worden in wiens tijd de werkzaamheden worden uitgevoerd. De vraag wie ‘opdracht’ kan geven heeft immers geen eenduidig antwoord.

              1. Klopt, je creëert een enorme onduidelijkheid voor jezelf en je werkgevers. Daar harde scheidslijnen mee afspreken is dan de enige optie. Want ja, ik zie hoe je school dan kan zeggen “die bundel is van ons want dat hadden we je kunnen opdragen”. Dat is dan niet doorslaggevend natuurlijk maar wel de start van een héél lang en duur discussietraject.

          2. De werknemer is geen slaaf van de werkgever. Een arbeidsovereenkomst geeft de werkgever slechts de bevoegdheid om de werknemer op te dragen werk te doen dat past binnen wat partijen overeengekomen zijn. Die docent heeft als taak om inspirerend en interactief onderwijs te verzorgen, leerarrangementen te ontwerpen en onderzoeksopdrachten op te stellen. Het maken van foto’s is geen activiteit die gedekt wordt door de arbeidsovereenkomst. Dat wordt niet anders op het moment deze docent toevallig goed is in het maken van foto’s. Een geschiedenisdocent kan rustig foto’s maken van oude gebouwen zonder te hoeven vrezen dat het auteursrecht op die foto’s bij de werkgever komt te liggen.

  3. Ik vind het toch een beetje een vreemde vraag. Als je iets bedenkt waarmee je werkgever efficiënter wordt, waarom moet daar dan een slaatje uitgeslagen worden? De ene werkdag kost je meer geld dan je oplevert, en de andere maak je iets beter waardoor het bedrijf juist veel kosten kan besparen.

    Ik volg inderdaad de redenering dat als jij een optimalisatie maakt voor wat er op je werk gebeurt je dit onder andere doet op basis van al je ervaringen op dat werk. Dus het is zeker niet totaal onafhankelijk en je eigen verdienste of in splendid isolation bedacht, maar een samenspel van jouw bijdrage en alle inputs die je door je werk hebt opgedaan, omgevingsfactoren en de bijdragen van anderen die daar werken, dus kan daar niet los van gezien worden.

    1. Ik ben niet zo’n type dat om “vijf voor” bij de prikklok staat om precies op tijd uit te kunnen klokken. Als er een urgent probleem is werk ik zonder te klagen over.

      Maar als programmeur weet ik hoeveel tijd het schrijven en testen van een “werkproces ondersteunende applicatie” kost. Dat vergt al snel enkele maanden (full-time). Ik verwacht dat er voor de vraagsteller al snel een halfjaar aan vrije tijd in gaat zitten.

      Bij dat soort investeringen (tijd is geld) voelt het niet terecht dat een werknemer dat maar om niets aan een werkgever zou moeten geven. Een m.i. betere optie is dat de werkgever een “tijdsbudget” ter beschikking stelt waarmee de werknemer (betaald) aan zijn applicatie kan werken.

      1. Wat ik vaak zie, is dat mensen vanuit liefde voor het werk aan zoiets beginnen. Hier en daar een scriptje, een klein stapje tussen A en B automatisch laten gebeuren. Dan wat knutselwerk er achteraan, op een rustige middag het script wat mooier herschrijven, feedback van een collega en daardoor gestimuleerd raken, en twee jaar later heb je zomaar een business critical applicatie.

        Dit is niet uniek bij programmeren overigens. Er zijn docenten te over die in hun vrije tijd hele lesmethoden ontwikkelen, met Raspberry Pi’s computergedreven opdrachten knutselen enzovoorts. En hoe veel mensen schrijven er geen boeken, whitepapers en dergelijke over hun werk in het kader van kennis delen?

        1. In dat geval is vastlegging ook heel belangrijk.

          Ik heb het volgens mij een paar jaar terug bij een verwant onder al eens verteld.

          Ik programmeer al als hoby sinds mijn tienerjaren. Voor mijn eerste werkgever heb ik wel een wat geprogrammeert waarbij ik bibliotheken gebruikt die ik tiujdens mijn midelbare schooltijd opgebouwd heb en daarna bijgehouden. Ik heb ze die code in licentie gegeven (MIT) (en bewijs dat die van voor mijn dienstverband stamde bewaard) Als ik het nu weer zou doen, zou ik eerst een overeenkomst op papier vastleggen. Zodat ook bugfixes en bijwerken van de code nar modernere standaarden niet tot discussies leidt.

  4. Ik ben naast werknemer ook een ZZP’er met een eigen bedrijf. Niet erg aktief, maar het is KvK-geregistreerd en heeft een eigen domeinnaam.

    Ik heb daarnaast op mijn computer twee virtuele schijven aangemaakt. De ene is voor mijn werkgever, met alle werk-gerelateerde projecten. De ander is voor mijn eigen bedrijf en mijn eigen projecten.

    Het verschil tussen beide bedrijven is dat mijn werk vooral op gebied van de financiele dienstverlening is, met daaronder het testen van betaalopties (wereldwijd) die banken aanbieden. Mijn eigen bedrijf is meer voor algemene software met de focus op afbeeldingen en verhalen. Er is niet een groot raakvlak, hoewel ik voor beiden werk met Visual Studio en C#. SQL Server voor op werk, PostgreSQL voor mijzelf.

    Toch ben ik erg voorzichtig met het maken van eigen projecten, waarbij ik verwarring probeer te voorkomen tussen beide bedrijven. Zo maak ik zelf afbeeldingen voor mijn eigen projecten terwijl mijn werkgever de afbeeldingen moet leveren voor werk-projecten. Idem met data en documentatie.

    Maar het blijft wel lastig daar waar prive en werk enige overlap heeft. Maar mijn huidige werkgever heeft er geen problemen mee. Een vorige werkgever, daarentegen, had er wel problemen mee dat ik een stukje broncode in een project had toegevoegd met mijn eigen copyright-tekst. Maar dit was weer van een project dat ik had gemaakt voor ik voor deze werkgever ging werken. (De datum in de tekst gaf dit ook aan.) Dit stukje code bleek handig te zijn voor mijn werk en dus maar even naar mijn werk overgebracht. Uiteindelijk wel het begrip ervoor gekregen, dus snel opgelost.

    (En ik denk dat iemand ondertussen die tekst eruit heeft gehaald, want dat gebeurde sowieso met veel third-party code binnen dat bedrijf…)

    1. (En ik denk dat iemand ondertussen die tekst eruit heeft gehaald, want dat gebeurde sowieso met veel third-party code binnen dat bedrijf…)

      Dit is toch wel heel bijzonder. Bewuste auteursrechteninbreuk (en aanpassingen zijn dat) is een misdrijf waar gevangenisstraf opstaat. Welk management geeft in hemelsnaam rechtstreeks opdracht aan zijn werknemers om een misdrijf te plegen? (We hebben het hier niet over te snel rijden door de werknemer, misschien mede veroorzaakt door een strakke planning door de werkgever, maar actief de opdracht: ‘pleeg maar een misdrijf!’)

  5. Ik ben het natuurlijk helemaal eens met Arnoud wat betreft de rechten van werknemers. In het octrooirecht (ik weet niet of dat in het auteursrecht ook zo is) ligt dat wel anders voor ZZP-ers, dus daar zit misschien nog een ontsnappingsmogelijkheid voor de ‘werknemer’.

    Overigens zie ik niet direct in hoe iemand (werkgever of werknemer) op een dergelijk programma octrooibescherming zou kunnen krijgen. Automatisering van (voorheen handmatig/hoofdmatig uitgevoerde) activiteiten is meestal niet octrooieerbaar (tenzij je een technisch niet voor de hand liggende stap gebruikt, maar die is dan waarschijnlijk weer niet kritisch-afhankelijk van de computerimplementatie van de methode)

    Veel mooie computertoepassingen, die veel werk kosten om te maken en die nuttig zijn voor de mensheid, zijn slecht of niet te beschermen door middel van het octrooirecht (tenminste in Europa. Ik weet onvoldoende van andere jurisdiscties). Terecht of onterecht, daar kunnen we over twisten, maar dat is nu eenmaal de wet.

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.