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

Mag je in een Git repository andermans merknaam gebruiken als verwijzing?

| AE 8983 | Merken, Open source | 5 reacties

github-octocatDiverse lezers wezen me (dank!) op dit artikel over het Docker-merk dat strenge regels hanteert over wat je met hun merknaam mag doen. Eén van die regels is dat je geen extensies mag publiceren op Docker als je daarbij de term ‘Docker’ gebruikt. Kan dat zomaar?

Docker is een containersysteem voor software, waardoor deze makkelijker te verspreiden is. Het is mogelijk hier allerlei extensies of scripts bij te ontwikkelen, en waar Docker zich dus tegen verzet is wanneer mensen zo’n eigen werk een naam geven die begint met docker. Zij zien dit als verwarringwekkend: mensen kunnen denken dat Docker, Inc. zelf deze projecten beheert of ze heeft goedgekeurd of gesponsord.

Het doet vagelijk denken aan dit geval uit maart waar een discussie over de merknaam 'Kik' zelfs lijdde tot een tijdelijk stukgaan van het internet. Maar daar ging het over het bezet houden van een naam (kik) door één van meerdere merkhouders. Hier gaat het over aanvullingen: docker-existdb bijvoorbeeld, een script waarmee je bij het bouwen van een container makkelijk verbinding kunt leggen met een database van eXist.

Is het nu verwarrend, docker-x als je wilt zeggen, een X voor/met Docker? Ik zou zeggen van niet. Het is toegestaan onder de merkenwet om te refereren naar een merkproduct, met name om aan te geven dat je daarmee compatibel bent of dat jouw product daarvoor bestemd is. "Hoesje voor Samsung Galaxy S" is dus legaal om te zeggen.

Daar staat tegenover dat je ook merkinbreuk pleegt door te onduidelijk te zijn over wie je wél bent. "Hoesje-voor-samsung-galaxy-s.nl" als webshop die zegt "Welkom, koop snel het mooiste hoesje voor uw Samsung Galaxy S" zou merkinbreuk zijn, omdat het hier (door stilzwijgen) lijkt alsof deze site van Samsung zelf is. Je moet dus als merkenverkoper expliciet en groot duidelijk maken wie je wél bent.

Bij Github-projecten wordt altijd vermeld wie de beheerder is van een project. De ontwikkelaar uit het artikel onderhoudt bijvoorbeeld zijn repositories op Github onder de naam 'zopyx', en dat kun je prima zien bij zijn projecten. Ik denk niet dat iemand hier uit zou halen dat dit een project van Docker is. Die zien er zo uit. Plus, in de opensourcegemeenschap dóe je dat nu eenmaal zo, de naam van het origineel combineren met wat jouw project daaraan toevoegt.

Maar toegegeven, deze informatiepresentatie is wel érg zakelijk en strak. De grootste en duidelijkste termen zijn de naam van het project. Als daar dan 'docker' in staat, dan zou je wellicht kunnen zeggen dat je daarmee de nadruk legt op Docker en zo dus stilzwijgend de indruk wekt dat dit project van Docker afkomstig is.

Wat vinden jullie? Overdreven zorg, of zou Docker legitiem kunnen vrezen dat mensen die onafhankelijke projecten aanzien voor die van hen?

Arnoud

Amerikaanse telecomwaakhond dwingt TP-Link open firmware toe te staan

| AE 8872 | Open source | 15 reacties

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

Maakt die Google/Oracle-uitspraak de GPL krachteloos?

| AE 8683 | Open source, Software | 33 reacties

Je kunt je mooie GPL vaarwel kussen, las ik bij Ars Technica vorige week. Die Google/Oracle uitspraak die een API fair use verklaarde, gaat namelijk de GPL en consorten onderuit schoffelen. Oké, het was de advocaat van Oracle die dat schreef, maar er zit een argumentatie bij. Dus laten we die eens nader bekijken. In… Lees verder

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 een merkenclaim tijdelijk het internet stukmaakte

| AE 8525 | Auteursrecht, Merken, Open source, Software | 23 reacties

Whoa. Elf regels code weghalen leidde tot een stukgegaan internet, las ik bij BusinessInsider. Dit was het onverwachte gevolg van een merkenclaim van sociaal netwerk Kik tegen softwaremodule Kik. Op basis van die claim werd de module weggehaald, waar de developer zo boos over werd dat hij al zijn code weghaalde. Waaronder dus die ene… 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