2

I'm writing some C++ code which I might eventually like to release under an Apache v2.0 license.

I'm looking to build the application linking to some of the LGPL v2.1-licensed shared libraries from Gnu GPG.

  • I shall not be statically linking with Gnu GPG libraries.

  • I shall NOT be including any Gnu GPG shared libraries or any other part of Gnu GPG when distributing my application.

  • Users will either already have them installed or will have to install them separately. In the absence of the Gnu GPG shared libraries, my application will continue to run without GPG functionality.

The LGPL v2.1 license wording appears to allow dynamically loaded shared libraries to be used in this way by applications which are licensed with licenses other than LGPL.

The question I have is this:

Is it permissible for me to distribute my application under the Apache 2.0 License if it dynamically links with LGPL v2.1 shared libraries as described above, and those LGPL shared libraries are not included in my distribution?

Otherwise, are there compatibility problems arising from the Apache license side ?

1 Answer 1

2

LGPL copyleft only applies to modifications to the library itself, not to applications that use the library. Therefore, your application may be under virtually any license whatsoever (including a nonfree license) and you could still be in compliance with the requirements of the LGPL license on the library. The only way an application's license could be a problem is if it somehow actively interfered with the library's internal copyleft, e.g., if the application's license actively forbade sharing the source of libraries in use. The Apache 2 license makes no such interfering requirement.


Even if your third-party library were GPL-licensed, the GPL requires than you distribute the source code of any binary form you actually distribute. If you don't distribute a binary that includes the GPL library, you don't have GPL obligations applied to your program.

(This is complicated ever-so-slightly by the fact that you application probably makes use of the library's API, which could, possibly, make it a derivative of the library, since APIs are copyrightable expression. However, you're using the API, not writing an implementation of the API, so your use is not very large. Also, the closer the API is to some fundamental operation, the less it has any copyright at all: e.g. symmetric encryption takes plaintext and a key, so an encrypt(key, plaintext) function has minimal copyrightability.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.