Github introduceert werknemersvriendelijk IP-contract

Broncodebeheerbedrijf Github staat sinds kort toe dat hun werknemers de rechten (IP) op eigen werk mogen houden als ze die met bedrijfsmiddelen of onder werktijd hebben gemaakt, meldde QZ onlangs. Hiermee wijkt men werknemersvriendelijk af van de standaard in de VS: gebruikelijk daar is dat alle IP toekomt aan de werkgever van alles dat ook maar enigszins gerelateerd is aan het werk, of dat met een bedrijfsmiddel vervaardigd is. Met de Balanced Employee IP Agreement wil men een modeltekst voor andere werkgevers bieden. Zou dat ook in Nederland nodig zijn?

Allereerst meteen even een ergernis uit de weg: nee, IP bestaat niet en intellectueel eigendom ook niet. Die termen verwijzen naar een juridisch rechtsgebied, net zoals arbeidsrecht – maar we spreken niet van aantasting van je arbeidsrechten, we zeggen dat je te weinig vakantiedagen krijgt of dat de proeftijd in strijd met de wet is. Doe dat dus ook niet meer met “IE”: wil men auteursrechten hebben, octrooien of iets anders? (En dit is geen muggeziften, ik zie te veel contracten waarin “het IE” als een autonoom onderwerp wordt behandeld náást auteursrechten.)

Maar goed. Auteursrecht dan maar even. Volgens de wet (artikel 7 Auteurswet) komt, tenzij anders overeengekomen, het auteursrecht toe op wat de werknemer maakt in het kader van het dienstverband. Wij kennen dus geen criteria zoals “het moet onder werktijd zijn gemaakt” of “het moet in directe opdracht zijn gemaakt” of “er moet een werkcomputer zijn gebruikt”. In het weekend op je eigen laptop een ongevraagd rapport met aanbevelingen voor een betere testprocedure typen, maakt dat de werkgever daar het auteursrecht op heeft. Op werkdagen tussen 9 en 12 op de bedrijfscomputer een roman schrijven is waarschijnlijk plichtsverzuim maar de rechten op die roman heb je zelf.

Amerikaansrechtelijke brede claims op alles dat je doet tot 2 jaar na je ontslag, ongeacht tijdstip of middel, zijn dus tegen de wet bij ons. Afgezien van dat “tenzij anders overeengekomen” dan: je mag als werkgever en werknemer anders afspreken. Ik blijf erbij dat dat beide kanten op gaat (sorry Alex), als beiden willen afspreken dat ook privéprojecten werkgeverseigendom worden, dan moet dat contractueel kunnen. (Wel op schrift en met handtekening, in verband met artikel 2 Auteurswet.) Waarom je dat als werknemer zou tekenen is natuurlijk een andere vraag.

Een probleem daarbij is wel dat zo’n afspraak tegen het basale principe van kenbaarheid aanloopt. Een toekomstig auteursrecht afstaan kan namelijk alleen als het betreffende werk op voorhand voldoende kenbaar is. “Ik wil dat je een roman schrijft en ik wil daar de auteursrechten op” voldoet daar waarschijnlijk wel aan. Maar “ieder project dat jij de komende jaren start, wordt van mij” is écht te vaag.

Misschien als je het koppelt aan het werk: “alle projecten die verwant zijn aan producten/diensten die wij leveren, worden van ons”, dat is nog redelijk te toetsen. Alleen: wélke? Die men nu heeft? Of ook in de toekomst? En alleen van de afdeling waar meneer/mevrouw werkt, of het hele bedrijf? Wereldwijd? En hoe definieer je ‘verwant’? Ik denk dat het daar al snel op zal stranden.

Hoe dan ook, die BEIPA van Github lijkt me te Amerikaans specifiek. Als principe vind ik het wel een heel goed idee: laat werkgevers ook eens nadenken over wat creatieve werknemers naast het werk willen doen, en claim niet op voorhand daar de rechten op. Programmeren is niet alleen werk, het is ook gewoon leuk.

Arnoud

4 reacties

  1. De Nederlandse wet is vaag. Ik heb eerder al eens vermeld wat er in mijn contract staat:

    Het auteursrecht op alles wat ik voor mijn werkgever maak ligt bij de werkgever. Ik mag geen nevenactiviteiten hebben in de markt waarin mijn werkgever zich begeeft.

    Nu maakt mijn werkgever software voor een goed gedefinieerde markt. Dus als ik specifiek iets voor die markt maak, dan snap ik dat het voor mijn werkgever is.

    Maar zelfs met deze blogpost kom ik niet uit de volgende situatie: Ik heb software gemaakt die niets te maken heeft met mijn werk en de markt waarop mijn werkgever zich begeeft. Het auteursrecht daarop ligt bij mij. Iets wat mijn werkgever ook beaamt.

    Alleen kon ik laatst een redelijk generiek deel uit mijn eigen software toch gebruiken voor iets op het werk. Ik kon kiezen hergebruiken of opnieuw maken. Met de kans dat opnieuw maken zo erg lijkt op wat ik al had dat het problemen geeft.

    Ik heb een copy paste gedaan van mijn bestaande code en er een BSD licentie ingezet, ik houd niet van het wiel opnieuw uitvinden. Maar het is mij volkomen onduidelijk hoe de situatie nu werkelijk ligt met zulke algemene code, die je in ieder programma hebt. Als die bij je baas komt te liggen omdat je dit als onderdeel van je werk zou kunnen maken is het feitelijk onmogelijk om voor jezelf iets te maken zonder dat de baas daar aanspraak op maakt/kan maken.

    1. Het auteursrecht is qua “wie heeft de rechten” erg rechtlijnig. Of het is van je werk op grond van je contract, of het is van jezelf. De enige vraag is dus of het werk dat je hebt gemaakt, voldoet aan de afspraken uit het contract. Het gaat hier om software die niet voor het werk is gemaakt, dus is die van jou. Jij kiest er als werknemer vervolgens voor om die software op het werk in te zetten. Dat is prima, net zoals je andere thirdpartysoftware mag inzetten op het werk. De eigendom gaat daarmee echter niet over. Aanpassingen die je daarna doet met het oog op integratie e.d. met werksoftware die zijn wél van de werkgever.

  2. Als je vast hebt liggen dat de code niet van de werkgever is mag ik hopen dat dat zo blijft. Dit vastleggen kan op schriftelijke wijze, ik hoop dat een e-mail tussen jou en je werkgever voldoet. Als ik het fout heb is het tijd dat de wet aangepast wordt.

  3. Helemaal eens met vorige posters. Het is gewoon veel te onduidlijk. Ik ben geen programmeur maar wel erg actief in de opensource wereld. Als ik door een arbeidscontract mijn opensource activiteiten zou moeten staken zou ik dat, op zijn zachtst gezegd, problematisch vinden.

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.