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

Mag je licentie-incompatibele dependencies meeleveren met je software?

| AE 9144 | Open source, Software | 34 reacties

Een lezer vroeg me:

Bij veel opensourcepakketten heb je allerlei extra software nodig, zogeheten dependencies. Soms is deze extra software meegeleverd met het pakket, maar vaak niet. Je moet dan maar hopen dat het via de repository van je Linux-distributie beschikbaar is. Ik had vernomen dat dat soms een juridische keuze is, hoe zit dat?

Het lijkt zo logisch om, als je eigen software afhankelijk is van andermans open source, die open source mee te leveren. Het is immers gewoon toegestaan om open source software te verspreiden, dat is het hele punt van open source. Het doet dus wat raar aan dat je bepaalde open source niet mee mag leveren.

De reden dat het soms toch niet kan, zit hem in de licentievoorwaarden. Sommige opensourcelicenties (met name de GNU GPL) eisen dat zogeheten afgeleide werken alleen mogen worden gedistribueerd onder die licentie. Als de licentie van het andere werk dit niet toestaat – zogeheten licentie-incompatibiliteit – dan is het dus niet mogelijk die twee samen te verspreiden.

Wat precies een afgeleid werk is, is al decennia een lange discussie, maar goed verdedigbaar is dat gebruik van een dependency daaronder valt. Heb je een specifiek ander stuk software nodig, dan bouw je voort op dat andere stuk software en dus ben je daar een afgeleide van. Hoewel ook goed verdedigbaar is dat je dan alleen functionaliteit aanroept, en dat valt buiten het auteursrecht en dus ook buiten de licentiescope. Maar als je dus zegt dat inroepen van dependencies jouw software een afgeleid werk daarvan maakt, dan moeten de licenties van de software en de dependencies allemaal compatibel met elkaar zijn.

Het gekke is dat het wél toegestaan is – ongeacht compatibiliteit – om te melden welke dependencies er gelden en de gebruiker die zelf te laten downloaden en installeren. Dat mag je zelfs automatiseren met een handig installatiescript of package manager-functionaliteit. Opensourcelicenties zijn namelijk distributielicenties, oftewel de voorwaarden gelden pas bij distributie. Wie alleen downloadt en gebruikt, heeft dus niets te maken met compatibiliteit van eventuele licenties.

Arnoud

Amerikaanse telecomwaakhond dwingt TP-Link open firmware toe te staan

| AE 8872 | Open source | 15 reacties

tp-link-router-firmwareDe FCC heeft een schikking getroffen met TP-Link van 200.000 dollar omdat verschillende wifi-routers van het bedrijf de radiofrequentieregels van de VS overtraden, las ik bij Tweakers. De routers konden met hoger vermogen zenden dan toegestaan. De schikking komt met een opmerkelijke uitkomst: het bedrijf zal opensourcefirmware toestaan op haar routers, iets dat sowieso vrij zelfzaam is in routerland.

De Amerikaanse toezichthouder FCC had op zeker moment nieuwe regels opgesteld over zenden op de 5 gigahertz-band. Een routermaker mocht ook derden niet meer toestaan op die band uit te zenden. TP-Link koos er voor deze regel na te leven door gewoon het installeren van software van derden onmogelijk te maken.

De FCC fluit TP-Link nu terug: dit gaat te ver, je had er enkel voor moeten zorgen dat die software van derden netjes omgaat met de 5 GHz-band. En om een duidelijk voorbeeld te stellen, wordt er gekozen voor een schikking waarbij TP-Link expliciet het mogelijk zal maken dat derden eigen firmware op mogen gebruiken.

Een uitdaging lijkt me, want TP-Link moet nog steeds wel ervoor waken dat de zendregels niet worden overtreden. Het zendvermogen op de 2,5GHz band mag niet meer zijn dan 100mW, en firmware moet dat niet kunnen aanpassen. De vraag is dus of je wel zinnige firmware kunt maken én dat soort regels kunt bewaken.

Arnoud

Mag een licentie je verbieden Kwaad te doen?

| AE 8555 | Contracten, Open source, Software | 11 reacties

Een lezer vroeg me: Onlangs vond ik de zogehten Do no evil-licentie. De JSON licentie zegt “The Software shall be used for Good, not Evil”. Is zoiets juridisch afdwingbaar, of wat zou de rechter hiermee doen? De licentie voor JSON (een protocol voor data-uitwisseling in Javascript) is voor 94,9% gelijk aan de bekende simpele MIT… Lees verder

Hoe kan ik een opensourcemodule opnieuw implementeren?

| AE 8194 | Open source, Software | 18 reacties

Een lezer vroeg me: Ik werk aan een opensourceproject dat een kloon (fork) is van een groter project. Wij krijgen bij onze nieuwste module nu het verwijt hun auteursrechten geschonden te hebben omdat de code te veel lijkt. Maar wij hebben deze echt zelf geschreven, hoewel de module wel exact hetzelfde doet. Plegen wij nu… Lees verder

Een medewerker heeft onze software ge-opensourcet, wat nu?

| AE 6258 | Arbeidsrecht, Open source, Software | 38 reacties

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… Lees verder

Spionagemalware Duqu schendt GPL

| AE 3040 | Grappig, Open source | 25 reacties

Sjongejongejonge, wat zullen de Duqu-makers daar wakker van liggen: de beruchte spionagemalware Duqu bevat open source-code die onder de ‘virale’ licentie GPL vallen, las ik bij Webwereld. Duqu blijkt open source blokken te bevatten van derden en die licentie te negeren. Tsja, wat moet je met zo’n berichtje? Ik noem het maar ‘grappig’, wanthet is… Lees verder

Kun je als koper van een Tomtec tablet ze dwingen de Linuxbroncode vrij te geven?

| AE 2939 | Open source | 61 reacties

Een lezer wees me op een draadje bij Gathering of Tweakers over de broncodes van de Linuxkernel in een Tomtec tablet: als aanvulling ik ben afgelopen vrijdag in een mailwisseling met TOM-TEC er achter gekomen dat zij niet eens (willen) snappen wat gpl betekend als kernel licentie en dat zij eigenlijk hun source moeten openbaren…. Lees verder

Zijn WordPress themes GPL?

| AE 2785 | Open source | 10 reacties

Een lezer vroeg me: Alweer een tijdje geleden speelde een discussie over het Thesis theme voor WordPress. Dat is een systeem voor layouts en uitbreidingen op het WordPress blogsysteem, dat eerst onder een gesloten (niet-open source) licentie beschikbaar was. WordPress zelf is GPL, en de auteurs daarvan eisten dan ook dat Thesis ook GPL moest… Lees verder