You are not logged in.

#1 2022-07-10 23:37:37

iTrooz
Member
Registered: 2022-07-10
Posts: 11

libcurl-gnutls is linked to libssl (openssl)

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

#2 2022-07-11 00:40:01

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 27,053
Website

Re: libcurl-gnutls is linked to libssl (openssl)

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.

Last edited by Trilby (2022-07-11 00:42:17)


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#3 2022-07-11 01:09:20

loqs
Member
Registered: 2014-03-06
Posts: 15,094

Re: libcurl-gnutls is linked to libssl (openssl)

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

#4 2022-07-11 11:49:08

iTrooz
Member
Registered: 2022-07-10
Posts: 11

Re: libcurl-gnutls is linked to libssl (openssl)

Trilby wrote:
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 ?

loqs wrote:

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

#5 2022-07-11 12:24:37

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 27,053
Website

Re: libcurl-gnutls is linked to libssl (openssl)

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).

iTrooz wrote:

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

#6 2022-07-11 13:47:14

iTrooz
Member
Registered: 2022-07-10
Posts: 11

Re: libcurl-gnutls is linked to libssl (openssl)

Trilby wrote:

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 ?

Trilby wrote:
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

#7 2022-07-11 14:12:39

iTrooz
Member
Registered: 2022-07-10
Posts: 11

Re: libcurl-gnutls is linked to libssl (openssl)

loqs wrote:

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

#8 2022-07-11 14:37:43

loqs
Member
Registered: 2014-03-06
Posts: 15,094

Re: libcurl-gnutls is linked to libssl (openssl)

Please try with lddtree from pax-utils,  is the linking directly to libcurl-gnutls.so or to libssh2?

Offline

#9 2022-07-11 14:59:33

iTrooz
Member
Registered: 2022-07-10
Posts: 11

Re: libcurl-gnutls is linked to libssl (openssl)

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

#10 2022-07-11 16:52:30

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 27,053
Website

Re: libcurl-gnutls is linked to libssl (openssl)

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

#11 2022-07-11 16:56:49

progandy
Member
Registered: 2012-05-17
Posts: 5,004

Re: libcurl-gnutls is linked to libssl (openssl)

Trilby wrote:

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.

https://www.gnu.org/licenses/old-licenses/gpl-2.0.de.html wrote:

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

#12 2022-07-11 17:03:25

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 27,053
Website

Re: libcurl-gnutls is linked to libssl (openssl)

progandy wrote:

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

#13 2022-07-12 20:39:09

iTrooz
Member
Registered: 2022-07-10
Posts: 11

Re: libcurl-gnutls is linked to libssl (openssl)

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

#14 2022-07-13 20:26:19

twelveeighty
Member
From: Alberta, Canada
Registered: 2011-09-04
Posts: 916

Re: libcurl-gnutls is linked to libssl (openssl)

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

#15 2022-07-13 20:59:48

loqs
Member
Registered: 2014-03-06
Posts: 15,094

Re: libcurl-gnutls is linked to libssl (openssl)

The update to OpenSSL 3.0. with its license change should also resolve any licensing issue without needing to change the PKGBUILD.

Offline

#16 2022-07-21 20:32:01

iTrooz
Member
Registered: 2022-07-10
Posts: 11

Re: libcurl-gnutls is linked to libssl (openssl)

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)

loqs wrote:

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

#17 2022-07-21 20:52:20

loqs
Member
Registered: 2014-03-06
Posts: 15,094

Re: libcurl-gnutls is linked to libssl (openssl)

iTrooz wrote:

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.

iTrooz wrote:

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

#18 2022-07-22 15:37:25

twelveeighty
Member
From: Alberta, Canada
Registered: 2011-09-04
Posts: 916

Re: libcurl-gnutls is linked to libssl (openssl)

iTrooz wrote:

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

#19 2022-07-22 21:35:08

iTrooz
Member
Registered: 2022-07-10
Posts: 11

Re: libcurl-gnutls is linked to libssl (openssl)

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

#20 2022-07-22 21:50:12

iTrooz
Member
Registered: 2022-07-10
Posts: 11

Re: libcurl-gnutls is linked to libssl (openssl)

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

#21 2022-07-22 22:13:06

loqs
Member
Registered: 2014-03-06
Posts: 15,094

Re: libcurl-gnutls is linked to libssl (openssl)

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.

Last edited by loqs (2022-07-22 22:17:41)

Offline

#22 2022-07-22 22:19:15

iTrooz
Member
Registered: 2022-07-10
Posts: 11

Re: libcurl-gnutls is linked to libssl (openssl)

loqs wrote:
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

#23 2022-07-23 16:03:21

twelveeighty
Member
From: Alberta, Canada
Registered: 2011-09-04
Posts: 916

Re: libcurl-gnutls is linked to libssl (openssl)

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

#24 2022-07-23 17:43:13

iTrooz
Member
Registered: 2022-07-10
Posts: 11

Re: libcurl-gnutls is linked to libssl (openssl)

twelveeighty wrote:

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

Board footer

Powered by FluxBB