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

Hello everyone,

This email is a continuation of a discussion from almost a year ago, started back here:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html

As described in that email, 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, and the LLVM Foundation hired Heather Meeker (a prominent OSS licensing attorney) to represent the interests of the LLVM Community. This proposal incorporates all of their feedback, and Heather has further refined and approved this approach.

The goals of this effort are outlined in the previous 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.

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

The email from last year proposed relicensing the LLVM project under the Apache 2 License, and using a runtime exception clause to avoid the binary attribute requirement of the Apache 2 license. The advantage of this approach is that it avoided developing an entirely novel license (which would introduce problems outlined in the original email), it keeps the liberal nature of the LLVM license (you can take and use it for lots of different kinds of projects without being required to publish your downstream code), it does not require a “contributor license agreement” (CLA) which would introduce a higher barrier of entry and increase uncertainty for contributors, and it solves the compiler/runtime library schism by allowing us to license everything uniformly under the same license.

After extensive discussion on the mailing list (see the archives if you missed it), the community generally agreed with the approach, but had a major concern: Many folks believe the Apache 2 license to be incompatible with the GPLv2 license. This is problem because there are a number of important GPLv2 projects that use LLVM (e.g. QEMU) or projects that are "GPLv2 or later” but which prefer to be used under the terms of the GPLv2 license (e.g. FreePascal). This strong voice inspired us to go back and look for ways to solve this problem.

This problem really is specific to GPLv2 (it doesn’t affect any other commonly used licenses), but it turns out that this is a surprisingly difficult problem to solve. For example, many prominent open source lawyers consider the GPLv2 and Apache 2 licenses to be compatible already, which means that there is no problem to solve. The problem for us as a community is that this issue hasn’t been tested in court, and there are other lawyers that believe that the two could be considered incompatible. As such, we recommend taking a pragmatic and conservative approach that defends against incompatibility if it eventually arises, instead of optimistically assuming that they are compatible.

After extensive discussion involving many lawyers with different affiliations, we recommend taking the approach of using the Apache 2.0 license, with the binary attribution exception (discussed before), and add an additional exception to handle the situation of GPL2 compatibility if it ever arises. Specifically, this is the proposed wording:

---- Exceptions to the Apache 2.0 License: ——

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.

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

The first paragraph is the exact same one proposed in the previous discussion (addressing the compiler / runtime schism), and the second addresses the GPLv2 concerns. It is structured the way it is for a number of reasons:

- We want to conservatively protect the community if the licenses are found to be incompatible.
- The LLVM community should not take a position on whether the licenses are compatible or not.
- We want to make it clear that the exception only applies if you’re using GPL2 code: if not, you can ignore it.
- Allowing retroactive waiving makes it unlikely that an LLVM user could be expected to pay damages (if the two licenses are ever found to be incompatible).

In the process of discussing this issue, we considered many different approaches, and I believe that this is the best approach: it provides the compatibility and protection that we seek, and Heather Meeker (legal representative for the LLVM Foundation) has contributed to and approved its wording.

With that as background I’d love to hear what the rest of you think: do you have any concerns? If you are yourself a lawyer or work for a company with them, does your legal counsel have any concerns? If you’d prefer not to discuss this on a public mailing list, feel free to email me personally.

Once we reach an agreement on the path to take, we can start talking about logistics of how to get there.

Thank you!

-Chris

Hi Chris,

---- Exceptions to the Apache 2.0 License: ——

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.

[...]

---- end ---

Just to make sure I get this straight, I can substitute 'this
Software' by the names of components provided by the LLVM project. For
example:

As an exception, if you use LLVM, Clang and/or DragonEgg to compile your source code and portions of compiler-rt, libc++, libc++abi and/or libunwind 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've got a couple of questions about this.

- Now that we're also in the business of providing other kinds of
tools that are not compilers (e.g., LLD being a linker), are we sure
that this will cover all of our needs?

- What about derived software? Would this also apply if I'd be using
the Swift compiler to generate an executable that contains some bits
from compiler-rt? What if I'd be using GCC, but added a tiny fraction
of LLVM's source code to it? What about a stock version of GCC that is
linked against compiler-rt?

Sorry if some of these questions may seem hypothetical or silly; I'm
merely interested in knowing where the boundary is and how this
licensing exception will work in practice.

Best regards,

---- end ---

Just to make sure I get this straight, I can substitute 'this
Software' by the names of components provided by the LLVM project.

This is the literal license text that will be included with each of these projects, so no, you cannot literally make that substitution.

However, yes, this will cover all parts of the LLVM project including LLVM, Clang, LLDB, libc++ etc if that’s what you’re asking.

For
example:

As an exception, if you use LLVM, Clang and/or DragonEgg to compile your source code and portions of compiler-rt, libc++, libc++abi and/or libunwind 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.

The license specifically does not make a distinction between LLVM/clang and libc++/compiler-rt. You should be able to embed LLVM or clang code into a binary without having to provide attribution.

I've got a couple of questions about this.

- Now that we're also in the business of providing other kinds of
tools that are not compilers (e.g., LLD being a linker), are we sure
that this will cover all of our needs?

Yes, I don’t see anything functionally or use-case different between LLD and Clang or LLDB.

- What about derived software?

You need to specify what you mean by derived, I’ll answer the specific questions below to the best of my knowledge. However, it would be great for someone like DannyB to confirm this.

Would this also apply if I'd be using
the Swift compiler to generate an executable that contains some bits
from compiler-rt?

Yes, the runtime exception clause covers the code being embedded (compiler-rt) not relating to how it got embedded.

FWIW, Swift already uses the Apache 2 license with the runtime exception clause, but that isn’t important for the question.

What if I'd be using GCC, but added a tiny fraction
of LLVM's source code to it? What about a stock version of GCC that is
linked against compiler-rt?

Both are fine, the compiler-rt code is covered regardless of how it gets embedded. You could use a fully proprietary compiler like Intel’s ICC and that would also be fine.

Sorry if some of these questions may seem hypothetical or silly; I'm
merely interested in knowing where the boundary is and how this
licensing exception will work in practice.

No problem at all,

-Chris

> - What about derived software?

You need to specify what you mean by derived, I’ll answer the specific
questions below to the best of my knowledge. However, it would be great
for someone like DannyB to confirm this.

Happy to try to give you specific answers if you have specific questions

Hi Chris,

You could use a fully proprietary compiler like Intel’s ICC and that would also be fine.

Got it. That's good to hear. What got me on the wrong track is the following:

As an exception, if you use this Software to compile your source code [...]

I interpreted this as if 'this Software' has an active role, namely
that it has to be the compiler itself. If I read your response
correctly, this doesn't need to be the case. Any piece of software can
be used for that purpose. It would have been a lot more clear for me
if it said:

As an exception, if this Software is compiled and/or linked together with your source code [...]

But I am not a laywer. :slight_smile:

Ah, I see what you’re saying. Let me chat with a few folks and get back to you, thank you for pointing this out!

-Chris

Looks great to me, thanks a lot for taking our (and others') concerns into consideration!

Jonas
(Free Pascal Compiler developer; just got back from holidays and catching up with LLVM mails)

Hi Chris,
let me go back to this with some of the thoughts from the last Berlin
Social. Ignoring the question of what license to choose, I see three
different components mangled together:

(1) Coherent licensing between "build time" and "run time" components.
This part does need a license change one way or another.

(2) LLVM contributors grant permissions to use their patents as far as
necessary for their contributions. The desirability of this is
unquestionable either.

(3) Revocation of copyright and patent use permissions in case of
litigation. I think this is the part about a potential move to APSL2
that is most highly contented.

I want to make sure that those are the goals used to justify a
(potential) license change.

I still stand by my position that (2) isn't served alone by the APSL,
since it isn't clear who the contributing entity is. A click-thru CLA
for individual contributors would server the purpose for those, IMO.
For non-natural legal entities as contributors, I still maintain my
position that at least under German law a proper legal agreement is
necessary to ensure that any obligations are actually enforceable.

Joerg

The goals of this effort are outlined in the previous 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.

Hi Chris,
let me go back to this with some of the thoughts from the last Berlin
Social.

Thanks! FWIW, if you or anyone else is going to be at the LLVM Dev Meeting and are interested in relicensing, then please come to the LLVM Foundation BoF. I’ll give an update there, and it’s a great place for general questions and discussion.

Ignoring the question of what license to choose, I see three
different components mangled together:

(1) Coherent licensing between "build time" and "run time" components.
This part does need a license change one way or another.

Right.

(2) LLVM contributors grant permissions to use their patents as far as
necessary for their contributions. The desirability of this is
unquestionable either.

I’m not sure what you mean by "unquestionable either”. Do you mean "unquestionable good”?

If we don’t achieve this, then we run the heightened risk of someone being sued for using LLVM. This isn’t good for the community.

(3) Revocation of copyright and patent use permissions in case of
litigation. I think this is the part about a potential move to APSL2
that is most highly contented.

That isn’t my impression. Everyone that I have spoken to is in favor of the patent termination clauses (including the FSF: Various Licenses and Comments about Them - GNU Project - Free Software Foundation).

The only complexity I’ve heard is that it introduces is a potential compatibility issue with GPL2 (GPL3 and other licenses are fine), which is addressed by the exception clause.

I want to make sure that those are the goals used to justify a
(potential) license change.

There are additional goals. Our current structure is broken in various ways (which I don’t want to enumerate in public), including potential legal issues with patches that come in from people who do not have commit access. If we don’t address these issues, then (in my personal opinion) it would be irresponsible to allow pull requests (assuming LLVM moves to github, which is still up in the air of course).

I still stand by my position that (2) isn't served alone by the APSL,
since it isn't clear who the contributing entity is. A click-thru CLA
for individual contributors would server the purpose for those, IMO.

A CLA was carefully considered and has numerous problems depending on which one you’re talking about. The most common proposal is to use an Apache CLA (aka Google CLA), which introduces several problems we discussed in the relicensing round a year ago: it increases the barrier to entry to contribution, makes it “too easy” to relicense the code later, etc.

For non-natural legal entities as contributors, I still maintain my
position that at least under German law a proper legal agreement is
necessary to ensure that any obligations are actually enforceable.

I’m not sure what you’re suggesting here.

-Chris

The goals of this effort are outlined in the previous 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.

Hi Chris,
let me go back to this with some of the thoughts from the last Berlin
Social.

Thanks! FWIW, if you or anyone else is going to be at the LLVM Dev Meeting and are interested in relicensing, then please come to the LLVM Foundation BoF. I’ll give an update there, and it’s a great place for general questions and discussion.

Ignoring the question of what license to choose, I see three
different components mangled together:

(1) Coherent licensing between "build time" and "run time" components.
This part does need a license change one way or another.

Right.

(2) LLVM contributors grant permissions to use their patents as far as
necessary for their contributions. The desirability of this is
unquestionable either.

I’m not sure what you mean by "unquestionable either”. Do you mean "unquestionable good”?

If we don’t achieve this, then we run the heightened risk of someone being sued for using LLVM. This isn’t good for the community.

I’m still not completely convinced by this argument, given that the majority of patent lawsuits come from NPEs. We’d still be in the situation where a malicious contributor could:

1. Spin up a new company to act as a NPE
2. Transfer ownership of the relevant patent(s) to the NPE
3. Contribute code to LLVM that infringes the patent, safely abiding by the terms that they’re licensing all of the patents that they own.
4. Watch the NPE sue everyone and laugh.

The Apache 2 License does nothing to prevent this, though Clause 5 of the Apache CLA would prevent it. Even the CLA wouldn’t protect anyone against being sued by dubious patents filed by NPEs that were accidentally infringed, which seems to be by far the biggest patent threat to any open source project.

(3) Revocation of copyright and patent use permissions in case of
litigation. I think this is the part about a potential move to APSL2
that is most highly contented.

That isn’t my impression. Everyone that I have spoken to is in favor of the patent termination clauses (including the FSF: Various Licenses and Comments about Them - GNU Project - Free Software Foundation).

The only complexity I’ve heard is that it introduces is a potential compatibility issue with GPL2 (GPL3 and other licenses are fine), which is addressed by the exception clause.

I’m surprised that all of the companies are happy with it, given that neutering defensive patents was one of the big objections we saw to GPLv3. In particular, various corporate lawyers were worried about this scenario that neuters defensive patents):

1. Company A adopts project X
2. X becomes an important part of A’s product line
3. Company B (competitor to A) contributes code infringing A’s patents to X
4. Company B sues A for infringement of another (unrelated) patent
5. Company A can’t use their patent to countersue without losing the ability to distribute X

I want to make sure that those are the goals used to justify a
(potential) license change.

There are additional goals. Our current structure is broken in various ways (which I don’t want to enumerate in public), including potential legal issues with patches that come in from people who do not have commit access. If we don’t address these issues, then (in my personal opinion) it would be irresponsible to allow pull requests (assuming LLVM moves to github, which is still up in the air of course).

I disagree. The GitHub CLA covers all pull requests and currently gives us far more protection than any other mechanism that we have for receiving patches.

I still stand by my position that (2) isn't served alone by the APSL,
since it isn't clear who the contributing entity is. A click-thru CLA
for individual contributors would server the purpose for those, IMO.

A CLA was carefully considered and has numerous problems depending on which one you’re talking about. The most common proposal is to use an Apache CLA (aka Google CLA), which introduces several problems we discussed in the relicensing round a year ago: it increases the barrier to entry to contribution, makes it “too easy” to relicense the code later, etc.

It would perhaps have been helpful for these to have been more widely enumerated. There seemed to be a lot more support both in the thread and in offline discussions for a CLA than for relicensing, yet there’s subsequently been a big push for relicensing and no discussion of a CLA.

I don’t have strong objections to the Apache 2 license, but I don’t like the precedent that we’d be setting by relicensing under a less permissive license. I was happy to give permission for code that I’d contributed to be relicensed under the MIT license for inclusion in libc++, but a move in the opposite direction seems harder to accept.

I’m also not completely convinced that the exemption to 4.d actually does what we’d need with respect to libc++. In FreeBSD, we compile most packages with clang, but a few with gcc (and all with gcc on a couple of architectures). We use libc++ for all C++ code, irrespective of how it was compiled. When we are not compiling with clang[1], we’d still be covered by 4.d and so every package that uses C++ (a few thousand) would need to include the attribution. Updating all of this and ensuring compliance would probably block us from updating libc++ for about a year after the license switch. At the very least, I think this exemption needs a lot more explicit clarification. Please compare the runtime exemption to the GPLv3 - you’ll note that it’s a lot longer, for good reason.

David

> Hi Chris,
> let me go back to this with some of the thoughts from the last Berlin
> Social.

Thanks! FWIW, if you or anyone else is going to be at the LLVM Dev
Meeting and are interested in relicensing, then please come to the LLVM
Foundation BoF. I’ll give an update there, and it’s a great place for
general questions and discussion.

Wrong continent for me.

> (2) LLVM contributors grant permissions to use their patents as far as
> necessary for their contributions. The desirability of this is
> unquestionable either.

I’m not sure what you mean by "unquestionable either”. Do you mean "unquestionable good”?

This is what we are trying to do already and something we want to keep
doing.

[snip of parts covered already by David]

> For non-natural legal entities as contributors, I still maintain my
> position that at least under German law a proper legal agreement is
> necessary to ensure that any obligations are actually enforceable.

I’m not sure what you’re suggesting here.

We still need to keep track of what legal entity is doing the
contribution. The easiest case is a lone programmer -- let him/her say so
once and the problem is solved until he/she gets employed and changes
his/her status.

For corporate entries as contributor it is somewhat more involved. I
don't know what form of authorisation lawyers on both sides are happy
with. It can be as simple as a company like Google or Apple signing
paper work once that they agree to the patent use and that all
contributions from a @google.com or @apple.com address are fine. They
might want to keep track of permitted individuals, I don't know.

Assuming the Github moves happens, it could be tight to the github
IDs. I know some projects are already using automated checks for pull
requests for proof of origin. It can be a bit work for people with
multiple github accounts, but that's a different issue.

Joerg

I’m still not completely convinced by this argument, given that the
majority of patent lawsuits come from NPEs.

That is not necessarily where the majority of patent lawsuit *danger* comes
from, and i'd argue, pretty strongly, it's not the most likely case for
LLVM.

  We’d still be in the situation where a malicious contributor could:

1. Spin up a new company to act as a NPE
2. Transfer ownership of the relevant patent(s) to the NPE
3. Contribute code to LLVM that infringes the patent, safely abiding by
the terms that they’re licensing all of the patents that they own.
4. Watch the NPE sue everyone and laugh.

There are literally attempts at loopholes one could play with literally
every legal scenario ever, no matter what is done.
I'll go further:
It's literally not possible to have a GPL compatible license and avoid some
of these loopholes.
That is the price we pay

The Apache 2 License does nothing to prevent this, though Clause 5 of the
Apache CLA would prevent it.

Actually, it does not.
The Apache CLA does not, in any way, shape, or form, prevent this issue.
Trust me, i answer questions about the CLA pretty much every day.

Even the CLA wouldn’t protect anyone against being sued by dubious patents
filed by NPEs that were accidentally infringed, which seems to be by far
the biggest patent threat to any open source project.

Based on what data?
This is, IMHO, simply not correct in an open source project that involves
cooperation among a large set of competitors.
Additionally, the ability for NPEs to affect a space like compilers is
small, because of the wide variety of algorithm choice, etc.

NPEs choose spaces where they can cover the field. Compilers are also old,
have very well documented histories (GCC has source code going back to
1983), and most things that happen get published.

All of which makes it not a great target for NPEs.

>> (3) Revocation of copyright and patent use permissions in case of
>> litigation. I think this is the part about a potential move to APSL2
>> that is most highly contented.
>
> That isn’t my impression. Everyone that I have spoken to is in favor of
the patent termination clauses (including the FSF:
Various Licenses and Comments about Them - GNU Project - Free Software Foundation).
>
> The only complexity I’ve heard is that it introduces is a potential
compatibility issue with GPL2 (GPL3 and other licenses are fine), which is
addressed by the exception clause.

This is correct.

I’m surprised that all of the companies are happy with it, given that
neutering defensive patents was one of the big objections we saw to GPLv3.

In particular, various corporate lawyers were worried about this scenario
that neuters defensive patents):

Lawyers see risk everywhere, so i'll just go with "various corporate
lawyers are concerned about everything, ever".
Clearly, for the majority, the prediction that those concerns would not
outweigh the desire to use the software came true.

>> I want to make sure that those are the goals used to justify a
>> (potential) license change.
>
> There are additional goals. Our current structure is broken in various
ways (which I don’t want to enumerate in public), including potential legal
issues with patches that come in from people who do not have commit
access. If we don’t address these issues, then (in my personal opinion) it
would be irresponsible to allow pull requests (assuming LLVM moves to
github, which is still up in the air of course).

I disagree. The GitHub CLA

When you say "the github cla", do you mean the modified Apache CLA they
have at cla.github.com?

Because if you are worried about loopholes, you can pretty much drive
trucks through that document because of what they removed (and things like
ripping out the warranty disclaimer make it significantly worse for both
users, and corporations)

Or do you mean something else?

I’m also not completely convinced that the exemption to 4.d actually does
what we’d need with respect to libc++. In FreeBSD, we compile most
packages with clang, but a few with gcc (and all with gcc on a couple of
architectures). We use libc++ for all C++ code, irrespective of how it was
compiled. When we are not compiling with clang[1], we’d still be covered
by 4.d and so every package that uses C++ (a few thousand) would need to
include the attribution. Updating all of this and ensuring compliance
would probably block us from updating libc++ for about a year after the
license switch. At the very least, I think this exemption needs a lot more
explicit clarification.

FWIW, the consensus on the open source legal counsel mailing lists i belong
to, when they saw it (IE on the public mailing lists), was basically that
it looked great and others want to use it.

Not a single person (and the list includes many zealous people of all
kinds) mentioned they believed there were any serious issues achieving it's
goals, or that it needed further clarifications.

Please compare the runtime exemption to the GPLv3 - you’ll note that it’s
a lot longer, for good reason.

Actually, as a guy who helped write it, i'm going to say "no it's not for
good reason" :slight_smile:
Really.

Most of the exception exists to try to define what exactly an IR or plugin
is to the compiler, and it doesn't do an amazing job of doing that because
of non-legal concerns.

It also has significantly surprising effects for people, not achieving that
goal either.

So while it's okay, it's not "better because it's longer" for users, and
the parts that are longer, don't help.

To name an example surprising effect:

If you statically link libstdc++, you have no serious obligations in your
distributed binary.

If you dynamically link libstdc++, you have no serious obligations in your
distributed binary, however, you must abide by the GPLv3 for the shared
libstdc++.so you ship.

(including distribution of source for libstdc++ and installation
information like signing keys necessary to install modified versions of the
.so).

I have yet to meet a corporate counsel or person who is not surprised by
this behavior (but the FSF will happily verify it is correct for you :P)

--Dan

In particular, various corporate lawyers were worried about this scenario that neuters defensive patents):

Lawyers see risk everywhere, so i'll just go with "various corporate lawyers are concerned about everything, ever".
Clearly, for the majority, the prediction that those concerns would not outweigh the desire to use the software came true.

Without a CLA, I don’t see anything in the Apache 2 license that prevents this scenario. If I want to use an Apple or Google patent, is it enough for me to commit some code that infringes it to LLVM and watch them lose their license to distribute LLVM if they try to sue me? If not, what prevents this?

I’m also not completely convinced that the exemption to 4.d actually does what we’d need with respect to libc++. In FreeBSD, we compile most packages with clang, but a few with gcc (and all with gcc on a couple of architectures). We use libc++ for all C++ code, irrespective of how it was compiled. When we are not compiling with clang[1], we’d still be covered by 4.d and so every package that uses C++ (a few thousand) would need to include the attribution. Updating all of this and ensuring compliance would probably block us from updating libc++ for about a year after the license switch. At the very least, I think this exemption needs a lot more explicit clarification.

FWIW, the consensus on the open source legal counsel mailing lists i belong to, when they saw it (IE on the public mailing lists), was basically that it looked great and others want to use it.

Not a single person (and the list includes many zealous people of all kinds) mentioned they believed there were any serious issues achieving it's goals, or that it needed further clarifications.

For clarification: Is my interpretation incorrect? If I compile code with GCC, which uses templates from libc++ headers and therefore results in libc++ code being inserted into the resulting binary, am I required to abide by clause 4 of the Apache license and include the libc++ attribution?

I’m willing to accept that I’m wrong here if you can point out why, but if I’m not then this is going to require that we audit around 30,000 software packages that we distribute, which is going to cause a lot of pain and suffering for us (to the extent that it would probably mean that we’d start actively looking for an alternative to libc++).

David

>> In particular, various corporate lawyers were worried about this
scenario that neuters defensive patents):
> Lawyers see risk everywhere, so i'll just go with "various corporate
lawyers are concerned about everything, ever".
> Clearly, for the majority, the prediction that those concerns would not
outweigh the desire to use the software came true.

Without a CLA, I don’t see anything in the Apache 2 license that prevents
this scenario.

Again, the scope and coverage of the CLA grant is essentially identical to
the license.

If I want to use an Apple or Google patent, is it enough for me to commit
some code that infringes it to LLVM and watch them lose their license to
distribute LLVM if they try to sue me?

No.

First, neither the CLA nor the license terminate all rights, only patent
rights. So the only thing that could happen is *someone else could sue them
for patent infringement*.
So no matter what, they will not have "lost their license to distribute
LLVM". It just may be risky to do so :slight_smile:

  If not, what prevents this?

Because the patent grant is based on the state of the software as of the
time of your contribution.
It's even covered in the Apache license FAQ:
"Q1: If I own a patent and contribute to a Work, and, at the time my
contribution is included in that Work, none of my patent's claims are
subject to Apache's Grant of Patent License, is there a way any of those
claims would later become subject to the Grant of Patent License solely due
to subsequent contributions by other parties who are not licensees of that
patent.
A1:No."
So if i make contribution that does *not* cover patent A (a patent i own)
You add stuff later that would cause users to infringe patent A.
I never contribute again.
That does not grant anyone rights from me to patent A.

The reason this is what occurs is pretty simple.
The wording on which claims are granted is "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."

Clearly, the first part does not apply, because I did not contribute it.
The "work" to which such contributions was submitted is the copyrightable
work of authorship.
That's LLVM, as of the date you contributed it.
Later contributions are not part of the "work" to which you submitted your
contribution, and thus, clearly not covered by the grant.

>> I’m also not completely convinced that the exemption to 4.d actually
does what we’d need with respect to libc++. In FreeBSD, we compile most
packages with clang, but a few with gcc (and all with gcc on a couple of
architectures). We use libc++ for all C++ code, irrespective of how it was
compiled. When we are not compiling with clang[1], we’d still be covered
by 4.d and so every package that uses C++ (a few thousand) would need to
include the attribution. Updating all of this and ensuring compliance
would probably block us from updating libc++ for about a year after the
license switch. At the very least, I think this exemption needs a lot more
explicit clarification.
>
> FWIW, the consensus on the open source legal counsel mailing lists i
belong to, when they saw it (IE on the public mailing lists), was basically
that it looked great and others want to use it.
>
> Not a single person (and the list includes many zealous people of all
kinds) mentioned they believed there were any serious issues achieving it's
goals, or that it needed further clarifications.

For clarification: Is my interpretation incorrect? If I compile code with
GCC, which uses templates from libc++ headers and therefore results in
libc++ code being inserted into the resulting binary, am I required to
abide by clause 4 of the Apache license and include the libc++ attribution?

Yes.
But, AFAIK, this is deliberate. IE the view is that in this case, you
*should* be giving attribution.
So this is at least "not a bug", regardless of whether it's liked or not.

First, neither the CLA nor the license terminate all rights, only patent
rights.

(and before anyone asks, it is not possible to terminate all rights,
including copyright, and remain GPLv2 compatible.
This is the one perennial problems of trying to write gplv2 compatible
licenses)

If not, what prevents this?

Because the patent grant is based on the state of the software as of the time of your contribution.
It's even covered in the Apache license FAQ:
"Q1: If I own a patent and contribute to a Work, and, at the time my contribution is included in that Work, none of my patent's claims are subject to Apache's Grant of Patent License, is there a way any of those claims would later become subject to the Grant of Patent License solely due to subsequent contributions by other parties who are not licensees of that patent.
A1:
No.”

Thanks, that makes sense. I had assumed the termination was closer to GPLv3.

For clarification: Is my interpretation incorrect? If I compile code with GCC, which uses templates from libc++ headers and therefore results in libc++ code being inserted into the resulting binary, am I required to abide by clause 4 of the Apache license and include the libc++ attribution?

Yes.
But, AFAIK, this is deliberate. IE the view is that in this case, you *should* be giving attribution.
So this is at least "not a bug", regardless of whether it's liked or not.

I believe that this would be a show-stopper for FreeBSD’s use of libc++ and compiler-rt. As such, I would strongly oppose this and would not consent to any of my code in libc++ being relicensed under the proposed terms. This would require that we audit all 30K packages, find the ones that will (when we ship binaries) link libc++, and add the attribution in the right places.

Whose view is ’the view'? I and the other libc++ contributors were all happy to have our code relicensed under the MIT license (or contribute it under those terms originally), so there is some pretty clear evidence that we explicitly did *not* require this attribution. Indeed, we relicensed under the MIT license (after long discussion) specifically to avoid this requirement. This seems like a step that is directly contrary to the intentions of the original authors.

David

> For clarification: Is my interpretation incorrect? If I compile code
with GCC, which uses templates from libc++ headers and therefore results in
libc++ code being inserted into the resulting binary, am I required to
abide by clause 4 of the Apache license and include the libc++ attribution?
>
> Yes.
> But, AFAIK, this is deliberate. IE the view is that in this case, you
*should* be giving attribution.
> So this is at least "not a bug", regardless of whether it's liked or not.

I believe that this would be a show-stopper for FreeBSD’s use of libc++
and compiler-rt. As such, I would strongly oppose this and would not
consent to any of my code in libc++ being relicensed under the proposed
terms. This would require that we audit all 30K packages, find the ones
that will (when we ship binaries) link libc++, and add the attribution in
the right places.

Whose view is ’the view'?

The consensus i saw here and elsewhere. I'm happy to be shown to be wrong.

I and the other libc++ contributors were all happy to have our code
relicensed under the MIT license (or contribute it under those terms
originally), so there is some pretty clear evidence that we explicitly did
*not* require this attribution.

That license does, in fact, require attribution:
"The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software. "

Indeed, we relicensed under the MIT license (after long discussion)

specifically to avoid this requirement.

If we did, we screwed it up then. We probably meant the zlib license, which
does not require attribution :wink:

I and the other libc++ contributors were all happy to have our code relicensed under the MIT license (or contribute it under those terms originally), so there is some pretty clear evidence that we explicitly did *not* require this attribution.

That license does, in fact, require attribution:
"The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. “

Again, unless I’m misreading this, there is no requirement that code that merely uses libc++ headers include a libc++ attribution. That was the explicit requirement for the switch to the MIT license. The proposed new license would mean that this is only true for code compiled with LLVM.

We must include the copyright and attribution when we distribute FreeBSD, because we include the whole of libc++. We do not need to separately include it in programs that simply link to libc++ (irrespective of how they were compiled) in packages, because they do not contain ‘substantial portions’ of the code (probably - it’s a bit of a grey area with respect to template-heavy C++).

Indeed, we relicensed under the MIT license (after long discussion) specifically to avoid this requirement.

If we did, we screwed it up then. We probably meant the zlib license, which does not require attribution :wink:

Assuming that your interpretation of this clause - which is the first time I have ever heard it interpreted to include either linking or including headers - is correct. I’d be quite surprised if it were, as the lawyers that reviewed it at the time were happy that it did not impose these constraints, but it’s possible.

David

>
>> I and the other libc++ contributors were all happy to have our code
relicensed under the MIT license (or contribute it under those terms
originally), so there is some pretty clear evidence that we explicitly did
*not* require this attribution.
>
> That license does, in fact, require attribution:
> "The above copyright notice and this permission notice shall be included
in all copies or substantial portions of the Software. “

Again, unless I’m misreading this, there is no requirement that code that
merely uses libc++ headers include a libc++ attribution.

You are misreading this :slight_smile:

I can tell you it's not even a consensus, i have not found a single lawyer
who believes otherwise.

I can forward you the discussion that occurred around this if you like (i
have to acquire permission from the folks involved first). There was 100%
universal agreement on this.

That was the explicit requirement for the switch to the MIT license. The
proposed new license would mean that this is only true for code compiled
with LLVM.

We must include the copyright and attribution when we distribute FreeBSD,
because we include the whole of libc++. We do not need to separately
include it in programs that simply link to libc++ (irrespective of how they
were compiled) in packages, because they do not contain ‘substantial
portions’ of the code (probably - it’s a bit of a grey area with respect to
template-heavy C++).

This is not correct :wink:

>> Indeed, we relicensed under the MIT license (after long discussion)
specifically to avoid this requirement.
>
> If we did, we screwed it up then. We probably meant the zlib license,
which does not require attribution :wink:

Assuming that your interpretation of this clause - which is the first time
I have ever heard it interpreted to include either linking or including
headers - is correct.

This is interesting, as i've said, i've literally never heard it
interpreted otherwise.

I’d be quite surprised if it were, as the lawyers that reviewed it at the
time were happy that it did not impose these constraints, but it’s possible.

Like I said, there was discussion of it on the open source counsel mailing
lists i belong to, and there was universal agreement that it required
attribution.

If your interpretation is correct, then almost every graphical X11 application is infringing the license with respect to libX, the authors of the license were incorrect as to what it does, every project that I’ve been involved with that has used it has adopted it assuming that it means something different, and every lawyer that I’ve spoken to at companies adopting such code has been wrong. This may be the case, but you’ll forgive me if I take your opinion with a grain of salt here.

The LLVM project's intention on moving libc++ and compiler-rt to the MIT license was that no code that simply linked to unmodified versions of these libraries would be required to contain attribution. A quick look on opensource.org points to TL;DRLegal, which concurs with this: you must include the copyright notice in a copy of the library, but you are not required to include any attribution. In fact, a quick skim of similar sites includes the same consensus, so I’m not sure who is on this mailing list that you allude to, but they seem to have some quite different opinions to the normal consensus.

David