
LLVM Relicensing Effort - frutiger
http://llvm.org/foundation/relicensing/
======
agnokapathetic
For those out of the loop like me, the Apache 2.0 license exceptions they are
addding are:

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

~~~
avar
Doesn't this just allow an end-run around the license by allowing you to
distribute a program that embeds LLVM, whose only purpose is to be an LLVM
wrapper to avoid those sections of the license?

~~~
jsmith45
I'm pretty sure the intention is that it does not allow that. Notice that they
say "as a result of your compiling your source code".

That is intended to mean that if the compiler copies in some binary code (to
implement a compiler primitive or the like), that it doing so does not require
you to treat that code like it is licensed under the LLVM terms.

Note that the LLVM source code is not "your source code", so simply copying in
the LLVM source and compiling it will not trigger this exception.

That is not to say that there might not be a loophole. E.G., modifying LLVM to
always copy all of its binary code into the resulting exececutable (and
licensing those changes under this license), and then compiling a program that
wants to embed LLVM. I'd like to think that courts would refuse to allow such
abuse, but who really knows.

~~~
Joky
It's blurry to me what it mean for including a libc++ header though? This is
not "your source code" but LLVM inline code. How is it different from
including a header from LLVM itself?

~~~
chandlerc1024
The intent is definitely to handle this as well. (Not really going to try and
dig into legal reasoning here.)

------
notaplumber
Mark Kettenis' formal objection on behalf of the OpenBSD project:
[http://lists.llvm.org/pipermail/llvm-
dev/2017-April/112300.h...](http://lists.llvm.org/pipermail/llvm-
dev/2017-April/112300.html)

Theo de Raadt:
[https://news.ycombinator.com/item?id=12617881](https://news.ycombinator.com/item?id=12617881)

These objections have been largely glossed over by the LLVM community. It's no
secret that a handful of corporations are pushing for this change, and not the
best interest of the open source community. Especially the larger ones using
LLVM, like *BSD. LLVM is already under a permissive BSD-like license (NCSA),
as pointed out by jwilk:
[https://news.ycombinator.com/item?id=18700258](https://news.ycombinator.com/item?id=18700258)

OpenSSL is similarly attempting the same thing with newer versions of OpenSSL,
which they went about in a particularly legally dubious way:
[https://lwn.net/Articles/717996/](https://lwn.net/Articles/717996/) (For
context, OpenBSD maintains LibreSSL).

~~~
DannyBee
" It's no secret that a handful of corporations are pushing for this change"

This is not actually true, and needs citation/data.

This is actually the foundation trying to keep peace, and in a good way.

"and not the best interest of the open source community"

And this is an unsourced assumption of bad faith.

It's also demonstrably false.

~~~
notaplumber
[http://lists.llvm.org/pipermail/llvm-
dev/2015-October/091536...](http://lists.llvm.org/pipermail/llvm-
dev/2015-October/091536.html)

It's stated as much in the initial proposal.

"1) Some contributors are actively blocked from contributing code to LLVM."

> These contributors have been holding back patches for quite some time that
> they’d like to upstream. Corporate contributors (in particular) often have
> patents on many different things, and while it is reasonable for them to
> grant access to patents related to LLVM, the wording in the Developer Policy
> can be interpreted to imply that unrelated parts of their IP could
> accidentally be granted to LLVM (through “scope creep”).

~~~
DannyBee
This is not even remotely the same as "a handful of corporations" _or_ "not in
the best interest of the open source community".

Also, you elided the other 2 large reasons given, which don't support your
point at all.

For example, GCC has an exception for its runtime libraries that it now
applies universally for the exact same reasons - desire to share code, etc.

It has that problem even reusing code from other GNU projects as well!

~~~
notaplumber
> This is a complicated topic that deals with legal issues and our primary
> goal is to unblock contributions from specific corporate contributors.

You were saying?

~~~
chandlerc1024
The interesting thing is that the vast majority (and for the first year+ all)
of the contributors to LLVM who donated massive amounts of time and resources
to make the relicensing happen were _not_ from any company that was blocked
from contributing.

I happen to know because I was one person who donated my time. I was not in
any way blocked. We were trying to find a way to help _more_ people (and yes,
companies, because companies tend to pay people) contribute to LLVM because
that is one of the things that makes the project stronger.

So saying that the change was _driven_ by these handful of contributors seems
really off base. And in fact, my experience during the process was that the
most motivated people were individual contributors, if anything pushing and
pulling companies along (by finding good ways to address their potential
concerns with any change like this).

Anyways, that was my experience from being involved in the process. YMMV of
course.

~~~
notaplumber
That doesn't change the reasons stated in the proposal email. Even if the
final legwork was orchestrated by individual contributors, it's clear that the
reasons were to appease corporations and not the community at large.

It would be unlikely for any open source project to begin such a massive
undertaking to re-license, from an already permissive license, without at
least some corporate incentive/initiative to do so. No doubt lawyers were
paid.

I understand what you're saying, but it is also being disingenuous.

~~~
DannyBee
"That doesn't change the reasons stated in the proposal email. Even if the
final legwork was orchestrated by individual contributors, it's clear that the
reasons were to appease corporations and not the community at large."

Except it's not, since the community was the one who desired those
contributions in the first place.

Seriously. You are going off making a lot of assertions without knowledge,
evidence, or data.

Truthfully, if this is how the community you belong to operates, i'm somewhat
glad they will no longer use LLVM.

------
jwilk
This page is missing one crucial piece of information: what's the current
license?

It's (a BSD-like) University of Illinois/NCSA Open Source License:

[https://releases.llvm.org/7.0.0/LICENSE.TXT](https://releases.llvm.org/7.0.0/LICENSE.TXT)

~~~
djsumdog
huh. I assumed it was already Apache 2 and they were adding an exemption. This
does change the reading quite a bit. They're asking all their contributors for
a pretty big relicensing.

~~~
riffraff
but it's a relicensing which is fairly close in spirit, isn't it?

Sure, apache 2 has the patent stuff, but I fail to see how anyone would object
to it.

~~~
beefhash
> how anyone would object to it

OpenBSD is objecting to it like so[1]:

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

[1] [https://www.openbsd.org/policy.html](https://www.openbsd.org/policy.html)

~~~
chandlerc1024
True.

FWIW, this is really the only strong objection we've heard to the overall
direction of this change.

~~~
notaplumber
And considering all the interesting work that OpenBSD is doing to Clang, i.e:
retguard [0] [1], ROP gadget reduction framework [2]. Ignoring the fact that
two major open source *BSD operating systems use and ship LLVM/Clang as their
default system compiler. Their entire system compiled with clang, LLD as the
default linker for an increasing number of supported platforms. A ports tree
with between 10,000 (OpenBSD) to 30,000 (FreeBSD) ports compiled with Clang,
maintaining patches upstreams won't take..

.. You might think that objection would be listened to more readily, or do the
interest of a handful of corporations hold greater weight?

OpenBSD will undoubtedly be forced to fork LLVM 8, and likely have to take on
the burden of asking individual developers to dual-license contributions they
backport going forward. This will place them in a similar position they had
with GCC, since the GPLv3 license change.

[0]
[https://github.com/openbsd/src/commit/e688c2b0648a80551cf735...](https://github.com/openbsd/src/commit/e688c2b0648a80551cf7353d9f455c7cbb98f13c)

[1]
[https://github.com/openbsd/src/commit/9866f44de26a847eaed067...](https://github.com/openbsd/src/commit/9866f44de26a847eaed067d23d8660b7dca51614)

[2]
[https://github.com/openbsd/src/commit/c0f0c565f0b312e55b410b...](https://github.com/openbsd/src/commit/c0f0c565f0b312e55b410ba69f4b621a01ef54cb)

Mark Kettenis formal rejection on behalf of the OpenBSD project:
[http://lists.llvm.org/pipermail/llvm-
dev/2017-April/112300.h...](http://lists.llvm.org/pipermail/llvm-
dev/2017-April/112300.html)

~~~
chandlerc1024
FreeBSD is OK with the license, so AFAIK, it is just OpenBSD.

We did listen, but we have specific goals that after a great deal of
discussion are best addressed with the approach of the Apache 2 license. The
objection was to those _goals_ in many ways, not to the particular mechanisms.

And we really did listen to the concerns about the goals (specifically
providing strong protection against patent issues) but there was strong
consensus in the community that this was a real problem we wanted to address,
and so we moved forward.

I am truly sad that this will cause issues w/ the OpenBSD community, but we
had consensus and needed to make progress.

~~~
apotheon
I think I know what you mean when you say "consensus" here, but that's not
what "consensus" really means. Perhaps you want a word more like "majority".

------
segfaultbuserr
Although Apache-2 is sometimes seen as a license-of-choice by major
proprietary software companies like Google, the license itself is actually
well-written. It explicitly offers a patent clause to protect contributors and
distributors from patent lawsuits from the copyright holder. I found even RMS
recommends using Apache-2 as a permissive license for minor programs that
don't need copyleft. So unless you explicitly support BSD/ISC, perhaps you
could give some consideration of using it as a license for your next program.

AFAIK, whether ISC/BSD/MIT style licenses offer a patent clause is still
unsettled.

 _UPDATE: See JoshTriplett 's post, Apache-2 has license compatibility issues
that prevent some code reuse, now I think BSDplusPatent license instead of
Apache-2 is a better idea for small programs._

~~~
JoshTriplett
Apache 2.0 is not a great choice if you care about license compatibility,
unless you include an exception as LLVM is doing here.

Another good choice is
[https://opensource.org/licenses/BSDplusPatent](https://opensource.org/licenses/BSDplusPatent)
, which combines the 2-clause BSD license with the explicit patent clause from
Apache 2.0. That gives you GPLv2-compatibility as well.

(Note that this is unrelated to the unfortunately similarly named license from
Facebook, which is not a FOSS license.)

~~~
the_why_of_y
IMHO the license incompatibilty problem is rather minor:

Firstly, AFAIK all of the licenses that ALv2 is incompatible with are obsolete
and superseded versions.

Secondly, the ALv2 is file-scoped, so you can typically combine a library
licensed ALv2 and another one with an incompatible permissive or weak copyleft
license.

In practice this means that you'll have a problem combining ALv2 with old
versions of strong copyleft licenses, e.g., something licensed GPLv2- _only_.

This is certainly an issue to consider for a project like LLVM, but of lesser
importance for the majority of smaller scoped libraries.

~~~
JoshTriplett
GPLv2 comes up reasonably often.

------
evmar
TypeScript has a similar problem, where depending on some compilation flags
you end up inheriting their license on your compiled output. I've been trying
to get them to fix it but it is stuck in lawyer limbo:

[https://github.com/Microsoft/tslib/issues/47](https://github.com/Microsoft/tslib/issues/47)

~~~
chandlerc1024
If you can reuse the legal mechanics of the new LLVM license, maybe that
helps? We spent a ____LOT __ __of lawyer time trying to get this right.

~~~
raphlinus
I just want to say, it's slightly mind-boggling to see two Googlers on a
thread talking about how to adapt legal work done for a mostly Apple-owned
project to improve the licensing of a Microsoft product.

~~~
chandlerc1024
I wouldn't call LLVM "mostly Apple owned" at this point. It has a huge range
of contributions from Apple, Google, and many others. Even Microsoft! =]

~~~
raphlinus
Fair point, though it certainly was try at one point. In any case, doesn't
detract from the point I was trying to make.

------
hannob
This looks mostly harmless, yet this made me pause: "The effort has been
overseen by Heather Meeker".

The same Heather Meeker that started the whole "let's relicense FOSS projects
with confusing non-FOSS licenses because we don't like that AWS is using our
code"-buzz that's been debated a lot lately.

~~~
detaro
It's not really surprising that companies wanting a new software license hire
a world-class expert in the field to help draft it. Any evidence she "started
the whole..." instead of doing her job as a lawyer?

~~~
hannob
> Any evidence she "started the whole..." instead of doing her job as a
> lawyer?

I'm not sure how that's a contradiction. Of course she can start something
while doing her job.

Evidence: [https://commonsclause.com/](https://commonsclause.com/) "The
Commons Clause is a license condition drafted by Heather Meeker"
[https://techcrunch.com/2018/11/29/the-crusade-against-
open-s...](https://techcrunch.com/2018/11/29/the-crusade-against-open-source-
abuse/) "Heather Meeker wrote both solutions, supported by feedback organized
by FOSSA."

~~~
detaro
Wouldn't you say the companies that asked her to help create these licenses
"started it"? I think for the question if another effort is suspect just
because it involves her the source of the motivation is IMHO relevant.

------
mijoharas
Can someone explain how the current licence is a problem for the following:

* Encourage ongoing contributions to LLVM by preserving a 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.

Is it because the other license is relatively unknown? Can anyone shed light
on why they didn't opt to go for BSD or MIT license? (is it the patent
protection stuff?)

~~~
geofft
The first mailing list post is a pretty good dive:
[http://lists.llvm.org/pipermail/llvm-
dev/2015-October/091536...](http://lists.llvm.org/pipermail/llvm-
dev/2015-October/091536.html)

In particular, the Apache license is a very clear and more importantly very
well-accepted mechanism of licensing relevant patents and not irrelevant ones.
The BSD and MIT licenses may or may not license patents depending on how you
(or the courts, really) interpret "Permission to use ... is hereby granted
...."

They also had a custom scheme for dual-licensing the runtime libraries that
get linked into compiled binaries. The new scheme grants a non-attribution
license based on the fact that it ended up in your code after running clang,
not which repo it was in, which makes it easier for LLVM to refactor code
between repos.

------
WalterBright
It's why the D language is all Boost licensed. We would have made it public
domain, but that isn't a legal concept in some countries. Boost is the closest
we could find to public domain and corporate lawyer approved.

------
floatingatoll
OP: This has been underway several years. Is there a recent turn of events
that should be considered as we view this page?

~~~
chandlerc1024
We are successfully moving towards the next bug milestone which will put the
new license in place going forward. This is likely among the most potentially
disruptive steps as we need to ensure subsequent contributions are under the
new license (additionally). We're targeting mid January pretty firmly now to
make the cutover. We'll be sending a detailed message to the LLVM lists about
this today.

And as the other responder mentioned, part of this has involved directly
contacting all committers in the last two years (more recent committers more
than once) to ensure we have everything we need to minimize disruption and
make the cut over.

~~~
nicwilson
I sincerely hope it ain't a bug milestone ;)

~~~
chandlerc1024
Doh!

------
rvp-x
I don't understand how licenses that make claims about patent lawsuits (GPLv3,
apache) can be re-using code from licenses that don't make patent claims (BSD,
etc.). I didn't promise not to sue anyone for royalties.

~~~
jessaustin
Their license doesn't bind your behavior, since you didn't release your code
under that license. However, it is probably the case that your code was also
not released under any license that forbids reuse by a downstream that does
make patent promises. (Does such a poison-pill anti-patent-promise license
even exist? I'm not aware of it.)

It might be a communications issue, that users of the downstream might assume
they won't get sued by you. If such users have money, they should hire
competent legal assistance.

------
hadrien01
The url shown in the header [0] doesn't exist:

> The requested URL /LICENSE.txt was not found on this server.

[0] [https://llvm.org/LICENSE.txt](https://llvm.org/LICENSE.txt)

~~~
athorax
[http://llvm.org/foundation/relicensing/LICENSE.txt](http://llvm.org/foundation/relicensing/LICENSE.txt)

------
hu3
Semi-related:

[https://opensource.google.com/docs/thirdparty/licenses/](https://opensource.google.com/docs/thirdparty/licenses/)

------
gigatexal
Yeah what’s the TL;DR but for dummies?

------
DannyB2
I wonder if LLVM has a code of conduct? It would be an interesting project to
develop a new open source CoC whose mere existence is a violation of itself.
:-)

~~~
wyldfire
> I wonder if LLVM has a code of conduct?

It does indeed. It was mostly non-controversial, except for [AFAIK] one
notable departure, de Espindola [1]. Lattner's response [2].

> ... new open source CoC whose mere existence is a violation of itself.

I can't tell if you're just being silly or if you're referring to an actual
contradiction related to relicensing and/or the CoC.

[1] [http://lists.llvm.org/pipermail/llvm-
dev/2018-May/122922.htm...](http://lists.llvm.org/pipermail/llvm-
dev/2018-May/122922.html)

[2]
[http://nondot.org/sabre/2018-05-02-Rafael.html](http://nondot.org/sabre/2018-05-02-Rafael.html)

