I'm developing a project that happens to use a lot of open-source third-party libraries by different authors. Most of these libraries use the same license (mostly MIT, with the occasional Apache or BSD license here or there). My LICENSE.txt file will likely be incredibly long and repetitive, but I'm not going to skip out on compliance.

If I use a lot of libraries that are released under the exact same license, must I include the text of the license once for each library? Or can I just include the license once, plus the unabridged copyright statement (author, year, license name, etc.) for each library? Or does that depend on the license itself?

EDIT: I understand that some licenses have named variations (e.g. BSD-3-Clause vs. BSD-3-Clause-No-Military-License or BSD-2-Clause). For the purpose of this question, I consider named variants to be different licenses entirely.

1 Answer 1


In principle, you can deduplicate the licensing terms. However, this is most appropriate for lengthy licenses with a clear name, e.g. Apache-2.0 or the GPL licenses. These are designed to be kept in a separate files.

For shorter licenses in the MIT or BSD families, there might be small differences that you would technically have to preserve. If you want to deduplicate those, don't do it manually. Personally, I don't think that deduplication for smallish licenses is very useful, in particular if you assemble your licensing documentation automatically.

In any case, you can at most deduplicate the license terms. You must not abbreviate copyright notices. Where licenses are kept in a separate file, it is also common to provide a short license notice, e.g. the GPL “This program is free software” notice. For those, the same concerns as with short-ish notices apply: yes, you could deduplicate these, but there might be subtle differences.

Note that you only have to include the license for a library if you include that library with your software, for example if you provide pre-built binaries or if you vendor these dependencies. Merely referencing other libraries in your source code doesn't impose requirements on you.

  • 1
    By "small differences that I would technically have to preserve", do you mean license variants (e.g. BSD-3-Clause-Clear or MITNFA), or something more subtle? For the purpose of this question, I consider named variants different licenses.
    – JesseTG
    Commented Jun 5, 2021 at 21:28
  • Also: "Merely referencing other libraries in your source code doesn't impose requirements on you." What do you mean by this? I understand that the inclusion of the library in a build (as opposed to edit-time tool output like compilers or image editors) is an important factor, but I don't understand the distinction you're making.
    – JesseTG
    Commented Jun 5, 2021 at 21:31
  • 2
    @JesseTG Re license differences. There are at least three different licenses that are sometimes called "MIT", Wikipedia summarizes some variants.
    – amon
    Commented Jun 6, 2021 at 6:35
  • 1
    Re inclusion: If I write a Rust software and have various dependencies on other crates, for which dependencies do I have to show the licenses? Usually, none, because my source code doesn't include the dependencies – there are just some instructions for the cargo package manager. I should take care of ensuring license compatibility though. In contrast, if I include the source code of the dependencies in my repository, or if I offer pre-built binaries, then I do have to fulfill their license terms. This also applies to transitive dependencies. Disclaimer: this is my opinion, others disagree.
    – amon
    Commented Jun 6, 2021 at 6:44
  • Ah, okay, thank you. (99% of software that I use or read is distributed in binary form, so for a second I forgot that some software is only released in source form.)
    – JesseTG
    Commented Jun 7, 2021 at 13:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.