Opensourcewerk als nevenactiviteit in het arbeidscontract

| AE 9171 | Arbeidsrecht, Open source | 18 reacties

Een lezer vroeg me:

Ik ga binnenkort als programmeur aan de slag bij een middelgroot bedrijf. Naast mijn werk wil ik aan allerlei open source projecten kunnen blijven werken, maar dat botst met de auteursrechtclausule uit hun contract: alles is automatisch van hen, ook als ik het in eigen tijd maak. Is daar juridisch iets aan te doen?

Het is zeer standaard om in een arbeidscontract binnen de ICT een auteursrechtclausule op te nemen. Als werkgever wil je immers zeker weten dat je de auteursrechten krijgt op wat je personeel maakt. Op zich staat dat al in de wet, maar je mag van die wettelijke regeling afwijken bijvoorbeeld door scherpere en/of bredere grenzen te trekken.

Als potentieel werknemer hoef je zo’n clausule natuurlijk niet te accepteren. Je mag hier vrij over onderhandelen. Natuurlijk loop je wel enig risico dat de werkgever dan geen zin meer in je heeft, maar ik mag hopen dat een werkgever extra enthousiast wordt van een programmeur die ook in zijn vrije tijd bezig is met zijn werk-skills aanscherpen.

Er zijn verschillende manieren om dit te doen. Vrijwel iedere werkgever gaat akkoord met “Ik mag aan nevenactiviteiten programmeren en de auteursrechten worden van mij, mits ik vooraf toestemming vraag”. Dit klinkt mooi, maar de cynische jurist zal meteen opmerken dat dit niets toezegt, want toestemming mag (binnen het redelijke) immers altijd worden geweigerd. Toevoegen “Toestemming mag alleen worden geweigerd als” met een beperkte lijst argumenten is dus wel zo verstandig. Denk aan “als de activiteit concurreert met het werk”, “als het werk gaat lijden onder het nevenwerk” of “als de nevenactiviteit gerund wordt door een concurrent/leverancier”.

Je kunt het ook generieker houden: nevenactiviteiten mogen tenzij ze concurreren of tenzij ze conflicteren met het werk. Dan is toestemming niet meer aan de orde maar moet de werknemer zelf inschatten of er een probleem kan ontstaan. In de praktijk komt het dan toch neer op een soort van toestemming, want bij twijfel gaat de werknemer natuurlijk vragen of iets mag of niet.

Vaak wordt ook gewerkt met een lijst met projecten waar men aan werkt. Dat kan, maar het onderhouden van die lijst is waar het dan vaak mis mee gaat. Maak dus dan in ieder geval een afspraak over hoe vaak die lijst wordt herzien en hoe eenzijdig de werknemer er projecten aan mag toevoegen. Is dat “ik zal nieuwe projecten mailen en ze zijn goedgekeurd tenzij men piept binnen 14 dagen” of “ik mag pas beginnen na schriftelijke goedkeuring van de directie”?

Mijn ervaring is wel dat dit soort clausules vaak discussie geven in het onderhandeltraject, en vervolgens compleet onder het tapijt verdwijnen. Ik vraag me dan ook wel eens af of het wel écht nodig is dit zo uitgebreid te regelen. Maar goed, het is altijd beter dingen vooraf te bespreken dan achteraf er ruzie over te maken.

Wat is bij jullie bedrijf het beleid over buiten het werk om aan open source te werken?

Arnoud

Deel dit artikel

    • Ik doelde op de wettelijke regeling uit artikel 7 Auteurswet:

      Indien de arbeid, in dienst van een ander verricht, bestaat in het vervaardigen van bepaalde werken van letterkunde, wetenschap of kunst, dan wordt, tenzij tusschen partijen anders is overeengekomen, als de maker van die werken aangemerkt degene, in wiens dienst de werken zijn vervaardigd.
      De woorden “tenzij anders overeengekomen” maken duidelijk dat dit regelend recht is en er dus van mag worden afgeweken in het arbeidscontract.

      Overigens, dit artikel is geen wettelijke plicht tot overdracht, het bepaalt wie maker geacht wordt te zijn. De rechten liggen dus ab initio (zoals dat zo mooi heet) bij de werkgever, de werknemer had nimmer rechten op deze werken.

      • Dit artikel gaat over arbeid die bestaat in het vervaardigen van bepaalde werken. Er moet sprake zijn werken die binnen de taakomschrijving vallen en daarnaast moet de werkgever zeggenschap hebben over de vorm waarin het concrete werk tot stand komt. Als daaraan voldaan is kan er van worden afgeweken. Dit artikel geeft de werkgever m.i. niet de vrijheid om van de bepaling af te wijken in de zin dat hij alles claimt wat de werknemer maakt, ongeacht of dit binnen de taakomschrijving van de werknemer valt of dat de werkgever zeggenschap heeft over de vorm waarin het werk tot stand komt. In het voorbeeld van de lezer gaat de werkgever duidelijk te ver.

    • De default is dat het maken van “bepaalde werken” binnen het dienstverband aan de werkgever toekomen. Dit vereist een duidelijke link met het werk en iets waaruit blijkt dat het maken van dat soort werken tot je werk behoort. Bij een programmeur is dus software in principe van de werkgever, als van die software denkbaar is dat de werkgever die zou kunnen opdragen te ontwikkelen. Omdat je hiermee heel snel in grijze gebieden komt (je maakt Office-automatiseringssoftware en in je vrije tijd werk je aan installatie-scripts en tools), zijn maatwerkafspraken wel zo verstandig.

      • Maatwerk lijkt me inderdaad handig. Stel, je werkt als programmeur op kantoor alleen met Office-software en programmeert daar dus voor en dat allemaal op Windows. Maar daarnaast werk je in je vrije tijd aan een vensterbeheerder (WM) voor Linux. Dat is duidelijk totaal iets anders, het zou raar zijn als de werkgever dat dan zou claimen als zijnde van hem want wat heeft de werkgever aan een WM voor Linux als hij alleen Windows gebruikt?

        Maatwerk is dus altijd handig.

  1. Ik breng dit altijd ter sprake nog voordat ik een contract te zien krijg. Het is voor alle werkgevers een groot pluspunt dat je je zozeer interesseert voor je werk dat je ook in je vrije tijd nog aan (veel gebruikte!) software sleutelt. Dat je de auteursrechten op niet-werkgerelateerde software wilt behouden, is dan gemakkelijk te beargumenteren. (Je kunt bijvoorbeeld noemen dat je niet meer mee mag doen zonder auteursrechten, omdat dat strijd oplevert met open source-licenties.)

    Maar ook in de contractfase moet je hier nog iets aan kunnen doen. Leg uit dat je open-source activiteiten heel belangrijk voor je verdere ontwikkeling zijn, en dat een contractaanpassing noodzakelijk is om daarmee door te kunnen gaan. Benadruk dat het enkel gaat om niet-werkgerelateerde software, en dat de werkgever auteursrechten op werkgerelateerde software die je eventueel in je vrije tijd maakt, toch behoudt.

    Mocht de werkgever op dit punt toch weigeren, zou ik zelf eieren voor mijn geld kiezen. Het zet namelijk de toon voor je verdere arbeidsverhouding.

    Ik heb overigens nooit een werkgever gesproken die hier moeilijk over deed.

  2. Bij mijn werkgever is het makkelijk: het beleid is dat ook software die binnen het dienstverband gemaakt wordt open source is (we verkopen geen software, maar reken- en opslagdiensten). Desalnietemin zou ik ook hier afspraken over maken (mag je als een werknemer werken aan closed-source projecten en dit verkopen?)

    In de praktijk ken ik geen werkgever die hier ooit moeilijk over deed. Wel is mijn tip om in de clausule alle auteursrechten mee te nemen, niet alleen software, maar ook bijvoorbeeld boeken.

    • Toch kan het verschil tussen voor je werkgever open source maken en voor jezelf open source maken belangrijk zijn. Het auteursrecht en de aansprakelijkheid zijn in het eerste geval voor je werkgever en in het tweede geval voor jou. Als er dan eens iemand met een claim komt (bv. er is een octrooi geschonden), als je de licentie wilt veranderen, enz., maakt dat uit.

  3. Als klein werkgever heb ik de standaard auteursrecht “Alles is van mij” clausule in het contract opgenomen. Eigenlijk vooral omdat ik het eigenlijk zo logisch vind mensen ook hun eigen projecten moeten kunnen hebben dat het niet in me opgekomen is dat ik daar wat langer over had kunnen nadenken. Werknemers ook nog niet over gehoord.

    Misschien weer een keertje doorlichten, want ik wil wel zorgen dat mijn werknemers zich niet bezwaard hoeven te voelen als ze gaan hobbyen. Maar, ga er in ieder geval geen punt van maken.

  4. In mijn contract staan slechts twee stukjes die hierop van toepassing zijn, samengevat:

    1. Alle auteursrechten als gevolg van werkzaamheden die werknemer voor werkgever verricht liggen bij de werkgever.
    2. Ik mag geen nevenactiviteiten hebben die met mijn werkgever of onze klanten concurreren.

    Mag ik dan concluderen dat als ik buitenwerktijd aan een project werk dat niets met de markt waarin mijn werkgever zich beweegt te maken heeft het auteursrecht bij mij ligt?

        • Ik ben dat ooit nagegaan en bij ons ligt het waarschijnlijk bij mijn werkgever.

          Zelfs als ik niet specifiek de opdracht heb gekregen om die software te maken, als ik in het algemeen software maak voor mijn werk kan dat al genoeg zijn om ook de software die ik in mijn vrije tijd maak van mijn werkgever te maken.

          Overigens heb ik in de praktijk nog nooit een claim van eigendom of auteursrecht van mijn werkgever gezien op enige software die hier gemaakt is. Sterker nog, het komt voor dat zulke software door werknemers in eigen bedrijfjes of -stichtingen wordt ondergebracht en commercieel wordt uitgebaat of verkocht, meestal na verdere doorontwikkeling.

      • Het kerncriterium is hier “niets met de markt waarin mijn werkgever zich beweegt”, niet of het onder werktijd is gemaakt of niet. Het is geen project wat je werkgever binnen alle redelijkheid als ‘werk’ aan zou kunnen merken,

        Werkgevers kunnen niet van je verwachten dat álle mogelijke projecten die buiten je kernwerkzaamheden vallen ineens onder het auteursrecht van de werkgever vallen.

  5. Wij gebruiken veel opensource, dus de algemene regel is dat elke breed bruikbare code ook ge-opensourced wordt.

    Hoe beter de programmeur, hoe groter de kans dat deze bijdraagt aan opensource projecten. Het is dus een afweging. En een beetje hypocriet als je een programmeur aanneemt op basis van Github profiel, maar dan toekomstige opensource uitsluit in contract.

    https://www.joelonsoftware.com/2016/12/09/developers-side-projects/

Laat een reactie achter

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

(verplicht)

Volg de reacties per RSS