[llvm-dev] Relicensing: Revised Developer Policy

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev
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 <[hidden email]>`_.  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
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
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
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
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
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
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

devpolicy.patch (16K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev
On 08/07/2017 08:53 AM, Chris Lattner via llvm-dev wrote:

> 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:[hidden email]>`_.  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*.
>
>

I had to read this paragraph a few times before I realized that this was a TODO
message for the author of the policy, and there was nothing for me (a prior
contributor) to do yet.  I would change this to something like:
" In the future we will have a mechanism for prior contributors to re-license
their code ..."

-Tom
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev
In reply to this post by George Karpenkov via llvm-dev
On 7 August 2017 at 16:53, Chris Lattner via llvm-dev
<[hidden email]> wrote:

> 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*.

Although the LLVM project and LLVM Foundation obviously can't give
legal advice, this page probably needs to be a little more than just a
web form. There is a wide variance in the level of understanding of
copyright and licensing issues across the developer community, even
open source contributors. As such, I think LLVM would benefit from
highlighting the sort of things contributors should be sure of before
submitting their permission, to ensure they have the authority to do
so. One scenario would be work-for-hire where permission was granted
to submit the code upstream, but copyright may still be held by the
client.

I'm really glad to see this re-licensing effort continuing to move
forwards. Thanks to everyone who has been working on it.

Best,

Alex
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev
On Mon, Aug 7, 2017 at 11:48 PM Alex Bradbury via llvm-dev <[hidden email]> wrote:
On 7 August 2017 at 16:53, Chris Lattner via llvm-dev
<[hidden email]> wrote:
> 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*.

Although the LLVM project and LLVM Foundation obviously can't give
legal advice, this page probably needs to be a little more than just a
web form. There is a wide variance in the level of understanding of
copyright and licensing issues across the developer community, even
open source contributors. As such, I think LLVM would benefit from
highlighting the sort of things contributors should be sure of before
submitting their permission, to ensure they have the authority to do
so. One scenario would be work-for-hire where permission was granted
to submit the code upstream, but copyright may still be held by the
client.

When we get to this point, we'll definitely be working with the lawyer for the Foundation to make sure we get the legal things worked out correctly. I think this TODO is just essentially a note for others that "something" vetted by our lawyer will go here, not trying to forecast exactly what it will be.

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev
On 8 August 2017 at 07:53, Chandler Carruth <[hidden email]> wrote:

> On Mon, Aug 7, 2017 at 11:48 PM Alex Bradbury via llvm-dev
> <[hidden email]> wrote:
>> Although the LLVM project and LLVM Foundation obviously can't give
>> legal advice, this page probably needs to be a little more than just a
>> web form. There is a wide variance in the level of understanding of
>> copyright and licensing issues across the developer community, even
>> open source contributors. As such, I think LLVM would benefit from
>> highlighting the sort of things contributors should be sure of before
>> submitting their permission, to ensure they have the authority to do
>> so. One scenario would be work-for-hire where permission was granted
>> to submit the code upstream, but copyright may still be held by the
>> client.
>
>
> When we get to this point, we'll definitely be working with the lawyer for
> the Foundation to make sure we get the legal things worked out correctly. I
> think this TODO is just essentially a note for others that "something"
> vetted by our lawyer will go here, not trying to forecast exactly what it
> will be.

That makes sense, thanks for the clarification.

Best,

Alex
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev
In reply to this post by George Karpenkov via llvm-dev
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 <[hidden email]> 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:[hidden email]>`_.  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
> [hidden email]
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev
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 <[hidden email]> 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 <[hidden email]> 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:[hidden email]>`_.  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
>> [hidden email]
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev
In reply to this post by George Karpenkov via llvm-dev

> On Aug 7, 2017, at 10:53, Chris Lattner via llvm-dev <[hidden email]> wrote:
>
> * 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).

Minor nit: "what was protection was" -> "what protection was".

--
Stephen Checkoway



_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev
In reply to this post by George Karpenkov via llvm-dev
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:[hidden email]>`_.  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
>>> [hidden email]
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:[hidden email]>`_.  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
>>>> [hidden email]
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:[hidden email]>`_.  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
>>>>> [hidden email]
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev

> On Aug 10, 2017, at 2:59 PM, Rafael Avila de Espindola <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:[hidden email]>`_.  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
>>>>>> [hidden email]
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev
On Thu, Aug 10, 2017 at 3:03 PM Chris Lattner via llvm-dev <[hidden email]> wrote:

> On Aug 10, 2017, at 2:59 PM, Rafael Avila de Espindola <[hidden email]> 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.

I think I remember another important issue in addition, let me dig through notes...
 

-Chris


>
> Thanks,
> Rafael
>
> Chris Lattner <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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:[hidden email]>`_.  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
>>>>>> [hidden email]
>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev
In reply to this post by George Karpenkov via llvm-dev
Chris Lattner <[hidden email]> writes:

>> On Aug 10, 2017, at 2:59 PM, Rafael Avila de Espindola <[hidden email]> 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.

Yes, but changing the license impacts our users, which is a bigger issue IMHO.

> 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).

We are proposing moving to modified Apache license. Why is a modified
license less troublesome than a modified 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.

I have no problem changing the license to something FreeBSD and OpenBSD
are happy with.

Cheers,
Rafael
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev
On Aug 10, 2017, at 3:08 PM, Rafael Avila de Espindola via llvm-dev <[hidden email]> wrote:

> Chris Lattner <[hidden email]> writes:
>
>>> On Aug 10, 2017, at 2:59 PM, Rafael Avila de Espindola <[hidden email]> 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.
>
> Yes, but changing the license impacts our users, which is a bigger issue IMHO.

We don’t believe that the relicense will impact users of LLVM.  Also, a relicense is unavoidable, as I already explained.

>> 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).
>
> We are proposing moving to modified Apache license. Why is a modified
> license less troublesome than a modified CLA?

The proposal is not a modified apache license.  It is an apache license that has some exceptions which can be completely ignored by a user of LLVM if they choose, and the exceptions are carefully scoped by many lawyers to ensure they are bounded in the right ways.

Designing a new CLA would be a significantly novel device which is very bad for reasons I’ve already explained in previous threads.

>> 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.
>
> I have no problem changing the license to something FreeBSD and OpenBSD
> are happy with.

I request that you let other people worry about and represent their own concerns: there is no need for you to try to defend or represent other other people’s interests.  There is a lot of diligence that is happening off list, which is one of the reasons progress is slow.  We’re doing everything possible to make sure the right thing happens for users and contributors, even if it is at the expense of calendar time.

That said, my understanding is that they are currently evaluating this, and the current (but not finalized) belief is that the new license is good for FreeBSD.  

-Chris

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev
Chris Lattner <[hidden email]> writes:

>> Yes, but changing the license impacts our users, which is a bigger issue IMHO.
>
> We don’t believe that the relicense will impact users of LLVM.  Also, a relicense is unavoidable, as I already explained.

The impact depends on the license. I don't think anyone ever objected to
MIT for example, and relicensing to that solves the issue of different
parts of llvm having different licenses.

>> I have no problem changing the license to something FreeBSD and OpenBSD
>> are happy with.
>
> I request that you let other people worry about and represent their own concerns: there is no need for you to try to defend or represent other other people’s interests.  There is a lot of diligence that is happening off list, which is one of the reasons progress is slow.  We’re doing everything possible to make sure the right thing happens for users and contributors, even if it is at the expense of calendar time.
>
> That said, my understanding is that they are currently evaluating this, and the current (but not finalized) belief is that the new license is good for FreeBSD.  

It is my interest to see my code used. In particular I am really excited
to see llvm/clang/lld/lldb/etc replacing more and more of the previous
components on these systems. I really don't want to harm that change.

If FreeBSD and OpenBSD are OK with license X, I am OK with license X.

Cheers,
Rafael
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev
On Aug 10, 2017, at 5:29 PM, Rafael Avila de Espindola <[hidden email]> wrote:

>>> I have no problem changing the license to something FreeBSD and OpenBSD
>>> are happy with.
>>
>> I request that you let other people worry about and represent their own concerns: there is no need for you to try to defend or represent other other people’s interests.  There is a lot of diligence that is happening off list, which is one of the reasons progress is slow.  We’re doing everything possible to make sure the right thing happens for users and contributors, even if it is at the expense of calendar time.
>>
>> That said, my understanding is that they are currently evaluating this, and the current (but not finalized) belief is that the new license is good for FreeBSD.  
>
> It is my interest to see my code used. In particular I am really excited
> to see llvm/clang/lld/lldb/etc replacing more and more of the previous
> components on these systems. I really don't want to harm that change.
>
> If FreeBSD and OpenBSD are OK with license X, I am OK with license X.

Great, thanks Rafael. I totally understand where you’re coming from.  I think that many of us contributors care a lot about our code being used as widely as possible :-)

-Chris

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev
In reply to this post by George Karpenkov via llvm-dev
On 11 Aug 2017, at 01:29, Rafael Avila de Espindola via llvm-dev <[hidden email]> wrote:
>
> If FreeBSD and OpenBSD are OK with license X, I am OK with license X.

Note: I don’t speak for either project, as I stood down from the FreeBSD Core Team last election (after two terms, I was owed some time off for good behaviour), but as I was part of the FreeBSD Core Team for much of this long process, I’m going to comment anyway.

OpenBSD and FreeBSD have different license policies, but Chris and others involved in this process have iterated with the FreeBSD project and the latest version has been sent to the FreeBSD Foundation’s lawyer.  We had several concerns about early versions of the license.  Most notably, we want to ship libc++ and compiler-rt as part of the base system and place no obligations on any third-party code.  The current version of the exemption appears to allow this[1] and also makes a number of other uses (e.g. using DRI drivers with X.org that use LLVM) equally simple.

My understanding of the new license is that it will make life easier for a number of downstream consumers, at the cost of a bit more legalese to wade through (though far less than the GPL, even v2).  I would be happier if we could achieve the same objective with less legal text, but the Apache 2 license plus the LLVM exemption appears to be close to the minimum that possible with the desired goals (permissive license, no restrictions on library use, patent protection).  In particular, the Apache 2 license has already been scrutinised by a lot of lawyers working for both companies that use / distribute open source software and for various open source foundations and is well understood.  The exemption is clear and excludes the only terms of the license that are not simply describing good manners.

Relicensing all of the code is going to be a complicated process, and I’m grateful to the LLVM Foundation for undertaking this effort.  There will probably be some pain in the intermediate steps, but I believe that the end state will be an improvement over the current state.

David

[1] I am not a lawyer, so I don’t make this claim strongly until we’ve heard back from the Foundation’s lawyer, but it looks pretty clear.
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev
In reply to this post by George Karpenkov via llvm-dev
> It is my interest to see my code used. In particular I am really excited
> to see llvm/clang/lld/lldb/etc replacing more and more of the previous
> components on these systems. I really don't want to harm that change.
>
> If FreeBSD and OpenBSD are OK with license X, I am OK with license X.

Rafael,

It is my understanding that Apache 2.0 licensed code will not be
integrated into OpenBSD under the current copyright policy:
https://www.openbsd.org/policy.html

This is problematic given that the default compiler on amd64 and i386
was just changed to clang:
https://marc.info/?l=openbsd-cvs&m=150109829003860

OpenBSD developers have previously made their position clear during
this discussion:
http://lists.llvm.org/pipermail/llvm-dev/2017-April/112300.html

That said, Chris and others have made it clear that the relicensing
process will proceed as planned. LLVM will most likely be forked.
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [llvm-dev] Relicensing: Revised Developer Policy

George Karpenkov via llvm-dev
In reply to this post by George Karpenkov via llvm-dev
Chris Lattner <[hidden email]> writes:
>>> 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).
>>
>> We are proposing moving to modified Apache license. Why is a modified
>> license less troublesome than a modified CLA?
>
> The proposal is not a modified apache license.  It is an apache license that has some exceptions which can be completely ignored by a user of LLVM if they choose, and the exceptions are carefully scoped by many lawyers to ensure they are bounded in the right ways.

The code is then effectively dual licensed. It is both Apache and
Apache+exceptions.

Could it be Apache+MIT for example?

Since every contributor would be agreeing with both, we would still get
section 3 (the grant of patents), and could drop our current patent
wording.

Cheers,
Rafael
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
12
Loading...