[MacPorts] #62849: How to deal with Qt-based ports being considered non-distributable?

[MacPorts]

#62849: How to deal with Qt-based ports being considered non-distributable?
-----------------------+--------------------
  Reporter:  szhorvat  |      Owner:  (none)
      Type:  request   |     Status:  new
  Priority:  Normal    |  Milestone:
 Component:  ports     |    Version:
Resolution:            |   Keywords:
      Port:            |
-----------------------+--------------------
Description changed by szhorvat:

Old description:

> **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 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 from portfiles that use the license exception. I suppose doubts
> around this issue might be why some PRs [https://github.com/macports
> /macports-ports/pull/10791#discussion_r621707434 like this one] are being
> held up.
>
> To be clear, I have no interest in debating licensing issues. I am merely
> looking for clarification, to expedite creating/handling PRs. That said,
> here is my understanding of the licensing situation, and my proposal for
> a guideline:
>
> > 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.

New description:

 **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
 [https://github.com/macports/macports-
 ports/pull/10791#discussion_r621707434 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.

--

-- 
Ticket URL: <https://trac.macports.org/ticket/62849#comment:1>
MacPorts <https://www.macports.org/>
Ports system for macOS