bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: uninorm/nfc - Unicode version?


From: Simon Josefsson
Subject: Re: uninorm/nfc - Unicode version?
Date: Wed, 19 Jan 2011 08:27:54 +0100
User-agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.2 (gnu/linux)

Bruno Haible <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]