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

• Regional Focus: Guidance is grounded in EU statutory directives, European institutional frameworks and developers based in Europe with a global focus.

• 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 references below and legal experts, especially if you have legal services at your host institute, could be of help:

• 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:

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 have not bundled third-party code inside your repository, you hold full copyright over your original codebase.

• JLA Selection Strategy: To ensure downstream users must acknowledge your original authorship while granting them maximum flexibility to incorporate your code into both open and proprietary software, you require citation credit (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. However, under EU civil law, authors cannot legally give up their moral rights (droit moral). Selecting an explicit permissive license like MIT or Apache-2.0 grants broad permissions globally, remains legally valid under European copyright law, and guarantees academic citation credit.

• 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: If you want to include small third-party code snippets in your files, you can freely embed code licensed under permissive terms (e.g., MIT, BSD, Apache-2.0, 0BSD) or public domain waivers (CC0) without affecting your permissive license. However, embedding copyleft snippets (e.g., GPL, EUPL) will trigger reciprocal obligations, forcing your entire repository to be re-licensed under those copyleft terms.

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

# SPDX-License-Identifier: MIT
# Copyright (c) 2026 Author Name <author@institute.eu>

import numpy as np

In software-licensing.md:

Scenario 2: Implementing mathematical models with copyleft obligations

You developed a custom mathematical solver implementing algorithms from academic literature. You want to ensure that any downstream improvements, extensions, or modifications made by others remain open-source and are shared back with the scientific community.

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

• Legal Reality: Mathematical concepts and formulas themselves are not copyrightable, but your specific code implementation is fully protected by copyright. Applying a copyleft license legally binds anyone who distributes modified versions of your implementation to release their source code under matching reciprocal terms.

• JLA Selection Strategy: To enforce reciprocal sharing, you must mandate that downstream distributors disclose their modified source code (Disclose source) and license their derivative 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), includes built-in compatibility clauses with GPL, and explicitly defaults to EU Member State jurisdiction and courts.

• 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.

• Allowed Inbound Snippets: You can freely embed code snippets licensed under permissive terms (e.g., MIT, Apache-2.0, BSD) or public domain waivers (CC0). You may also embed snippets from compatible copyleft code (e.g., EUPL, GPL). However, you cannot embed closed-source or proprietary code snippets.

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

# SPDX-License-Identifier: EUPL-1.2
# Copyright (c) 2026 Author Name <author@institute.eu>

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 attribution 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, select citation obligations (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. If you copy code from an Apache-2.0 or BSD-3-Clause project into your MIT-licensed repository, you must retain the original author’s copyright statement and license identifier directly above the embedded code block.

• 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). You cannot embed copyleft code (e.g., GPL, EUPL) without upgrading your entire repository’s license to match that copyleft license.

• In-File Identification (SPDX): Mark both your overall file license and the specific embedded snippet using SPDX comments:

# SPDX-License-Identifier: MIT
# Copyright (c) 2026 Author Name <author@institute.eu>

# --- Embedded Third-Party Snippet ---
# SPDX-License-Identifier: Apache-2.0
# Copyright (c) 2024 External Contributor <dev@external-lib.org>
def fast_matrix_solver(matrix):
    # Embedded algorithm implementation
    return np.linalg.solve(matrix, np.eye(len(matrix)))
# --- End Embedded Snippet ---

def main():
    pass

In software-licensing.md:

Scenario 4: Embedding copyleft third-party code

You are building an 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.

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

• Legal Reality: Copyleft licenses require that any work containing copyleft code must be shared under a compatible copyleft license as a whole. Embedding copyleft code directly into your repository creates a single combined work, making copyleft licensing mandatory for your entire project.

• JLA Selection Strategy: Because the inbound copyleft code forces your repository to adopt reciprocal sharing terms, you must 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

• Copyleft Scope & EUPL Compatibility (Legal Nuance): Directly copying copyleft code into your source files extends the copyleft obligation to your entire codebase. If the embedded snippet is EUPL-1.2, its built-in compatibility provisions allow you to license your combined project under GPL-3.0 if your project ecosystem requires it, resolving license conflicts without violating EUPL terms.

• Downstream Obligations: Anyone who receives, modifies, or distributes your repository must receive full access to the source code under the same copyleft license terms (GPL-3.0 or EUPL-1.2) and preserve all copyright notices.

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

• In-File Identification (SPDX): Mark your overall file license and clearly cite the embedded copyleft snippet using SPDX comments:

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

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

def main():
    pass

In software-licensing.md:

Scenario 5: Linking against a GPL-licensed library

You are developing an 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: Under mainstream copyright interpretation and the text of GPL-3.0, linking your code directly against a GPL library (whether statically or dynamically) creates a combined work. Consequently, the copyleft obligations of the external library extend to your entire repository.

• JLA Selection Strategy: Because linking to a GPL library requires your distributed project to be released under matching reciprocal terms, you must configure JLA to mandate 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

• Linking Boundaries & License Selection (Legal Nuance):

  • Why GPL forces copyleft: Linking against a standard GPL-3.0 library extends copyleft to your entire project. Your repository must adopt a compatible copyleft license (GPL-3.0 or EUPL-1.2, which explicitly lists GPL-3.0 in its compatibility appendix).

  • Why LGPL or EUPL-1.2 libraries allow permissive licenses: If the external library is licensed under LGPL (which includes an explicit linking exception) or EUPL-1.2 (where European Commission guidance takes the position that dynamically linking an EUPL work through its API does not by itself create a derivative work), copyleft does not extend to your application. In these dynamic linking scenarios, your own project can stay permissively licensed (e.g., MIT, Apache-2.0, BSD). However, note that this EUPL stance reflects Commission guidance rather than settled CJEU case law, and static linking or direct code incorporation continues to trigger EUPL copyleft obligations.

• Downstream Obligations: Downstream users who receive or run your application must receive full access to your source code under GPL-3.0 (or EUPL-1.2), along with all upstream copyright notices and build scripts required to recompile the project.

• 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.

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

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

import gpl_licensed_solver  # External GPL dependency forces GPL/EUPL compliance

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, 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 execution time. You hold copyright over the unique build instructions you write in the Dockerfile.

• JLA Selection Strategy: To allow anyone to reuse or adapt your container recipe without restrictions, you require citation credit (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

• 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. A permissively licensed Dockerfile can install both permissive and copyleft packages without legal conflict.

• Downstream Obligations: Anyone who reuses or adapts your build recipe must preserve your original copyright notice in the header of the recipe file.

• Allowed Inbound Snippets: You can freely include build commands and code snippets from permissively licensed build scripts or public domain code.

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

# SPDX-License-Identifier: MIT
# Copyright (c) 2026 Author Name <author@institute.eu>

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) 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. Distributing pre-built binaries triggers source-code distribution obligations for any copyleft software (e.g., Linux base packages, coreutils, GPL libraries) pre-installed inside the image layers.

• 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

• Example JLA Matches: Multi-License Bundle (Governed by constituent package terms)

• 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.

• Downstream Obligations: You must ensure that downstream users can obtain the source code for copyleft components shipped inside the image, typically by publishing the Dockerfile and build steps used to generate the image from public upstream sources.

• Allowed Inbound Packages: Before publishing an image binary, run automated compliance scanning tools (e.g., Syft, Trivy) to generate a Software Bill of Materials (SBOM) and verify that no non-redistributable or proprietary software is packaged inside.

• 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:

# SPDX-License-Identifier: MIT
# Copyright (c) 2026 Author Name <author@institute.eu>

FROM ubuntu:24.04
LABEL org.opencontainers.image.authors="author@institute.eu"
# OCI Standard Image Annotations for Docker Hub Compliance
LABEL org.opencontainers.image.title="My Research Pipeline"
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: Retain clear ownership and apply a permissive license (MIT or Apache-2.0) to your repository without incurring hidden copyright infringement or copyleft obligations from code embedded during model training.

• Legal Reality: Unmodified AI-generated outputs lack human authorship and are generally not eligible for copyright protection under current EU and international legal standards. However, 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 citation credit (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

• AI Code Generation & Verification Nuance: Because non-human AI output cannot hold copyright, your copyright applies to the overall project structure, human-written logic, and creative choices. To protect your repository against accidental copyright infringement or copyleft contamination from AI memorization, turn on public code matching filters in your AI tools and run automated code-similarity scanners before releasing your repository.

• 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 have been verified against verbatim training data duplication.

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

# SPDX-License-Identifier: MIT
# Copyright (c) 2026 Author Name <author@institute.eu>

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 dual-licensing strategy that makes both the software source code and the non-code assets (data, weights) open and reusable under appropriate legal frameworks.

• Legal Reality: Standard open-source software licenses (MIT, GPL) are written specifically for source code and are legally ill-suited for datasets or neural network parameters. Under EU legal frameworks, datasets and model weights are governed by database rights (sui generis database protection) rather than traditional code copyright.

• 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) 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 & OpenRAIL Nuance: Never apply software licenses like GPL or MIT to raw datasets or model weights. Use CC-BY-4.0 or CC0 for non-code assets. Additionally, behavioral licenses (such as OpenRAIL) impose usage restrictions (e.g., prohibiting specific harmful uses), which means they do not qualify as OSI-approved open-source software and cannot be filtered via standard JLA open-source queries.

• Downstream Obligations: Downstream users must cite your repository for the code (under your chosen software license) and give credit for the model weights and data under the corresponding Creative Commons license.

• Allowed Inbound Assets: You may combine permissively licensed python code with CC-BY-4.0 datasets or open-weight models, provided the attribution files clearly separate code licenses from data/weight licenses.

• In-File Identification (SPDX / Dual-Licensing Structure): Document the dual-licensing scheme in your root repository structure and script headers:

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

import torch

def load_pipeline():
    model = torch.load("models/climate_weights.safetensors")
    return model

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?

OLD Software licensing

In software-licensing-old.md:

Licensing-1: What constitutes derivative work?

This question 5 below can be used as a starting point and copied to the collaborative document or form input for an online poll:

## Question 5: Which of these are derivative works?

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

- A. Download some code from a website and add on to it
  - votes:

- B. Download some code and use one of the functions in your code
  - votes:

- C. Changing code you got from somewhere
  - votes:

- D. Extending code you got from somewhere
  - votes:

- E. Completely rewriting code you got from somewhere
  - votes:

- F. Rewriting code to a different programming language
  - votes:

- G. Linking to libraries (static or dynamic), plug-ins, and drivers
  - votes:

- H. Clean room design (somebody explains you the code but you have never seen it)
  - votes:

- I. You read a paper, understand algorithm, write own code
  - votes:

Solution

• Derivative work: A-F

• Not derivative work: G-I

• E and F: This depends on how you do it, see clean room design.

In software-licensing-old.md:

Licensing-2: Consider some common licensing situations

1. What is the StackOverflow license for code you copy and paste?

2. A journal requests that you release your software during publication. You have copied a portion of the code from another package, which you have forgotten. Can you satisfy the journal’s request?

3. You want to fix a bug in a project someone else has released, but there is no license. What risks are there?

4. How would you ask someone to add a license?

5. You incorporate MIT, GPL, and BSD3 licensed code into your project. What possible licenses can you pick for your project?

6. You do the same as above but add in another license that looks strong copyleft. What possible licenses can you use now?

7. Do licenses apply if you don’t distribute your code? Why or why not?

8. Which licenses are most/least attractive for companies with proprietary software?

Solution

1. As indicated here, all publicly accessible user contributions are licensed under Creative Commons Attribution-ShareAlike license. See Stackoverflow Terms of service for more detailed information.

2. “Standard” licensing rules apply. So in this case, you would need to remove the portion of code you have copied from another package before being able to release your software.

3. By default you are no authorized to use the content of a repository when there is no license. And derivative work is also not possible by default. Other risks: it may not be clear whether you can use and distribute (publish) the bugfixed code. For the repo owners it may not be clear whether they can use and distributed the bugfixed code. However, the authors may have forgotten to add a license so we suggest you to contact the authors (e.g. make an issue) and ask whether they are willing to add a license.

4. As mentionned in 3., the easiest is to fill an issue and explain the reasons why you would like to use this software (or update it).

5. Combining software with different licenses can be tricky and it is important to understand compatibilities (or lack of compatibilities) of the various licenses. GPL license is the most protective (BSD and MIT are quite permissive) so for the resulting combined software you could use a GPL license. However, re-licensing may not be necessary.

6. Derivative work would need to be shared under this strong copyleft license (e.g. AGPL or GPL), unless the components are only plugins or libraries.

7. If you keep your code for yourself, you may think you do not need a license. However, remember that in most companies/universities, your employer is “owning” your work and when you leave you may not be allowed to “distribute your code to your future self”. So the best is always to add a license!

8. The least attractive licenses for companies with proprietary software are licenses where you would need to keep an open license when creating derivative work. For instance GPL and and AGPL. The most attractive licenses are permissive licenses where they can reuse, modify and relicense with no conditions. For instance MIT, BSD and Apache License.