LWN: Comments on "PostgreSQL, OpenSSL, and the GPL"

Why the OpenSSL license can't change

eay — Fri, 24 Mar 2017 23:42:18 +0000

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 :-)

LibNSS advantages

nix — Mon, 27 May 2013 22:27:34 +0000

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

LibNSS advantages

rahulsundaram — Mon, 27 May 2013 21:31:33 +0000

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

Jehreg — Mon, 27 May 2013 21:10:46 +0000

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.

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

trekker.dk — Sun, 13 Mar 2011 22:23:23 +0000

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)

PostgreSQL, OpenSSL, and the GPL

paulj — Mon, 28 Feb 2011 11:33:47 +0000

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

rahulsundaram — Mon, 28 Feb 2011 09:52:20 +0000

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

PostgreSQL, OpenSSL, and the GPL

salimma — Mon, 28 Feb 2011 09:29:34 +0000

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?

What does readline have to do with OpenSSL

jake — Fri, 25 Feb 2011 17:24:02 +0000

> 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

What does readline have to do with OpenSSL

MattPerry — Fri, 25 Feb 2011 17:14:15 +0000

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

jake — Thu, 24 Feb 2011 20:19:34 +0000

> 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

MattPerry — Thu, 24 Feb 2011 20:14:15 +0000

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?

Sorry, but this is quite different...

jjs — Thu, 24 Feb 2011 04:16:06 +0000

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

dvdeug — Wed, 23 Feb 2011 22:44:15 +0000

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

nye — Tue, 22 Feb 2011 17:16:31 +0000

>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

fdr — Mon, 21 Feb 2011 07:17:26 +0000

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.

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

fjalvingh — Sun, 20 Feb 2011 10:24:26 +0000

Thank you! I did not know that!

PostgreSQL, OpenSSL, and the GPL

foom — Sun, 20 Feb 2011 00:53:29 +0000

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

nix — Sat, 19 Feb 2011 23:07:52 +0000

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

butlerm — Sat, 19 Feb 2011 17:01:54 +0000

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

dvdeug — Sat, 19 Feb 2011 06:16:11 +0000

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; }

Sorry, but this is quite different...

khim — Fri, 18 Feb 2011 16:28:35 +0000

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.

Again: "derived work" is meaningless here.

fuhchee — Fri, 18 Feb 2011 15:14:48 +0000

"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.

PostgreSQL, OpenSSL, and the GPL

butlerm — Fri, 18 Feb 2011 06:24:55 +0000

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?).

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.

Again: "derived work" is meaningless here.

khim — Fri, 18 Feb 2011 06:07:55 +0000

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.

It's not so easy...

samroberts — Fri, 18 Feb 2011 05:21:16 +0000

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.

Why the OpenSSL license can't change

foom — Fri, 18 Feb 2011 04:43:14 +0000

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

cmccabe — Fri, 18 Feb 2011 04:29:32 +0000

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?

Why the OpenSSL license can't change

BrucePerens — Fri, 18 Feb 2011 03:36:35 +0000

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

pabs — Fri, 18 Feb 2011 02:58:42 +0000

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

PostgreSQL, OpenSSL, and the GPL

gmaxwell — Fri, 18 Feb 2011 02:42:54 +0000

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

vonbrand — Fri, 18 Feb 2011 01:42:26 +0000

PostgreSQL, OpenSSL, and the GPL

vonbrand — Fri, 18 Feb 2011 01:35:28 +0000

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

vonbrand — Fri, 18 Feb 2011 01:23:39 +0000

This is obviously only applicable to your specific packages installed

PostgreSQL, OpenSSL, and the GPL

giraffedata — Fri, 18 Feb 2011 00:14:29 +0000

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.

Why the OpenSSL license can't change

BrucePerens — Thu, 17 Feb 2011 23:39:58 +0000

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.

PostgreSQL, OpenSSL, and the GPL

sfeam — Thu, 17 Feb 2011 21:21:23 +0000

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

dlang — Thu, 17 Feb 2011 21:09:14 +0000

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

kleptog — Thu, 17 Feb 2011 20:48:00 +0000

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

branden — Thu, 17 Feb 2011 17:39:02 +0000

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.