[llvm-dev] RFC: Improving license & patent issues in the LLVM community
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Wed Oct 21 08:19:06 PDT 2015
----- Original Message -----
> From: "Joachim Durchholz via llvm-dev" <llvm-dev at lists.llvm.org>
> To: llvm-dev at lists.llvm.org
> Sent: Wednesday, October 21, 2015 9:58:24 AM
> Subject: Re: [llvm-dev] RFC: Improving license & patent issues in the LLVM community
> 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,
> I think it's largely orthogonal to the question whether the code is
To be clear, I meant "job security" in a figurative sense: security for LLVM within the space of software projects. The analogy is apt, to adapt your wording, because it might be the only piece of (open-source) software that can handle (use) a specific patented technique.
> Allowing patented code into LLVM makes LLVM more powerful, but it
> makes it harder to take LLVM code away into other projects (the
> 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
> ecosystem as a whole at all.
I feel that we must be interested, if only out of enlightened self interest. Wait long enough, and we suffer from the same fate as the ecosystem itself. Specifically under the licensing scheme, wait long enough, and we'll want to completely rewrite some component or other, and will the implicit patent license granted by contributors to the old version automatically apply to the new version? The answer might unfortunately be no.
As you point out below, eventually patents to expire, but the timescale of software may be shorter. 15, 17, etc. years is a long time.
> 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
> patents involved. Forces patent holders into a judgement call about
> whether the patent is worth the hassle of maintaining a patch set
> the patent expires - from an "improve the FOSS ecosystem"
> that's actually a Good Thing because it might liberate some patents.
> - Make an open-source compiler backend, don't make any patent
> 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
> 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
> getting enforced.
> This might actually be attractive for corporate lawyers: they don't
> 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
> addressed without changing the project goals, then choose appropriate
> Right now, there's insufficient data for an informed opinion, let
> an informed decision.
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory
More information about the llvm-dev