I cannit answer to all the point but at least I can comment
the redistribution one :
To my point of view, a static linking is NOT a redistribution,
just because the liked library is not usable by the end user.
To an extreme extent, the end user is not necessarily aware that the
product contains
a static version of ssl lib, and even so he/she is not necessarily aware
of what is it and
what he/she could do with it if this lib was ...directly accessible as a
dll, which it is NOT !
What I mean is that "redistributing" something as embedded in a product
is not opening its free usage
by the end user. The product received is NOT the same as the product
used by the developper,
and has often less features (as your product does not expose to end
users all the functionnalities of the original
openssl lib.
Even more if "redistributing as embedded" was "redistributing", then it
would allow the end user to do the same thing as yourself,
I mean the same usage of the library: and this is impossible.
More over it would allow him to redistribute openssl again ....but it is
also impossible because openssl lib has been embedded,
ie hidden in some way, in your application.
The only way the end user could "propagate" openssl would be to
redistribute your whole application :
this depends on your own license, but would not lead anyway to a
"usable" full featured lib.
Finally, I would say that in fact "dynamic linking" is the scenario most
closed to "redistribution" than static linking :
because it allows, at least technically, a possible distribution of a
copy of a dll.
And a dll is a full featured independent product that can be used as is
by proper calling, and redistributed with its full features again.
But openssl team do not distribute dll, but sources to produce such...it
is another question.
This is just a comment.
Pierre Delaage
Le 07/10/2010 03:05, Tristan Schmelcher a écrit :
I work on a proprietary Linux application that dynamically links to
OpenSSL for some cryptographic features (www.google.com/chat/video)
and I am considering switching to static linking in order to get
around OpenSSL ABI compatibility issues across different Linux
distributions/versions. Before doing so though I am hoping that
someone can help me to better understand the acknowledgement clauses
in the OpenSSL license. I have read the thread at
http://www.mail-archive.com/[email protected]/msg16849.html,
but it didn't completely clear things up for me.
My interpretation of clause 3 of the OpenSSL license (and similarly
clause 3 of the SSLeay license) is that we only have to include the
acknowledgement if/when we advertise the cryptographic features (which
AFAIK we do not advertise anywhere). Since the license says at the
beginning that it applies to both redistribution and _use_, it seems
to me that this clause would apply to both dynamic linking and static
linking equally, since both are certainly a "use" of the software. It
would even apply to anyone using the OpenSSL build that Apple ships on
Macs. So it seems to me that switching from dynamic linking to static
linking would have no effect on our obligations under this clause.
However, I'm not so sure about clause 6 of the OpenSSL license. An
executable that dynamically links to OpenSSL is certainly not a
redistribution of OpenSSL, but I can imagine someone making the
argument that an executable that _statically_ links to OpenSSL _is_ a
redistribution of OpenSSL.
I am wondering what the opinion of the OpenSSL developer community is
on this point. Ideally I would not like to have to add an
acknowledgement into our product purely because of a change in the
linking process. (It's not even clear to me where we would put the
text.)
Thanks,
Tristan Schmelcher
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
