llvm dev - Aug 2017 - Relicensing: Revised Developer Policy

This has already been discussed extensively in the public.  The threads are
available in the archives.

-Chris
> On Aug 10, 2017, at 1:05 PM, Rafael Avila de Espindola <rafael.espindola
at gmail.com> wrote:
> 
> Sorry, but I really don't think a private conversation is appropriate
> for such discussions.
> 
> If the motive cannot be explained in public I have no choice but to decide
> based on what I know.
> 
> Cheers,
> Rafael
> 
> Chris Lattner <clattner at llvm.org> writes:
> 
>> Hi Rafael,
>> 
>> We’ve discussed why a license change is preferable over the span of
several years now.  I’m happy to explain over the phone, contact me off list and
we can talk.
>> 
>> -Chris
>> 
>>> On Aug 10, 2017, at 8:33 AM, Rafael Avila de Espindola
<rafael.espindola at gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I still don't see any justification in the text why a license
change is
>>> required over having a contributor agreement including whatever
patent
>>> wording we want.
>>> 
>>> As such, I don't agree with it.
>>> 
>>> Cheers,
>>> Rafael
>>> 
>>> Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org>
writes:
>>> 
>>>> Hi all,
>>>> 
>>>> Now that we’ve settled on the license legalese to get to, we
need to start the process of relicensing.  We’re still sorting through all of
the details of what this will take, but the first step is clear: new
contributions to LLVM will need to be under both the old license structure and
the new one (until the old structure is completely phased out).  From a
mechanical perspective, this is pretty simple, but I want to make sure that the
community is aware of this and has time to digest and discuss any concerns.
>>>> 
>>>> In order to spell out what this will look like, we’ve gone
ahead and revised http://llvm.org/docs/DeveloperPolicy.html to reflect what the
new structure will look like.  While the license text is the canonical truth,
the DeveloperPolicy serves a few purposes: it explains to non-lawyers what the
license means, provides rationale for the design, and deals with relicensing
process topics.
>>>> 
>>>> I’ve attached a draft of the revised document below.  Please
take a look and let me know if anything should be further clarified or if you
have any other questions and comments.  Thanks!
>>>> 
>>>> -Chris
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> Copyright, License, and Patents
>>>> ==============================>>>> 
>>>> .. note::
>>>> 
>>>>  This section deals with legal matters but does not provide
legal advice.  We
>>>>  are not lawyers --- please seek legal counsel from a licensed
attorney.
>>>> 
>>>> This section addresses the issues of copyright, license and
patents for the LLVM
>>>> project.  The copyright for the code is held by the
contributors of
>>>> the code.  The code is licensed under permissive `open source
licensing terms`_,
>>>> namely the Apache 2 license, which includes a copyright and
`patent license`_.
>>>> When you contribute code to the LLVM project, you license it
under these terms.
>>>> 
>>>> If you have questions or comments about these topics, please
contact the
>>>> `LLVM Developer's Mailing List <mailto:llvm-dev at
lists.llvm.org>`_.  However,
>>>> please realize that most compiler developers are not lawyers,
and therefore you
>>>> will not be getting official legal advice.
>>>> 
>>>> Copyright
>>>> ---------
>>>> 
>>>> The LLVM project does not collect copyright assignments, which
means that the
>>>> copyright for the code in the project is held by the respective
contributors.
>>>> Because you (or your company)
>>>> retain ownership of the code you contribute, you know it may
only be used under
>>>> the terms of the open source license you contributed it under:
the license for
>>>> your contributions cannot be changed in the future without your
approval.
>>>> 
>>>> Because the LLVM project does not require copyright
assignments, changing the
>>>> LLVM license requires tracking down the
>>>> contributors to LLVM and getting them to agree that a license
change is
>>>> acceptable for their contributions.  We feel that a high burden
for relicensing
>>>> is good for the project, because contributors do not have to
fear that their
>>>> code will be used in a way with which they disagree.
>>>> 
>>>> Relicensing
>>>> -----------
>>>> 
>>>> The last paragraph notwithstanding, the LLVM Project is in the
middle of a large
>>>> effort to change licenses, which aims to solve several
problems:
>>>> 
>>>> * The old licenses made it difficult to move code from (e.g.)
the compiler to
>>>> runtime libraries, because runtime libraries used a different
license from the
>>>> rest of the compiler.
>>>> * Some contributions were not submitted to LLVM due to concerns
that
>>>> the patent grant required by the project was overly broad.
>>>> * The patent grant was unique to the LLVM Project, not written
by a lawyer, and
>>>> was difficult to determine what was protection was provided (if
any).
>>>> 
>>>> The scope of relicensing is all code that is considered part of
the LLVM
>>>> project, including the main LLVM repository, runtime libraries
(compiler_rt,
>>>> OpenMP, etc), Polly, and all other subprojects.  There are a
few exceptions:
>>>> 
>>>> * Code imported from other projects (e.g. Google Test,
Autoconf, etc) will
>>>> remain as it is.  This code isn't *developed* as part of
the LLVM project, it
>>>> is *used* by LLVM.
>>>> * Some subprojects are impractical or uninteresting to
relicense (e.g. llvm-gcc
>>>> and dragonegg). These will be split off from the LLVM project
(e.g. to
>>>> separate Github projects), allowing interested people to
continue their
>>>> development elsewhere.
>>>> 
>>>> To relicense LLVM, we will be seeking approval from all of the
copyright holders
>>>> of code in the repository, or potentially remove/rewrite code
if we cannot.
>>>> This is a large
>>>> and challenging project which will take a significant amount of
time to
>>>> complete.  In the interim, **all contributions to the project
will be made under
>>>> the terms of both the new license and the legacy license
scheme** (each of which
>>>> is described below).  The exception to this is the legacy
patent grant, which
>>>> will not be required for new contributions.
>>>> 
>>>> When all of the code in the project has been converted to the
new license or
>>>> removed, we will drop the requirement to contribute under the
legacy license.
>>>> This will achieve the goal of having
>>>> a single standardized license for the entire codebase.
>>>> 
>>>> If you are a prior contributor to LLVM and have not done so
already, please do
>>>> *TODO* to allow us to use your code. *Add a link to a separate
page here, which
>>>> is probably a click through web form or something like that. 
Details to be
>>>> determined later*.
>>>> 
>>>> 
>>>> .. _open source licensing terms:
>>>> 
>>>> New LLVM Project License Framework
>>>> ----------------------------------
>>>> 
>>>> Contributions to LLVM are licensed under the `Apache License,
Version 2.0
>>>> <https://www.apache.org/licenses/LICENSE-2.0>`_, with two
limited
>>>> exceptions intended to ensure that LLVM is very permissively
licensed.
>>>> Collectively, the name of this license is "Apache 2.0
License with LLVM
>>>> exceptions".  The exceptions read:
>>>> 
>>>> ::
>>>> 
>>>>  ---- LLVM Exceptions to the Apache 2.0 License ----
>>>> 
>>>>  As an exception, if, as a result of your compiling your source
code, portions
>>>>  of this Software are embedded into an Object form of such
source code, you
>>>>  may redistribute such embedded portions in such Object form
without complying
>>>>  with the conditions of Sections 4(a), 4(b) and 4(d) of the
License.
>>>> 
>>>>  In addition, if you combine or link compiled forms of this
Software with
>>>>  software that is licensed under the GPLv2 ("Combined
Software") and if a
>>>>  court of competent jurisdiction determines that the patent
provision (Section
>>>>  3), the indemnity provision (Section 9) or other Section of
the License
>>>>  conflicts with the conditions of the GPLv2, you may
retroactively and
>>>>  prospectively choose to deem waived or otherwise exclude such
Section(s) of
>>>>  the License, but only in their entirety and only with respect
to the Combined
>>>>  Software.
>>>> 
>>>> 
>>>> We intend to keep LLVM perpetually open source and available
under a permissive
>>>> license - this fosters the widest adoption of LLVM by
>>>> **allowing commercial products to be derived from LLVM** with
few restrictions
>>>> and without a requirement for making any derived works also
open source.  In
>>>> particular, LLVM's license is not a "copyleft"
license like the GPL.
>>>> 
>>>> The "Apache 2.0 License with LLVM exceptions" allows
you to:
>>>> 
>>>> * freely download and use LLVM (in whole or in part) for
personal, internal, or
>>>> commercial purposes.
>>>> * include LLVM in packages or distributions you create.
>>>> * combine LLVM with code licensed under every other major open
source
>>>> license (including BSD, MIT, GPLv2, GPLv3...).
>>>> * make changes to LLVM code without being required to
contribute it back
>>>> to the project - contributions are appreciated though!
>>>> 
>>>> However, it imposes these limitations on you:
>>>> 
>>>> * You must retain the copyright notice if you redistribute
LLVM: You cannot
>>>> strip the copyright headers off or replace them with your own.
>>>> * Binaries that include LLVM must reproduce the copyright
notice (e.g. in an
>>>> included README file or in an "About" box), unless
the LLVM code was added as
>>>> a by-product of compilation.  For example, if an LLVM runtime
library like
>>>> compiler_rt or libc++ was automatically included into your
application by the
>>>> compiler, you do not need to attribute it.
>>>> * You can't use our names to promote your products (LLVM
derived or not) -
>>>> though you can make truthful statements about your use of the
LLVM code,
>>>> without implying our sponsorship.
>>>> * There's no warranty on LLVM at all.
>>>> 
>>>> We want LLVM code to be widely used, and believe that this
provides a model that
>>>> is great for contributors and users of the project.  For more
information about
>>>> the Apache 2.0 License, please see the `Apache License FAQ
>>>> <http://www.apache.org/foundation/license-faq.html>`_,
maintained by the
>>>> Apache Project.
>>>> 
>>>> 
>>>> .. note::
>>>> 
>>>>  The LLVM Project includes some really old subprojects
(dragonegg,
>>>>  llvm-gcc-4.0, and llvm-gcc-4.2), which are licensed under
**GPL
>>>>  licenses**.  This code is not actively maintained - it does
not even
>>>>  build successfully.  This code is cleanly separated into
distinct SVN
>>>>  repositories from the rest of LLVM, and the LICENSE.txt files
specifically
>>>>  indicate that they contain GPL code.  When LLVM transitions
from SVN to Git,
>>>>  we plan to drop these code bases from the new repository
structure.
>>>> 
>>>> 
>>>> .. _patent license:
>>>> 
>>>> Patents
>>>> -------
>>>> 
>>>> Section 3 of the Apache 2.0 license is a patent grant under
which
>>>> contributors of code to the project contribute the rights to
use any of
>>>> their patents that would otherwise be infringed by that code
contribution
>>>> (protecting uses of that code).  Further, the patent grant is
revoked
>>>> from anyone who files a patent lawsuit about code in LLVM -
this protects the
>>>> community by providing a "patent commons" for the
code base and reducing the
>>>> odds of patent lawsuits in general.
>>>> 
>>>> The license specifically scopes which patents are included with
code
>>>> contributions.  To help explain this, the `Apache License FAQ
>>>> <http://www.apache.org/foundation/license-faq.html>`_
explains this scope using
>>>> some questions and answers, which we reproduce here for your
convenience (for
>>>> reference, the "ASF" is the Apache Software
Foundation, the guidance still
>>>> holds though)::
>>>> 
>>>>  Q1: If I own a patent and contribute to a Work, and, at the
time my
>>>>  contribution is included in that Work, none of my patent's
claims are subject
>>>>  to Apache's Grant of Patent License, is there a way any of
those claims would
>>>>  later become subject to the Grant of Patent License solely due
to subsequent
>>>>  contributions by other parties who are not licensees of that
patent.
>>>> 
>>>>  A1: No.
>>>> 
>>>>  Q2: If at any time after my contribution, I am able to license
other patent
>>>>  claims that would have been subject to Apache's Grant of
Patent License if
>>>>  they were licenseable by me at the time of my contribution, do
those other
>>>>  claims become subject to the Grant of Patent License?
>>>> 
>>>>  A2: Yes.
>>>> 
>>>>  Q3: If I own or control a licensable patent and contribute
code to a specific
>>>>  Apache product, which of my patent claims are subject to
Apache's Grant of
>>>>  Patent License?
>>>> 
>>>>  A3:  The only patent claims that are licensed to the ASF are
those you own or
>>>>  have the right to license that read on your contribution or on
the
>>>>  combination of your contribution with the specific Apache
product to which
>>>>  you contributed as it existed at the time of your
contribution. No additional
>>>>  patent claims become licensed as a result of subsequent
combinations of your
>>>>  contribution with any other software. Note, however, that
licensable patent
>>>>  claims include those that you acquire in the future, as long
as they read on
>>>>  your original contribution as made at the original time. Once
a patent claim
>>>>  is subject to Apache's Grant of Patent License, it is
licensed under the
>>>>  terms of that Grant to the ASF and to recipients of any
software distributed
>>>>  by the ASF for any Apache software product whatsoever.
>>>> 
>>>> 
>>>> Legacy License Structure
>>>> ------------------------
>>>> 
>>>> .. note::
>>>>  The code base was previously licensed under the Terms
described here.
>>>>  We are in the middle of relicensing to a new approach
(described above), but
>>>>  until this effort is complete, the code is also still
available under these
>>>>  terms.  Once we finish the relicensing project, new versions
of the code will
>>>>  not be available under these terms.  However, nothing takes
away your right
>>>>  to use old versions under the licensing terms under which they
were
>>>>  originally released.
>>>> 
>>>> We intend to keep LLVM perpetually open source and to use a
permissive open
>>>> source license.  The code in
>>>> LLVM is available under the `University of Illinois/NCSA Open
Source License
>>>> <http://www.opensource.org/licenses/UoI-NCSA.php>`_,
which boils down to
>>>> this:
>>>> 
>>>> * You can freely distribute LLVM.
>>>> * You must retain the copyright notice if you redistribute
LLVM.
>>>> * Binaries derived from LLVM must reproduce the copyright
notice (e.g. in an
>>>> included README file).
>>>> * You can't use our names to promote your LLVM derived
products.
>>>> * There's no warranty on LLVM at all.
>>>> 
>>>> We believe this fosters the widest adoption of LLVM because it
**allows
>>>> commercial products to be derived from LLVM** with few
restrictions and without
>>>> a requirement for making any derived works also open source
(i.e. LLVM's
>>>> license is not a "copyleft" license like the GPL). We
suggest that you read the
>>>> `License
<http://www.opensource.org/licenses/UoI-NCSA.php>`_ if further
>>>> clarification is needed.
>>>> 
>>>> In addition to the UIUC license, the runtime library components
of LLVM
>>>> (**compiler_rt, libc++, and libclc**) are also licensed under
the `MIT License
>>>> <http://www.opensource.org/licenses/mit-license.php>`_,
which does not contain
>>>> the binary redistribution clause.  As a user of these runtime
libraries, it
>>>> means that you can choose to use the code under either license
(and thus don't
>>>> need the binary redistribution clause), and as a contributor to
the code that
>>>> you agree that any contributions to these libraries be licensed
under both
>>>> licenses.  We feel that this is important for runtime
libraries, because they
>>>> are implicitly linked into applications and therefore should
not subject those
>>>> applications to the binary redistribution clause. This also
means that it is ok
>>>> to move code from (e.g.)  libc++ to the LLVM core without
concern, but that code
>>>> cannot be moved from the LLVM core to libc++ without the
copyright owner's
>>>> permission.
>>>> 
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> llvm-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

I can find old threads about it, but nothing saying why it was decided
that contributor agreement wouldn't work. Care to send the URL?

Thanks,
Rafael

Chris Lattner <clattner at llvm.org> writes:
> This has already been discussed extensively in the public.  The threads are
available in the archives.
>
> -Chris
>
>> On Aug 10, 2017, at 1:05 PM, Rafael Avila de Espindola
<rafael.espindola at gmail.com> wrote:
>> 
>> Sorry, but I really don't think a private conversation is
appropriate
>> for such discussions.
>> 
>> If the motive cannot be explained in public I have no choice but to
decide
>> based on what I know.
>> 
>> Cheers,
>> Rafael
>> 
>> Chris Lattner <clattner at llvm.org> writes:
>> 
>>> Hi Rafael,
>>> 
>>> We’ve discussed why a license change is preferable over the span of
several years now.  I’m happy to explain over the phone, contact me off list and
we can talk.
>>> 
>>> -Chris
>>> 
>>>> On Aug 10, 2017, at 8:33 AM, Rafael Avila de Espindola
<rafael.espindola at gmail.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I still don't see any justification in the text why a
license change is
>>>> required over having a contributor agreement including whatever
patent
>>>> wording we want.
>>>> 
>>>> As such, I don't agree with it.
>>>> 
>>>> Cheers,
>>>> Rafael
>>>> 
>>>> Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org>
writes:
>>>> 
>>>>> Hi all,
>>>>> 
>>>>> Now that we’ve settled on the license legalese to get to,
we need to start the process of relicensing.  We’re still sorting through all of
the details of what this will take, but the first step is clear: new
contributions to LLVM will need to be under both the old license structure and
the new one (until the old structure is completely phased out).  From a
mechanical perspective, this is pretty simple, but I want to make sure that the
community is aware of this and has time to digest and discuss any concerns.
>>>>> 
>>>>> In order to spell out what this will look like, we’ve gone
ahead and revised http://llvm.org/docs/DeveloperPolicy.html to reflect what the
new structure will look like.  While the license text is the canonical truth,
the DeveloperPolicy serves a few purposes: it explains to non-lawyers what the
license means, provides rationale for the design, and deals with relicensing
process topics.
>>>>> 
>>>>> I’ve attached a draft of the revised document below. 
Please take a look and let me know if anything should be further clarified or if
you have any other questions and comments.  Thanks!
>>>>> 
>>>>> -Chris
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> Copyright, License, and Patents
>>>>> ==============================>>>>> 
>>>>> .. note::
>>>>> 
>>>>>  This section deals with legal matters but does not provide
legal advice.  We
>>>>>  are not lawyers --- please seek legal counsel from a
licensed attorney.
>>>>> 
>>>>> This section addresses the issues of copyright, license and
patents for the LLVM
>>>>> project.  The copyright for the code is held by the
contributors of
>>>>> the code.  The code is licensed under permissive `open
source licensing terms`_,
>>>>> namely the Apache 2 license, which includes a copyright and
`patent license`_.
>>>>> When you contribute code to the LLVM project, you license
it under these terms.
>>>>> 
>>>>> If you have questions or comments about these topics,
please contact the
>>>>> `LLVM Developer's Mailing List <mailto:llvm-dev at
lists.llvm.org>`_.  However,
>>>>> please realize that most compiler developers are not
lawyers, and therefore you
>>>>> will not be getting official legal advice.
>>>>> 
>>>>> Copyright
>>>>> ---------
>>>>> 
>>>>> The LLVM project does not collect copyright assignments,
which means that the
>>>>> copyright for the code in the project is held by the
respective contributors.
>>>>> Because you (or your company)
>>>>> retain ownership of the code you contribute, you know it
may only be used under
>>>>> the terms of the open source license you contributed it
under: the license for
>>>>> your contributions cannot be changed in the future without
your approval.
>>>>> 
>>>>> Because the LLVM project does not require copyright
assignments, changing the
>>>>> LLVM license requires tracking down the
>>>>> contributors to LLVM and getting them to agree that a
license change is
>>>>> acceptable for their contributions.  We feel that a high
burden for relicensing
>>>>> is good for the project, because contributors do not have
to fear that their
>>>>> code will be used in a way with which they disagree.
>>>>> 
>>>>> Relicensing
>>>>> -----------
>>>>> 
>>>>> The last paragraph notwithstanding, the LLVM Project is in
the middle of a large
>>>>> effort to change licenses, which aims to solve several
problems:
>>>>> 
>>>>> * The old licenses made it difficult to move code from
(e.g.) the compiler to
>>>>> runtime libraries, because runtime libraries used a
different license from the
>>>>> rest of the compiler.
>>>>> * Some contributions were not submitted to LLVM due to
concerns that
>>>>> the patent grant required by the project was overly broad.
>>>>> * The patent grant was unique to the LLVM Project, not
written by a lawyer, and
>>>>> was difficult to determine what was protection was provided
(if any).
>>>>> 
>>>>> The scope of relicensing is all code that is considered
part of the LLVM
>>>>> project, including the main LLVM repository, runtime
libraries (compiler_rt,
>>>>> OpenMP, etc), Polly, and all other subprojects.  There are
a few exceptions:
>>>>> 
>>>>> * Code imported from other projects (e.g. Google Test,
Autoconf, etc) will
>>>>> remain as it is.  This code isn't *developed* as part
of the LLVM project, it
>>>>> is *used* by LLVM.
>>>>> * Some subprojects are impractical or uninteresting to
relicense (e.g. llvm-gcc
>>>>> and dragonegg). These will be split off from the LLVM
project (e.g. to
>>>>> separate Github projects), allowing interested people to
continue their
>>>>> development elsewhere.
>>>>> 
>>>>> To relicense LLVM, we will be seeking approval from all of
the copyright holders
>>>>> of code in the repository, or potentially remove/rewrite
code if we cannot.
>>>>> This is a large
>>>>> and challenging project which will take a significant
amount of time to
>>>>> complete.  In the interim, **all contributions to the
project will be made under
>>>>> the terms of both the new license and the legacy license
scheme** (each of which
>>>>> is described below).  The exception to this is the legacy
patent grant, which
>>>>> will not be required for new contributions.
>>>>> 
>>>>> When all of the code in the project has been converted to
the new license or
>>>>> removed, we will drop the requirement to contribute under
the legacy license.
>>>>> This will achieve the goal of having
>>>>> a single standardized license for the entire codebase.
>>>>> 
>>>>> If you are a prior contributor to LLVM and have not done so
already, please do
>>>>> *TODO* to allow us to use your code. *Add a link to a
separate page here, which
>>>>> is probably a click through web form or something like
that.  Details to be
>>>>> determined later*.
>>>>> 
>>>>> 
>>>>> .. _open source licensing terms:
>>>>> 
>>>>> New LLVM Project License Framework
>>>>> ----------------------------------
>>>>> 
>>>>> Contributions to LLVM are licensed under the `Apache
License, Version 2.0
>>>>> <https://www.apache.org/licenses/LICENSE-2.0>`_, with
two limited
>>>>> exceptions intended to ensure that LLVM is very
permissively licensed.
>>>>> Collectively, the name of this license is "Apache 2.0
License with LLVM
>>>>> exceptions".  The exceptions read:
>>>>> 
>>>>> ::
>>>>> 
>>>>>  ---- LLVM Exceptions to the Apache 2.0 License ----
>>>>> 
>>>>>  As an exception, if, as a result of your compiling your
source code, portions
>>>>>  of this Software are embedded into an Object form of such
source code, you
>>>>>  may redistribute such embedded portions in such Object
form without complying
>>>>>  with the conditions of Sections 4(a), 4(b) and 4(d) of the
License.
>>>>> 
>>>>>  In addition, if you combine or link compiled forms of this
Software with
>>>>>  software that is licensed under the GPLv2 ("Combined
Software") and if a
>>>>>  court of competent jurisdiction determines that the patent
provision (Section
>>>>>  3), the indemnity provision (Section 9) or other Section
of the License
>>>>>  conflicts with the conditions of the GPLv2, you may
retroactively and
>>>>>  prospectively choose to deem waived or otherwise exclude
such Section(s) of
>>>>>  the License, but only in their entirety and only with
respect to the Combined
>>>>>  Software.
>>>>> 
>>>>> 
>>>>> We intend to keep LLVM perpetually open source and
available under a permissive
>>>>> license - this fosters the widest adoption of LLVM by
>>>>> **allowing commercial products to be derived from LLVM**
with few restrictions
>>>>> and without a requirement for making any derived works also
open source.  In
>>>>> particular, LLVM's license is not a
"copyleft" license like the GPL.
>>>>> 
>>>>> The "Apache 2.0 License with LLVM exceptions"
allows you to:
>>>>> 
>>>>> * freely download and use LLVM (in whole or in part) for
personal, internal, or
>>>>> commercial purposes.
>>>>> * include LLVM in packages or distributions you create.
>>>>> * combine LLVM with code licensed under every other major
open source
>>>>> license (including BSD, MIT, GPLv2, GPLv3...).
>>>>> * make changes to LLVM code without being required to
contribute it back
>>>>> to the project - contributions are appreciated though!
>>>>> 
>>>>> However, it imposes these limitations on you:
>>>>> 
>>>>> * You must retain the copyright notice if you redistribute
LLVM: You cannot
>>>>> strip the copyright headers off or replace them with your
own.
>>>>> * Binaries that include LLVM must reproduce the copyright
notice (e.g. in an
>>>>> included README file or in an "About" box),
unless the LLVM code was added as
>>>>> a by-product of compilation.  For example, if an LLVM
runtime library like
>>>>> compiler_rt or libc++ was automatically included into your
application by the
>>>>> compiler, you do not need to attribute it.
>>>>> * You can't use our names to promote your products
(LLVM derived or not) -
>>>>> though you can make truthful statements about your use of
the LLVM code,
>>>>> without implying our sponsorship.
>>>>> * There's no warranty on LLVM at all.
>>>>> 
>>>>> We want LLVM code to be widely used, and believe that this
provides a model that
>>>>> is great for contributors and users of the project.  For
more information about
>>>>> the Apache 2.0 License, please see the `Apache License FAQ
>>>>>
<http://www.apache.org/foundation/license-faq.html>`_, maintained by the
>>>>> Apache Project.
>>>>> 
>>>>> 
>>>>> .. note::
>>>>> 
>>>>>  The LLVM Project includes some really old subprojects
(dragonegg,
>>>>>  llvm-gcc-4.0, and llvm-gcc-4.2), which are licensed under
**GPL
>>>>>  licenses**.  This code is not actively maintained - it
does not even
>>>>>  build successfully.  This code is cleanly separated into
distinct SVN
>>>>>  repositories from the rest of LLVM, and the LICENSE.txt
files specifically
>>>>>  indicate that they contain GPL code.  When LLVM
transitions from SVN to Git,
>>>>>  we plan to drop these code bases from the new repository
structure.
>>>>> 
>>>>> 
>>>>> .. _patent license:
>>>>> 
>>>>> Patents
>>>>> -------
>>>>> 
>>>>> Section 3 of the Apache 2.0 license is a patent grant under
which
>>>>> contributors of code to the project contribute the rights
to use any of
>>>>> their patents that would otherwise be infringed by that
code contribution
>>>>> (protecting uses of that code).  Further, the patent grant
is revoked
>>>>> from anyone who files a patent lawsuit about code in LLVM -
this protects the
>>>>> community by providing a "patent commons" for the
code base and reducing the
>>>>> odds of patent lawsuits in general.
>>>>> 
>>>>> The license specifically scopes which patents are included
with code
>>>>> contributions.  To help explain this, the `Apache License
FAQ
>>>>> <http://www.apache.org/foundation/license-faq.html>`_
explains this scope using
>>>>> some questions and answers, which we reproduce here for
your convenience (for
>>>>> reference, the "ASF" is the Apache Software
Foundation, the guidance still
>>>>> holds though)::
>>>>> 
>>>>>  Q1: If I own a patent and contribute to a Work, and, at
the time my
>>>>>  contribution is included in that Work, none of my
patent's claims are subject
>>>>>  to Apache's Grant of Patent License, is there a way
any of those claims would
>>>>>  later become subject to the Grant of Patent License solely
due to subsequent
>>>>>  contributions by other parties who are not licensees of
that patent.
>>>>> 
>>>>>  A1: No.
>>>>> 
>>>>>  Q2: If at any time after my contribution, I am able to
license other patent
>>>>>  claims that would have been subject to Apache's Grant
of Patent License if
>>>>>  they were licenseable by me at the time of my
contribution, do those other
>>>>>  claims become subject to the Grant of Patent License?
>>>>> 
>>>>>  A2: Yes.
>>>>> 
>>>>>  Q3: If I own or control a licensable patent and contribute
code to a specific
>>>>>  Apache product, which of my patent claims are subject to
Apache's Grant of
>>>>>  Patent License?
>>>>> 
>>>>>  A3:  The only patent claims that are licensed to the ASF
are those you own or
>>>>>  have the right to license that read on your contribution
or on the
>>>>>  combination of your contribution with the specific Apache
product to which
>>>>>  you contributed as it existed at the time of your
contribution. No additional
>>>>>  patent claims become licensed as a result of subsequent
combinations of your
>>>>>  contribution with any other software. Note, however, that
licensable patent
>>>>>  claims include those that you acquire in the future, as
long as they read on
>>>>>  your original contribution as made at the original time.
Once a patent claim
>>>>>  is subject to Apache's Grant of Patent License, it is
licensed under the
>>>>>  terms of that Grant to the ASF and to recipients of any
software distributed
>>>>>  by the ASF for any Apache software product whatsoever.
>>>>> 
>>>>> 
>>>>> Legacy License Structure
>>>>> ------------------------
>>>>> 
>>>>> .. note::
>>>>>  The code base was previously licensed under the Terms
described here.
>>>>>  We are in the middle of relicensing to a new approach
(described above), but
>>>>>  until this effort is complete, the code is also still
available under these
>>>>>  terms.  Once we finish the relicensing project, new
versions of the code will
>>>>>  not be available under these terms.  However, nothing
takes away your right
>>>>>  to use old versions under the licensing terms under which
they were
>>>>>  originally released.
>>>>> 
>>>>> We intend to keep LLVM perpetually open source and to use a
permissive open
>>>>> source license.  The code in
>>>>> LLVM is available under the `University of Illinois/NCSA
Open Source License
>>>>> <http://www.opensource.org/licenses/UoI-NCSA.php>`_,
which boils down to
>>>>> this:
>>>>> 
>>>>> * You can freely distribute LLVM.
>>>>> * You must retain the copyright notice if you redistribute
LLVM.
>>>>> * Binaries derived from LLVM must reproduce the copyright
notice (e.g. in an
>>>>> included README file).
>>>>> * You can't use our names to promote your LLVM derived
products.
>>>>> * There's no warranty on LLVM at all.
>>>>> 
>>>>> We believe this fosters the widest adoption of LLVM because
it **allows
>>>>> commercial products to be derived from LLVM** with few
restrictions and without
>>>>> a requirement for making any derived works also open source
(i.e. LLVM's
>>>>> license is not a "copyleft" license like the
GPL). We suggest that you read the
>>>>> `License
<http://www.opensource.org/licenses/UoI-NCSA.php>`_ if further
>>>>> clarification is needed.
>>>>> 
>>>>> In addition to the UIUC license, the runtime library
components of LLVM
>>>>> (**compiler_rt, libc++, and libclc**) are also licensed
under the `MIT License
>>>>>
<http://www.opensource.org/licenses/mit-license.php>`_, which does not
contain
>>>>> the binary redistribution clause.  As a user of these
runtime libraries, it
>>>>> means that you can choose to use the code under either
license (and thus don't
>>>>> need the binary redistribution clause), and as a
contributor to the code that
>>>>> you agree that any contributions to these libraries be
licensed under both
>>>>> licenses.  We feel that this is important for runtime
libraries, because they
>>>>> are implicitly linked into applications and therefore
should not subject those
>>>>> applications to the binary redistribution clause. This also
means that it is ok
>>>>> to move code from (e.g.)  libc++ to the LLVM core without
concern, but that code
>>>>> cannot be moved from the LLVM core to libc++ without the
copyright owner's
>>>>> permission.
>>>>> 
>>>>> _______________________________________________
>>>>> LLVM Developers mailing list
>>>>> llvm-dev at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

> On Aug 10, 2017, at 2:59 PM, Rafael Avila de Espindola <rafael.espindola
at gmail.com> wrote:
> 
> I can find old threads about it, but nothing saying why it was decided
> that contributor agreement wouldn't work. Care to send the URL?
Here are some quick points that come to mind:

1. It raises the bar to contribution, because something must be “signed” before
a contribution can be made.
2. The Apache CLA is the only widely available one, but it is unsuitable for
LLVM’s goals because it allows a project to relicense contributions.
3. Some contributors are significantly concerned with the Apache CLA, partially
because of #2, but there are other concerns.  Losing contributors would be
unfortunate.
4. We do not want a novel legal device (e.g. a new or significantly hacked up
CLA).
5. The only way to achieve our goals (e.g. the ability to move code between the
compiler and runtime libraries) is through a relicense, so a CLA doesn’t make
anything simpler.

-Chris

> 
> Thanks,
> Rafael
> 
> Chris Lattner <clattner at llvm.org> writes:
> 
>> This has already been discussed extensively in the public.  The threads
are available in the archives.
>> 
>> -Chris
>> 
>>> On Aug 10, 2017, at 1:05 PM, Rafael Avila de Espindola
<rafael.espindola at gmail.com> wrote:
>>> 
>>> Sorry, but I really don't think a private conversation is
appropriate
>>> for such discussions.
>>> 
>>> If the motive cannot be explained in public I have no choice but to
decide
>>> based on what I know.
>>> 
>>> Cheers,
>>> Rafael
>>> 
>>> Chris Lattner <clattner at llvm.org> writes:
>>> 
>>>> Hi Rafael,
>>>> 
>>>> We’ve discussed why a license change is preferable over the
span of several years now.  I’m happy to explain over the phone, contact me off
list and we can talk.
>>>> 
>>>> -Chris
>>>> 
>>>>> On Aug 10, 2017, at 8:33 AM, Rafael Avila de Espindola
<rafael.espindola at gmail.com> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> I still don't see any justification in the text why a
license change is
>>>>> required over having a contributor agreement including
whatever patent
>>>>> wording we want.
>>>>> 
>>>>> As such, I don't agree with it.
>>>>> 
>>>>> Cheers,
>>>>> Rafael
>>>>> 
>>>>> Chris Lattner via llvm-dev <llvm-dev at
lists.llvm.org> writes:
>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> Now that we’ve settled on the license legalese to get
to, we need to start the process of relicensing.  We’re still sorting through
all of the details of what this will take, but the first step is clear: new
contributions to LLVM will need to be under both the old license structure and
the new one (until the old structure is completely phased out).  From a
mechanical perspective, this is pretty simple, but I want to make sure that the
community is aware of this and has time to digest and discuss any concerns.
>>>>>> 
>>>>>> In order to spell out what this will look like, we’ve
gone ahead and revised http://llvm.org/docs/DeveloperPolicy.html to reflect what
the new structure will look like.  While the license text is the canonical
truth, the DeveloperPolicy serves a few purposes: it explains to non-lawyers
what the license means, provides rationale for the design, and deals with
relicensing process topics.
>>>>>> 
>>>>>> I’ve attached a draft of the revised document below. 
Please take a look and let me know if anything should be further clarified or if
you have any other questions and comments.  Thanks!
>>>>>> 
>>>>>> -Chris
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Copyright, License, and Patents
>>>>>> ==============================>>>>>> 
>>>>>> .. note::
>>>>>> 
>>>>>> This section deals with legal matters but does not
provide legal advice.  We
>>>>>> are not lawyers --- please seek legal counsel from a
licensed attorney.
>>>>>> 
>>>>>> This section addresses the issues of copyright, license
and patents for the LLVM
>>>>>> project.  The copyright for the code is held by the
contributors of
>>>>>> the code.  The code is licensed under permissive `open
source licensing terms`_,
>>>>>> namely the Apache 2 license, which includes a copyright
and `patent license`_.
>>>>>> When you contribute code to the LLVM project, you
license it under these terms.
>>>>>> 
>>>>>> If you have questions or comments about these topics,
please contact the
>>>>>> `LLVM Developer's Mailing List <mailto:llvm-dev
at lists.llvm.org>`_.  However,
>>>>>> please realize that most compiler developers are not
lawyers, and therefore you
>>>>>> will not be getting official legal advice.
>>>>>> 
>>>>>> Copyright
>>>>>> ---------
>>>>>> 
>>>>>> The LLVM project does not collect copyright
assignments, which means that the
>>>>>> copyright for the code in the project is held by the
respective contributors.
>>>>>> Because you (or your company)
>>>>>> retain ownership of the code you contribute, you know
it may only be used under
>>>>>> the terms of the open source license you contributed it
under: the license for
>>>>>> your contributions cannot be changed in the future
without your approval.
>>>>>> 
>>>>>> Because the LLVM project does not require copyright
assignments, changing the
>>>>>> LLVM license requires tracking down the
>>>>>> contributors to LLVM and getting them to agree that a
license change is
>>>>>> acceptable for their contributions.  We feel that a
high burden for relicensing
>>>>>> is good for the project, because contributors do not
have to fear that their
>>>>>> code will be used in a way with which they disagree.
>>>>>> 
>>>>>> Relicensing
>>>>>> -----------
>>>>>> 
>>>>>> The last paragraph notwithstanding, the LLVM Project is
in the middle of a large
>>>>>> effort to change licenses, which aims to solve several
problems:
>>>>>> 
>>>>>> * The old licenses made it difficult to move code from
(e.g.) the compiler to
>>>>>> runtime libraries, because runtime libraries used a
different license from the
>>>>>> rest of the compiler.
>>>>>> * Some contributions were not submitted to LLVM due to
concerns that
>>>>>> the patent grant required by the project was overly
broad.
>>>>>> * The patent grant was unique to the LLVM Project, not
written by a lawyer, and
>>>>>> was difficult to determine what was protection was
provided (if any).
>>>>>> 
>>>>>> The scope of relicensing is all code that is considered
part of the LLVM
>>>>>> project, including the main LLVM repository, runtime
libraries (compiler_rt,
>>>>>> OpenMP, etc), Polly, and all other subprojects.  There
are a few exceptions:
>>>>>> 
>>>>>> * Code imported from other projects (e.g. Google Test,
Autoconf, etc) will
>>>>>> remain as it is.  This code isn't *developed* as
part of the LLVM project, it
>>>>>> is *used* by LLVM.
>>>>>> * Some subprojects are impractical or uninteresting to
relicense (e.g. llvm-gcc
>>>>>> and dragonegg). These will be split off from the LLVM
project (e.g. to
>>>>>> separate Github projects), allowing interested people
to continue their
>>>>>> development elsewhere.
>>>>>> 
>>>>>> To relicense LLVM, we will be seeking approval from all
of the copyright holders
>>>>>> of code in the repository, or potentially
remove/rewrite code if we cannot.
>>>>>> This is a large
>>>>>> and challenging project which will take a significant
amount of time to
>>>>>> complete.  In the interim, **all contributions to the
project will be made under
>>>>>> the terms of both the new license and the legacy
license scheme** (each of which
>>>>>> is described below).  The exception to this is the
legacy patent grant, which
>>>>>> will not be required for new contributions.
>>>>>> 
>>>>>> When all of the code in the project has been converted
to the new license or
>>>>>> removed, we will drop the requirement to contribute
under the legacy license.
>>>>>> This will achieve the goal of having
>>>>>> a single standardized license for the entire codebase.
>>>>>> 
>>>>>> If you are a prior contributor to LLVM and have not
done so already, please do
>>>>>> *TODO* to allow us to use your code. *Add a link to a
separate page here, which
>>>>>> is probably a click through web form or something like
that.  Details to be
>>>>>> determined later*.
>>>>>> 
>>>>>> 
>>>>>> .. _open source licensing terms:
>>>>>> 
>>>>>> New LLVM Project License Framework
>>>>>> ----------------------------------
>>>>>> 
>>>>>> Contributions to LLVM are licensed under the `Apache
License, Version 2.0
>>>>>> <https://www.apache.org/licenses/LICENSE-2.0>`_,
with two limited
>>>>>> exceptions intended to ensure that LLVM is very
permissively licensed.
>>>>>> Collectively, the name of this license is "Apache
2.0 License with LLVM
>>>>>> exceptions".  The exceptions read:
>>>>>> 
>>>>>> ::
>>>>>> 
>>>>>> ---- LLVM Exceptions to the Apache 2.0 License ----
>>>>>> 
>>>>>> As an exception, if, as a result of your compiling your
source code, portions
>>>>>> of this Software are embedded into an Object form of
such source code, you
>>>>>> may redistribute such embedded portions in such Object
form without complying
>>>>>> with the conditions of Sections 4(a), 4(b) and 4(d) of
the License.
>>>>>> 
>>>>>> In addition, if you combine or link compiled forms of
this Software with
>>>>>> software that is licensed under the GPLv2
("Combined Software") and if a
>>>>>> court of competent jurisdiction determines that the
patent provision (Section
>>>>>> 3), the indemnity provision (Section 9) or other
Section of the License
>>>>>> conflicts with the conditions of the GPLv2, you may
retroactively and
>>>>>> prospectively choose to deem waived or otherwise
exclude such Section(s) of
>>>>>> the License, but only in their entirety and only with
respect to the Combined
>>>>>> Software.
>>>>>> 
>>>>>> 
>>>>>> We intend to keep LLVM perpetually open source and
available under a permissive
>>>>>> license - this fosters the widest adoption of LLVM by
>>>>>> **allowing commercial products to be derived from
LLVM** with few restrictions
>>>>>> and without a requirement for making any derived works
also open source.  In
>>>>>> particular, LLVM's license is not a
"copyleft" license like the GPL.
>>>>>> 
>>>>>> The "Apache 2.0 License with LLVM exceptions"
allows you to:
>>>>>> 
>>>>>> * freely download and use LLVM (in whole or in part)
for personal, internal, or
>>>>>> commercial purposes.
>>>>>> * include LLVM in packages or distributions you create.
>>>>>> * combine LLVM with code licensed under every other
major open source
>>>>>> license (including BSD, MIT, GPLv2, GPLv3...).
>>>>>> * make changes to LLVM code without being required to
contribute it back
>>>>>> to the project - contributions are appreciated though!
>>>>>> 
>>>>>> However, it imposes these limitations on you:
>>>>>> 
>>>>>> * You must retain the copyright notice if you
redistribute LLVM: You cannot
>>>>>> strip the copyright headers off or replace them with
your own.
>>>>>> * Binaries that include LLVM must reproduce the
copyright notice (e.g. in an
>>>>>> included README file or in an "About" box),
unless the LLVM code was added as
>>>>>> a by-product of compilation.  For example, if an LLVM
runtime library like
>>>>>> compiler_rt or libc++ was automatically included into
your application by the
>>>>>> compiler, you do not need to attribute it.
>>>>>> * You can't use our names to promote your products
(LLVM derived or not) -
>>>>>> though you can make truthful statements about your use
of the LLVM code,
>>>>>> without implying our sponsorship.
>>>>>> * There's no warranty on LLVM at all.
>>>>>> 
>>>>>> We want LLVM code to be widely used, and believe that
this provides a model that
>>>>>> is great for contributors and users of the project. 
For more information about
>>>>>> the Apache 2.0 License, please see the `Apache License
FAQ
>>>>>>
<http://www.apache.org/foundation/license-faq.html>`_, maintained by the
>>>>>> Apache Project.
>>>>>> 
>>>>>> 
>>>>>> .. note::
>>>>>> 
>>>>>> The LLVM Project includes some really old subprojects
(dragonegg,
>>>>>> llvm-gcc-4.0, and llvm-gcc-4.2), which are licensed
under **GPL
>>>>>> licenses**.  This code is not actively maintained - it
does not even
>>>>>> build successfully.  This code is cleanly separated
into distinct SVN
>>>>>> repositories from the rest of LLVM, and the LICENSE.txt
files specifically
>>>>>> indicate that they contain GPL code.  When LLVM
transitions from SVN to Git,
>>>>>> we plan to drop these code bases from the new
repository structure.
>>>>>> 
>>>>>> 
>>>>>> .. _patent license:
>>>>>> 
>>>>>> Patents
>>>>>> -------
>>>>>> 
>>>>>> Section 3 of the Apache 2.0 license is a patent grant
under which
>>>>>> contributors of code to the project contribute the
rights to use any of
>>>>>> their patents that would otherwise be infringed by that
code contribution
>>>>>> (protecting uses of that code).  Further, the patent
grant is revoked
>>>>>> from anyone who files a patent lawsuit about code in
LLVM - this protects the
>>>>>> community by providing a "patent commons" for
the code base and reducing the
>>>>>> odds of patent lawsuits in general.
>>>>>> 
>>>>>> The license specifically scopes which patents are
included with code
>>>>>> contributions.  To help explain this, the `Apache
License FAQ
>>>>>>
<http://www.apache.org/foundation/license-faq.html>`_ explains this scope
using
>>>>>> some questions and answers, which we reproduce here for
your convenience (for
>>>>>> reference, the "ASF" is the Apache Software
Foundation, the guidance still
>>>>>> holds though)::
>>>>>> 
>>>>>> Q1: If I own a patent and contribute to a Work, and, at
the time my
>>>>>> contribution is included in that Work, none of my
patent's claims are subject
>>>>>> to Apache's Grant of Patent License, is there a way
any of those claims would
>>>>>> later become subject to the Grant of Patent License
solely due to subsequent
>>>>>> contributions by other parties who are not licensees of
that patent.
>>>>>> 
>>>>>> A1: No.
>>>>>> 
>>>>>> Q2: If at any time after my contribution, I am able to
license other patent
>>>>>> claims that would have been subject to Apache's
Grant of Patent License if
>>>>>> they were licenseable by me at the time of my
contribution, do those other
>>>>>> claims become subject to the Grant of Patent License?
>>>>>> 
>>>>>> A2: Yes.
>>>>>> 
>>>>>> Q3: If I own or control a licensable patent and
contribute code to a specific
>>>>>> Apache product, which of my patent claims are subject
to Apache's Grant of
>>>>>> Patent License?
>>>>>> 
>>>>>> A3:  The only patent claims that are licensed to the
ASF are those you own or
>>>>>> have the right to license that read on your
contribution or on the
>>>>>> combination of your contribution with the specific
Apache product to which
>>>>>> you contributed as it existed at the time of your
contribution. No additional
>>>>>> patent claims become licensed as a result of subsequent
combinations of your
>>>>>> contribution with any other software. Note, however,
that licensable patent
>>>>>> claims include those that you acquire in the future, as
long as they read on
>>>>>> your original contribution as made at the original
time. Once a patent claim
>>>>>> is subject to Apache's Grant of Patent License, it
is licensed under the
>>>>>> terms of that Grant to the ASF and to recipients of any
software distributed
>>>>>> by the ASF for any Apache software product whatsoever.
>>>>>> 
>>>>>> 
>>>>>> Legacy License Structure
>>>>>> ------------------------
>>>>>> 
>>>>>> .. note::
>>>>>> The code base was previously licensed under the Terms
described here.
>>>>>> We are in the middle of relicensing to a new approach
(described above), but
>>>>>> until this effort is complete, the code is also still
available under these
>>>>>> terms.  Once we finish the relicensing project, new
versions of the code will
>>>>>> not be available under these terms.  However, nothing
takes away your right
>>>>>> to use old versions under the licensing terms under
which they were
>>>>>> originally released.
>>>>>> 
>>>>>> We intend to keep LLVM perpetually open source and to
use a permissive open
>>>>>> source license.  The code in
>>>>>> LLVM is available under the `University of
Illinois/NCSA Open Source License
>>>>>>
<http://www.opensource.org/licenses/UoI-NCSA.php>`_, which boils down to
>>>>>> this:
>>>>>> 
>>>>>> * You can freely distribute LLVM.
>>>>>> * You must retain the copyright notice if you
redistribute LLVM.
>>>>>> * Binaries derived from LLVM must reproduce the
copyright notice (e.g. in an
>>>>>> included README file).
>>>>>> * You can't use our names to promote your LLVM
derived products.
>>>>>> * There's no warranty on LLVM at all.
>>>>>> 
>>>>>> We believe this fosters the widest adoption of LLVM
because it **allows
>>>>>> commercial products to be derived from LLVM** with few
restrictions and without
>>>>>> a requirement for making any derived works also open
source (i.e. LLVM's
>>>>>> license is not a "copyleft" license like the
GPL). We suggest that you read the
>>>>>> `License
<http://www.opensource.org/licenses/UoI-NCSA.php>`_ if further
>>>>>> clarification is needed.
>>>>>> 
>>>>>> In addition to the UIUC license, the runtime library
components of LLVM
>>>>>> (**compiler_rt, libc++, and libclc**) are also licensed
under the `MIT License
>>>>>>
<http://www.opensource.org/licenses/mit-license.php>`_, which does not
contain
>>>>>> the binary redistribution clause.  As a user of these
runtime libraries, it
>>>>>> means that you can choose to use the code under either
license (and thus don't
>>>>>> need the binary redistribution clause), and as a
contributor to the code that
>>>>>> you agree that any contributions to these libraries be
licensed under both
>>>>>> licenses.  We feel that this is important for runtime
libraries, because they
>>>>>> are implicitly linked into applications and therefore
should not subject those
>>>>>> applications to the binary redistribution clause. This
also means that it is ok
>>>>>> to move code from (e.g.)  libc++ to the LLVM core
without concern, but that code
>>>>>> cannot be moved from the LLVM core to libc++ without
the copyright owner's
>>>>>> permission.
>>>>>> 
>>>>>> _______________________________________________
>>>>>> LLVM Developers mailing list
>>>>>> llvm-dev at lists.llvm.org
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev