PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 21:33 UTC (Wed) by joey (guest, #328)
Parent article: PostgreSQL, OpenSSL, and the GPL

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.

to post comments

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 (subscriber, #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 (subscriber, #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.