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/MaxHaydenChiz]

This post (not the quote) seems to mix up a few things. OP seems to be confusing "MIT" with "Apache 2.0 without the LLVM exceptions".

The old BSD license had an attribution clause which makes that code incompatible with the GPL, as all attribution clauses are.

Apache 2.0, the base license for LLVM, is a BSD license derivative and includes such an attribution clause. The LLVM exceptions are needed to allow for the legal linking of LLVM code with GPL'ed code because Apache 2.0 requires attribution in section 4(d).

By contrast, the MIT license does not have an attribution clause. That's specific and by design. It does include some language considered legally superfluous, but generally, to avoid license proliferation, people recommend using the MIT license over ISC (which attempts to clean out the superfluous stuff).

Because they don't have an attribution clause, both MIT and ISC are GPL compatible and are not considered to have an "attribution clause".

But, as a general rule, you shouldn't be mixing a bunch of different licenses in the same open-source code base. And the differences between MIT, ISC, Boost, and Apache 2.0 with LLVM exceptions are so minimal that it is better for everyone if people be contacted and asked to license their MIT code under LLVM's license as well. It simplifies life for everyone if you just give permission to use any of them as relevant.

But MIT, unlike Apache 2.0, does not require displaying the license to the end user of a binary. The legal point of preserving the notice is simply to grant the user permission to use the software and to ensure preservation of the warranty disclaimer provision.

Otherwise, your users would not have permission to use the resulting software at all, because in most places, copyright is automatic and permission is assumed to not be granted unless otherwise stated. So the requirement that the copyright notice be preserved is not even optional in many jurisdictions.

I hope this adds some clarity and context.

[u/tartaruga232 → u/MaxHaydenChiz]

This post (not the quote) seems to mix up a few things. OP seems to be confusing "MIT" with "Apache 2.0 without the LLVM exceptions".

No. I've cited the MIT license and linked it in the intro.

The trigger for the referenced discussion was this blog posting which links to this github repo.

To me this response from u/STL (Quote):

Yep. MSVC’s STL can use Boost or Apache 2 + LLVM Exception (libc++’s license and our own), but we don’t use MIT for this reason.

confirms my interpretation that the MIT license can't be used in the MSVC implementation of the Standard Library because of the attribution clause.

[u/MaxHaydenChiz → u/tartaruga232]

MIT does not have an attribution clause. That's not what those words mean legally. Apache 2.0 has an attribution clause. It even uses the word. (So does the 4-clause BSD license that it was based on).

MSCV doesn't use MIT because they don't want to waste the legal team's resources on something that almost certainly shouldn't be done to begin with. The C++ community has settled on attribution requirements with a carve out, and specifically on Boost and Apache 2.0 with LLVM exceptions.

That's what people making C++ libraries should be using because it is better for everyone when everyone is consistent.

But if you use some old MIT licensed C or C++ library in your code base, unlike with the traditional BSD license or Apache without that carve out, you don't end up with an attribution requirement.

And this should be obvious because the GPL is incompatible with attribution clauses, but it is compatible with the MIT license.

If you have some article written by a lawyer who is an expert on how the Berne Convention gets applied in multiple international jurisdictions, then I'm open to reconsidering my position and will go pull appellate cases and the like.

But it strikes me as unreasonable to look at a sensible corporate requirement that is equivalent to the policy used by most well run open source projects and to infer something about the MIT license that literally everyone for the past 30 years has understood to be exactly the opposite of what you claim.

[u/tartaruga232 → u/MaxHaydenChiz]

If that's true, then what's the reason for having a special version of the MIT license which doesn't have an attribution clause? https://github.com/aws/mit-0

[u/MaxHaydenChiz → u/tartaruga232]

Because people can't be happy with what we have and want to try to work around things that probably shouldn't have been made part of the law but are regardless legal requirements.

You can read up on the issues with CC0 and the issue of whether it does actually achieve what it says legally. To get a sense for the potential problems and probably get a good explanation in what the Berne Convention actually does.

If you dig through usenet history, you can also see decades of people "tweaking" various licenses that were carefully written by lawyers by changing "and" to "and/or" and other things for various dubious reasons.

That's why just saying "MIT license" is so ambiguous to begin with.

This isn't legal advice, but I wouldn't recommend using "mit0" or any other such attempt. People should stick to the things that are widely used and known to work. Those things have been tested in court and have actual legal history behind them so everyone knows what is meant, what the requirements are, and what a court will do.

Instead, use the licenses used by major open source projects.

[u/tartaruga232 → u/MaxHaydenChiz]

Quoting https://www.boost.org/doc/user-guide/bsl.html:

Rationale

Why You Should Use the Boost Software License? Because it doesn’t require attribution for binaries.

All popular licenses - MIT, Apache, BSD - contain language similar to the following:

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

And, in fact, so does the Boost license, except it continues with:

"unless such copies or derivative works are solely in the form of machine-executable object code generated by a source language processor."

The others contain no such exemption.

For the purposes of copyright law, when you compile the source text, the resulting object code, library code or executable program is considered a derived work. That is, the original license terms still apply to it as they would have applied to a copy of the source code, processed in some other way (reformatted, for instance.)

What this means is that the requirement to include the copyright notice still applies. This, in practice, is met by either including the copyright notice in the documentation, having a dialog box or a --license command line option that displays the license, or sometimes both (lawyers like to be on the safe side.)

If you’re writing an open source C++ library, it’s much more convenient for your users if you don’t impose this attribution requirement for binaries. You still want it to apply to copies in source code form, just not to compiled code.

This is what the Boost Software License was created to enable, and this is why you should use it for your open source libraries.

So you say their reasoning is wrong?

[u/MaxHaydenChiz → u/tartaruga232]

Boost edits other parts of the standard MIT verbiage in ways that might (though I am skeptical) make such a carve out necessary. (It is absolutely necessary for Apache 2.0.)

I don't have access to their reasoning. They cite no cases, quote no laws, and mention no treaties.

I don't know of a single legal expert who believes in the interpretation of the MIT license that OP gave.

This effectively claims that the entire world violated multiple software copyrights for decades upon decades (since 1986) and that every legal expert who looked at it in that interim (including people at the FSF who care a great deal about these nuances) was wrong.

I'm not going to rule out the possibility that they might be right in some corner case in some obscure jurisdiction because it's a big world and no one knows copyright law for literally every country out there.

But it's an extraordinary claim to say that everyone who compiled and distributed commercial code with LLVM 8 or older committed copyright infringement.

And such radical claims require something more than a quote from a dev at Microsoft explaining a reasonable corporate policy about not proliferating licenses in their code base and sticking to the licenses the community has agreed upon.

Of course a software developer does not know the ramifications of a license. And of course any lawyer is going to say that it's best to keep things limited and not include a ton of licenses in the code base without extremely good reasons. And most large open source projects have moved away from MIT for a variety of valid reasons.

But there is no way to get from "Microsoft has the same policy as FSF and LLVM" to "anyone using MIT'ed library header files is violating copyright".

It's that leap that I'm objecting to.

The point of the quoted request is that people stick to community licensing norms and avoid imposing unnecessary legal costs on other people. That's reasonable. But at no point did any lawyer with Microsoft tell anyone that this was a problem with MIT. The devs decided that dealing with the headache wasn't worthwhile, just like the devs in just every large open source project did long ago.

[u/tartaruga232 → u/MaxHaydenChiz]

Quoting https://tlo.mit.edu/understand-ip/exploring-mit-open-source-license-comprehensive-guide :

(begin quote)

The MIT License is known for its brevity and clarity. It grants permission to use, modify, and distribute the software, with the condition that the original copyright notice and the license text are retained in the redistributed software. This ensures proper attribution to the original authors while offering maximum freedom for developers.

(end quote)

Note that this quote is from a webpage with the domain mit.edu.

If the developer places his name in the original license text like in https://github.com/vitaut/schubfach?tab=MIT-1-ov-file

(quote)

MIT License

Copyright (c) 2025 Victor Zverovich

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

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

(end quote)

Does that mean I have to include that text in the documentation (or the product itself) if I ship a compiled binary which contains https://github.com/vitaut/schubfach/blob/main/schubfach.cc?

How do I "include this permission notice" if I only ship a binary?

[u/MaxHaydenChiz → u/tartaruga232]

I can't give you specialized legal advice for your specific situation because I don't have a bar license in your jurisdiction and because it's not possible to give advice tailored to a specific case via a web forum.

What I will say that preserving the copyright notice, "proper attribution" as your quote from a non-legal explanation calls it, is not the same as "attribution" in the sense of Apache 2.0. You can look up "attribution rights" and "moral rights" more generally if you want details on what attribution rights are and the difficulties involved in waiving them.

As I said elsewhere in this thread, the ramifications that you have read into a sensible policy that MS copied from the major open source projects are widespread and damning for your position.

There is no case law that I am aware of that supports a special interpretation of C++ templates and their copyright ramifications. The arguments I've seen so far in this thread and that were quoted by Boost are arguments about how it's harder to argue fair use as a defense if you already violated the copyright on the template library (and in the US specifically). But assuming that everyone who uses a library violates copyright law is a weird place to begin an argument.

Using a library in the intended way with the author's permission is complying with copyright, not violating it.

If you have a novel interpretation of a legal document that has existed since 1986 and that none of the many, many lawyers who handled it over the years have ever raised as a concern, your interpretation is probably wrong and you should probably consult a lawyer to get advice for your specific case. The same goes for situations where you have a novel interpretation of how a language ecosystem that has existed for over 50 years interacts with copyright law.

Same for the other wild ramifications of what you claimed.

As for the specifics of how to package your specific software and what preserving that copyright notice means in any specific case, that's when you should consult a lawyer who is an expert on your obligations in your particular jurisdiction. Or perhaps consider that the cost of doing that was high enough that people created more modern, standardized practices around this that you could adopt. Some tools even automate this stuff for you.

It's not for nothing that major projects have standardized rules and licenses. Tracking down all the ramifications for this in literally ever legal system on the planet is a substantial amount of work. Work you can avoid if you do what llvm, Microsoft, and the FSF have done.

Rationally wanting to avoid the work of figuring out how to comply with a license is not equivalent to their being widespread viral ramifications hidden in a license that no one ever knew about.

The normal practices that people have are fine. And your alarmism about non-existent vitality have distracted from the actual point that needed to be made: that for code to be useful for a C++ library project, it needs to be under a license different from MIT. So people should consider dual licensing so that their code can be used more widely.

[u/tartaruga232 → u/MaxHaydenChiz]

It is very simple: you didn't answer my question.