Bruno Haible <br...@clisp.org> writes: > Hi Simon, > >> I recalled another concern: libunistring is LGPLv3+, glibc is LGPLv2+. >> I don't know how glibc people will think about dynamically loading >> LGPLv3+ code > > Yes, good point. > >> A daemon approach with a smaller wrapper library to communicate with it >> would avoid this concern too > > I'm not in favour of implementing bloated or technically bad solutions for > the reasons of copyright... > >> -- would you be willing to relicense libunistring (or parts >> of it, given that I'll probably stay at Unicode 5.2 at least until I've >> confirmed that it works fine with Unicode 6.0 too) in this case? > > ... therefore, yes, I'm willing to relicense the parts of libunistring that > libidna needs under LGPLv2+. Please come back to me again when you have the > complete and minimal list of the modules that you need.
Willdo. For illustration, right now the complete list of gnulib modules that I need are: git-version-gen lib-symbol-versions maintainer-makefile uniconv/u8-strconv-from-locale unictype/bidicategory-of unictype/property-combining uninorm/nfc uninorm/u32-normalize unistr/u32-cpy-alloc unistr/u32-to-u8 unistr/u8-to-u32 I'm not yet sure whether to generate the RFC 5892 tables on-the-fly or during-compilation or not at all. The first alternative would have an impact on the modules needed. OTOH, by only relicensing some modules, I don't think I can use an installed libunistring shared library, which would contain LGPLv3+ code too. /Simon
