PostgreSQL, OpenSSL, and the GPL

By Jake Edge
February 16, 2011

The OpenSSL license, which is BSD-style with an advertising clause, has been a source of problems in the past because it is rather unclear whether projects using it can also include GPL-licensed code. Most distributions seem to be comfortable that OpenSSL can be considered a "system library", so that linking to it does not require OpenSSL to have a GPL-compatible license, but the Free Software Foundation (FSF) and, unsurprisingly, Debian are not on board with that interpretation. This licensing issue recently reared its head again in a thread on the pgsql-hackers (PostgreSQL development) mailing list.

For command-line-oriented programs, the GNU readline library, which allows various types for command-line editing, is a common addition. But readline is licensed under the GPL (rather than the LGPL), which means that programs which use it must have a compatible license and PostgreSQL's BSD-ish permissive license certainly qualifies. But the OpenSSL license puts additional restrictions on its users and is thus not compatible with the GPL. Whether that is a real problem in practice depends on how you interpret the GPL and whether OpenSSL qualifies for the system library exception.

Debian has chosen a fairly hardline stance on the matter, which is evidently in line with the FSF's interpretation, so it switched to the BSD-licensed Editline (aka libedit) library instead of readline. PostgreSQL supports libedit as a readline alternative, so making the switch is straightforward. Unfortunately, a bug in libedit means that Debian PostgreSQL users can't input multi-byte characters into the psql command-line tool when using Unicode locales.

For the PostgreSQL project, it is something of a "rock and a hard place" problem. The OpenSSL code works well, and is fairly tightly—perhaps too tightly—integrated. There are two obvious alternatives, though, GnuTLS and Mozilla's Network Security Services (NSS). Switching to either of those would obviate the readline problem because their licenses do not contain the problematic advertising clause.

There have been efforts to switch PostgreSQL to use GnuTLS, as described in Greg Smith's nice overview of the history of the problem, but they didn't pass muster due to the size and intrusiveness of the patch. Part of the problem is that psql is too closely tied to OpenSSL as Martijn van Oosterhout, who developed the GnuTLS support, describes:

I spent some time a while back making PostgreSQL work with GnuTLS. The actual SSL bit is trivial. The GnuTLS interface actually made sense whereas the OpenSSL one is opaque (at least, I've never seen any structure in it). The GnuTLS interface was designed in the modern era and it shows.

The problems are primarily that psql exposes in various ways that it uses OpenSSL and does it in ways that are hard to support backward [compatibly]. So for GnuTLS support you need to handle all those bits too.

Another route to fixing the problem might be for either the readline or the OpenSSL license to change, but that is not a very likely outcome. Some GPL-licensed code has added an explicit "OpenSSL exception", but it is pretty implausible to expect the FSF to do so for readline—it has long seen that library as a way to move more projects to GPL-compatible licenses. OpenSSL is either happy with its license or is unable to change it as Stephen Frost points out in the thread:

aiui [as I understand it], the problem here is actually a former OpenSSL hacker who has no interest (and, in fact, a positive interest against) in changing the OpenSSL licensing. Most of the current OpenSSL hackers don't have an issue with the change (again, aiui).

Robert Haas recommends revisiting the GnuTLS support for the PostgreSQL 9.2 release, but in the meantime there are some Debian users who cannot easily use psql. It goes beyond just Debian, though, because Ubuntu will be picking up the PostgreSQL+libedit version for its next release. That spreads the problem further, as Joshua D. Drake, who started the whole thread, notes: "As popular as Debian is, the 'user' population is squarely in Ubuntu world and that has some serious public implications as a whole."

Instead of GnuTLS, NSS could be used and has one major advantage: Federal Information Processing Standard (FIPS) 140-2 certification. FIPS 140-2 is a US government standard for encryption that is sometimes required by companies and organizations when adopting products that contain encryption. OpenSSL has been FIPS 140-2 certified, as has NSS, but GnuTLS has not been. For that reason, there is talk of making PostgreSQL support NSS rather than GnuTLS.

The Fedora project is also looking at NSS as part of an effort to consolidate the cryptography libraries used by the project. For a number of reasons, including FIPS certification and some features missing from GnuTLS (notably S/MIME), NSS is the direction Fedora chose. One would guess that the GPL-incompatible license for OpenSSL played a role in eliminating it from consideration.

On the other hand, Fedora does ship various tools with both readline and OpenSSL, including PostgreSQL. It would seem that Fedora (and possibly Red Hat's lawyers) are relying on a belief that OpenSSL is distributed as a system library, as Fedora engineering manager Tom "spot" Callaway has said in 2008 and again in 2009. The project (and other distributions) may also be relying on the near-zero probability that the FSF will ever make a serious effort to stop the distribution of PostgreSQL using readline.

For Debian, though, that's not enough. Another Debian bug report contained more discussion of the problem, and a workaround discovered by Andreas Barth:

If calling psql as

    LD_PRELOAD=/lib/libreadline.so.5 psql

everything works as normal.

That's a bit of an ugly hack, and no one seems very happy about it, but the plan is to add the LD_PRELOAD (if libreadline is available) into the psql wrapper that is shipped in the postgresql-client-common package. Martin Pitt sums it up this way:

Technically, this is a bit fragile, of course, as there might be some subtle ABI differences which lead to crashes. However, the preloading workaround already makes the situation so much better than before, so IMHO it's better than the previous status quo.

I don't really like this situation, and personally I'd rather move back to libreadline until OpenSSL or readline or PostgreSQL threatens Debian with a legal case for license violation (I daresay that the chances of this happening are very close to zero..). But oh well..

This kind of licensing clash occurs with some frequency, and the OpenSSL license is known to be problematic—at least for projects that use GPL code. The advertising requirement, which is something of a throwback to the early days of the BSD license, makes OpenSSL increasingly isolated. Distributions and other projects are likely to continue to search for, and find, alternatives, if only to reduce the licensing murkiness and associated questions from developers and users. It is unfortunate that an ego-stroking clause or two in the license of a useful library may reduce its usage but, as always, free software will find a way to work around these kinds of problems and move on.

rlwrap can be used (and not just for psql!)

Posted Feb 16, 2011 19:01 UTC (Wed) by cortana (subscriber, #24596) [Link] (4 responses)

A safer/saner way to restore readline functionality:

$ rlwrap psql -n

rlwrap is a really great program. It will add readline functionality to any other line-oriented program.

rlwrap can be used (and not just for psql!)

Posted Feb 16, 2011 20:15 UTC (Wed) by dskoll (subscriber, #1630) [Link]

Thank you for that! I didn't know about rlwrap. It's terrific!

rlwrap can be used (and not just for psql!)

Posted Feb 16, 2011 23:23 UTC (Wed) by davide.del.vento (guest, #59196) [Link] (1 responses)

Yes, rlwrap is very good.
But unfortunately it breaks autocompletion, so it's not a full substitute for readline.
I guess for the time being the real "solution" is for everybody to recompile their own psql against readline and openssl.

rlwrap can be used (and not just for psql!)

Posted Mar 13, 2011 22:23 UTC (Sun) by trekker.dk (guest, #65149) [Link]

Not that hard - at least in version 9.0.3 this worked:

# apt-get build-dep postgresql-client-9.0
$ apt-get source postgresql-client-9.0
$ cd postgresql-9.0-9.0.3/
$ fakeroot-sysv debian/rules binary
# dpkg -i postgresql-client-9.0_9.0.3-1_amd64.deb

Or something along those lines. $ and # characters denote privileges needed (root/user)

rlwrap can be used (and not just for psql!)

Posted Feb 20, 2011 10:24 UTC (Sun) by fjalvingh (guest, #4803) [Link]

Thank you! I did not know that!

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 19:21 UTC (Wed) by madscientist (subscriber, #16861) [Link] (17 responses)

The licensing pain is real, for sure, but OpenSSL is really all kinds of bad news. They, or whomever packages them, have absolutely no clue when it comes to shared library support/backward compatibility. What a nightmare.

NSS has one other very significant advantage over GnuTLS and OpenSSL not mentioned in this article: NSS has been blessed as the standard SSL library for LSB. So it will be available on all LSB-compliant installations.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 20:07 UTC (Wed) by foom (subscriber, #14868) [Link] (3 responses)

It has one significant disadvantage though: almost nothing uses it. :)

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 20:39 UTC (Wed) by madscientist (subscriber, #16861) [Link] (2 responses)

Well, compared to OpenSSL that might be true but I wouldn't say "almost nothing": all the Mozilla apps obviously use it (Firefox, thunderbird, etc.) Additionally (according to wikipedia) it's used by Chrome, Evolution, Pidgin, OpenOffice, various Red Hat services and various Sun Java services.

Numerically maybe not so impressive but there are some pretty high-profile users there.

The main point, though, is not how many applications use it but the fact that it's (a) correctly backward compatible, and (b) guaranteed to be available on all LSB systems. LSB has a bad rep but it IS a useful baseline that's very nice to rely on, for what it contains, and virtually every serious Linux distro supports it now.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 2:11 UTC (Thu) by jamesh (guest, #1159) [Link] (1 responses)

Furthermore, those applications probably account for the majority of SSL connections established on most people's machines, and the largest number of different servers connected to. So the actual networking code is probably just as robust as OpenSSL.

The main issue is whether the API it provides makes it as easy to integrate into applications as the OpenSSL API does.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 15:54 UTC (Thu) by lkundrak (subscriber, #43452) [Link]

Well, there is nss_compat_ossl library which implements a subset of openssl API on top of NSS. For most software it takes very little effort to carry them over from openssl, just to be on the safe side.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 20:35 UTC (Wed) by jengelh (guest, #33263) [Link] (3 responses)

>NSS has been blessed as the standard SSL library for LSB.

Being part of some standard won't magically proliferate it.

$ for i in mozilla-nss libgnutls26 libopenssl1_0_0; do rpm --test -e "$i" 2>&1 | pcregrep -o '(?<=$installed$ )\S+' | sort -u | wc -l; done
7
9
63

..I still wait for the day until a "beautiful" API comes around. One that does not hide pointers behind, or use, typedefs, but rather ptrs to <incomplete> structs, does so in lower-case, and also has a prefix of sorts. No library fulfills all of these atm.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 21:18 UTC (Wed) by madscientist (subscriber, #16861) [Link]

See my above comment. I don't care how many different apps use it... why should that matter? Enough serious applications rely on it to ensure it's not overtly buggy and doesn't contain lots of silly security holes and that's all that's important. Having it part of LSB ensures it will be there, and it will be supported, and it will be backward compatible. That's absolutely critical for those who don't want to be forced to recompile their software for every given distro and distro version.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 15:59 UTC (Thu) by lkundrak (subscriber, #43452) [Link] (1 responses)

[lkundrak@potwor ~]$ rpm -q --whatrequires libcrypto.so.10 |wc -l
63
[lkundrak@potwor ~]$ rpm -q --whatrequires libnss3.so |wc -l
23

PostgreSQL, OpenSSL, and the GPL

Posted Feb 18, 2011 1:23 UTC (Fri) by vonbrand (subscriber, #4458) [Link]

This is obviously only applicable to your specific packages installed

LibNSS advantages

Posted Feb 17, 2011 2:56 UTC (Thu) by ringerc (subscriber, #3071) [Link] (8 responses)

There's more than one advantage to NSS.

Unlike OpenSSL and GnuTLS, which are crypto and SSL libraries, NSS is a more complete system with key management support, PKCS#11 support, etc. Rather than apps having to implement all their own key storage and management, they just use the existing libnss database and tools. Best of all, you can have a shared per-user key database, so you can FINALLY avoid having to install your X.509 client certificate manually into every app you use individually.

Key management in Linux is a shrieking nightmare for administrators and no fun for users either. I'd love to see libNSS more widely adopted as it'd really help address that.

LibNSS advantages

Posted Feb 17, 2011 3:14 UTC (Thu) by foom (subscriber, #14868) [Link] (7 responses)

But that doesn't even work between Firefox and Thunderbird!

LibNSS advantages

Posted Feb 17, 2011 3:26 UTC (Thu) by ringerc (subscriber, #3071) [Link] (6 responses)

Neither Firefox nor Thunderbird are set up to use it. Grr!

LibNSS supports a shared SQLite database but nobody wants to agree on where to keep it or whether to use it at all. They all want to stick to how they used to do it. Evolution uses gnutls and its own key management; ff and tbird use private libnss keystores; ssh doesn't even use x.509 certs at all (argh!).

You can enable the shared keystore with one line of code, but nobody's shipping FF and tbird configured that way, let alone adopting it for other apps. Very frustrating. Because few devs use X.509 client certificate infrastructure, it doesn't seem to get much attention/interest.

LibNSS advantages

Posted Feb 17, 2011 5:58 UTC (Thu) by djao (guest, #4263) [Link] (4 responses)

LibNSS supports a shared SQLite database but nobody wants to agree on where to keep it or whether to use it at all. They all want to stick to how they used to do it.

The problem with the shared database is that it breaks backward compatibility. My keys are already in the right configuration file, and the current version of the program that I have already installed expects the key to be in that file. I don't want to be forced to move my keys somewhere else, much less an opaque database. A real UNIX admin prefers flat human-readable text configuration files for any number of reasons. There appears to be no sane way to simultaneously support both in-database keys and configuration-file keys in NSS.

I recently ran into this problem in Fedora's version of openswan, which uses NSS for key storage instead of flat text files like the openswan in every other Linux distribution. This makes key management in Fedora's openswan a huge hassle (you cannot just copy over keys in files). If openswan supported both key databases and keys in files, then there would be no problem. But it doesn't.

LibNSS advantages

Posted Feb 17, 2011 7:10 UTC (Thu) by ringerc (subscriber, #3071) [Link]

The SQLite database replaces the existing nss key3.db and cert8.db files, which are Berkeley DB files. It doesn't replace any text-based configuration mechanism a program may offer for key access.

NSS may be used to load keys from files pointed to by a config file, just as OpenSSL and GnuTLS may. It adds the _option_ of a keystore if you want to use it, but doesn't force it. The issue you ran into sounds like a heavy-handed conversion to nss done by the Fedora folks, rather than an issue inherent to NSS its self.

LibNSS advantages

Posted May 27, 2013 21:10 UTC (Mon) by Jehreg (guest, #91153) [Link] (2 responses)

Let me be clear: This change was done to Openswan by Fedora. Xelerance never forced the use of LIBNSS, as you can see from the authoritative repository held at Github : https://github.com/xelerance/Openswan.git

Xelerance will be issuing a new version (2.6.39) in the next few weeks, and LIBNSS will still not be forced. If Fedora decides to be idiots and force LIBNSS then they will have to answer to their clients, as Xelerance will recommend running other distributions to their clients and partners.

Patrick Naubert
Xelerance Corp.

LibNSS advantages

Posted May 27, 2013 21:31 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

You do realize you are posting to a news story from several years back? If you have a problem with downstream packaging, talk to them, file a bug report or post in their development list and reference that in such conversations.

LibNSS advantages

Posted May 27, 2013 22:27 UTC (Mon) by nix (subscriber, #2304) [Link]

btw, your handle should be spelt 'Jhereg'. :)

LibNSS advantages

Posted Feb 17, 2011 7:16 UTC (Thu) by corsac (subscriber, #49696) [Link]

Evolution uses NSS for all the mail-related code (imap/pop/smtp) and uses the shared nss database (from /etc/pki/nssdb and $HOME/.pki/nssdb). It uses gnutls only through libsoup for http/webdav calendars.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 20:24 UTC (Wed) by dberkholz (guest, #23346) [Link] (7 responses)

Am I understanding correctly that this whole discussion is because nobody's fixing a bug in libedit?

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 20:40 UTC (Wed) by mbanck (subscriber, #9035) [Link]

The only weak spot in the article is that it makes it seem there is but one small issue in libedit. It rather appears to be that there is more breakage involved and it is not clear fixing it up will be trivial and really, this is not the PostgreSQL developer's job. Plus, unicode bugs are rarely easy.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 20:41 UTC (Wed) by sfeam (subscriber, #2841) [Link]

Am I understanding correctly that this whole discussion is because nobody's fixing a bug in libedit?

Calling it a "bug" isn't really correct. libedit simply doesn't have any support for UTF-8. Or wait - you could say it's a bug in the documentation; the source distribution site www.thrysoee.dk/editline/ does mention UTF-8 support, but having gone over the source code I conclude that whoever wrote that did not understand the difference between support for "wchar" fixed-length 16 bit or 32 bit encodings and support for a variable length encoding like UTF-8. libedit recently added support for the former, but I found no hint of support for the latter.

The gnuplot project has been suffering from this problem for a long time now. It would be nice to offer the option of linking to libedit (in fact we do offer that option) but it simply doesn't work in a UTF-8 or SJIS environment. This is particularly annoying because Apple ships a version of libedit with OSX that announces itself as "readline". But it isn't, so programs that autoconfigure to use readline then fail because "readline" is really "libedit".

Now I would be happy as a clam if someone can tell me otherwise, and point to source for a libedit version, buggy or not, that does really support UTF-8. Anyone?

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 20:42 UTC (Wed) by rvfh (guest, #31018) [Link]

That's what I understand from the article as well, the but licensing issue is so much more interesting... NOT!

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 20:43 UTC (Wed) by obrakmann (subscriber, #38108) [Link] (3 responses)

I think so... It's mind-boggling, really, if it's true.

Especially since Debian seems to use a libedit from 2008 (according to the package version at least: 2.11-20080614-2), while the latest changelog entry from 2010 (on the homepage linked to from this article) says "Now with UTF-8 support"

Lovely.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 20:50 UTC (Wed) by mbanck (subscriber, #9035) [Link] (2 responses)

People tried the latest libedit version with psql and it was still (differently) broken.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 22:27 UTC (Wed) by mikov (guest, #33179) [Link] (1 responses)

It seems to me that fixing libedit, or even rewriting it from scratch should be much easier than replacing OpenSSL. I mean, editing a single line of text is a problem? Really? Can someone explain why?

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 5:06 UTC (Thu) by khim (subscriber, #9252) [Link]

I mean, editing a single line of text is a problem? Really? Can someone explain why?

Sure. It's easy: because this book weights over five pounds (2kg)...

Editing of a single line of US-ASCII text is easy and libedit does it acceptably well. But when you go beyond that... some characters take two positions on screen, some don't take anything at all, etc. Readline does not do it all that well, but in comparison to libedit... well, it's not so simple to edit a single line of text, believe me...

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 20:36 UTC (Wed) by josh (subscriber, #17465) [Link] (5 responses)

Technical considerations about library quality aside, quite a bit of software uses OpenSSL, and it represents one of the most common issues of GPL-incompatibility between FOSS licenses. If the OpenSSL license really comes down to a single developer objecting, with all other developers not caring about it, then perhaps someone could take the time to document precisely the contributions of that developer for wholesale rewriting?

Alternatively, I wonder just how much work it would take to make GnuTLS's OpenSSL compatibility layer complete and working, or create such a layer for NSS.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 21:07 UTC (Wed) by foom (subscriber, #14868) [Link] (1 responses)

GnuTLS's openssl layer is even worse license-wise: that's under the GPL! (not LGPL).

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 21:18 UTC (Wed) by josh (subscriber, #17465) [Link]

That wouldn't pose any problem for the various GPL code that currently links to OpenSSL and adds a license exception (or worse, doesn't).

It's not so easy...

Posted Feb 17, 2011 5:10 UTC (Thu) by khim (subscriber, #9252) [Link] (2 responses)

If the OpenSSL license really comes down to a single developer objecting, with all other developers not caring about it, then perhaps someone could take the time to document precisely the contributions of that developer for wholesale rewriting?

If only it were so easy. First of all: it's not "a single developer", it's two: Eric A. Young and Tim Hudson. And these are the guys who wrote the whole thing initially! It'll be very-very hard to rip all that code out, believe me. Not impossible, but "rewrite from scratch" will be simpler approach - and it was done quite few times. You only need to pick suitable library...

It's not so easy...

Posted Feb 17, 2011 6:48 UTC (Thu) by josh (subscriber, #17465) [Link]

Fair enough. Sounds like a compatibility layer for GnuTLS or NSS will prove far easier.

It's not so easy...

Posted Feb 18, 2011 5:21 UTC (Fri) by samroberts (subscriber, #46749) [Link]

And they work for RSA, who sells a commercial competitor to OpenSSL. They may have a financial disinterest in making OpenSSL easier to use, its not simply ego-stroking.

The problem with ossl is that horrid and old-school as the C API is (and the command line interface isn't much better), there is a HUGE amount of valuable code in it supporting tons of crypto algorithms and formats with very fast implementations and years and years of interoperability testing and hacks.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 20:36 UTC (Wed) by mattdm (subscriber, #18) [Link] (1 responses)

I don't think the "system library" exception applies when the system library is distributed together with the GPL-licensed work -- as it would be in any Linux distro.

Correct...

Posted Feb 17, 2011 4:50 UTC (Thu) by khim (subscriber, #9252) [Link]

This is the relevant part:

However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable (emphasis mine).

If the PostgreSQL is included on CD it's pretty hard to argue that "that component itself does not accompanies the executable". Of course we'll only know if/when FSF will sue RedHat (or at least will clearly write that you can not link program with both libreadline and opensll and then distribute it as part of CD) because it's very-very gray area...

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 21:33 UTC (Wed) by joey (guest, #328) [Link] (25 responses)

I'm highly doubful that the LD_PRELOAD hack will survive a legal review.

It's perfectly legal to use the hack (or rlwrap) on your own computer, but
shipping it in the same package with the code that "doesn't link" to libreadline is really just shipping some code that finds a new and unusual way to link to libreadline.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 21:43 UTC (Wed) by dlang (guest, #313) [Link] (9 responses)

in a way I'd love to see this go to court and see if dynamic linking by itself can be deemed to create a derived work.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 0:20 UTC (Thu) by gmaxwell (guest, #30048) [Link] (4 responses)

Sigh.

Your distributor relied on the license in order to create the CD containing the GPLed work and openssl. From then on out they were bound by the relevant licenses by virtue of the copying alone.

The legal definition of a derived work isn't especially relevant: If the GPL said that you could only use the software on a machine with no microsoft products, then thats the rule. You don't have to ask if the microsoft products are a derived work in order to answer questions about being able to use the licensed work itself.

The license can do whatever it likes, and your option and obligation is to not distributed the GPLed software if you are can't/won't meet the licensing requirements. So the relevant question is "what does the GPL require?"

The whole concept of derived works is a pure distraction for linking boundary questions when you're asking about someone who distributes _both_ the GPL and the non-GPL thing. The legal derived work boundary only matters when someone is claiming that they have no obligations under the GPL because they don't distribute the GPLed thing.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 18, 2011 0:14 UTC (Fri) by giraffedata (guest, #1954) [Link]

Your distributor relied on the license in order to create the CD containing the GPLed work and openssl. From then on out they were bound by the relevant licenses by virtue of the copying alone.

You've got this all turned around. A license doesn't restrict people; it permits them. You don't copy and then have to do what the license says; you meet the conditions of the license and then you have permission to copy. After you make that legally permitted copy, the license is irrelevant.

Some publishers extend their control with a contract (EULA): in exchange for a license to copy, the copier promises never to use Microsoft products in the future. Now the publisher can enforce that contract -- not the license. Some people believe a contract like that is formed whenever someone avails himself of a public license such as GPL. Some don't. But either way, the contract is quite distinct from the copyright license.

I agree with you that a copyright licensing scheme for readline could stop people from shipping readline in a package with openssl to be dynamically linked, and do it without involving any rights over derived works.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 18, 2011 1:35 UTC (Fri) by vonbrand (subscriber, #4458) [Link] (2 responses)

Careful here. GPL is a license, in that it allows you to do certain things that under normal circumstances you aren't allowed to do under the law. If the law says that just linking two binary blobs doesn't create a derivative work of either one, FSF can insist until they are blue in the face that GPL doesn't allow linking to non-GPL-compatible stuff on the theory that that creates a derivative, but you are allowed to do it anyway (by the law).

PostgreSQL, OpenSSL, and the GPL

Posted Feb 18, 2011 2:42 UTC (Fri) by gmaxwell (guest, #30048) [Link] (1 responses)

You appear to be perpetuating a common misunderstanding.

Absent the permissions provided in the license you are not legally permitted to do much with the covered work. If you want to perform some act reserved to the copyright holder (like copy the covered work with or without combining it with other things) then you may legally do so only by the good graces of the license.

This is the relevant hook. Quoting v2, "You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or _distributing the Program_ (or any work based on the Program), you indicate your acceptance of this License to do so, and _all its terms and conditions_ for copying, distributing or modifying the Program or works based on it." (em mine)

The FSF can't stop you from wearing party hats*, but they can write a no party hat condition into their license, and your only options are to decline to practice the copyright-exclusive acts (distributing the software), eschew party hats, or violate copyright (at your own legal peril).

Moreover, if it _didn't_ work this way if the license continued to permit copying when you violate its terms then the license could have no useful effect except creating a blanket permission. The GPL makes _many_ such requirements of normally permitted activities conditions for enjoying the license, e.g. offering the source code.

In the few cases where someone might link to GPLed code without ever subjecting themselves to the requirements of the GPL (e.g. by not distributing the covered work or engaging in other copyright-protected activities, including creating derivatives in the strict legal sense) then they can potentially get away with it. An example of this might be a proprietary software vendor linking a GPLed system library which they are careful to never distribute themselves.

*[A silly example; I would expect a court to invalidate such a term as having no meaningful connection to the licensed activity. The same could not be said about rules about how the software was employed]

PostgreSQL, OpenSSL, and the GPL

Posted Feb 22, 2011 17:16 UTC (Tue) by nye (subscriber, #51576) [Link]

>You appear to be perpetuating a common misunderstanding.

You should re-read the post to which you are replying - I believe you've entirely misunderstood what vonbrand wrote.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 15:56 UTC (Thu) by paulj (subscriber, #341) [Link] (3 responses)

It can't. In a similar fashion, working around dynamic linking with some technical trick can't "un-derive" one work from another either. In short, the technical arcania may not be massively relevant to the derivation question.

E.g. Google have put Bluez in Android behind a DBus IPC interface, because Bluez is GPL and they wish to insulate proprietary applications that build on Android's Bluetooth stack from the GPL. While it may technically succeed in isolating such apps from the bluez library /API/, legally it need *not* change the fact that codes X,Y,etc are dependent on code Y.

At least, that's the legal advice I'm aware of from the corporate counsel of a different, large technology counsel, in a very similar situation code/IPC wise.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 28, 2011 9:29 UTC (Mon) by salimma (subscriber, #34460) [Link] (2 responses)

In the Android case, wouldn't BlueZ be considered part of the system libraries, in which case it's a moot point whether apps using it indirectly through the DBus layer are considered derivatives or not?

PostgreSQL, OpenSSL, and the GPL

Posted Feb 28, 2011 9:52 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

Perhaps. Maybe Google lawyers are being extra cautious. It doesn't really hurt them to do that.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 28, 2011 11:33 UTC (Mon) by paulj (subscriber, #341) [Link]

The system library exception exists to allow GPL apps to link to proprietary apps. It does not apply in the opposite direction, i.e. it can not give proprietary apps permission to derive from a GPL work. IMU.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 21:56 UTC (Wed) by joey (guest, #328) [Link]

minor correction: rlwrap does not cause anything to link to libreadline.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 23:49 UTC (Wed) by butlerm (subscriber, #13312) [Link] (13 responses)

is really just shipping some code that finds a new and unusual way to link to libreadline

It is entirely possible for the FSF to license libreadline in such a way that it cannot be distributed in conjunction with code that does that dynamically, but the idea that doing so is in itself the creation of a legally prohibited derived work is unusually dubious logic.

Even if the co-existence of a library and application code in memory is considered to be some sort of "derived work" (which is highly doubtful), 17 USC 117(a)(1) is sufficiently explicit as to authorize the end user to do all that and more, including creating statically linked versions, if necessary to run legitimately acquired software "on a machine":

Making of additional copy or adaptation by owner of copy. Notwithstanding the provisions of section 106 [17 USC 106], it is not an infringement for the owner of a copy of a computer program to make or authorize the making of another copy or adaptation of that computer program provided: (1) that such a new copy or adaptation is created as an essential step in the utilization of the computer program in conjunction with a machine and that it is used in no other manner

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 4:15 UTC (Thu) by vonbrand (subscriber, #4458) [Link] (12 responses)

It is not just linking, to use readline you have to use it's API, and that can be construed to create a work derivative of readline

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 10:22 UTC (Thu) by cortana (subscriber, #24596) [Link] (1 responses)

Wouldn't that make libedit a derivative of readline?

MySQL AB formerly claimed that re-implementing libmysql's interface would create a derived work. They also used to claim that writing another SQL server that implemented the MySQL protocol would do the same!

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 16:13 UTC (Thu) by njs (subscriber, #40338) [Link]

Anything that's "purely functional" -- e.g., it's the only possible way to accomplish something, like talk to a MySQL server -- is by definition not covered by copyright. What that means in particular cases is not always obvious...

There's a plausible argument that the existence of libedit means that psql *per se* is not a derived work of readline. But that doesn't matter for people who are shipping psql+readline compiled together -- that combination is *clearly* a derived work of both.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 16:10 UTC (Thu) by butlerm (subscriber, #13312) [Link] (9 responses)

It is not just linking, to use readline you have to use it's API, and that can be construed to create a work derivative of readline

That is the most pathetic sort of legal fiction imaginable. Not only is it irrational and impractical (every Win32 program is a derivative of Windows, every POSIX program is a derivative of UNIX, etc) it is contradicted by dozens of legal precedents. Baystate v. Bentley Systems (1996) perhaps the most explicit of those. See here for example (pdf).

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 20:48 UTC (Thu) by kleptog (subscriber, #1183) [Link] (8 responses)

Well, not totally fictional. During the compilation process the header file of readline is combined with the source code of the program and the result is processed by the compiler into a single object file and eventually into an executable. Unless you want to suggest that the contents of the header have no influence at all I don't think you can suggest the binary is not derived from the header file.

The reason your windows programs is not affected by this is because the licence of the relevant files is such that you are specifically allowed to use them to compile your programs and have no effects on the licence of the result.

That case you refer to doesn't really apply since it's talking copying (reverse engineering) an interface for compatibility, whereas we're talking the literal textual copying of file with an explicit licence. You are not being forced to use the readline interface.

[Be careful to separate two issues: PostgreSQL is not a derived work of readline, but any PostgreSQL binary you compile using the readline headers is.]

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 21:09 UTC (Thu) by dlang (guest, #313) [Link]

the very real question is if the header file is copywriteable.

remember things that are purely functional, or are constrained by interoperability requirements are not copywritable.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 21:21 UTC (Thu) by sfeam (subscriber, #2841) [Link] (6 responses)

How do you reach that conclusion? Where is this "textual copying" in the case of C language header files? The literal text of readline.h, if it is copyrightable at all, appears nowhere in the compiled binary. As already mentioned in earlier comments, there is ample [USA] precedent that using the published API of a library does not make the caller a derived work. So if it is OK for a program to use the library API, and no library text is copied, what is your basis for stating that the binary is a derived work of an external library? I am aware that some people make a strong distinction between linking to a shared library (OK) and including the library itself into a static executable (arguably not OK). That may or may not be a tenable distinction, but it doesn't hinge on use of the header files.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 18, 2011 1:42 UTC (Fri) by vonbrand (subscriber, #4458) [Link] (5 responses)

The (USA) problem here is that a decision one way or the other here can only result from a final decision in a (multi-million) lawsuit over this obscure point, and that is rather unlikely to happen (FSF vs OpenSSL?).

PostgreSQL, OpenSSL, and the GPL

Posted Feb 18, 2011 6:24 UTC (Fri) by butlerm (subscriber, #13312) [Link] (4 responses)

A stronger (USA) precedent than any project here would ever need was set by Baystate v. Bentley Systems (1996). The key holding is that technical interfaces are not copyrightable. Not just binary interfaces, but structure and element names. See here (pdf).

Even if this ruling didn't exist, in no way is it reasonable to conclude that the resulting binary of a compilation process that includes an ordinary header file to be "based upon" that header file. The reason why is that the compiler doesn't include any part of an ordinary header file in the resulting binary - it simply refers to information contained within it. Big difference.

As a consequence the resulting binary is not "substantially similar" to the header file in any way, and thus cannot seriously be considered to be "based upon" it. If merely referring to information from another source made something a derived work, all academic research would stop tomorrow. That's absurd, the courts know it, and so they exercise a modicum of sanity (where they can) when issuing rulings like this.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 19, 2011 6:16 UTC (Sat) by dvdeug (guest, #10998) [Link] (3 responses)

All of an ordinary header file is included in the code that is sent to the compiler. How you define included in the resulted binary I don't know; usually none of the text of code is included in the output, except for function names, like those included in the header. If you're only including code, the following define from openssl/engine.h compiles a function into the binary of the program instead of keeping it into the library.

#define IMPLEMENT_DYNAMIC_BIND_FN(fn) \
OPENSSL_EXPORT \
int bind_engine(ENGINE *e, const char *id, const dynamic_fns *fns) { \
if(ENGINE_get_static_state() == fns->static_state) goto skip_cbs; \
if(!CRYPTO_set_mem_functions(fns->mem_fns.malloc_cb, \
fns->mem_fns.realloc_cb, fns->mem_fns.free_cb)) \
return 0; \
CRYPTO_set_locking_callback(fns->lock_fns.lock_locking_cb); \
CRYPTO_set_add_lock_callback(fns->lock_fns.lock_add_lock_cb); \
CRYPTO_set_dynlock_create_callback(fns->lock_fns.dynlock_create_cb); \
CRYPTO_set_dynlock_lock_callback(fns->lock_fns.dynlock_lock_cb); \
CRYPTO_set_dynlock_destroy_callback(fns->lock_fns.dynlock_destroy_cb); \
if(!CRYPTO_set_ex_data_implementation(fns->ex_data_fns)) \
return 0; \
if(!ERR_set_implementation(fns->err_fns)) return 0; \
skip_cbs: \
if(!fn(e,id)) return 0; \
return 1; }

PostgreSQL, OpenSSL, and the GPL

Posted Feb 19, 2011 17:01 UTC (Sat) by butlerm (subscriber, #13312) [Link] (2 responses)

I said an "ordinary" header file for a reason. Inline functions of any sophistication are clearly an exception. They are also pretty much useless for any library that wants to maintain binary compatibility.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 19, 2011 23:07 UTC (Sat) by nix (subscriber, #2304) [Link]

Not necessarily. I've written a good few headers which define convenience functions as static functions in the header file, which only call other public functions with guaranteed API/ABI. This makes them inlinable even if the bulk of the library is in a shared object and thus not amenable to cross-translation-unit inlining from its users, while simultaneously being quite safe compatibility-wise: if the functions they call break, they'd break for all their other users too. The only real downside is that bugs fixed in those functions will not be reflected by their users until those users are recompiled.

Static functions in the header which mess with non-API-guaranteed stuff are exactly as bad as allowing your users to mess with such stuff in the first place. In both cases, the answer is the same: Don't Do That.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 23, 2011 22:44 UTC (Wed) by dvdeug (guest, #10998) [Link]

But that is part of the code that libssl may compile into your program. Glibc will compile similar chunks into your code; see bits/stdlib.h. Or libpng/png.h where png_composite is a small chunk of inline code. There's enough of these files to say that to exclude these from being "ordinary" header files, /usr/include has an awful lot of header files that are or include superordinary files.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 21:52 UTC (Wed) by bagder (guest, #38414) [Link]

On a related subject, I did a talk in Fosdem 2011's security devroom about libcurl and its support of 7 different SSL libraries and a bit about how they stack up in a comparison. Link follows to a youtubed recording:

http://www.youtube.com/watch?v=y3cfEP05LDA

PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 22:06 UTC (Wed) by fuhchee (guest, #40059) [Link] (4 responses)

This LD_PRELOAD hack reminds one of the confusion associated with that
"derived work" term. While the FSF unofficially advises an expansive
definition ("anything that links"), here LD_PRELOAD can allow completely
decoupled distribution of the two pieces of code without any plausible
license-cross-infection claim. That in turn puts that expansive
definition into some doubt.

Again: "derived work" is meaningless here.

Posted Feb 18, 2011 6:07 UTC (Fri) by khim (subscriber, #9252) [Link] (3 responses)

While the FSF unofficially advises an expansive definition ("anything that links"), here LD_PRELOAD can allow completely decoupled distribution of the two pieces of code without any plausible license-cross-infection claim.

Yes, of course. Unless you'll include such script in your distribution and make it available by default. You see, GPL is pretty expansive: if forces you to distribute everything derived from GPLed sources to be distributed under GPL terms. Including whole distributions! But there are couple of exceptions: system libraries ("unless that component itself accompanies the executable") and "mere aggregation". Now, of course libedit-linked postgresql is not infringing. But what about distribution which forces usage of readline injected in postgresql client? This very much a grey area. If it's unconditionally injects the readline then it can probably viewed as a clever way to circumvent the GPL requirement. But if it's configurable and user can select one of two choices... then it's more like mere aggregation - but only court can say for sure... and two different courts may decide differently too.

We can argue till we blue in face but because law is squishy there are no resolution till actual court proceeding will occur. We can only estimate probabilities of different outcomes, really.

Again: "derived work" is meaningless here.

Posted Feb 18, 2011 15:14 UTC (Fri) by fuhchee (guest, #40059) [Link] (2 responses)

"You see, GPL is pretty expansive: if forces you to distribute everything derived from GPLed sources to be distributed under GPL terms."

No, that is not the "expansiveness" what I was referring to. It was that the FSF has taught people to think of *linkage* as being an obvious example of *derivation*, despite e.g. Sega v. Accolade.

Sorry, but this is quite different...

Posted Feb 18, 2011 16:28 UTC (Fri) by khim (subscriber, #9252) [Link] (1 responses)

Sigh. Sega never distributed anything from Accolade. Accolade never distributed anything from Sega.

There are no doubt that if distribution does not include readline library but includes openssl library you are allowed to link your product with both [system] openssl and [non-system] readline: the whole thing which you are distibuting is most probably not derived (like in Sega v. Accolade case) and, in fact, GPL contains explicit permission for such a case.

Now, if you distribute the single package on a CD which includes both openlssl and readline then there are no doubts that this combination is compilation of both works! You don't even need any linkage for it to be compilation - and while compilations have some additional rules you still need permissions from all authors. GPL gives you two choices: either the whole compilation is distributed under GPL or you can combine totally unrelated things to form it ("mere aggregation" clause).

Sega v. Accolade will be relevant in cases like nVidia driver: where some piece is distributed under GPL, another piece under proprietary license but they are never combined to form the single compilation (except by the end user who has a right to do this and more as long as he does not distribute the result).

So... Close but no cigar.

P.S. It's interesting to note that by your reasoning you actually can include LGPLed (and even GPLed) libraries in distribution and as long is interfaces are not too rich (== don't include tons of non-trivial inlined functions) third-party developers will be allowed to use them. Again: as long as these third-party developments don't come pre-installed. This interpretation may even be correct, but it's not relevant to Debian case.

Sorry, but this is quite different...

Posted Feb 24, 2011 4:16 UTC (Thu) by jjs (guest, #10315) [Link]

GPL2 Para 2:
n addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

You can include anthing you wnat in the compilation, to include proprietary software.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 3:53 UTC (Thu) by dlazaro (subscriber, #38702) [Link] (2 responses)

Shouldn't it be easier to fix Unicode support in libedit?

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 7:05 UTC (Thu) by djm (subscriber, #11651) [Link] (1 responses)

Sure, but that wouldn't provide an excuse to bash BSD-license libraries.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 8:28 UTC (Thu) by branden (guest, #7029) [Link]

OpenSSL's license is neither the original BSD license with the advertising clause, nor the BSD license without the advertising clause, nor even the original BSD license with an advertising clause which changes the name of the credited party.

Read it sometime. It's clearly based on the BSD license but so are many others, like the license on Apache 1.1. Adding any old language you want to the BSD license doesn't retain its identity as "the BSD license".

OpenSSL's license explicitly contains an anti-GPL provision (though it refers to the GPL inaccurately and furthermore betrays a misunderstanding of how the GPL works).

I have to guess that this is what the "positive interest against" the GNU GPL is. Some of the original OpenSSL developers didn't understand it, didn't like it, and are indifferent to the collateral damage caused by their ignorance and hostility.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 7:25 UTC (Thu) by trasz (guest, #45786) [Link] (6 responses)

Note that this incompatibility is intentional - http://www.gnu.org/licenses/why-not-lgpl.html explicitly says that readline uses GPL instead of LGPL in order to prevent it from being used by non-GPL code.

In other words, it's not just another licensing problem caused by GPL - this time, it's done on purpose.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 8:30 UTC (Thu) by branden (guest, #7029) [Link] (5 responses)

The OpenSSL license's incompatibility with the GNU GPL is likewise intentional and explicitly stated in its text.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 8:45 UTC (Thu) by trasz (guest, #45786) [Link] (4 responses)

Not true - there are no claims from the OpenSSL people that you cannot link their software with <whatever>, because that would be a derived work. In other words, there are no SSL-incompatible licenses (other than GPL), no CDDL-incompatible licenses (other than GPL), no Mozilla-incompatible licenses (other than GPL), there is just a bunch of GPL-incompatible licenses, due to restrictions in GPL.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 12:35 UTC (Thu) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

Read the OpenSSL license. The incompatibility with GPL is very much intended and so was CDDL license incompatibility with GPL according to

http://lwn.net/Articles/198171/

" One current and one former Sun employee visited the annual Debian conference in Mexico in 2006. Danese Cooper clearly stated there that the CDDL was intentionally modelled on the MPL in order to make it GPL-
incompatible. For everyone who wants to hear this first-hand, we have
video from that talk available at [2]."

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 12:51 UTC (Thu) by trasz (guest, #45786) [Link] (2 responses)

Read the OpenSSL license. There is nothing there that would cause incompatibility with any other Open Source license, with the notable exception FSF interpretation of GPL, which basically requires everything to be GPL or a subset of GPL.

While one could claim that any license that is not GPL-compatible is being done "on purpose", it's good to keep in mind that the whole problem with incompatibility is on the GPL side. Again, that's why there are no OpenSSL-incompatible licenses, no Mozilla-incompatible licenses and no CDDL-incompatible licenses - except for GPL.

One more thing to note is that if Sun released their code under GPL, it would make it impossible to guarantee a patent protection to their users, or to use that code in any operating system other than Linux - and Linux folks wouldnt' accept that code anyway due to NIH.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 15:51 UTC (Thu) by nye (subscriber, #51576) [Link] (1 responses)

Bear in mind that '*both* the conditions of the OpenSSL License *and* the original SSLeay license apply to the toolkit' [emphasis mine].

>The licence and distribution terms for any publically available version or
>derivative of this code cannot be changed. i.e. this code cannot simply be
>copied and put under another distribution licence
>[including the GNU Public Licence.]

So any derivative work must be released under the terms of the SSLeay license. This makes it incompatible with any copyleft license at the very least. For example, an MIT licensed piece of software can be combined with CDDL software, and the whole distributed under the CDDL, because adhering to the terms of the CDDL necessarily means adhering to the terms of the MIT license. With SSL, this is not the case; in fact it's similar to the GPL's requirement that no further restrictions be imposed, so probably has all the same incompatibilities.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 17:39 UTC (Thu) by branden (guest, #7029) [Link]

Eric Young's licenses on his Blowfish and DES implementations are also in the mix.

Thanks for quoting the paragraph to which I referred. I don't understand how people can overlook that when it's been kept in the top-level license file for at least the past five years.

gnutls interoperability

Posted Feb 17, 2011 9:19 UTC (Thu) by arekm (guest, #4846) [Link] (1 responses)

Mine problem with gnutls is that it's more stricter than openssl. openssl can connect to some "broken" servers while gnutls can't without manual intervention (switching some things on/off).

Example: https://savannah.gnu.org/support/index.php?106628
Unfortunately these broken servers are bank servers :/

gnutls interoperability

Posted Feb 17, 2011 10:29 UTC (Thu) by cortana (subscriber, #24596) [Link]

Indeed. GnuTLS' poor interoperability has been a constant source of problems for Debian's exim packages, which cannot use OpenSSL for familiar reasons.

Why the OpenSSL license can't change

Posted Feb 17, 2011 23:39 UTC (Thu) by BrucePerens (guest, #2510) [Link] (5 responses)

Eric A Young was compelled to sign an agreement that he would not touch the software again. So, he can't change the license on his contribution.

Why the OpenSSL license can't change

Posted Feb 18, 2011 2:58 UTC (Fri) by pabs (subscriber, #43278) [Link] (3 responses)

Do you have any references to back that up or more details? Why would he agree to sign such a thing?!

Why the OpenSSL license can't change

Posted Feb 18, 2011 3:36 UTC (Fri) by BrucePerens (guest, #2510) [Link] (2 responses)

He was compelled, it's not something that he wanted to do. And he's not allowed to talk about it. I'm not sure of the reason.

Why the OpenSSL license can't change

Posted Feb 18, 2011 4:43 UTC (Fri) by foom (subscriber, #14868) [Link] (1 responses)

Now you've gotten me interested. :) I can't find any other references on the internet. People around Dec 1998 say Eric Young won't be working on it anymore, but there's no more details...

http://www.mail-archive.com/openssl-users@openssl.org/msg...
http://marc.info/?l=apache-ssl&m=91399607525631&w=1
http://marc.info/?l=ssl-users&m=91399693926181&w=1

Perhaps it was a condition of his employment by RSA, working on a commercial SSL implementation, that he never again touch his open source SSLeay project. Or maybe Australia decided to prosecute him for dealing in "weapons" (crypto) afterall, like the first link said, and it was a condition of dropping the case that he never work on it again.

Why the OpenSSL license can't change

Posted Mar 24, 2017 23:42 UTC (Fri) by eay (guest, #114767) [Link]

When the RSA patent existed, software patents did not apply to Australia, but
contributory patent infringement did.
https://www.wadesonip.com.au/patent-attorney-services/pat...

As for 'weapons', Australian law, at the time, only applied to software that was being sold, not distributed for free, unlike the USA.

eric (going back into lurking mode :-)

Why the OpenSSL license can't change

Posted Feb 18, 2011 4:29 UTC (Fri) by cmccabe (guest, #60281) [Link]

That's interesting. But... changing the license on his contribution doesn't require changing the software, does it? If he gives verbal approval, someone else could edit LICENSE.txt, surely?

PostgreSQL, OpenSSL, and the GPL

Posted Feb 20, 2011 0:53 UTC (Sun) by foom (subscriber, #14868) [Link]

One interesting thing of note is the recent transition of readline from GPLv2 to GPLv3. So, any software which is licensed under GPLv2-only also now has a similar incompatibility issue with readline.

I'm not sure how much software that actually impacts, but I don't think anyone's been paying as much attention to that sort of problem (upgrades introducing newly incompatible licensing) as they ought to.

PostgreSQL, OpenSSL, and the GPL

Posted Feb 21, 2011 7:17 UTC (Mon) by fdr (guest, #57064) [Link]

One problem I have with libedit is that it (to my fingers) doesn't seem to work as well as readline. I was also part of this thread, not because I had problems with multibyte characters, but because I *definitely* noticed that things that used to work weren't working anymore.

tl;dr: my unexpert opinion is that libedit is not as good, or psql is not very good at using it, and it makes my hands angry.

What does readline have to do with OpenSSL

Posted Feb 24, 2011 20:14 UTC (Thu) by MattPerry (guest, #46341) [Link] (3 responses)

I'm very confused by this article. What does readline have to do with OpenSSL? The article mentions in the second paragraph that the readline license is compatible with the PostgreSQL license. Why does readline keep getting mentioned?

What does readline have to do with OpenSSL

Posted Feb 24, 2011 20:19 UTC (Thu) by jake (editor, #205) [Link] (2 responses)

> What does readline have to do with OpenSSL? The article mentions in the
> second paragraph that the readline license is compatible with the
> PostgreSQL license. Why does readline keep getting mentioned?

PostgreSQL uses readline (in many distributions) *and* it uses OpenSSL. Their licenses are considered to be incompatible by some. Does that help?

jake

What does readline have to do with OpenSSL

Posted Feb 25, 2011 17:14 UTC (Fri) by MattPerry (guest, #46341) [Link] (1 responses)

No, not at all. I read the article for a fourth time and it's still confusing. This article is in desperate need of revision. Its message would be greatly improved if the parts about readline were removed and you focused solely on the OpenSSL issue.

You already established that the readline library is compatible with PostgreSQL. From the second paragraph of the article:

> But readline is licensed under the GPL (rather than the LGPL), which
> means that programs which use it must have a compatible license and
> PostgreSQL's BSD-ish permissive license certainly qualifies.

The title of the article states that it's about "PostgreSQL, OpenSSL, and the GPL" and the first paragraph only talks about OpenSSL. In fact, the first paragraph is setting up a discussion about how OpenSSL and PostgreSQL might have license compatibility issues. Bringing up readline out of the blue, and never tying it to your point, leaves me confused about what you are attempting to communicate. It's as if you started this article about readline but switched to talking about OpenSSL and never fully edited out the readline information.

Here's another example:

> Unfortunately, a bug in libedit means that Debian PostgreSQL users can't
> input multi-byte characters into the psql command-line tool when using
> Unicode locales.
> For the PostgreSQL project, it is something of a "rock and a hard place"
> problem. The OpenSSL code works well, and is fairly tightlyperhaps too
> tightlyintegrated.

So again you are talking about readline (or libedit as a replacement) then you mention that this puts the PostgreSQL project into a difficult position. Reading this I expect the next sentence to be related to readline and now this readline difficulty will be resolved. Yet, you switch back to talking about OpenSSL and I'm left saying, "Huh?"

In fact, you mention that it's the Debian project, not PostgreSQL, that has a problem with readline. Debian's problems aren't PostgreSQL's problems.

If the license issues are similar with readline and PostgreSQL, then a short mention of that at the end of the article would be sufficient. As it is, the article is switching between the two without warning and without clearly establishing the relationship between all of them. The statement which I quoted at the top of this post only further confuses matters.

What does readline have to do with OpenSSL

Posted Feb 25, 2011 17:24 UTC (Fri) by jake (editor, #205) [Link]

> This article is in desperate need of revision. Its message would be
> greatly improved if the parts about readline were removed and you focused
> solely on the OpenSSL issue.

Well, I'm sorry it's confusing, that is (obviously) not the intent. But the problem involves the combination of PostgreSQL (or really *any* program), OpenSSL *and* readline. With only one of the latter two (OpenSSL or readline) being linked into PostgreSQL, there would be no problem.

PostgreSQL was just the most recent place where the issue has come up, but linking OpenSSL and GPL code has been a recurring problem (in the eyes of some, anyway). In this case, the GPL code is readline.

jake