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.> The more interesting question is whether you want to dual license, add > a general exception to the LLVM license, or switch wholesale to MIT > license. >This is indeed the question: what should the end state be. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120531/e3332d60/attachment.html>
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? --kcc> > >> The more interesting question is whether you want to dual license, add >> a general exception to the LLVM license, or switch wholesale to MIT >> license. >> > > This is indeed the question: what should the end state be. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120601/f38b5dec/attachment.html>
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. I'll up-prioritize the build system stuff, and maybe we can chat about how to share some of that work? 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/ac7ea4b1/attachment.html>