As a feature request, it'd be useful to have an additional configure flag "--enable-gpl" like the FFmpeg folks use that allows GPL algorithms to be built. Otherwise, by default, LGPL algorithms/code only is allowed in shared libraries. Right now I have to play around with makefiles to remove GPL-only algorithms (as per the included manual) such as serpent and blowfish.
Thanks, - David Hoyt
"Hoyt, David" hoyt6@llnl.gov writes:
As a feature request, it'd be useful to have an additional configure flag "--enable-gpl" like the FFmpeg folks use that allows GPL algorithms to be built.
Would make some sense, except that I'd prefer a different default, and I'm not sure what the name should be. I'd somehow prefer something like enable-lgpl-compatibility to the blunt --disable-gpl.
To implement it, one would need one autoconf/Makefile conditional (setup in the same way as IF_HOGWEED and IF_SHARED), and one preprocessor conditional to disable use in nettle-benchmark.c and any other places.
Right now I have to play around with makefiles to remove GPL-only algorithms (as per the included manual) such as serpent and blowfish.
For blowfish, I think it should be straight-forward to copy the lgpl:ed implementation from libgrypt.
For serpent, I'm not aware of any lgpl:ed implementation, and I doubt it's worth the efffort to write one from scratch (or rather, I'd prefer that the guy who wants to use serpent in a proprietary application pays for that development...). Several years ago, I wrote to the serpent folks to ask if they were willing to change the license of their implementation to the lgpl. If I remember correctly, there were no strong objections, but they didn't have the time to track down everyone who was involved in the project and discuss a license change.
Regards, /Niels
As a feature request, it'd be useful to have an additional configure flag "--enable-gpl" like the FFmpeg folks use that allows GPL algorithms to be built.
Would make some sense, except that I'd prefer a different default, and I'm not sure what the name should be. I'd somehow prefer something like enable-lgpl-compatibility to the blunt --disable-gpl.
To implement it, one would need one autoconf/Makefile conditional (setup in the same way as IF_HOGWEED and IF_SHARED), and one preprocessor conditional to disable use in nettle-benchmark.c and any other places.
That sounds fine. I only suggested that because that's the only other project I've seen that provides an LGPL and GPL option for their build. So it made sense to follow suit (playing it safe by default unless you explicitly and knowingly ask for GPL code).
Right now I have to play around with makefiles to remove GPL-only algorithms (as per the included manual) such as serpent and blowfish.
For blowfish, I think it should be straight-forward to copy the lgpl:ed implementation from libgrypt.
For serpent, I'm not aware of any lgpl:ed implementation, and I doubt it's worth the efffort to write one from scratch (or rather, I'd prefer that the guy who wants to use serpent in a proprietary application pays for that development...). Several years ago, I wrote to the serpent folks to ask if they were willing to change the license of their implementation to the lgpl. If I remember correctly, there were no strong objections, but they didn't have the time to track down everyone who was involved in the project and discuss a license change.
For my needs, blowfish and serpent aren't necessary, so simply removing them is alright. Of course having them there wouldn't hurt, either. :) I'm just more concerned about mitigating licensing issues to the maximum extent possible.
nettle-bugs@lists.lysator.liu.se
-
Hoyt, David -
nisse＠lysator.liu.se