Runtime library components licensing / MIT License / credit requirements

Project Infrastructure LLVM Dev List Archives
1

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

2

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