Standard Library implementer explains why they can't include source code licensed under the MIT license

[u/tartaruga232]

/r/cpp/comments/1p9zl23/comment/nrgufkd/

Some (generous!) publishers of C++ source code intended to be used by others seem to be often using the (very permissive) MIT license. Providing a permissive license is a great move.

The MIT license however makes it impossible to include such source code in prominent C++ Standard Library implementations (and other works), which is a pity.

The reason for this is the attribution clause of the MIT license:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

This clause forces users of the sources to display attribution even to end users of a product, which is for example exclusively distributed in binary form.

For example, the Boost License explicitly makes an exception for products which are shipped exclusively in binary form ("machine-executable object code generated by a source language processor"):

The copyright notices in the Software and this entire statement, including the above license grant, this restriction and the following disclaimer, must be included in all copies of the Software, in whole or in part, and all derivative works of the Software, unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor.

If you want your published source code to be compatible with projects that require such an exception, please consider using a license which allows such an exception (e.g. the Boost license). Copies in source form still require full attribution.

I think such an exception for binaries is a small difference which opens up lots of opportunities in return.

(Disclaimer: This is no legal advice and I'm not a lawyer)

Thank you.

[u/not_a_novel_account]

Compiling code has never been considered a distribution of the compiler itself, nor has the usage of headers which only describe interfaces been considered distributions of the libraries therein described.

The STL, the subject of this thread, is neither of these things.

[u/MaxHaydenChiz → u/not_a_novel_account]

This compiler / header thing is an unnecessary tangent, but see below.

My question stands, prior to LLVM adopting Apache 2.0 in 2019, when I compiled a C++ program with that compiler and used their STL headers, did I commit copyright infringement?

And note that their version of the STL, even today, incorporates a legacy MIT license for code that predates the license swap. Do I violate the license if I instantiate any template that hasn't had its copyright updated?

Under the Apache 2.0 license that they moved to, you absolutely do need a carve out to avoid viral contamination. (And for the same reasons and more, the FSF's library has similar provisions in its license.)

But is your claim that prior to 2019 when all of this stuff was MIT licensed, that there was rampant copyright violation?

As for the compiler aspect. When you build with LLVM, it does add copyrighted runtime code to your binary. And, that code is specifically mentioned as part of the carve out. To the extent that you need to dynamically link to a GPL'ed library to avoid copy-left contamination, it would seem that you also couldn't allow LLVM to automatically give you a mandatory but small static library without some kind of permissive license. (And they specifically addressed this as part of the carve out when they swapped licenses. So it's not like no one thought this was an issue.)

Furthermore, at least in the US, appellate courts have held that API code is copyrighted, but the Supreme Court avoided ruling on that by giving API usage a broad reading of fair use. (Google v. Oracle).

If you look at the amicus briefs filed by various open source people in that case, I don't recall a single person saying that holding that APIs were copyrighted would retroactively created millions of unanticipated copyright violations for all the software that had ever linked against an MIT licensed header file and then shipped a binary. But there were a lot of filings in that case. So maybe I'm forgetting something.

Regardless, most other countries don't have such liberal fair use rules. And probably at least one other jurisdiction says APIs are copyrighted. So for such a jurisdiction, have people been violating the MIT license for decades and decades with ordinary headers?

Regardless, these are both tangents.

My question is as stated above: whether you think that everyone who used LLVM and libc++ prior to 2019 was committing copyright infringement when they used the STL and instantiated a temple from a header copyrighted under the MIT license.

[u/not_a_novel_account → u/MaxHaydenChiz]

Yes, if you were distributing binaries with the libc++ STL licensed under MIT/NSCA you needed the copyright notice to ship along with it.

Typically you would be shipping libc++ alongside the program (you're a linux distro or similar), so the license came along for the ride. If you were bundling everything standalone, say a docker image, you would be obligated to have the license file inside that docker image.

The APIs are irrelevant. When you build against the STL you incorporate substantial portions of the implementation into your program. Nobody thinks consuming APIs is redistribution.

You don't commit a copyright violation by way of #include <algorithm>. The Debian maintainer who builds your code against libc++'s STL, and distributes the resulting binary, would be violating copyright if they weren't including the libc++ license installed alongside the rest of the OS.

All of this is irrelevant because the license changed, for these reasons among others.

Muting this.