Cyrus-SASL and Debian

Pidgin
1

There’s been a brewing issue with our Debian package for Pidgin 2 that affects a lot of stuff. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036113

The TL;DR is that Cyrus-SASL is mostly licensed with a BSD license that has an advertisement clause that is believed to be GPL incompatible. Due to this incompatibility Pidgin and the 27 packages that depend on it are currently schedule to be removed from Debian on July 19th.

Obviously we’re not going to let this happen but there isn’t one quick solution which is why I’m pinging all of you.

For starters, we’re going to disable Cyrus-SASL in the Debian build. This will only affect users running testing/unstable, but I’m sure we’ll hear about it regardless. This is a stop gap to keep everything in Debian while determine how we’re going to move forward as we do need to remove Cyrus-SASL from everything else as well, including the Windows build.

The easiest solution for this to move to HASL, the new SASL library I wrote for Pidgin 3. HASL should cover most of our use cases and won’t be hard to implement the rest. But we probably will break some users here for at least a little while.

The real issues with HASL is that it was designed to automate some things we were doing manually with Cyrus-SASL which means the code to support both would be a pain. The other issue as I mentioned earlier is that we’ll have to build and package it for Windows and get it in our win32-dev environment which I’m not sure anyone actually knows how to do right.

Complicating the matter is that some platforms (I’m not sure which of the top of my head) treat Cyrus-SASL as a system/platform library so the license incompatibility doesn’t exist there and therefore we technically don’t need to do anything there.

Just to reiterate, this is ONLY for Pidgin 2, Pidgin 3 is unaffected as it only supports HASL.

Regardless, we need to make a decision soon, so this poll with close this Saturday at 00:00 UTC. Presumably, it’ll be me doing the work and the outcome doesn’t really mater, but at this point.

  • Drop Cyrus-SASL and do not implement HASL
  • Keep Cyrus-SASL and implement HASL
  • Drop Cyrus-SASL and implement HASL

0 voters

2

Does it have to be packaged separately for Pidgin2? Can’t it be added to the Pidgin repo so we don’t have to touch the win32-dev environment?

3

In theory, but then we’d have to integrate it into autotools and the mingw makefiles and throw away it’s build system. Remember pidgin 2 is autotools/custom “static” makefiles for windows.

4

I haven’t dealt with autotools much and I hear it’s painful but is it more painful than touching the win32-dev environment nobody knows anymore how to recreate?

Though if we decide to change the win32-dev env maybe that would be a good chance to take another shot at the crash at exit bug.

5

The Pidgin 2 windows build system is completely separate from the autotools build system that’s used elsewhere. So we’d have to update both build systems to put it in tree.

That said @eion has mentioned he would start looking at getting hasl built for the win32-dev directory so that does seem like the way to go.