Nettle as default

[Andrew W. Nosenko]

On Sat, Oct 9, 2010 at 00:51, Niels Möller <nisse at lysator.liu.se> wrote:
> Nikos Mavrogiannopoulos <nmav at gnutls.org> writes:
>
>> Niels would there be other GPL parts of nettle except serpent and
>> blowfish?
>
> Not that I'm aware of.
>
>> Would there be a way to have an LGPL-only nettle
>
> In principle, you can delete the files which are not LGPL-compatible,
> and make the necessary tweaks to the build system. The result could then
> be distributed and used under the terms of the LGPL. But that's of
> course not very convenient.
>
> Personally, I'm a bit pragmatic, and I say the following in the manual:
>
>  This means that if you don't use the parts of nettle that are
>  GPL-only, you have the option to use the Nettle library just as if it
>  were licensed under the LGPL.
>
> For static libraries, that's more or less obvious (the object code
> corresponding to the serpent and blowfish source code won't be copied
> into the executable).
>
> For shared libraries, I don't see a big problem linking a proprietary
> (or otherwise non-GPL-compatible executable) with a nettle library
> containing those GPL:ed files, in the special case that those functions
> are not used and that the executable would link successfully and work in
> exactly the same way if one substituted the nettle shared library with a
> hacked version in which all GPL:ed functions are removed (and with no
> other changes). But I understand not everyone will agree with my
> judgement here.
>
> Adding a configure option like --enable-lgpl-compatibility has been
> suggested. The meaning would be to include only LGPL-compatible files in
> the built libraries and executables. I have not given the subtle details
> much thought (such as what sonames should be used, and how to keep both
> default nettle and lgpl-compatible variants of libnettle.so on the same
> system). Suggestions are welcome.
>
> But I suspect such a configure option would not really help you; if you
> don't agree with my thinking that it's ok to link a non-gpl program with
> a library which contains some gpl code which the executable doesn't use
> at all, you still can't link to the shared nettle library provided by
> debian (since that ought to include the full set of algorithms). You'd
> need to provide a separate lgpl-only shared nettle library, and then
> maybe it would be easier for you to just link libgnutls.so statically to
> nettle (have a look at the code size of the objects you'll pull in
> before ruling this option out). Might be against debian policy though,
> and have some practical problems in case there's some security problem
> in nettle which must be fixed.
>
> Long term, the best way would naturally be to simply replace the
> non-lgpl-compatible code. For blowfish, that's no big deal (just copy
> the version in libgcrypt and convert it to nettle conventions; patches
> to do that are welcome). For serpent, I'm not aware of any other
> implementation than the gpl:ed one I use, but I may well be missing
> something.

I see two variants more or less convinient for all variants (no
options like --enable/disable-gpl involved at all):

1.  2 shared libraries:
    libnettle-lgpl.so  -- LGPL compatible code, suitable for linking
itself (like Nettle would to build with GPL code removed), if nettle
contains utility support/framework functionts, they are here also
    libnettle-gpl.so -- GPL code only, linked with libnettle-lgpl.so
therefore by linking with libnettle-lgpl.so you are LGPL clean, by
linking with libnettle-gpl.so you have full fetured Nettle (LGPL part
going through inter-library dependence).

2. 3 libraries (variation about variant #1):
    libnettle-lgpl.so  -- LGPL compatible code, suitable for linking
itself (like Nettle would to build with GPL code removed), if nettle
contains utility support/framework functionts, they are here also
    libnettle-gpl.so -- GPL code only
    libnettle.so -- dummy library linked with both libnettle-lgpl.so
and libnettle-gpl.so and therefore GPL licensed.  Just for keep the
backward compatible name.

"Inter-library dependence" or "linked with..." doesn't need to be at
the system's ld.so level.  It may be just looks like for developer
point of view and be implemented through additional "metadata" like
pkg-config's .pc file or libtool's .la file.

Therefore, you won't need to have a kinds of packages, configs or
builds.  One build will have anything for satisfy both needs.

-- 
Andrew W. Nosenko <andrew.w.nosenko at gmail.com>