Hello all
I am circulating some recent advice from an open‑source lawyer
(who I cannot name due to the Chatham House rule) on the open
licensing of software configuration files. The term
"work" here is legal jargon for an artifact potentially subject
to copyright and allied rights protection.
"I have provided guidance to projects to explicitly not publish configuration files as part of the work but as separate works and to treat this separate works as data that is read into the covered work at runtime"
So that means that, for instance, a python‑based snakemake file should be released under say a Creative Commons CC‑BY‑4.0 content license and not under your main codebase software license (which may be anything from MIT to AGPL‑3.0‑or‑later). Such files may be in the same repo though — while noting that some projects run distinct repos for their core code and for their associated workflow processing pipelines (for example, PyPSA and PyPSA‑Earth, respectively).
The Linux Foundation maintain a list of SPDX pubic license identifiers:
Only Open Source Initiative (OSI)
approved software licenses should be applied to source code.
If anyone has experiences to share,
please do so.
kia ora, Robbie
-- Robbie Morrison Address: Schillerstrasse 85, 10627 Berlin, Germany Phone: +49.30.612-87617
Hello all
This discussion is quite technical and probably of limited
interest.
First thanks to those (KG,JH,TN) who replied to me directly and pointed out that snakemake would class as code. My experience ended with classic make, which simply articulates sets of rules and would likely be regarded as data.
Some more backstory. The discussion is directed to the AGPL‑3.0‑*
license. That license often applies to projects developing code
that could be run from remote servers and based on
software‑as‑a‑service (SaaS) architectures. If you don't deploy
that particular license, then you can probably stop reading.
The AGPL‑3.0‑*
requires operators to convey their corresponding
source, also any modifications, on user request. That same
license defines "installation information" as "any methods,
procedures, authorization keys, or other information required to
install and execute modified versions of a covered work" and
requires that be provided too. So questions arise as what to do
when your configuration information contains security‑related
and/or private details. The open source lawyers I know would
naturally resist providing those details on request, of course.
One option is to carve out those details to dedicated data files
and treat them as a separate work — thereby
avoiding the need to reveal them on request under the terms of the
AGPL‑3.0‑*
. And then license them or not as you wish.
To my knowledge, just SIREN, open_plan, and (possibly) energyRt (from EDF) use an AGPL. With one other data pipeline project considering moving to that license mid this year too.
sorry for any confusion, with best wishes, Robbie
--
You received this message because you are subscribed to the Google Groups "openmod initiative" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openmod-initiat...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openmod-initiative/aafdaf63-2dcf-d221-2674-95f9277efd04%40posteo.de.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openmod-initiative/74190811-d705-aa5b-264d-d139bfed5f6a%40posteo.de.
Hi all
Johnannes is right, the REUSE system provides a good strategy in most cases. I will use the legal term "work" to describe the various entities under various licenses and authorships.
Under REUSE, the relevant licensed texts are
first added to the root directory and then each text‑based file
gets a license notice which points to one of the
license texts just mentioned. That procedure then distinguishes
each work implicitly. Those files too trivial to handle, like .gitignore
,
receive a Creative Commons CC0‑1.0 public domain wavier instead,
something like:
# Waiver: To the extent possible under law, [Author] has waived all copyright and related or neighboring rights to this [configuration file]. http://creativecommons.org/publicdomain/zero/1.0/
The corner case of when two different works use the same
license is not covered by REUSE (as best I can tell)
except by resorting to SPDX-FileCopyrightText
field
in each file. And even then, that might not be sufficient to
provide disaggregation. It also seems rather brittle as a
strategy.
I am currently following up this question elsewhere and can hopefully provide an update in due course.
with best wishes, Robbie
Hi all
A follow‑up as promised. The more
general issue is the normally poor state of legacy code,
rather than the mechanics of licensing and license notices. One
computer scientist opined thus (provided under the Chatham House
rule so their name must necessary remain hidden, also with some
light copy‑editing):
The problem at hand is to perform a 'due diligence' on a large code base developed over decades to sort out, for each distinct component (or we can call it 'work' if you like), the chain of rights, with the goal to open source it.
This is a huge undertaking that I'm sure a few people in this [legal network community] have unfortunately faced before — a notable former example is moving Netscape Navigator to Mozilla Firefox. Inria in France, as an example from academia, has experience with similar beasts, and the one I have in mind took two years and special tooling to sort out.
I fear that using the different declared licenses in the source code files to infer where they belong may seem a nice idea, but in general it's far from sufficient, and it will be a rough ride to get to the end.
Since the due diligence work will be expensive to do, one could suggest to take this occasion to check whether the result of the process may be to get a single 'work' under a single choice of license, to make it simpler to move forward once this dish of spaghetti is released, instead of finding tricky ways of keeping inside a single repository different 'works' and tracking their rights with some extra metadata here and there.
The REUSE
project does not support two or more components (or works to
use the legal concept) under the same license type. I guess that
project aims to tread some line between simplicity and
functionality. But REUSE does support code under say MIT or
Apache‑2.0, documentation under say CC‑BY‑4.0, and configuration
files under say CC0‑1.0, but nothing more complex. As Johannes
indicated for the PyPSA project.
A corollary would be: when dealing with new or recent
projects, plan your software architectures and open
licensing strategies with considerable care and then maintain
discipline!
with best wishes, Robbie
To unsubscribe from this group and stop receiving emails from it, send an email to openmod-initiat...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openmod-initiative/76e0071e-4859-9c20-0f38-9e3a9d88c261%40posteo.de.
To view this discussion on the web, visit https://groups.google.com/d/msgid/openmod-initiative/154cb76d-6880-13af-f90c-fd949b9300d2%40posteo.de.