<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr">On Wed, Oct 12, 2016 at 1:53 AM David Chisnall <<a href="mailto:David.Chisnall@cl.cam.ac.uk">David.Chisnall@cl.cam.ac.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On 12 Oct 2016, at 09:34, Chandler Carruth <<a href="mailto:chandlerc@gmail.com" class="gmail_msg" target="_blank">chandlerc@gmail.com</a>> wrote:<br class="gmail_msg">> Given the tendency of utilities like this to become used pervasively in the project, it would seem a fairly heavy weight dependency to grow.<br class="gmail_msg"><br>A reimplementation is likely to be no less complex than any of the originals.  Both fmtlib and FastFormat are under BSD / MIT-style licenses and are both small enough that it would be possible to embed copies of either in the LLVM tree if eliminating a dependency were desired.<br class="gmail_msg"></blockquote><div><br></div><div>Sorry, by heavyweight I meant more that everything in LLVM would end up using it, and so any potential license incompatibility would be a serious issue.</div><div><br></div><div>And "BSD / MIT-style licenses" specifically don't address a number of the issues raised in the licensing thread. I don't want to try to rehash it here, but if we as a community think those issues are worth addressing, that precludes depending on existing code carrying these licenses.</div><div><br></div><div>As a specific issue: if this code ends up transitively used in runtime libraries, we would have binary attribution problems. So adding a dependency on code under some other license is, IMO, problematic from a very basic pragmatic perspective. It would move us back into having a weird partition through the LLVM project of some code that could go into runtimes but other code that could not go into runtimes. I don't want to go back to that point.</div></div></div>