[PATCH 0/3] Apply cryptsetup-OpenSSL-exception

[Bastian Germann]

The OpenSSL exception that was around has received a SPDX ID.
This series recovers it and applies it to my contributions.
I consent to apply it to any other GPL-licensed file that is
partly copyrighted by me.

Note that this applies the proper WITH operator in the SPDX
expression which is not around in Yocto project for historical
reasons. They apply their own expressions to SPDX IDs.
This operator still complies with the REUSE checks.

Bastian Germann (3):
Revert "Remove unused OpenSSL exception"
Rename the OpenSSL exception to the correct SPDX ID
Apply the cryptsetup-OpenSSL-exception

LICENSES/cryptsetup-OpenSSL-exception.txt | 14 ++++++++++++++
crypto/swupdate_pkcs11.h | 6 ++----
crypto/swupdate_pkcs7_verify_mbedtls.c | 2 +-
crypto/swupdate_pkcs7_verify_wolfssl.c | 2 +-
lws/Kconfig | 2 +-
lws/Makefile | 2 +-
lws/lws_interface.c | 2 +-
scripts/acceptance-tests/test_webserver.sh | 2 +-
8 files changed, 22 insertions(+), 10 deletions(-)
create mode 100644 LICENSES/cryptsetup-OpenSSL-exception.txt

[Bastian Germann]

This reverts commit b6c0adbc545675babf0a324e3410407f9d985b1e.
There is still demand for the OpenSSL exception.

Signed-off-by: Bastian Germann <ba...@debian.org>
---
LICENSES/LicenseRef-OpenSSL-Exception.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 LICENSES/LicenseRef-OpenSSL-Exception.txt

diff --git a/LICENSES/LicenseRef-OpenSSL-Exception.txt b/LICENSES/LicenseRef-OpenSSL-Exception.txt
new file mode 100644
index 00000000..a6a032c0
--- /dev/null
+++ b/LICENSES/LicenseRef-OpenSSL-Exception.txt
@@ -0,0 +1,14 @@
+GPL License Exception:
+
+In addition, as a special exception, the copyright holders give
+permission to link the code of portions of this program with the
+OpenSSL library under certain conditions as described in each
+individual source file, and distribute linked combinations
+including the two.
+You must obey the GNU General Public License in all respects
+for all of the code used other than OpenSSL. If you modify
+file(s) with this exception, you may extend this exception to your
+version of the file(s), but you are not obligated to do so. If you
+do not wish to do so, delete this exception statement from your
+version. If you delete this exception statement from all source
+files in the program, then also delete it here.

[Bastian Germann]

The OpenSSL exception used by SWUpdate has the ID cryptsetup-OpenSSL-exception.

Link: https://spdx.org/licenses/cryptsetup-OpenSSL-exception.html

Signed-off-by: Bastian Germann <ba...@debian.org>
---

...Ref-OpenSSL-Exception.txt => cryptsetup-OpenSSL-exception.txt} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename LICENSES/{LicenseRef-OpenSSL-Exception.txt => cryptsetup-OpenSSL-exception.txt} (100%)

diff --git a/LICENSES/LicenseRef-OpenSSL-Exception.txt b/LICENSES/cryptsetup-OpenSSL-exception.txt
similarity index 100%
rename from LICENSES/LicenseRef-OpenSSL-Exception.txt
rename to LICENSES/cryptsetup-OpenSSL-exception.txt

[Bastian Germann]

The SPDX specification 2.0 allows combining licenses and license expressions
using the WITH operator so they do not need to add every combination of
licenses with their exceptions.

Apply the exception the the GPL files copyrighted by Bastian Germann.

Signed-off-by: Bastian Germann <ba...@debian.org>
---

crypto/swupdate_pkcs11.h | 6 ++----
crypto/swupdate_pkcs7_verify_mbedtls.c | 2 +-
crypto/swupdate_pkcs7_verify_wolfssl.c | 2 +-
lws/Kconfig | 2 +-
lws/Makefile | 2 +-
lws/lws_interface.c | 2 +-
scripts/acceptance-tests/test_webserver.sh | 2 +-

7 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/crypto/swupdate_pkcs11.h b/crypto/swupdate_pkcs11.h
index 5658dc88..5f78cfd1 100644
--- a/crypto/swupdate_pkcs11.h
+++ b/crypto/swupdate_pkcs11.h
@@ -1,8 +1,6 @@
/*
- * (C) Copyright 2025
- * Bastian Germann
- *
- * SPDX-License-Identifier: GPL-2.0-only
+ * SPDX-FileCopyrightText: 2025 Bastian Germann
+ * SPDX-License-Identifier: GPL-2.0-only WITH cryptsetup-OpenSSL-exception
*/

#pragma once
diff --git a/crypto/swupdate_pkcs7_verify_mbedtls.c b/crypto/swupdate_pkcs7_verify_mbedtls.c
index 450d995e..b082bb6e 100644
--- a/crypto/swupdate_pkcs7_verify_mbedtls.c
+++ b/crypto/swupdate_pkcs7_verify_mbedtls.c
@@ -1,6 +1,6 @@
// SPDX-FileCopyrightText: 2026 Bastian Germann
//
-// SPDX-License-Identifier: GPL-2.0-only
+// SPDX-License-Identifier: GPL-2.0-only WITH cryptsetup-OpenSSL-exception

#include <mbedtls/version.h>
#if defined(CONFIG_SIGALG_CMS) && MBEDTLS_VERSION_NUMBER >= 0x03040000
diff --git a/crypto/swupdate_pkcs7_verify_wolfssl.c b/crypto/swupdate_pkcs7_verify_wolfssl.c
index 8473359a..7d428fc1 100644
--- a/crypto/swupdate_pkcs7_verify_wolfssl.c
+++ b/crypto/swupdate_pkcs7_verify_wolfssl.c
@@ -4,7 +4,7 @@
* (C) Copyright 2023
* Bastian Germann
*
- * SPDX-License-Identifier: GPL-2.0-only
+ * SPDX-License-Identifier: GPL-2.0-only WITH cryptsetup-OpenSSL-exception
*
* Code mostly taken from openssl examples
*/
diff --git a/lws/Kconfig b/lws/Kconfig
index 6405f8c4..00f46e65 100644
--- a/lws/Kconfig
+++ b/lws/Kconfig
@@ -1,6 +1,6 @@
# SPDX-FileCopyrightText: 2026 Bastian Germann
#
-# SPDX-License-Identifier: GPL-2.0-only
+# SPDX-License-Identifier: GPL-2.0-only WITH cryptsetup-OpenSSL-exception

config LWS
bool "libwebsockets"
diff --git a/lws/Makefile b/lws/Makefile
index 1789ffdb..7b615c5f 100644
--- a/lws/Makefile
+++ b/lws/Makefile
@@ -1,5 +1,5 @@
# SPDX-FileCopyrightText: 2026 Bastian Germann
#
-# SPDX-License-Identifier: GPL-2.0-only
+# SPDX-License-Identifier: GPL-2.0-only WITH cryptsetup-OpenSSL-exception

lib-$(CONFIG_LWS) += lws_interface.o
diff --git a/lws/lws_interface.c b/lws/lws_interface.c
index c01cf457..14595612 100644
--- a/lws/lws_interface.c
+++ b/lws/lws_interface.c
@@ -1,6 +1,6 @@
/* SPDX-FileCopyrightText: 2026 Bastian Germann
*
- * SPDX-License-Identifier: GPL-2.0-only
+ * SPDX-License-Identifier: GPL-2.0-only WITH cryptsetup-OpenSSL-exception
*/

/*
diff --git a/scripts/acceptance-tests/test_webserver.sh b/scripts/acceptance-tests/test_webserver.sh
index b75925e6..9e90049a 100755
--- a/scripts/acceptance-tests/test_webserver.sh
+++ b/scripts/acceptance-tests/test_webserver.sh
@@ -1,6 +1,6 @@
#!/bin/sh
# SPDX-FileCopyrightText: 2026 Bastian Germann
-# SPDX-License-Identifier: GPL-2.0-only
+# SPDX-License-Identifier: GPL-2.0-only WITH cryptsetup-OpenSSL-exception
#
# Integration tests for the SWUpdate webserver.
#

[Stefano Babic]

On 8/18/26 11:44, Bastian Germann wrote:
> The OpenSSL exception that was around has received a SPDX ID.
> This series recovers it and applies it to my contributions.
> I consent to apply it to any other GPL-licensed file that is
> partly copyrighted by me.

Ok, fine - after applying this, I will post patches for the other files
where I am copyright holder and issue should be solved.

Anyway:

- why crypto/swupdate_pkcs7_verify_mbedtls.c ? We compile the file
without openssl, see crypto/Kconfig.

- crypto/swupdate_pkcs7_verify_wolfssl.c - same question.

- crypto/swupdate_pkcs11.h : the reference is p11kit. The file is not
directly using OpenSSL. Do we need it here ?

Best regards,
Stefano

>
> Note that this applies the proper WITH operator in the SPDX
> expression which is not around in Yocto project for historical
> reasons. They apply their own expressions to SPDX IDs.
> This operator still complies with the REUSE checks.
>
> Bastian Germann (3):
> Revert "Remove unused OpenSSL exception"
> Rename the OpenSSL exception to the correct SPDX ID
> Apply the cryptsetup-OpenSSL-exception
>
> LICENSES/cryptsetup-OpenSSL-exception.txt | 14 ++++++++++++++
> crypto/swupdate_pkcs11.h | 6 ++----
> crypto/swupdate_pkcs7_verify_mbedtls.c | 2 +-
> crypto/swupdate_pkcs7_verify_wolfssl.c | 2 +-
> lws/Kconfig | 2 +-
> lws/Makefile | 2 +-
> lws/lws_interface.c | 2 +-
> scripts/acceptance-tests/test_webserver.sh | 2 +-
> 8 files changed, 22 insertions(+), 10 deletions(-)
> create mode 100644 LICENSES/cryptsetup-OpenSSL-exception.txt
>

--
_______________________________________________________________________
Nabla Software Engineering GmbH
Hirschstr. 111A | 86156 Augsburg | Tel: +49 821 45592596
Geschäftsführer : Stefano Babic | HRB 40522 Augsburg
E-Mail: sba...@nabladev.com

[Bastian Germann]

On 8/18/26 12:53, Stefano Babic wrote:

> On 8/18/26 11:44, Bastian Germann wrote:
>> The OpenSSL exception that was around has received a SPDX ID.
>> This series recovers it and applies it to my contributions.
>> I consent to apply it to any other GPL-licensed file that is
>> partly copyrighted by me.
>
> Ok, fine - after applying this, I will post patches for the other
> files where I am copyright holder and issue should be solved.
>
> Anyway:
>
> - why crypto/swupdate_pkcs7_verify_mbedtls.c  ? We compile the file
> without openssl, see crypto/Kconfig.
>
> -  crypto/swupdate_pkcs7_verify_wolfssl.c - same question.
>
> - crypto/swupdate_pkcs11.h : the reference is p11kit. The file is not
> directly using OpenSSL. Do we need it here ?

With the old crypto architecture where these files were mutually
exclusive with an OpenSSL configuration it would have been okay not to
add the exception. But now they are not mutually exclusive anymore.

All GPL files that can form a derivative work with OpenSSL and are
supposed to be distributed should be marked with the exception to make
it effective. I.e., all .h and .c files outside the test or tools
directories because they end up in the swupdate binary that links with
libssl.

The "viral" property of GPL-2 (no further restrictions may be introduced
with combined works) is responsible for that.

The Makefile and Kconfig changes in the 3rd commit could be removed
though but I have decided to include them for simplicity reason: The
whole lws directory is under one license with them applied.

[Stefano Babic]

Hi Bastian,

On 8/18/26 20:19, Bastian Germann wrote:
> On 8/18/26 12:53, Stefano Babic wrote:
>
>> On 8/18/26 11:44, Bastian Germann wrote:
>>> The OpenSSL exception that was around has received a SPDX ID.
>>> This series recovers it and applies it to my contributions.
>>> I consent to apply it to any other GPL-licensed file that is
>>> partly copyrighted by me.
>>
>> Ok, fine - after applying this, I will post patches for the other
>> files where I am copyright holder and issue should be solved.
>>
>> Anyway:
>>
>> - why crypto/swupdate_pkcs7_verify_mbedtls.c  ? We compile the file
>> without openssl, see crypto/Kconfig.
>>
>> -  crypto/swupdate_pkcs7_verify_wolfssl.c - same question.
>>
>> - crypto/swupdate_pkcs11.h : the reference is p11kit. The file is not
>> directly using OpenSSL. Do we need it here ?
>
> With the old crypto architecture where these files were mutually
> exclusive with an OpenSSL configuration it would have been okay not to
> add the exception. But now they are not mutually exclusive anymore.
>
> All GPL files that can form a derivative work with OpenSSL and are
> supposed to be distributed should be marked with the exception to make
> it effective. I.e., all .h and .c files outside the test or tools
> directories because they end up in the swupdate binary that links with
> libssl.

No, I disagree on this. Changes in the crypto architecture has no
influence. Even before you could have OpenSSL or not in the build, and
this does not mean that all files must be changed. The exception says
that it is allowed to link, and the result is GPLv2 + Exception, but it
does not mean that all files underlies this. In SWUpdate, each file has
an own licence, not all of them are GPLv2, there are several MIT, CC, etc.

Even if you think that the new crypto design changes something, what
about if we disable OpenSSL ? Why should files (like parser, utilities,
etc.) have an Openssl exception if they do not use OpenSSL at all ?

Nevertheless, I do not see replacing the license in all sources by
comparing other projects that has the OpenSSL exception.

>
> The "viral" property of GPL-2 (no further restrictions may be introduced
> with combined works) is responsible for that.
>
> The Makefile and Kconfig changes in the 3rd commit could be removed
> though but I have decided to include them for simplicity reason: The
> whole lws directory is under one license with them applied.

No, I do not see in this way. I agree to mark files that are obviously
using the library, and they can have maybe some code taken from OpenSSL
(I do not know myself if this is the case..) and then the exception
resolves the license issue. But not generally in all files.

Best regards,
Stefano

[OSADL]

Hi Stefano,

> With the old crypto architecture where these files were mutually
> exclusive with an OpenSSL configuration it would have been okay not to
> add the exception. But now they are not mutually exclusive anymore.
>
> All GPL files that can form a derivative work with OpenSSL and are
> supposed to be distributed should be marked with the exception to make
> it effective. I.e., all .h and .c files outside the test or tools
> directories because they end up in the swupdate binary that links with
> libssl.

No, I disagree on this. Changes in the crypto architecture has no
influence. Even before you could have OpenSSL or not in the build, and
this does not mean that all files must be changed. The exception says
that it is allowed to link, and the result is GPLv2 + Exception, but it
does not mean that all files underlies this. In SWUpdate, each file has
an own licence, not all of them are GPLv2, there are several MIT, CC, etc.

Yes, and that's fine, since all of these licenses are compatible with GPLv2 and do not have a copyleft clause themselves, so the entire binary can be distributed under GPLv2. But Bastian is right that the copyleft of the GPL is not limited to individual source code files, but encompasses the entire work (i.e. the entire binary). So if there is even one single source code file licensed as GPL without exception that is compiled into the binary which is linked to libssl, the incompatibility issue persists.

 

Even if you think that the new crypto design changes something, what
about if we disable OpenSSL ? Why should files (like parser, utilities,
etc.) have an Openssl exception if they do not use OpenSSL at all ?

Nevertheless, I do not see replacing the license in all sources by
comparing other projects that has the OpenSSL exception.

>
> The "viral" property of GPL-2 (no further restrictions may be introduced
> with combined works) is responsible for that.
>
> The Makefile and Kconfig changes in the 3rd commit could be removed
> though but I have decided to include them for simplicity reason: The
> whole lws directory is under one license with them applied.

No, I do not see in this way. I agree to mark files that are obviously
using the library, and they can have maybe some code taken from OpenSSL
(I do not know myself if this is the case..) and then the exception
resolves the license issue. But not generally in all files.

Since the copyleft clause of the GPL is not file-based, only such files that are never compiled into a binary that can be linked with libssl do not require the exception. Everything else has to carry the exception for it to be useful at all even if a given source code file does not directly use or link the library, since the object under evaluation for the GPL's copyleft is the entire binary.

Best,

Caren

 

--
Caren Kresse, Compliance and Technology Officer
Phone: +49(6221)98504-14, Fax: +49(6221)98504-814
Caren....@osadl.org

Open Source Automation Development Lab (OSADL) eG
Im Neuenheimer Feld 583, D-69120 Heidelberg, Germany
Phone: +49(6221)98504-0, Fax: +49(6221)98504-80
off...@osadl.org
http://www.osadl.org
https://youtu.be/z0MiLwP_n40

Location of the company: Heidelberg, Germany
Cooperative register #700048 at the district court of Mannheim
Chairman of the Supervisory Board: Dr. Wilfried Wessner
Directors: Jan Altenberg, Caren Kresse
Tax number 32080/02883, VAT Id-No DE249975743

[Stefano Babic]

Hi Caren,

But is this not already covered by the exception saying that linking to
OpenSSL is allowed and the resulting (derivative) work becomes GTPL2 +
Openssl Exception ?

On the other side, multiple files have GPLv2 or even MIT / BSD, etc. It
is allowed to take one SWUpdate source file and use it in own product,
but of course without changing copyright and license. That means if
someone wants to take core/utils.c from the project, and this has
nothing to do with OpenSSL, can do if the derivative product is still
GPLv2 because it is forced by my source. But if this is changed to GPLv2
+ Exception, also some derivative work will be GPLv2 + Exception, even
if it doesn't use OpenSSL at all.

I see a big difference between derivative work, that is linking to
OpenSSL and license becomes with exceptions, and single files that can
use OpenSSL or not.

If SWUpdate is built without OpenSSL support, and this is plausible, the
resulting license for all files will be GPLv2 + Exception, and this is
nonsense.

include/semver.h has a MIT license. Even if SWUpdate is GPLKv2, it is
allowed to take tjis file and include it into own products, even
commercial, and the derivative product is not GPLv2.

> So if there is
> even one single source code file licensed as GPL without exception that
> is compiled into the binary which is linked to libssl, the
> incompatibility issue persists.

Then why the exception ? The exception allows to link and sets the
derivative work, but not the single sources.

>
> Even if you think that the new crypto design changes something, what
> about if we disable OpenSSL ? Why should files (like parser, utilities,
> etc.) have an Openssl exception if they do not use OpenSSL at all ?
>
> Nevertheless, I do not see replacing the license in all sources by
> comparing other projects that has the OpenSSL exception.
>
> >
> > The "viral" property of GPL-2 (no further restrictions may be
> introduced
> > with combined works) is responsible for that.
> >
> > The Makefile and Kconfig changes in the 3rd commit could be removed
> > though but I have decided to include them for simplicity reason: The
> > whole lws directory is under one license with them applied.
>
> No, I do not see in this way. I agree to mark files that are obviously
> using the library, and they can have maybe some code taken from OpenSSL
> (I do not know myself if this is the case..) and then the exception
> resolves the license issue. But not generally in all files.
>
> Since the copyleft clause of the GPL is not file-based, only such files
> that are never compiled into a binary that can be linked with libssl do
> not require the exception. Everything else has to carry the exception
> for it to be useful at all even if a given source code file does not
> directly use or link the library, since the object under evaluation for
> the GPL's copyleft is the entire binary.

We cannot set dynamically the license on depend if SWUpdate is compiled
with OpenSSL as crypto engine or not.

Nvertheless, I do not see that other FOSS projects using OpenSSL has
changed in this way the license for the single source files (cryptsetup,
OpenVPN,..). The exception is added for the linking to OpenSSL, but it
is not propagated for the single files. So I have big concerns why this
should be done in SWUpdate only.

REUSE forced me to set also the exact license for each file, and this
leads that SWUPdate has multiple licenses, but at the end the derivative
work is GPLv2 (or GPLv2 + Exception with OpenSSL).

[OSADL gmail]

I asked our General Counsel for his opinion on the best way to add an
exception. His preferred recommendation is to add the exception to every
file that currently has a GPL-2.0-only license notice. Since the
exception refers explicitly to linking with OpenSSL and does not
otherwise alter the GPL licensing and also gives the permission to
remove the exception when changing a file, this wouldn't affect the
licensing in practice when a file is used in another project.

However, he also said, that it is possible to add the exception only in
the top level license file of the project instead of every single file
as long as it is made clear that the exception applies to all files that
are otherwise licensed GPL-2.0-only. E.g. the COPYING file could contain
a note that says something like:

"This exception to the GPL-2.0 applies to all files within this project
that are licensed as GPL-2.0-only."

In this case, the exception should *only* be added at the top level and
not to any individual files, since this implies that some GPL files are
licensed differently than others and might confuse users.

This is more along the lines of what was done before, so I hope it's
easier to implement.

However in both cases, it is absolutely necessary for the exception to
apply to every single GPL-licensed file that is compiled into the
binary. Otherwise even a single source code file with a "pure" GPL leads
to the entire work being licensed as GPL, no matter what other licenses
are included. That's the whole point of the copyleft effect (and the
reason why license compatibility is required within a project).

Best,
Caren

[Stefano Babic]

Hi Caren,

This is my preferred option - go through this path.

> E.g. the COPYING file could contain
> a note that says something like:
>
> "This exception to the GPL-2.0 applies to all files within this project
> that are licensed as GPL-2.0-only."

Ok, so we agree, we should just check how to introduce it correctly.
There is a COPYING file in SWUpdate but it is still there just for
sentimental reasons, because it wasn't ever changed and take the date of
the first commit for SWUpdate. Really, it is useless.

The file has no influence anymore because after switching to REUSE the
licenses are pointed to the LICENSES directory and recipe in YP points
just takes them, without any reference to COPYING, that has no validity.

https://github.com/sbabic/meta-swupdate/blob/master/recipes-support/swupdate/swupdate.inc#L10

LICENSE = "GPL-2.0-only & GPL-2.0-or-later & LGPL-2.1-or-later &
LGPL-2.1-only & MIT & ISC & BSD-1-Clause & BSD-3-Clause & OFL-1.1"

and the listed files are just under LICENSES.

If we add cryptsetup-OpenSSL-exception.txt, we have then a valid
SPDX-ID, but there is not the phrase suggested by your Counsel, that I
have no problem to add.

cryptsetup-OpenSSL-exception.txt contains:

"In addition, as a special exception, the copyright holders give

permission to link the code of portions of this program with the

OpenSSL library under certain conditions as described in each

individual source file, and distribute linked combinations

including the two."

Anyway, cryptsetup sources do not contain any reference to OpenSSL as
requested by your Counsel.

>
> In this case, the exception should *only* be added at the top level and
> not to any individual files, since this implies that some GPL files are
> licensed differently than others and might confuse users.
>

It is fine, but for REUSE compliance we should do something that is also
SPDX supported. I am open for suggestions. If you think that
cryptsetup-OpenSSL-exception.txt is enough, we are ready. But if I have
to add the phrase above, this is not anymore
"cryptsetup-OpenSSL-exception.txt" but
"cryptsetup-OpenSSL-exception-with-OSADL-suggestion-modified-by-stefano.txt"
and I have no SPDX-ID.

How can we solve this ?

> This is more along the lines of what was done before, so I hope it's
> easier to implement.
>

Apart the issue above, I agree, this is the path to follow.

> However in both cases, it is absolutely necessary for the exception to
> apply to every single GPL-licensed file that is compiled into the
> binary. Otherwise even a single source code file with a "pure" GPL leads
> to the entire work being licensed as GPL, no matter what other licenses
> are included. That's the whole point of the copyleft effect (and the
> reason why license compatibility is required within a project).

That is fine but then it is an issue of the companies / manufacturers
how they make usage of it, but the topic is solved inside the project.
In YP I could also make the LICENSE (that goes into SBOM) dynamic, and
adds the exception (cryptsetup-OpenSSL-exception.txt) only if
CONFIG_SSL_IMPL_OPENSSL is set.

[OSADL gmail]

Hi Stefano,

>> However, he also said, that it is possible to add the exception only
>> in the top level license file of the project instead of every single
>> file as long as it is made clear that the exception applies to all
>> files that are otherwise licensed GPL-2.0-only.
>
> This is my preferred option - go through this path.
>

Ok.

>> E.g. the COPYING file could contain a note that says something like:
>>
>> "This exception to the GPL-2.0 applies to all files within this
>> project that are licensed as GPL-2.0-only."
>
> Ok, so we agree, we should just check how to introduce it correctly.
> There is a COPYING file in SWUpdate but it is still there just for
> sentimental reasons, because it wasn't ever changed and take the date of
> the first commit for SWUpdate. Really, it is useless.
>
> The file has no influence anymore because after switching to REUSE the
> licenses are pointed to the LICENSES directory and recipe in YP points
> just takes them, without any reference to COPYING, that has no validity.
>

I don't think the COPYING file is useless, because any users that are
not familiar with REUSE would take this as the main information for
licensing. So I think it is a good place to add an exception (in
addition to the LICENSES directory) and maybe even the note I suggested,
to make it clear what you intend without breaking REUSE standards.

> https://github.com/sbabic/meta-swupdate/blob/master/recipes-support/

> swupdate/swupdate.inc#L10
>
> LICENSE = "GPL-2.0-only & GPL-2.0-or-later & LGPL-2.1-or-later &
> LGPL-2.1-only & MIT & ISC & BSD-1-Clause & BSD-3-Clause & OFL-1.1"
>
> and the listed files are just under LICENSES.
>
> If we add cryptsetup-OpenSSL-exception.txt, we have then a valid SPDX-
> ID, but there is not the phrase suggested by your Counsel, that I have
> no problem to add.
>
> cryptsetup-OpenSSL-exception.txt contains:
>
> "In addition, as a special exception, the copyright holders give
> permission to link the code of portions of this program with the
> OpenSSL library under certain conditions as described in each
> individual source file, and distribute linked combinations
> including the two."
>
> Anyway, cryptsetup sources do not contain any reference to OpenSSL as
> requested by your Counsel.
>

I don't understand what you're missing. cryptsetup-OpenSSL-exception
refers to OpenSSL explicitly in two places: "link the code of portions
of this program with the OpenSSL library" and "You must obey the GNU
General Public License in all respects for all of the code used other
than OpenSSL". Do you require anything else?

Of course, we can still wait for the reaction of the SPDX legal team to
a suggestion for a generic OpenSSL exception. There's no hurry :-)

>>
>> In this case, the exception should *only* be added at the top level
>> and not to any individual files, since this implies that some GPL
>> files are licensed differently than others and might confuse users.
>>
>
> It is fine, but for REUSE compliance we should do something that is also
> SPDX supported. I am open for suggestions. If you think that cryptsetup-
> OpenSSL-exception.txt is enough, we are ready. But if I have to add the
> phrase above, this is not anymore "cryptsetup-OpenSSL-exception.txt" but
> "cryptsetup-OpenSSL-exception-with-OSADL-suggestion-modified-by-
> stefano.txt" and I have no SPDX-ID.
>
> How can we solve this ?
>

The additional note that I suggested above is not part of the license
text and therefore does not require to alter the SPDX ID. It is simply a
note to explain how the given license notices are to be applied. It can
be given for example in the README or as suggested above in the COPYING
file.

The licenses listed in
https://github.com/sbabic/meta-swupdate/blob/master/recipes-support/swupdate/swupdate.inc#L10
should then read

LICENSE = "GPL-2.0-only WITH cryptsetup-OpenSSL-exception &
GPL-2.0-or-later WITH cryptsetup-OpenSSL-exception & LGPL-2.1-or-later &

LGPL-2.1-only & MIT & ISC & BSD-1-Clause & BSD-3-Clause & OFL-1.1

That's it.

>> This is more along the lines of what was done before, so I hope it's
>> easier to implement.
>>
>
> Apart the issue above, I agree, this is the path to follow.
>

Ok.

>> However in both cases, it is absolutely necessary for the exception to
>> apply to every single GPL-licensed file that is compiled into the
>> binary. Otherwise even a single source code file with a "pure" GPL
>> leads to the entire work being licensed as GPL, no matter what other
>> licenses are included. That's the whole point of the copyleft effect
>> (and the reason why license compatibility is required within a project).
>
> That is fine but then it is an issue of the companies / manufacturers
> how they make usage of it, but the topic is solved inside the project.
> In YP I could also make the LICENSE (that goes into SBOM) dynamic, and
> adds the exception (cryptsetup-OpenSSL-exception.txt) only if
> CONFIG_SSL_IMPL_OPENSSL is set.
>

That basically implements the wording of the exception in practice,
since it is not valid if OpenSSL is not linked. Would be nice, but not
absolutely necessary :-)

Best,
Caren

[Stefano Babic]

Hi Caren,

On 8/20/26 11:43, OSADL gmail wrote:
> Hi Stefano,
>
>>> However, he also said, that it is possible to add the exception only
>>> in the top level license file of the project instead of every single
>>> file as long as it is made clear that the exception applies to all
>>> files that are otherwise licensed GPL-2.0-only.
>>
>> This is my preferred option - go through this path.
>>
> Ok.
>
>>> E.g. the COPYING file could contain a note that says something like:
>>>
>>> "This exception to the GPL-2.0 applies to all files within this
>>> project that are licensed as GPL-2.0-only."
>>
>> Ok, so we agree, we should just check how to introduce it correctly.
>> There is a COPYING file in SWUpdate but it is still there just for
>> sentimental reasons, because it wasn't ever changed and take the date
>> of the first commit for SWUpdate. Really, it is useless.
>>
>> The file has no influence anymore because after switching to REUSE the
>> licenses are pointed to the LICENSES directory and recipe in YP points
>> just takes them, without any reference to COPYING, that has no validity.
>>
> I don't think the COPYING file is useless, because any users that are
> not familiar with REUSE would take this as the main information for
> licensing.

COPYING is just a copy of GPLv2, and it is missing other licenses like
LGPLv2.1 for the library. If someone is not aware of REUSE, there is a
big LICENSES directory with all licenses listed.

> So I think it is a good place to add an exception (in
> addition to the LICENSES directory) and maybe even the note I suggested,
> to make it clear what you intend without breaking REUSE standards.
>
>> https://github.com/sbabic/meta-swupdate/blob/master/recipes-support/
>> swupdate/swupdate.inc#L10
>>
>> LICENSE = "GPL-2.0-only & GPL-2.0-or-later & LGPL-2.1-or-later &
>> LGPL-2.1-only & MIT & ISC & BSD-1-Clause & BSD-3-Clause & OFL-1.1"
>>
>> and the listed files are just under LICENSES.
>>
>> If we add cryptsetup-OpenSSL-exception.txt, we have then a valid SPDX-
>> ID, but there is not the phrase suggested by your Counsel, that I have
>> no problem to add.
>>
>> cryptsetup-OpenSSL-exception.txt contains:
>>
>> "In addition, as a special exception, the copyright holders give
>> permission to link the code of portions of this program with the
>> OpenSSL library under certain conditions as described in each
>> individual source file, and distribute linked combinations
>> including the two."
>>
>> Anyway, cryptsetup sources do not contain any reference to OpenSSL as
>> requested by your Counsel.
>>
> I don't understand what you're missing. cryptsetup-OpenSSL-exception
> refers to OpenSSL explicitly in two places: "link the code of portions
> of this program with the OpenSSL library" and "You must obey the GNU
> General Public License in all respects for all of the code used other
> than OpenSSL". Do you require anything else?

Not me - your Counsel wants ""This exception to the GPL-2.0 applies to
all files within this project that are licensed as GPL-2.0-only." and I
do not find anything similar in cryptsetup or other GPLv2 projects
linking to OpenSSL.

>
> Of course, we can still wait for the reaction of the SPDX legal team to
> a suggestion for a generic OpenSSL exception. There's no hurry :-)

Fine with me - so we will do just once. And if we will not have a clear
answer, we can go on with what we agreed here.

>
>>>
>>> In this case, the exception should *only* be added at the top level
>>> and not to any individual files, since this implies that some GPL
>>> files are licensed differently than others and might confuse users.
>>>
>>
>> It is fine, but for REUSE compliance we should do something that is
>> also SPDX supported. I am open for suggestions. If you think that
>> cryptsetup- OpenSSL-exception.txt is enough, we are ready. But if I
>> have to add the phrase above, this is not anymore "cryptsetup-OpenSSL-
>> exception.txt" but "cryptsetup-OpenSSL-exception-with-OSADL-
>> suggestion-modified-by- stefano.txt" and I have no SPDX-ID.
>>
>> How can we solve this ?
>>
> The additional note that I suggested above is not part of the license
> text and therefore does not require to alter the SPDX ID.

Ah !

> It is simply a
> note to explain how the given license notices are to be applied. It can
> be given for example in the README or as suggested above in the COPYING
> file.

README is a nice place - everyone notices this and it is on the start
page of the project. No problem to change this and add the note to the
README, I think it is a better place than COPYING.

>
> The licenses listed in https://github.com/sbabic/meta-swupdate/blob/
> master/recipes-support/swupdate/swupdate.inc#L10 should then read
>
> LICENSE = "GPL-2.0-only WITH cryptsetup-OpenSSL-exception & GPL-2.0-or-
> later WITH cryptsetup-OpenSSL-exception & LGPL-2.1-or-later & LGPL-2.1-
> only & MIT & ISC & BSD-1-Clause & BSD-3-Clause & OFL-1.1
>
> That's it.

Yes, agreed.

>
>>> This is more along the lines of what was done before, so I hope it's
>>> easier to implement.
>>>
>>
>> Apart the issue above, I agree, this is the path to follow.
>>
> Ok.
>
>>> However in both cases, it is absolutely necessary for the exception
>>> to apply to every single GPL-licensed file that is compiled into the
>>> binary. Otherwise even a single source code file with a "pure" GPL
>>> leads to the entire work being licensed as GPL, no matter what other
>>> licenses are included. That's the whole point of the copyleft effect
>>> (and the reason why license compatibility is required within a project).
>>
>> That is fine but then it is an issue of the companies / manufacturers
>> how they make usage of it, but the topic is solved inside the project.
>> In YP I could also make the LICENSE (that goes into SBOM) dynamic, and
>> adds the exception (cryptsetup-OpenSSL-exception.txt) only if
>> CONFIG_SSL_IMPL_OPENSSL is set.
>>
> That basically implements the wording of the exception in practice,
> since it is not valid if OpenSSL is not linked. Would be nice, but not
> absolutely necessary :-)

Ok

So we just wait for an answer from SPDX, but IMHO we can add the note to
README and the cryptsetup exception into LICENSES.

[OSADL gmail]

Hi Stefano,

> So we just wait for an answer from SPDX, but IMHO we can add the note to
> README and the cryptsetup exception into LICENSES.
>

Ok, let's wait and see which exception it will be.

Best,
Caren