## AI disclosure Much of this project's code, tests and documentation was written with AI coding agents, and so was this request. I direct that work and am responsible for what is posted here. ### What this asks I maintain the [BlockNote module](https://www.drupal.org/project/blocknote), a rich text editor integration. Several of its editor buttons draw an icon copied from [Remix Icon](https://github.com/Remix-Design/RemixIcon), a set licensed Apache License 2.0, which "Drupal.org distribution packaging requirements" (https://www.drupal.org/node/1475972) lists among the software library licenses not allowlisted. I have held each glyph as an unmodified `.svg` file in a directory named `icons/remix/`, with Remix's own `License` file beside it as `LICENSE`, a `README.md` naming the source URL, the tag, the commit, the license and the file list, and a `sha256sums.txt` recording each file's hash, on the reading that this is the shape the policy on third-party assets (https://www.drupal.org/node/422996) and the git repository usage policy (https://www.drupal.org/node/1001544) describe when they say a non-code asset such as an icon may be distributed "in aggregate" with GPL code under a free license, with its provenance, license and source documented in the repository. Neither policy page says whether a `.svg` file, inlined into a compiled JavaScript bundle at build time with a bundler's raw-text import and rendered into the page as markup at runtime, is still the "non-code asset (icons)" the policy means, or whether inlining it into a compiled script moves it into the category the allowlist marks Apache-2.0 refused for. I am asking which reading is correct, because the two `icons/remix/` directories in this repository, and the two components that read them, are built on the first reading. ### The concrete case Two directories, each holding a `README.md`, a `LICENSE` (Remix Icon's own, unmodified), a `sha256sums.txt` with the sha256 of every file beside it, which the build checks before it writes `THIRD_PARTY_NOTICES.md`, and unmodified `.svg` files fetched verbatim from `https://raw.githubusercontent.com/Remix-Design/RemixIcon/v4.6.0/icons/<Category>/<name>.svg`, tag `v4.6.0`, commit `8bc436bdd329cf342958d8effdd078bfa74354c6`: | Directory | Files | | --------- | ----- | | `js/icons/remix/` | `link.svg`, `text.svg`, `external-link-fill.svg`, `link-unlink.svg`, `subscript.svg`, `superscript.svg` | | `modules/blocknote_media/js/icons/remix/` | `image-edit-fill.svg`, `image-add-fill.svg`, `input-field.svg`, `text.svg`, `align-left.svg`, `align-center.svg`, `align-right.svg` | `js/src/icons.tsx` and `modules/blocknote_media/js/icon.tsx` each read a file with Vite's `?raw` import at build time and render the resulting string into the page with `dangerouslySetInnerHTML`, inside a `<span>` marked `aria-hidden="true"`; nothing in the file is executed, evaluated or otherwise treated as code. `THIRD_PARTY_NOTICES.md` names both directories, their source, tag, commit and license, the same way it already names the bundled `@blocknote/*` packages. The copied tag, `v4.6.0` (commit `8bc436bdd329cf342958d8effdd078bfa74354c6`), predates Remix's own relicensing: Remix Icon's `License` file changed from the Apache License 2.0 to the non-free "Remix Icon License v1.0" from `v4.9.0`, January 2026, confirmed directly against both tags. No file in either directory is ever refreshed from, or added from, a commit at or after that relicensing, and each directory's `README.md` says so. ### Why this project believes the non-code-asset rule applies The policy on third-party assets states: "Drupal also permits 3rd party GPL-incompatible non-code assets (e.g. fonts, icons, etc.) in the repo if it can be distributed 'in aggregate' with GPL code under a 'GPL-friendly' license," and the git repository usage policy adds that "any third party assets you include must have their provenance, license and source documented in a file included in the project." An icon is named explicitly as the example non-code asset in both pages. The `.svg` files here are exactly that: unmodified icon files, in their own directory, with their provenance, license and source documented beside them. What is new is that a build step reads the text of the file and puts it in the compiled output verbatim, the way a CSS `background-image: url()` or an HTML `<img src>` would if either format were used instead; the module reads the choice between those techniques as a build detail that does not change what kind of thing the `.svg` file is. ### What this project has already found - "Drupal.org distribution packaging requirements" (https://www.drupal.org/node/1475972), whose allowlist is of libraries holding only code compatible with GPL-2.0-or-later, lists Apache-2.0 among the software library licenses "not allowlisted under our current policy", beside GPL-3.0 and LGPL-3.0, and says that this policy "is still being discussed", linking https://git.drupalcode.org/project/drupal_lwg/-/work_items/1449452 for the status. That note is stale: #1449452 asked for GPLv3+ as a license option for packaged distributions, and kreynen closed it as works as designed on 2022-07-08, noting that nothing changes in the git policy and that general projects, such as site recipes, may now declare dependencies under any license. It was about packaged downloads, not about what a project's repository may hold. For code, the answer has long been no: a 2012 support request about Apache-2.0 code in a contributed module, https://git.drupalcode.org/project/drupal_lwg/-/work_items/1804284, was answered that it cannot be included, because Apache-2.0 is compatible with GPLv3 but not with GPLv2. - The page's GPL-friendly table names CC BY, CC BY-SA, OFL and GPL with font exception. Its CC BY, CC BY-SA and OFL entries came from https://git.drupalcode.org/project/drupal_lwg/-/work_items/2954773 (2018, fixed), which listed them once the repository usage policy began to allow third-party assets; Apache-2.0 was not discussed there. The table does not name Apache-2.0, and the page does not say whether a documented icon asset under Apache-2.0 is covered by the non-code-asset rule regardless of the allowlist's own code table. - How such an asset's provenance, license and source should be declared is the subject of https://git.drupalcode.org/project/drupal_lwg/-/work_items/2934443, "Recommendation for declaring metadata for third party assets", which has been waiting for review since 2018. The files beside the icons here give what its proposed resolution asks for: who made the assets and where they came from, the license they came under, and their own license file kept beside them. - I found no LWG ruling that addresses an icon `.svg` file specifically, whether held as an asset or pasted as path data inside a script. - Core 11.4.x ships no Apache-2.0 file. `material_base` 3.x, a contributed theme, commits Material Design `.svg` icons under Apache-2.0 without documenting them the way this module's `icons/remix/README.md` files do, which this project reads as an existing practice rather than as a ruling either way. - This module's own compiled bundle, `dist/blocknote.js`, already carries 63 glyphs through the upstream `@blocknote/react` and `@blocknote/mantine` packages' own use of `react-icons`, which they inline when they are published: 55 from Remix Icon and 4 from Material Design (both Apache-2.0), one from Font Awesome 5 (CC BY 4.0), and one each from Ant Design Icons, Tabler Icons and Heroicons (all MIT). This request does not ask about that set, which this project has yet to list in `THIRD_PARTY_NOTICES.md`; I am disclosing it here so the working group has the fuller picture while it answers the narrower question about the two documented directories. ### The question Does a directory of unmodified `.svg` icon files, held in a GPL-2.0-or-later contributed module's repository with a `README.md` naming their source, tag, commit and license and the license's own unmodified text beside them, meet the non-code-asset rule for a GPL-incompatible license such as Apache-2.0, when a build step reads each file's text and inlines it into a compiled JavaScript bundle at build time, rendered into the page as markup at runtime rather than executed as code? If yes, is there anything about the documentation, the file layout or the build technique above that should change to make the answer more clearly yes? If no, because inlining moves the asset into the category the code allowlist governs, what shape would make it a non-code asset in the working group's reading, for example an image the browser loads by URL rather than markup a bundler inlines? ### What this project does meanwhile Until this is answered, the two directories stay as documented `.svg` assets, and the module's [decision record 0033](https://git.drupalcode.org/project/blocknote/-/blob/1.0.x/docs/decisions/0033-editor-icons-are-blocknote-s-own-held-as-documented-icon-assets.md), which made this choice, names the fallback if the answer is no: redrawing the same glyphs by hand, in Remix's visual style, which needs no license documentation because nothing would be copied. ### Related #3578950 asks about the module's bundled MPL-2.0 packages.