On May 4, 2026, Notepad++ creator Don Ho publicly denounced a macOS port of the Windows text editor as unauthorized, saying it used the Notepad++ name, logo, and presentation in ways that misled users and media into believing it was official. The dispute is not really about whether open-source code can be forked; Ho says it can. It is about whether a familiar project name can be borrowed so aggressively that a fork starts to look like a release channel. For Windows users and IT admins, the episode is a reminder that trust in software is not just compiled code — it is branding, provenance, update paths, and the boring chain of custody that tells you who you are really installing.
The developer behind the macOS app, New York software engineer Andrey Letov, appears to have done what open-source licenses are meant to permit: he took free and open-source code, built something useful, and tried to extend a popular tool to a platform that never had an official native version. That part is not scandalous. The GPL is designed to allow modification and redistribution, and Ho himself acknowledged that a fork or port is not the problem.
The trouble began when the port was presented as “Notepad++ for Mac,” used the familiar chameleon logo, and placed Ho on an author page in a way that, even with disclaimers elsewhere, made the project look blessed by the original maintainer. It did not take much for the internet’s headline machine to do the rest. Reddit posts and tech coverage framed the app as if Notepad++ had finally crossed the macOS border after more than two decades.
Ho’s response was unusually blunt, but the substance was straightforward. Notepad++ has never released a macOS version. The Mac app was not authorized, not endorsed, and not affiliated with the project. In Ho’s view, the site’s use of the Notepad++ trademark and logo crossed from homage into impersonation.
Letov, for his part, said he intended to credit Ho rather than imply Ho’s involvement. That is plausible as human intent and still inadequate as software distribution practice. In open source, good intentions do not erase confusing packaging, especially when the confusion is predictable and commercially useful.
That distinction matters because a project’s name is not decorative. It is the mental shortcut users rely on when deciding whether to download, install, trust, and update software. A name like Notepad++ carries 20-plus years of accumulated credibility among Windows users, developers, hobbyists, and sysadmins who have installed it on countless machines with little ceremony.
The chameleon logo performs the same function. It tells a user, before any hash check or release-note review, that this is the thing they meant to get. If a new port borrows the name and the mascot, a disclaimer tucked into a webpage cannot do all the work of unwinding that first impression.
That is why Ho’s complaint lands harder than a mere trademark squabble. He is not objecting to Mac users benefiting from Notepad++ code. He is objecting to the use of the Notepad++ brand as a distribution accelerant for a project he does not maintain, cannot validate, and did not authorize.
This is where software identity becomes a UX problem. Users do not read pages like lawyers. They scan the domain, the logo, the name, a download button, and maybe a sentence near the top. If all the high-signal elements say “official,” a low-signal disclaimer saying “independent” is not enough.
The media reaction proved the point. Coverage and community posts quickly treated the port as the long-awaited arrival of Notepad++ on macOS, rather than a third-party derivative. That was not merely a misunderstanding by inattentive readers; it was the foreseeable result of branding that leaned heavily on the original project’s recognizability.
Ho’s irritation at being placed on the author page is also easy to understand. Credit is not the same as authorship in an active product. A reader seeing Ho’s name and photo in the context of a Mac app could reasonably conclude that the original maintainer had some role in it, even if the page attempted to explain otherwise.
That status makes the Mac dispute more sensitive than it might look from the outside. Notepad++ is not merely a set of source files; it is a Windows-native application built around assumptions, APIs, workflows, and muscle memory that grew up on Microsoft’s platform. A macOS port can recreate a great deal, but it cannot magically become the official continuation of that lineage just by compiling a native interface around inherited code.
There is also a cultural asymmetry here. Mac users have long had capable native editors, from lightweight tools to full developer environments. Windows users, meanwhile, have treated Notepad++ as one of the platform’s great pieces of freeware infrastructure. Calling a Mac fork “Notepad++ for Mac” does not just describe compatibility; it borrows from a Windows community’s accumulated trust.
That does not mean Notepad++ should remain culturally fenced off from other platforms. Open-source software thrives when people adapt it. But cross-platform ambition is strongest when it is honest about what changed, who maintains it, and where the line runs between upstream and fork.
That context changes the stakes. When a software project has recently had to reassure users about update integrity, the last thing its maintainer needs is a separate site using the project’s name and logo while distributing an unrelated build. Even if the Mac app itself is benign, the pattern is exactly the sort of ambiguity attackers exploit: familiar branding, plausible download, unclear authority.
For IT departments, the lesson is blunt. The officialness of a software package is not an aesthetic concern. It affects patching, inventory, incident response, allowlisting, vendor risk review, and user education. If a helpdesk ticket says “I installed Notepad++ for Mac,” the first question becomes: from where, by whom, signed how, and updated through what channel?
This is why Ho’s use of language like impersonation and phishing should not be dismissed as theatrical. In modern software distribution, identity confusion is an attack surface. A domain name and a logo can be as consequential as an executable, because they guide the user toward the executable in the first place.
The temptation is understandable. If you build a Mac editor inspired by Notepad++, the fastest way to reach people is to call it what they are searching for. “Notepad++ for Mac” is a perfect SEO phrase, a perfect Reddit headline, and a perfect download-page conversion tool. It is also exactly why the phrase is dangerous when the original project has not authorized it.
Open-source forks face this problem constantly. A good fork needs to signal lineage without implying endorsement. The honest formula is usually something like “based on,” “inspired by,” or “compatible with,” paired with a distinct name, distinct logo, and a conspicuous statement that the project is independently maintained.
That is less efficient marketing. It is also the price of not trading on someone else’s reputation. If the Mac port is good, it can earn its own identity. If it needs the original name to be noticed, then the original maintainer’s objection becomes even stronger.
The domain issue is harder. A site living at a Notepad++-themed address continues to capture users searching for the official project, even if the page itself now says Nextpad++. Ho reportedly requested that the domain change as well, and Letov’s site indicated a move to a new domain was imminent. That matters because domains are among the strongest signals ordinary users understand.
A clean rebrand would do several things at once. It would move to a distinct domain, use a distinct app name, remove the original logo entirely, clarify the relationship to upstream in plain language, and explain how updates are signed and delivered. It would credit Notepad++ without making Ho look like a participant.
This is not just about appeasing a trademark holder. It is about giving the new Mac project a chance to stand on firmer ground. A fork that begins life under a cloud of confusion may struggle to win the trust of the very users it wants to serve.
But porting a beloved Windows utility is not merely a technical exercise. Notepad++ grew out of the Win32 world, and any native macOS version must make decisions about interface conventions, file handling, plugin compatibility, keyboard behavior, signing, notarization, and update distribution. At some point, the port becomes its own product, even if the source lineage remains obvious.
That independence is not a weakness. It is a responsibility. A Mac-native Notepad++-like editor should be judged on how well it serves Mac users, not on how convincingly it wears a Windows project’s costume. If Nextpad++ wants to be taken seriously, it should embrace that reality rather than blur it.
There is a broader irony here. The Mac community often prizes polished, well-signed, provenance-conscious apps. A project that arrives with brand confusion and a public trademark dispute undermines precisely the kind of trust Mac users expect from native software. The code may be open, but the relationship must be legible.
Software supply-chain risk is often discussed in terms of dependency confusion, compromised packages, poisoned updates, and malicious maintainers. Those are real threats. But brand confusion is the softer front door to the same building. Before a user can run the wrong binary, they often have to be persuaded that it is the right binary.
This is why enterprise controls increasingly need to care about source, not just category. “Text editor” is not a sufficient approval. The relevant questions are whether the package is official, whether it is signed by the expected publisher, whether updates come from a trusted channel, and whether the maintainer relationship is clear.
The Notepad++ Mac incident is almost a lab specimen for that problem. The app was presented as a Mac version of a trusted Windows editor, discussed as a long-awaited official arrival, and then disowned by the original author. That does not make it malware. It does make it a case study in why identity and distribution must be part of software review.
Open source gives users and developers freedoms that proprietary software withholds. It does not require maintainers to surrender the project’s public identity to anyone who can compile a derivative build. In fact, many open-source ecosystems depend on trademark boundaries precisely because forks are allowed. If anyone can fork, users need a way to tell which build is upstream, which is downstream, and which is unrelated.
Linux distributions, browser projects, office suites, and programming language ecosystems have all wrestled with versions of this problem. The healthier projects do not pretend names are irrelevant. They create rules that let derivatives flourish without making users guess who is responsible for what.
Ho’s stance fits that tradition. He did not say Mac users must not benefit from the code. He said the Mac project must not use the Notepad++ name and logo in a way that confuses users. That is not hostility to open source. It is maintenance of the trust boundary that makes open source usable by people who are not reading every commit.
A familiar logo on an unfamiliar platform sends a strong message: this is the same project, merely adapted. That is exactly the message Ho rejected. He does not own a Mac, did not ship a Mac build, and was not maintaining the port. The chameleon, in that context, was doing more than decorating a website; it was vouching for something the original project had not vouched for.
The author-page problem compounded it. Including Ho’s name and image may have been intended as attribution, but attribution in a download context is delicate. If the page lists a project founder among authors, many users will not parse the difference between “created the original codebase” and “participates in this product.”
That is why open-source credit needs careful language. “Based on the Notepad++ project created by Don Ho” is different from placing Ho in an author roster for the Mac app. The former explains lineage. The latter risks implying involvement.
It also skips the most important word: unofficial. In software coverage, that omission is not trivial. Readers often encounter the headline before they encounter the caveat, and in many cases they never get beyond the headline at all. By the time Ho responded, the confusion had already escaped its container.
This is not a call for every article about a fork to become a licensing seminar. But it is a call for precision when a project’s original maintainer is not involved. “Unofficial Mac port” is not less interesting; it is more accurate. It tells the reader what happened without smuggling in endorsement.
The episode should embarrass more than one party. A developer leaned too hard on a famous identity. Media and social posts amplified the most exciting interpretation. Users were left to sort out the difference after the original maintainer had to object in public.
That world has not disappeared, but the risk model has changed. Small tools now sit inside enterprise environments, developer workflows, privileged sessions, and code repositories. A compromised editor or fake update path can be more consequential than its humble interface suggests.
The Notepad++ update-server incident earlier this year already showed how attractive a target a trusted utility can become. A fake or confusing Mac distribution channel sits in the same conceptual neighborhood, even if there is no allegation that Letov’s port was malicious. Trust in small tools is now part of the larger software supply chain.
For sysadmins, this means nostalgia is not a policy. The fact that a tool has been beloved for decades does not remove the need to verify where it came from. The fact that a fork is open source does not remove the need to understand who signs it, who updates it, and who answers when something breaks.
A fork can share code lineage with Notepad++ while having a separate identity. It can credit Don Ho while making clear that Ho is not maintaining it. It can serve Mac users while admitting that it is not the official Notepad++ release. Those distinctions are not pedantry; they are the map users need in order to make informed trust decisions.
The concrete lessons are simple enough to survive outside this particular fight.
The larger lesson is that open source works best when freedom and responsibility travel together. Developers should be free to port, remix, and extend beloved tools, and users should be free to benefit from that work. But the name on the tin still matters, especially in a software world where the tin is often all a user sees before clicking download. If Nextpad++ grows into a respected Mac editor, it will be because it finally stepped out from behind Notepad++’s identity and gave users something cleaner: a fork they can recognize as a fork, maintained by the people actually shipping it.
Source: PCMag Australia NotePad++ Dev Slams Mac Version As Unauthorized and 'Frankly Disrespectful'
The Mac Port Was Legal Enough to Exist, but Not Honest Enough to Wear the Badge
The developer behind the macOS app, New York software engineer Andrey Letov, appears to have done what open-source licenses are meant to permit: he took free and open-source code, built something useful, and tried to extend a popular tool to a platform that never had an official native version. That part is not scandalous. The GPL is designed to allow modification and redistribution, and Ho himself acknowledged that a fork or port is not the problem.The trouble began when the port was presented as “Notepad++ for Mac,” used the familiar chameleon logo, and placed Ho on an author page in a way that, even with disclaimers elsewhere, made the project look blessed by the original maintainer. It did not take much for the internet’s headline machine to do the rest. Reddit posts and tech coverage framed the app as if Notepad++ had finally crossed the macOS border after more than two decades.
Ho’s response was unusually blunt, but the substance was straightforward. Notepad++ has never released a macOS version. The Mac app was not authorized, not endorsed, and not affiliated with the project. In Ho’s view, the site’s use of the Notepad++ trademark and logo crossed from homage into impersonation.
Letov, for his part, said he intended to credit Ho rather than imply Ho’s involvement. That is plausible as human intent and still inadequate as software distribution practice. In open source, good intentions do not erase confusing packaging, especially when the confusion is predictable and commercially useful.
Open Source Does Not Mean Open Season on Identity
This is the point too often lost in arguments about free software. A license can let you copy code without letting you copy the project’s identity. The law and the culture of open source have long distinguished between the right to fork and the right to pass your fork off as the original.That distinction matters because a project’s name is not decorative. It is the mental shortcut users rely on when deciding whether to download, install, trust, and update software. A name like Notepad++ carries 20-plus years of accumulated credibility among Windows users, developers, hobbyists, and sysadmins who have installed it on countless machines with little ceremony.
The chameleon logo performs the same function. It tells a user, before any hash check or release-note review, that this is the thing they meant to get. If a new port borrows the name and the mascot, a disclaimer tucked into a webpage cannot do all the work of unwinding that first impression.
That is why Ho’s complaint lands harder than a mere trademark squabble. He is not objecting to Mac users benefiting from Notepad++ code. He is objecting to the use of the Notepad++ brand as a distribution accelerant for a project he does not maintain, cannot validate, and did not authorize.
The Disclaimers Were Fighting the Headline, and the Headline Won
Letov’s site reportedly described the app as an independent community port with no official affiliation. That sounds responsible until you look at the totality of the presentation. “Notepad++ for Mac” is not a neutral phrase; it is the phrase a user would naturally type if they were looking for an official Mac release.This is where software identity becomes a UX problem. Users do not read pages like lawyers. They scan the domain, the logo, the name, a download button, and maybe a sentence near the top. If all the high-signal elements say “official,” a low-signal disclaimer saying “independent” is not enough.
The media reaction proved the point. Coverage and community posts quickly treated the port as the long-awaited arrival of Notepad++ on macOS, rather than a third-party derivative. That was not merely a misunderstanding by inattentive readers; it was the foreseeable result of branding that leaned heavily on the original project’s recognizability.
Ho’s irritation at being placed on the author page is also easy to understand. Credit is not the same as authorship in an active product. A reader seeing Ho’s name and photo in the context of a Mac app could reasonably conclude that the original maintainer had some role in it, even if the page attempted to explain otherwise.
Notepad++ Is a Windows Institution, Not Just a Codebase
Notepad++ occupies a strange and durable place in the Windows ecosystem. It is not glamorous software. It is not the editor that launches keynote demos or developer influencer threads. It is the utility you find on admin workstations, developer laptops, lab machines, and rescue environments because it is fast, familiar, and just powerful enough without becoming a lifestyle choice.That status makes the Mac dispute more sensitive than it might look from the outside. Notepad++ is not merely a set of source files; it is a Windows-native application built around assumptions, APIs, workflows, and muscle memory that grew up on Microsoft’s platform. A macOS port can recreate a great deal, but it cannot magically become the official continuation of that lineage just by compiling a native interface around inherited code.
There is also a cultural asymmetry here. Mac users have long had capable native editors, from lightweight tools to full developer environments. Windows users, meanwhile, have treated Notepad++ as one of the platform’s great pieces of freeware infrastructure. Calling a Mac fork “Notepad++ for Mac” does not just describe compatibility; it borrows from a Windows community’s accumulated trust.
That does not mean Notepad++ should remain culturally fenced off from other platforms. Open-source software thrives when people adapt it. But cross-platform ambition is strongest when it is honest about what changed, who maintains it, and where the line runs between upstream and fork.
The Security Context Makes the Branding Fight Less Petty
If this dispute had happened in a vacuum, it might have looked like the usual open-source etiquette flameout: one maintainer, one enthusiastic fork, one argument over names. But Notepad++ has recently been part of a much darker story. Earlier this year, the project disclosed that attackers had compromised its update infrastructure in a targeted campaign that reportedly redirected some users toward malicious installers during 2025.That context changes the stakes. When a software project has recently had to reassure users about update integrity, the last thing its maintainer needs is a separate site using the project’s name and logo while distributing an unrelated build. Even if the Mac app itself is benign, the pattern is exactly the sort of ambiguity attackers exploit: familiar branding, plausible download, unclear authority.
For IT departments, the lesson is blunt. The officialness of a software package is not an aesthetic concern. It affects patching, inventory, incident response, allowlisting, vendor risk review, and user education. If a helpdesk ticket says “I installed Notepad++ for Mac,” the first question becomes: from where, by whom, signed how, and updated through what channel?
This is why Ho’s use of language like impersonation and phishing should not be dismissed as theatrical. In modern software distribution, identity confusion is an attack surface. A domain name and a logo can be as consequential as an executable, because they guide the user toward the executable in the first place.
The Fork Author’s Mistake Was Confusing Reach With Legitimacy
Letov’s defense is revealing. He said he wanted to make a free Mac version easier for users to find and hoped to expand the Notepad++ brand. That sounds generous, but it assumes the brand is a commons in the same way the code is. It is not.The temptation is understandable. If you build a Mac editor inspired by Notepad++, the fastest way to reach people is to call it what they are searching for. “Notepad++ for Mac” is a perfect SEO phrase, a perfect Reddit headline, and a perfect download-page conversion tool. It is also exactly why the phrase is dangerous when the original project has not authorized it.
Open-source forks face this problem constantly. A good fork needs to signal lineage without implying endorsement. The honest formula is usually something like “based on,” “inspired by,” or “compatible with,” paired with a distinct name, distinct logo, and a conspicuous statement that the project is independently maintained.
That is less efficient marketing. It is also the price of not trading on someone else’s reputation. If the Mac port is good, it can earn its own identity. If it needs the original name to be noticed, then the original maintainer’s objection becomes even stronger.
The Rebrand Was Inevitable, but the Domain Still Matters
The Mac project has since moved toward the name Nextpad++ and replaced the chameleon with a frog. That is the right direction, though the “++” suffix and proximity to the original name will keep inviting scrutiny. In software, a rebrand is not just a new icon; it is a reset of expectations.The domain issue is harder. A site living at a Notepad++-themed address continues to capture users searching for the official project, even if the page itself now says Nextpad++. Ho reportedly requested that the domain change as well, and Letov’s site indicated a move to a new domain was imminent. That matters because domains are among the strongest signals ordinary users understand.
A clean rebrand would do several things at once. It would move to a distinct domain, use a distinct app name, remove the original logo entirely, clarify the relationship to upstream in plain language, and explain how updates are signed and delivered. It would credit Notepad++ without making Ho look like a participant.
This is not just about appeasing a trademark holder. It is about giving the new Mac project a chance to stand on firmer ground. A fork that begins life under a cloud of confusion may struggle to win the trust of the very users it wants to serve.
Mac Users Wanted a Native Notepad++, but They Got a Governance Lesson
The appetite for a Mac version is real. Notepad++ has existed since 2003, and its absence from macOS has been a recurring frustration for users who move between Windows and Apple hardware. For many, the appeal is not ideological; they simply want the same fast editor, the same habits, and the same lightweight feel on every machine.But porting a beloved Windows utility is not merely a technical exercise. Notepad++ grew out of the Win32 world, and any native macOS version must make decisions about interface conventions, file handling, plugin compatibility, keyboard behavior, signing, notarization, and update distribution. At some point, the port becomes its own product, even if the source lineage remains obvious.
That independence is not a weakness. It is a responsibility. A Mac-native Notepad++-like editor should be judged on how well it serves Mac users, not on how convincingly it wears a Windows project’s costume. If Nextpad++ wants to be taken seriously, it should embrace that reality rather than blur it.
There is a broader irony here. The Mac community often prizes polished, well-signed, provenance-conscious apps. A project that arrives with brand confusion and a public trademark dispute undermines precisely the kind of trust Mac users expect from native software. The code may be open, but the relationship must be legible.
Windows Admins Should Treat This as a Supply-Chain Parable
For WindowsForum readers, the immediate practical impact may be limited. Notepad++ for Windows remains the official project, and Ho’s complaint is about a macOS port. But the pattern is familiar to anyone who has managed software at scale: users search the web, click the thing that looks right, and bring the consequences to IT later.Software supply-chain risk is often discussed in terms of dependency confusion, compromised packages, poisoned updates, and malicious maintainers. Those are real threats. But brand confusion is the softer front door to the same building. Before a user can run the wrong binary, they often have to be persuaded that it is the right binary.
This is why enterprise controls increasingly need to care about source, not just category. “Text editor” is not a sufficient approval. The relevant questions are whether the package is official, whether it is signed by the expected publisher, whether updates come from a trusted channel, and whether the maintainer relationship is clear.
The Notepad++ Mac incident is almost a lab specimen for that problem. The app was presented as a Mac version of a trusted Windows editor, discussed as a long-awaited official arrival, and then disowned by the original author. That does not make it malware. It does make it a case study in why identity and distribution must be part of software review.
Trademark Enforcement Is Not Anti-Open-Source
Some developers bristle when maintainers enforce trademarks, especially in communities built around permissive collaboration. The reaction is predictable: if the code is free, why police the name? But that objection misunderstands the bargain.Open source gives users and developers freedoms that proprietary software withholds. It does not require maintainers to surrender the project’s public identity to anyone who can compile a derivative build. In fact, many open-source ecosystems depend on trademark boundaries precisely because forks are allowed. If anyone can fork, users need a way to tell which build is upstream, which is downstream, and which is unrelated.
Linux distributions, browser projects, office suites, and programming language ecosystems have all wrestled with versions of this problem. The healthier projects do not pretend names are irrelevant. They create rules that let derivatives flourish without making users guess who is responsible for what.
Ho’s stance fits that tradition. He did not say Mac users must not benefit from the code. He said the Mac project must not use the Notepad++ name and logo in a way that confuses users. That is not hostility to open source. It is maintenance of the trust boundary that makes open source usable by people who are not reading every commit.
The Chameleon Cannot Be the Installer
The most important artifact in this dispute is not a line of code. It is the chameleon. Logos compress trust into an image, and that compression is powerful enough to move users from curiosity to installation.A familiar logo on an unfamiliar platform sends a strong message: this is the same project, merely adapted. That is exactly the message Ho rejected. He does not own a Mac, did not ship a Mac build, and was not maintaining the port. The chameleon, in that context, was doing more than decorating a website; it was vouching for something the original project had not vouched for.
The author-page problem compounded it. Including Ho’s name and image may have been intended as attribution, but attribution in a download context is delicate. If the page lists a project founder among authors, many users will not parse the difference between “created the original codebase” and “participates in this product.”
That is why open-source credit needs careful language. “Based on the Notepad++ project created by Don Ho” is different from placing Ho in an author roster for the Mac app. The former explains lineage. The latter risks implying involvement.
The Tech Press Also Helped Make the Mess
It is easy to put all the blame on the Mac port’s branding, but the press and social platforms played their part. The phrase “Notepad++ comes to Mac after 20 years” is irresistible because it turns a port into a narrative. It has longing, surprise, and platform drama in one line.It also skips the most important word: unofficial. In software coverage, that omission is not trivial. Readers often encounter the headline before they encounter the caveat, and in many cases they never get beyond the headline at all. By the time Ho responded, the confusion had already escaped its container.
This is not a call for every article about a fork to become a licensing seminar. But it is a call for precision when a project’s original maintainer is not involved. “Unofficial Mac port” is not less interesting; it is more accurate. It tells the reader what happened without smuggling in endorsement.
The episode should embarrass more than one party. A developer leaned too hard on a famous identity. Media and social posts amplified the most exciting interpretation. Users were left to sort out the difference after the original maintainer had to object in public.
The Trust Model for Small Tools Has Changed
Notepad++ belongs to a class of software that users historically installed casually. Text editors, archive utilities, screenshot tools, media players, terminal helpers — these were the small conveniences that made a machine feel usable. Many of them were distributed by small teams or individual maintainers and spread by word of mouth.That world has not disappeared, but the risk model has changed. Small tools now sit inside enterprise environments, developer workflows, privileged sessions, and code repositories. A compromised editor or fake update path can be more consequential than its humble interface suggests.
The Notepad++ update-server incident earlier this year already showed how attractive a target a trusted utility can become. A fake or confusing Mac distribution channel sits in the same conceptual neighborhood, even if there is no allegation that Letov’s port was malicious. Trust in small tools is now part of the larger software supply chain.
For sysadmins, this means nostalgia is not a policy. The fact that a tool has been beloved for decades does not remove the need to verify where it came from. The fact that a fork is open source does not remove the need to understand who signs it, who updates it, and who answers when something breaks.
The Lesson Hidden Inside the Nextpad++ Name Change
The rebrand to Nextpad++ may end the immediate conflict, but it should not end the discussion. This episode usefully separates three things that users often collapse into one: code lineage, project identity, and maintainer responsibility.A fork can share code lineage with Notepad++ while having a separate identity. It can credit Don Ho while making clear that Ho is not maintaining it. It can serve Mac users while admitting that it is not the official Notepad++ release. Those distinctions are not pedantry; they are the map users need in order to make informed trust decisions.
The concrete lessons are simple enough to survive outside this particular fight.
- A GPL project can be forked or ported, but the original project’s name and logo are not automatically part of the license grant.
- A disclaimer cannot reliably cure branding that otherwise makes an unofficial app look official.
- A fork should use a distinct name, logo, domain, signing identity, and update channel from the upstream project.
- Media coverage should put “unofficial” in the first breath when a beloved project’s maintainer is not involved.
- IT teams should treat confusing provenance as a software risk even when there is no evidence of malware.
- The Notepad++ Windows project has not released an official macOS version, regardless of how polished a third-party port may appear.
The larger lesson is that open source works best when freedom and responsibility travel together. Developers should be free to port, remix, and extend beloved tools, and users should be free to benefit from that work. But the name on the tin still matters, especially in a software world where the tin is often all a user sees before clicking download. If Nextpad++ grows into a respected Mac editor, it will be because it finally stepped out from behind Notepad++’s identity and gave users something cleaner: a fork they can recognize as a fork, maintained by the people actually shipping it.
Source: PCMag Australia NotePad++ Dev Slams Mac Version As Unauthorized and 'Frankly Disrespectful'