Open Source Licensing in Research

Research Software Rights Management at Helmholtz, 26.09.2025, Online Tobias Schlauch <Tobias.Sc[email protected]> Institute for Software Technology German Aerospace Center (DLR) http://www.dlr.de/sc OPEN SOURCE LICENSING IN RESEARCH About me •Tobias Schlauch, M.Sc. in Computer Science •Works as software engineer at DLR and coordinates the DLR Software Engineering Initiative •Supports DLR researchers in context of the topics open source and software licensing in cooperation with the DLR technology transfer division Disclaimer: I am not a lawyer. The presented information result from my practical experiences and are no legal advice. If you need legal advice, please reach out to your legal team. Typical question in software license consultations Can we provide <SOFTWARE> under <LICENSE> to <EXTERNAL AUDIENCE> in this <FORMAT>? Distribution of software to thirdparties typical triggers license conditions! Step 1: Check that you have the required “rights” The “Software” What will be distributed? Do we have the required “rights”? Step 1: Check that you have the required “rights” Potential problems and preventive measures The “Software” Preventive measures: •Contract management: employees, project partners, students, … •Documentation: •Use a version control system •Document all authors and licenses ideally in a machine readable way •Document AI usage •Use snippet scanning tools Potential problems: •Unclear authorship situation •Who contributed at all? •Under which contractual situation has this person contributed this code? •Unclear license of file(s) •Under which license is this logo? •Is this AI generated code a copy of a GPL licensed code? Step 1: Check that you have the required “rights” Documentation with REUSE Software •Goal: Make it easy to determine license and copyright information of source code! •Heavily builds on SPDX: https://spdx.dev/ •Provides the reuse helper tool for annotation, validation, and more: https://git.fsfe.org/reuse/tool •For more information: Tutorial, FAQ, Specification Step 2: Check the license compatibility LibA, v1.2.3, MIT LibB, v0.2.3, LGPL-3-only … …… LibA1.4.1, v0.1.1, GPL-2or-later Program A, <TARGET LICENSE> LibC, v0.9.1, Apache-2.0 Basic approach: •Find out the individual program(s) •Find out the concretely used software libraries and their licenses for each individual program •Analyse license compatibility for each individual program Your Code Is it statically or dynamically linked? Is license metadata of LibA wrong or is it only a IPC call? Step 2: Check the license compatibility Technical usage and copyleft effect of GPL licensed code •Clear cases: •Copying GPL-licensed code usually triggers copyleft effect •Inter-process communication with GPL-licensed program (e.g. via pipes / sockets) usually does not trigger the copyleft effect •GPL-licensed system libraries (e.g., operating system and other runtimes) usually do not trigger the copyleft effect •Controversial case: Linking to GPL-licensed software libraries / plugins / modules: •Free Software Foundation generally considers linking (statically and dynamically) to trigger the copyleft effect •Recommendation:Avoid this “grey area” and follow this interpretation GPL-licensed code Your Code Program under GPL? LibA, v1.2.3, MIT LibB, v0.2.3, LGPL-3-only … …… LibA1.4.1, v0.1.1, GPL-2or-later LibC, v0.9.1, Apache-2.0 Your Code Step 2: Check the license compatibility Potential problems and preventive measures The “Software” Preventive measures: •Clear dependency selection process: •Make license a selection criteria •Check relevant subdependencies and options as well •Document dependencies and use a package manager •Use license scanners/linters: ecosystem-specific vs. generic tools Potential problems: •Unclear which individual programs exist •Unclear list of dependencies and how they are used •Mixing program and development dependencies •Wrong license metadata in used software libraries LibA, v1.2.3, MIT LibB, v0.2.3, LGPL-3-only … …… LibA1.4.1, v0.1.1, GPL-2or-later LibC, v0.9.1, Apache-2.0 Your Code