LLVM Developers Discuss Relicensing Code To Apache License
Right now LLVM's license is the permissive University of Illinois/NCSA Open Source License, which is similar to the three-clause BSD license. However, over concerns that some companies feel blocked from contributing to LLVM as a result of its overly vague patent section of the LLVM developer policy, there's a proposal to relicense the code under Apache 2.0.
However, shifting the license would break compatibility with the GPLv2 and could make this compiler less interesting to the BSD developers from contributing. LLVM Founder Chris Lattner issued the request for comments over possibly changing the license. The current licensing situation is also problematic for not being able to easily move code from LLVM to their Compiler-RT sub-project, since that's licensed under both the UIUC and MIT licenses.
Other potential alternatives to putting the LLVM code under Apache 2.0 would be either coming up with a brand new license or other "novel legal solution", require contributors to sign the Apache Contributor License Agreement (CLA), etc. Chris though and the LLVM Foundation are in favor of re-licensing all the code, "This probably isn’t a surprise at this point, but the LLVM Foundation board and I recommend that we relicense all of the LLVM Project code (including clang, lldb,...) currently under the UIUC and MIT licenses (i.e. not including the GPL bits like llvm-gcc and dragonegg) under the Apache 2 license. We feel that it is important to do something right for the long term, even if it is a complicated and slow process, than to do the wrong thing in the short term. It will take quite some time to roll this out - potentially 18 months or more, but we believe it is possible and have some thoughts about how to do it. We have confirmed that choosing to go down this path would immediately unblock contributions from the affected companies, because we could start accepting new contributions under the terms of the UIUC/MIT/Apache licenses together and repeal the wording in the developer policy. If we get broad agreement that this is the right direction to go, we can lay out our early ideas for how to do it, and debate and fully bake that plan in public discussion."
The aforelinked mailing list thread has commentary on both sides of the table and no conclusion has been drawn yet with this matter to be discussed further at this week's LLVM Developer Meeting (29-30 October, San Jose).
24 Comments
