Removal of mail/fetchmail

[8191]

Hi,

I just recognized that mail/fetchmail was removed (6673bb86). I could not find the reason for this (neither here nor on Github)... Any background information to share here?

[franco]

The author of fetchmail insists that linking fetchmail against LibreSSL is illegal and in his capacity as a FreeBSD committer also forces his anti-LibreSSL stance on the FreeBSD ports tree consumers.

We have removed the fetchmail port from our builds to avoid potential damage to the project and its users.


Cheers,
Franco

[8191]

Thanks for the update!
I'm not an expert on BSD like licenses, but how is such a "limitation" even possible? Need to do some research on that issue...

Was OPNsense ever explicitly addressed by the author? Or you're just acting precautionary?

BR

[franco]

The emotionally charged exchange is here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259214 prompted by FreeBSD ports tree commit of the software's author. I get that someone can say it's ok to do this and this is a reasonable view, but to ignore this from a downstream perspective is simply dangerous.

fetchmail is GPLv2 or later and one legal interpretation is that GPLv2 is incompatible with the license used in current OpenSSL releases, which in turn was inherited by LibreSSL and this is where the whole mess starts.

https://gitlab.com/fetchmail/fetchmail/-/blob/legacy_64/COPYING

Now the trick is that OpenSSL is such an integral part of modern networking software exceptions are made for system libraries (a big Linux distribution might claim this to remove any legal implication so to speak as a standard loophole) or specific author exceptions under the previous assumption that this is illegal (what the fetchmail author did).

And so the fetchmail author does not give permission for LibreSSL even though from a code framework standpoint if LibreSSL presents itself as OpenSSL (which it is) the software being linked cannot know the difference, but legally the "LibreSSL project" entity is not the "OpenSSL project" so the whole thing is constructed to be problematic.

How providing and requiring the software bindings while also trying to make an assumption about the future use of it (OpenSSL exception was given before LibreSSL was forked) is definitely questionable. I don't know of any legal challenge that actually decided this one way or another.

OpenSSL 3 will try to avert this continued disaster by switching the license to make it generally compatible. The best approach for LibreSSL is to refork after OpenSSL version 3 is out and the issue is resolved for them as well and the whole thing here has been rather very pointless.

I can see that the author subsequently avoided the brewing OpenBSD disaster (one of the reasons why I thought this was a bad idea to start with but I don't see that I have to point this out beforehand) by issuing https://gitlab.com/fetchmail/fetchmail/-/commit/c4419bdd25 but if I hadn't replied to the Bugzilla report above this likely would not have happened and we will never know otherwise.

Previously the author did not support LibreSSL and doesn't want you to use it and now the author supports LibreSSL but wants to control how you use it. It looks like the smartest thing seen here so far, but it's still a very low bar to clear. Personally I prefer not dealing with such time sinks anymore and shield users from it if they want to or not.


Cheers,
Franco

[Patrick M. Hausen]

Seriously: why not bin LibreSSL instead of fetchmail? I know of no compelling reason to run it instead of OpenSSL in my >50 servers >500 jails data centre ...

[mimugmail]

Seriously: why not bin LibreSSL instead of fetchmail? I know of no compelling reason to run it instead of OpenSSL in my >50 servers >500 jails data centre ...

People would also say such things about Netbsd or OpenBSD
We need drama from time to time