#1036110 qemu-system-*: license conflict with libsasl2

Package:
src:qemu
Source:
src:qemu
Submitter:
Bastian Germann
Date:
2023-08-01 14:57:02 UTC
Severity:
normal
Tags:
#1036110#5
Date:
2023-05-15 16:49:22 UTC
From:
To:
Hi,

the qemu-system-* binaries depends on libsasl2-2, which is licensed under CMU's BSD-3-Clause-Attribution license and
covered by the RSA-MD license. They have clauses in place, which are known to be incompatible with GPL (as far as I can
see the mentioned binaries' license). There are several possible solutions to this problem:

1) Build without VNC SASL support. Just get rid of the Build-Dependency libsasl2-dev.

2) Support my request at #996892.

3) Ask upstream to add a license exception for libsasl2-2, similar to the one that was required by Debian for OpenSSL
for a long time.

Thanks for your consideration,
Bastian
#1036110#10
Date:
2023-05-15 17:15:49 UTC
From:
To:
15.05.2023 19:49, Bastian Germann wrote:

Can you be a bit more specific please, about the "known to be incompatible" part?
Known to whom? Can this knowledge be shared?

Again, can you please provide a bit more context here,  which exception are you talking
about, exactly? Maybe some particular wording example?

It's quite sad this issue has popped up this close to the release.
This condition has been here forever, marking as found in 3.0 (arbitrary).

Thanks,

/mjt
#1036110#21
Date:
2023-05-15 17:50:46 UTC
From:
To:
15.05.2023 19:49, Bastian Germann wrote:


I'm not a licensing expert.  Here's a personal opinion of one of
the QEMU developers (and note this attribution, not advertising):

<danpb> mjt: mho clause 4 attribution is satisfied by simply always providing
         the full corresponding source tarball alongside the binary tarball,
         or by including the license file text in the binary dist
<danpb> the attribution clause looks unpleasant, but imho it is defanged by
         not giving any specific rules about /how/ you must attribute them
<danpb> the original BSD-4 clause was a serious problem because it specifically
         mentioned "All advertising materials mentioning features or use of this
         software"
<danpb> IOW, it proscribed a specific rule for how you must attribute

(Just another point of view here).
#1036110#26
Date:
2023-05-15 17:50:46 UTC
From:
To:
15.05.2023 19:49, Bastian Germann wrote:


I'm not a licensing expert.  Here's a personal opinion of one of
the QEMU developers (and note this attribution, not advertising):

<danpb> mjt: mho clause 4 attribution is satisfied by simply always providing
         the full corresponding source tarball alongside the binary tarball,
         or by including the license file text in the binary dist
<danpb> the attribution clause looks unpleasant, but imho it is defanged by
         not giving any specific rules about /how/ you must attribute them
<danpb> the original BSD-4 clause was a serious problem because it specifically
         mentioned "All advertising materials mentioning features or use of this
         software"
<danpb> IOW, it proscribed a specific rule for how you must attribute

(Just another point of view here).
#1036110#31
Date:
2023-05-15 18:17:15 UTC
From:
To:
15.05.2023 20:50, Michael Tokarev wrote:

Also for the RSA-MD license (which has stronger attribution clause), the 4 files
in cyrus-sasl which are covered by it should just be deleted and replaced with equivalent
implementations which is done by everyone else.

/mjt
#1036110#36
Date:
2023-08-01 14:54:23 UTC
From:
To:
Control: severity -1 important
This was done in the latest cyrus-sasl2 package version. As RSA-MD was the strong offender and the
case is not as clear cut for BSD-3-Clause-Attribution, I am lowering the severity.