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 19:48:52 GMT
Alex,

On 11/7/19 13:21, Alex Harui wrote:
> You could certainly be right.  I'm not sure what part of a LLVM
> compiler gets added to the output.

This would be for any compiler.

For example, if you have this C source:

  int i;
  char *s = (char*)malloc(10 * (sizeof char));

  for(i=0; i<10; ++i)
    *(s+i) = '0' + i;

Perhaps the compiler will unroll that loop and produce the machine code
equivalent of :

  s[0] = '0';
  s[1] = '1';
  s[2] = '2';
  .. and so on.

This is essentially a code template which gets dumped into the output of
the compiler. There are many such kinds of code templates. You can use a
binary analyzer to determine which compiler generated the binary, and
often determine which *version* of the compiler generated it.

That is, you can tell the difference between binaries generated by LLVM
versus GCC versus some other compiler given the exact same source. That
implies that each compiler has something of its own fingerprints on the
output. There is more than one way to skin a cat.

Those fingerprints could be considered a part of the compiler itself.

Also consider static linking and a compiler-provided standard C library.
Someone had to write malloc for your target architecture. If the OS
isn't providing a dynamically-linked library for stdlib, then the
compiler is providing it. Not everything that goes into your binary
comes from the code you fed into the compiler.

> I think GCC has that exception not because compiler source/bytecode
> gets added but because GNU-licensed compiler library code gets added
> to the output.
I think we are saying the same things, here (eg static linking).

> Apache Flex and Royale have library code whose source is part of the
> release that gets added to the output as well.  So if GCC/GNU really
> need an explicit exception, Flex and Royale might need it too.
While it may be true that Flex and Royale should address this, I don't
believe those projects need to be released under an "altered license".
It just needs to be clear that the artifacts produced by the
AL2-licensed software do not also carry that license along with them.

-chris

> ´╗┐On 11/7/19, 10:06 AM, "Sean Owen" <srowen@gmail.com> wrote:
> 
>     (IIUC, the issue isn't tool output per se, which doesn't seem like it
>     would ever be covered by an OSS license, but output that includes part
>     of the tool itself, whose redistribution is governed by OSS licenses.)
>     
>     On Thu, Nov 7, 2019 at 12:02 PM Alex Harui <aharui@adobe.com.invalid> wrote:
>     >
>     > 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://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.gnu.org%2Flicenses%2Fgcc-exception-3.1.html&amp;data=02%7C01%7Caharui%40adobe.com%7Cfbad591a181549d3153208d763ad4730%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C1%7C637087468182010919&amp;sdata=qidLbQ9Gg%2FOjQ76nGVBd1iQoLJy10grSF45NULgnB40%3D&amp;reserved=0
>     >
>     > 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.
>     >
>     > -Alex
>     >
>     
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>     For additional commands, e-mail: legal-discuss-help@apache.org
>     
>     
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org
> 


Mime
View raw message