被 Microsoft「硬分支」：開源維護者與企業不對等的授權困境 https://philiplaine.com/posts/getting-forked-by-microsoft/

原始文章分享了一位 Spegel 專案的單一維護者，因微軟主動聯絡討論合作契機而感到期待，原本希望對方能夠合作或引進新維護者。然而，過程中發現微軟在沒有適當歸屬（attribution）的情況下將 Spegel 的原始碼 fork（複製分支）並去除原作者之著作權標示，違反了 MIT 授權的明確要求。作者認為，雖然本可以選擇較嚴格的授權條款，但現實上即使換授權，最核心的問題在於缺乏執行法律手段的資源。法律保障層面終究很難改變大公司對授權的態度和遵從。

Hacker News 的討論普遍認為，像 MIT 這種寬鬆授權，理論上要求「每個拷貝都須保留原始著作權聲明」，但實務上一旦大企業未遵守，個人很難透過訴訟維權。一些留言進一步說明，條文雖簡單明瞭，執行卻高度仰賴信賴，開源維護者缺乏與大型企業抗衡的財力與法律資源。如此一來，開發者即使選用 MIT 授權，也可能在開源貢獻被重新包裝、歸屬遭抹去時，沒有實質救濟手段，這造成 open source（開源軟體）生態的弱勢方持續處於不利地位。

討論中另有不少意見建議，單一維護者或小團隊開發的專案應慎選授權條款，考慮使用更具 Copyleft（著作權左轉，強制衍生專案也需相同授權）的 GPL、AGPL 等條款來保護自己，這可減少大公司不當利用、強化法律規範力。不過，也有留言指出，即便選用較嚴格的授權，若對方選擇忽略條款，最後仍需要耗費大量時間和金錢維權，而且現行軟體授權並不要求回饋（contribute back），僅強調公開源碼和保留歸屬，有些開發者也樂於專案被廣泛採用。

部分討論者分享過去與大企業互動或遭 fork 的經驗，認為微軟乃至其他科技巨頭長期以來都存在「主動主導、延伸並消滅原創」（Embrace, Extend, Extinguish）的策略，往往先取得 know-how（技術細節、知識），隨後直接另起新專案抄襲、重新命名或包裝為官方產品。此外，有意見提到，Megacorp（超大型企業）仗著龐大資本，通常不擔心授權糾紛，反而要求個人開發者無酬協助甚至提供顧問意見，形同不對等壓榨；有建議指出如能堅持索取合理回報或直接拒絕私下會談，有助於減少被不當利用的風險。

https://news.ycombinator.com/item?id=43750535