[zeromq-dev] TLS (openssl) for ZeroMQ

Luca Boccassi luca.boccassi at gmail.com
Wed Dec 26 16:26:56 CET 2018 

I'm afraid that we need to be much more careful than a law firm, for
the simple reason that we don't have the resources to fend off
potential litigations, whether they have any ground or not. A lot of
our users are individuals or academic researchers, our software gets
redistributed by free distros, and so on. So IMHO we need to be as
conservative and careful as possible with legal issues.

On the specific point of dl_open vs compile time linking, it's always
been the legal opinion of the FSF that they are equivalent with regards
to the clauses of the GPL. Some people disagree, some agree.

The key point is that legal uncertainty drives users away, so IMHO we
should do our best to avoid any.

On Tue, 2018-12-25 at 18:33 -0500, Steven McCoy wrote:
> It’s how Thomson Reuters uses OpenSSL and they’re the biggest law
> firm in
> the world.  Here's the code, now open source, but not matching
> license, for
> reference:
> 
> https://github.com/thomsonreuters/Elektron-SDK/blob/master/Cpp-C/Eta/
> Impl/Transport/ripcsslutils.c
> 
> On Tue, Dec 25, 2018 at 15:16 Luca Boccassi <luca.boccassi at gmail.com>
> wrote:
> 
> > On Tue, 2018-12-25 at 11:47 -0500, Steven McCoy wrote:
> > > A common workaround is to dynamically pull in OpenSSL at
> > > runtime.  Have a
> > > context option that specifies the OpenSSL “.so” or “.dll” path
> > > and
> > > cache
> > > the required API inside a struct or similar.
> > 
> > Sorry but that's not a legal solution, but rather a way to try and
> > be
> > "clever" and waltz around the precise wording of the licenses. A
> > lawyer
> > could very well convince a judge that that still counts as a single
> > unit of compilation and as distributions. We cannot take chances
> > like
> > that - we don't have any lawyers "working" here, it's a community
> > driven project.
> > 
> > > On Tue, Dec 25, 2018 at 6:30 Luca Boccassi <luca.boccassi at gmail.c
> > > om>
> > > wrote:
> > > 
> > > > On Tue, 2018-12-25 at 00:53 +0100, 林宝龙 wrote:
> > > > > The problem of first option we met is that OpenSSL provides a
> > > > > lot
> > > > > configurable things, for example, trust group, external
> > > > > verification
> > > > > callback, etc. We must add more options to sockopt to have
> > > > > such
> > > > > things
> > > > > configurable. For the callback functions, if we continue
> > > > > using
> > > > > setsockopt,
> > > > > we need to cast function pointer to void pointer and vice
> > > > > versa,
> > > > > looks not
> > > > > good.
> > > > 
> > > > As mentioned, there is really no alternative to continue
> > > > supporting
> > > > bindings. Also, exposing a third party API/ABI again would mean
> > > > that
> > > > the users would need to start worrying about OpenSSL's API/ABI
> > > > changes,
> > > > and keep them in sync with the internal usage of the library.
> > > > That
> > > > would not be maintainable.
> > > > 
> > > > So it looks like there are both legal and implementation
> > > > problems.
> > > > So
> > > > let's take a step back: why is the current
> > > > encryption/authentication
> > > > support via CURVE and GSSAPI not sufficient? What is lacking
> > > > that
> > > > you
> > > > need in your application?
> > > > 
> > > > > About the licence issue, I'm not familiar with those
> > > > > licenses,
> > > > > and I
> > > > > have
> > > > > asked someone inside my company, got the answer that I can
> > > > > use
> > > > > OpenSSL in
> > > > > libzmq with an exception, I don't know how. He said that we
> > > > > will
> > > > > share the
> > > > > code out in the end, but can't contribute back to libzmq
> > > > > directly.
> > > > > Does it
> > > > > same as what you concern? Do you have more information that
> > > > > we
> > > > > must
> > > > > stop
> > > > > using OpenSSL inside libzmq?
> > > > 
> > > > Yes an exception is needed as I said, but not just from you:
> > > > from
> > > > every
> > > > single copyright holder of libzmq, of which there are many.
> > > > That's
> > > > because adding an exception to the license is a change in
> > > > license,
> > > > and
> > > > cannot legally be done unilaterally.
> > > > 
> > > > Note that this is not only a problem for contributing code
> > > > back,
> > > > but
> > > > also for your application. You cannot distribute those changes
> > > > to
> > > > anybody without a license change, which means you cannot give
> > > > your
> > > > application to anybody without breaching the terms of the
> > > > license,
> > > > and
> > > > thus copyright law.
> > > > 
> > > > > On Mon, 24 Dec 2018, 23:42 Luca Boccassi <luca.boccassi at gmail
> > > > > .com
> > > > > wrote:
> > > > > 
> > > > > > On Mon, 24 Dec 2018, 23:03 林宝龙 <lbl52001 at gmail.com wrote:
> > > > > > 
> > > > > > > Hi,
> > > > > > > 
> > > > > > > We are adding TLS support for ZeroMQ(based on 4.2.5).
> > > > > > > Product
> > > > > > > reason, we
> > > > > > > choosed OpenSSL as TLS library.
> > > > > > > 
> > > > > > > Ask community for suggestions, which solution below is
> > > > > > > better?
> > > > > > > 1. Use TLS public certification, private key, etc as
> > > > > > > socket
> > > > > > > option (set
> > > > > > > through setsockopt), ZeroMQ manages the OpenSSL context,
> > > > > > > one  OpenSSL
> > > > > > > context per socket_base_t object.
> > > > > > > 2. Use OpenSSL context as socket option(set through
> > > > > > > setsockopt),
> > > > > > > external
> > > > > > > application should provide the OpenSSL context, with
> > > > > > > public
> > > > > > > certification,
> > > > > > > private key, etc. set in context level, all ssl
> > > > > > > connections
> > > > > > > share
> > > > > > > the same
> > > > > > > configuration as the input OpenSSL context.
> > > > > > > 
> > > > > > > At beginning we choosed the first solution, like curve,
> > > > > > > use
> > > > > > > public
> > > > > > > certification, private key as the socket option. But
> > > > > > > later
> > > > > > > on, we
> > > > > > > found the
> > > > > > > second solution that use external OpenSSL context can
> > > > > > > make
> > > > > > > the
> > > > > > > ZeroMQ code
> > > > > > > simpler, and more flexible, external application can
> > > > > > > configure
> > > > > > > the OpenSSL
> > > > > > > context without change the ZeroMQ socket options.
> > > > > > > 
> > > > > > > Welcome your comments.
> > > > > > > 
> > > > > > > Best regards,
> > > > > > > Baolong
> > > > > > > 
> > > > > > 
> > > > > > The first option would be better, exposing third party API
> > > > > > and
> > > > > > ABI
> > > > > > would
> > > > > > be a nightmare, especially for bindings. O
> > > > > > 
> > > > > > But the most important issue is that the Openssl license is
> > > > > > not
> > > > > > compatible
> > > > > > with libzmq, which is licensed under the lgpl3, so I'm
> > > > > > afraid
> > > > > > such
> > > > > > combination will not be legally distributable. At least not
> > > > > > without
> > > > > > a
> > > > > > relicensing effort to add an exception - we are already
> > > > > > trying
> > > > > > that
> > > > > > to
> > > > > > change to mpl2 and are nowhere near done unfortunately.
> > > > > > 
> > > > > > > _______________________________________________
> > > > > > 
> > > > > > zeromq-dev mailing list
> > > > > > zeromq-dev at lists.zeromq.org
> > > > > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > > > > > 
> > > > > 
> > > > > _______________________________________________
> > > > > zeromq-dev mailing list
> > > > > zeromq-dev at lists.zeromq.org
> > > > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > > > 
> > > > --
> > > > Kind regards,
> > > > Luca Boccassi_______________________________________________
> > > > zeromq-dev mailing list
> > > > zeromq-dev at lists.zeromq.org
> > > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > > > 
> > > 
> > > _______________________________________________
> > > zeromq-dev mailing list
> > > zeromq-dev at lists.zeromq.org
> > > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > 
> > --
> > Kind regards,
> > Luca Boccassi_______________________________________________
> > zeromq-dev mailing list
> > zeromq-dev at lists.zeromq.org
> > https://lists.zeromq.org/mailman/listinfo/zeromq-dev
> > 
> 
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://lists.zeromq.org/mailman/listinfo/zeromq-dev

-- 
Kind regards,
Luca Boccassi
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20181226/24f4ad60/attachment.sig>

More information about the zeromq-dev mailing list