[llvm-dev] moving libfuzzer to compiler-rt?

Chris Bieneman via llvm-dev llvm-dev at lists.llvm.org
Thu May 4 11:31:41 PDT 2017


IANAL, but I have a few licensing related concerns about a some of the things being discussed on this thread.

(1) We can't move libFuzzer to compiler-rt without re-licesning the code or making the compiler-rt repository contain code covered under different licenses. This is because compiler-rt is licensed differently from LLVM. IMO, this should make moving the code into compiler-rt untenable at least until after the project's general licensing discussion reaches some form of resolution.

(2) libFuzzer is licensed today under LLVM's UIUC license which requires binary attribution. If we're adding options to the clang driver, and potentially including libFuzzer in distributions of LLVM, this licensing requirement becomes problematic for our users. We should consider how bet to approach this.

I do believe that Justin's solution of structuring libFuzzer as a standalone project and moving it under llvm/runtimes does side-step some of the licensing complications, and it is a good technical solution to the problem at least in the interim.

I think waiting for the monorepo to happen is a bad idea. If only from the perspective that we haven't actually had that decision made yet, so waiting for something that may not actually happen isn't a great solution.

-Chris


> On May 3, 2017, at 2:10 PM, Kostya Serebryany via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> >
> > can we?
> > If we can, then we probably can also leave the code where it is, and tweak
> > the cmake to use just-built-clang. No?
> 
> Absolutely - this shouldn't be all that hard. I'd thought about taking a
> crack at it a while ago but I haven't had the time.
> 
> The only complicated part is deciding what to do when we're not building
> clang - should we build libFuzzer with the host compiler in this case,
> or not build it at all?
> not build at all
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170504/6db50324/attachment.html>


More information about the llvm-dev mailing list