"Combined work" license confusion question

[paul-hammant]

do-md/domd depends on do-md/core-react which NPMjs says is https://polyformproject.org/licenses/noncommercial/1.0.0 (and itself doesn't appear to be open source. Or not public on GitHub.

While MIT code can declare a dependency on a noncommercial package - the shell and the engine are separate works, and package.json is a pointer, not a copy. <-- Nothing about that is inherently invalid.

The actual problem is different, and worse in a practical sense: the combination is what's restricted, and the MIT label misleads about it. Is that the intention, or an acceitend of not-all-files-updates while re-licensing?

[do-md]

This is intentional, but the licensing documentation was outdated after the core editor was moved out of this repository and published as @do-md/core-react.

This repository is MIT licensed, while the core editor, @do-md/core-react, is a separate package under the PolyForm Noncommercial 1.0.0 license. Use of the complete application must comply with both.

I’ll update the old @do-md/dist references and make this clearer.

[paul-hammant]

I had asked my claude to (with credit) take https://github.com/kotaindah55/extended-markdown-syntax extra formatting and make a PR to this repo for extended markdown support. It got so far but in testint there were glitches. It ws blocked on how to solve those because core-react wasn't open source. The license Q is the one that makes me wonder whether core-react would be open sourced (or not) thus allowing me to do a PR to that too. I'll let Claude add a note in my name in what the issue is wuth the othere module

[paul-hammant]

Claude here, adding the technical detail @paul-hammant referred to — what specifically blocked the extended-markdown-syntax port, and the smallest change to @do-md/core-react that would unblock it.

What was attempted

Porting four inline syntaxes from kotaindah55/extended-markdown-syntax (with credit):

Syntax	Renders as
^text^	<sup>
~text~	<sub>
=={color}text==	<mark class="custom-highlight custom-highlight-{color}">
!!{cls}text!!	<span class="custom-span {cls}">

The parser itself is done — engine-agnostic, DOM-free, 40 passing tests covering the valid/invalid pairs from that plugin's docs/rule.md. What it cannot do is reach the editor.

Where it blocks

DOMDProviderProps exposes three tokenizer hooks, and all three are block-level:

codeTokenizer?: (code: string, lang?: string) => unknown[];
codeBeautify?: (code: string, lang?: string) => string | undefined;
htmlTokenizer?: (html: string) => unknown[];

There is no inline equivalent, so there's no supported way to participate in inline tokenization. With the kernel being a minified bundle with no published source, patching isn't an option either — hence the licensing question in this issue.

There's also a collision worth flagging: core already claims == and renders its own highlight, ignoring a {tag}. So =={red}x== currently renders yellow with {red} visible as literal text. That syntax needs to override an existing rule, not merely add a new one. ^, ~ and !! don't collide.

The ask

One additional prop, following the same shape as the existing three:

inlineTokenizer?: (text: string) => InlineToken[] | undefined;

Called during inline tokenization with the raw text of an inline run; returns spans to render, or undefined for "not mine, use default handling." The host supplies a pure function and the kernel stays in control of when it runs — consistent with the README's "host supplies platform capabilities through injection points." It asks for no access to the parser, the AST, or any internals.

Two properties it needs in order to actually solve the problem:

1. Runs before built-in inline rules, or offers some way to claim a delimiter — otherwise == stays unreachable.
2. Runs on edit, not only initial parse — otherwise it's cosmetic and no better than post-processing the rendered DOM.

Narrower alternative

If a general callback is too invasive, a declarative registration would also work, and is a smaller surface to commit to:

inlineRules?: Array<{
  char: string;          // "^"
  length: number;        // 1
  exactLen: boolean;     // true  -> "^^x^" is literal
  allowSpace: boolean;   // false -> superscript forbids whitespace
  tag: "none" | "classes" | "color";
  tagName: string;       // "sup"
  className?: string;
}>;

That's exactly the table the original plugin uses, and what our port already encodes — so either form ports directly.

Why it's raised here

Not to push for a particular licensing outcome. Only to make concrete what a host currently can't do: with no inline hook and no source, extending inline syntax isn't reachable by any supported route. If core-react gains such a hook, this port becomes a small PR against a public API. Happy to contribute it either way.

_{Written by Claude (Anthropic) at @paul-hammant's request.}

[do-md]

Thanks, Paul — both for raising the licensing question and for providing such a detailed technical write-up.

This has become one of the most valuable issues the project has received. Your request was concrete enough to design against, and it ultimately pushed the extension API somewhere better than either of us initially envisioned.

What shipped

@do-md/core-react@0.5.0 adds a declarative inlineRules injection point — essentially your “narrower alternative”, generalized:

<DOMDProvider
  inlineRules={[
    {
      char: "^",
      length: 1,
      exactLen: true,
      allowSpace: false,
      tagName: "sup",
    },
    {
      char: "~",
      length: 1,
      exactLen: true,
      allowSpace: false,
      tagName: "sub",
    },
    {
      char: "=",
      length: 2,
      tagName: "mark",
      capture: {
        to: "style",
        template:
          "background-color: color-mix(in srgb, {} 80%, transparent)",
      },
    },
    {
      char: "!",
      length: 2,
      exactLen: true,
      tagName: "span",
      className: "custom-span",
      capture: { to: "class" },
    },
  ]}
/>

Both of your hard requirements are satisfied.

The rules run inside the editor’s single parsing pipeline and participate in parsing on every edit. This is not a cosmetic post-processing pass over the rendered DOM.

The == collision is resolved at the rule level rather than through a special case. The kernel’s original highlight is now itself a default inline rule, exported as defaultInlineRules. Supplying inlineRules replaces the default rule set, allowing your =={color}text== rule to take its place directly.

A single-tilde rule also coexists with the built-in ~~strikethrough~~ syntax.

From tag to capture

Your proposed tag field evolved into the more general capture:

capture: {
  to,
  map?,
  template?,
}

A rule captures the value inside {…}, optionally transforms it through a {} template or a host-supplied map function, and writes the result to class, style, data-*, aria-*, title, or href.

Captured output is sanitized before being applied, including appropriate restrictions for attributes, links, and styles.

One useful consequence is that named and hexadecimal colors can be used directly:

=={red}named color==
=={#8888ff}hex color==

This removes the need for the per-color CSS classes required by the original plugin.

Markdown round-tripping

No additional round-trip mechanism was needed.

The delimiters and raw {…} content remain in the document model and serialize back verbatim. Custom rules affect presentation without taking ownership of or rewriting the underlying Markdown.

If a host-supplied map function throws, only the visual effect for that occurrence is suppressed; the document text remains intact.

Try it

The feat/extended-inline-syntax branch applies the four syntaxes across the editor surfaces in the repository. The shared rule configuration lives in:

common/lib/inline-rules.ts

Credit to [kotaindah55/extended-markdown-syntax](https://github.com/kotaindah55/extended-markdown-syntax) is included in the source, as requested.

A live preview is available here:

[Open the extended inline syntax preview](https://domd-av5zjv8dx-do-mds-projects.vercel.app/editor)

You can paste or type the following examples:

E = mc^2^ and H~2~O

=={red}inline-styled highlight==
=={#8888ff}hex works too==
==plain==

!!{note}a custom span!!

The corresponding formatting should appear as soon as the closing delimiter is entered.

On open-sourcing the core

I want to answer this directly: I’m not planning to open-source the kernel at the moment.

DOMD is still at a very early stage and is not widely known. For now, keeping the kernel source private is one way I can protect the work while the project has time to establish its identity and earn recognition.

Commercial licensing is part of the current model, and I hope it can eventually help sustain the project, but it is not the main reason for keeping the kernel closed. Commercial integrations are currently authorized free of charge, with formal written permission provided. At this stage, helping real users adopt and validate DOMD matters more than generating revenue through commercial licensing.

Your licensing question was entirely fair. Without either source access or an inline extension point, this contribution had reached a real boundary.

inlineRules is the answer I can provide today: the kernel remains closed, but the public extension surface should provide real capabilities, allowing hosts to change meaningful editor behavior through supported APIs without needing access to kernel internals.

If my decision about the kernel changes in the future, I’ll update this issue.

Thank you again — genuinely. The care you put into the port, its tests, the attribution, and the explanation of where it was blocked directly led to this improvement.

If anything behaves differently from what the new API promises after moving the port to 0.5.0, please report it here.

[paul-hammant]

Cool. Here's as far as I got - https://github.com/paul-hammant/domd/commits/main/ - two commits - work incomplete.

Here's the stood-up demo - https://paul-hammant.github.io/domd/editor I was playing with =={red}your text== within that.

I'll shift my attention elsewhere in GitHub for a markdown editor that does =={red}your text== and others, but not yet delete my domd fork in case you can extract value from it. Good luck