PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 21:21 UTC (Thu) by sfeam (subscriber, #2841)
In reply to: PostgreSQL, OpenSSL, and the GPL by kleptog
Parent article: PostgreSQL, OpenSSL, and the GPL

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.

to post comments

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.