You are not logged in.
I've checked the /usr/lib/libcurl-gnutls.so.4.8.0 library on my filesystem with ldd, and it appears to be linked to libssl.so.1.1 (openssl)
From what I understand, the purpose of libcurl-gnutls is *not* to be linked against openssl, to allow GPL 2 program to use it, since they can't use openssl because of licensing issues
On Ubuntu (tested on 22.04), it seems not to be linked to libssl
Is this a wanted behavior ? If so, why ?
Offline
... to allow GPL 2 program to use it, since they can't use openssl because of licensing issues
This is incorrect. Any GPL program can link to openssl as it's licensed permissively. Though if this were not correct, libcurl-gnutls would be an issue itself as it is also licensed permissively (not GPL).
A GPL licensed project can link to permissively-licensed libraries (e.g., BSD or MIT) it's only the reverse that can be an issue.
Last edited by Trilby (2022-07-11 00:42:17)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
The section of the build for libcurl-gnutls
# build libcurl-gnutls
cd "${srcdir}"/build-curl-gnutls
"${srcdir}/${pkgbase}-${pkgver}"/configure \
"${_configure_options[@]}" \
--disable-versioned-symbols \
--without-ssl \
--with-gnutls='/usr'
sed -i -e 's/ -shared / -Wl,-O1,--as-needed\0/g' libtool
make -C lib
}
Which produces this configure listing
configure: Configured to build curl/libcurl:
Host setup: x86_64-pc-linux-gnu
Install prefix: /usr
Compiler: gcc
CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -g -ffile-prefix-map=/build/curl/src=/usr/src/debug -flto=auto -Werror-implicit-function-declaration -Wno-system-headers
CPPFLAGS:
LDFLAGS: -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto=auto -L/usr/lib
LIBS: -lnghttp2 -lidn2 -lssh2 -lssh2 -lpsl -lnettle -lgnutls -lssl -lcrypto -lssl -lcrypto -lgssapi_krb5 -lzstd -lbrotlidec -lz
curl version: 7.84.0
SSL: enabled (OpenSSL, GnuTLS)
SSH: enabled (libSSH2)
zlib: enabled
brotli: enabled (libbrotlidec)
zstd: enabled (libzstd)
GSS-API: enabled (MIT Kerberos/Heimdal)
GSASL: no (libgsasl not found)
TLS-SRP: enabled
resolver: POSIX threaded
IPv6: enabled
Unix sockets: enabled
IDN: enabled (libidn2)
Build libcurl: Shared=yes, Static=yes
Built-in manual: no (--enable-manual)
--libcurl option: enabled (--disable-libcurl-option)
Verbose errors: enabled (--disable-verbose)
Code coverage: disabled
SSPI: no (--enable-sspi)
ca cert bundle: /etc/ssl/certs/ca-certificates.crt
ca cert path: no
ca fallback: no
LDAP: no (--enable-ldap / --with-ldap-lib / --with-lber-lib)
LDAPS: no (--enable-ldaps)
RTSP: enabled
RTMP: no (--with-librtmp)
PSL: enabled
Alt-svc: enabled (--disable-alt-svc)
Headers API: enabled (--disable-headers-api)
HSTS: enabled (--disable-hsts)
HTTP1: enabled (internal)
HTTP2: enabled (nghttp2)
HTTP3: no (--with-ngtcp2, --with-quiche --with-msh3)
ECH: no (--enable-ech)
Protocols: DICT FILE FTP FTPS GOPHER GOPHERS HTTP HTTPS IMAP IMAPS MQTT POP3 POP3S RTSP SCP SFTP SMB SMBS SMTP SMTPS TELNET TFTP
Features: AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile MultiSSL NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets alt-svc brotli libz threadsafe zstd
I do not know if using both OpenSSL and GnuTLS is intended. If --without-ssl is changed to --without-openssl then only GnuTLS is used.
Edit:
I should clarify that even with the above change as libcurl-gnutls uses libssh2 which uses OpenSSL it would still be indirectly linked in.
Last edited by loqs (2022-07-11 01:16:55)
Offline
iTrooz wrote:... to allow GPL 2 program to use it, since they can't use openssl because of licensing issues
This is incorrect. Any GPL program can link to openssl as it's licensed permissively. Though if this were not correct, libcurl-gnutls would be an issue itself as it is also licensed permissively (not GPL).
A GPL licensed project can link to permissively-licensed libraries (e.g., BSD or MIT) it's only the reverse that can be an issue.
AFAIK, openssl licence is Apache Licence 2.0, which seems to be incompatible with GPLv2 (FSF link : https://gplv3.fsf.org/wiki/index.php/Co … _licenses)
in the other hand, libcurl is licenced under MIT, which is compatible with GPLv2 (same FSF link, and curl FAQ : https://curl.se/docs/faq.html#I_have_a_ … can_I_use)
Another thing that leads me to think that openssl is not GPL-compatible is the Debian stance on it :
https://lists.debian.org/debian-legal/2 … 00072.html (From 2002, so maybe outdated ?)
https://github.com/WerWolv/ImHex/issues/173
The openssl faq also states that it is unclear in case openssl is not a system library in the target system
https://www.openssl.org/docs/faq.html#LEGAL
i'm honestly confused by the state of openssl at this point. It seems like a system library (GPL has an exception for system libraries), but Debian.. doesn't recognize it as such ?
I do not know if using both OpenSSL and GnuTLS is intended. If --without-ssl is changed to --without-openssl then only GnuTLS is used.
Edit:
I should clarify that even with the above change as libcurl-gnutls uses libssh2 which uses OpenSSL it would still be indirectly linked in.
On Debian, libssh2 is not linked with libssl
I get that this is a completely different matter on Arch tho
Okay, so I think my question is...
If everything I said was right *which I doubt*
is openssl considered as a system library on ArchLinux ?
Last edited by iTrooz (2022-07-11 12:18:24)
Offline
Openssl 3.0 and greater are licensed under the Apache 2.0, but this isn't what's in our repos. We have 1.1.1.q in the repos which is under a different license which pacman has labeled as BSD, but this is apparently not accurate, it is a custom license fairly similar to BSD. While I'm cautious to interpret custom licenses, it does not appear that there is anything in it that'd be incompatible with the GPL.
I also cringe at license "compatibility" lists as that just doesn't mean anything at all without some more specification. It is nonsensical to say whether or not two licenses are compatible with each other. It's only relevant to ask whether code under license A can be linked to code under license B - this is not a symetrical relationship. So every pair of licenses could have two different answers for compatibility depending on which project is linking to which.
Also for a vast vast majority of code, this is only even relevant for redistributing modifications, only for the GPL is it relevant to linking libraries ... and if what you say is true, there's an exception for "system libraries" which is a meaningless phrase which makes the exception meaningless, which makes the license meaningless. They may just as well have an exception for code written by an author while the constellations of their astrological signs are aligned with Saturn ... that'd be absurd, but it would actually be clearly defined. In any case, I *think* the "system library" exception was intended to work in the direction opposite of what is discussed here (for non-GPL code to link to a GPL library).
is openssl considered as a system library on ArchLinux ?
Define "system library". It's a library. It's part of your system.
Last edited by Trilby (2022-07-11 12:27:34)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Openssl 3.0 and greater are licensed under the Apache 2.0, but this isn't what's in our repos. We have 1.1.1.q in the repos which is under a different license which pacman has labeled as BSD, but this is apparently not accurate, it is a custom license fairly similar to BSD. While I'm cautious to interpret custom licenses, it does not appear that there is anything in it that'd be incompatible with the GPL.
I'm not sure about this, I've seen a lot of packages writing an exception on their licence to allow linking against OpenSSL (also see https://lists.debian.org/debian-legal/2 … 0030.html)
Did I understand something wrong ?
iTrooz wrote:is openssl considered as a system library on ArchLinux ?
Define "system library". It's a library. It's part of your system.
I was talking about this : https://www.gnu.org/licenses/gpl-faq.en … yException
Quote from the GPLv2 licence :
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
Interesting comment from Clint Byrum about this : http://disq.us/p/1hat3ik (seems to refer to the 1.1 licence)
Last edited by iTrooz (2022-07-11 14:14:21)
Offline
The section of the build for libcurl-gnutls
# build libcurl-gnutls cd "${srcdir}"/build-curl-gnutls "${srcdir}/${pkgbase}-${pkgver}"/configure \ "${_configure_options[@]}" \ --disable-versioned-symbols \ --without-ssl \ --with-gnutls='/usr' sed -i -e 's/ -shared / -Wl,-O1,--as-needed\0/g' libtool make -C lib }
Which produces this configure listing
configure: Configured to build curl/libcurl: Host setup: x86_64-pc-linux-gnu Install prefix: /usr Compiler: gcc CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -g -ffile-prefix-map=/build/curl/src=/usr/src/debug -flto=auto -Werror-implicit-function-declaration -Wno-system-headers CPPFLAGS: LDFLAGS: -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -flto=auto -L/usr/lib LIBS: -lnghttp2 -lidn2 -lssh2 -lssh2 -lpsl -lnettle -lgnutls -lssl -lcrypto -lssl -lcrypto -lgssapi_krb5 -lzstd -lbrotlidec -lz curl version: 7.84.0 SSL: enabled (OpenSSL, GnuTLS) SSH: enabled (libSSH2) zlib: enabled brotli: enabled (libbrotlidec) zstd: enabled (libzstd) GSS-API: enabled (MIT Kerberos/Heimdal) GSASL: no (libgsasl not found) TLS-SRP: enabled resolver: POSIX threaded IPv6: enabled Unix sockets: enabled IDN: enabled (libidn2) Build libcurl: Shared=yes, Static=yes Built-in manual: no (--enable-manual) --libcurl option: enabled (--disable-libcurl-option) Verbose errors: enabled (--disable-verbose) Code coverage: disabled SSPI: no (--enable-sspi) ca cert bundle: /etc/ssl/certs/ca-certificates.crt ca cert path: no ca fallback: no LDAP: no (--enable-ldap / --with-ldap-lib / --with-lber-lib) LDAPS: no (--enable-ldaps) RTSP: enabled RTMP: no (--with-librtmp) PSL: enabled Alt-svc: enabled (--disable-alt-svc) Headers API: enabled (--disable-headers-api) HSTS: enabled (--disable-hsts) HTTP1: enabled (internal) HTTP2: enabled (nghttp2) HTTP3: no (--with-ngtcp2, --with-quiche --with-msh3) ECH: no (--enable-ech) Protocols: DICT FILE FTP FTPS GOPHER GOPHERS HTTP HTTPS IMAP IMAPS MQTT POP3 POP3S RTSP SCP SFTP SMB SMBS SMTP SMTPS TELNET TFTP Features: AsynchDNS GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile MultiSSL NTLM NTLM_WB PSL SPNEGO SSL TLS-SRP UnixSockets alt-svc brotli libz threadsafe zstd
I do not know if using both OpenSSL and GnuTLS is intended. If --without-ssl is changed to --without-openssl then only GnuTLS is used.
Edit:
I should clarify that even with the above change as libcurl-gnutls uses libssh2 which uses OpenSSL it would still be indirectly linked in.
I know this has no relation to the original problem, but while you are mentioning that : did you check the linkings of the resulting .so file ?
Mine is at ./lib/.libs/libcurl.so, and it's *still* linked with openssl, even though the summary doesn't make mention of it
Offline
Please try with lddtree from pax-utils, is the linking directly to libcurl-gnutls.so or to libssh2?
Offline
Neither, it was coming from ldap
I disabled it, and there are no libssl dependencies anymore
thanks for showing me this tool, it's really useful !
Offline
That FAQ answer is odd (no surprise in my view) as the words "system library" do not appear in the GPL2 at all, so it certainly isn't defined in the license. Further, the FAQ answer references the end of section three of the license for this point - but there is no such discussion in the text of the license in section 3 (which is about the requirement to make source code available).
Last edited by Trilby (2022-07-11 16:54:33)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
That FAQ answer is odd (no surprise in my view) as the words "system library" do not appear in the GPL2 at all, so it certainly isn't defined in the license. Further, the FAQ answer references the end of section three of the license for this point - but there is no such discussion in the text of the license in section 3 (which is about the requirement to make source code available).
I think it should refer to this part of GPLv2 section 3. The waiver for source code inclusion might imply some sort of permission to use libraries with different licenses.
However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.
Last edited by progandy (2022-07-11 16:59:15)
| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |
Offline
I think ... might imply ...
Both phrases that should never be needed when talking about a well written legal document. But this is about requirements to include source code, *not* about whether linking is acceptable. It also completely avoids actually defining what the exception is in any objective terms. It's so vague as to be legally meaningless: it's not clear if / when it would ever apply so it only invites legal disputes. Some might be tempted to use this exception, but GNUs lawyers would always have the option to come after anyone who does so.
So this doesn't grant rights (which is what a license is supposed to do), it only dangles something that looks vaguely like a carrot over a threat of a lawsuit.
Last edited by Trilby (2022-07-11 17:05:49)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
In this case (unclear openssl legality), do you think it would be reasonable for me to directly email the packager to ask if this is intentional for gnutls to link to it?
Offline
Don't email the packager - I think the quickest way would be to hand-roll your own libcurl-gnutls with --without-openssl and then open a bug on the Arch bug tracker with a suggested patch and justification.
However, according to the Packages page, curl itself links to libssl.so.1.1, and it's obviously a dependency for libcurl-gnutls, so you may have to build curl with different settings as well.
Having said all this, let's not talk in hypotheticals, exactly which GPL2 software are you concerned with in being 'tainted' with linking to openssl's custom or other permissive licenses? Remember that the kernel itself is GPL2, and they have not challenged openssl afaik.
Offline
The update to OpenSSL 3.0. with its license change should also resolve any licensing issue without needing to change the PKGBUILD.
Offline
I think the quickest way would be to hand-roll your own libcurl-gnutls with --without-openssl and then open a bug on the Arch bug tracker with a suggested patch and justification.
Okay, then think I'll do that when I get more time.
Having said all this, let's not talk in hypotheticals, exactly which GPL2 software are you concerned with in being 'tainted' with linking to openssl's custom or other permissive licenses?
The software is https://github.com/werWolv/imHex (there has already been an issue with openssl, see https://github.com/WerWolv/ImHex/issues/173)
The update to OpenSSL 3.0. with its license change should also resolve any licensing issue without needing to change the PKGBUILD
I'm not sure about that. IIRC if you check my link on Debian email lists, they say that the new OpenSSL licence doesn't fix the problem
Offline
Having said all this, let's not talk in hypotheticals, exactly which GPL2 software are you concerned with in being 'tainted' with linking to openssl's custom or other permissive licenses?
The software is https://github.com/werWolv/imHex (there has already been an issue with openssl, see https://github.com/WerWolv/ImHex/issues/173
You are concerned about an older version of the package? As the current release no longer uses OpenSSL as the report you linked notes.
I'm not sure about that. IIRC if you check my link on Debian email lists, they say that the new OpenSSL licence doesn't fix the problem
It did not help with the issue raised as Debian was not at that point was not packaging OpenSSL 3 in any of its repositories. https://lists.debian.org/debian-legal/2 … 00037.html
https://www.gnu.org/licenses/license-li … leLicenses lists Apache 2.0 as compatible.
Edit:
The packages that use libcurl-gnutls are spotify-launcher (I assume for spotify rather than the launcher itself) and steam-native-runtime?
Last edited by loqs (2022-07-21 23:38:24)
Offline
The software is https://github.com/werWolv/imHex
Same as loqs' comment: is this still an issue then? I checked your PKGBUILD you maintain in that upstream repo and there doesn't appear to be dependency on openssl or other problematic licenses anymore?
Btw: Had not seen that hex editor before, looks really cool. (Kind of ironic a reverse engineering tool is released under a license that holds itself and others to higher standards - "it's not about the money, it's about the principal". But I understand and respect it).
Offline
The "problem" is that ImHex depends on libcurl, and since libcurl is sometimes linked with openssl, we actually compile curl with ImHex (as a git submodule) and bundle it. We'd rather like to use a system-provided libcurl, and that would mean using libcurl-gnutls.so
It did not help with the issue raised as Debian was not at that point was not packaging OpenSSL 3 in any of its repositories. https://lists.debian.org/debian-legal/2 … 00037.html
https://www.gnu.org/licenses/license-li … leLicenses lists Apache 2.0 as compatible.
Unfortunately, it isn't compatible with GPL 2 (See https://directory.fsf.org/wiki/License:Apache2.0)
EDIT : meant https://www.gnu.org/licenses/license-li … ml#apache2
Last edited by iTrooz (2022-07-22 22:19:28)
Offline
Okay, so... while doing research, I found this link completely at random (https://bugs.freebsd.org/bugzilla/show_ … ?id=263484) which says gnutls can only be found on some Linux distributions, which is.. kind of a deal breaker for using it, so I guess I'll guess I won't do anything with gnutls.
I feel kinda dumb to not have checked that in the first place
Sorry
Offline
loqs wrote:https://www.gnu.org/licenses/license-li … leLicenses lists Apache 2.0 as compatible.
Unfortunately, it isn't compatible with GPL 2 (See https://directory.fsf.org/wiki/License:Apache2.0)
Ah I missed GPL 2 vs GPL 3 being the key element.
Last edited by loqs (2022-07-22 22:17:41)
Offline
iTrooz wrote:loqs wrote:https://www.gnu.org/licenses/license-li … leLicenses lists Apache 2.0 as compatible.
Unfortunately, it isn't compatible with GPL 2 (See https://directory.fsf.org/wiki/License:Apache2.0)
Ah I missed GPL 2 vs GPL 3 being the key element.
Ooops, I thought I copied an anchor when I copied a different link. But yeah, this is said on your link
Offline
What's stopping you and your contributors from changing the ImHex license from GPLv2 to GPLv3? From my outsider perspective it sounds like the project relies too much on Apache2/MIT licensed dependencies to be viable as a GPLv2 project. You could try to 'clean-room' a competing GPLv2 curl/TLS implementation, but that sounds like an enormous task with little benefit.
Last edited by twelveeighty (2022-07-23 16:03:53)
Offline
What's stopping you and your contributors from changing the ImHex license from GPLv2 to GPLv3? From my outsider perspective it sounds like the project relies too much on Apache2/MIT licensed dependencies to be viable as a GPLv2 project. You could try to 'clean-room' a competing GPLv2 curl/TLS implementation, but that sounds like an enormous task with little benefit.
Essentially because switching the licence (and thus asking every contributor) would be a big task, and the project author do not want to use GPL (because of a new restriction it added IIRC, I don't remember much about the conversation we had)
Offline