llvm dev - Oct 2015 - RFC: Improving license & patent issues in the LLVM community

Hi Everyone,

I’d like to start a discussion about how to improve some important issues we
have in the LLVM community, regarding our license and patent policy.  Before we
get started, I’d like to emphasize that *this is an RFC*, intended for
discussion.  There is no time pressure to do something fast here -- we want to
do the right long-term thing for the community (though we also don’t want
unnecessary delay, because there are real problems that need to be solved).  My
primary goal is to kick off the discussion now so that we can use time at the
LLVM Dev Meeting to talk about ideas and concerns in person.

If you’re not familiar, our current relevant policies are laid out here, in the
“license” and “patents” section:
http://llvm.org/docs/DeveloperPolicy.html#license
<http://llvm.org/docs/DeveloperPolicy.html#copyright-license-and-patents>

This is a long email, so I’ve broken it up into three sections:

1) The problem
2) Potential solutions
3) Recommended path forward

The TL;DR version of this is that I think we should discuss relicensing all of
LLVM under the Apache 2.0 license and add a runtime exception clause.  See below
for a lot more details.


The problem

We, as a community, have three major problems to solve in this space.  The first
two are active problems, the third is a lurking one:

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.  The root issue is that the wording in the Patent
section is fuzzy, novel to LLVM, and overly broad.  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”).  I will not
make any claims about whether these fears are founded or not, but I will observe
that this is a serious and current problem for the community.


2) We cannot easily move code from LLVM to compiler_rt (for example).

We currently have a schism between the compiler code (licensed under the UIUC
license) and the runtime library code (licensed under the UIUC & MIT
license).  This schism exists because the UIUC license carries what is known as
a “binary attribution clause”.  This clause requires someone to acknowledge
their use of LLVM if they link part of the compiler itself into their app (e.g.
in a readme, or an “about” panel).  This is reasonable for the compiler, but
isn’t reasonable for runtime libraries - you shouldn’t have to acknowledge LLVM
just because you happened to build your app with Clang!

Our previous approach to solving this problem was to dual license the runtime
libraries under both the UIUC and MIT licenses, because the MIT license doesn’t
carry a binary attribution clause.  This solved the attribution problem but
prevents us from moving code from LLVM to compiler_rt, because the contributor
may not have agreed to the use of the code under the MIT license.  This is an
active problem for ASAN and other technologies, that (e.g.) might want to use MC
disassembler functionality from a runtime library.


3) The patent coverage provided by the Developer Policy may not provide the
protection it intends.

The UIUC and MIT licenses have nothing to say about patents, and the wording in
the patents section of the Developer Policy was written by a well-intentioned
grad student, not by a lawyer.  The wording is fuzzy, imprecise, and potentially
incomplete and so it probably doesn’t provide the protection it intends.  
Fortunately, to my knowledge, this protection hasn’t been tested, but if it ever
was, it would be very bad for the community overall.  Lack of protection could
also lead to a potential user deciding not to use LLVM, if they perceived such
use to be too risky.


Potential solutions

The board decided to explore this area, and several of us have spent months
looking into this space to see what we can do to improve the situation.  This is
a complicated topic that deals with legal issues and our primary goal is to
unblock contributions from specific corporate contributors.  Because of that,
we’ve done some leg-work exploring options with a few of the largest
contributors in this space.  The board’s role here is to organize and facilitate
a discussion that leads to progress, and I’d like to share what we’ve found so
we (as a community) can discuss the options further.

We have four major options here, each of which implies that the license/patent
section of the Developer Policy would be removed and rewritten.  Once we agree
on a course of action, we can discuss exact wording and roll-out strategies:


1) We could introduce a novel legal solution.

We discussed a large number of different solutions that involve coming up with
something new.  For example, we could write an entirely new license, we could
write an entirely new patent grant, we could take existing license or grant
language and modify it, etc. This approach seems appealing in that we could get
something specifically tailored to LLVM and its contributors.

Unfortunately, there are many problems with this.  For example, using well known
license and patent mechanics makes it much easier for new contributors to get
permission to use and contribute to LLVM, because this often requires approval
from a corporate legal team, and reviewing something novel takes a long time and
a lot of energy.  If we go with a well known / standard approach, everything
goes simpler and faster.

Second, in legal circles, a novel solution (no matter how well intended) is
almost always considered to be a bad thing, because it hasn’t been legally
tested and hasn’t been scrutinized as much as existing ones.  Third, designing
such a thing is extremely complicated, because lawyers will all want to optimize
the result for their specific organization’s interests, so coming to an
agreement on such a new document will take a very long time and may be
impossible to get actual agreement.  We spent many of the months talking about
possibilities in this space, so we’ve seen some of this in action with no
closure in sight.


2) We could require new contributors to sign the Apache CLA.

The Apache CLA (e.g. the Google CLA is one example of it) is a well known and
highly respected way to define and scope guarantees when it comes to patent
contribution and coverage.  These are the specific forms I’m referring to: the
first is for individuals and the second is for corporate contributors:
https://www.apache.org/licenses/icla.txt
<https://www.apache.org/licenses/icla.txt>
http://www.apache.org/licenses/cla-corporate.txt
<http://www.apache.org/licenses/cla-corporate.txt>

The upshot is that adding the Apache CLA would solve some real problems.  It
would unblock contribution by properly scoping patent contributions and it would
ease fear of being sued (and though it wouldn’t help us with the binary
attribution clause problem with the runtime libraries, we could add a runtime
exception to solve that).  Rolling this out would be very straight-forward: we
could start requiring the CLA for new contributions, which provides guarantees
going forward, and we could even try to get earlier contributors to provide
retroactive coverage for previous contributions.

Unfortunately, adding the Apache CLA also has several disadvantages as well:

- It adds new barriers for new contributors to LLVM.  We don’t currently have a
process where you need to sign (or click through) a form, and adding one is a
barrier in certain situations (e.g. it requires individuals to disclose
sensitive personal information like mailing addresses etc, and may require extra
levels of legal approval in corporate situations).

- It significantly increases the burden for the LLVM project, because we need to
track a bunch of more data for each contributor (including their current
employment affiliation) to verify whether we are *allowed* to accept a patch. 
Engineers move around between companies all of the time, and it is problematic
(and invasive into personal privacy) for llvm.org <http://llvm.org/> to
have to know about this.

- The CLA requires corporations to keep an updated list of which employees are
allowed to contribute from their company (see Schedule A of
http://www.apache.org/licenses/cla-corporate.txt
<http://www.apache.org/licenses/cla-corporate.txt>).  This is a
significant burden on llvm.org <http://llvm.org/> as well as on corporate
contributors.  The logical end result of this is that a company would designate
a few people as contributors and funnel many other people’s work through them,
which is not good for the existing successful engineering culture of the
project.

- The CLA has specific wording that lawyers at multiple prominent corporate
contributors are reluctant to sign.  The changes they request are small, but
once we make changes to the CLA, it is now a novel document and we end up with
all the problems of solution #1.

- The CLA also provides power that I (personally) don’t think we “want" as
a community.  For example, it would allow the LLVM Foundation to arbitrarily
relicense the project without approval from the copyright holders.  While it may
seem ironic based on what I’m suggesting below, I think that it is in the *best
interest* of the project for any relicensing effort to be a painful and
expensive process that requires contacting all contributors.  Changing the
license of the project is a big deal, and not something we should do frequently.
Further, some individuals and corporations are wary of contributing to a project
when their code can be taken and relicensed to something that they didn’t agree
to, and we may lose them if we start requiring that.


3) We could relicense all of LLVM under the Apache 2.0 license and add a runtime
exception.

The Apache 2.0 license is a well known, widely used, and highly respected way to
define and scope guarantees when it comes to patent contribution and coverage. 
This is the license in question:
http://www.apache.org/licenses/LICENSE-2.0
<http://www.apache.org/licenses/LICENSE-2.0>

The runtime exception would be a short addendum.  For example, it could be
something like:
"As an exception, if you use this Software to compile your source code and
portions of this Software are embedded into the binary product as a result, you
may redistribute such product without providing attribution as would otherwise
be required by Sections 4(a), 4(b) and 4(d) of the License."

This approach solves all three of the problems above: it would unblock the
contributors in question by providing a known scope of patent grant based on
contribution and it provides patent protection to users of LLVM.  Adding a
runtime exception solves the runtime library issue, and is a standard way that
compilers do this sort of thing (e.g. GCC does something similar to avoid
compiled code having to be GPL compatible).

Switching LLVM to the Apache 2.0 license has some large advantages:

- We believe that we can use the license as-is, which avoids having to design a
novel solution.  Many companies already contribute to projects that use the
Apache 2.0 license.  Some of the companies we have spoken to have responded with
comments like “Apache 2?  Of course that would be fine with us.”

- The patent coverage in license is “self executing,” which means that coverage
is associated with a contributor putting code into the repository.  There are no
additional CLAs to agree to, no book-keeping or process issues for llvm.org
<http://llvm.org/> or corporate contributors, no personal information that
needs to be distributed, etc.  A company or individual merely needs to decide
whether they want to contribute a patch or not (a decision they need to make in
any case!) and everything else is automatic.

However, it also has one big disadvantage: the time and cost of doing it. 
Relicensing a large code base with many contributors is expensive, time
consuming, and complicated.  However, it has been done with other large projects
before (e.g. Mozilla) and in our early analysis, we believe it can be done with
LLVM too.


4) We could switch to another well-known solution.

We discussed many different well known licenses, CLAs, and other approaches to
solving these problems.  None of the ones considered fared as well as the Apache
CLA or the Apache 2.0 license, but of course something may have been missed.


Recommended path forward

NOTE: This is an RFC - this is a recommendation, not a dictate :-)

This probably isn’t a surprise at this point, but the LLVM Foundation board and
I recommend that we relicense all of the LLVM Project code (including clang,
lldb, …) currently under the UIUC and MIT licenses (i.e. not including the GPL
bits like llvm-gcc and dragonegg) under the Apache 2 license. We feel that it is
important to do something right for the long term, even if it is a complicated
and slow process, than to do the wrong thing in the short term.

It will take quite some time to roll this out - potentially 18 months or more,
but we believe it is possible and have some thoughts about how to do it.  We
have confirmed that choosing to go down this path would immediately unblock
contributions from the affected companies, because we could start accepting new
contributions under the terms of the UIUC/MIT/Apache licenses together and
repeal the wording in the developer policy.  If we get broad agreement that this
is the right direction to go, we can lay out our early ideas for how to do it,
and debate and fully bake that plan in public discussion.


With all this said, I’d love to hear what you all think.  If you have a specific
comment or discussion about one aspect of this, it might be best to start a new
thread.  I’d also appreciated it if you would mention whether you are a current
active contributor to LLVM, whether you are using LLVM but blocked from
contribution (and whether this approach would unblock that) or if you’re an
interested community member that is following or using LLVM, but not currently
(or on the edge of) contributing.  I’d be particularly interested if you are
blocked from contributing but this proposal doesn’t solve your concern.

If you plan to attend the developer meeting and would like to discuss it there,
the LLVM Foundation BOF would be a great place to talk about this.

Thanks!

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151019/31a2f8c5/attachment.html>

On 19 October 2015 at 16:25, Chris Lattner via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> This probably isn’t a surprise at this point, but the LLVM Foundation board
> and I recommend that we relicense all of the LLVM Project code (including
> clang, lldb, …) currently under the UIUC and MIT licenses (i.e. not
> including the GPL bits like llvm-gcc and dragonegg) under the Apache 2
> license. We feel that it is important to do something right for the long
> term, even if it is a complicated and slow process, than to do the wrong
> thing in the short term.
Hi Chris,

IANAL etc, but I think this is a good move. Open Source license
proliferation is a serious problem and it does incur in very long
delays in contributions from some companies / groups.

I can't comment on the virtues of the Apache license (versus BSD,
LGPL, etc), and I personally don't have preferences as to which
license we move to, as long as it's well known, widely used and
provide the features we need. If the Apache 2.0 (plus the binary
clause, that GCC uses too) fits the bill, LGTM. :)

The move may impose some extra work on the companies that already
contribute to LLVM but still don't have legal approval for Apache 2.0
licensed projects. But if the time frame is 18+ months, I think that's
not going to be that big of a deal.

cheers,
--renato

On Mon, Oct 19, 2015 at 08:25:16AM -0700, Chris Lattner via llvm-dev
wrote:
> 1) We could introduce a novel legal solution.
Please, no.
> 2) We could require new contributors to sign the Apache CLA.
To me, this is the most acceptable option of the listed terms.
> 3) We could relicense all of LLVM under the Apache 2.0 license and add a
runtime exception.
This one I would consider a regression over the status quo. Your list is
missing "the license is significantly longer and harder to read".

Joerg

On Mon, Oct 19, 2015 at 9:27 AM, Joerg Sonnenberger via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On Mon, Oct 19, 2015 at 08:25:16AM -0700, Chris Lattner via llvm-dev wrote:
>> 1) We could introduce a novel legal solution.
>
> Please, no.
>
>> 2) We could require new contributors to sign the Apache CLA.
>
> To me, this is the most acceptable option of the listed terms.
>
>> 3) We could relicense all of LLVM under the Apache 2.0 license and add
a runtime exception.
>
> This one I would consider a regression over the status quo. Your list is
> missing "the license is significantly longer and harder to read".
Why is this a consideration?

The apache license is incredibly well known, and easy to analyze.

> On Oct 19, 2015, at 9:27 AM, Joerg Sonnenberger via llvm-dev <llvm-dev
at lists.llvm.org> wrote:
> 
> On Mon, Oct 19, 2015 at 08:25:16AM -0700, Chris Lattner via llvm-dev wrote:
>> 1) We could introduce a novel legal solution.
> 
> Please, no.
> 
>> 2) We could require new contributors to sign the Apache CLA.
> 
> To me, this is the most acceptable option of the listed terms.
Please explain: why?
>> 3) We could relicense all of LLVM under the Apache 2.0 license and add
a runtime exception.
> 
> This one I would consider a regression over the status quo. Your list is
> missing "the license is significantly longer and harder to read”.
To repeat Danny’s point, this doesn’t seem like a concern to me.  Please explain
your concern: does this affect users of llvm, contributors to llvm, or someone
else?  How?

-Chris

Hi Chris,

On 19 Oct 2015, at 16:25, Chris Lattner via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 1) The problem
> 2) Potential solutions
> 3) Recommended path forward
> 
> The TL;DR version of this is that I think we should discuss relicensing all
of LLVM under the Apache 2.0 license and add a runtime exception clause.  See
below for a lot more details.
I agree that this is a problem.  In another community, we’ve deployed an
Apache-style CLA.  From a legal perspective, it’s definitely the best way
forward, but it does add a significant barrier to entry (though not as big as
copyright assignment, as for FSF projects).    I have two concerns, one related
to the Apache 2 license in general, the other related to switching license in
general.

Because LLVM has not had a policy of including copyright holders in files
(something else that we should change), it’s difficult to identify copyright
holders.  When we relicensed libcompiler_rt and libc++ under the MIT license,
there were only a few contributors and it was easy to identify us all.  Over
LLVM, it’s not clear that the people who have committed code on behalf of others
have been good at ensuring that it’s correctly attributed.  I’d be interested to
hear what the Foundation’s strategy for dealing with this is (and what will
happen if a contributor of a significant amount of code does not permit their
code to be relicensed if the overall consensus appears to be in favour of
relicensing).

On the Apache 2 front specifically, we’ve been slowly reducing the amount of
Apache 2 code in FreeBSD and would be quite unhappy to suddenly increase it. 
LLVM is one of the largest bits of contrib code in our base system and, for us,
it would be a step in the wrong direction.  One worry is that Apache 2 is
incompatible with GPLv2 (is it incompatible with other licenses?), which limits
the number of places where it can be used (though possibly not to a degree worth
worrying about).  A related concern is that I can read the UIUC and, as a
non-lawyer, be pretty sure that I understand it.  I can not make the same claim
about Apache 2, in spite of having read it several times.  It’s probably not a
show-stopper for us, but it would probably reduce LLVM contributions from within
the FreeBSD community, which is something that’s been slowly increasing
recently.
> With all this said, I’d love to hear what you all think.  If you have a
specific comment or discussion about one aspect of this, it might be best to
start a new thread.  I’d also appreciated it if you would mention whether you
are a current active contributor to LLVM, whether you are using LLVM but blocked
from contribution (and whether this approach would unblock that) or if you’re an
interested community member that is following or using LLVM, but not currently
(or on the edge of) contributing.  I’d be particularly interested if you are
blocked from contributing but this proposal doesn’t solve your concern.
I’m wearing a few LLVM-related hats (including a downstream consumer with my
FreeBSD Core Team hat and a few research projects, and a contributor to various
bits of LLVM, including clang, libc++, libcompiler_rt, optimisers, codegen and
the MIPS back end).  I’m not blocked from contributing by the current status quo
(other than the fact that most of the changes in the LLVM trees that I’m
responsible for at the moment are of no interest to people who don’t [yet?] have
access to some currently quite rare hardware).

David

Am 19.10.2015 um 17:25 schrieb Chris Lattner via
llvm-dev:
> Unfortunately, adding the Apache CLA also has several disadvantages
> as well:
>
> - It adds new barriers for new contributors to LLVM.  We don’t
> currently have a process where you need to sign (or click through) a
> form, and adding one is a barrier in certain situations (e.g. it
> requires individuals to disclose sensitive personal information like
> mailing addresses etc, and may require extra levels of legal approval
> in corporate situations).
If you want to extend a patent license to any LLVM user, you need legal 
approval from the patent holder, and that inevitably means paperwork.
> - The CLA also provides power that I (personally) don’t think we
> “want" as a community.  For example, it would allow the LLVM
> Foundation to arbitrarily relicense the project without approval from
> the copyright holders.
That's actually a necessity. Laws change, interpretations change, and it 
may be necessary to change the license to achieve the original goals.

If you want to make clear that it is not going to be "power to the 
LLVM", you can state what kinds of license change might be done in the 
future.
> 4) We could switch to another well-known solution.
One solution I haven't seen mentioned: Become one of the projects under 
the Apache Foundation umbrella.
Benefits are legal protection, established licensing terms, established 
organizational procedures, a pool of experience to tap for questions 
like Code of Conduct, legalese, or organisational details.
Downside is that you need to relicense everything for the Apache 2.0 
license, but if you consider going there, it may be a good idea to go 
the full distance.
> With all this said, I’d love to hear what you all think.
Speaking as a potential user of LLVM, I'd be happy with almost anything. 
Well, maybe not the GPL because that would restrict my own licensing 
options, but the GPL isn't on the table anyway, so I don't have any 
stakes in this.

Regards,
Jo

On Mon, Oct 19, 2015 at 10:24 AM, Joachim Durchholz via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Am 19.10.2015 um 17:25 schrieb Chris Lattner via llvm-dev:
>>
>> Unfortunately, adding the Apache CLA also has several disadvantages
>> as well:
>>
>> - It adds new barriers for new contributors to LLVM.  We don’t
>> currently have a process where you need to sign (or click through) a
>> form, and adding one is a barrier in certain situations (e.g. it
>> requires individuals to disclose sensitive personal information like
>> mailing addresses etc, and may require extra levels of legal approval
>> in corporate situations).
>
>
> If you want to extend a patent license to any LLVM user, you need legal
> approval from the patent holder, and that inevitably means paperwork.
Speaking as an IP lawyer, No it does not require more than the CLA or
the license provide.
Period.
If you want details, i'm happy to chat, but suffice to say, either of
the CLA or relicensing option would provide the same patent
protection.

I really really do not like armchair lawyer discussions and this is
just flamebait if I've ever seen it...
---------------
#1 Is the submarine patent risk really that bad? (What's driving this)

#2 Pragmatically have "you" even considered how to execute on this
relicense plan?
a. What if one of the copyright holders doesn't agree?
b. What audit procedure do you plan to use
c. Legal costs??? Is Apple or Google going to pay the bill or is some
poor non-profit going to get stuck with it
d. What's the project downside
i. Fragmentation from people who feel strongly against the APL2 license...
ii. Lost cycles because people who could be writing code are pandering
on about licensing

On Oct 19, 2015, at 11:25 AM, Chris Lattner via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 3) We could relicense all of LLVM under the Apache 2.0 license and add a
runtime exception.
> 
> The Apache 2.0 license is a well known, widely used, and highly respected
way to define and scope guarantees when it comes to patent contribution and
coverage.  This is the license in question:
> http://www.apache.org/licenses/LICENSE-2.0
<http://www.apache.org/licenses/LICENSE-2.0>
> 
> The runtime exception would be a short addendum.  For example, it could be
something like:
> "As an exception, if you use this Software to compile your source code
and portions of this Software are embedded into the binary product as a result,
you may redistribute such product without providing attribution as would
otherwise be required by Sections 4(a), 4(b) and 4(d) of the License."
It seems important to be clear in communications like this that the proposal is
for LLVM to be relicensed under the "Apache 2.0 with extra LLVM runtime
exception" license, NOT under the "Apache 2.0" license, with an
extra LLVM runtime exception.

That seems important to be absolutely clear about, because at the very least
presumably LLVM would not be allowed to integrate any code under the normal
Apache 2.0 license, or else it'd lose the runtime exception, right?


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151019/e2ce5dbf/attachment.html>

On 19 October 2015 at 18:12, David Chisnall via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> One worry is that Apache 2 is incompatible with GPLv2 (is it incompatible
with other licenses?)
This is interesting, I did not know that...

http://www.apache.org/licenses/GPL-compatibility.html

"Despite our best efforts, the FSF has never considered the Apache
License to be compatible with GPL version 2, citing the patent
termination and indemnification provisions as restrictions not present
in the older GPL license."

It seems to be compatible with GPLv3, though. But I think most
companies that use LLVM are stuck with GPLv2 due to the patents issue.

cheers,
--renato

> On Oct 19, 2015, at 10:50 AM, James Y Knight via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> On Oct 19, 2015, at 11:25 AM, Chris Lattner via llvm-dev <llvm-dev at
lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> 3) We could relicense all of LLVM under the Apache 2.0 license and add
a runtime exception.
>> 
>> The Apache 2.0 license is a well known, widely used, and highly
respected way to define and scope guarantees when it comes to patent
contribution and coverage.  This is the license in question:
>> http://www.apache.org/licenses/LICENSE-2.0
<http://www.apache.org/licenses/LICENSE-2.0>
>> 
>> The runtime exception would be a short addendum.  For example, it could
be something like:
>> "As an exception, if you use this Software to compile your source
code and portions of this Software are embedded into the binary product as a
result, you may redistribute such product without providing attribution as would
otherwise be required by Sections 4(a), 4(b) and 4(d) of the License."
> 
> It seems important to be clear in communications like this that the
proposal is for LLVM to be relicensed under the "Apache 2.0 with extra LLVM
runtime exception" license, NOT under the "Apache 2.0" license,
with an extra LLVM runtime exception.
Right, I’m sorry for over simplifying that.
> That seems important to be absolutely clear about, because at the very
least presumably LLVM would not be allowed to integrate any code under the
normal Apache 2.0 license, or else it'd lose the runtime exception, right?
Yes, that is correct.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151019/36327ebf/attachment.html>

Hi Chris,

I think the license and patent policy changes you've recommended sound good
and will help avoid any confusion about these for the project. Thanks for
broaching the subject and dealing with the related issues

-eric

On Mon, Oct 19, 2015, 8:25 AM Chris Lattner via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi Everyone,
>
> I’d like to start a discussion about how to improve some important issues
> we have in the LLVM community, regarding our license and patent policy.
> Before we get started, I’d like to emphasize that *this is an RFC*,
> intended for discussion.  There is no time pressure to do something fast
> here -- we want to do the right long-term thing for the community (though
> we also don’t want unnecessary delay, because there are real problems that
> need to be solved).  My primary goal is to kick off the discussion now so
> that we can use time at the LLVM Dev Meeting to talk about ideas and
> concerns in person.
>
> If you’re not familiar, our current relevant policies are laid out here,
> in the “license” and “patents” section:
> http://llvm.org/docs/DeveloperPolicy.html#license
>
<http://llvm.org/docs/DeveloperPolicy.html#copyright-license-and-patents>
>
> This is a long email, so I’ve broken it up into three sections:
>
> 1) The problem
> 2) Potential solutions
> 3) Recommended path forward
>
> The TL;DR version of this is that I think we should discuss *relicensing
> all of LLVM under the Apache 2.0 license* and *add a runtime exception
> clause*.  See below for a lot more details.
>
>
> *The problem*
>
> We, as a community, have three major problems to solve in this space.  The
> first two are active problems, the third is a lurking one:
>
> 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.  The root issue is that the wording in the Patent
> section is fuzzy, novel to LLVM, and overly broad.  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”).  I will not make any claims about whether these fears are founded
> or not, but I will observe that this is a serious and current problem for
> the community.
>
>
> 2) We cannot easily move code from LLVM to compiler_rt (for example).
>
> We currently have a schism between the compiler code (licensed under the
> UIUC license) and the runtime library code (licensed under the UIUC &
MIT
> license).  This schism exists because the UIUC license carries what is
> known as a “binary attribution clause”.  This clause requires someone to
> acknowledge their use of LLVM if they link part of the compiler itself into
> their app (e.g. in a readme, or an “about” panel).  This is reasonable for
> the compiler, but isn’t reasonable for runtime libraries - you shouldn’t
> have to acknowledge LLVM just because you happened to build your app with
> Clang!
>
> Our previous approach to solving this problem was to dual license the
> runtime libraries under both the UIUC and MIT licenses, because the MIT
> license doesn’t carry a binary attribution clause.  This solved the
> attribution problem but prevents us from moving code from LLVM to
> compiler_rt, because the contributor may not have agreed to the use of the
> code under the MIT license.  This is an active problem for ASAN and other
> technologies, that (e.g.) might want to use MC disassembler functionality
> from a runtime library.
>
>
> 3) The patent coverage provided by the Developer Policy may not provide
> the protection it intends.
>
> The UIUC and MIT licenses have nothing to say about patents, and the
> wording in the patents section of the Developer Policy was written by a
> well-intentioned grad student, not by a lawyer.  The wording is fuzzy,
> imprecise, and potentially incomplete and so it probably doesn’t provide
> the protection it intends.   Fortunately, to my knowledge, this protection
> hasn’t been tested, but if it ever was, it would be very bad for the
> community overall.  Lack of protection could also lead to a potential user
> deciding not to use LLVM, if they perceived such use to be too risky.
>
>
> *Potential solutions*
>
> The board decided to explore this area, and several of us have spent
> months looking into this space to see what we can do to improve the
> situation.  This is a complicated topic that deals with legal issues and
> our primary goal is to unblock contributions from specific corporate
> contributors.  Because of that, we’ve done some leg-work exploring options
> with a few of the largest contributors in this space.  The board’s role
> here is to organize and facilitate a discussion that leads to progress, and
> I’d like to share what we’ve found so we (as a community) can discuss the
> options further.
>
> We have four major options here, each of which implies that the
> license/patent section of the Developer Policy would be removed and
> rewritten.  Once we agree on a course of action, we can discuss exact
> wording and roll-out strategies:
>
>
> 1) We could introduce a novel legal solution.
>
> We discussed a large number of different solutions that involve coming up
> with something new.  For example, we could write an entirely new license,
> we could write an entirely new patent grant, we could take existing license
> or grant language and modify it, etc. This approach seems appealing in that
> we could get something specifically tailored to LLVM and its contributors.
>
> Unfortunately, there are many problems with this.  For example, using well
> known license and patent mechanics makes it much easier for new
> contributors to get permission to use and contribute to LLVM, because this
> often requires approval from a corporate legal team, and reviewing
> something novel takes a long time and a lot of energy.  If we go with a
> well known / standard approach, everything goes simpler and faster.
>
> Second, in legal circles, a novel solution (no matter how well intended)
> is almost always considered to be a bad thing, because it hasn’t been
> legally tested and hasn’t been scrutinized as much as existing ones.
> Third, designing such a thing is extremely complicated, because lawyers
> will all want to optimize the result for their specific organization’s
> interests, so coming to an agreement on such a new document will take a
> very long time and may be impossible to get actual agreement.  We spent
> many of the months talking about possibilities in this space, so we’ve seen
> some of this in action with no closure in sight.
>
>
> 2) We could require new contributors to sign the Apache CLA.
>
> The Apache CLA (e.g. the Google CLA is one example of it) is a well known
> and highly respected way to define and scope guarantees when it comes to
> patent contribution and coverage.  These are the specific forms I’m
> referring to: the first is for individuals and the second is for corporate
> contributors:
> https://www.apache.org/licenses/icla.txt
> http://www.apache.org/licenses/cla-corporate.txt
>
> The upshot is that adding the Apache CLA would solve some real problems.
> It would unblock contribution by properly scoping patent contributions and
> it would ease fear of being sued (and though it wouldn’t help us with the
> binary attribution clause problem with the runtime libraries, we could add
> a runtime exception to solve that).  Rolling this out would be very
> straight-forward: we could start requiring the CLA for new contributions,
> which provides guarantees going forward, and we could even try to get
> earlier contributors to provide retroactive coverage for previous
> contributions.
>
> Unfortunately, adding the Apache CLA also has several disadvantages as
> well:
>
> - It adds new barriers for new contributors to LLVM.  We don’t currently
> have a process where you need to sign (or click through) a form, and adding
> one is a barrier in certain situations (e.g. it requires individuals to
> disclose sensitive personal information like mailing addresses etc, and may
> require extra levels of legal approval in corporate situations).
>
> - It significantly increases the burden for the LLVM project, because we
> need to track a bunch of more data for each contributor (including their
> current employment affiliation) to verify whether we are *allowed* to
> accept a patch.  Engineers move around between companies all of the time,
> and it is problematic (and invasive into personal privacy) for llvm.org to
> have to know about this.
>
> - The CLA requires corporations to keep an updated list of which employees
> are allowed to contribute from their company (see Schedule A of
> http://www.apache.org/licenses/cla-corporate.txt).  This is a significant
> burden on llvm.org as well as on corporate contributors.  The logical end
> result of this is that a company would designate a few people as
> contributors and funnel many other people’s work through them, which is not
> good for the existing successful engineering culture of the project.
>
> - The CLA has specific wording that lawyers at multiple prominent
> corporate contributors are reluctant to sign.  The changes they request are
> small, but once we make changes to the CLA, it is now a novel document and
> we end up with all the problems of solution #1.
>
> - The CLA also provides power that I (personally) don’t think we
“want" as
> a community.  For example, it would allow the LLVM Foundation to
> arbitrarily relicense the project without approval from the copyright
> holders.  While it may seem ironic based on what I’m suggesting below, I
> think that it is in the *best interest* of the project for any relicensing
> effort to be a painful and expensive process that requires contacting all
> contributors.  Changing the license of the project is a big deal, and not
> something we should do frequently.  Further, some individuals and
> corporations are wary of contributing to a project when their code can be
> taken and relicensed to something that they didn’t agree to, and we may
> lose them if we start requiring that.
>
>
> 3) We could relicense all of LLVM under the Apache 2.0 license and add a
> runtime exception.
>
> The Apache 2.0 license is a well known, widely used, and highly respected
> way to define and scope guarantees when it comes to patent contribution and
> coverage.  This is the license in question:
> http://www.apache.org/licenses/LICENSE-2.0
>
> The runtime exception would be a short addendum.  For example, it could be
> something like:
> "As an exception, if you use this Software to compile your source code
> and portions of this Software are embedded into the binary product as a
> result, you may redistribute such product without providing attribution as
> would otherwise be required by Sections 4(a), 4(b) and 4(d) of the
License."
>
> This approach solves all three of the problems above: it would unblock the
> contributors in question by providing a known scope of patent grant based
> on contribution and it provides patent protection to users of LLVM.  Adding
> a runtime exception solves the runtime library issue, and is a standard way
> that compilers do this sort of thing (e.g. GCC does something similar to
> avoid compiled code having to be GPL compatible).
>
> Switching LLVM to the Apache 2.0 license has some large advantages:
>
> - We believe that we can use the license as-is, which avoids having to
> design a novel solution.  Many companies already contribute to projects
> that use the Apache 2.0 license.  Some of the companies we have spoken to
> have responded with comments like “Apache 2?  Of course that would be fine
> with us.”
>
> - The patent coverage in license is “self executing,” which means that
> coverage is associated with a contributor putting code into the
> repository.  There are no additional CLAs to agree to, no book-keeping or
> process issues for llvm.org or corporate contributors, no personal
> information that needs to be distributed, etc.  A company or individual
> merely needs to decide whether they want to contribute a patch or not (a
> decision they need to make in any case!) and everything else is automatic.
>
> However, it also has one big disadvantage: the time and cost of doing it.
> Relicensing a large code base with many contributors is expensive, time
> consuming, and complicated.  However, it has been done with other large
> projects before (e.g. Mozilla) and in our early analysis, we believe it can
> be done with LLVM too.
>
>
> 4) We could switch to another well-known solution.
>
> We discussed many different well known licenses, CLAs, and other
> approaches to solving these problems.  None of the ones considered fared as
> well as the Apache CLA or the Apache 2.0 license, but of course something
> may have been missed.
>
>
>
> *Recommended path forward*
> NOTE: This is an RFC - this is a recommendation, not a dictate :-)
>
> This probably isn’t a surprise at this point, but the LLVM Foundation
> board and I recommend that we relicense all of the LLVM Project code
> (including clang, lldb, …) currently under the UIUC and MIT licenses (i.e.
> not including the GPL bits like llvm-gcc and dragonegg) under the Apache 2
> license. We feel that it is important to do something right for the long
> term, even if it is a complicated and slow process, than to do the wrong
> thing in the short term.
>
> It will take quite some time to roll this out - potentially 18 months or
> more, but we believe it is possible and have some thoughts about how to do
> it.  We have confirmed that choosing to go down this path would immediately
> unblock contributions from the affected companies, because we could start
> accepting new contributions under the terms of the UIUC/MIT/Apache licenses
> together and repeal the wording in the developer policy.  If we get broad
> agreement that this is the right direction to go, we can lay out our early
> ideas for how to do it, and debate and fully bake that plan in public
> discussion.
>
>
> With all this said, I’d love to hear what you all think.  If you have a
> specific comment or discussion about one aspect of this, it might be best
> to start a new thread.  I’d also appreciated it if you would mention
> whether you are a current active contributor to LLVM, whether you are using
> LLVM but blocked from contribution (and whether this approach would unblock
> that) or if you’re an interested community member that is following or
> using LLVM, but not currently (or on the edge of) contributing.  I’d be
> particularly interested if you are blocked from contributing but this
> proposal doesn’t solve your concern.
>
> If you plan to attend the developer meeting and would like to discuss it
> there, the LLVM Foundation BOF would be a great place to talk about this.
>
> Thanks!
>
> -Chris
> _______________________________________________
> 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/20151020/73a841e0/attachment.html>

Hi David,

Sorry for the delay getting back to you, been a bit buried:

On Oct 19, 2015, at 10:12 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk> wrote:
>> The TL;DR version of this is that I think we should discuss relicensing
all of LLVM under the Apache 2.0 license and add a runtime exception clause. 
See below for a lot more details.
> 
> I agree that this is a problem.  In another community, we’ve deployed an
Apache-style CLA.  From a legal perspective, it’s definitely the best way
forward, but it does add a significant barrier to entry (though not as big as
copyright assignment, as for FSF projects).    I have two concerns, one related
to the Apache 2 license in general, the other related to switching license in
general.
> 
> Because LLVM has not had a policy of including copyright holders in files
(something else that we should change), it’s difficult to identify copyright
holders.  When we relicensed libcompiler_rt and libc++ under the MIT license,
there were only a few contributors and it was easy to identify us all.  Over
LLVM, it’s not clear that the people who have committed code on behalf of others
have been good at ensuring that it’s correctly attributed.  I’d be interested to
hear what the Foundation’s strategy for dealing with this is (and what will
happen if a contributor of a significant amount of code does not permit their
code to be relicensed if the overall consensus appears to be in favour of
relicensing).
I’m intentionally trying to separate the discussion of “what to do” from the
“how to do it” discussion (both topics are complex and could confuse the issue).
If we can gain consensus on direction, then we can turn to logistics.

I completely agree with you that this will be a pain and a lot of work.  I have
no personal experience with such an effort, but I have spoken to a few folks who
have done similar things in other large scale projects to discuss the viability
of this.  They seem to think it is possible, and there are multiple possible
paths to get from here to there if the community agrees that it is the right
path.
> On the Apache 2 front specifically, we’ve been slowly reducing the amount
of Apache 2 code in FreeBSD and would be quite unhappy to suddenly increase it. 
LLVM is one of the largest bits of contrib code in our base system and, for us,
it would be a step in the wrong direction.  One worry is that Apache 2 is
incompatible with GPLv2 (is it incompatible with other licenses?), which limits
the number of places where it can be used (though possibly not to a degree worth
worrying about).  A related concern is that I can read the UIUC and, as a
non-lawyer, be pretty sure that I understand it.  I can not make the same claim
about Apache 2, in spite of having read it several times.  It’s probably not a
show-stopper for us, but it would probably reduce LLVM contributions from within
the FreeBSD community, which is something that’s been slowly increasing
recently.
I am truly sorry that the FreeBSD community would see this as a step backward. 
I believe that I have covered both of these points in other posts, but to
summarize:

- My understanding is that “GPL2-and-not-later” projects are extremely rare. 
Apache 2 is compatible with GPL3 code, and the FSF recommends use of Apache 2
for permissively licensed code (because they see the patent protection as being
valuable).  Is there a specific set of affected GPL2-only code that we should
consider?  Note that it will still be fine to *compile* GPL2 with Clang for
example, it is only linking LLVM code into a GPL2-only app that would become a
problem.

- Apache 2 is definitely a longer and more complex license than (e.g.) MIT, BSD,
or UIUC licenses.  However, it is the only prominent choice that achieves our
goals.  If you have other suggestions for consideration, I’d welcome it.

Does the FreeBSD project see any value in the patent coverage provided by the
Apache 2 license, or is it really a net negative?  In your opinion, would this
cause the FreeBSD to look to abandon use of LLVM code, or would it just cause
some amount of discomfort/unhappiness?

-Chris

Hi David,

Sorry for the delay getting back to you, been a bit buried:

On Oct 19, 2015, at 10:12 AM, David Chisnall <David.Chisnall at
cl.cam.ac.uk> wrote:
>> The TL;DR version of this is that I think we should discuss relicensing
all of LLVM under the Apache 2.0 license and add a runtime exception clause. 
See below for a lot more details.
> 
> I agree that this is a problem.  In another community, we’ve deployed an
Apache-style CLA.  From a legal perspective, it’s definitely the best way
forward, but it does add a significant barrier to entry (though not as big as
copyright assignment, as for FSF projects).    I have two concerns, one related
to the Apache 2 license in general, the other related to switching license in
general.
> 
> Because LLVM has not had a policy of including copyright holders in files
(something else that we should change), it’s difficult to identify copyright
holders.  When we relicensed libcompiler_rt and libc++ under the MIT license,
there were only a few contributors and it was easy to identify us all.  Over
LLVM, it’s not clear that the people who have committed code on behalf of others
have been good at ensuring that it’s correctly attributed.  I’d be interested to
hear what the Foundation’s strategy for dealing with this is (and what will
happen if a contributor of a significant amount of code does not permit their
code to be relicensed if the overall consensus appears to be in favour of
relicensing).
I’m intentionally trying to separate the discussion of “what to do” from the
“how to do it” discussion (both topics are complex and could confuse the issue).
If we can gain consensus on direction, then we can turn to logistics.

I completely agree with you that this will be a pain and a lot of work.  I have
no personal experience with such an effort, but I have spoken to a few folks who
have done similar things in other large scale projects to discuss the viability
of this.  They seem to think it is possible, and there are multiple possible
paths to get from here to there if the community agrees that it is the right
path.
> On the Apache 2 front specifically, we’ve been slowly reducing the amount
of Apache 2 code in FreeBSD and would be quite unhappy to suddenly increase it. 
LLVM is one of the largest bits of contrib code in our base system and, for us,
it would be a step in the wrong direction.  One worry is that Apache 2 is
incompatible with GPLv2 (is it incompatible with other licenses?), which limits
the number of places where it can be used (though possibly not to a degree worth
worrying about).  A related concern is that I can read the UIUC and, as a
non-lawyer, be pretty sure that I understand it.  I can not make the same claim
about Apache 2, in spite of having read it several times.  It’s probably not a
show-stopper for us, but it would probably reduce LLVM contributions from within
the FreeBSD community, which is something that’s been slowly increasing
recently.
I am truly sorry that the FreeBSD community would see this as a step backward. 
I believe that I have covered both of these points in other posts, but to
summarize:

- My understanding is that “GPL2-and-not-later” projects are extremely rare. 
Apache 2 is compatible with GPL3 code, and the FSF recommends use of Apache 2
for permissively licensed code (because they see the patent protection as being
valuable).  Is there a specific set of affected GPL2-only code that we should
consider?  Note that it will still be fine to *compile* GPL2 with Clang for
example, it is only linking LLVM code into a GPL2-only app that would become a
problem.

- Apache 2 is definitely a longer and more complex license than (e.g.) MIT, BSD,
or UIUC licenses.  However, it is the only prominent choice that achieves our
goals.  If you have other suggestions for consideration, I’d welcome it.

Does the FreeBSD project see any value in the patent coverage provided by the
Apache 2 license, or is it really a net negative?  In your opinion, would this
cause the FreeBSD to look to abandon use of LLVM code, or would it just cause
some amount of discomfort/unhappiness?

-Chris

----- Original Message -----
> From: "Chris Lattner via llvm-dev" <llvm-dev at
lists.llvm.org>
> To: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Monday, October 19, 2015 10:25:16 AM
> Subject: [llvm-dev] RFC: Improving license & patent issues in the LLVM
community
> 
> Hi Everyone,
> 
> 
...
> 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. The root issue is that the wording in
> the Patent section is fuzzy, novel to LLVM, and overly broad.
> 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”). I
> will not make any claims about whether these fears are founded or
> not, but I will observe that this is a serious and current problem
> for the community.
Can you provide an explicit example of this "score creep", and how the
Apache 2 license avoids it? And, furthermore, is avoiding it really a good
thing?

The current text says, "If you or your employer own the rights to a patent
and would like to contribute code to LLVM that relies on it, we require that the
copyright owner sign an agreement that allows any other user of LLVM to freely
use your patent." One interpretation of "scope creep" is that, if
contributor C owns a patent on algorithm A, and contributes an implementation of
that to LLVM, then the current wording implies that any user of LLVM (which, in
practice, means everyone) can use algorithm A for whatever purpose they choose.
I can understand that being troubling for the holder of that IP, who might want
to allow use of algorithm A only within LLVM. However, from the open-source
perspective, I find anything else deeply troubling. This means that, while, it
might be fine to use algorithm A in code in (or derived from) LLVM, I cannot
look at that algorithm and reimplement it anywhere else. In practice, this
implies that the current LLVM codebase will accumulate an unknown number of
algorithms that cannot be reimplemented in other contexts. While this might make
good 'job security' for LLVM, it seems bad for the ecosystem as a whole.

The Apache 2 license, section 3 (Grant of Patent License), "... where such
license applies only to those patent claims licensable by such Contributor that
are necessarily infringed by their Contribution(s) alone or by combination of
their Contribution(s) with the Work to which such Contribution(s) was
submitted." This text seems to swing the "scope creep" pendulum
all the way in the other direction, specifically by saying "*was*
submitted". This does not seem to make a provision for future growth of the
project, let alone uses in combination with third-party code. And, frankly,
trying to predict the future directions of the project, as a whole, can be
difficult (everything from libFuzzer and an OpenMP runtime to clang-modernize
and Clang's static analyzer, not to mention traditional compiler
technologies). This seems to imply that a contributor could make a contribution
necessarily infringing on their patented algorithm A, but that implied patent
license covers only using A in combination with the things LLVM happened to do
at the time the contribution was made (and not, necessarily, with any
third-party code).

To be clear, I'd really like to see a solution that will unblock
contributions from these potential contributors, however, I think we need to
better understand their concerns and the ramifications of the wording we propose
to adopt.
> 
...
>
> 3) The patent coverage provided by the Developer Policy may not
> provide the protection it intends.
> 
...
> 
> 3) We could relicense all of LLVM under the Apache 2.0 license and
> add a runtime exception.
> 
> 
> The Apache 2.0 license is a well known, widely used, and highly
> respected way to define and scope guarantees when it comes to patent
> contribution and coverage. This is the license in question:
> http://www.apache.org/licenses/LICENSE-2.0
> 
> 
> The runtime exception would be a short addendum. For example, it
> could be something like:
> "As an exception, if you use this Software to compile your source
> code and portions of this Software are embedded into the binary
> product as a result, you may redistribute such product without
> providing attribution as would otherwise be required by Sections
> 4(a), 4(b) and 4(d) of the License."
I assume this still needs some fair amount of wordsmithing. 'compile'
might be overly specific, given that we have source-to-source translators
(clang-modernize, etc.) that can easily introduce the same problem.
'your' seems ambiguous.

The downside here is that, by adding an exception, we've again created
something novel. I agree, however, that adding some kind of runtime exception to
all of LLVM is the right direction for the project.

Thanks again,
Hal
> 
> 
...
> 
> Thanks!
> 
> 
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory

Am 21.10.2015 um 13:55 schrieb Hal Finkel via llvm-dev:
> The current text says, "If you or your employer own the rights to a
> patent and would like to contribute code to LLVM that relies on it,
> we require that the copyright owner sign an agreement that allows any
> other user of LLVM to freely use your patent." One interpretation of
> "scope creep" is that, if contributor C owns a patent on
algorithm A,
> and contributes an implementation of that to LLVM, then the current
> wording implies that any user of LLVM (which, in practice, means
> everyone) can use algorithm A for whatever purpose they choose. I can
> understand that being troubling for the holder of that IP, who might
> want to allow use of algorithm A only within LLVM. However, from the
> open-source perspective, I find anything else deeply troubling. This
> means that, while, it might be fine to use algorithm A in code in (or
> derived from) LLVM, I cannot look at that algorithm and reimplement
> it anywhere else. In practice, this implies that the current LLVM
> codebase will accumulate an unknown number of algorithms that cannot
> be reimplemented in other contexts. While this might make good 'job
> security' for LLVM, it seems bad for the ecosystem as a whole.
I do not think that job security comes into play; job security stems 
from being the only person who can handle a specific piece of code, and 
I think it's largely orthogonal to the question whether the code is 
patented.

Allowing patented code into LLVM makes LLVM more powerful, but it also 
makes it harder to take LLVM code away into other projects (the latter 
usually leads to cross-pollination, which can be highly fertile).
Essentially that's a judgement call of the LLVM community.

Whether the "ecosystem as a whole" profits is a rather contentious 
claim. The question is whether the LLVM community is interested in the 
ecosystem as a whole at all.

So... what are the goals of the project?
- Improve the Open Source ecosystem? Then LLVM cannot accept any code 
that does not come with a free-of-charge, public patent license for any 
patents involved. Forces patent holders into a judgement call about 
whether the patent is worth the hassle of maintaining a patch set until 
the patent expires - from an "improve the FOSS ecosystem" perspective,
that's actually a Good Thing because it might liberate some patents.
- Make an open-source compiler backend, don't make any patent promises 
towards users of LLVM? Then anything will be okay.
- Help corporations that need compiler backends? Then even an 
LLVM-specific patent pool would work.
- Be redistributable with, say, Debian? Then it needs to be 
DFSG-compatible - which seems scary but Debian's policy seems to ignore 
patents but drop the affected patents as soon as somebody starts 
enforcing them.

There's the additional option of a reciprocal clause. I.e. the LLVM 
redistribution license ends as soon as a patent that's used in LLVM is 
getting enforced.
This might actually be attractive for corporate lawyers: they don't need 
to decide whether granting a patent to the public is worth the LLVM 
improvement, they can make that decision at a point in the future.

A milder form of reciprocality might be that the corporate entity can 
revoke the patent but must explicitly name the affected code.

The problem with all these is that they're far into 
make-your-own-license land.
> To be clear, I'd really like to see a solution that will unblock
> contributions from these potential contributors, however, I think we
> need to better understand their concerns and the ramifications of the
> wording we propose to adopt.
Maybe that's really the best course of action.
Find out what the actual problems are, then decide which of these can be 
addressed without changing the project goals, then choose appropriate 
language.
Right now, there's insufficient data for an informed opinion, let alone 
an informed decision.

Hi,

Regarding the previously voiced concerns of incompatibilities between  
the Apache and GPLv2 license, I'd like to add one more thing.

I work on a, at this time mostly LLVM-unrelated [1], "GPLv2 or later"
licensed compiler: the Free Pascal Compiler. Some people in the  
project are vehemently opposed to the GPLv3, so a move of our project  
to that license would not be easy (even if legally perfectly possible).

The reason I care about the LLVM license is that I regularly consult  
the Clang source code to find out things that are not documented  
anywhere else. In particular:
a) layout details of Objective-C class/category/interface metadata
b) OS X compilation details, e.g. for which versions of (Mac) OS X and  
iOS do you have to link in which, if any, crt*.o file

Not being able to use the Clang source code anymore as a reference  
point for this kind of information would be a big loss to me. Apple  
just documenting all of this would be equally fine by me, of course,  
but I don't see that happening.


Jonas

[1] I'm working on an LLVM IR code generator to co-exist with our  
other code generators, but we'll likely never link to LLVM itself to  
ease deployment (different versions of LLVM will be handled in the  
compiler like different architecture versions of actual CPUs).

On 29 October 2015 at 10:25, Jonas Maebe via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Hi,
>
> Regarding the previously voiced concerns of incompatibilities between the
> Apache and GPLv2 license, I'd like to add one more thing.
>
> I work on a, at this time mostly LLVM-unrelated [1], "GPLv2 or
later"
> licensed compiler: the Free Pascal Compiler. Some people in the project are
> vehemently opposed to the GPLv3, so a move of our project to that license
> would not be easy (even if legally perfectly possible).
>
> The reason I care about the LLVM license is that I regularly consult the
> Clang source code to find out things that are not documented anywhere else.
> In particular:
> a) layout details of Objective-C class/category/interface metadata
> b) OS X compilation details, e.g. for which versions of (Mac) OS X and iOS
> do you have to link in which, if any, crt*.o file
>
> Not being able to use the Clang source code anymore as a reference point
for
> this kind of information would be a big loss to me. Apple just documenting
> all of this would be equally fine by me, of course, but I don't see
that
> happening.
(Disclaimer: I am not a lawyer).

Copyright protects creative expression rather than ideas or facts
(although some jurisdictions do have a copyright-like idea of
'database rights'
https://en.wikipedia.org/wiki/Sui_generis_database_right). Referring
to Clang source to ascertain certain facts wouldn't necessarily put
any requirement on the licensing of the code you later produce.
However for safety many might prefer not to look at the source so that
any incidental similarities can't be accused of being due to copying
code directly. If you're worried about this, asking a community member
to use the Clang source to write a short document on the details you
require might be a way forward.

Alex