type: decision
status: active
timestamp: 2026-06-24
tags: [decision, policy, forks, chrome-web-store, gpl, licensing]

Shipping a forked extension to Chrome Web Store under our name

GPL-3.0 forks to CWS: keep license, note modified, rename

Shipping a forked extension to Chrome Web Store

When publishing a fork of someone else’s extension under our own Chrome Web Store developer account:

Hard requirements (license-level)

For GPL / AGPL / LGPL forks:

For MIT / BSD / Apache forks: only attribution is required.

For proprietary / no-license / Apple-license-restricted sources: do NOT republish. Hard stop.

Hard requirements (CWS-level)

Soft requirement (API backend)

If the upstream extension talks to upstream’s API (e.g. DeArrow talks to sponsor.ajay.app), check the API ToS. For DeArrow specifically, the API ToS says “free to use for all non browser-extensions” — i.e. browser-extension use needs explicit permission. Two paths:

  1. Ask upstream maintainer by opening an issue on their repo describing the fork + traffic estimate. Free, polite, usually approved if the fork is non-commercial.
  2. Self-host the backend. DeArrow’s API is open-source and stateless (per its docs); the database is downloadable. Hosting costs are minimal (read-only edge cache).

Without either, the fork risks rate-limiting / blocking by upstream at their discretion.

What does NOT need permission

Decision context

This rule was extracted on 2026-06-24 while planning the chirag127/DeArrow-plus CWS upload. Applies to any future fork we might ship to CWS, App Store (different rules — see Apple Developer program separately), Firefox Add-ons, or VS Code Marketplace.


Edit on GitHub · Back to index