PostgreSQL, OpenSSL, and the GPL

Posted Feb 17, 2011 16:10 UTC (Thu) by butlerm (subscriber, #13312)
In reply to: PostgreSQL, OpenSSL, and the GPL by vonbrand
Parent article: PostgreSQL, OpenSSL, and the GPL

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.