Skip to content

mdbook-html: Account for licenses of bundled JavaScript libraries and artwork - #3144

Open
decathorpe wants to merge 2 commits into
rust-lang:mainfrom
decathorpe:master
Open

mdbook-html: Account for licenses of bundled JavaScript libraries and artwork#3144
decathorpe wants to merge 2 commits into
rust-lang:mainfrom
decathorpe:master

Conversation

@decathorpe

Copy link
Copy Markdown

This is an attempt to address issue #2956

The first commit adds the missing license texts:

  • The MIT and BSD-3-Clause license texts are taken verbatim from the respective projects.
  • The CC-BY-4.0 license text is the canonical copy from creativecommons.org.

favicon license (canonical copy of the CC-BY-4.0 text):
https://creativecommons.org/licenses/by/4.0/legalcode.txt

clipboard.js license text:
https://github.com/zenorocha/clipboard.js/blob/v2.0.5/LICENSE

highlight.js license text:
https://github.com/highlightjs/highlight.js/blob/10.1.1/LICENSE

elasticlunr.js license text:
https://github.com/weixsong/elasticlunr.js/blob/v0.9.5/LICENSE

mark.js license text:
https://github.com/julkue/mark.js/blob/8.11.1/LICENSE

The second commit updates the package.license of the mdbook-html crate to account for all included code and content.

Licenses covering bundled JavaScript libraries:

- ace.js: BSD-3-Clause
- clipboard.js: MIT
- elasticlunr.js: MIT
- highlight.js: BSD-3-Clause
- mark.js: MIT

Licenses covering bundled content / fonts:

- favicon: CC-BY-4.0
- open-sans: Apache-2.0
- source-code-pro: OFL-1.1
@rustbot rustbot added the S-waiting-on-review Status: waiting on a review label Jun 24, 2026
description = "mdBook HTML renderer"
edition.workspace = true
license.workspace = true
license = "MPL-2.0 AND Apache-2.0 AND BSD-3-Clause AND CC-BY-4.0 AND MIT AND OFL-1.1"

@GuillaumeGomez GuillaumeGomez Sep 8, 2026

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if the license field is for the whole crate or for the rust code. And even worse: if we don't enable the "editable codeblock" feature, some of the licenses are not in use.

View changes since the review

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if the license field is for the whole crate or for the rust code.

Right, I have not ever seen a conclusive decision about this - but since this is the license string that is prominently displayed in various places (like the crates.io page) ... 🤷🏼‍♂️

For what it's worth, the legal guidance we have received from Red Hat lawyers for Fedora packaging is that our license metadata should just enumerate the licenses of everything that's included in a package.

And even worse: if we don't enable the "editable codeblock" feature, some of the licenses are not in use.

Barring conditional crate metadata ("if feature foo is enabled then license this else that") this is not expressible. Additionally, this seems to be related to the kind of book content that mdbook generates at runtime - but that has no bearing on whether this content (JavaScript, etc.) gets compiled / statically embedded into the mdbook executable, which happens unconditionally.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah no clue.

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Including license texts for all bundled components should be the uncontroversial part here though, I can drop changing the package.license metadata for the mdbook-html crate from this PR for now, if that helps?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pinged someone who might know more about, so let's just wait for their input. Sorry for they delay here, it's the kind of things you don't want to mess up so rather than making you do more changes for nothing, better to wait for their input.

@GuillaumeGomez

Copy link
Copy Markdown
Member

@Manishearth Should we bring this topic up to the project?

@GuillaumeGomez GuillaumeGomez removed the S-waiting-on-review Status: waiting on a review label Sep 8, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants