只要是採開源授權提供的軟體，基本上只要註引出處，並提供個別條款要求提供的必要源碼，則之後就可以拿它來用於任何目的上。

所以使用開源軟體，產出合規的出處列表是一個基本功，然這個功夫的實踐過程也需要知道一些必要的domain knowledge（領域知識），例如，有時候寬鬆類的授權條款，雖然名稱不同，但A即為B、C即為D或E之類的，說來有趣，事實上不少大型公司的法務同仁，就曾為這樣的問題，造成開源合規列表的產出卡關。

舉例來說，Eclipse Distribution License 1.0，其實即為BSD-3-Clause；而Matplotlib License，亦為基於Python Software Foundation License 2.0 (PSF-2.0)進行更名發布的授權條款，除了條款名稱及發布組織外，前者的條款內容，與後者幾乎完全一致！

為什麼會這樣？主要在於EDL-1.0軟體的發布者，並非加州大學柏克萊分校(UC Berkeley)，而Matplotlib這個專案的開發團隊，也並非Python軟體基金會，所以雖然他們個自認同UC Berkeley或Python基金會撰寫的授權條款，合乎他們使用期待，然實際在軟體發布時，擔心產生發布組織方面的誤解，故而修潤原開源條款，或甚至只是將原條款名稱更換，便稱其為一個新的授權條款。這樣的狀況，發生在MIT License上，更是不勝枚舉。

當在製作開源軟體上下游套件清單，發現這樣的狀況，一般來說我的建議會是：

• 條款全稱上仍登錄原始名稱，例如：Eclipse Distribution License 1.0
• 條款縮寫，例如SPDX Identifier時，留下最常見的條款縮寫，或是兩者並陳，例如：EDL-1.0 (BSD-3-Clause)
• 授權條款全文兩者皆放！例如有些元件採EDL-1.0發布，有些元件採BSD-3-Clause發布，雖然這兩個條款，內容上幾乎就是同款，但有時授權條款的前言或出處聲明會有異動，所以各放一份，是較嚴謹而不容易產生操作錯誤的建議手段。