License incompatibility: linking against libsasl2 conflicts with GPL license

[sunweaver]

If you'd like to put out an incentive for fixing this bug, you can do so at https://issuehunt.io/r/LibVNC/libvncserver

Describe the bug
This bug was originally reported against Debian's bug tracker (see: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034358)

libvncserver (to be more precise: libvncclient) depends on libsasl2, which is licensed under CMU's BSD-3-Clause-Attribution license and covered by the
RSA-MD license. They have clauses in place, which are known to be incompatible with GPL (libvncclient1's license).

The preferred solution to amend this license incompatibility is:

3. Ask upstream to add a license exception for libsasl2-2, similar to the one that was required by Debian for OpenSSL
   for a long time.

(See the original Debian bug for the other solutions suggested by the bug reporter).

To Reproduce
Look at license headers of source files building libvncclient.

Expected Behavior
License chain compatibitlity including compatibility with libsasl2's license.

Logs/Backtraces
None.

Your environment (please complete the following information):

• Debian

Additional context
None.

[XZCE]

I use libvncclient, it works flawlessly for what I need, and my full build directory only has 1 filename that contains the term "sasl" - "sasl.h" which defines a couple of things (clearly not being used) and is written by S. Waterman (c) 2017 - and is GPL...

Since this repo is pure source code, and, without my awareness of reasons not to use sasl (of which, now I wouldn't, and it must have been something too hard for my meagre ability to get working anyway, and was easily turned off) how is sasl something that is "absolutely" depended upon by libvncclient?

It's not. It's clearly optional, so as licenses go, the end user has to make a decision on what is being accepted - which I didn't in the case of sasl - and I wouldn't put the onus on the "owner of something" that can simply make the use of a thing called sasl? A note somewhere here may be the most that's needed, "turn sasl off, unless you paid for it" would surely be enough, I wouldn't beg.

(And, thanks to the owner... I still appreciate the hard work done here.)

[bk138]

Hi @sunweaver, I've read https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034358 but am not sure what the call to action is 🧐. Someone has to ask libsasl upstream about a license exception?

[sunweaver]

Nope, the change needs to be done in all files (their license headers resp.) built into libvncclient. I can propose a PR (against this project, i.e. libvncserver sources).

[bk138]

Thanks, that would be super helpful! Do we need to get consent of the other authors of the respective files for that?

[sunweaver]

Unfortunately, yes.

[XZCE]

@sunweaver what is your interest in posting this bug report? It's a actually serious question, are you a lawyer practised in the software licencing field? Are you representing anyone?

I'll be interested in seeing the PR in any case.

[bk138]

@sunweaver what is your interest in posting this bug report? It's a actually serious question, are you a lawyer practised in the software licencing field? Are you representing anyone?

@XZCE he's the maintainer of libvncclient's Debian package and just acting in response to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034358#5

[bk138]

Unfortunately, yes.

Well, that's gonna be interesting ;-). Two questions:

• Just for the files using symbols from libsasl?
• I'm sure cases like this happened for other Debian packages, what did they do?

[XZCE]

Ahh, he is that "end user" I was talking about in my first post... Righto.

I also thought it was funny having to get permission from people no longer interested and/or deceased.

For what it's worth, what's here is a "complex instruction" of how something might or could work, but until you compile it and use it (and/or sell it somehow, probably via services) then there is no actual conflict with licensing.

But if it's easy and you're willing, then sure, making the changes is no big deal.

[bgermann]

If you want to get around relicensing and not ignore the issue for derivative works, i.e. compiled and linked binaries of your software: You can also switch to a GPL-compatible SASL implementation like gsasl which is the way that mutt went.

[bk138]

If you want to get around relicensing and not ignore the issue for derivative works, i.e. compiled and linked binaries of your software: You can also switch to a GPL-compatible SASL implementation like gsasl which is the way that mutt went.

Sounds interesting! Does it have the same funcionality like the other implementation?

[bgermann]

It should be the same. Maybe the available SASL mechanisms differ.