[LLVMdev] Using LLVM code in projects/compiler-rt

[Kostya Serebryany]

On Fri, Jun 1, 2012 at 12:20 PM, Chandler Carruth <chandlerc at google.com>wrote:

> On Fri, Jun 1, 2012 at 12:59 AM, Kostya Serebryany <kcc at google.com> wrote:
>
>>
>>
>> On Fri, Jun 1, 2012 at 10:17 AM, Chandler Carruth <chandlerc at google.com>wrote:
>>
>>> On Thu, May 31, 2012 at 11:10 PM, Daniel Berlin <dberlin at dberlin.org>wrote:
>>>
>>>> >
>>>> > #4 is interesting, but a *ton* of work. The Object library, most of
>>>> Support
>>>> > and System, all would have to sink into this core module, all would
>>>> have to
>>>> > get dual-licensed (ow!!! how? some of the contributors are around to
>>>> agree
>>>> > to new license, but not all... likely a fair amount of rewrite
>>>> required to
>>>> > produce new versions of libraries under the correct license).
>>>>
>>>> You actually don't have that many contributors. I've seen this done
>>>> for projects with 200+ contributors.
>>>> Even better, most LLVM contributors are still around.
>>>> If you have to rewrite a little code along the way to account for
>>>> folks you can't find, this is probably worth the expense anyway (and
>>>> i'm pretty sure we'd be happy to fund it :P).
>>>>
>>>
>>> After talking with DannyB, I now am strongly in the camp that we should
>>> do #4 whole-sale, and make everything hold a license that works for
>>> runtimes. We can potentially move completely away from dual-licensing.
>>>
>>> We can definitely drive this effort if the community is supportive,
>>> including re-writing parts of the codebase from authors we can't contact.
>>>
>>
>> What will be our (asan/tsan) next steps?
>>
>
> I think you can carry on with #1 in the interim.
>
Ok.

> I'll up-prioritize the build system stuff, and maybe we can chat about how
> to share some of that work?
>

Yes, definitely.

--kcc


> All of that work is necessary even if we figure out whatever license
> arrangement we end up with. During that time, we should document carefully
> that this attaches the attribution requirement, and we should be able to
> have the license issues fixed prior to the next LLVM release so it doesn't
> have to be permanent.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120601/4e6259d6/attachment.html>