[Pan-devel] OpenSSL and the GPL: License problems

[Duncan]

** The background.  

Skip down to the next ** line if you just want the point.

Here on Gentoo, I just recently upgraded ffmpeg.  It turns out that the 
latest ffmpeg has SSL support.  Now unlike most popular distributions, 
gentoo ordinarily only ships scripts to build sources (the liveCD and 
binary packages being exceptions, see below), so both license and patent 
issues affect it rather differently than they do many distros.

For patents, at least in the US where software patents are legal but free 
speech is a constitutional right, sources are generally considered a 
speech protected description of a possible implementation that would be 
argued to be covered by patent, so are fine, while the built binary, 
despite being the very same originally protected speech in machine 
language, no longer gets that speech protection and is considered an 
actual implementation subject to patent.  Crazy, but that's how it works, 
and as long as Gentoo ships only scripts to build sources (and mirrors 
the sources as it does), the only patents that directly affect Gentoo 
would be patents in the software shipped in binary form on the liveCD/DVDs 
and binpkg DVDs.

Luckily, we're not dealing with a patent issue here, however, just a 
license issue, with the GPL because both ffmpeg and pan are licensed 
under the GPL.  But because the GPL is concerned with ensuring that 
sources remain available for distributed binaries, again, Gentoo has 
relatively less to worry about than most distros, because it ships 
relatively few binaries.

But for the binaries Gentoo does ship, and as a meta-distribution, to 
help others who may be distributing binaries built using the Gentoo 
system, Gentoo has a USE flag (a flag that sets an option for the build-
time or install-time script, part of the system of scripts that make 
Gentoo what it is as a distribution) called "bindist".

On ebuilds (as these scripts are called) that have reason to use the 
bindist USE flag, if the user sets USE=bindist, it turns off whatever 
claimed patent-controlled optional feature, or in the case we're 
concerned about here, linking to whatever license incompatible optional 
libraries.

Here's the deal.  OpenSSL's license has an advertising clause that is GPL 
incompatible.  Luckily, the new ffmpeg has SSL support options for both 
OpenSSL, which Gentoo put under USE=bindist since it's incompatible with 
the general ffmpeg license, and GNUTLS, which is GPLed, so compatible 
with ffmpeg's GPL license.  As my global USE flags include bindist, gnutls 
and openssl all three, when I went to build the new ffmpeg, portage (my 
choice of three package managers supported in gentoo, the package manager 
being the interpreter for ebuild scripts) aborted with an error, telling 
me that I had to turn off either USE=bindist or USE=openssl.

It was investigating that error that made me aware of the openssl/GPL 
license incompatibility issue.

** Pan's problem.

Right now, pan's in the process of getting into the same sort of 
problem.  Pan is GPLed, and the GPL is incompatible with the OpenSSL 
license advertising clause.  Here's a description of the problem from one 
of the gnome folks:

http://people.gnome.org/~markmc/openssl-and-the-gpl.html

Pan's developing problem is that HMueller's SSL support is currently 
OpenSSL based.

As I explained above, it's not too much of an issue for source-based 
distros such as gentoo, so it's not a big deal for me (unless I go into 
the pan binary distribution business).  If this hits a released version, 
gentoo will simply stick the OpenSSL support under USE=bindist (plus 
either USE=ssl or USE=openssl), and ship the ebuilds and mirror sources 
as it normally would.  NNTP based access is obscure enough, it's unlikely 
that gentoo itself will ship a built-binary of pan, and if they did, the 
bindist would ensure that binary didn't have the openssl support builtin, 
and gentoo users would ordinarily rebuild from sources with the USE flags 
they wanted reasonably quickly anyway, so no big deal.

But for binary distros including both the big guys like Fedora and 
Ubuntu, and binary-based distros based on source-based distros like 
Sabayon (based on Gentoo), it's an ENTIRELY different matter!  They won't 
be able to ship pan binaries with OpenSSL support as that'd violate pan's 
GPL, which is the only thing giving them the legal right to distribute 
pan binaries.

** Pan's options.

What are the options?

1) Do nothing.  Continue on the present course, integrate SSL support 
using OpenSSL, and leave the binary distros and their users with the 
problem.  Since pan as currently released doesn't support SSL anyway, 
they won't be losing anything they have now, even if they can't ship an 
SSL supporting binary.  Users who want to can always build pan from 
sources themselves.

If we want to encourage users with the resources to do so, to build from 
sources, and don't particularly care whether the masses of ordinary users 
who simply run the binaries their distro ships get the new SSL support or 
not, this works fine.

It's worth noting that this would put those distributing and using pan on 
MSWindows in a bind as well.  There, the users face a rather higher 
hurdle to building from sources, as it's not something the "distro" 
normally supports, and it'd put the volunteers who currently ship 
MSWindows binaries they've built in a serious bind.  They could either 
ship with SSL support turned off and be legal, or decide to ship with it 
turned on and be technically illegal, but gamble that no one with pan 
copyright rights will choose to go after them.

In practice, this is likely to be a reasonable gamble, as only those with 
copyright interest in pan could sue, Charles Kerr is I'd guess unlikely 
to as he already demonstrated quite an interest in getting pan on 
MSWindows, given the work he put into getting it to work, and given the
C++ rewrite of 0.90+, it's arguable that not many before that still have 
the requisite rights.  And hmueller's implementing it, so isn't likely to 
sue.  That limits the group with legal standing to sue to a rather small 
list, khaley being foremost, plus all the folks who have contributed 
patches, depending on where the line is drawn at "too trivial to be 
copyrightable", a line that's not clearly drawn at this point.  Certainly 
there's a few others, but it's a limited list, and they'd have to decide 
they care about such a violation in ordered to pursue it, which would 
mean they'd have to know about it, which means they'd have to be 
following pan with enough interest to learn about it...

And even if someone did sue and win, the practical damages other than a 
cease and desist would presumably be rather limited.

Still, the community has been pretty good about encouraging copyright 
abiding behavior even when we don't entirely agree with the laws, and at 
least IMO that's not a position we really want to force our folks 
building for MS into.

2) Kill the SSL support entirely, or alternatively, only ship it in the 
live-git repo.  Strip it from version-tagged sources and the 
corresponding tarballs.

After all, pan has gone without the feature for over a decade, and nntp 
is dying, right, so it shouldn't matter at this point.  But somehow I 
don't see anyone really finding that argument or this option at all 
viable.  Option #1, just let the distros worry about it and disable the 
option if they feel the need, seems better.  Still, this is an option, if 
one I can't see anyone choosing.

3) Switch to gnutls or Mozilla nss.

Gnutls is GPLed so there's not an issue.  Mozilla's nss is tri-licensed 
MPLv1.1/GPLv2/LGPLv2.1, so again, it's not an issue.  But it seems of the 
three, nss is used least (outside of mozilla products), so with webkit 
based browsers now dominating, that's risking pan being the only thing 
pulling in nss on some systems, increasing pan's dependency weight.

This is a viable option but of course it will require some work.  And 
since Heinrich is the one doing the SSL implementation, it'd be primarily 
him doing the extra work.  Thus, absent someone else stepping up with a 
patch or credibly offering to do that work (I could offer but I don't 
code but bash scripts, so it wouldn't be credible), and let's face it, if 
that were likely it'd have happened already and we'd not be having this 
discussion, it's Heinrich that decides on this one.

4) Implement support for both/all-three openssl and gnutls and/or nss.  
This is what ffmpeg did (openssl gnutls) and it seems a reasonably common 
choice elsewhere, as well.

Since openssl support is pretty much there already, this wouldn't be 
/that/ much more work than #3, switching entirely to gnutls/nss.  It's 
similar in the other major characteristic as well; implementor's choice, 
implementor being Heinrich.

If this did happen, presumably it'd be a compile-time choice, and the 
binary distros (including the folks shipping MSWindows binaries, except 
that I'm not sure whether gnutls is available for MS or not) would simply 
choose the license compatible gnutls (or possibly nss), so the openssl 
support would in practice be for built-it-myself people only.

5) Compile a list of everybody with copyright interest in current pan, 
and get them to agree to a GPL exception clause.

Quoting from the gnome guy resource linked above:

>>>>>

One recommended way around this GPL incompatibility is to add an OpenSSL 
exemption when you license your code under the GPL. See this mail from 
debian-legal to a developer which suggests the following wording for the 
exemption:

 * In addition, as a special exception, the copyright holders give
 * permission to link the code of portions of this program with the
 * OpenSSL library under certain conditions as described in each
 * individual source file, and distribute linked combinations
 * including the two.
 * You must obey the GNU General Public License in all respects
 * for all of the code used other than OpenSSL.  If you modify
 * file(s) with this exception, you may extend this exception to your
 * version of the file(s), but you are not obligated to do so.  If you
 * do not wish to do so, delete this exception statement from your
 * version.  If you delete this exception statement from all source
 * files in the program, then also delete it here.

<<<<<

Of course, contacting everyone with legal copyright interest in pan and 
getting their consent will be a lot of work as well, altho it should be 
less work now than before the C++ rewrite, as that will have removed most 
of the historic code, some of which would have been from people far more 
difficult to trace down this far from the fact.

Also, I've literally /no/ idea whether or how far the permissions 
requirement would spread toward other pan dependencies.  Do we need to 
seek permission from all the gtk authors too, since pan links to gtk?  We 
may.  Certainly this is a choice that would require legal help, both in 
authoring the agreement for those with legal copyright interest to sign, 
and in advising how far we need to extend it.

As such, this choice doesn't seem particularly viable, either, since such 
legal help tends to cost money, unless we can get cooperation from 
whoever advises gnome on such things, or someone else in the community, 
perhaps the Debian legal folks, for instance.  But that's a lot of 
hassle, likely increasing the time and work cost of this option beyond 
viability even if it's not a financial cost.

And, even if the permissions thing is viable, there's no guarantee we'd 
actually get permission from everyone, thus obligating a code-around 
solution if their contribution is small enough, or dropping the idea 
entirely if it's too big.  So in practice, this option really does look 
to be inviable, due to the high cost with no guarantee of success even 
then.

** Conclusion

I guess that's it.  That's the problem and choices we have.  The 
conclusion from the gnome guy as linked above is worth quoting here:

>>>>>

The conclusion I draw from all this is that if want to use OpenSSL with a 
GPL program you should consider whether an OpenSSL exemption to the 
license is viable - i.e. do all the copyright holders for the affected 
code agree? Failing that, you could distribute the GPL program using 
OpenSSL but you are effectively trusting that the copyright holders for 
that program don't care. A much safer option is to use either the GNU TLS 
or Mozilla NSS library.

<<<<<

Given the options, that last sentence is worth repeating as my opinion as 
well:

"A much safer option is to use either the GNU TLS or Mozilla NSS library."

But, as the implementor, it would appear to be primarily Heinrich's 
choice.  Option #1 above, simply implementing OpenSSL support as a 
compile-time option (as is the current situation) and letting the binary 
distros choose not to enable it if they believe that's what they must do 
legally (as they certainly will), is the status quo and thus the easiest 
to go with.  But it's early enough in the process and many of the lessons 
learned with the openssl experience can be applied to gnutls or nss as 
well, that #3 or #4, switching to gnutls/nss or supporting openssl and 
one or both of them, are also viable, should Heinrich decide to do so, 
now that I've alerted him to the situation and options available.

Of course, if anyone sees that I've missed an option, please do post it.  
I've covered those I could think of, but that doesn't mean I didn't miss 
one or more!

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman