On Wed, 26 Aug 2020 at 09:59, Christian Mazakas via Boost
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.