List of exercises

Full list

This is a list of all exercises and solutions in this lesson, mainly as a reference for helpers and instructors. This list is automatically generated from all of the other pages in the lesson. Any single teaching event will probably cover only a subset of these, depending on their interests.

Social coding

In social-coding.md:

Social-1: Think about if and how you share

• Did you ever share your code? If yes, what motivated you? Come up with reasons for sharing your scripts/code/data.

• Also think about reasons for not sharing.

In social-coding.md:

Social-2: Discussion about “You aren’t required to support anyone”

• Have you experienced an implicit expectation of support?

• Supporting all requests can lead to overworking and mental health issues.

• Not supporting requests can also induce guilt.

• Most projects are maintained by 1 or 2 persons.

• Most projects cannot retain contributors for a longer time. Interests change. “Casual contributors are like tourists visiting NYC for a weekend” (Nadia Asparouhova, book below).

• If you maintain all projects that you start forever, at some point it may be difficult to start new projects.

• What are your experiences? Do you agree with the above thoughts?

• Book recommendation: Nadia Asparouhova (formerly Nadia Eghbal): “Working in Public: The Making and Maintenance of Open Source Software (Stripe Press)”

Software licensing focusing on open source

In software-licensing.md:

Limitations and context of this lesson

This lesson is designed as practical educational material for researchers and research software engineers, not formal legal advice.

• EU directives set only minimum requirements in some areas: Member States implement them differently and may add national rules not covered here. For example, some Member States let university researchers retain ownership of the programs they write instead of applying the employer rule in Art. 2(3).

• Institutional Context: Employment contracts, grant agreements, and university policies heavily influence software ownership and licensing choices.

• This lesson covers only the general principles of open-source reuse, copyright scope, and software adaptation.

If you need formal guidance, the references below can help and so can legal experts, especially if your host institute has a legal services office:

• EUR Directive 2009/24/EC

• Compendium of U.S. Copyright Office Practices (3rd Ed.) – Chapter 700, Section 721: Computer Programs

• Chinese Regulations on Computer Software Protection,(search:”计算机软件保护条例”)

• Joinup Licensing Assistant,JLA

• FSFE REUSE Initiative

• Research Software Alliance Policy Directory

In software-licensing.md:

Licensing-1: Which scenarios typically describe your work?

The text below can be copied to the collaborative document for an online poll:

## Question: How do you work with other's code?

**Choose many**. Vote by adding an `o` character:

- 1. Writing everything yourself
  - votes:

- 2. Implementing a published algorithm 
  - votes:

- 3. Pasting in a permissive snippet
  - votes:

- 4. Pasting in a copyleft snippet
  - votes:

- 5. Importing or linking a library
  - votes:

- 6. Writing a Dockerfile or .def
  - votes:

- 7. Publishing a built image
  - votes:

- 8. Using Copilot, ChatGPT, Claude, or similar
  - votes:

- 9. Shipping prompts, weights or datasets
  - votes:

In software-licensing.md:

Licensing-2: Can you decide from the number of lines?

The text below can be copied to the collaborative document for an online poll:

## Question: Which of these can you safely copy *based only on its size*?

**Choose many**. Vote by adding an `o` character:

- A. A one-line expression: `return max(lo, min(x, hi))`
  - votes:

- B. Five lines of ordinary boilerplate for parsing command-line arguments
  - votes:

- C. Three unusually written lines copied verbatim from a GPL-licensed solver
  - votes:

- D. Twenty lines you wrote independently after reading an algorithm in a paper, without looking at another implementation
  - votes:

- E. Anything under 10 lines is too small to be copyrighted
  - votes:

- F. None of the above: the number of lines alone does not decide
  - votes:


### Follow-up question

For each example, what information would you want to know before reusing or publishing the code?

Solution

The key answer is F: there is no fixed safe number of lines.

Copyright does not use a numerical threshold such as 5, 10, or 20 lines. The important question is whether what has been copied is protected expression. Very short or purely functional code may not meet the originality threshold, while a short but distinctive piece of code may.

• A and B: they may be too simple, conventional, or constrained by function to contain protectable expression, but their size alone does not answer the question.

• C: being only three lines does not automatically make copied code unprotected. Check its provenance and license.

• D: independently implementing the idea or algorithm is different from copying somebody else’s expression of it.

• E: there is no “10-line rule”.

Practical rule: if you copied code and are unsure whether it is protected, check where it came from and under which license it was published. Preserve any required notices, or independently implement the underlying idea instead of copying the code.

In software-licensing.md:

Scenario 1: Authoring original code and algorithms

You wrote an original algorithm from scratch (in Python, C++, Rust, etc.). Your repository contains only your original source code and dependency specifications (requirements.txt, CMakeLists.txt, Cargo.toml).

• Licensing Goal: You want maximum adoption and zero friction for commercial or academic reuse.

• Legal Reality: External dependencies remain separate works. Because you only list them and have not bundled third-party code inside your repository, no inbound license terms constrain your choice. This changes if you ship dependencies together with your code, for example in an executable or container image (see Scenario 5 and Scenario 7).

• JLA Selection Strategy: To ensure downstream users must keep your copyright notice while granting them maximum flexibility to incorporate your code into both open and proprietary software, you require Incl. Copyright without imposing share-alike conditions (leaving Copyleft/Share a. unselected).

Solution

What to select in the JLA interface:

1. Can Column: Select Distribute, Modify/merge, and Commercial use

2. Must Column: Select Incl. Copyright

3. Support Column: Select OSI approved

• Example JLA Matches: MIT, Apache-2.0, BSD-3-Clause

• Permissive vs. Public Domain (EU Civil Law Nuance): Public domain dedications (e.g., CC0, Unlicense) attempt to give away all rights. In many EU countries, authors cannot fully waive their rights, especially moral rights such as being named as the author. CC0 handles this with a fallback license, which makes it a good choice for data, but it explicitly grants no patent rights and is not OSI approved, so it is less suited to code. An explicit permissive license like MIT or Apache-2.0 is valid across Europe and is the clearer choice for software.

• Credit vs. Citation: Permissive licenses require users to keep your copyright notice in the code. They do not require anyone to cite you in a publication. For academic citation, add a CITATION.cff file to your repository.

• Downstream Obligations: Anyone who reuses, modifies, or integrates your code into their work must preserve your copyright notice and license text. They are not required to share their modifications or open-source their downstream projects.

• Allowed Inbound Snippets: You can freely embed small third-party code snippets licensed under permissive terms (e.g., MIT, BSD, Apache-2.0, 0BSD), keeping their notices, without affecting your permissive license. Copying copyleft code into your files is different: strong copyleft (e.g., GPL, EUPL) generally requires re-licensing your project, and pasted weak copyleft code does not stay contained either. Pasted MPL-2.0 code makes that file MPL-covered, and pasted LGPL code is treated like GPL. Weak copyleft only lets your code stay permissive when you use it as a separate file or library (see Scenario 4).

• In-File Identification (SPDX): Apply standard machine-readable SPDX tags directly at the top of your scripts, following the REUSE specification:

# SPDX-FileCopyrightText: 2026 Author Name <author@institute.eu>
# SPDX-License-Identifier: MIT

import numpy as np

In software-licensing.md:

Scenario 2: Choosing reciprocity for your own implementation

You developed a custom solver implementing algorithms from academic literature. You want any downstream improvements, extensions, or modifications to remain open-source and be shared back with the scientific community.

• Licensing Goal: You want to enforce reciprocity (share-alike), preventing third parties from incorporating your implementation into proprietary software without sharing their modifications.

• Legal Reality: The published algorithm itself is an unprotected idea anyone may implement it independently, as Scenario 1 and the SAS ruling establish. What copyright protects is your specific implementation. Nothing about implementing a published method forces a particular license; copyleft here is your deliberate choice to bind downstream distributors to matching terms.

• JLA Selection Strategy: To enforce reciprocal sharing, you must mandate that downstream distributors disclose their modified source code (Disclose source) and license their adaptations or combined works under matching terms (Copyleft/Share a.).

Solution

What to select in the JLA interface:

1. Can Column: Select Distribute, Modify/merge, and Commercial use

2. Must Column: Select Incl. Copyright, Disclose source, and Copyleft/Share a.

3. Support Column: Select OSI approved

• Example JLA Matches: EUPL-1.2, GPL-3.0, AGPL-3.0

• Copyleft Mechanics (EUPL vs. GPL Nuance): GPL-3.0 is the standard global copyleft license, but EUPL-1.2 is specifically tailored for European institutions. EUPL-1.2 is officially published in 23 EU language versions (each with equal legal validity) and sets the applicable law and courts by reference to the licensor’s EU Member State. Its compatibility clause works in one direction only: EUPL code can be combined into a GPL project and distributed under GPL, but GPL code cannot be re-licensed under EUPL.

• AGPL and network use: AGPL-3.0 adds one rule to GPL-3.0: if you modify the software and let people use it over a network (for example a web portal or API), you must offer them the source code, even if you never distribute copies. Consider it if your group runs research software as an online service.

• The trade-offs of strong copyleft: Reciprocity comes at a cost. Some companies and projects avoid copyleft code entirely, so you may reach fewer users than with a permissive license. Strong copyleft licenses are also frequently incompatible with each other, so a future collaborator on a differently-licensed copyleft project may be unable to use your work at all (Scenario 5 covers this). Neither choice is better: Scenario 1 optimizes for reach, this scenario for keeping improvements open.

• Choose deliberately, early: Changing your license later is only possible if you hold all the rights. Once others have contributed code, you need every contributor’s agreement to re-license.

• Downstream Obligations: Anyone who distributes your code or a modified version of it must provide complete access to the corresponding source code under the same copyleft license and preserve your original copyright notices. Running modified code internally, without distributing it, creates no obligation (except under AGPL for network use).

• Allowed Inbound Snippets: You can freely embed code snippets licensed under permissive terms (e.g., MIT, Apache-2.0, BSD), keeping their notices, or public domain waivers (CC0). Copyleft snippets must be compatible with your license, and compatibility is directional: a GPL project can take EUPL or GPL snippets, but a GPL snippet in an EUPL project would require the combined work to be distributed under GPL. When in doubt, only embed copyleft code under the same license as your project. You cannot embed closed-source or proprietary code snippets.

• In-File Identification (SPDX): Apply standard machine-readable SPDX tags directly at the top of your scripts, following the REUSE specification. If you choose GPL, use GPL-3.0-only or GPL-3.0-or-later rather than plain GPL-3.0, since the two behave differently when a new GPL version is released:

# SPDX-FileCopyrightText: 2026 Author Name <author@institute.eu>
# SPDX-License-Identifier: EUPL-1.2

import numpy as np

In software-licensing.md:

Scenario 3: Embedding permissively licensed third-party code

You are building an RSE tool and copied a helper function or utility snippet from a third-party project licensed under a permissive license (e.g., MIT or Apache-2.0) directly into one of your source files.

• Licensing Goal: You want to maintain a permissive default for your project while properly acknowledging and legally respecting the embedded third-party code.

• Legal Reality: Permissive licenses explicitly grant you permission to copy, modify, and embed their code into your repository. However, embedding permissive code does not make the original third-party copyright disappear: you must preserve the original copyright notice and license terms for that specific snippet.

• JLA Selection Strategy: Because inbound permissive code gives you maximum licensing flexibility, your overall repository can remain permissively licensed. To reflect this, require that notices are kept (Incl. Copyright) without imposing reciprocal sharing constraints (leaving Copyleft/Share a. unselected).

Solution

What to select in the JLA interface:

1. Can Column: Select Distribute, Modify/merge, and Commercial use

2. Must Column: Select Incl. Copyright

3. Support Column: Select OSI approved

• Example JLA Matches: MIT, Apache-2.0, BSD-3-Clause

• Notice Preservation Nuance: Permissive licenses are flexible, but they are not license-free. Your repository license covers your code. It does not relicense the embedded snippet that code stays under its original license and its original copyright holder’s terms. You are distributing one file containing two separately licensed contributions, which is why both notices must appear.

• What “keeping the notice” requires: Keep the original copyright line and the license text. An SPDX identifier only points to a license, so the full text must also be in your repository, typically as one file per license in a LICENSES/ folder (e.g., LICENSES/Apache-2.0.txt). Apache-2.0 adds two small requirements: if you modified the snippet, state that you changed it, and if the original project has a NOTICE file, carry its relevant content along.

• Check the source before copying: Confirm the license in the original project’s own LICENSE file, not in a blog post or second-hand claim. A project with no license file is All Rights Reserved, so its code cannot be copied. Note that Stack Overflow content is licensed CC BY-SA, a share-alike license, not a permissive one, so non-trivial Stack Overflow snippets belong in Scenario 4.

• Downstream Obligations: Downstream users receive your project under your primary permissive license (e.g., MIT), but they must preserve both your overall copyright notice and the specific third-party notices attached to embedded snippets.

• Allowed Inbound Snippets: In addition to the embedded permissive snippet, you can freely embed other permissively licensed code (MIT, BSD, Apache-2.0) or public domain waivers (CC0). Embedding strong copyleft code (GPL, EUPL) generally requires re-licensing your repository to match. Weak copyleft does not stay contained when pasted either: pasted MPL-2.0 code makes that file MPL-covered, and pasted LGPL code is treated like GPL. Weak copyleft only lets your code stay permissive when used as a separate file or library.

• In-File Identification (SPDX): Mark your file’s own license at the top, and mark the embedded snippet with the REUSE snippet tags so its boundaries are machine-readable:

# SPDX-FileCopyrightText: 2026 Author Name <author@institute.eu>
# SPDX-License-Identifier: MIT

import numpy as np

# SPDX-SnippetBegin
# SPDX-SnippetCopyrightText: 2024 External Contributor <dev@external-lib.org>
# SPDX-License-Identifier: Apache-2.0
def fast_matrix_solver(matrix):
    # Embedded algorithm implementation
    return np.linalg.solve(matrix, np.eye(len(matrix)))
# SPDX-SnippetEnd

def main():
    pass

In software-licensing.md:

Scenario 4: Embedding copyleft third-party code

You are building a software tool and copied a non-trivial code snippet from a third-party project licensed under a copyleft license (e.g., GPL-3.0 or EUPL-1.2) directly into one of your source files. This is the situation behind the failed build (job #142) in the Motivation section.

• Licensing Goal: Comply with legal requirements imposed by the inbound copyleft code while ensuring your overall repository remains legally compliant.

• Legal Reality: Copying a non-trivial copyleft snippet into your source files creates a single combined work, so copyleft licensing generally extends to your whole project. Moving the snippet into a separate file of the same program does not change this. “Non-trivial” matters: a snippet too short or purely functional to qualify as the author’s own intellectual creation (Art. 1(3)) may not carry copyright at all. There is no word count or line count that draws this line if you are unsure, assume it is protected and either comply or reimplement.

• JLA Selection Strategy: If you keep the snippet, your repository must adopt reciprocal sharing terms, so configure JLA to require source code disclosure (Disclose source) and reciprocal licensing (Copyleft/Share a.).

Solution

What to select in the JLA interface:

1. Can Column: Select Distribute, Modify/merge, and Commercial use

2. Must Column: Select Incl. Copyright, Disclose source, and Copyleft/Share a.

3. Support Column: Select OSI approved

• Example JLA Matches: GPL-3.0, EUPL-1.2

• Match the snippet’s license: JLA lists both, but you do not get to choose freely. Your project must take a license compatible with the snippet: a GPL snippet means GPL, because GPL code cannot be re-licensed under EUPL. An EUPL-1.2 snippet can go either way: its compatibility clause allows the combined project to be distributed under GPL-3.0 if your ecosystem requires it.

• Re-licensing is not the only fix: Re-licensing your project is only possible if you hold the rights, so check with co-authors and your institution first. The alternatives are to reimplement the functionality yourself (a genuine rewrite, not a close paraphrase), to find a permissively licensed alternative, or to ask the snippet’s copyright holder for permission to use it under your license, in writing.

• Stack Overflow snippets: Stack Overflow content is licensed CC BY-SA (version 2.5, 3.0, or 4.0 depending on when it was posted), a share-alike license. Credit non-trivial snippets with a link to the answer and the author’s name. Creative Commons considers CC BY-SA 4.0 compatible with GPL-3.0 in one direction, so such snippets can go into a GPL-3.0 project, but not into an MIT project.

• Downstream Obligations: Anyone to whom you distribute your repository must receive full access to the source code under the same copyleft license terms and preserve all copyright notices. Running the code internally, without distributing it, creates no obligation.

• Allowed Inbound Snippets: Because your overall repository is now governed by a copyleft license, you can safely embed code from permissive sources (MIT, BSD, CC0), keeping their notices, as well as compatible copyleft sources. Note that Apache-2.0 is compatible with GPL-3.0 but not with GPL-2.0. You cannot embed proprietary, closed-source code or snippets from incompatible copyleft licenses.

• In-File Identification (SPDX): Mark your file’s own license at the top, and mark the embedded copyleft snippet with the REUSE snippet tags so the original author remains credited:

# SPDX-FileCopyrightText: 2026 Author Name <author@institute.eu>
# SPDX-License-Identifier: GPL-3.0-or-later

import numpy as np

# SPDX-SnippetBegin
# SPDX-SnippetCopyrightText: 2023 External Researcher <researcher@university.org>
# SPDX-License-Identifier: GPL-3.0-or-later
def optimized_fft_filter(data_signal):
    # Embedded copyleft algorithm implementation
    return np.fft.fft(data_signal)
# SPDX-SnippetEnd

def main():
    pass

In software-licensing.md:

Scenario 5: Linking against a GPL-licensed library

You are developing a software application that imports or links against an external software library licensed under GPL-3.0 (e.g., importing a GPL Python package or linking a C/C++ static/shared library).

• Licensing Goal: Ensure legal compliance while using copyleft libraries as core dependencies in your software project.

• Legal Reality: Whether linking creates a combined work is genuinely unsettled, and often has to be decided case by case. The FSF’s position is that linking a GPL library statically or dynamically creates a combined work; some legal scholars and Commission EUPL guidance disagree, particularly for dynamic linking through a stable API. Most Member States have no case law on this, so no firm general rule can be stated. The guidance below follows the conservative, widely-adopted reading.

• JLA Selection Strategy: Under the conservative reading, linking to a GPL library means the combined program you distribute must be released under matching reciprocal terms, so configure JLA to require source code disclosure (Disclose source) and reciprocal licensing (Copyleft/Share a.).

Solution

What to select in the JLA interface:

1. Can Column: Select Distribute, Modify/merge, and Commercial use

2. Must Column: Select Incl. Copyright, Disclose source, and Copyleft/Share a.

3. Support Column: Select OSI approved

• Example JLA Matches: GPL-3.0, EUPL-1.2

• The safe default, not settled law: On the conservative reading, your own files must be under a GPL-compatible license (GPL itself, or permissive licenses such as MIT or BSD), and the combined program you distribute is under GPL. EUPL-1.2 also works for your own files through its compatibility clause, but the combined program then goes out under GPL anyway.

• What you ship matters: Static linking copies the library’s code into your binary, so you always distribute it. With dynamic linking (including a Python import), the library stays a separate file. If you publish only your own source and users install the GPL library themselves, the risk is much lower, although the FSF would still expect your code to be GPL-compatible. If you bundle the library, in an executable, a container image, or a compiled binary, GPL clearly applies to what you ship.

• Alternatives if you want to stay permissive:

  • Find a permissively licensed alternative library.

  • Use an LGPL library instead: with dynamic linking, your own code can stay permissive, provided you keep its notices and do not restrict users from modifying the library or reverse engineering to debug those modifications.

  • Use an EUPL-1.2 library through dynamic linking: Commission guidance says this does not make your program a derivative work (guidance, not case law). Static linking or copying EUPL code is treated as a combined work.

  • Call a GPL tool as a separate program (e.g., via the command line) rather than importing it. This is generally treated as two programs communicating, not a combined work.

• Copyleft licenses are not compatible with each other: Two strong copyleft licenses can each demand that the combined work use their terms, which makes the combination undistributable. The classic trap is GPL-2.0-only: without the “or later” clause you cannot upgrade to GPL-3.0 to resolve a conflict, so GPL-2.0-only code cannot be combined with GPL-3.0 or Apache-2.0 code at all. Always check the exact SPDX identifier GPL-2.0-only and GPL-2.0-or-later behave very differently.

• Downstream Obligations: Anyone to whom you distribute the application must receive full access to your source code under GPL-compatible terms, along with upstream copyright notices and the build scripts needed to recompile it. Running the software internally, without distributing it, creates no such obligation though note that AGPL-3.0 extends this to network use, such as a web application built on an AGPL library.

• Allowed Inbound Code & Dependencies: Your project can import or include other permissively licensed packages (MIT, BSD, Apache-2.0) and public domain waivers (CC0). However, all code linked together in the final executable or runtime environment must satisfy GPL compatibility; for example, Apache-2.0 is compatible with GPL-3.0 but not with GPL-2.0.

• Check your dependencies: Tools such as pip-licenses (Python) list the license of every installed package. Most package ecosystems have an equivalent. Run one once per project.

• In-File Identification (SPDX): Apply standard machine-readable SPDX tags directly at the top of your main scripts:

# SPDX-FileCopyrightText: 2026 Author Name <author@institute.eu>
# SPDX-License-Identifier: GPL-3.0-or-later

import gpl_licensed_solver  # External GPL dependency: conservative reading requires GPL compatibility

def solve_system(data):
    return gpl_licensed_solver.compute(data)

In software-licensing.md:

Scenario 6: Authoring container recipes and environment specifications

You are creating a Dockerfile, Apptainer .def file, Conda environment.yml, or build recipe to automate the setup of your research environment. The recipe itself contains setup instructions, shell commands, and package lists.

• Licensing Goal: You want maximum adoption and reuse of your build automation script so other researchers can freely adapt and build upon your workflow.

• Legal Reality: Build recipes and configuration scripts are plain-text source code, separate from the software binaries they download at build time. The build instructions you write are your expression but note that a very short recipe (a FROM line plus two RUN commands) may be too trivial to meet the Art. 1(3) originality threshold and may not attract copyright at all. The same applies to a plain list of package names in an environment.yml. Longer, non-obvious recipes clearly do attract copyright.

• JLA Selection Strategy: To allow anyone to reuse or adapt your container recipe without restrictions, require that your copyright notice is kept (Incl. Copyright) while leaving reciprocal requirements (Copyleft/Share a.) unselected.

Solution

What to select in the JLA interface:

1. Can Column: Select Distribute, Modify/merge, and Commercial use

2. Must Column: Select Incl. Copyright

3. Support Column: Select OSI approved

• Example JLA Matches: MIT, Apache-2.0, BSD-3-Clause

• License short recipes anyway: Even if a recipe may fall below the originality threshold, a two-line SPDX header removes any doubt for people who want to reuse it, and tools such as reuse lint expect every file to be marked. For very small configuration files, some projects use CC0-1.0.

• Recipe vs. Image Nuance: The license applied to a Dockerfile covers only the recipe instructions, not the software packages installed inside the container when docker build runs. Writing apt-get install for a GPL package, or FROM ubuntu, names the software without copying it. A permissively licensed Dockerfile can therefore install both permissive and copyleft packages without legal conflict. This applies to the recipe only: once you build and publish the resulting image, you are distributing every package inside it (see Scenario 7).

• Downstream Obligations: Anyone who reuses or adapts your build recipe must preserve your original copyright notice and license text. Keeping the recipe in your repository alongside the LICENSES/ folder covers this.

• Allowed Inbound Snippets: Copying build steps from other people’s recipes follows the same rules as source code. Steps from permissively licensed recipes or public domain code can be included freely, keeping their notices (Scenario 3). A non-trivial block from a copyleft project’s recipe falls under Scenario 4. In practice, most build commands are short and generic, so this rarely applies.

• In-File Identification (SPDX): Place SPDX tags as comments at the top of your Dockerfile or recipe file:

# SPDX-FileCopyrightText: 2026 Author Name <author@institute.eu>
# SPDX-License-Identifier: MIT

FROM ubuntu:24.04
RUN apt-get update && apt-get install -y python3 python3-pip
COPY solver.py /app/solver.py

In software-licensing.md:

Scenario 7: Distributing pre-built container images

You compiled and published a pre-built container image (e.g., pushing a compiled Docker image to Docker Hub, GitHub Container Registry, or an institutional registry, or sharing an Apptainer .sif file) containing an OS layer, runtime binaries, dependencies, and your application code.

• Licensing Goal: Safely distribute compiled container images without violating the license terms of any software layer or binary included inside the image.

• Legal Reality: A compiled container image is a multi-license aggregate bundle, not a single combined work. Distributing pre-built binaries makes you a distributor of every package inside, so source-availability obligations apply to the copyleft components (Linux base packages, coreutils, GPL libraries). But those packages sitting in the same filesystem as your application do not make your application a derivative of them: this is mere aggregation. Your own code keeps whatever license you chose; you simply also carry distributor obligations for the copyleft software you are shipping alongside it.

• JLA Selection Strategy: Because a container image combines multiple distinct software components, JLA is used to evaluate constituent component obligations. When distributing compiled binaries containing copyleft layers, source disclosure requirements (Disclose source) must be fulfilled for those specific layers.

Solution

What to select in the JLA interface:

1. Can Column: Select Distribute and Commercial use

2. Must Column: Select Incl. Copyright and Disclose source

3. Support Column: Select OSI approved

• JLA Outcome: No single license applies. Use JLA per component to check each one’s obligations, then record the aggregate in your image metadata.

• Aggregation covers independent programs only: Mere aggregation applies to programs that simply live side by side in the image, such as your application next to bash or coreutils. If your application actually imports or links a GPL library inside the image, that relationship is a linking question, covered by Scenario 5.

• Multi-License Aggregation Nuance: Applying a permissive license (like MIT) to your application code inside the container does not override or erase the GPL/LGPL obligations of base system packages installed in /usr/lib or /usr/bin. Distributing the built image binary makes you a distributor of all installed packages.

• What counts as distribution: Pushing an image to a public registry, or sharing an image or .sif file with people outside your organisation, is distribution. Keeping an image in a private registry used only within your own organisation is generally not. If you are unsure, treat it as distribution.

• Downstream Obligations: You must ensure downstream users can obtain the corresponding source for the copyleft components you shipped. Publishing your Dockerfile documents the build but does not by itself satisfy this the GPL asks for the source of the binaries actually distributed. In practice, most research images rely on unmodified upstream distribution packages, and pointing to the distributor’s public source archives is common practice. The exact rules differ between GPL versions, however, and many distribution packages are GPL-2.0, so for images on public registries the safest option is to keep the relevant source available yourself. If you modify or rebuild a copyleft component yourself, you must provide that source directly.

• Watch for non-redistributable software: The bigger risk in an image is often proprietary software you are not allowed to redistribute at all, such as parts of NVIDIA CUDA, Intel’s math libraries, MATLAB runtimes, or commercial solvers. Their redistribution terms are set by each vendor’s license, so check them before publishing.

• Generate a Software Bill of Materials (SBOM): Before publishing an image, use tools such as Syft or Trivy to list every package inside it, with versions and licenses. This SBOM is the complete record of what you distribute, and it shows whether any non-redistributable software is included. Consider publishing it alongside the image.

• In-File Identification (Metadata Annotations): Document the multi-license nature of the aggregate bundle using standard OCI (Open Container Initiative) image labels inside your Dockerfile. The licenses label is a summary: a base image contains many more licenses than it lists, so the SBOM remains the complete record.

# SPDX-FileCopyrightText: 2026 Author Name <author@institute.eu>
# SPDX-License-Identifier: MIT

FROM ubuntu:24.04
LABEL org.opencontainers.image.authors="author@institute.eu"
# OCI standard image annotations, displayed by registries and tools
LABEL org.opencontainers.image.title="My Research Pipeline"
# Summary only; see the published SBOM for the full list of licenses
LABEL org.opencontainers.image.licenses="MIT AND GPL-3.0-or-later"
LABEL org.opencontainers.image.vendor="My Institute Name"
LABEL org.opencontainers.image.description="Includes Ubuntu 24.04 base layers (GPL/LGPL) and custom solver (MIT)"

COPY solver.py /app/solver.py

In software-licensing.md:

Scenario 8: AI-assisted code generation

You used AI tools (e.g., GitHub Copilot, ChatGPT, Claude) to write functions, unit tests, or documentation for your research software repository.

• Licensing Goal: Apply a permissive license (MIT or Apache-2.0) to your repository with confidence, without incurring hidden copyright infringement or copyleft obligations from code the AI model reproduced from its training data.

• Legal Reality: Unmodified AI-generated outputs lack human authorship and are generally not eligible for copyright protection under current EU and international legal standards. Most real code, however, is a mix of human and AI contribution: you prompt, select, edit, and integrate. Where the line falls between AI output and your own work is unsettled and varies between Member States; there is no percentage or line-count threshold. The more you design, choose, edit, and integrate, the stronger your claim that the result is your work. Separately, if an LLM reproduces a substantial copyrighted code snippet verbatim from its training data (memorization), that output snippet retains its original copyright and license obligations.

• JLA Selection Strategy: To ensure maximum adoption and academic reuse for your overall codebase, require that your copyright notice is kept (Incl. Copyright) while avoiding share-alike constraints (leaving Copyleft/Share a. unselected), supported by automated compliance checks.

Solution

What to select in the JLA interface:

1. Can Column: Select Distribute, Modify/merge, and Commercial use

2. Must Column: Select Incl. Copyright

3. Support Column: Select OSI approved

• Example JLA Matches: MIT, Apache-2.0, BSD-3-Clause

• License your repository as normal: Your license covers everything you authored. Any purely AI-generated parts that are not protected by copyright are free to use anyway, so the license does no harm there. Many AI tools’ terms state that the output belongs to you as far as any rights exist, but a contract cannot create copyright that the law does not grant.

• Checking for memorized code: Memorization is uncommon for everyday code, but it does happen, especially for well-known code that appears many times in training data. Practical checks:

  • Be most careful with long, distinctive functions and implementations of well-known algorithms. Short boilerplate and unit tests are low risk.

  • If you use GitHub Copilot, check whether the setting that blocks suggestions matching public code is enabled for your account or organisation.

  • If a suggestion looks suspiciously polished, search for a distinctive line of it on GitHub. If it appears in a copyleft project, treat it as that project’s code (Scenario 4).

• Marking AI-generated code: Some projects and AI tool terms require contributors to disclose AI involvement via a commit trailer, a PR checkbox, or an in-file comment. Even where it is optional, marking AI-assisted sections is increasingly recommended practice: it records provenance, signals to reviewers where extra scrutiny is warranted, and makes later authorship or infringement questions much easier to resolve. Check the contribution guidelines of any project you submit to.

• Use AI to write code, not to decide licensing: As noted in the section on the limitations of AI-assisted licensing advice, AI assistants tend to apply US legal concepts. Check licensing questions against the actual license text.

• Downstream Obligations: Downstream users must preserve your copyright notice for the repository. They are free to reuse, modify, and integrate your code into commercial or open-source projects.

• Allowed Inbound Snippets: You can include permissively licensed code, public domain code (CC0), and AI-generated snippets that you have checked for verbatim reproduction of training data, as described above.

• In-File Identification (SPDX): Apply standard machine-readable SPDX tags directly at the top of your scripts, and mark AI-assisted code where it appears:

# SPDX-FileCopyrightText: 2026 Author Name <author@institute.eu>
# SPDX-License-Identifier: MIT

def filter_sensor_data(raw_readings: list[float]) -> list[float]:
    """Cleans raw sensor data (written with AI assistance and human review)."""
    return [reading for reading in raw_readings if reading > 0.0]

In software-licensing.md:

Scenario 9: Packaging AI workflows, datasets, and model weights

You are developing research software that includes source code alongside trained machine learning model weights (.pt, .safetensors) and benchmark datasets.

• Licensing Goal: Apply a clear licensing structure, with different licenses for different parts of the repository, that makes both the software source code and the non-code assets (data, weights) open and reusable under appropriate legal frameworks.

• Legal Reality: Standard software licenses (MIT, GPL) are written for source code and fit datasets and model parameters poorly. Datasets may attract the EU sui generis database right where there has been substantial investment in obtaining, verifying, or presenting their contents. Model weights are a harder case: they are the numerical values learned during training, neither code nor a database, and whether they attract any copyright protection in the EU is genuinely unsettled. Because of this uncertainty, applying an explicit license to weights is about setting clear terms for your users, not about relying on a settled legal right.

• JLA Selection Strategy: Use JLA to select an OSI-approved open-source license for the executable code component (Incl. Copyright selected), while using Creative Commons licenses (e.g., CC-BY-4.0 or CC0-1.0) for the dataset and weight files.

Solution

What to select in the JLA interface:

1. Can Column: Select Distribute, Modify/merge, and Commercial use

2. Must Column: Select Incl. Copyright

3. Support Column: Select OSI approved

• Example JLA Matches: MIT, Apache-2.0 (for the code component)

• Code vs. Data/Weights: Avoid applying software licenses like GPL or MIT to raw datasets or model weights their terms reference source code, object code, and linking, which leaves users guessing about what applies. Use CC-BY-4.0 or CC0-1.0 for non-code assets instead. CC-BY-4.0 requires credit; CC0-1.0 requires nothing, which makes it easier for data that others will combine with many other datasets. Note that this pattern is sometimes called “dual-licensing”, but that term usually means offering the same work under two licenses.

• You can only license what is yours: If your dataset contains material you did not create, such as scraped text, images, or other people’s data, your license covers only your own contribution; the original content keeps its own rights. If your dataset contains personal data, data protection rules apply regardless of the license.

• Open weights are not always open source: If you fine-tuned an existing model, its license still applies to what you built on it. Many models published with open weights come with their own licenses restricting, for example, commercial use or certain applications. Check the base model’s license before fine-tuning and publishing.

• Behavioral licenses (OpenRAIL): Licenses such as OpenRAIL impose usage restrictions (e.g., prohibiting specific harmful uses). This can be a reasonable choice, but it means they do not qualify as OSI-approved open source and will not appear in standard JLA queries.

• Downstream Obligations: Downstream users must keep your copyright notice and license text for the code (under your chosen software license) and give credit for the model weights and data as the corresponding Creative Commons license requires. For academic citation, add a CITATION.cff file to your repository.

• Allowed Inbound Assets: You may combine permissively licensed Python code with CC-BY-4.0 datasets, provided the attribution files clearly separate code licenses from data/weight licenses. Models published with open weights can be included only under the terms of their own licenses (see above).

• In-File Identification (SPDX / Licensing Structure): Binary files such as weights and datasets cannot contain comments, so REUSE marks them with a companion .license file next to each one (e.g., climate_weights.safetensors.license) or with a single REUSE.toml file covering whole folders. State in your README which license covers which folder, and fill in the license fields on platforms such as Zenodo or Hugging Face. In your code, document the structure in the header:

# SPDX-FileCopyrightText: 2026 Author Name <author@institute.eu>
# SPDX-License-Identifier: MIT
#
# Note: Source code is licensed under MIT.
# Model weights in /models/ and datasets in /data/ are licensed under CC-BY-4.0.

from safetensors.torch import load_file

def load_pipeline():
    weights = load_file("models/climate_weights.safetensors")
    return weights

Software citation

In software-citation.md:

Discussion (Citation-1): Explain how you currently cite software

• Do you cite software that you use? How?

• If I wanted to cite your code/scripts, what would I need to do?