The intention of this bug is to clarify and confirm, that the described intentions are acceptable. Thunderbird considers to use and distribute three libraries, which are available under the LGPL version 2.1: - libOTR A library implementing the encrypted OTR communication protocol. https://otr.cypherpunks.ca/README-libotr-4.1.1.txt The above has runtime requirements on the following libraries from the GnuPG project: - libgpg-error A GnuPG-project helper/runtime library. https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=blob;f=README;h=e0b9f16445a96942af0839bcdb9a0b0f8cf31380;hb=HEAD - libgcrypt Aa GnuPG-project library implementing generic cryptography. https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=README;h=92f2f1b35f741500d310cb479ad6e6e0e91e8232;hb=HEAD We'd access libOTR using dynamic linking. We specifically don't intend to mix MPL code with LGPL code. The binary LGPL code would remain completely separate from the MPL code, by distributing it as shared libraries that are dynamically linked (.so on Linux, .dll on Windows, .dylib on OSX). This setup wouldn't create a derived work of the mentioned LGPL libraries, but simply use them. It would allow users to easily recompile those libraries, independently from Thunderbird, and would allow users to replace those libraries with modified or updated libraries. In my understanding this approach satisfies the LGPL v2.1 licensing requirements, independently of the license(s) that Thunderbird uses. Despite Thunderbird not requiring any modifications to libOTR etc., IMHO, it would be preferable to include a copy of the source code in the Thunderbird source tree. This can allow the Thunderbird build to automatically build binaries of those LGPL libraries for distribution. Some parts of the source code distribution of those libraries aren't LGPL, but GPL. This applies to test code and helper utitilies. Because the Thunderbird binary distribution wouldn't use those GPL portions, having that GPL library source code in the Thunderbird source code distribution should be acceptable. The libgcrypt page https://www.gnupg.org/software/libgcrypt/index.html also mentions "former U.S. export restrictions on cryptographic software". We should clarify if those export restrictions are still a problem. Are we allowed to import a copy of libgcrypt into the Thunderbird source repository that is hosted on U.S. servers, and also include it in the Thunderbird source distributions, which are hosted on U.S. servers? Finally, libgcrypt includes some code with additional (compatible) licenses, which requires that permission notices are included. We'll have to check which of the following require additions to about:license: https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=LICENSES;h=f6733a69246bb2d0236af42cff28c1a6fee43c36;hb=HEAD

We've found https://searchfox.org/mozilla-central/source/config/external/lgpllibs/moz.build and how e.g. libsoundtouch makes use of it, so in part the question may be answered. Mike, can you confirm that using FINAL_LIBRARY = 'lgpllibs' and making sure the directory has a LICENSE file would allow us to add the sources in tree and make use of them? If that is true, the open questions would be: * Is it ok to check in the GPL licensed test code and helper utilities, given they are not linked into the final product? * Are there any issues regarding U.S. export restrictions mentioned on the libgcrypt page https://www.gnupg.org/software/libgcrypt/index.html ? * Are there any issues with the licenses mentioned at https://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=LICENSES;h=f6733a69246bb2d0236af42cff28c1a6fee43c36;hb=HEAD ? Kai, let me know if I missed something.

Philipp, thanks for your research. It seems the lgpllibs precedent could confirm that using LGPL code in general is permissible. Apparently the lgpllibs module is a special construct used by Mozilla, which picks up some individually selected, external LGPL source code files. In thr OTR scenario, using the "lgpllibs" approach shouldn't be necessary, because the desired libraries are already self-contained, dynamic libraries. We should use them as they are, not repackage into Mozilla's own lgpllibs container (it would make things more complicated). So to clarify Philipp's comment 1, I suggest not to focus on the question "are we required to use the Mozilla module named lgpllibs" to solve the solution, but I'd keep it at the general level "are we allowed to bundle and ship the LGPL libraries", as I've originall described it. The other questions, that Philipp reworded in comment 1, also need confirmation.

We have a licensing runbook here - "in case of license X, you can do Y" - that's shaped up pretty well, and that I expect to publish shortly. Kai, I'd be happy to share it with you if you like. In the section on "Incorporating open-source-licensed third-party code into existing products or projects", it reads: The following licences are partially compatible with the MPL, and code under these licenses can be integrated into Mozilla products under some circumstances. - Code licensed under the Lesser GNU Public License (LGPL) can be included both as in-tree and vendored-in dependencies provided it is compiled into a separate library and linked dynamically from the rest of the codebase. - See: mozilla-central/obj-x86_64-pc-linux-gnu/config/external/lgpllibs/ for one example of how this works. - In particular, see: mozilla-central/obj-x86_64-pc-linux-gnu/config/external/lgpllibs/liblgpllibs_so.list for additional information.