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

Daniel Berlin via llvm-dev llvm-dev at lists.llvm.org
Sun Apr 23 09:18:27 PDT 2017

On Sun, Apr 23, 2017 at 8:50 AM, Mark Kettenis via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More information about the llvm-dev mailing list