本文採 CC-BY-SA-3.0-TW+ 授權發布

這週和下週有三場規劃給三家合作廠商的開源內訓，因為近期的事件，Apache-2.0專案的合規熱度，直接拉滿，也被詢問是否能就此事，增補內訓簡報的內容。其實Apache-2.0是寬鬆的自由開源軟體授權條款，除了特殊的「軟體專利反制條款」以外，其餘相關的原理原則，幾與MIT與BSD一致，一般我將其視為「化簡為繁–來補述MIT、BSD灰色地帶的擴充條款」，但本質上的寬鬆性是一致的。

以下是就這個主題補充簡報的要點：

一、透過開源管理政策判定來思索情境，是要將改作後的開源專案，由FOSS轉非FOSS型態使用(就是閉源啦！)，還是繼續維持FOSS型態使用。

甘瓜苦蒂、天下物無全美，開源有開源的好、閉源有閉源的坎，不過無論如何，管理與轉換之間，必須要合法合規。所以說，如果組織的管理政策是偏向閉源，那建議將原開源專案成果，移至private repo來進行延續開發，此時原專案若帶copyleft特性(GPL/LGPL/AGPL/MPL/EPL/CDDL)，則必須註記未來僅得於組織內部使用(internal-use only)，不得讓公司外部人員接觸，例如晶片品質良率監管分析程式；而若原專案為permissive類別開源軟體(BSD/MIT/Apache-2.0)，則應備妥CD(Copyright Notice + Disclaimer)、授權條款全文(license text)，以及登錄原專案相關的其他顯名聲明，這些資訊，當未來該專案轉object form會同其他產品出貨時，皆應該被披露尊重。

而若是組織的管理政策，可透過開源政策吸引外部助力，或就是公務相關專案，定調將採開源模式帶動跨界協力開發，那相關專案可以延續在public repo進行延續開發，最簡單的方式就是透過原託管平台的fork功能直接fork一份，但也並不是fork之後就直接動手開發，而是應該考量(1)fork之後是否延續原授權？需不需轉換為其他開源授權？

(2)是否修改專案名稱來避免與原專案產生混淆，以及(3)將前手的貢獻寫入CONTRIBUTION或NOTICE這類專責尊重的相關文件裡。而若是跨平台、跨版本控制系統、或是只需要抄錄部份程式碼而毋須全專案forking的狀況，則下載原專案的程式源碼，適當調校刪減之後採migrate模式上傳另外的開發平台，此時一樣備妥CD(Copyright Notice + Disclaimer)、授權條款全文(license text)，以及登錄原專案相關的其他顯名聲明，這些資訊，未來延續開發都會用到。開源軟體是能夠自由地轉換託管平台的，並不是說站內forking一定優於另案migrating，但兩個模式的差異處理，應評估其利弊得失。

二、著作權聲明、免責聲明、授權條款全文、程式(檔案)修改註記、以及copyleft類型的對應源碼

當開源軟體被發布或配合其他產品發布時，要做的相關義務基本上就是這五點。輕簡型的MIT、BSD、Apache-2.0專案，其著作權聲明、免責聲明原則上都會併入「授權條款全文」或code header裡進行展示，著作權聲明通常在條款的上緣或code header、免責聲明就是條款大寫粗體的免責條款，所以說只要確認授權條款有隨同散布，那基本上這三點幾乎就可以做齊。然後程式(檔案)修改註記是GPL系列、Apache-2.0授權的共同要求，雖然其他開源授權條款不一定要求，但常態性去做好這塊能避免掛一漏萬，最後就是copyleft類型的corresponding source，若是沒有隨同產品提供，就是另起一份written offer給受眾，讓受眾需要時，能索取。

三、以Apache-2.0為例進行授權資訊尊重與收斂

改作他人的Apache-2.0授權專案，是不是必須延用原專案的LICENSE TEXT？其實答案是，要、也不要。所謂「要」，指的是就是依原專案規模開發，所以相關管理都採最小異動處理，這時候本來「著作權聲明、免責聲明、授權條款全文」就是三者都綁定在LICENSE TEXT三位一體，那若是想要增加著作權聲明的表述，自然使用原專案的LICENSE TEXT，在上面增加資訊即可。那什麼時候「不要」？是當專案規模擴大，或是專案僅取原Apache-2.0授權專案一部份的程式碼，而另行加寫或加入其他專案的成果，此時Apache-2.0的設計機制，是透過NOTICE.txt這個文件來統合相關資訊，在這種模式，就是另起一份Apache-2.0 LICENSE TEXT的標準模板，然後將相關的著作權、專利、商標、及其他顯名聲明都從原出處，移到NOTICE.txt的內容來。所以是這樣，Apache-2.0並沒有硬性要求專案的原作者，一定要建立NOTICE檔案，原作者也可以依MIT、BSD的習慣，把著作權聲明及相關聲明直接寫到LICENSE TEXT裡，但若是原作者已經建立了NOTICE檔案，那後手續作者原則上就應該就這個NOTICE檔案，來做相關資訊的匯整和更新，此外，若原作者沒有建立NOTICE.txt，後手其實也可以從他接手開發時，主動去產出這個NOTICE.txt，將原專案散見各處的聲明，統一寫到NOTICE.txt來進行維護，這算是開源專案由輕簡到繁大的調整過程。這樣收斂性的整理，也可參見Android Open Source Project的表列方式。

畢竟，當一個系統裡內含數十、數百個Apache-2.0授權專案，沒有理由不讓這些專案共享一份授權條款，來簡化管理也減輕儲存空間。此類在專案歷任開發之後，採NOTICE.txt配合LICENSE.txt作呈現的模式，可參照下列兩圖。

四、為什麼一定要給LICENSE TEXT？

所有的自由開源軟體，都要求散布程式時，必須附隨一份授權條款文本，這是因為開源授權不會撤回、也能自由分流，所以認條款不認平台，來確保其不會被封鎖的自由發展性，該程式能怎麼用，就是依其散布時準據的授權條款。而雖然BSD/MIT/Apache-2.0並不要求必然要將程式源碼分享給後手，然而保有原始授權條款，再配合軟體清單，當可以指示收受程式或產品之人，自行按圖索驥找到原始的開源專案來自力救濟、另行開發，也是確保開源永續的一種方法。

OpenSourceCompliance #ApacheLicense #FOSSManagement #LicenseGovernance #SoftwareReuse