Welke licentie moet je toevoegen aan je software om het FAIR te maken?

Dit is de eerste blog in de serie Simple steps towards FAIR code and software. Eén van de meest gestelde vragen van onderzoekers aan RDM Support over de publicatie van code of software is: Welke licentie moet ik toevoegen aan mijn software om het FAIR te maken? In deze blogpost vragen we projectleider FAIR Data and Software van het Open Science Programma Jonathan de Bruin om deze vraag voor je te beantwoorden.

Disclaimer: Deze blogpost is een interview met een expert. Er kunnen geen rechten aan worden ontleend.

Vertel: welke softwarelicentie moeten we toevoegen aan onze onderzoekscode en -software?

"(ha-ha) Dit is precies wat de meeste onderzoekers vragen! Hoewel het geen ingewikkeld antwoord hoeft te zijn, is het niet mogelijk om deze vraag te beantwoorden met één enkele licentie. De beste licentie voor je code of software hangt af van meerdere dingen, zoals jouw wensen en die van je collega’s, details van je project en aanbevelingen van je geldschieters of universiteit. Onze universiteit, de Universiteit Utrecht, promoot een open houding waarin open en FAIR publicatie van onderzoekscode en -software een cruciaal aspect is. Daarom is een zogenaamde open licentie, in het algemeen, de beste manier voor de meeste onderzoekers. Software of code gepubliceerd onder een open source licentie mag vrij worden gebruikt, gewijzigd en gedeeld. Als je geen licentie aan je code of software toevoegt, is dit meestal niet mogelijk vanwege auteursrechtwetten. Het goede hieraan is dat je niet je eigen open source licentie hoeft te schrijven; er zijn veel open licenties beschikbaar. Vooral licenties die zijn goedgekeurd door het zijn betrouwbaar en nuttig. Juridische experts en softwareontwikkelaars lezen deze licenties uitgebreid door."

Betekent dit dat de universiteit geen beleid heeft dat een specifieke softwarelicentie handhaaft?

"Momenteel heeft de Universiteit Utrecht geen universiteitsbreed beleid dat een specifieke softwarelicentie handhaaft voor onderzoekers en medewerkers. Ik denk zelf dat dit goed is; zoals eerder gezegd, hangt de beste licentie af van het project waar je aan werkt en wat je nodig hebt. We weten dat onze universiteit inzet op openheid en daarom kunnen we ons meestal beperken tot open source-licenties. Soms heeft een geldschieter aanbevelingen of een beleid over licenties voor onderzoeks-code of software-output, maar dit is meestal beperkt tot het publiceren van het werk onder een open source-licentie."

Onze universiteit, de Universiteit Utrecht, promoot een open houding waarin open en FAIR publicatie van onderzoekscode en -software een cruciaal aspect is.

Je zegt, "Er zijn veel open source licenties." Kun je de verschillen uitleggen?

"Er zijn inderdaad veel open source licenties. Als je naar de lijst van door het Open Source Initiative goedgekeurde licenties kijkt, word je waarschijnlijk overdonderd. In het algemeen delen de meeste mensen open source licenties in drie verschillende categorieën: permissive, weakly copyleft, en strongly copyleft. Permissive licenties zijn licenties met minimale restricties op hoe software wordt gebruikt, gewijzigd en gedeeld. Ze vereisen meestal alleen een auteursrechtvermelding, soms gezien als toeschrijving. Bekende permissive licenties zijn MIT, Apache 2.0 en BSD. Copyleft licenties zijn een juridische manier om te vereisen dat kopieën of derivaten van je code of software dezelfde rechten hebben, bijvoorbeeld wat betreft openheid. Ik leg dit soms zo uit aan onderzoekers: Als ik open werk, moet jij (red.: de (her)gebruiker van het werk) ook open werken. Voor strongly copyleft-werk geldt dit ook voor alle toevoegingen en verlengstukken van het werk. Daarom wordt dit type licentie soms viral genoemd. Voorbeelden hiervan zijn LGPL-, GPL- en EUPL-licenties."

Vereisen de licenties ook correcte bronvermelding?

"Geen één van de populaire open source softwarelicenties die ik ken vereisen dat de gebruiker van de code of software het werk vermeldt zoals we dat doen in de academische wereld. Ze beperken dit meestal tot het noemen van de auteursrechtvermelding, bijvoorbeeld ’Copyright Utrecht University, 2023’. Er zijn veel effectievere methoden om je werk vermeld te krijgen dan proberen dat te vereisen met een licentie. Je kunt bijvoorbeeld instructies toevoegen in je documentatie of software voor hoe je vermeldt wilt worden. Tegenwoordig zijn er ook speciale bestanden die je kunt toevoegen aan je werk om de gebruiker te helpen om je werk goed te vermelden, bijvoorbeeld CITATION.CFF."

Gezien de eerder genoemde verschillen, wat beveel je meestal aan aan onderzoekers?

"Voor de meeste onderzoekers is een permissive licentie goed geschikt. In de afgelopen jaren is de MIT-licentie, vernoemd naar het Massachusetts Institute of Technology (MIT), de populairste licentie geworden onder open source ontwikkelaars en in de Universiteit Utrecht. In 2022 voerden we een studie uit aan de Universiteit Utrecht die laat zien dat 32 procent van de code en software was gepubliceerd onder de MIT-licentie. Deze licentie is vooral interessant omdat het alleen een korte juridische tekst is die verbazend gemakkelijk te lezen en te begrijpen is. Als je deze licentie kiest, is het belangrijk om te letten op je dependencies of code die je hebt gekopieerd uit bronnen met een strengere of copyleft licentie. In dat geval moet je zorgvuldig controleren of je je werk nog mag publiceren onder een permissive licentie.

Sommige onderzoekers zijn zeer tegen het hergebruik van hun werk in een gesloten of commerciële omgeving. Ze gaan meestal voor een copyleft licentie zoals GPL, LGPL of EUPL. Dit voorkomt commercieel gebruik niet, maar handhaaft de open source status van de wijzigingen en derivaten. Dit is meestal oké voor de meeste van deze onderzoekers, aangezien een licentie die deze eisen handhaaft niet gebruikelijk is."

In 2022 voerden we een studie uit aan de Universiteit Utrecht die laat zien dat 32 procent van de code en software wordt gepubliceerd onder de MIT-licentie.

Zijn er redenen om geen open source licentie te gebruiken voor je werk?

"Zeker! Maar dit is minder gebruikelijk dan wanneer je onderzoeksdata publiceert. Denk bijvoorbeeld aan code die privacygevoelige informatie laat zien. Je kunt dit meestal omzeilen met goede codering, maar als dit niet het geval is, wil je het werk misschien niet publiceren onder een open licentie. Andere mogelijke redenen zijn met copyright beschermde onderdelen, patenten, juridische beperkingen of ondernemersambities met het werk. In dat geval denk ik dat het goed zou zijn om contact op te nemen met je juridische afdeling, de medewerker kennistransfer en een expert in open source software."

Het is nog steeds een beetje overdonderend voor mij. Ik kan me voorstellen dat onderzoekers hetzelfde doormaken. Waar moeten ze naartoe gaan voor hulp?

"Dit is een interessante vraag. Ga je naar je juridische afdeling? Of naar IT Support, het auteursrechtkantoor of je Research Support Officer (RSO’s)- Of naar de collega’s van Research Data Management Support? Ik denk dat onderzoekers naar het laatste, RDM Support , moeten gaan met hun vragen. Ze hebben veel ervaring op het gebied van licenties en hebben contact met juridische deskundigen, RSO’s en open source softwareontwikkelaars. Onderzoekers zouden nooit moeten aarzelen om hun vragen daar te stellen of hun licentie te laten dubbelchecken. We zijn er om je te helpen."

De definitie voor "onderzoekssoftware"

De werkgroep FAIR for Research Software (FAIR4RS) zegt dat de volgende zaken onder onderzoekssoftware vallen: "broncodebestanden, algoritmes, scripts, computationele werkstromen en uitvoerbare bestanden die zijn gecreëerd tijdens het onderzoeksproces of voor onderzoeksdoeleinden. Software-onderdelen (e.g., besturingssystemen, bibliotheken, dependencies, softwarepakketten, scripts, etc.) die worden gebruikt voor onderzoek maar niet zijn gemaakt tijdens onderzoek of met duidelijke bedoelingen voor onderzoek moeten worden gezien als software in onderzoek en niet als onderzoekssoftware. Dit onderscheid kan variëren tussen disciplines" ( Gruenpeter , 2022). Deze definitie wordt gebruikt in de publicatie "Introducing the FAIR Principles for research software" door Barker et al (2022) en is ook overgenomen door de RDM Support gemeenschap aan de Universiteit Utrecht.