PostgreSQL, OpenSSL, and the GPL

Posted Feb 16, 2011 23:49 UTC (Wed) by butlerm (subscriber, #13312)
In reply to: PostgreSQL, OpenSSL, and the GPL by joey
Parent article: PostgreSQL, OpenSSL, and the GPL

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

to post comments

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.