Nettle as default

[Niels Möller]

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.

Regards,
/Niels

-- 
Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26.
Internet email is subject to wholesale government surveillance.