** 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 _______________________________________________ Pan-devel mailing list Pan-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/pan-devel
