Notepad++’s Mac-port dispute: licensing, branding and software provenance

The May 2026 dispute over a project promoted as Notepad++ for Mac was about more than whether Windows code could be adapted to another operating system. It exposed a distinction between permission to modify software, presentation of a product as official and responsibility for supporting the resulting application.

An independent port can be a legitimate development project without being maintained or endorsed by the original team. Conversely, a familiar name or icon does not establish that a downloadable application has the original project's release process. That distinction is the concrete lesson of this case, rather than a reason to declare every fork unsafe.

What the original maintainer objected to

In the original project's GitHub discussion, Don Ho said he welcomed ports in principle but objected to branding that gave the impression of an official macOS release. He described asking the port's developer to change its name and logo and distinguished the port itself from the misleading impression of endorsement.

The developer, Andrey Letov, responded that he had not intended to imply Ho's involvement and wanted to credit the original author. Those are the participants' accounts. The thread documents the disagreement; it is not a judicial finding about every disputed legal question or an independent audit of the software.

Ars Technica's May report described the dispute, the proposed NextPad++ rebranding and the developer's account of using AI coding tools. The report did not establish that an AI-assisted codebase is necessarily malicious, and this article makes no such claim.

Attribution does not necessarily mean involvement

A modified application can contain work by an original author who did not develop, test or release that particular modification. Preserving an attribution and presenting someone as a maintainer of a new product are different statements. A reader needs to know which one an author page actually means.

That distinction also affects support expectations. Recognizing an interface does not identify the person responsible for a regression, a plugin incompatibility or a security update in the modified build. The original team cannot be assumed to have reviewed changes merely because its earlier work appears in the codebase.

The earlier article blurred these questions with a sweeping list of safe alternatives and guaranteed compatibility routes. Those rankings were not established by testing and are removed. A particular Windows plugin's behavior in a different runtime requires evidence about that plugin and environment, not an inference from the editor's name.

The license does not make charging inherently suspect

The license distributed with Notepad++ includes GPLv3 terms and project clarifications. GPLv3 section 4 allows copies to be conveyed for a price or without one, subject to its conditions. Modified-source and object-code distribution have further requirements in the subsequent sections.

This corrects the earlier article's implication that charging for GPL-based software is itself a warning sign of wrongdoing. Price alone does not establish license compliance, noncompliance, quality or official status. A free download can be misleading, and a paid distribution can satisfy applicable conditions.

The same license text expressly distinguishes possible additional terms involving attribution, origin and trademark rights. This article does not adjudicate how every term applies to the disputed port. The narrower point is that code-distribution permission and a claim of official affiliation cannot be treated as the same proposition.

Signing and notarization answer another question

Apple's explanation of Gatekeeper says Developer ID signature checks address an identified developer and whether software has been altered. It describes notarization as a check for malicious software in which none was detected. Those checks concern the distributed application and Apple's process, not endorsement by an unrelated upstream project.

A notarized application can therefore still be unofficial. That does not make notarization meaningless; it means the evidence supports a different claim. The earlier article's presentation of a short checklist as enough to establish that a download should be installed was too strong.

This account neither installs the port nor advises overriding a macOS warning. It also does not certify a binary as clean. Reading a repository discussion is not the same as auditing a release artifact or establishing its correspondence with published source.

Separate the questions before drawing a conclusion

For this case, the relevant questions are who produced the modified application, who authorized its presentation, which license conditions apply and what technical validation has actually occurred. Each needs its own evidence. Answering one does not automatically answer the rest.

The corrected account records a dated branding dispute and the maintainer's stated lack of endorsement. It removes unverified editor rankings, obsolete price assumptions, plugin guarantees and blanket claims about unofficial builds. That leaves a clearer explanation of provenance: compatible-looking software can come from a different project, under different support arrangements, even when it legitimately builds on shared code.