www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <ch...@christopherschultz.net>
Subject Re: Apache 2.0 License with LLVM Exceptions
Date Thu, 07 Nov 2019 15:25:07 GMT
Bill,

On 11/7/19 10:04, William A Rowe Jr wrote:
> First off, interesting news of yet another successful external project 
> (one used by many developers at the ASF) who have migrated to the 
> Apache License; http://llvm.org/docs/DeveloperPolicy.html#relicensing 
> 
> What I found interesting are their two additional clauses to purportedly 
> make a "more" open flavor of the AL 2.0? I'd be interested in the thoughts
> of our licensing and legal minds as to the usefulness and practicality.
> Note I don't see the ASF releasing software itself with such exceptions.
> 
> And kudos to the LLVM community for clearly not calling their exceptions
> an Apache License.
> 
> ---- LLVM Exceptions to the Apache 2.0 License ----
> 
> As an exception, if, as a result of your compiling your source code,
> portions
> of this Software are embedded into an Object form of such source code, you
> may redistribute such embedded portions in such Object form without
> complying
> with the conditions of Sections 4(a), 4(b) and 4(d) of the License.
> 
> In addition, if you combine or link compiled forms of this Software with
> software that is licensed under the GPLv2 ("Combined Software") and if a
> court of competent jurisdiction determines that the patent provision
> (Section
> 3), the indemnity provision (Section 9) or other Section of the License
> conflicts with the conditions of the GPLv2, you may retroactively and
> prospectively choose to deem waived or otherwise exclude such Section(s) of
> the License, but only in their entirety and only with respect to the
> Combined
> Software.

+1 to the kudos, here.

IANAL, but I would expect that the LLVM folks have applied the following
logic:

1. LLVM is a compiler (well...)
2. Compilers take input and produce output which is executable
3. That generated code is necessarily ... part of the compiler itself
4. Therefore, output of the compiler is ... partially the compiler
itself (at least as far as licensing is concerned)

Ergo, the exception that object code is essentially freed of the
requirements of the compiler's license (e.g. LICENSE file, etc.).

This isn't code that just runs ephemerally like httpd, OpenOffice, or
Tika. Projects which generate files like PDF, Office docs, etc. are
working with file types which are covered under other licenses e.g. MS,
Adobe, OpenDocument/OSASIS, public-domain (e.g. plain-text, CSV) and so on.

If Apache OpenOffice defined its own document format, it would have to
license the file format in some way to users, and it wouldn't be
practical to require one of the following:

a. Every ApacheOpenOfficeDocument file shall contain a copy of the AL2
license (text).
b. Every ApacheOpenOfficeDocument file shall be accompanied by a copy of
the AL2 license (file).

So I see a parallel with what LLVM has done. They are essentially
claiming -- or, more strongly, PROMISING -- that the output of their
compiler (which contains "parts" of the compiler) are necessarily freed
from the license of the compiler itself.

This really makes me (re)consider the Java compiler. It's a piece of
code with a license (OpenJDK=GPL) and it produces .class files which are
specific to the Java Virtual Machine. I can't find a license anywhere
for bytecode, but presumably Sun/Oracle have it under some license. They
would have sued Google for appropriating JVM bytecode had it not been a
permissive license. The runtime API is another matter, but LLVM
(usually) produces standalone binaries, not something that gets run in a
licensed-runtime like Java.

-chris


Mime
View raw message