Opened 3 years ago

Last modified 3 years ago

#62849 new request

How to deal with Qt-based ports being considered non-distributable?

Reported by: szhorvat (Szabolcs Horvát) Owned by:
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), ryandesign (Ryan Carsten Schmidt)
Port:

Description (last modified by szhorvat (Szabolcs Horvát))

tl;dr GPL-licensed ports that depend on Qt are considered non-distributable by MacPorts due to Qt being marked with the OpenSSLException license. There is an easy fix: add license_noconflict to the dependent port. I am looking for a clear guideline on when this fix can be used.


The qt5 ports in MacPorts have the license (LGPL-3 or GPL-3 or OpenSSLException). Most ports that depend on Qt have GPL-2 or GPL-3. The GPL and OpenSSL licenses are not compatible. As a practical result, most Qt-based ports in MacPorts end up being considered non-distributable, and are built from source on the user's machine. This often takes a very long time, and (at least for me) is one of the major annoyances of using MacPorts.

There is an easy technical fix: add license_noconflict openssl to the affected port. Many ports already use this, but with varying and not entirely consistent justifications. See e.g.:

https://github.com/macports/macports-ports/blob/master/devel/qt5-qtcreator/Portfile#L45

I count 149 uses at present.

I opened this issue to request clarification on when it is acceptable to add license_noconflict openssl to a portfile. It would be useful to have a clear guideline on this (e.g. in the wiki), which can also be linked as justification from portfiles that use the license exception. I suppose doubts around this issue might be why some PRs like this one are being held up.

To be clear, I have no interest in debating licensing issues. I am merely looking for clear and easy to follow guidelines, to expedite creating/handling PRs. That said, here is my understanding of the licensing situation, and my proposal for a guideline. It hope this will be a useful starting point.

In MacPorts, Qt links to OpenSSL by default, but this can be easily switched off with a variant (-openssl). Most software that use Qt have no knowledge of whether Qt is built with or without OpenSSL, so their distributability should not be affected by which version of Qt is present on the user's machine. Therefore, it makes sense to use the following as a guideline: If the binaries of a software work correctly regardless of whether Qt is installed with the +openssl or -openssl variant, it is fine to add license_noconflict openssl to the portfile of that software.

Change History (3)

comment:1 Changed 3 years ago by szhorvat (Szabolcs Horvát)

Description: modified (diff)

comment:2 in reply to:  description Changed 3 years ago by ryandesign (Ryan Carsten Schmidt)

Replying to szhorvat:

GPL-licensed ports that depend on Qt are considered non-distributable by MacPorts due to Qt being marked with the OpenSSLException license.

No, not due to that reason. OpenSSLException is added to a GPL license in a port's license line when that project's license verbiage specifically allows a binary to be linked with openssl, which is not normally permitted under the GPL. This allows a port to be distributed that would not have been distributable before. Adding OpenSSLException removes existing GPL-related distributability restrictions; it does not impose them.

comment:3 Changed 3 years ago by szhorvat (Szabolcs Horvát)

Thanks for the response. It seems I misunderstood the reason for the problem, nevertheless the problem remains:

If a GPL port uses Qt, MacPorts will treat it as non-distributable without additional intervention. It would be good to have guidelines on when the intervention can be applied.

Note: See TracTickets for help on using tickets.