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

[Joachim Durchholz via llvm-dev]

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.