On Sat, 20 Jun 2020 at 09:32, Peter Dimov via Boost
Zach Laine wrote:
Of course, and I don't think Boost.Text actually imposes any such requirement. Boost.Locale also uses ICU headers and links to ICU, and neither shows the Unicode copyright, nor requires its users to do so.
But Boost.Local merely depends on ICU being installed. It doesn't include any ICU code.
Boost.Text will have some code derived from ICU, and that implies that Boost.Text should impose the same license-notification obligations on the user that ICU does on Boost.Locale. That is, none.
This is one of those things for which lawyers say "this is an interesting position, and I'd be glad to try it in court for you and see how it goes."
IANAL. But I also don't see how one can extrapolate from a case where headers and a library binary are obtained/built/installed by a user and then used to resolve a Boost.Local dependency to one where some of that libraries "source files" (not to be specific about file/content type/semantics) are used to produce files that form part of Boost.Text source distribution. Note this is based on my rough understanding of what Boost.Text is actually doing/depending on from unicode.org / ICU. Please correct me if I am wrong.
<snip>
Is it really necessary to use the original ICU files?
A different set of questions: 1. Does a Boost.Text library user (not author) actually need any ICU files when using Boost.Text? 2. Is the use of ICU files by Boost.Text limited to the generation (by the author/committer, not an end user) of C++ static definitions from ICU .txt file definitions / data? 3. Is there code in Boost.Test itself that was copied and modified from ICU sources? I had been (in another thread) assuming the answers to the above were No, Yes, No. Had that been the case I would have (and still will in the context of that part of the usage) argue that the use of ICU data (in .txt files) was by Zach to extract values from that published data and use them to produce C++. This extraction of data (effectively, parts of the unicode spec - one could have extracted/obtained it other ways) has been automated by Zach but that doesn't mean that the output of the automated process (the generator program/template being a creative work by Zach, not ICU) is necessarily a derived work. This depends on whether the source data used was, by itself, without the rest of the ICU code etc a creative work v.s just a list of values/information but "just data". But question 3 is more problematic - I think the answer is actually Yes. Some headers in https://github.com/tzlaine/text/tree/master/include/boost/text/detail/icu seem to be modified from ICU headers. Some of them have quite complex derivation/licence pre-history - as well as significant modification by Zach. This is more of a problem than any use of original ICU files imho because they can't be replaced with references to the ICU files (vs including them in Boost). Possible(?) solutions are: 1. I am wrong (lets hope). 2. A "clean-room" re-implementation of these headers without use/reference to ICU code 3. Modify Boost.Text detail to be an adapter between the unmodified ICU code/interface and Boost.Text (I have no idea if that is practical) 4. Give in and include ICU and unicode.org licence terms etc as/where required (I realise this won't happen and is a very messy proposition - ICU shows some of the issues with not having a policy like Boost's) Only 1 and 2 avoid requiring that users install ICU (or at least ICU headers)... Perhaps I am wrong about the answers to the questions - but I think they do need answering/resolving.