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.
