www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com.INVALID>
Subject Re: Apache 2.0 License with LLVM Exceptions
Date Thu, 07 Nov 2019 18:01:47 GMT
Interesting question.  I thought it was established that tool output was not licensed by the
tool's license, but I can't find that in Google right now, and GCC/GNU took the time to create
an exception to make it more explicit:  https://www.gnu.org/licenses/gcc-exception-3.1.html

If I use MS Word to write a document, the document is not under MS's license, but maybe that
is explicitly called out in their EULA.  Same for Adobe Acrobat and PDF files.

Apache Flex and Royale have compilers.  I don't recall any explicit exception in Adobe's EULA
for Flex.   So if it turns out tool output needs explicit exceptions then we might need them
for Flex and Royale.  It could be that I've always thought of compiled output as a translation
(In fact, Royale's compiler 'transpiles' from ActionScript to JavaScript, so not a binary
output), and AIUI, translations are copyright the original owner.


´╗┐On 11/7/19, 7:25 AM, "Christopher Schultz" <chris@christopherschultz.net> wrote:

    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
    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.

View raw message