the peculiar libretunnel situation
The author of stunnel has (once, twice asserted that stunnel may not be used with LibreSSL, only with OpenSSL. This is perhaps a strange thing for free software to do, and it creates the potential for some very weird consequences.
First, some background. The OpenSSL license and the GPL are both free software licenses, but they are different flavors of freedom, meaning you can’t mix them. It would be like mixing savory and sweet. Can’t do it. Alright, so maybe technically you can do it, but you’re not supposed to. The flavor, er, freedom police will come get you. One workaround is for the GPL software to say, oh, but maybe wait, here’s an exception. (Does this make the software more or less free?) Here’s a longer explanation with sample exception.
The stunnel license says it may be combined with “code included in the standard release of OpenSSL under the OpenSSL License (or modified versions of such code, with unchanged license).”
So, the scene is set. What does it all mean?
One might say that LibreSSL is OpenSSL, making it all moot. This is in fact the position of the LibreSSL team. If you like us, er, agree with us, you can stop reading here. No worries.
The stunnel author apparently disagrees, however, because “I’m going to refrain from any actions that could potentially benefit LibreSSL.” So let’s pretend it’s different and see where that goes.
OpenBSD ships LibreSSL as part of the base operating system, so it’s already covered by the default system library exception in the GPL. Void Linux uses LibreSSL by default, so maybe it’s covered. But RedHat does not. So, theoretically, you’re allowed to use stunnel with LibreSSL on some Linux distros, but not on others. Better read the fine print.
The really strange thing, especially for a GPL program, is that he’s essentially asserting the right to amend the OpenSSL license to say “Please disregard all of the above. No forking permitted.” Ironic, considering the whole OpenSSL/GPL situation arises because the GPL prohibits additional restrictions. “No forking” is a pretty big restriction, no? I believe the legal term is tortious interference.
Again, all moot, since the stunnel license itself extends the exception to modified versions of OpenSSL. But regardless of efficacy, the declared intent is to prohibit forking. Not of his own software, but of somebody else’s. No BoringSSL either, presumably.
There’s actually another situation regarding the OCB patent license. There are various exceptions for open source software, non military software, and an extra exception for OpenSSL. There’s no chance of OCB ending up in LibreSSL, simply because it’s too hard to know when the exceptions stop applying. People take OpenBSD and make derived products from it, not all of which are open source. It would be cruel to booby trap the code base with latent patent conditions that only trigger in certain conditions. (The OpenSSL license here is kind of narrow in scope; I wouldn’t want to bet it always applies.)
Is there a lesson here? How about, keep your licenses simple? When you start handing out exceptions and exemptions, especially by name, you’re asking for trouble. A special case by any other name would not be as special. Something, something, Ship of Theseus.