# eIsland, a Windows widget with an Apple platform ban

> eIsland is a Dynamic Island style floating widget for Windows, built with Electron, React, and TypeScript, showing weather, synced lyrics, timers, and a small agent workspace. The interesting part is not the widget. It is the licence section, which releases the code under GPLv3 or later and then adds a clause forbidding any Apple platform target, a combination that a downstream user can undo simply by choosing the earlier option.

**JNTMTMTM/eIsland** — eIsland - A sleek, Apple Dynamic Island inspired floating widget for Windows, built with Electron.

- Repository: https://github.com/JNTMTMTM/eIsland
- Website: https://dev.electronisland.com/
- Stars: 320 · Forks: 18
- Language: TypeScript
- License: GPL-3.0
- Published: 2026-09-18 · Updated: 2026-09-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/jntmtmtm-eisland

## The platform ban sits inside a GPLv3 release

The licence section has two halves that pull in opposite directions.

The first half is a release under the GNU General Public License version 3 or later. The second is a platform restriction: the software is developed exclusively for Windows, and any porting, adaptation, or redistribution targeting Apple macOS or any Apple operating system is strictly prohibited by the original author. The restriction is stated to apply to all forks, derivative works, and redistributions, must be retained in full, and violations are threatened with legal action.

The mechanism used to attach it is Section 7(b) of the GPL, which allows additional permissions, conditions, or restrictions beyond the licence text, alongside a requirement that author attributions be retained.

The tension is structural rather than moral. A licence that grants version 3 or later lets any downstream recipient take the same work and re-distribute it under version 3 alone, which means under version 3 without the additional clause. The or-later option exists precisely so that additional terms can be dropped. Two attributions are also required, one for the author and one for a separate site, pyisland.com.

None of this is legal advice. It is the reason to read the LICENSE file rather than the summary before you redistribute anything.

## package.json says GPL-3.0 and the README says or later

The two places that record the licence disagree about the version range.

The README states the project is released under GPLv3 or later and labels it GPL-3.0-or-later. The licence field in package.json is GPL-3.0, which is the identifier for version 3 with no option to move to a later version.

For most consumers that difference is invisible, since version 3 is what anyone will actually use. For tooling it is not: package scanners, dependency review tools, and anything that resolves a package's licence programmatically read the field in package.json, not the prose in a README.

So a repository scan will tell you the code is GPL-3.0 only, while the README tells you it is GPL-3.0-or-later with extra terms. One of those is a machine-readable statement and the other is a human-readable one, and they do not agree.

The project version is in the same file, at 26.7.4, which matches the most recent release tag. The last release was that tag in August 2026 and the last push to main was on 28 September 2026, so roughly a month of commits sit past the tagged build without a version bump in the file.

## Two of the three legal documents are not in the tree

The README points at a legal directory and the top-level listing does not have one.

Three documents are referenced by path: terms of service, a privacy policy, and a billing and refund policy, all under a LEGAL directory. None of those three files appears in the repository's top-level listing, which runs from the dotfiles and the three agent instruction files through assets, docs, i18n, plugins, resources, scripts, sdk, src, test, and web.

That matters more here than it would in a library. A desktop application that syncs lyrics, fetches weather, resolves your location, and includes an agent screen collects enough to need a stated policy, and a billing and refund policy implies money changes hands somewhere in the distribution model. The README asserts that all three exist.

Two possibilities, and the repository does not distinguish them. Either the documents are in the tree and the listing is partial, or they are distributed with the packaged application rather than the source. The second would be normal for a shipped product and wrong for a source repository, because a licence file and a privacy policy are supposed to travel with the code.

Worth resolving before you build on the project, and worth resolving before you file an issue about it.

## Node 25 is the floor and four scripts strip types

The runtime requirement is recent, and the build scripts depend on it.

The engines field asks for Node 25.0.0 or newer. Four scripts invoke node with the experimental strip types flag: the changelog generator, the incremental release notes generator, the object storage upload script, the internationalisation completeness check, and the CDN purge scripts. Running TypeScript directly from node is what that flag enables.

So the repository is not runnable on the Node versions most people still have installed, and the requirement is not incidental. The scripts would fail on an older runtime rather than degrading.

The rest of the script surface is conventional for an Electron project. dev, build, and preview go through electron-vite. test is vitest run, with a coverage variant and one script that runs only the preload test at src/preload/index.test.ts, which is the script worth having a dedicated target for since the preload bridge is the part of an Electron app that the renderer depends on entirely.

There is also a postinstall hook that runs electron-builder install-app-deps, so native modules are rebuilt for the packaged architecture during install rather than at build time. The project uses npm rather than a workspace tool, with a package-lock file and no workspace configuration in the visible tree.

## A release uploads to object storage then purges a CDN

The release pipeline is four commands, and it ends with a cache purge.

The main path packages the application with electron-vite and electron-builder, then runs an upload script, then purges the CDN. There are variants: an upload-only variant that skips the packaging step, and a MinIO variant that uploads to MinIO only and still purges afterwards. A separate script purges by hostname, with an all variant.

Two things follow. First, the upload step is the same script in all three paths with a different destination flag, so a self-hosted distribution only needs the MinIO variant and does not need a second maintenance. Second, purging is coupled to uploading rather than left to a schedule, which is the correct order for a release and means a stale CDN is not a recurring problem after a successful publish.

The short names suggest the CDN is the ESA platform, given that the purge scripts share the same prefix as the upload scripts. Whatever it is, the design decision is visible: uploads go to object storage, delivery goes through a CDN, and the release step owns both.

There is a dev-app-update.yml at the repository root as well, which is the electron-updater configuration for development builds, separate from the release pipeline above.

## A bluetooth helper is a separate plugin with its own build

The plugin directory is not a folder of assets; it contains a separately built package.

One script changes into a plugin directory for a Windows bluetooth helper and runs its own build chain. That plugin has its own package manifest and its own build targets, which means it is a real second package rather than a folder of source files that the main application compiles.

Splitting native and platform-specific work into a plugin with its own build is the right structure for a Windows shell application, because the helper has a different toolchain requirement than an Electron renderer. It also means the repository has more than one install and more than one thing that can be out of date.

The plugin path is named for what it does rather than for where it sits, so it is discoverable from the script name alone.

The rest of the top level shows how much tooling the project carries. There are configuration directories for seven different assistants and editors, plus agent instruction files at the root for three of them. There are separate TypeScript configurations for the node side, the web side, and the eslint integration, an html validation config, a stylelint config, and a vitest config. An internationalisation directory has its own completeness check script, which is the kind of guard that stops a new string from shipping untranslated.

## The wallpaper credit names the camera for each photograph

The image credits section is unusually precise, and it is the clearest writing in the file.

Three wallpapers ship by default and each is credited to a named photograph from the Artemis II mission, with the exact file identifier and the capture device. One is titled Spaceship Earth and was taken on an iPhone 17 Pro Max. Another is titled A Crescent Earth and was taken on a NIKON Z9 with a 35mm lens at f/2. The third is titled Thinking of You, Earth, also on an iPhone 17 Pro Max.

So two of the three default wallpapers were shot on a phone and one on a camera body with a named lens. That detail is there because the source site publishes it, and reproducing it is the correct thing to do.

The attribution is complete in the other direction too. Every icon comes from a single font library rather than from mixed sources, which means there is one licence to satisfy instead of dozens. The images are stated to be used under the space agency's image usage policy, with an explicit note that use does not imply endorsement, and further sources are linked for anyone who wants more.

Three default wallpapers that a photographer shot from orbit, credited to the device, is a more careful default set than most projects ship.

## Conclusion

eIsland is a reasonable choice if you want the Dynamic Island interaction on Windows and do not intend to redistribute it, since the platform restriction only bites when you do. Check four things before you build on it. Whether your Node runtime is 25 or newer, since that is the declared floor and four scripts rely on type stripping. Whether you can accept that the licence metadata and the README disagree about or-later. Whether the icon set and wallpapers carry terms you need to honour, since they come from a font library and from a space agency rather than from the author. And whether you plan to distribute, because that is the only situation where the platform clause becomes a live question and where you would want real legal advice rather than a README.

## FAQ

### What is eIsland and what does it run on?

It is a floating widget for Windows in the style of the Apple Dynamic Island, built with Electron, React, and TypeScript. The README states the software is developed exclusively for Windows and prohibits porting, adaptation, or redistribution targeting Apple macOS or any Apple operating system.

### What does the eIsland app show?

Six screens described in the README: an overview with date, weather, countdowns, and quick launch tools, a weather screen with auto-location and manual configuration, a lyrics screen with automatic matching from multiple sources, a settings screen for appearance and network configuration, an agent screen, and a toolbox panel of utility actions.

### Which Node version does eIsland require?

The engines field in package.json asks for Node 25.0.0 or newer. Several scripts invoke node with the experimental strip types flag to run TypeScript directly, including the changelog, release notes, upload, and internationalisation check scripts.

### Can I port eIsland to macOS?

The README states the opposite: any porting, adaptation, or redistribution targeting Apple macOS or any Apple operating system is strictly prohibited by the original author, applying to all forks, derivative works, and redistributions, with violations subject to legal action.

## Sources

- [JNTMTMTM/eIsland on GitHub](https://github.com/JNTMTMTM/eIsland)
- [License: GPL-3.0](https://github.com/JNTMTMTM/eIsland/blob/main/LICENSE)
- [Project website](https://dev.electronisland.com/)
- [README](https://github.com/JNTMTMTM/eIsland/blob/main/README.md)
- [Releases](https://github.com/JNTMTMTM/eIsland/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/jntmtmtm-eisland