[llvm-dev] Relicensing: Revised Developer Policy

[Chandler Carruth via llvm-dev]

On Thu, Aug 10, 2017 at 3:03 PM Chris Lattner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> > On Aug 10, 2017, at 2:59 PM, Rafael Avila de Espindola <
> rafael.espindola at gmail.com> wrote:
> >
> > I can find old threads about it, but nothing saying why it was decided
> > that contributor agreement wouldn't work. Care to send the URL?
>
> Here are some quick points that come to mind:
>
> 1. It raises the bar to contribution, because something must be “signed”
> before a contribution can be made.
> 2. The Apache CLA is the only widely available one, but it is unsuitable
> for LLVM’s goals because it allows a project to relicense contributions.
> 3. Some contributors are significantly concerned with the Apache CLA,
> partially because of #2, but there are other concerns.  Losing contributors
> would be unfortunate.
> 4. We do not want a novel legal device (e.g. a new or significantly hacked
> up CLA).
> 5. The only way to achieve our goals (e.g. the ability to move code
> between the compiler and runtime libraries) is through a relicense, so a
> CLA doesn’t make anything simpler.
>

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


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