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

[Hal Finkel via llvm-dev]

----- Original Message -----
> From: "Chris Lattner via llvm-dev" <llvm-dev at lists.llvm.org>
> To: "llvm-dev" <llvm-dev at lists.llvm.org>
> Sent: Monday, October 19, 2015 10:25:16 AM
> Subject: [llvm-dev] RFC: Improving license & patent issues in the LLVM	community
> 
> Hi Everyone,
> 
> 
...
> 1) Some contributors are actively blocked from contributing code to
> LLVM.
> 
> These contributors have been holding back patches for quite some time
> that they’d like to upstream. The root issue is that the wording in
> the Patent section is fuzzy, novel to LLVM, and overly broad.
> Corporate contributors (in particular) often have patents on many
> different things, and while it is reasonable for them to grant
> access to patents related to LLVM, the wording in the Developer
> Policy can be interpreted to imply that unrelated parts of their IP
> could accidentally be granted to LLVM (through “scope creep”). I
> will not make any claims about whether these fears are founded or
> not, but I will observe that this is a serious and current problem
> for the community.

Can you provide an explicit example of this "score creep", and how the Apache 2 license avoids it? And, furthermore, is avoiding it really a good thing?

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.

The Apache 2 license, section 3 (Grant of Patent License), "... where such license applies only to those patent claims licensable by such Contributor 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." This text seems to swing the "scope creep" pendulum all the way in the other direction, specifically by saying "*was* submitted". This does not seem to make a provision for future growth of the project, let alone uses in combination with third-party code. And, frankly, trying to predict the future directions of the project, as a whole, can be difficult (everything from libFuzzer and an OpenMP runtime to clang-modernize and Clang's static analyzer, not to mention traditional compiler technologies). This seems to imply that a contributor could make a contribution necessarily infringing on their patented algorithm A, but that implied patent license covers only using A in combination with the things LLVM happened to do at the time the contribution was made (and not, necessarily, with any third-party code).

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.

> 
...
>
> 3) The patent coverage provided by the Developer Policy may not
> provide the protection it intends.
> 
...
> 
> 3) We could relicense all of LLVM under the Apache 2.0 license and
> add a runtime exception.
> 
> 
> The Apache 2.0 license is a well known, widely used, and highly
> respected way to define and scope guarantees when it comes to patent
> contribution and coverage. This is the license in question:
> http://www.apache.org/licenses/LICENSE-2.0
> 
> 
> The runtime exception would be a short addendum. For example, it
> could be something like:
> "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."

I assume this still needs some fair amount of wordsmithing. 'compile' might be overly specific, given that we have source-to-source translators (clang-modernize, etc.) that can easily introduce the same problem. 'your' seems ambiguous.

The downside here is that, by adding an exception, we've again created something novel. I agree, however, that adding some kind of runtime exception to all of LLVM is the right direction for the project.

Thanks again,
Hal

> 
> 
...
> 
> Thanks!
> 
> 
> -Chris
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 

-- 
Hal Finkel
Assistant Computational Scientist
Leadership Computing Facility
Argonne National Laboratory