llvm dev - Apr 2017 - RFC #3: Improving license & patent issues in the LLVM community

Hello everyone,

This email is a continuation of a discussion started in October 2015, and
continued in September 2016:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html
http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html

As with those emails, this is a complicated topic and deals with sensitive legal
issues.  I am not a lawyer, and this email is not intended to be legal advice in
the formal sense.  That said, I have spoken with many lawyers about this,
Heather Meeker (a prominent and distinguished OSS licensing attorney) has agreed
to represent the interests of the LLVM Community as independent counsel.  This
proposal incorporates all of their feedback.


The goals of this effort are outlined in the first email but, in short, we aim
to:
- encourage ongoing contributions to LLVM by preserving low barrier to entry for
contributors.
- protect users of LLVM code by providing explicit patent protection in the
license.
- protect contributors to the LLVM project by explicitly scoping their patent
contributions with this license.
- eliminate the schism between runtime libraries and the rest of the compiler
that makes it difficult to move code between them.
- ensure that LLVM runtime libraries may be used by other open source and
proprietary compilers.

Here we are discussing what the best end game is -- not the logistics of how to
get from here to there.


In case you haven’t been following, here is an attempt at quick recap the
history, leading to today:

The first email thread addressed the issue of how to structure the new LLVM
license, what the problem to be solved is, and rationale for a general approach.
We decided and converged on using the approach of the industry standard Apache 2
License, with exceptions to correct problematic cases for the LLVM community
(specifically, the issue of runtime libraries that are implicitly linked into an
application by the compiler).  The concern there is that users of LLVM compilers
(e.g. Clang) would not necessarily know that runtime libraries are implicitly
linked into their application, and thus fail to attribute the LLVM project in
binaries.  The LLVM project generally isn’t widely concerned with binary
attribution, but widespread noncompliance with license terms can lead to
problems enforcing other terms in the license.

That first discussion recognized the binary attribution issue, but a second
concern was raised by some who believe the Apache 2 and GPL version 2.0 licenses
are incompatible.  The second email thread addressed that compatibility concern
by introducing a second exception clause.  In the second email thread, those
concerned about GPL2 were satisfied, but an additional issue was raised about
the first binary attribution clause: specifically, we aim for the LLVM runtime
libraries to be used very permissively, even by proprietary compilers and
linkers.  This led to another round of intense (offline) discussion about the
concrete wording of the exceptions, which brings us to today.


Today we’re proposing a new wording, in line with the previous approach: we use
the Apache 2.0 license with two exceptions, one to address binary attribution
issues and one to address concerns about GPL2 compatibility.  In addition, we
have striven to align the wording and legal terminology with those in the Apache
2.0 license.  For general rationale and framing for why these approaches are
important, I’ll refer you back to the first and second threads.  Here is our new
proposed wording:


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

---- end —


Despite the effort required to reach this point, this is only a small shift from
the second round proposal.  We believe that this will resolve the issue of LLVM
runtime libraries being used by proprietary and other non-LLVM compilers, and
the wording has been carefully vetted by a team of super-smart legal folks, led
by Heather (who represents the interests of the LLVM community).

We expect that we will need to have a name for this wording, and propose the
name "Apache 2.0 License with LLVM Exception” to align the naming with the
other exception clauses listed in the SPDX database
(https://spdx.org/licenses/exceptions-index.html).  Several other approaches to
naming were considered, but we believe that, in this case at least, the most
obvious answer is the best.

At this point, we’re fairly confident that this wording covers all of the known
bases.  That said, we welcome comments and questions on this thread, because
while we know that it is impossible to please everyone, we want to know if we’ve
missed the mark in a significant way.

If the LLVM community is generally on board with this approach, we’ll ask the
LLVM Foundation Board of Directors to approve this, and we can move on to the
logistical discussion of how to enact a new license structure: itself a
difficult act.

Thanks,

-Chris

Hi Chris,

On 17 Apr 2017, at 15:37, Chris Lattner via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> ---- 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.
> 
> ---- end —
> 
> 
> Despite the effort required to reach this point, this is only a small shift
from the second round proposal.  We believe that this will resolve the issue of
LLVM runtime libraries being used by proprietary and other non-LLVM compilers,
and the wording has been carefully vetted by a team of super-smart legal folks,
led by Heather (who represents the interests of the LLVM community).
> 
> We expect that we will need to have a name for this wording, and propose
the name "Apache 2.0 License with LLVM Exception” to align the naming with
the other exception clauses listed in the SPDX database
(https://spdx.org/licenses/exceptions-index.html).  Several other approaches to
naming were considered, but we believe that, in this case at least, the most
obvious answer is the best.
> 
> At this point, we’re fairly confident that this wording covers all of the
known bases.  That said, we welcome comments and questions on this thread,
because while we know that it is impossible to please everyone, we want to know
if we’ve missed the mark in a significant way.
It’s not clear to me that this covers the case of code (e.g. template
definitions) in libc++ headers being included in programs.  With this license,
if I compile a program that uses C++ standard library #includes on a platform
(e.g. macOS, FreeBSD) where libc++ is the default C++ standard library
implementation, am I required to add explicit LLVM attribution to binaries that
I distribute?  I’m happy with the platform that ships libc++ having to include
an attribution in its docs somewhere, but requiring the attribution for every
C++ program is very difficult to comply with.

David

On 04/18/2017 02:36 AM, David Chisnall via llvm-dev
wrote:
> Hi Chris,
>
> On 17 Apr 2017, at 15:37, Chris Lattner via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>> ---- 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.
>>
>> ---- end —
>>
>>
>> Despite the effort required to reach this point, this is only a small
shift from the second round proposal.  We believe that this will resolve the
issue of LLVM runtime libraries being used by proprietary and other non-LLVM
compilers, and the wording has been carefully vetted by a team of super-smart
legal folks, led by Heather (who represents the interests of the LLVM
community).
>>
>> We expect that we will need to have a name for this wording, and
propose the name "Apache 2.0 License with LLVM Exception” to align the
naming with the other exception clauses listed in the SPDX database
(https://spdx.org/licenses/exceptions-index.html).  Several other approaches to
naming were considered, but we believe that, in this case at least, the most
obvious answer is the best.
>>
>> At this point, we’re fairly confident that this wording covers all of
the known bases.  That said, we welcome comments and questions on this thread,
because while we know that it is impossible to please everyone, we want to know
if we’ve missed the mark in a significant way.
> It’s not clear to me that this covers the case of code (e.g. template
definitions) in libc++ headers being included in programs.  With this license,
if I compile a program that uses C++ standard library #includes on a platform
(e.g. macOS, FreeBSD) where libc++ is the default C++ standard library
implementation, am I required to add explicit LLVM attribution to binaries that
I distribute?  I’m happy with the platform that ships libc++ having to include
an attribution in its docs somewhere, but requiring the attribution for every
C++ program is very difficult to comply with.
The intent is not to require attribution for all users of libc++. Can 
you explain why you feel that it might not cover this case?

In case it helps, I'll point out that the Apache 2 license's definition 
of Object form is very general: ""Object" form shall mean any
form
resulting from mechanical transformation or translation of a Source 
form, including but not limited to..."

  -Hal
>
> David
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

Let me say first that I personally am awed and gratified by the
effort, patience and persistence of the people who have been
pursuing the licensing topic.  I have some idea what it's like.

One question came up internally, which I am passing back to the
interested parties.  While it is clear about the intent of the
clause to address compatibility with GPLv2, what is the state of
compatibility with respect to LGPLv2.1?

Thanks,
--paulr

-----Original Message-----
From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of Chris
Lattner via llvm-dev
Sent: Monday, April 17, 2017 7:37 AM
To: llvm-dev
Subject: [llvm-dev] RFC #3: Improving license & patent issues in the LLVM
community

Hello everyone,

This email is a continuation of a discussion started in October 2015, and
continued in September 2016:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html
http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html

As with those emails, this is a complicated topic and deals with sensitive legal
issues.  I am not a lawyer, and this email is not intended to be legal advice in
the formal sense.  That said, I have spoken with many lawyers about this,
Heather Meeker (a prominent and distinguished OSS licensing attorney) has agreed
to represent the interests of the LLVM Community as independent counsel.  This
proposal incorporates all of their feedback.


The goals of this effort are outlined in the first email but, in short, we aim
to:
- encourage ongoing contributions to LLVM by preserving low barrier to entry for
contributors.
- protect users of LLVM code by providing explicit patent protection in the
license.
- protect contributors to the LLVM project by explicitly scoping their patent
contributions with this license.
- eliminate the schism between runtime libraries and the rest of the compiler
that makes it difficult to move code between them.
- ensure that LLVM runtime libraries may be used by other open source and
proprietary compilers.

Here we are discussing what the best end game is -- not the logistics of how to
get from here to there.


In case you haven’t been following, here is an attempt at quick recap the
history, leading to today:

The first email thread addressed the issue of how to structure the new LLVM
license, what the problem to be solved is, and rationale for a general approach.
We decided and converged on using the approach of the industry standard Apache 2
License, with exceptions to correct problematic cases for the LLVM community
(specifically, the issue of runtime libraries that are implicitly linked into an
application by the compiler).  The concern there is that users of LLVM compilers
(e.g. Clang) would not necessarily know that runtime libraries are implicitly
linked into their application, and thus fail to attribute the LLVM project in
binaries.  The LLVM project generally isn’t widely concerned with binary
attribution, but widespread noncompliance with license terms can lead to
problems enforcing other terms in the license.

That first discussion recognized the binary attribution issue, but a second
concern was raised by some who believe the Apache 2 and GPL version 2.0 licenses
are incompatible.  The second email thread addressed that compatibility concern
by introducing a second exception clause.  In the second email thread, those
concerned about GPL2 were satisfied, but an additional issue was raised about
the first binary attribution clause: specifically, we aim for the LLVM runtime
libraries to be used very permissively, even by proprietary compilers and
linkers.  This led to another round of intense (offline) discussion about the
concrete wording of the exceptions, which brings us to today.


Today we’re proposing a new wording, in line with the previous approach: we use
the Apache 2.0 license with two exceptions, one to address binary attribution
issues and one to address concerns about GPL2 compatibility.  In addition, we
have striven to align the wording and legal terminology with those in the Apache
2.0 license.  For general rationale and framing for why these approaches are
important, I’ll refer you back to the first and second threads.  Here is our new
proposed wording:


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

---- end —


Despite the effort required to reach this point, this is only a small shift from
the second round proposal.  We believe that this will resolve the issue of LLVM
runtime libraries being used by proprietary and other non-LLVM compilers, and
the wording has been carefully vetted by a team of super-smart legal folks, led
by Heather (who represents the interests of the LLVM community).

We expect that we will need to have a name for this wording, and propose the
name "Apache 2.0 License with LLVM Exception” to align the naming with the
other exception clauses listed in the SPDX database
(https://spdx.org/licenses/exceptions-index.html).  Several other approaches to
naming were considered, but we believe that, in this case at least, the most
obvious answer is the best.

At this point, we’re fairly confident that this wording covers all of the known
bases.  That said, we welcome comments and questions on this thread, because
while we know that it is impossible to please everyone, we want to know if we’ve
missed the mark in a significant way.

If the LLVM community is generally on board with this approach, we’ll ask the
LLVM Foundation Board of Directors to approve this, and we can move on to the
logistical discussion of how to enact a new license structure: itself a
difficult act.

Thanks,

-Chris
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

LGPLv2.1 has no real compatibility issues with anything, because it allows
additional restrictions and license of choice (as long as they meet two
requirements that apache can meet).

--Dan

On Wed, Apr 19, 2017 at 3:44 PM, Robinson, Paul via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Let me say first that I personally am awed and gratified by the
> effort, patience and persistence of the people who have been
> pursuing the licensing topic.  I have some idea what it's like.
>
> One question came up internally, which I am passing back to the
> interested parties.  While it is clear about the intent of the
> clause to address compatibility with GPLv2, what is the state of
> compatibility with respect to LGPLv2.1?
>
> Thanks,
> --paulr
>
> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of
> Chris Lattner via llvm-dev
> Sent: Monday, April 17, 2017 7:37 AM
> To: llvm-dev
> Subject: [llvm-dev] RFC #3: Improving license & patent issues in the
LLVM
> community
>
> Hello everyone,
>
> This email is a continuation of a discussion started in October 2015, and
> continued in September 2016:
> http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html
> http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html
>
> As with those emails, this is a complicated topic and deals with sensitive
> legal issues.  I am not a lawyer, and this email is not intended to be
> legal advice in the formal sense.  That said, I have spoken with many
> lawyers about this, Heather Meeker (a prominent and distinguished OSS
> licensing attorney) has agreed to represent the interests of the LLVM
> Community as independent counsel.  This proposal incorporates all of their
> feedback.
>
>
> The goals of this effort are outlined in the first email but, in short, we
> aim to:
> - encourage ongoing contributions to LLVM by preserving low barrier to
> entry for contributors.
> - protect users of LLVM code by providing explicit patent protection in
> the license.
> - protect contributors to the LLVM project by explicitly scoping their
> patent contributions with this license.
> - eliminate the schism between runtime libraries and the rest of the
> compiler that makes it difficult to move code between them.
> - ensure that LLVM runtime libraries may be used by other open source and
> proprietary compilers.
>
> Here we are discussing what the best end game is -- not the logistics of
> how to get from here to there.
>
>
> In case you haven’t been following, here is an attempt at quick recap the
> history, leading to today:
>
> The first email thread addressed the issue of how to structure the new
> LLVM license, what the problem to be solved is, and rationale for a general
> approach.  We decided and converged on using the approach of the industry
> standard Apache 2 License, with exceptions to correct problematic cases for
> the LLVM community (specifically, the issue of runtime libraries that are
> implicitly linked into an application by the compiler).  The concern there
> is that users of LLVM compilers (e.g. Clang) would not necessarily know
> that runtime libraries are implicitly linked into their application, and
> thus fail to attribute the LLVM project in binaries.  The LLVM project
> generally isn’t widely concerned with binary attribution, but widespread
> noncompliance with license terms can lead to problems enforcing other terms
> in the license.
>
> That first discussion recognized the binary attribution issue, but a
> second concern was raised by some who believe the Apache 2 and GPL version
> 2.0 licenses are incompatible.  The second email thread addressed that
> compatibility concern by introducing a second exception clause.  In the
> second email thread, those concerned about GPL2 were satisfied, but an
> additional issue was raised about the first binary attribution clause:
> specifically, we aim for the LLVM runtime libraries to be used very
> permissively, even by proprietary compilers and linkers.  This led to
> another round of intense (offline) discussion about the concrete wording of
> the exceptions, which brings us to today.
>
>
> Today we’re proposing a new wording, in line with the previous approach:
> we use the Apache 2.0 license with two exceptions, one to address binary
> attribution issues and one to address concerns about GPL2 compatibility.
> In addition, we have striven to align the wording and legal terminology
> with those in the Apache 2.0 license.  For general rationale and framing
> for why these approaches are important, I’ll refer you back to the first
> and second threads.  Here is our new proposed wording:
>
>
> ---- 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.
>
> ---- end —
>
>
> Despite the effort required to reach this point, this is only a small
> shift from the second round proposal.  We believe that this will resolve
> the issue of LLVM runtime libraries being used by proprietary and other
> non-LLVM compilers, and the wording has been carefully vetted by a team of
> super-smart legal folks, led by Heather (who represents the interests of
> the LLVM community).
>
> We expect that we will need to have a name for this wording, and propose
> the name "Apache 2.0 License with LLVM Exception” to align the naming
with
> the other exception clauses listed in the SPDX database (
> https://spdx.org/licenses/exceptions-index.html).  Several other
> approaches to naming were considered, but we believe that, in this case at
> least, the most obvious answer is the best.
>
> At this point, we’re fairly confident that this wording covers all of the
> known bases.  That said, we welcome comments and questions on this thread,
> because while we know that it is impossible to please everyone, we want to
> know if we’ve missed the mark in a significant way.
>
> If the LLVM community is generally on board with this approach, we’ll ask
> the LLVM Foundation Board of Directors to approve this, and we can move on
> to the logistical discussion of how to enact a new license structure:
> itself a difficult act.
>
> Thanks,
>
> -Chris
> _______________________________________________
> 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/20170419/bfe34006/attachment-0001.html>

> Date: Mon, 17 Apr 2017 07:37:17 -0700
> From: Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org>
Chris and others,

As stated before the APL 2.0 poses a serious problem for OpenBSD as it
contradicts the poject goals of providing a freely distributable base
operating system that includes all the tools to build from source.
What changed since the last time the license change came up is that
OpenBSD now uses clang as the system compiler and lld as the system
compiler to support OpenBSD/arm64, and that we're actively working on
using it on other hardware platforms supported by OpenBSD as well.
OpenBSD developers (myself included) are becoming more involved with
LLVM development as a result.

Triggered by recent discussions related to the proposed OpenSSL
license change our position on the Apache license has been clarified
on the porject goals web page http://www.openbsd.org/policy.html:

  Apache

    The original Apache license was similar to the Berkeley license,
  but source code published under version 2 of the Apache license is
  subject to additional restrictions and cannot be included into
  OpenBSD. In particular, if you use code under the Apache 2 license,
  some of your rights will terminate if you claim in court that the
  code violates a patent.

    A license can only be considered fully permissive if it allows use
  by anyone for all the future without giving up any of their
  rights. If there are conditions that might terminate any rights in
  the future, or if you have to give up a right that you would
  otherwise have, even if exercising that right could reasonably be
  regarded as morally objectionable, the code is not free.

    In addition, the clause about the patent license is problematic
  because a patent license cannot be granted under Copyright law, but
  only under contract law, which drags the whole license into the
  domain of contract law. But while Copyright law is somewhat
  standardized by international agreements, contract law differs
  wildly among jurisdictions. So what the license means in different
  jurisdictions may vary and is hard to predict.

Sadly the changes made over the last few months do not address these
concerns.  Especially the "patent termination clause" has not been
removed even though I don't see how that clause is essential to
achieve the goals of the proposed license change.

I also wonder if the international context has been taken into
account.  As the recent European LLVM Developers Meeting shows, LLVM
is a very international project so I think this deserves a more
international approach, especially because US copyright is so
hopelessly interlocked in contract law.

Mark

2017-04-23 12:50 GMT-03:00 Mark Kettenis via llvm-dev <
llvm-dev at lists.llvm.org>:
> In particular, if you use code under the Apache 2 license,
>   some of your rights will terminate if you claim in court that the
>   code violates a patent.
>
I'm really ignorant of the legal nuances but this is my question:

Isn't it irrelevant what the licence says in this case? The limitation of
rights happens anyways, because patent law trumps copyright law, no ?

I am making an honest question, not intended to sparkle a flame war or to
be trollish. With that said I will recognize here
that i do not agree with with the openBSD or even the the GPLv3 folks.

Also could you suggest what kind of alteration would make you guys happy
and still provide for patent protection for individuals and corporations?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170423/10b35915/attachment.html>

On Sun, Apr 23, 2017 at 8:50 AM, Mark Kettenis via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> > Date: Mon, 17 Apr 2017 07:37:17 -0700
> > From: Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org>
>
> Chris and others,
>
> As stated before the APL 2.0 poses a serious problem for OpenBSD as it
> contradicts the poject goals of providing a freely distributable base
> operating system that includes all the tools to build from source.
> What changed since the last time the license change came up is that
> OpenBSD now uses clang as the system compiler and lld as the system
> compiler to support OpenBSD/arm64, and that we're actively working on
> using it on other hardware platforms supported by OpenBSD as well.
> OpenBSD developers (myself included) are becoming more involved with
> LLVM development as a result.
>
>
So let me ask:
What do you expect to happen here?
Your goals seem irreconcilable with the other goals here.

"I also wonder if the international context has been taken into
account."
It definitely was.
Do you have a specific concern here?

"n particular, if you use code under the Apache 2 license,
  some of your rights will terminate if you claim in court that the
  code violates a patent."

This is true but deliberate.
While you may think otherwise, maintaining patent peace between
otherwise-competing contributors is actually quite important to the health
of projects like LLVM.



"In addition, the clause about the patent license is problematic
  because a patent license cannot be granted under Copyright law, but
  only under contract law. which drags the whole license into the
  domain of contract law. But while Copyright law is somewhat
  standardized by international agreements, contract law differs
  wildly among jurisdictions. So what the license means in different
  jurisdictions may vary and is hard to predict."

FWIW: This is pretty much FUD. I think you should leave it out of this
discussion.
I hope this was not written by an IP lawyer, because, it's actually just
flat out wrong.

But here's a detailed analysis, FWIW:
"granted under Copyright law, but only under contract law."

Errr, no, both are IP law, but IP law is already a subset of contract law
for the most part.
There is no framing under which patent law is not exactly as special as you
think copyright law is.
(IE there are exactly as special as each other).

"which drags the whole license into the domain of contract law. "
This is just a muddle.

Granting *licenses* is always contract law, for both copyright, and
patents, in every jurisdiction (maybe you can find one where it's not, but
i'll just go with "every" for now).
It just happens the remedies may be different, and there may be specific
requirements for the contracts.
That does not make it any less contract law.

I believe whoever wrote this is confused because people refer to breach of
contract and copyright infringement as different things.
the same, fwiw, is true of patent infringement (see above).
This is all true, but would be irrelevant.  It just means there is a
separate statute you can sue under, outside of normal contract law.
Again, true for both copyrights and patents.
It's still a contract. Just one with more remedies.

But there is no difference between a "license" and a
"contract".

IE any grant of rights i give you as a "license" is really a
"contract".

Again, in just about every jurisdiction i can choose to sue you either for
breach of contract or copyright infringement or patent infringement, or all
of them.

People usually don't because the contract damages would be hard to quantify.

" So what the license means in different
  jurisdictions may vary and is hard to predict."

Apache was vetted quite heavily by a large number of international lawyers
prior to release, much like GPLv3.
So this falls into the "cast random aspersions on license with no concrete
concern".
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170423/331140af/attachment.html>

Sorry for the delay, I was on vacations.

Ed, what is the FreeBSD position about the apache version 2 in base? A
quick search only shows it in contrib/ and crypto/openssl.

If I understand the issue, we can achieve the desired results with a
license change that handles patents or by keeping a minimal license
for runtime and llvm, but requiring a contributor agreement in the
project before we accept changes. Am I correct?

Not requiring a contributor agreement is awesome. It makes it really
easy for people to join the project or send one time fixes. It also
saves committers from having to check some database before committing
a patch by someone else.

On the other hand, at least for me, one of the main motivations for
wanting to contribute to llvm projects is how widely used they are. I
understand that an effort was made for gpl2 compatibility, but that is
a bit of innovation that we were trying to avoid. More importantly, it
is hard to say that is the only issue one will ever find.

Also, at least the OpenBSD project is reluctant to use the Apache2
license. From where I stand it doesn't really matter if their concerns
with the license are unfounded: until they are convinced otherwise the
change is undesirable from the perspective of making llvm used as much
as possible.

Given the situation I would prefer to penalize the development process
a bit and have a contributor agreement instead of the license change.

Cheers,
Rafael

On 17 April 2017 at 10:37, Chris Lattner via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hello everyone,
>
> This email is a continuation of a discussion started in October 2015, and
continued in September 2016:
> http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html
> http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html
>
> As with those emails, this is a complicated topic and deals with sensitive
legal issues.  I am not a lawyer, and this email is not intended to be legal
advice in the formal sense.  That said, I have spoken with many lawyers about
this, Heather Meeker (a prominent and distinguished OSS licensing attorney) has
agreed to represent the interests of the LLVM Community as independent counsel. 
This proposal incorporates all of their feedback.
>
>
> The goals of this effort are outlined in the first email but, in short, we
aim to:
> - encourage ongoing contributions to LLVM by preserving low barrier to
entry for contributors.
> - protect users of LLVM code by providing explicit patent protection in the
license.
> - protect contributors to the LLVM project by explicitly scoping their
patent contributions with this license.
> - eliminate the schism between runtime libraries and the rest of the
compiler that makes it difficult to move code between them.
> - ensure that LLVM runtime libraries may be used by other open source and
proprietary compilers.
>
> Here we are discussing what the best end game is -- not the logistics of
how to get from here to there.
>
>
> In case you haven’t been following, here is an attempt at quick recap the
history, leading to today:
>
> The first email thread addressed the issue of how to structure the new LLVM
license, what the problem to be solved is, and rationale for a general approach.
We decided and converged on using the approach of the industry standard Apache 2
License, with exceptions to correct problematic cases for the LLVM community
(specifically, the issue of runtime libraries that are implicitly linked into an
application by the compiler).  The concern there is that users of LLVM compilers
(e.g. Clang) would not necessarily know that runtime libraries are implicitly
linked into their application, and thus fail to attribute the LLVM project in
binaries.  The LLVM project generally isn’t widely concerned with binary
attribution, but widespread noncompliance with license terms can lead to
problems enforcing other terms in the license.
>
> That first discussion recognized the binary attribution issue, but a second
concern was raised by some who believe the Apache 2 and GPL version 2.0 licenses
are incompatible.  The second email thread addressed that compatibility concern
by introducing a second exception clause.  In the second email thread, those
concerned about GPL2 were satisfied, but an additional issue was raised about
the first binary attribution clause: specifically, we aim for the LLVM runtime
libraries to be used very permissively, even by proprietary compilers and
linkers.  This led to another round of intense (offline) discussion about the
concrete wording of the exceptions, which brings us to today.
>
>
> Today we’re proposing a new wording, in line with the previous approach: we
use the Apache 2.0 license with two exceptions, one to address binary
attribution issues and one to address concerns about GPL2 compatibility.  In
addition, we have striven to align the wording and legal terminology with those
in the Apache 2.0 license.  For general rationale and framing for why these
approaches are important, I’ll refer you back to the first and second threads. 
Here is our new proposed wording:
>
>
> ---- 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.
>
> ---- end —
>
>
> Despite the effort required to reach this point, this is only a small shift
from the second round proposal.  We believe that this will resolve the issue of
LLVM runtime libraries being used by proprietary and other non-LLVM compilers,
and the wording has been carefully vetted by a team of super-smart legal folks,
led by Heather (who represents the interests of the LLVM community).
>
> We expect that we will need to have a name for this wording, and propose
the name "Apache 2.0 License with LLVM Exception” to align the naming with
the other exception clauses listed in the SPDX database
(https://spdx.org/licenses/exceptions-index.html).  Several other approaches to
naming were considered, but we believe that, in this case at least, the most
obvious answer is the best.
>
> At this point, we’re fairly confident that this wording covers all of the
known bases.  That said, we welcome comments and questions on this thread,
because while we know that it is impossible to please everyone, we want to know
if we’ve missed the mark in a significant way.
>
> If the LLVM community is generally on board with this approach, we’ll ask
the LLVM Foundation Board of Directors to approve this, and we can move on to
the logistical discussion of how to enact a new license structure: itself a
difficult act.
>
> Thanks,
>
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

Hi Rafael,

I believe that all of these points are covered in the first round of discussion,
including the FreeBSD team’s position.

-Chris
> On Apr 27, 2017, at 2:43 PM, Rafael Espíndola via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Sorry for the delay, I was on vacations.
> 
> Ed, what is the FreeBSD position about the apache version 2 in base? A
> quick search only shows it in contrib/ and crypto/openssl.
> 
> If I understand the issue, we can achieve the desired results with a
> license change that handles patents or by keeping a minimal license
> for runtime and llvm, but requiring a contributor agreement in the
> project before we accept changes. Am I correct?
> 
> Not requiring a contributor agreement is awesome. It makes it really
> easy for people to join the project or send one time fixes. It also
> saves committers from having to check some database before committing
> a patch by someone else.
> 
> On the other hand, at least for me, one of the main motivations for
> wanting to contribute to llvm projects is how widely used they are. I
> understand that an effort was made for gpl2 compatibility, but that is
> a bit of innovation that we were trying to avoid. More importantly, it
> is hard to say that is the only issue one will ever find.
> 
> Also, at least the OpenBSD project is reluctant to use the Apache2
> license. From where I stand it doesn't really matter if their concerns
> with the license are unfounded: until they are convinced otherwise the
> change is undesirable from the perspective of making llvm used as much
> as possible.
> 
> Given the situation I would prefer to penalize the development process
> a bit and have a contributor agreement instead of the license change.
> 
> Cheers,
> Rafael
> 
> On 17 April 2017 at 10:37, Chris Lattner via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Hello everyone,
>> 
>> This email is a continuation of a discussion started in October 2015,
and continued in September 2016:
>> http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html
>> http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html
>> 
>> As with those emails, this is a complicated topic and deals with
sensitive legal issues.  I am not a lawyer, and this email is not intended to be
legal advice in the formal sense.  That said, I have spoken with many lawyers
about this, Heather Meeker (a prominent and distinguished OSS licensing
attorney) has agreed to represent the interests of the LLVM Community as
independent counsel.  This proposal incorporates all of their feedback.
>> 
>> 
>> The goals of this effort are outlined in the first email but, in short,
we aim to:
>> - encourage ongoing contributions to LLVM by preserving low barrier to
entry for contributors.
>> - protect users of LLVM code by providing explicit patent protection in
the license.
>> - protect contributors to the LLVM project by explicitly scoping their
patent contributions with this license.
>> - eliminate the schism between runtime libraries and the rest of the
compiler that makes it difficult to move code between them.
>> - ensure that LLVM runtime libraries may be used by other open source
and proprietary compilers.
>> 
>> Here we are discussing what the best end game is -- not the logistics
of how to get from here to there.
>> 
>> 
>> In case you haven’t been following, here is an attempt at quick recap
the history, leading to today:
>> 
>> The first email thread addressed the issue of how to structure the new
LLVM license, what the problem to be solved is, and rationale for a general
approach.  We decided and converged on using the approach of the industry
standard Apache 2 License, with exceptions to correct problematic cases for the
LLVM community (specifically, the issue of runtime libraries that are implicitly
linked into an application by the compiler).  The concern there is that users of
LLVM compilers (e.g. Clang) would not necessarily know that runtime libraries
are implicitly linked into their application, and thus fail to attribute the
LLVM project in binaries.  The LLVM project generally isn’t widely concerned
with binary attribution, but widespread noncompliance with license terms can
lead to problems enforcing other terms in the license.
>> 
>> That first discussion recognized the binary attribution issue, but a
second concern was raised by some who believe the Apache 2 and GPL version 2.0
licenses are incompatible.  The second email thread addressed that compatibility
concern by introducing a second exception clause.  In the second email thread,
those concerned about GPL2 were satisfied, but an additional issue was raised
about the first binary attribution clause: specifically, we aim for the LLVM
runtime libraries to be used very permissively, even by proprietary compilers
and linkers.  This led to another round of intense (offline) discussion about
the concrete wording of the exceptions, which brings us to today.
>> 
>> 
>> Today we’re proposing a new wording, in line with the previous
approach: we use the Apache 2.0 license with two exceptions, one to address
binary attribution issues and one to address concerns about GPL2 compatibility. 
In addition, we have striven to align the wording and legal terminology with
those in the Apache 2.0 license.  For general rationale and framing for why
these approaches are important, I’ll refer you back to the first and second
threads.  Here is our new proposed wording:
>> 
>> 
>> ---- 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.
>> 
>> ---- end —
>> 
>> 
>> Despite the effort required to reach this point, this is only a small
shift from the second round proposal.  We believe that this will resolve the
issue of LLVM runtime libraries being used by proprietary and other non-LLVM
compilers, and the wording has been carefully vetted by a team of super-smart
legal folks, led by Heather (who represents the interests of the LLVM
community).
>> 
>> We expect that we will need to have a name for this wording, and
propose the name "Apache 2.0 License with LLVM Exception” to align the
naming with the other exception clauses listed in the SPDX database
(https://spdx.org/licenses/exceptions-index.html).  Several other approaches to
naming were considered, but we believe that, in this case at least, the most
obvious answer is the best.
>> 
>> At this point, we’re fairly confident that this wording covers all of
the known bases.  That said, we welcome comments and questions on this thread,
because while we know that it is impossible to please everyone, we want to know
if we’ve missed the mark in a significant way.
>> 
>> If the LLVM community is generally on board with this approach, we’ll
ask the LLVM Foundation Board of Directors to approve this, and we can move on
to the logistical discussion of how to enact a new license structure: itself a
difficult act.
>> 
>> Thanks,
>> 
>> -Chris
>> _______________________________________________
>> 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

On 27 Apr 2017, at 22:43, Rafael Espíndola via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> Sorry for the delay, I was on vacations.
> 
> Ed, what is the FreeBSD position about the apache version 2 in base? A
> quick search only shows it in contrib/ and crypto/openssl.
It’s not something that we’re enthusiastic about, but something that we
tolerate.  I don’t have personal objections to it (and at work we use an Apache
2-derived license for a lot of stuff we release), but a few other FreeBSD
contributors have told me that it will decrease their interest in working on
LLVM.
> If I understand the issue, we can achieve the desired results with a
> license change that handles patents or by keeping a minimal license
> for runtime and llvm, but requiring a contributor agreement in the
> project before we accept changes. Am I correct?
(IANAL) I believe that the separate copyright and patent license makes it hard
for one to revoke the other, so a company that starts suing others for
infringing their patents would lose their patent license, but not their
copyright license for LLVM and so would be free distribute LLVM while they sue
non-patent-owning LLVM distributors without fear of a countersuit (until they
annoy a company that does hold LLVM patents).
> Not requiring a contributor agreement is awesome. It makes it really
> easy for people to join the project or send one time fixes. It also
> saves committers from having to check some database before committing
> a patch by someone else.
Note that other projects have handled this quite easily.  Microsoft, for
example, makes it easy to associate a GitHub identity with a CLA signatory and
has a bot that tags all pull requests with either ‘CLA required’ or ‘CLA
completed’, so committers know not to merge pull requests that don’t have the
correct tag.

I believe that the difficulties were more on the other side - getting certain
companies to agree to sign a CLA (it’s unidirectional: they agree not to sue,
but distributors that don’t contribute don’t agree not to sue them, whereas the
proposed license means that if you sue over a patent infringed by LLVM then you
are blocked from distributing LLVM - not that I expect this to make a difference
as long as it’s easy for NPEs to sue for patent infringement, as it’s easy to
sell a patent to a new NPE in exchange for a perpetual license and 95% of the
proceeds from any other licenses.  The NPE then sues everyone, but doesn’t
distribute LLVM).

David