Releasing my tools under the MIT License was probably a mistake (2023)

Original Article ↗ Hacker News Discussion ↗

Open‑source developers debate whether permissive licenses like MIT unintentionally enable SEO squatters and ad‑laden copycat sites to rehost web tools, sometimes outranking and commercially exploiting the original creators. Many argue that stricter licenses (GPL/AGPL), trademarks, or DMCA takedowns offer only limited practical protection against bad actors, and that authors must choose licenses based on whether they truly accept unrestricted reuse—even in ways they dislike. Others suggest a pragmatic split: keep emotionally or commercially important projects closed or copylefted, and reserve permissive licensing for code you’re comfortable seeing used without prominent attribution.

Scope of the Problem (SEO Clones & Monetization)

  • Many commenters restate the situation: MIT-licensed tools are being cloned, lightly modified, wrapped in ads/SEO spam, and sometimes outrank the original site.
  • Some view this as emotionally frustrating but logically consistent with permissive licensing.
  • Several argue that “SEO squatters will squat regardless of license,” so changing licenses may not solve the core problem.

MIT License, Attribution, and Enforcement

  • Multiple comments note MIT does require preserving the copyright notice, but:
    • It only applies when the software is distributed, not when it’s merely used server-side.
    • Attribution can be buried in source or archives; no requirement for visible UI credit.
  • Some suggest DMCA takedowns when license terms are violated; others doubt it’s worth the effort or effective against low-effort clones.

Copyleft vs Permissive (GPL/AGPL/LGPL/BSD/Apache)

  • One camp: GPL/AGPL or LGPL are better fits when you want modifications to remain open and to discourage freeloaders.
  • Another camp: even AGPL would not meaningfully prevent the described SEO/ads behavior, since minimal compliance (buried links, small notices) is enough.
  • Some see copyleft as “poisonous” or anti-freedom; others see it as a necessary tool to preserve openness and counter market pressures.
  • There is disagreement on how often AGPL actually deters “parasites” in practice.

Definitions: “Free” and “Open Source”

  • Long subthread debates who gets to define “free” and “open source.”
  • One side insists on FSF/OSI definitions (no discrimination by field of use, ads allowed).
  • Others argue common-language use of “free/open” is broader and that people can legitimately choose non-OSI or “source-available” terms.

Alternatives: Closed Source, Trademarks, and Licensing Strategy

  • Some say: if you don’t want this kind of reuse, don’t open source the tool at all; keep some projects private and others permissively licensed.
  • Trademarks are proposed to control use of the project name and branding, separate from code licensing.
  • Relicensing is discussed; it may be complicated if there are external contributors.
  • CC licenses for code are discouraged; people ask for a “CC-BY-like for code,” but thread consensus is that standard software licenses don’t perfectly match that desire.