Hi,
Keep up the great work. I was looking for an LGPL-2.1 crypto library that can be used as an alternative to libgcrypt. Reason being can best be explained at [1].
So here are some questions I have. GNU Nettle is going to stick with LGPL-2.1+ correct? I ask this since I'm currently working on implementing full RAR archive support with libarchive, to ultimately be used in XBMC Media Center. XBMC is GPL-2+ and we have no desire to go to GPL-3.
Another question, the only thing I see missing in nettle that libarchive can make use of is RIPEMD-160. In case I want to submit patches, I should submit them here correct? Also, I suppose if I wanted to submit patches, there's no issue in porting code from gcrypt over to nettle correct? I think it would be easier (and faster) to reuse the implementation in gcrypt than to implement the algorithm from scratch.
Andres Mejia mcitadel@gmail.com writes:
So here are some questions I have. GNU Nettle is going to stick with LGPL-2.1+ correct?
At some point the license may be upgraded to LGPLv3. Or dual license LGPLv3 and GPLv2+. The latter, more complex, alternative would be helpful for you, right?
Another question, the only thing I see missing in nettle that libarchive can make use of is RIPEMD-160. In case I want to submit patches, I should submit them here correct?
Right.
Also, I suppose if I wanted to submit patches, there's no issue in porting code from gcrypt over to nettle correct?
Copying code from libgcrypt is fine. In general, to make it as easy as possible to integrate patches, it's nice if they include:
1. An authoritative reference for the implemented algorithm.
2. Test cases.
3. Documentation.
4. And then both interface and implementation should try to follow nettle conventions.
Regards, /Niels
On Tue, Aug 23, 2011 at 12:49 AM, Niels Möller nisse@lysator.liu.se wrote:
Andres Mejia mcitadel@gmail.com writes:
So here are some questions I have. GNU Nettle is going to stick with LGPL-2.1+ correct?
At some point the license may be upgraded to LGPLv3. Or dual license LGPLv3 and GPLv2+. The latter, more complex, alternative would be helpful for you, right?
So long as XBMC can remain GPLv2, then it's ok.
However, I'm sure there are some projects out there that could benefit from an LGPLv2.1 crypto library. I looked around and so far have found one, libaacs which is itself LGPLv2.1. libaacs is used indirectly by XBMC, through libbluray. Currently, libaacs uses libgcrypt for crypto, but it would be nice if the number of crypto libraries in use are kept to a minimum.
Another question, the only thing I see missing in nettle that libarchive can make use of is RIPEMD-160. In case I want to submit patches, I should submit them here correct?
Right.
Also, I suppose if I wanted to submit patches, there's no issue in porting code from gcrypt over to nettle correct?
Copying code from libgcrypt is fine. In general, to make it as easy as possible to integrate patches, it's nice if they include:
An authoritative reference for the implemented algorithm.
Test cases.
Documentation.
And then both interface and implementation should try to follow
nettle conventions.
Regards, /Niels
-- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.
Andres Mejia mcitadel@gmail.com writes:
On Tue, Aug 23, 2011 at 12:49 AM, Niels Möller nisse@lysator.liu.se wrote:
At some point the license may be upgraded to LGPLv3. Or dual license LGPLv3 and GPLv2+. The latter, more complex, alternative would be helpful for you, right?
So long as XBMC can remain GPLv2, then it's ok.
However, I'm sure there are some projects out there that could benefit from an LGPLv2.1 crypto library. I looked around and so far have found one, libaacs which is itself LGPLv2.1. libaacs is used indirectly by XBMC, through libbluray.
I have to look at this more closely before upgrading the license (which I don't have any immediate plans of doing). I'm not sure, but I actually don't see any obvious problem with linking LGPLv2 and LGPLv3 code together.
The problem when linking GPLv2 and LGPLv3 code together is not that LGPLv3 doesn't allow it (after all, LGPL, any version, allows linking even with with proprietary code), but that GPLv2 requires that the *entire* work (except system libraries) can be distributed under GPLv2, with no additional restrictions, and some of the new conditions in (L)GPLv3 (probably the ones related to drm or patents) are additional restrictions.
And dual licensing as LGPLv3+ and GPLv2+ solves precisely that problem: GPLv2 programs (including tivoized GPLv2 programs) can still use the library under the GPLv2 conditions, while all other users of the library, in particular, all proprietary applications, must abide by the new conditions introduced in LGPLv3.
Regards, /Niels
On Thu, Aug 25, 2011 at 1:46 PM, Niels Möller nisse@lysator.liu.se wrote:
Andres Mejia mcitadel@gmail.com writes:
On Tue, Aug 23, 2011 at 12:49 AM, Niels Möller nisse@lysator.liu.se wrote:
At some point the license may be upgraded to LGPLv3. Or dual license LGPLv3 and GPLv2+. The latter, more complex, alternative would be helpful for you, right?
So long as XBMC can remain GPLv2, then it's ok.
However, I'm sure there are some projects out there that could benefit from an LGPLv2.1 crypto library. I looked around and so far have found one, libaacs which is itself LGPLv2.1. libaacs is used indirectly by XBMC, through libbluray.
I just remembered another example of an LGPLv2.1 library that can make use of nettle. It's called GPAC. It currently uses openssl for crypto. I did at one time try to implement crypto support using libgcrypt, until I read about the problems that arise when using libgcrypt.
I have to look at this more closely before upgrading the license (which I don't have any immediate plans of doing). I'm not sure, but I actually don't see any obvious problem with linking LGPLv2 and LGPLv3 code together.
The problem when linking GPLv2 and LGPLv3 code together is not that LGPLv3 doesn't allow it (after all, LGPL, any version, allows linking even with with proprietary code), but that GPLv2 requires that the *entire* work (except system libraries) can be distributed under GPLv2, with no additional restrictions, and some of the new conditions in (L)GPLv3 (probably the ones related to drm or patents) are additional restrictions.
And dual licensing as LGPLv3+ and GPLv2+ solves precisely that problem: GPLv2 programs (including tivoized GPLv2 programs) can still use the library under the GPLv2 conditions, while all other users of the library, in particular, all proprietary applications, must abide by the new conditions introduced in LGPLv3.
This matrix here might help. http://www.gnu.org/licenses/gpl-faq.html#AllCompatibility
So any LGPL program can use another LGPL library regardless of their versions. However, GPLv2 programs that want to use an LGPLv3 library will need to upgrade to GPLv3. This would be a problem for XBMC. Dual licensing would be better for us.
And just to be clear, dual licensing as LGPLv3+ *or* GPLv2+ would be ok.
Regards, /Niels
-- Niels Möller. PGP-encrypted email is preferred. Keyid C0B98E26. Internet email is subject to wholesale government surveillance.
On 08/23/2011 04:51 AM, Andres Mejia wrote:
Another question, the only thing I see missing in nettle that libarchive can make use of is RIPEMD-160. In case I want to submit patches, I should submit them here correct? Also, I suppose if I wanted to submit patches, there's no issue in porting code from gcrypt over to nettle correct? I think it would be easier (and faster) to reuse the implementation in gcrypt than to implement the algorithm from scratch.
Btw cryptsetup uses ripemd160 if used in plain mode (iow mode where encryption key is directly hashed password). So despite cryptsetup has already optional Nettle crypto backend support, is cannot provide backward compatibility without ripemd160.
So you have yet another user for these patches ;-)
Thanks, Milan
nettle-bugs@lists.lysator.liu.se
-
Andres Mejia -
Milan Broz -
nisse＠lysator.liu.se