Gesendet: Donnerstag, 27. August 2020 um 07:15 Uhr Von: "Rainer Deyke via Boost"
On 26.08.20 01:58, Christian Mazakas via Boost wrote:
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.
The only reason I'm interested in Boost.Text is that it will help me get rid of my dependency on ICU, with its broken build system and bloat. A version of Boost.Text that relies on ICU has no value to me, and I would not use it.
For me it wouldn't become useless, but I'd certainly say it would be the least appealing solution for me and make it significantly less likely that we will use this library in one of our projects. Also, how would such a design impact the interface and performance of this library? For example this would make it impossible to ever use parts of this lib in a constexpr context correct?. Considering that it seems unclear if such measure are necessary to begin with, I'd implore the boost organization to first seek legal advice and/or contact whoever holds the copyright for libicu to establish that this is really the only viable option before taking "the easy way out" and delivering a technically inferior library just out of uncertainty. What I wonder: If the same data could - in theory - be scraped from a published ISO standards document, then can that data really be subject to the libicu license requirements? I'm also not positive, that if you put a copyrighted document through a language processor and the output retains none of the structure of the original document, that this counts as "derived work" in the sense of copyright law. Extreme case: If I run a novel through a tool like, wc, I don't believe the output of that tool would stell be under the copyright of the owner. Of course IANAL so my opinion doesn't mean anything, but this is why this should be reviewd by someone who is actually a lawyer. Best Mike
-- Rainer Deyke (rainerd@eldwood.com)