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
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
