Re: Boost.Text Unicode licence issues

From: Darryl Green (darryl.green_at_[hidden])
Date: 2020-08-26 16:02:23

On Wed, 26 Aug 2020 at 09:59, Christian Mazakas via Boost
<boost_at_[hidden]> wrote:
>
> > 5. Removing this from Boost.Text, keeping just the UTFn conversion
> > code and anything else that doesn't depend on the problematic data files
> > (as I advocated in my review).
>
> I think this would be to the ultimate detriment of the library. Anything
> Boost.Text can do for the user is a boon in this regard and only increases
> the quality of the lib.
>

Agree

> > 1. A run-time dependency on libicu, getting libicu to do all the
> > work, as Boost.Locale does.
>
> I think this would be the best path forward. Obtaining a dynamic version
> of libicu is relatively straight-forward on all systems and would dodge the
> licensing issues.
>

I disagree as a user. From a user perspective a libicu dependency does
not "dodge" anything. The user then definitely has to comply with the
libicu license. Also, for many uses of the words "all systems" (that
want to process unicode text) obtaining and using a dynamic version of
libicu is anything but "reasonably straight-forward". Having only a
licence issue to resolve is simpler than having a library dependency
that itself creates a dependency on the same license. Note I am not
referring to any "copyleft" issues that might arise (and might or
might not be avoided through dynamic linking - its hard to dynamically
link a header dependency) as there is no copyleft involved in this
license. The preceding is about licence terms - but there is first an
issue of what rights the copyright holder actually has over the work /
whether the work is actually copyrightable in the first place. Some
would claim that the icu data files are simply a list of facts and not
creative. However, as ICU "made up" (defined) some of those facts it
perhaps can't be said not to be creative. In the absence of explicit
permission from ICU to place a different licence on the generated
files it may be best to ensure that these files do identify their ICU
dependency/derivation, and reference the relevant licence. Any/all of
Boost.Text that does not depend on these files should be usable in a
"NO_ICU" build that does not include/compile any of the generated
files. And the ICU licence should be included with and referenced from
the generated files. What a user chooses to do is up to them. Boost
has definitely complied. And the user issue is JUST how (and, dare I
say, if) to comply with the ICU license terms - which at worst
requires distributing the ICU license file somehow. This isn't a huge
hardship.