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

Wed Oct 21 05:52:26 PDT 2015

Hi David,

> - Contributor A submits something that infringes a patent owned by A...

I think the proposal also addresses this case (the first one in your email).
I believe several companies have some sort of process to ensure this does not happen (clean room, training, peer review, legal review, ...), but the risk will never be zero. And the more contributors a company has / the more contributions a company makes will only make the risk become a fact ... after some time. This proposal  really acts as a risk containment: if company A erroneously contributed in this case, then company A is protected (only the necessarily infringed patents are affected) as well as the users of this contribution. Beside, this protection would be made clearly in the license file in the source tree, not in a separate web page.

I think there is some merit in having all the legal blurb in a single place within the source tree as well as attempting some clarification on the patent subject. I personally see this as a step in the right direction.

Kind regards,
--
Arnaud

> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of David
> Chisnall via llvm-dev
> Sent: 21 October 2015 11:10
> To: Chris Lattner
> Cc: llvm-dev
> Subject: Re: [llvm-dev] RFC: Improving license & patent issues in the LLVM
> community
> 
> On 21 Oct 2015, at 06:12, Chris Lattner <clattner at apple.com> wrote:
> >
> > - 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.
> 
> The other alternative would be a separate patent license (Google’s VP8 is the
> most high-profile project that I’m aware of to use this model), so the
> copyright license and the patent license are orthogonal.
> 
> > 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?
> 
> I don’t think that anyone objects to the patent protection, it’s the complexity
> of the license and its reduced ability to compose with other licenses,
> combined with the perceived lack of real benefit, that people seem to object
> to (note: most of the opinions here I’m relaying from other FreeBSD
> developers - I have no strong feelings either way on the Apache 2 license.
> We use a modified[1] version of it at work).  If I write BSDL (or MITL, or
> UIUCL) code, then I know that I can use it in every single place where I may
> wish to use it.  This is less true with ASL2.
> 
> In particular, though the number of GPLv2-only projects is small, there are
> still a lot of GPLv2 or later projects.  I can accept GPLv2, modify them in a way
> that incorporates LLVM today and redistribute the result, and not at any
> point have accepted GPLv3.  If I modify them to adopt ASL2 code and
> redistribute the result then I am accepting GPLv3, and I share your
> employer’s reluctance to do this.  This *has* blocked me from using CLucene
> in a project that incorporated GPLv2 code in the past, so I don’t consider it to
> be much of a stretch to imagine that I’d encounter similar reservations with
> regard to an ASL2 LLVM.
> 
> From the FreeBSD perspective (note: this is my informed opinion as a
> member of the the Core Team, but should not be construed as official
> project policy): With a license change, LLVM would still be our best option for
> the default toolchain and a few other things.    The main difference that
> you’re likely so see is that the growing number of people who work on both
> LLVM and FreeBSD would shrink.  I think that this would be bad for FreeBSD,
> as the overlap in contributors to both projects has been a significant benefit
> for us.
> 
> Neither ASL2 nor the contributors’ agreement (which would be my preferred
> choice) protect against what I regard as the largest patent threat: code
> contributed by one entity that infringes the patent owned by another entity.
> The vast majority of patent problems that open source projects have had in
> the past have been of this form, typically with NPEs.  No license or CLA
> (unless it tries to attach a requirement that the contributor indemnify the
> project, which would basically kill contributions from individuals) can protect
> against this.  I think that we have three possible cases:
> 
> - Contributor A submits something that infringes a patent owned by A.  Even
> if this is not covered by estoppel, in the US at least, you can’t claim damages
> that occurred between being aware of the infringement and sending the
> C&D notice.  It’s hard to argue that you weren’t aware that code that you
> contributed infringed a patent that you owned convincingly, so this case
> would be handled by reverting the patch on receiving the C&D and kicking
> contributor A out of the project.
> 
> - Contributor A submits something that infringes a patent owned by NPE B.
> In this case, no license or CLA will help.  Anyone who has distributed LLVM is
> a target for a lawsuit and it’s very messy and annoying, but not addressed by
> ASL2 or a CLA.
> 
> - Contributor A submits something that infringes a patent owned by
> contributor B.  The terms of the ASL2 are a bit interesting there. To take a
> hypothetical example, if IBM has some code in LLVM (I think that have quite
> a bit in the PowerPC back end now) and I decide to implement RCU with all of
> the go-faster stripes that are still patented in libSupport, then they can sue
> me, but in doing so they would immediately lose the rights to any other
> patents that entities own in LLVM, so now I have neatly sidestepped their
> [L]GPL-only patent grant for these.  This isn’t totally hypothetical, by the way:
> there are some folks in your employer’s CoreOS team who would be very
> happy to see this happen...
> 
> It seems as if the proposed change only protects us from the last case, by
> providing an explicit termination clause.  A separate patent license that
> contained a similar termination clause would have a similar outcome.  It
> would also be easier to deploy, as the only people who would need to agree
> to it retroactively are those that own any patents, which I believe is a fairly
> small subset of LLVM contributors.  Even then, the choice between allowing
> third parties to contribute code that infringes your patents, or losing the
> rights to distribute an important piece of software for your product, is what
> made a lot of companies unwilling to adopt GPLv3, so I’d imagine some push-
> back.
> 
> David
> 
> [1] The Apache *Software* License is a software license, so needed
> extending to explicitly cover the things that we were licensing.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev