Getting forked by Microsoft

Original Article ↗ Hacker News Discussion ↗

License violation and attribution

  • Many argue Microsoft clearly violated the MIT license by removing the original copyright notice (“The Spegel Authors” / Xenit AB) and substituting “Copyright Microsoft Corporation” in LICENSE and headers.
  • Counterpoint: some note Spegel had only a root LICENSE file and no per‑file headers, and question whether copying without file‑level notices is a “mistake of form” vs. deliberate plagiarism.
  • There’s debate about what counts as “substantial portions of the Software” and where the MIT notice must appear (root license, per file, third‑party notices, etc.), but most agree attribution is the only real condition of MIT, so failing it is serious, not “minor”.

Power, enforcement, and legal realities

  • Multiple comments stress that licenses matter only if you can enforce them; individual maintainers are unlikely to afford litigation against a megacorp.
  • Others point to organizations (FSF, Software Freedom Conservancy, SFLC) that do enforce copyleft, but even then enforcement is costly and slow.
  • Asymmetry: Microsoft has huge legal resources, and even if you win, collecting and covering fees is hard.

Permissive vs. copyleft vs. “fair source”

  • Large faction: permissive licenses (MIT/BSD/Apache) are effectively charity to megacorps; if you don’t want this outcome, use GPL/AGPL or similar.
  • Others argue: the real problem here is that Microsoft ignored even MIT’s minimal terms—changing to GPL wouldn’t stop a company willing to ignore licenses.
  • Some propose non‑OSI “fair source”/revenue‑ or size‑restricted licenses (e.g., NC‑style, market‑cap limits, Polyform, BSL, Llama‑like thresholds) to exclude hyperscalers while remaining friendly to small users.
  • Pushback: such licenses are not “open source” by OSI’s definition and may limit adoption, but advocates say that’s acceptable if it protects maintainers.

Ethics of corporate engagement with OSS

  • Many see a pattern: big vendors set up flattering “collaboration” meetings to extract design knowledge, then reimplement or fork with minimal credit (AppGet/winget, others cited).
  • Some defend Microsoft: peerd adds Azure‑specific features and artifact streaming the author had said were out of scope, so a separate project isn’t inherently wrong—only the missing attribution is.
  • Others frame this as textbook “embrace, extend, extinguish” and “brain‑rape” tactics driven by internal promotion incentives.

Advice to individual maintainers

  • Common themes:
    • Don’t accept unpaid “consultation” with megacorps; quote serious consulting rates or decline.
    • Let corporations interact via normal public channels (issues/PRs), not private meetings, unless there’s a contract.
    • Pick licenses deliberately (often GPL/AGPL for apps, Apache for “permissive but stricter attribution”), and imagine your least‑favorite company doing the worst thing the license allows.
    • Always keep clear copyright/LICENCE notices; many recommend per‑file headers or explicit third‑party notices.

Community reaction and Microsoft’s response

  • Strong emotional reaction: frustration at repeated corporate extraction of unpaid OSS labor, and dismay at commenters normalizing or minimizing license violations.
  • Others caution against assuming malice, suggesting an inexperienced engineer mishandled licensing and attribution.
  • Later in the thread, a Microsoft representative apologizes publicly, calls it an “oversight”, and a PR is raised to amend LICENSE and file headers to credit Xenit/Spegel; critics say this fixes the legal form going forward but doesn’t address the broader power and trust issues.