[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Updating the fis-gtm package to V6.2-000


On 09/30/2014 04:43 AM, Thorsten Alteholz wrote:
Hi Bhaskar,

On Mon, 29 Sep 2014, Bhaskar, K.S wrote:

GT.M does not require OpenSSL, does not statically link to it, and does
not in a strict sense, depend on OpenSSL.  But there is a looser
relationship / dependency.

hmm, while looking at the Debian package, I found the following comment:
"The upstream V6.2-000 CMakeLists.txt file built only one of three
 possible encryption plugin libraries. This meant that the debian fis-gtm
 package was missing a core piece of the distributed binaries. Upstream will
 apply this change to the next release after internal review."

Further the Debian package contains:
  libgtmcrypt_openssl_BLOWFISHCFB.so
  libgtmcrypt_gcrypt_AES256CFB.so
  libgtmcrypt_openssl_AES256CFB.so

So at least the version in the Debian package is actually linked with OpenSSL.

[KSB] Those *openssl* files are versions of the reference implementation of the plugin compiled with #include, #if, etc. configured to call call OpenSSL.  They are not actually linked to OpenSSL or other libraries - linking happens dynamically.  The user sets libgtmcrypt.so to point to the version of plugin s/he wants to use.  For example, on my laptop:

kbhaskar@bhaskark:~$ ls -l /usr/lib/fis-gtm/V6.2-000_x86_64/plugin/lib*crypt*
-r-xr-xr-x 1 root root 40656 Sep 18 15:45 /usr/lib/fis-gtm/V6.2-000_x86_64/plugin/libgtmcrypt_gcrypt_AES256CFB.so
-r-xr-xr-x 1 root root 40030 Sep 18 15:45 /usr/lib/fis-gtm/V6.2-000_x86_64/plugin/libgtmcrypt_openssl_AES256CFB.so
-r-xr-xr-x 1 root root 40056 Sep 18 15:45 /usr/lib/fis-gtm/V6.2-000_x86_64/plugin/libgtmcrypt_openssl_BLOWFISHCFB.so
lrwxrwxrwx 1 root root    33 Sep 18 15:45 /usr/lib/fis-gtm/V6.2-000_x86_64/plugin/libgtmcrypt.so -> ./libgtmcrypt_gcrypt_AES256CFB.so
-r-xr-xr-x 1 root root 18688 Sep 18 15:45 /usr/lib/fis-gtm/V6.2-000_x86_64/plugin/libgtmcryptutil.so
kbhaskar@bhaskark:~$

Most of the discussion of license interaction between copyleft and non-copyleft licenses at en.wikipedia.org/wiki/GNU_General_Public_License pertain to software used under non-copyleft licenses requesting services from (I deliberately avoid the use of "linking to") software used under non-copyleft licenses.  In this case, we have the reverse - a copyleft software (GT.M) requesting services from non-copyleft software (OpenSSL).  Regardless, it appears that there are different schools of thought on this.

If there is no specific Debian policy, and we agree that this is a gray area, I am happy to state here that we do not consider the calling of OpenSSL by the reference implementation of the plugin to create a derivative work - and as long as there is no derivative work, there is no interaction between the licenses.  [As I said in an earlier post, I consider the reference implementation of the plugin to be like a configuration file or a shell script that a user can use as-distributed, or customize to his/her needs.]

If there is a specific Debian policy, and this is not a gray area, then I propose that we address it by one of the following methods (from most preferred to least preferred in my opinion):

  • Include a statement in the README that says something like: As dynamic linking by the reference implementation of the plugin to software such as cryptographic libraries that are released under non-copyleft licenses is not considered to create a derivative work, there is no interaction between the license used for GT.M and those of cryptographic libraries.
  • Remove any claim of copyright from the reference implementation of the plugin (i.e., place the reference implementation in the public domain).
  • Remove the precompiled versions of the reference implementation of the plugin from the distribution and include only the source of the plugin (as I noted earlier, the GT.M binary distribution includes source code for the reference implementation of the plugin).  Use the post-install script to compile the reference implementation of the plugin.

Thorsten, please let me know what you think.

Regards
-- Bhaskar


As the OpenSSL license contains (advertising) restrictions[1] that are not allowed by the AGPL, the AGPL must be extended by an exception clause.

  Thorsten

[1]https://urldefense.proofpoint.com/v1/url?u=https://en.wikipedia.org/wiki/OpenSSL%23Licensing&k=%2FbkpAUdJWZuiTILCq%2FFnQg%3D%3D%0A&r=G5N3MCzgmIzHOZjVHAPkWPrIpVi%2BYUaznSzJrMCLquI%3D%0A&m=3KyT1ayTnNzWVGGXsiwKtyOsgNa%2FrEJIeNwnErx%2Fb60%3D%0A&s=3aeda9621ba072bc7721b930329d7738cd29ce1249255183cce96cde2d1b2d6f 



-- 
GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
Reply to: