[llvm-dev] Runtime library components licensing / MIT License / credit requirements

[Jonas Thiem via llvm-dev]

To explain a bit my motivation behind this e-mail due to the lack of
reactions:

What I am hoping to achieve with this request?

I asked mainly because I would love to hear either more in-depth
explanations why the current MIT licensing of the clang runtime parts
has no such legal implications, or acknowledgment of the issue with some
sort of basic considerations of a potential refinement of the clang
licensing to improve this.

Why do I care in the first place?

I am considering using a clang-compiled executable as a bytecode runtime
for something which other developers use (and which ships with their
self-written programs), and since my own project is zlib/libpng licensed
I currently have zero such license notice requirements. If clang
introduces them, it would complicate things a bit:

It wouldn't be an absolute showstopper of course, but I would feel
compelled to inform those people through various means and write FAQs
about it and all, and it might lead to 1. making the licensing
compliance for the clang-compiled bytecode runtime I am writing more
complicated (compared to "nothing required") 2. a bit of a potential
grey area for people who miss out on this despite FAQ and all since
people are usually aware of lib deps & compliance with that but not
hidden core runtime deps put in by the compiler.

I hope this helps making my questions more interesting and relatable.

Regards,
Jonas Thiem

On 11/25/2017 11:08 AM, Jonas Thiem via llvm-dev wrote:
> Hi,
> 
> I am writing here because the LLVM Developer Policy on licensing as
> found here http://llvm.org/docs/DeveloperPolicy.html#license says that
> questions about the licensing should be sent to this list.
> 
> The LLVM Developer Policy on licensing says the following about runtime
> components compiled into/linked to programs compiled with clang:
> 
> "In addition to the UIUC license, the runtime library components of LLVM
> (compiler_rt, libc++, and libclc) are also licensed under the MIT
> License, which does not contain the binary redistribution clause. [...]
> We feel that this is important for runtime libraries, because they are
> implicitly linked into applications and therefore should not subject
> those applications to the binary redistribution clause."
> 
> This sounds like the idea of picking the MIT license instead of clang's
> regular Illinois licensing is that there shall be no need to have a
> condition similar to the referenced "binary redistribution clause" which
> reads as follows: "Redistributions in binary form must reproduce the
> above copyright notice, this list of conditions and the following
> disclaimers in the documentation and/or other materials provided with
> the distribution."
> 
> However, the MIT license says the following: "The above copyright notice
> and this permission notice shall be included in all copies or
> substantial portions of the Software." which doesn't define what a
> substantial portion of the software even is, and notably does NOT
> exclude redistributions in binary form at all. I am also pretty certain
> I've read interpretations on the web which understand the license
> implications of MIT similarly that binary redistributions must also
> adhere to the copyright & conditions notice requirement such that it
> doesn't actually provide any weaker requirements here than the
> University of Illinois/NCSA license.
> 
> Therefore, how is the MIT even better here? It seems like it doesn't
> actually achieve the intended goal with any certainty. Wouldn't it be a
> much better idea to pick the zlib/libpng license or another license with
> a similarly clear text like this: "This notice may not be removed or
> altered from any source distribution." .. which very clearly excludes
> include binary redistribution from this requirement? Something again the
> documentation appears to suggest for the MIT license but which the MIT
> license actually doesn't seem to fulfill.
> 
> Disclaimer: I am not a lawyer so all of what I am writing here might be
> utterly wrong
> 
> Regards,
> Jonas Thiem
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>