Github introduceert werknemersvriendelijk IP-contract

| AE 9359 | Arbeidsrecht | 4 reacties

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

Mag je geen open source meer op Github zetten?

| AE 9296 | Open source | 10 reacties

Paniek in de tent: softwarehostingsite Github heeft nieuwe voorwaarden, en die botsen met veel open licenties. Dat las ik op diverse plekken. Je moet ze een brede licentie geven en afstand doen van je persoonlijkheidsrechten, en dat kan nu eenmaal niet als je open source daar neerzet. Maar volgens mij valt dat wel mee.

De pijn zou zitten in sectie D, over eigendomsrechten. Allereerst de licentie die je moet verlenen:

If you set your pages and repositories to be viewed publicly, you grant each User of GitHub a nonexclusive, worldwide license to access your Content through the GitHub Service, and to use, display and perform your Content, and to reproduce your Content solely on GitHub as permitted through GitHub’s functionality. You may grant further rights if you adopt a license.

In gewone taal: wij als Github mogen jouw content (inclusief eventuele werken van derden daarin) gebruiken en verspreiden op onze dienst, en alle gebruikers mogen dat ook. Dit is typisch juridisch moeilijk doen: oh jee, straks zegt iemand dat wij een kopie maken van zijn software omdat hij die bij ons host, laten we maar even zeggen dat hij ons een licentie moet geven.

Maar belangrijker, ik zie er geen tegenspraak in met de opensourcelicentie die je op je werk plakt. Mensen moeten met de Github functionaliteit kunnen doen wat die functionaliteit doet. En met open source mag je alles: kopiëren, aan derden geven, importeren in je eigen project en ga zo maar door. Het is de distributie naar anderen toe waarop de voorwaarden geschreven zijn, en die anderen moeten dus gewoon zorgen dat ze de voorwaarden nakomen.

Dan de morele rechten: daar moet je inderdaad afstand van doen, iets dat van de Auteurswet mag (behalve het recht van verminking, maar hoe dat moet uitpakken bij software weet werkelijk niemand). Dat botst dan met licenties die naamsvermelding eisen, en dat is 99% van de opensourcelicenties. Maar ik zie ook dat niet als een probleem:

To the extent such an agreement is not enforceable by applicable law, you grant GitHub a nonexclusive, revocable, worldwide, royalty-free right to (1) use the Content without attribution strictly as necessary to render the Website and provide the Service; and (2) make reasonable adaptations of the Content as provided in this Section. We need these rights to allow basic functions like search to work.

Github wil met name voorkomen dat elke zoekopdracht moet zeggen “met code van Jan, Piet en Klaas”. Iets dat iedere rechter volkomen redelijk zal vinden. Zeker omdat je meteen wordt doorverwezen naar de resultaten, waar de naam van de programmeurs wel gewoon bij staat. Ik vraag me zelfs af of Github uberhaupt een licentie nodig heeft om zoekresultaten te mogen tonen, dat zie ik gewoon als citaatrecht.

Alles bij elkaar lijkt dit me dus een storm in een glas water, hoewel ik wel toegeef dat dit iets handiger had kunnen worden opgeschreven.

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

Mag GHTorrent openbare data van Github aggregeren als onderzoeksdataset?

| AE 8460 | E-mail, Privacy, Software | 25 reacties

Mag je eisen dat je e-mailadres verwijderd wordt uit de GHTorrent dataset? Een veel voorkomende klacht bij dit project. GHTorrent is een onderzoeksproject dat Github-softwareprojecten indexeert en gemakkelijk doorzoekbaar maakt. Hierbij worden ook de e-mailadressen van ontwikkelaars geïndexeerd, waardoor je allerlei koppelingen kunt leggen. Maar mag dat eigenlijk wel? Github is een van de grootste… Lees verder

Moet je bij een notice/takedown je hele GitHub repository verwijderen?

| AE 7673 | Auteursrecht, Software | 15 reacties

Een lezer vroeg me: Als ik in mijn GitHub repository een pull-request binnenhaal waar ik later een notice and takedown over krijg, voldoet het dan om met een nieuwe commit de omstreden code te verwijderen (de omstreden code blijft dan in in de git historie beschikbaar) of moet ik dan de hele repository verwijderen? Voor… Lees verder