22 日晚，Apache SkyWalking Founder 吳晟在朋友圈中指出，因違反開源協議要求，SkyWalking 只能暫時拒絕針對唯品會 Saturn 項目的插件需求。
Saturn 是 fork 自 ElasticJob，並更改了版權資訊，這是一個非常嚴重的許可證問題。基於 ElasticJob 的原始許可證 Apache 2.0 ，所有文件的 header 都應該保留，即便他們修改了代碼。所以，無論你或是任何人想要做這個插件，我們都不能正式接受它作為 Apache SkyWalking 的一部分。如果你認識他們，請聯繫他們。只有在他們糾正了許可證問題，並且回滾了所有的 header 之後，我們才能支持他們的新版本。
我們聯繫吳晟了解相關情況，根據他的說法，他在查看 Saturn 源碼時，發現項目實際上是 fork 自當當網的 ElasticJob。
ElasticJob 採用的 Apache 2.0 開源許可協議。根據 Apache 2.0 協議的要求，衍生項目需要在源碼中有明確標識，說明此項目是 fork 自 ElasticJob ，一般就是在使用到的源碼上保留原始附加版權資訊，方可進行二次分發。
也就是說，Saturn 需要保留原項目文檔中的版權 header 說明，聲明噹噹的原始版權。但吳晟發現，Saturn 項目大部分文檔中並沒有聲明版權歸 ElasticJob。
這相當於，Saturn 複製了一遍 ElasticJob 的源碼，並自行修改，但沒有很好地尊重 ElasticJob 的版權。嚴格來看，類似「抄襲」原始碼行為。
此時 Saturn 要提交給 SkyWalking，SkyWalking 認為它在「開源」約定上是不合規的，就拒絕了。
吳晟表示，Saturn 想要更正這個問題，工作量會非常大，首先需要把所有來自 ElasticJob 的源文件全部退回噹噹的 header，在庫裡聲明，這是基於噹噹版本 ElasticJob 二次分發的一個版本。更正後需要重新發布一個 release 版本，「基於這個 release 版本，SkyWalking 肯定是可以接受它的插件到官方庫的。之前的所有版本都不合規，如果不修正，那麼實際上就是一直存在版權問題，不僅影響自身在開源上更好地發展，也會給其它準備和已經使用了它的項目帶來困擾。」
不過吳晟認為，Saturn 應當沒有「抄襲」源碼的初心，因為 Saturn 的代碼庫中有標註一個致謝信息，說明項目來自噹噹的 ElasticJob，並感謝軟體核心開發者/發起人張亮。（編者註：ElasticJob 已經捐贈給 Apache 基金會，版權也隨之屬於 Apache 基金會）
所以可以假定 Saturn 並沒有故意隱瞞項目來源於 ElasticJob 的事實，假裝原創，但由於它是一個 fork 項目，所以必須按照協議要求，保留原始版權聲明，而不是只在結尾致謝。
整件事情對於開發者來說很有教育意義，尤其是在做開源開發時，必須要了解開源協議。開源軟體本身的存在就是為了給用戶自由，開源協議雖然各有不同，但最基本的要求往往都是尊重軟體版權。
Saturn 沒有正確保留版權聲明，致使目前所有版本都不合規，對自己和使用它的項目都造成了一定的影響。
近期也有一例不符合 Apache 2.0 協議引發的事故。6月，雲計算解決方案服務商博雲，因為使用了 SkyWalking，卻未按照 Apache 2.0 協議的要求，在顯著位置說明項目使用了 SkyWalking，被 Apache 基金會披露。事後博雲方面回應稱，他們對外一直公開說是基於 SkyWalking，並沒有把 SkyWalking 裝扮成自己產品的意思，「我們這次事幹得粗糙了。」
從 Saturn 的庫和博雲的回覆來看，兩件事或許都是不懂協議造成的。
兩件事涉及到的 Apache 2.0 協議是 ASF 在2004年發布的，屬於寬鬆型協議。今年5月，《大教堂與集市》的經典中文版本譯者衛劍釩用一句話總結了 Apache 協議的要旨：「要留我的名，改哪了你得說！」，並解讀 Apache 協議精要：
你可以隨便用！不會因版權和專利找你麻煩的！不能用我的商標！你分發本作品或衍生作品時，可以不再提供源碼！你在分發時，必須做到：1、帶上本許可證！2、保留本軟體的所有版權、專利等說明！3、你改過的文件，你得說改了哪！4、NOTICE 文件中的信息得保留！5、在遵循本許可證的條件下，你可以再許可！本作品就這樣了，我不會負任何責任的！你想負責你可以負，但別拉上我！
「授權只是給你使用，並不是授權無限制地剝奪人家的著作權」，吳晟表示，fork 了別人的東西時，不能改掉別人的 License 聲明，這應該屬於強制性的東西。
實際上，聲明版權只是協議的一項基本要求，一些更嚴格的協議，如 GPL 會要求採用了 GPL 協議軟體的整個軟體包也必須開源。現在，通過 OSI 認證的協議已有近百個，雖然這可能會使開源軟體的使用變得複雜，但也保障了開源軟體及其作者的基本權益。違反開源協議輕則會被公開批評、重則會導致項目因合規問題無法登上更大的開源舞臺，甚至有可能引發訴訟。
開發者在使用一個開源軟體時，首先要做的，或許就是去了解它的開源協議。