被微軟分支（fork）收割的經驗 （★ 646 分 🔥）
這次事件主軸為 Spegel 的開源開發者（作者），描述自己與微軟（Microsoft）接洽的經歷：一開始，微軟團隊主動聯絡且表現出合作意願，讓作者感到受到肯定並期待後續協作甚至社群擴展。但最終，微軟選擇單方面將 Spegel 專案「分支」（fork），並推出自家版本 Peerd。更嚴重的是，微軟在重新發佈這個分支時，並未保留 Spegel 原作者的著作權聲明，違反了 MIT 授權條款。作者因此感到受到背叛和利用，並反思開放原始碼授權的局限性。
接續這樣的主題，許多技術社群成員聚焦於 MIT 授權的實際效力及其對大型企業行為的影響。許多評論者強調，雖然 MIT 屬於「寬鬆授權」且允許自由改作、再分發和商用，但對於著作權聲明的保留卻有明文規定。微軟移除原始著作權聲明，形同剽竊功勞並違反授權，無論法律還是倫理層面都不應被接受。不少人認為，即使受害人可採法律途徑維權，現實中面對跨國大企業時，個人開發者在訴訟、證據與費用上毫無對等籌碼，反映出現行開放授權在面對不誠實商業勢力時的「法理 vs. 實踐」窘境。
部分討論主張，若不希望自己的心血被大型企業輕易收割、甚至壟斷成果，應避免使用 MIT 等過於寬鬆的授權，而應考慮 GPL（GNU 通用公共授權）、AGPL（GNU Affero 通用公共授權）等具保護性與「傳染性」（copyleft）條款的開放授權。這類授權可有效要求所有分支及改作必須同樣釋出原始碼並保留著作權歸屬，以減少大企業「擁抱、擴展、消滅」（Embrace, Extend, Extinguish）的濫用空間。但同時也有意見認為，企業之所以偏好 MIT/Apache 等授權，是因為這樣較易合法商用，而若強制擁抱保護性授權，反倒可能抑制社群推廣與普及。
另外有不少聲音指出，個人或社群開發者應在初期就有明確策略及自我保護意識，包含：慎選授權條款、避免無償對大企業提供諮詢、對於諮詢或合作邀約應主動提出合理報酬要求。例如有經驗人士建議，遇到大型企業詢問專案時，直接以顧問費用或專案授權金做為前置條件，甚至不應接受不明確會議，減少自身心力被白白利用的風險。此外，技術圈普遍不滿微軟過去在業界「表面支持 FOSS，實則兼併壟斷」的歷史手法，強調必須對此類「道德風險」保持高度警戒。
最後，討論中亦有開發者感嘆，現有的開源定義及授權機制難以有效反制大企業，若社群內部期望建立「只針對社群、排除企業」或「社群有償」的新型授權，則需面對現行法律、開放定義與開源精神的根本衝突。部分人建議，至少應在原始碼每一檔案內都標註著作權，避免往後分支被移除歸屬；更有人認為，硬性的限制（如貿易條款、從市值或員工數設定商用限制）雖難被主流開源社群接受，卻反映出現代 FOSS 發展面對企業資本霸權時的深層焦慮與無力感。
👥 337 則討論、評論 💬 🔥
https://news.ycombinator.com/item?id=43750535