Een lezer vroeg me:
Wij zijn een klein softwarebedrijf dat snel wil groeien, dus we hebben recent een aantal mensen aangenomen. Nu blijkt eentje daarvan in zijn vrije tijd aan een opensourceproject te werken. Op zich prima, alleen brengt hij code in dat project die hij voor zijn werk geschreven heeft. Hij zegt dat het standaardcode is en dat we er alleen maar baat bij hebben, maar volgens mij bepaal ik nog altijd wat wij hier open sourcen. Wat kan ik nu doen?
Een werknemer kan inderdaad niet zelfstandig besluiten dat software die eigendom is van de werkgever, onder een opensourcelicentie beschikbaar mag zijn voor derden. Dat is een bedrijfsbeslissing. En als het bedrijf daarin volgens de werknemer de verkeerde beslissing neemt, dan heb je dat als werknemer te accepteren.
Hier is het duidelijk dat de code van de werkgever is, de software is voor het werk geschreven. Maar er zijn genoeg situaties met twijfelgevallen: het is niet letterlijk dezelfde code, maar men schrijft gelijksoortige code in eigen tijd. Of men schrijft volledig eigen code maar wel aan een project dat werkgerelateerd is. Een webbouwer die in zijn vrije tijd PHP modules ontwikkelt bijvoorbeeld. Dan kom je in de discussie of het werk binnen het kader van het dienstverband valt of niet. En dat is geen kwestie van “het was na 17 uur gemaakt” of “ik gebruikte mijn privélaptop”.
Goed, dus de code is van de werkgever. In principe kan deze nu gewoon naar het opensourceproject stappen en eisen dat deze de code verwijdert. Het project gebruikt de code immers zonder toestemming van de rechthebbende, inbreuk op auteursrecht dus.
Of niet? Het project zou kunnen zeggen, wij mochten erop vertrouwen dat deze werknemer gemachtigd was dit te doen. De wet kent namelijk een beschermingsconstructie voor situaties als deze. Als de werkgever de indruk heeft gewekt bij het project dat de werknemer dit mocht, dan zegt 3:61 BW dat het bedrijf gebonden is aan de licentie, ook als in feite de werknemer niet gemachtigd was dat te doen.
Wat kan zo’n indruk nu opwekken? Enkel dat de werknemer het doet, lijkt me niet genoeg. Een verklaring op de site van het bedrijf dat men open source steunt en belangrijk vindt in combinatie met gebruik van het zakelijke mailadres van de werknemer, dat zou ik wel een moeilijke vinden om te weerleggen. Dat het bedrijf het opensourcepakket (met werknemersbijdragen) zelf in producten stopt, lijkt me ook wel een overtuigend verhaal.
Los daarvan kun je je afvragen of je echt een discussie moet starten bij het opensourceproject. Dat gaat een hoop gedoe en negatieve PR opleveren. Is dat je code echt waard?
Arnoud<br/> PS meer weten over open source? Volg ons webinar open source de 28e.
Maar moet je als bedrijf nu niet je hele project open source maken omdat je nu een deel van de open source code gebruikt?
Daarvan is hier geen sprake. Men gebruikt hooguit de zelf geschreven code van die medewerker, maar geen opensourcecode van derden. Die medewerker kan geen opensourcelicentie aan werk-resultaten hangen, daar beslist hij niet over. Bovendien mag de rechthebbende op de code altijd de code gebruiken zoals hij wil, ongeacht de licentie die hij erop plakt.
Maar nietsdoen betekent in dit geval mogelijk een soort erkenning van een auteursrecht claim van het opensource project?
Door de code op te nemen in een project dat een open source-licentie heeft, heeft de medewerker dat toch al gedaan, of hij dat kon of niet?
Hij mocht het formeel niet, maar mogelijk kan het opensourceproject claimen dat zij erop mochten vertrouwen dat hij het wel mocht.
Maar zelfs als de code als open source is vrijgegeven, mag de rechthebbende er nog steeds mee doen wat hij wil. Open source is geen generiek kenmerk van de code maar eerder een juridische fork van de code. Ik kan jou een kopie geven onder open source en Wim ten Brink kan een kopie krijgen onder een zelfgemaakte licentie. Wim heeft dan niets te maken met de opensourcelicentie, net zo min als jij iets te maken hebt met Wims licentie.
Interessante case. Ik ben er niet van overtuigd dat mogelijke negatieve PR een argument is om geen actie te ondernemen. Als je duidelijk en proactief communiceert waarom je juridische stappen onderneemt en zorgt dat je verhaal via de juiste kanalen bij het juiste publiek terechtkomt, kan dat positieve publiciteit opleveren. Ik ken de details van deze case uiteraard niet, maar in algemene zin vind ik dat bedrijven zich vaak ten onrechte uit angst voor negatieve publiciteit juridisch laten ‘gijzelen’.
Dit geldt dus ook voor tekstuele bijdragen? ( Bv.: je zoekt iets op op Wikipedia dat je nodig hebt voor je werk, en voert daarin een verbetering door.) Lijkt me lastig toe te passen.
Als het je werk is om dergelijke teksten te produceren, of als je een specifieke opdracht had om dergelijke teksten te maken, dan mag je die teksten niet in Wikipedia plakken want jij kunt ze niet Creative-commonsen. Bij een spelfout corrigeren zal niemand er wakker van liggen, maar plak je de handleiding van het nieuwe product integraal als lemma in Wikipedia dan kan ik me voorstellen dat je daar gedoe van krijgt.
|Het is het beste om het open source project te informeren dat een werknemer code heeft gepubliceerd die eigendom is van de het bedrijf zonder toestemming. Daarbij aangeven dat het bedrijf geen licentie geeft voor die code en dat het bedrijf zich dus ook het recht voorbehoudt om gebruikers van de OSS software die inbreuk op hun auteursrecht maakt te vervolgen. Het OSS project zal dan vermoedelijk zelf overgaan tot verwijderen van de code die door de betreffende gwgebruiker is toegevoegd omdat ze willen dat de licentie die zij verstrekken dekkend is en niet een waardeloze kreet.
Geen verdere discussie aangaan met OSS community bij het project.. Dat is een zinloze actie en als je iemand op de tenen trapt heb je zo een hackaanval of een DDoS voor je kiezen
Dan ken je de wraak niet van de OSS gemeenschap. Een groot deel zal zich inderdaad netjes gedragen maar er zullen er genoeg zijn die met protest-acties zullen komen en de code zullen blijven verspreiden. Onder een andere naam en mogelijk met wat kleine aanpassingen maar je krijgt het niet meer van het Internet. En dan zullen er nog enkele hackers zijn die proberen je bedrijfs-site te hacken en een aantal anderen die je goede naam zullen besmeuren in diverse media. En ze allemaal vervolgen is een optie, maar dan ben je als bedrijf alleen nog maar aan het procederen…
Het bedrijf hoeft ook niet vragen om de code te verwijderen. Dat moeten ze aan het project overlaten. Het bedrijf moet gewoon aangeven dat iedereen het product gebruikt met de code erin van die programmeur inbreuk kan maken maken en dat je als bedrijf dus de mogelijkheid voorbehoudt om afnemers van die open source programmateur wegens inbreuk te vervolgen. De OSS community wil juist schone programmatuur waar niemand anders rechten op kan claimen omdat anders hun ‘vrije’ licentie niet veel meer dan een prul is. Je kan het meestal dus wel aan hen overlaten om de besmette code van die programmeur zelf te verwijderen
Het hangt deels af van de manier en de site waar de code als open-source is vrijgegeven. De OSS community wil inderdaad schone code maar er zijn genoeg gerelateerde communities die zich daar minder druk om maken. Die schamen zich er niet voor om de code te kopieren, wat kleine aanpassingen te maken en dan de code opnieuw als open-source op de markt te brengen. Immers, wie code op het Net vrijgeeft krijgt kudos van andere internetters en daar gaat het sommigen gewoon om. Je ziet het ook met ander auteursrechtelijk beschermd werk. Een stukje code, een mooie foto, een leuk CGI plaatje… Je publiceert het en een ander gaat ermee aan de haal na enkele kleine aanpassingen aan te brengen. Desnoods door de EXIF informatie aan te passen of de variabelen in de code te hernoemen. En dan is het best lastig om aan te tonen dat jij zelf de auteur bent. En dan zijn er ook nog die personen en bedrijfjes die open-source gebruiken in hun commerciele producten zonder de licentie te respecteren en zelfs de code onder eigen naam door te verkopen. Dat gebeurt zelden, maar het gebeurt toch. Met een goed product is het namelijk snel verdiend geld. Zeker in bepaalde landen waar toegang tot open-source bronnen enigszins beperkt is of men sowieso weinig om auteursrechten geeft. (Denk aan China.)
Dit lijkt wel een beetje op die rechtszaak van RealNetworks over Real Alternative.
RealNetworks beweerde daarin dat Real Alternative inbreuk op hun auteursrecht zou maken, terwijl RealNetworks zelf met Helix veel met open source doet en de indruk wekt dat je hun componenten mag gebruiken.
Doordat overal – ook op de gerenommeerde software sites waarvan je zorgvuldigheid mag verwachten – staat dat Real Alternative een legaal freeware programma is, mocht je volgens de rechtbank Den Haag ervan uitgaan dat dit juist is:
Maar vergis je niet! Real Alternative was een freeware programma dat gebouwd was om speciale DLLs van RealNetworks. En die DLL libraries waren absoluut niet gratis! RA ging daarmee dus de fout in door deze mee te distributeren. Maar dat konden de meeste mensen niet weten totdat RN erover ging klagen. Het verzoek van RN om deze freeware offline te halen wegens misbruik van de auteursrechten moet dus wel gehonoreerd worden. Freeware is nog geen open-source. De code van RA was niet vrijgegeven en dus is het lastig te bepalen of er daadwerkelijk geen enkele auteursrechten waren geschonden. Maar als je bij ieder freeware product eerst een aluminium hoedje op moet zetten omdat deze auteursrechten kan schenden omdat je de code niet kunt controleren? Giechel…
Inmiddels heeft een onderzoek van de PC van Edskens uitgewezen dat hij ook zelf de uploader was van die bestanden naar freenet en dus van zijn eigen servers verwees naar ‘publieke’ bestanden die hij ook zelf verspreid had. (wat ook iedereen al wel kon raden omdat hij telkens de eerst was die links naar die bestanden publiceerde)
Ik volg deze zaak al jaren en wat jij schrijft is allebei niet waar, hij was niet de eerste die links naar die bestanden publiceerde en freenet.de heeft verklaard dat ze hun eigen servers uitsluitend zelf beheren:
“Only employees of our editorial staff at freenet.de can upload files to our ftp Servers and add listings to our download catalogue at download.freenet.de.”
Dit nog daargelaten dat het hem niet duidelijk behoefde te zijn dat het bewuste materiaal wellicht inbreukmakend zou zijn.
Ik vraag me af of de programmeur voordat hij/zij in dienst trad al bij het open source project actief was, ook welke afspraken er gecommuniceerd zijn met de programmeur. Ik kan me prima vinden in “bijdragen aan een open source project alleen na toestemming van het management”, maar dat moet dan wel helder gecommuniceerd worden aan alle betrokkenen. En er moeten afspraken gemaakt worden met hoe mensen die buiten hun reguliere werkzaamheden om bijdragen aan open source projecten. Leg vast wat van de werknemer en wat van de werkgever is/wordt.
In het voorliggende geval lijkt me een bestraffing voor de werknemer (schriftelijke waarschuwing) op zijn plaats. Ik zou een email naar het project sturen (houd het vriendelijk, want hen valt niet veel te verwijten) waarin je vertelt dat de werknemer niet gemachtigd was om de code aan project te doneren en het project verzoekt om betreffende code uit hun product te verwijderen, (Geef duidelijk aan om welke regels code het gaat.) Natuurlijk is het goed om betreffende email door een jurist te laten lezen voor je hem verstuurt.
Het is beter om de naam aan te geven waaronder de betreffende programmauer zaken heeft ingechecked en vanaf wanneer zijn werken onder het auteursrecht van de werkgever zou kunnen vallen. In feite zijn namelijk alle bijdragen van die programmeur ’tainted’. Als een bedrijf bijvoorbeeld expliciet aangeeft welke regels code ze verwijderd wilt hebben zou je mogelijk voor andere bijgedragen code waar zo ook rechten op hebben implciete toestemming verlenen wat je als bedrijf juist niet wilt.
Jij gaat er vanuit dat de programmeur “committer” rechten heeft bij het project, dat hoeft niet. Het is ook niet zeker dat het project met een publieke repository werkt. Je kunt altijd vragen of het project mee wil werken aan een onderzoek naar de omvang van de onrechtmatige donatie, in ruil voor een beperkte licentie op de software. Als je als bedrijf helemaal niet reageert mag het open source project aannemen dat je programmeur de donatie rechtmatig gedaan heeft; je bent met je email toch al bezig “schade” te herstellen. En je kunt aangeven dat het onderzoek nog niet compleet is en dat er mogelijk nog meer uit rolt. Het hangt er ook vanaf hoe je (als bedrijf) dat specifieke project ziet: als concurrent of als iets dat aan je eigen (geplande) product iets toevoegt. En van de reactie van het project…
Sowieso denk ik dat iemand die in zijn vrije tijd ook programmeert gewoon zijn eigen versiebeheer-systeem moet gebruiken voor privezaken. Dit soort tools zijn al lange tijd gewoon gratis beschikbaar en veelal goed geimplementeerd. Je kunt daarmee aantonen wanneer je prive-code hebt ingechecked en dus of je dit binnen of buiten werktijd hebt gedaan. Daarnaast zal dit ervoor zorgen dat je prive en zakelijk beter gescheiden houdt. Het is misschien niet altijd voldoende om als programmeur de rechten te behouden, maar het geeft wel aan dat je deze code bewust voor jezelf hebt geschreven en niet voor de werkgever. Het wordt pas spannend als je daarna je eigen versiesysteem gaat kruisbestuiven met die van je werkgever. Dat moet je nooit doen omdat dan de zaak vertroebelt. Privecode voor werk gebruiken kan alleen maar als je met je werkgever daar afspraken over maakt met betrekking tot de licentie.
Zelf, als programmeur, heb ik altijd in mijn vrije tijd aan code gewerkt maar hield daarbij altijd rekening mee dat mijn hobby-projecten een totaal ander doel moesten hebben dan mijn werk-projecten. Maar dat neemt niet weg dat je ook dan af en toe kruisbestuivingen kunt krijgen. In het verleden heb ik wel eens een stukje open-source code geschreven om in Delphi/Pascal heel efficient gebruik te kunnen maken van tekstbestanden en dan vooral het schrijven ernaar. De kracht daarbij was dat je gewoon de standaard Write/WriteLn commando’s kon gebruiken, maar de tekst dan b.v. met een timestamp in een logbestand kwam, of werd opgesplitst naar een tekstveld op het scherm en een bestand. Of zelfs dat je bij het sluiten van het tekstbestand de boel automatisch werd verstuurd naar een bepaald email adres. Heel handig, en in prive-tijd gemaakt voordat ik bij mijn werkgever terecht kwam die het uiteindelijk ook best handig vond om te gebruiken. En dan moet je als programmeur goed opletten. Je moet dan afspraken maken over hoe je werkgever jouw code mag gebruiken. Ik gaf mijn werkgever gewoon een licentie en aanpassingen die tijdens werktijd werden gemaakt kwamen niet in mijn open-source code terecht. Andersom wel, want het is immers open-source en ik had mijn werkgever er een licentie voor gegeven. Toch blijf ik enorm voorzichtig met het schrijven van code in prive-tijd omdat ik niet wil dat werkgevers er een claim op kunnen leggen. Sowieso ben ik thuis ook steeds minder bezig met programmeren en meer met het maken van CGI plaatjes, en code die ik schrijf hebben daar meestal betrekking op. Mijn werkgever doet niets met CGI, dus is dat geen eigendom van de werkgever.
Wel maak ik tegenwoordig voor privezaken gebruik van TFS, het versiebeheer systeem van Microsoft. Hiermee kan ik exact aantonen wanneer ik een bepaalde versie van code heb ingecheckt en dat dit buiten werktijd gebeurt. Daarmee is prive-werk apart van mijn werk-projecten. Het bemoeilijkt ook kruisbestuivingen omdat ik dan aktief code van het ene versiesysteem naar het andere moet verplaatsen. Of het dan nog binnen het kader van het dienstverband valt vind ik lastig te beoordelen omdat de betreffende server niet binnen dienstverband valt, en ik de server al langer heb dan het dienstverband.
Overigens is sommige code zeker de moeite van het beschermen waard. Vooral in de financiele wereld zijn er veel complexe berekeningen die zo efficient mogelijk uitgevoerd moeten worden. Een Monte Carlo methode is bijvoorbeeld vrij complex maar worden b.v. gebruikt om te schatten wat iemands vermogen is na 5 jaar, 10 jaar en 20 jaar. Deze methode wordt gebruikt omdat bepaalde variabelen zoals rente en inflatie niet altijd goed zijn in te schatten dus dan maar heel veel berekeningen met relatief random waardes om te kunnen bepalen wat ongeveer de ondergrens en bovengrens kan zijn waartussen je vermogen dan zijn eindwaarde heeft. En dit zijn absurd veel berekeningen die zo efficient mogelijk uitgevoerd moeten worden. Zeer waardevol, dus…
En dat is dus niet zo. Als jouw werkgever je had kunnen vragen om die code te schrijven, dan heeft jouw werkgever het auteursrecht op die code. Ook al heb je het om drie uur ’s nachts geschreven.
http://blog.iusmentis.com/2008/03/08/in-eigen-tijd-gemaakte-software-kan-toch-van-uw-baas-zijn/
Maar het gaat uiteindelijk om civiele rechtzaken, waarin beide partijen met goede argumenten moeten aankomen die aangeven waarom de betreffende partij de eigenaar van de code is. Dat de werkgever het toelaat dat ik prive-code alleen in een prive-server opsla, dat is best vreemd. Dat geeft in ieder geval aan dat ik het werk niet voor mijn werkgever heb uitgevoerd, maar voor mijzelf. Dat is niet een opdracht die een werkgever zal geven. Het wordt anders indien ik mijn code ook in het CVS-systeem van mijn werkgever plaats. Dan wordt het van mijn werkgever, tenzij er afspraken over zijn gemaakt. En in die andere post ging het ook om code die de werknemer had geplaatst tussen het werk van zijn werkgever. Die kruisbestuiving mag gewoon niet gebeuren. Ik werk vooral aan software voor de financiele wereld. Als ik dus een programma schrijf dat een hypotheek berekent dan is dat een heel sterk raakvlak met mijn dagelijkse werk, en dus zal mijn werkgever dat snel, met succes kunnen claimen. Als ik een boekhoudpakket maak om mijn bitcoin-inkomsten en uitgaven mee bij te houden dan wordt het al een stuk lastiger voor mijn werkgever. Ja, het is een boekhoudpakket dus er kan een claim komen. Maar mijn werkgever werkt niet met bitcoins dus dit komt al in een grijs gebied. En als ik thuis werk aan een cheat-applicatie om een hogere score te behalen in World of Warcraft dan kan ik mij niet voorstellen dat mijn werkgever daar een claim op wil leggen. Dat komt niet door de giecheltest heen… En thuis ben ik met van alles en nog wat bezig, maar de focus ligt vooral op zaken die mijn werkgever niet aan mij zal vragen. Doet hij dat toch een keer dan kan ik aantonen dat ik er al mee bezig was voordat de werkgever dit uiteindelijk aan mij vroeg. (En mogelijk voordat ik bij de werkgever begon te werken.)
Als de korte samenvatting van jouw betoog is dat het van een hoop kan afhangen, maar dat het tijdstip van produceren volledig irrelevant is, dan zijn we het helemaal eens 🙂
Het tijdstip is volgens mij ook enigszins van belang. Code die je schreef voordat je bij de werkgever ging werken is namelijk ook jouw eigendom. Idem voor code die je schrijft nadat je bij de werkgever bent vertrokken. Blijft over de code die je schrijft gedurende de dag dat je bent aangenomen en de dag dat je weer bent vertrokken. Dan is het een vrij zwak argument maar als de werkgever niet kan aantonen dat hij voor het betreffende werk aan jou een opdracht zou geven, dan kun je er makkelijker mee wegkomen als het buiten werktijd is gemaakt dan wanneer het gedurende werktijd is gemaakt. De update van 11/11/2013 geeft al een mooi voorbeeld hiervan. Daar heeft hij in zijn diensttijd toch te weinig aan aangepast zodat de werkgever er geen claim op heeft. En ja, met het log van alle check-ins kun je aantonen dat je daadwerkelijk weinig hebt aangepast tijdens werk. (Of zelfs erbuiten.)
Wim, je had het in je eerste post over het tijdstip als in “om 7 uur ’s avonds en ik werk maar tot 5 uur ’s middags”, niet over de datum als in “op 29 augustus en ik werk er pas sinds 1 september”
Klopt, maar ook dat kan meetellen. Als het onduidelijk is of de werkgever opdracht had kunnen geven tot het maken van bepaalde code, dan komen er andere factoren bij kijken. Gedurende de werk-uren behoor ik voor de baas te werken en code geschreven tijdens die uren zou dan vrijwel automatisch aan de werkgever toe kunnen behoren, ook al heeft het weinig met werk te maken. Buiten de werk-uren is in principe prive en dan weegt het argument sterker dat ik het voor eigen gebruik heb ontwikkeld. Weegt misschien nog niet genoeg, maar wel iets zwaarder. Dat is van geen belang als duidelijk is als de werkgever hier opdracht toe had kunnen geven. En het is ook onbelangrijk als de werkgever er nooit een opdracht toe zou geven. Maar dus wel als dit een duidelijk twijfelgeval is. Ik gaf al een bitcoin-boekhoudprogramma als voorbeeld. Als je werkt binnen de financiele dienstverlening dan is het echt twijfelachtig of je werkgever daar opdracht toe zou geven, tenzij hij ook aktief bezig is met bitcoins. Zoniet, dan is het redelijk prive, tenzij je gewoon tijdens kantoor-uren eraan hebt geknutseld. Je zit dan in een grijs gebied waar je met goede argumenten moet komen om de rechter in jouw voordeel te doen beslissen. In de praktijk zal het niet snel voorkomen omdat de meeste werkgevers wel zullen beseffen dat ze weinig nut hebben aan dergelijke code. Het kan dan gezien worden als werknemertje-pesten en schadeclaims opleveren.
Zou een mededeling op je website dat je “open source steunt” echt voldoende zijn om de schijn van volmachtverlening aan een werknemer voor het sluiten van een licentieovereenkomst toe te rekenen aan de werkgever? Het lijkt me toch om het de werkgever toe te rekenen er in ieder geval de indruk gewekt moet worden dat er volmacht was voor deze concrete licentieovereenkomst. (Bijvoorbeeld als blijkt dat de directeur van het bedrijf op de hoogte was dat een bepaalde library in een opensourceproject was gestopt, maar geen actie ondernam of iets dergelijks).
Als je door het uiten van sympathie jegens open source het risico loopt dat een werknemer opeens alle beschermde werken van je bedrijf kan creative-commonsen zou ik als bedrijf toch nog wel 3 keer nadenken of ik die sympathie zou uiten…
Als je open-source steunt dan betekent dat vaak dat je open-source gebruikt en daar wijzigingen aan maakt. Veel OS-licenties bepalen dan dat deze code weer moet worden vrijgegeven, wat betekent dat de werkgever aan die verplichting voldoet. Buitenstaanders weten namelijk niet wat nou precies OS is en wat gesloten code is van hetgeen het bedrijf produceert. Een bedrijf dat dus werkt met Linux, NGinx, MySQL en PHP plus een open-source CRM pakket (zoals Arnoud met dit blog!) die maakt dus gebruik van een open-source licentie waarbij het waarschijnlijk is dat ze, volgens de licentie, weer delen van moeten vrijgeven indien ze het resultaat weer aan anderen geven. (Arnoud komt er redelijk mee weg omdat hij alles voor zichzelf gebruikt. GPLv2 staat dit toe.) Als een medewerker van Arnoud de code van dit blog zou delen dan is het best lastig voor Arnoud om aan te tonen dat dit niet mocht. Arnoud heeft namelijk niet alle auteursrechten maar alleen op de wijzigingen die hij heeft aangebracht. Het zou een complexe kwestie kunnen worden.
Rien, de wet gaat er van uit dat overeenkomsten die een werknemer namens zijn werkgever sluit de werkgever binden. KPN hoort toezeggingen die iemand van het KPN callcenter doet na te komen. Als de medewerker niet gemachtigd was om een dergelijke toezegging te doen of overeenkomst te sluiten dan is dat een probleem tussen werkgever en werknemer. Je mag er als derde in principe van uit gaan dat de werknemer namens zijn werkgever spreekt. Dat wordt anders als je kennis krijgt van informatie die op het tegendeel wijst. Een berichtje van (de advocaat van) de werkgever is wat dat betreft relevante informatie. Veel open source licenties kunnen ingetrokken worden, dat is voor de werkgever de makkelijkste (juridische) weg om de verspreiding van de werken te stoppen. De jurist kan ook op “redelijkheid en billijkheid” gaan hameren. (Schadevergoeding door het open source project zit er niet in, daarvoor moet je bij je werknemer zijn.)
De simpele mededeling “dat werkgever open source steunt” heeft pas invloed wanneer een rechter “redelijkheid en billijkheid” gaat overwegen. Je kunt wel gehouden worden aan concrete toezeggingen als “wij brengen onze code uit als open source.”
Niet per se. Als het project mocht afgaan op gewekt vertrouwen, dan kan het bedrijf juist niet alsnog de licentie ongedaan maken. Ze hébben dan de licentie verleend – daar mocht het project immers op vertrouwen. Als de KPN callcentermeneer zegt “U bent per direct van uw abonnement af meneer” dan kan KPN dat op geen enkele wijze meer herroepen.
Eens, tot er andere informatie binnenkomt, mag je vertrouwen op de gedane toezeggingen; je moet de latere informatie wel meenemen in de beslissingen die je neemt nadat je er kennis van hebt genomen. (Bijdragen van de “gulle gever” extra kritisch bekijken is een verstandige beslissing.) En de werkgever kan schadeplichtig worden tegenover het open source project als zij zomaar de licentie intrekt. Een reden te meer om in overleg te treden met het open source project.
Ik weet niet zeker of we dezelfde stelling bespreken. Gewekt vertrouwen gaat over de vraag of de werkgever/achterman een toezegging mag worden aangerekend. Als de KPN callcentermeneer zegt “U bent per direct van uw abonnement af meneer” dan kan KPN dat op geen enkele wijze meer herroepen. Ook niet achteraf als ze hun bedrijfshandboeken of zelfs de statuten van de BV laten zien waarin staat dat callcentermedewerkers dat nooit mogen zeggen en dat de algemene voorwaarden compleet anders zijn. De toezegging is gedaan, er is gewekt vertrouwen dus het bedrijf hangt eraan vast en heeft die licentie zélf verleend (volgens de juridische fictie).
Natuurlijk moet je voor toekomstige bijdragen van de werknemer dubbel kritisch zijn. Maar als ten tijde van een bijdrage er redelijk gewekt vertrouwen is dat de werkgever het goed vond, dan hangt de werkgever. Bewijzen van dat vertrouwen (en van wat de werknemer eventueel gezegd/gedaan heeft) zal niet meevallen.
Of de werkgever de licentie in kan trekken, is een andere vraag. Wel een goeie. Opensourcelicenties zijn volgens hun teksten niet intrekbaar. Zie bv de GPLv3 artikel 2: “All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met.”
Het lijkt me dus dat áls een werknemer code onder GPL uitgeeft én de werkgever de redelijke indruk wekte dat zij dit goed vond, de code in kwestie voor altijd onder GPL beschikbaar kan blijven.
@Mathfox Volgens mij is de stelling dat de wet er vanuit gaat dat “overeenkomsten die een werknemer namens zijn werkgever sluit de werkgever binden” veel en veel te kort door de bocht. De wet is ook andersom geformuleerd: Er is alleen een volmacht als die is verleend (stilzwijgend of uitdrukkelijk).
Als een werknemer waaraan geen volmacht is verleend nu toch namens de werkgever overeenkomsten aangaat, is de werkgever in beginsel juist niet gebonden. Dit is alleen anders als de werkgever iets heeft gedaan waardoor een derde redelijkerwijs mocht aannemen dat die volmacht wel bestond (art. 3:61(2) BW). Alleen in die situatie is de werkgever wel gebonden. Dat “iets gedaan” hoeft niet veel te zijn, maar alleen het feit dat iemand werknemer is, is niet voldoende.
Als je als KPN een werknemer neerzet in een callcenter, dan zal KPN zonder twijfel gebonden zijn aan overeenkomsten die die werknemer sluit betreffende mobiele abbonnementen van klanten, ook als KPN expliciet met de werknemer is overeengekomen dat er bijvoorbeeld voor bepaalde overeenkomsten toestemming nodig is van de supervisor oid. Dit is niet omdat de persoon aan de telefoon werknemer van KPN is, maar omdat KPN door die persoon aan de telefoon te zetten de indruk heeft gewekt dat er een volmacht was en dat het in het maatschappelijk verkeer normaal is dat callcentermedewerkers dergelijke overeenkomsten namens hun werkgevers aangaan.
Maar wat nu als diezelfde werknemer namens KPN telefonisch een koopovereenkomst voor een nieuw bedrijfspand of een nieuwe bedrijfsauto aangaat? Of 10 gratis iphones belooft als je je abbonnement 1 maand verlengt? In dergelijke gevallen is er heus meer nodig om als derde partij een beroep te doen op art. 3:61(2).
Terug naar de casus: Het enkele feit dat iemand werknemer is bij een softwarebouwer is – lijkt me – te weinig om redelijk vertrouwen bij een derde te wekken dat die werknemer een volmacht heeft om licentieovereenkomsten te sluiten namens de werkgever. Mijn vraag was dus ook of het op de website vermelden dat het bedrijf “open source steunt” al een voldoende gedraging van de werkgever is om dat redelijke vertrouwen wel te wekken. Mij lijkt dat een bezwaarlijk lage lat, temeer omdat dergelijke licentieovereenkomsten voor veel softwarebedrijven een flink deel van hun inkomsten zijn.
Voor mij is “namens de werkgever sluiten” synoniem voor “de rechtshandeling heeft een redelijkerwijs gewekt vertrouwen van vertegenwoordiging”. Ik snap je nuance, het kan dat je iets sluit uit naam van een achterman die vervolgens niet gebonden is omdat dat vertrouwen er niet is. Maar het ging mij hier jusit om de situatie dát hij gebonden is.
Ik geef toe dat het enkele feit dat men “open source is geweldig!” op de site heeft, niet genoeg is om vertrouwen aan te mogen nemen. Maar als meneer met regelmaat óók nog eens vanaf een zakelijk adres dingen bijdraagt, dan wordt het toch lastiger. Dan doet hij zich voor als geautoriseerd werknemer, en waarom deed de werkgever daar nooit iets tegen?
Het lijkt me dat een formele brief met een aanbod op briefpapier van de zaak al snel redelijk vertrouwen draagt. En eerlijk gezegd zie ik niet waarom dat met een zakelijke mail anders zou moeten zijn. Natuurlijk, een mail is zo gestuurd en voor papier moet je een secretaresse zoeken of de voorraadkast in duiken. Maar als ik als wederpartij géén vertrouwen mag verwachten bij een gemailde offerte(-aanvraag) dan wordt het handelsverkeer toch een beetje onhandig.
Zo simpel is het meestal niet.
Bij veel open source-projecten staat wel vermeld welke licentie er wordt gebruikt, maar niet door wie. Soms is er helemaal geen specifieke rechtspersoon die de software beschikbaar stelt – in dat geval zijn het blijkbaar de individuele bijdragers die dat ieder voor zich doen, mogelijk namens een organisatie waarvoor ze werken. In het besproken geval is er wel degelijk een, namelijk de werkgever, maar het zit er dik in dat dat nooit is vermeld, en dat dat bovendien niet voor alle bijdragen aan de software geldt (bijvoorbeeld doordat ze door een derde zijn bijgedragen of doordat ze uit andere projecten zijn overgenomen).
Ik denk dus dat het heel vaak voorkomt dat de rechtshandeling (van het onder specifieke voorwaarden beschikbaar stellen van de software) een redelijkerwijs gewekt vertrouwen van vertegenwoordiging heeft, zonder dat het ook maar enigszins duidelijk is wat de rol van een eventuele werkgever daarbij is, en dus zonder dat je er van uit kunt gaan dat het namens of door een bepaalde werkgever gebeurt.
Als de werknemer zonder toestemming of medeweten van de werkgever op officieel briefpapier cq. zakelijke e-mail een licentieovereenkomst sluit inhoudende een GPL of creative-commons-achtige, is de werkgever dan werkelijk automatisch gebonden?
Overeenkomstenrecht is even geleden, maar in bijna al dit soort zaken was er toch sprake van dat de werkgever alleen gebonden is als ze zelf een situatie in het leven hebben geroepen die de ander geen aanleiding geeft tot onderzoek naar de aanwezigheid van een volmacht, en, meer recent, als die situatie ontstaan is door feiten en omstandigheden die voor risico van de pseudovertegenwoordigde komen (ING/Bera).
Alles bij mekaar – hij is werknemer, het staat op bedrijfspapier, het bedrijf vindt opensource geweldig – is misschien wel genoeg om geen onderzoeksplicht bij de wederpartij neer te leggen. Aan de andere kant, een dergelijke overeenkomst gooit de code wel irreversibel in het publieke domein; geld verdienen met het uitsluitende recht op de code is dan opeens uitgesloten. Dat is voor een softwarebedrijf toch best een vergaande stap. Zou hieruit dan niet toch wel weer een beetje onderzoeksplicht voortvloeien?
(Zou een programmeur van Microsoft de hele windows-sourcecode kunnen creative-commonsen dmv een paar emails vanaf zijn Microsoft-adres? hmmm…)
Ik denk dat we het redelijk eens zijn:
Veel Open Source projecten communiceren via email… dan is het makkelijk om te achterhalen wat er door wie gezegd is. Wanneer er “redelijk gewekt vertrouwen” bestaat is iets waarvoor alle feiten (en gewekte indrukken) gewogen moeten worden. Voor een tweeregelige bugfix zal de lat lager liggen dan wanneer iemand de “kroonjuwelen” van zijn werkgever openbaar maakt.