Bug 259214 - mail/fetchmail: Fix build with LibreSSL 3.4
Summary: mail/fetchmail: Fix build with LibreSSL 3.4
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Matthias Andree
URL:
Keywords:
Depends on:
Blocks: 259945
  Show dependency treegraph
 
Reported: 2021-10-16 17:30 UTC by Bernard Spil
Modified: 2021-12-13 11:05 UTC (History)
3 users (show)

See Also:
chalpin: maintainer-feedback+


Attachments
git diff for mail/fetchmail (588 bytes, patch)
2021-10-16 17:30 UTC, Bernard Spil
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Bernard Spil freebsd_committer freebsd_triage 2021-10-16 17:30:47 UTC
Created attachment 228766 [details]
git diff for mail/fetchmail

Source: http://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/mail/fetchmail/patches/patch-tls-aux_h
Comment 1 Li-Wen Hsu freebsd_committer freebsd_triage 2021-10-20 07:12:29 UTC
Submitter is committer.
Comment 2 Corey Halpin 2021-10-23 13:08:58 UTC
Looks good to me. Passes  'poudriere testport' on both amd64 and i386 under 13.0 and 12.2 for the following configurations:
  - Default settings 
  - Default settings, build as non-root
  - ssl=base, GSSAPI_MIT
  - ssl=base, GSSAPI_NONE
  - ssl=openssl
  - ssl=openssl with SSL2 and SSL3 disabled
  - ssl=openssl, GSSAPI_NONE
  - ssl=libressl
  - ssl=libressl, GSSAPI_NONE
  - ssl=libressl-devel (which I just added to my set of configs to test)

Built package works in my testing.

I approve this patch. Thank you!

(ps. I'd also appreciate it if a committer could look at 258207.)
Comment 3 commit-hook freebsd_committer freebsd_triage 2021-10-23 17:11:54 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=0c86d31161b9f576267e5d9cea2f5e18bf89fd2c

commit 0c86d31161b9f576267e5d9cea2f5e18bf89fd2c
Author:     Bernard Spil <brnrd@FreeBSD.org>
AuthorDate: 2021-10-23 17:08:00 +0000
Commit:     Bernard Spil <brnrd@FreeBSD.org>
CommitDate: 2021-10-23 17:08:00 +0000

    mail/fetchmail: Fix build with LibreSSL 3.4

    PR:             259214
    Approved by:    Corey Halpin <chalpin cs wisc edu> (maintainer)

 mail/fetchmail/files/patch-LibreSSL (new)         | 14 ++++++++++++++
 security/p5-Net-SSLeay/files/patch-LibreSSL (new) | 16 ++++++++++++++++
 2 files changed, 30 insertions(+)
Comment 4 Bernard Spil freebsd_committer freebsd_triage 2021-10-24 08:35:44 UTC
sent mail to perl@ for the p5-Net-SSLeay patch that has been inadvertently included.
Comment 5 Matthias Andree freebsd_committer freebsd_triage 2021-11-20 10:17:57 UTC
While technically correct, this is illegal. 

Fetchmail uses GPLd code and code under OpenSSL or SSLeay license, and the GPL clause 2(b) exception to resolve this applies to OpenSSL, and OpenSSL only, not LibreSSL. 

I (hat: upstream maintainer) have no intentions of contacting all contributors for permissions to relicense because the fix has already been deployed, OpenSSL 3.0 is under the Apache License v2.0 and we can just upgrade fetchmail to GPL v3+ and move on with life as soon as OpenSSL 1.1.1 is EOL.

I am proposing an update to fetchmail 6.4.24 to Corey anyways, which will include the necessary IGNORE_SSL tags and remove this patch. 

I was unaware of this effort, else I would have made fetchmail 6.4.24 lock out LibreSSL altogether.
Comment 6 commit-hook freebsd_committer freebsd_triage 2021-11-20 22:46:56 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=30e97245f9dd9ddef1bffd874a9035a6fe9b6817

commit 30e97245f9dd9ddef1bffd874a9035a6fe9b6817
Author:     Matthias Andree <mandree@FreeBSD.org>
AuthorDate: 2021-11-20 10:19:22 +0000
Commit:     Matthias Andree <mandree@FreeBSD.org>
CommitDate: 2021-11-20 22:45:48 +0000

    mail/fetchmail: update to 6.4.24 and block LibreSSL.

    fetchmail cannot legally be linked with LibreSSL,
    because there is no GPLv2 clause 2b exemption for
    LibreSSL, only for OpenSSL.

    Correct LICENSE and remove LICENSE_COMB.
    Remove LibreSSL patch.

    Add FSF comment suggested by Corey Halpin in PR.

    Related to:
    PR:             259214

    Update:
    PR:             259945
    MFH:            2021Q4

    Approved by:    chalpin@cs.wisc.edu (maintainer)

 mail/fetchmail/Makefile                    | 78 ++++++++++++++++++------------
 mail/fetchmail/distinfo                    |  6 +--
 mail/fetchmail/files/patch-LibreSSL (gone) | 14 ------
 mail/fetchmailconf/Makefile                | 21 ++++----
 4 files changed, 60 insertions(+), 59 deletions(-)
Comment 7 commit-hook freebsd_committer freebsd_triage 2021-11-20 22:58:03 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=997bacb528ceba53b9e680dff833a0258d3bf917

commit 997bacb528ceba53b9e680dff833a0258d3bf917
Author:     Matthias Andree <mandree@FreeBSD.org>
AuthorDate: 2021-11-20 10:19:22 +0000
Commit:     Matthias Andree <mandree@FreeBSD.org>
CommitDate: 2021-11-20 22:55:58 +0000

    mail/fetchmail: update to 6.4.24 and block LibreSSL.

    Now really 6.4.24 and not a 6.4.25 WIP.

    fetchmail cannot legally be linked with LibreSSL,
    because there is no GPLv2 clause 2b exemption for
    LibreSSL, only for OpenSSL.

    Correct LICENSE and remove LICENSE_COMB.
    Add comment on FSF dynamic linking dynamically
    suggested by Corey Halpin in the approval.

    Remove LibreSSL patch.

    Related to:
    PR:             259214

    Update:
    PR:             259945
    MFH:            2021Q4

    Approved by:    chalpin@cs.wisc.edu (maintainer)

 mail/fetchmail/Makefile                    | 70 +++++++++++++++++-------------
 mail/fetchmail/distinfo                    |  6 +--
 mail/fetchmail/files/patch-LibreSSL (gone) | 14 ------
 mail/fetchmailconf/Makefile                | 21 +++++----
 4 files changed, 52 insertions(+), 59 deletions(-)
Comment 8 commit-hook freebsd_committer freebsd_triage 2021-11-20 23:00:04 UTC
A commit in branch 2021Q4 references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=67f2fcbfde9e6cd493086c4858bf3e4d91480252

commit 67f2fcbfde9e6cd493086c4858bf3e4d91480252
Author:     Matthias Andree <mandree@FreeBSD.org>
AuthorDate: 2021-11-20 10:19:22 +0000
Commit:     Matthias Andree <mandree@FreeBSD.org>
CommitDate: 2021-11-20 22:59:18 +0000

    mail/fetchmail: update to 6.4.24 and block LibreSSL.

    fetchmail cannot legally be linked with LibreSSL,
    because there is no GPLv2 clause 2b exemption for
    LibreSSL, only for OpenSSL.

    Correct LICENSE and remove LICENSE_COMB.
    Add comment on FSF dynamic linking dynamically
    suggested by Corey Halpin in the approval.

    Remove LibreSSL patch.

    Related to:
    PR:             259214

    Update:
    PR:             259945
    MFH:            2021Q4

    Approved by:    chalpin@cs.wisc.edu (maintainer)

    (cherry picked from commit 997bacb528ceba53b9e680dff833a0258d3bf917)

 mail/fetchmail/Makefile     | 69 +++++++++++++++++++++++++--------------------
 mail/fetchmail/distinfo     |  6 ++--
 mail/fetchmailconf/Makefile | 21 +++++++-------
 3 files changed, 52 insertions(+), 44 deletions(-)
Comment 9 Franco Fichtner 2021-11-29 12:37:04 UTC
I do hope a lawyer was consulted here otherwise this could be interpreted as vandalism.  ;)


Cheers,
Franco
Comment 10 Corey Halpin 2021-11-29 22:40:10 UTC
(In reply to Franco Fichtner from comment #9)

I do not understand this comment.

Matthias is the upstream maintainer of `fetchmail`. He noted, correctly, that the port was not properly following FSF's guidance about how the GPL should be interpreted. He asked, entirely reasonably, for this to be fixed.

In what way could this be considered vandalism?
Comment 11 Matthias Andree freebsd_committer freebsd_triage 2021-12-10 19:52:45 UTC
(In reply to Franco Fichtner from comment #9)
I wonder how to treat *YOUR* doorbell prank. 
It certainly was not fostering your reputation.
Comment 12 Franco Fichtner 2021-12-11 11:13:38 UTC
Listen carefully, because I'm only going to say this once.

Your continued ad hominem attacks are one thing.  I will not engage in private discussions since the last time it derailed into a demeaning conversation where you asserted that my FreeBSD contributions are insignificant.  Thanks for that horrible insight, BTW.  ;)

You have been engaging in destructive behaviour towards LibreSSL in the FreeBSD ports tree before and have overstepped these bounds in the process denigrating the work of others in this tree.  I'm seeing a pattern here for a disregard of different opinions alone.

I know for a fact that you hold no value for LibreSSL, but it doesn't give you the right to use your FreeBSD commit bit to enforce your opinion on the FreeBSD ports users.

In the case of fetchmail the questionable GPL choice is yours alone. Tagging along the FSF's legal bubble opinion on its own matters in a BSD project is slightly worse. Then asserting that something is illegal now requires you to sue downstream users for using your software since 2016 when a LibreSSL patch was added to this port and you have done nothing to remedy the situation.  Good luck with that latter part. If your choice is to take a hostile stance against open source in general please don't expect everyone to like it or let you go for it.

And don't mind me not taking your opinion for granted because I know you personally think very lowly of me as initially stated, but that's a mutual agreement I've come to understand that can't really be generalised like you did before. It again shows lack of the opinion of others, or maybe you just don't care. It doesn't matter to me.


Cheers,
Franco
Comment 13 Matthias Andree freebsd_committer freebsd_triage 2021-12-11 12:10:56 UTC
Franco, 

you were accusing me of vandalism, and that is factually not correct, therefore offensive and libel, and is not something I tolerate. 

You can see from comment #10 that I am not the only person who was irritated by your false accusation.

I was offering a discussion to you behind the scenes by e-mail to explain comment #9, which you chose to ignore.

I do not need a lawyer to understand that fetchmail consists of various components from different copyright holders, or taken out from other software, under one or another GNU License.

In case you have not noticed yet, I will rub this in: I cannot just relicense code which I myself am redistributing under license, unless that license allows me to.

And who are you to challenge the authority of the Free Software Foundation, the creator of the GPL license text, for the interpretation of its own license text?

So please enlighten me, what is your contribution to FreeBSD that is worth having and that compensates your mud-slinging?
Comment 14 Matthias Andree freebsd_committer freebsd_triage 2021-12-11 12:31:51 UTC
Also Franco, who are you to challenge my, or the original authors', choice of licenses at all?
Comment 15 Corey Halpin 2021-12-13 02:34:35 UTC
Franco, you state that FSF's license guidance comes from a "legal bubble." Can you cite some authoritative sources to support that claim? My understanding is that this is a complex issue on which lawyers disagree that lacks a simple, clear-cut resolution. I would recommend the April 24, 2013 LWN article "Dynamic linking and derivative works" at https://lwn.net/Articles/548216/ and the references therein as excellent background. Most of the authoritative sources I've found conclude that the FSF's interpretation is probably legally correct. All of the authoritative sources I've found agree that no clear answer has yet been provided by the courts. I can find no authoritative sources arguing that the FSF does not understand the intent of the license that they wrote and so it is reasonable to disregard their guidance on how to apply it.

I think it's worth taking a step back to consider what a license is: a legal framework for copyright holders to grant permission for others to use their work. For the case of how the FreeBSD ports tree should treat fetchmail, or indeed any GPL'd software, the most relevant question is NOT "do we like the FSF's guidance on their license?", nor "do we agree with FSF's guidance on their license?", nor is it "what is the most we can legally do with this software given a strict, literal interpretation of the text of the license that ignores any clarifying information provided by the authors of the license?". The most relevant question is this: What permission did the authors of this software explicitly give us? In the case of fetchmail, the upstream authors did NOT explicitly give us permission to distribute binaries linked with LibreSSL. 

Fetchmail is a house built by the people who wrote it. Above the door to this house the builders placed a sign giving anyone permission to be a guest in their house provided that they follow the rules of the GPL according to the FSF's guidance. I have no interest in turning the FreeBSD fetchmail port into the kind of guest that violates the rules of the house and then tries to argue with the host that the rules were wrong.

And regarding "Vandalism" -- it simply can not be vandalism when someone paints their own house.
Comment 16 Corey Halpin 2021-12-13 11:05:15 UTC
Thinking a bit more about what I've written, I realize that the last sentence in #15 could be read in several ways that I didn't intend. It also focuses on the wrong thing and omits important nuance. I'd like to revise it as follows:

Regarding "Vandalism" -- it is not vandalism when someone points out a sign above the door of a house they co-own that has been there since the house was built and which they, themselves, do not have the authority change.