Software licensing

Objectives

  • Knowing about what derivative work is and whether we can share it.

  • Get familiar with terminology around licensing.

  • Practical advice for software licensing.

Derivative work: Sampling/remixing

Generated image of a monk operating a record player

[Midjourney, CC-BY-NC 4.0]

Generated image of a monk operating two record players

[Midjourney, CC-BY-NC 4.0]

  • Changing and distributing software is similar to changing and distributing music

  • You can do almost anything if you don’t distribute it

Often we don’t have the choice:

  • We are expected to publish software

  • Sharing can be good insurance against being locked out

Exercise: Derivative work

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:

Derivative work and containers

(I haven’t found a discussion/paper on this so only speculating; please suggest changes/improvements)

  • Distribution of container recipes: it’s like distributing source code

  • Distribution of container images: it’s like distributing binary form

Taxonomy of software licenses

European Union Public Licence (EUPL): guidelines July 2021

European Commission, Directorate-General for Informatics, Schmitz, P., European Union Public Licence (EUPL): guidelines July 2021, Publications Office, 2021, https://data.europa.eu/doi/10.2799/77160

Comments:

  • Arrows represent compatibility (A -> B: B can reuse A)

  • Proprietary/custom: Derivative work typically not possible (no arrow goes from proprietary to open)

  • Permissive: Derivative work does not have to be shared

  • Copyleft/reciprocal: Derivative work must be made available under the same license terms

  • NC (non-commercial) and ND (non-derivative) exist for data licenses but not really for software licenses

Great resource for comparing software licenses: Joinup Licensing Assistant

If you would like to learn more about licenses, check out our slide deck: “Software licensing and open source explained with cakes”.

Exercise: Licensing situations

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?

When should I add a license?

Choose a license early in the project, even before you publish it. Later in the project it may become complicated to change it. Agreeing on a software license does not mean that you have to make it open immediately. You can also follow the “open core” approach: You don’t have to open source all your work. Core can be open and on a public branch. Unpublished code can be on a private repository.

However, we recommend to work as if the code is public even though it still may be private (thanks to E. Glerean for this great suggestion): This is to avoid surprises about code in the history with incompatible license years later when you decide to open the project.

How to add a license if your work is derivative work

Your code is derivative work if you have started from an existing code and made changes to it or if you incorporated an existing code into your code.

If your code is derivative work, then you need to check the license of the original code. Depending on the license, your choices might be limited. In this case we recommend to use these two resources:

If the original code does not have a license, you may not be able to distribute your derivative code. You can try to contact the authors and ask them to clarify the license of their code.

Practical steps for incorporating something small into your own project with a license that allows you to do so (as an example incorporating a function or two from another project):

  • Create a LICENSES/ folder in your project and “put the unmodified license text (i.e., the license text template without any copyright notices) in your LICENSES/ folder” (https://reuse.software/faq/#license-templates). This way if you reuse code from multiple projects, you can keep there multiple license files.

  • Put the code that you incorporate into a separate file or separate files. This makes it later easier to see what was incorporated, and what was written from scratch. On top of the file(s) which you have incorporated into your project add (and adapt) the following header (more examples):

    # SPDX-FileCopyrightText: 2023 Jane Doe <jane@example.com>
#
# SPDX-License-Identifier: MIT

    The REUSE initiative was started by the Free Software Foundation Europe to make licensing of software projects easier. It is OK if you prefer to not follow this strict format but the advantage of following it is that the reuse-tool makes it then easy to verify and update license headers if you have many files from different sources.

  • If it does not make sense to have several files in your project (e.g. when incorporating something into a notebook), then add a note/comment about the license and where the code came from on top of the function.

  • Although it is not dictated by the license but it can still be nice to acknowledge the incorporated functions/code in your README/documentation and to cite their work if you publish a paper about your code.

  • Some licenses are more permissive (you can keep your changes private) but some licenses require you to publish the changes (share-alike).

Practical steps for making changes to an existing project with a license that allows you to do so:

  • If the project is on GitHub or GitLab or similar, first fork the project (copy it into your user space where you can make changes).

  • For the BSD and MIT licenses you are not obliged to state your changes but it can still be helpful for others if you do. You can state your changes in the header of the files you have modified. It can be helpful to state bigger-picture changes in the README file of the project.

  • Some licenses are more permissive (you can keep your changes private) but some licenses require you to publish the changes (share-alike).

If your work is not derivative work

If you have started “from scratch”, and not used any existing code, or incorporated existing code into your code, then you may consider your code to be not derivative work.

Before you may choose a license, clarify the following points with, for example, your supervisor, collaborators, or principal investigator:

  • Does your work contract, grant, or collaboration agreement dictate a specific license?

  • Is there an intent to commercialize the code?

  • When there is unknown or mixed ownership: If there are multiple persons or organizations as owners of the code, all must agree to the license.

Do not invent your own license. Choose one of the standard licenses, otherwise compatibility is not clear:

Practical steps:

  • Create a LICENSES/ folder (example).

  • Put the unmodified license text (i.e., the license text template without any copyright notices) in plain text format into the folder (example). Here are the two above licenses in plain text: EUPL and MIT (but the latter contains a copyright notice which we rather want to have on top of files).

  • Add copyright and license information to each file following https://reuse.software/tutorial/ which uses a standard format with so-called SPDX identifiers. Example below (example):

    # SPDX-FileCopyrightText: 2023 Jane Doe <jane@example.com>
#
# SPDX-License-Identifier: EUPL-1.2

    The REUSE initiative was started by the Free Software Foundation Europe to make licensing of software projects easier. It is OK if you prefer to not follow this strict format but the advantage of following it is that the reuse-tool makes it then easy to verify and update license headers if you have many files from different sources.

  • For really small projects with one or two files the above may seem excessive and some projects choose to not have copyright information on top of their files and they only have one LICENSE file and that is OK for really small projects.

Great resources

Keypoints

  • You cannot ignore licensing: default is “no one can make copies or derivative works”.