[Interest] Qt, openssl and redistribution (of binary packages)

[René J. V. Bertin]

Constantin Makshin wrote:


> I'm not sure omitting licensing information is a good idea. Instead you
> may specify that while Qt5 itself can be redistributed under the terms
> of either GPL3 or LGPL{2|3}, MacPorts package in particular is limited
> to LGPL (due to OpenSSL). But even that is not necessary if you use

I'm not exactly sure what the license info provided by MacPorts packages is 
about, but it's probably a list of all licenses that cover the software provided 
through the package ("port").

> OpenSSL libraries provided by the OS (I don't know whether macOS does
> that) because GPL explicitly allows linking to system libraries without
> any restrictions.

Yes, they exist, but are only as up-to-date as the latest update Apple shipped, 
while the OpenSSL copy provided by MacPorts is almost by definition more recent. 
That means OpenSSL 0.9.8 "64.30.2" vs. 1.0.2j ...

The same argument that applies to SecureTransport, which could otherwise be used 
to solve the whole licensing problem.

If QtNetwork is as feature-complete with SecureTransport as with OpenSSL, of 
course.


> Qt Creator is GPL-only, but that's okay if you use system OpenSSL libraries.
> I also did "fgrep -R ssl" on a directory with unpacked Qt Creator 4.2.1
> sources and didn't find any signs of Qt Creator's [direct] dependency on
> OpenSSL.

But are you sure that an indirect dependency (through QtNetwork) is OK?!

I've looked into building runtime OpenSSL support using the system OpenSSL 
headerfiles, but at the least that will lead to feature loss on systems that are 
still on OpenSSL < 1.0.0 - meaning all versions of Apple's OS.

I should look into building the latest version of the Security framework 
(https://opensource.apple.com/source/Security/Security-57740.31.2/) ...


R