這篇基本是由Lucien主筆，我則是參與架構跟內容討論、以及最後的修校，原文發表在原文發表在由軟體鑄造場的法律專欄。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
近十年來，自由開源授權軟體元件 (Free and Open Source Software, FOSS) 被大舉運用到商業應用的環境裡，然而，FOSS 的授權規則，亦相當程度賦含了自由分享的理念，故其中不少義務性要求與條件，並不能全然依照傳統商業授權的定式與慣習來進行，而若取之為應用的商業公司過於疏忽了義務性要求方面的條件，在貢獻者與商用者立場產生嚴重期待落差時，難免會引發原始權利人出來主張其開源授權的成果遭到濫用，進而提升到法庭上授權爭訟的衝突狀態。因為如此，許多 FOSS 商業應用者無不自問：究竟應該完成哪些義務性條件的遵守，才能有效降低開源授權爭訟的相關風險？這樣的問題，多數 FOSS 的研發社群朋友，並不會給過予一個界限分明的答案，一來並非所有 FOSS 專案撰寫的程式開發者，都能清楚依據著作權法主張其權利範圍與義務要求，二來許多程式開發者，更重視的是開源取予協調 (give and take) 的尊重與感受，故其並不想要在相關議題上過於闡釋，以免對 FOSS 專案的互惠分享範圍自我設限（註一）。然而，自由開源軟體授權條款的型態甚多（註二），其相關的義務性要求亦有些許分殊，若是能有更簡便的要項能夠遵守，則亦將有助於降低開源授權爭訟的相關風險，故本文依據司法實務以及所能接觸到的和解資訊，整理以下三大要點，提綱挈領地進行資訊分享。 閱讀全文 降低開源授權爭訟風險的三大要點 →
本文原刊於自由軟體鑄造場的法律專欄，一樣是與Lucien共同撰寫，尤其感謝Lucien的補充潤飾，讓整篇文章的內容有趣、易讀多了。
~~~~~~~~~~ 本文開始 ~~~~~~~~~~
程式源碼 (Source Code) 與目的碼（Object Code，註一）是軟體程式存在的兩種基本型態，前者指的是電腦程式可供後續增編修改的格式，有時可被直接執行，但多半時候必須經編譯或界定程序之後才能被執行，後者則是能夠直接供電腦機器判讀的執行檔格式，但因已經過編譯程序，故除非經過反組譯或是還原工程，否則一般人無法直接觀察目的碼，來了解該電腦程式的演算過程及運算邏輯 (algorithm)。一般來說，軟體程式可以擇一或是同時透過這兩種型態來被散布，就法律論理上，其在著作權法上是被視為是同一作品不同形態的表現，故其表現形式雖不同，但法律定位完全相同。過去電腦程式目的碼是不是能受到著作權法保障是有疑慮的，畢竟這樣的著作格式並不如同一般受著作權保護的客體：詩、詞、書、畫、文章、音樂、電影般，能被直接閱讀、聆聽、感受，和了解，不過美國於 1983 年 Apple Computer, Inc. v. Franklin Computer Corp. 一案中，承審法官在反覆的論理之後，判定目的碼亦為美國著作權法保護的客體之一，同時，因其無法為人類直接了解之故，更進一步認定其與程式源碼具有同一性關係（註二）。此一判決也影響其他各國就此議題的認識，此後多數法律見解皆偏向於將程式源碼與目的碼，視為電腦程式的一體兩面，故表現的方式雖有差異，但被著作權法保護的本質與地位相同。這樣的解讀態度適用在一般私有軟體 (proprietary software) 上，固然不會有太大的問題，畢竟私有軟體在授權使用上的基本規則為「權利人保留所有權利 (all rights reserved)」，故使用他人電腦程式時，未經授權方同意的方式，基本上都是不被法律所允許的，然而，許多的自由開源軟體 (Free and Open Source Software) 專案及其授權條款，蘊含著一種盡量將程式源碼提出來讓後手使用者增刪修改並便利應用的態度，故在其授權條款中，可以看到許多的內容是明確地針對程式源碼或目的碼所作的，略有差異的義務性要求，此項特點多為一般使用者所不知或忽略，而這方面的資訊，也正是本文希望透過特定條款的例示與說明，所要傳達給大家的。 閱讀全文 淺論程式源碼與目的碼在自由開源軟體授權條款裡的同與異 →
A stupid human living somewhere on Earth.