RFC #3: Improving license & patent issues in the LLVM community

Project Infrastructure LLVM Dev List Archives
1

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 (License Exceptions | Software Package Data Exchange (SPDX)). 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

2

Hi Chris,

3

Hi Chris,

---- 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 (License Exceptions | Software Package Data Exchange (SPDX)). 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

4

Thanks, I think that covers everything that I was interested in, though presumably it also means that there are no binary attribution requirements if I use the LLVM libraries and use a system-provided libLLVM.so (or similar), only if I distribute my own copy of the LLVM libraries?

I note that the Apache license does not include a definition of ‘compiling’. As a non-lawyer, I would take this to not include linking, though with LTO the boundary is fairly blurry. If ‘compiling’ includes the linking step, then presumably I’m free to ignore 4a, 4b, and 4d for anything. If 'compiling' doesn’t include linking, then how does this relate to bits of compiler-rt that might end up statically linked into the binary (or bits of libc++ if I statically link on a platform where libc++ is the default C++ standard library)?

My chief concern is that if I do (for any foo.cc):

$ c++ -static foo.cc

Then the resulting a.out should not come with any attribution requirements (for compiler-rt or libc++). If it does, then we are going to end up with a large number of accidental license violations.

David

5

Right. The intention is that that does not require attribution due to the exception.

-Chris

6

In that case, this looks good to me. In addition to the license, please can we put together an FAQ explicitly discussing these cases and indicating what we believe the license requires of people?

David

7

Umm.. How is Apple or another large company currently handling this if
the current situation is unacceptable? Doesn't Apple ship libc++ by
default? Is it telling them to give attribution in every program
somewhere?

8

I don’t see anyone saying that the current situation is unacceptable. We have special rules around runtime libraries right now to try and address these issues, and we’re discussing how they might be addressed with a single license going forward (with the advantages listed in Chris’s email).

I also think questions about how specific companies are handling specific products’ license compliance requirements (including any part of LLVM’s requirements) should be directed to the company so that whatever lawyers represent that company can respond with accurate details. That seems much more like a discussion about a company and a product than an interesting discussion about the right path forward for LLVM’s license.

9

Umm.. How is Apple or another large company currently handling this if
the current situation is unacceptable? Doesn't Apple ship libc++ by
default? Is it telling them to give attribution in every program
somewhere?

I cannot speak for any company, and IANAL, but the big problem that I see in the current situation is that we can’t freely move code between LLVM and the runtime libraries, and we can’t share code between LLVM and the runtime libraries, because we address the runtime exception by having a different license for the runtimes than what LLVM and Clang are licensed under.

Moving to this modified Apache 2 license for all our projects seems like a clear win to me.

-Chris

10

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

11

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

12

Yes. In the “rolling this out” stage of the proposal, we’ll have a concrete patch to apply to the developer policy which will include the FAQ content.

-Chris

13

Date: Mon, 17 Apr 2017 07:37:17 -0700
From: Chris Lattner via llvm-dev <llvm-dev@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

14

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?

15

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

16

Can't make everyone happy all the time.

I wish people with extreme views would be more moderate, but it isn't
to say they are wrong. Please just don't try to punish or subject your
views onto everyone else.

17

2017-04-23 12:50 GMT-03:00 Mark Kettenis via llvm-dev <
llvm-dev@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?

No.

The limitation of rights happens anyways, because patent law trumps
copyright law, no ?

No.

But note, the license only terminates patent rights, not copyright ones.
So to the degree there were no patents involved, it has terminated nothing.

18

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

And BTW, the claim it makes about apache is even more true of the license
OpenBSD uses:

1. It had no international lawyers review it at the time.
2. It relies on implied licenses for patents, and you can't get a group of
lawyers in any single jurisdiction to agree that such a thing exists in
most cases, let alone what the scope would be.

This is because it's completely judicially defined, so it's literally not
even written down anywhere, let alone similar between jurisdictions.

3. The only way you ever get out of "So what the license means in
different jurisdictions
may vary and is hard to predict." is to define what you mean, not say
less. So this is even *more* true of things like BSD.

19

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

20

Hi Rafael,

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

-Chris