List of software licensing schemes: Difference between revisions

From LemonWiki共筆
Jump to navigation Jump to search
mNo edit summary
 
(One intermediate revision by the same user not shown)
Line 5: Line 5:
'''容易犯的錯誤:'''
'''容易犯的錯誤:'''
# 只憑 GitHub 或 GitLab 專案顯示的 MIT License 就判斷可以直接商用
# 只憑 GitHub 或 GitLab 專案顯示的 MIT License 就判斷可以直接商用
# 只看到免費與開源的標示,未深入檢視所有相關組件的授權條款
# 只看到免費與開源的標示,未深入檢視所有相關組件 (component) 的授權條款
# 原始碼可以公開檢視,與採用開源可商業使用 (商用) 的授權方案不同
# 可以公開檢視原始碼,但授權方案不是「開放原始碼促進會」(Open Source Initiative,縮寫 OSI) [https://opensource.org/licenses 核可的授權方案]


{{Tips}} 「有些軟體的作者只將原始碼公開,卻不符合「開放原始碼」的定義及條件,因為作者可能設定公開原始碼的條件限制,諸如限制可閱讀原始碼的對象、限制衍生產品等,此稱之為公開原始碼的免費軟體(Freeware,例如知名網路論壇軟體Discuz!),因此公開原始碼的軟體並不一定可稱為開放原始碼軟體。」(資料來源:[https://zh.wikipedia.org/wiki/%E5%BC%80%E6%BA%90%E8%BD%AF%E4%BB%B6 維基百科])
{{Tips}} 「有些軟體的作者只將原始碼公開,卻不符合「開放原始碼」的定義及條件,因為作者可能設定公開原始碼的條件限制,諸如限制可閱讀原始碼的對象、限制衍生產品等,此稱之為公開原始碼的免費軟體(Freeware,例如知名網路論壇軟體Discuz!),因此公開原始碼的軟體並不一定可稱為開放原始碼軟體。」(資料來源:[https://zh.wikipedia.org/wiki/%E5%BC%80%E6%BA%90%E8%BD%AF%E4%BB%B6 維基百科])

Latest revision as of 15:35, 7 February 2025

開源軟體授權風險評估:如果想將開放原始碼的軟體方案,整合在公司的商業服務內,需考慮著作權授權與商業應用是否相容。

授權方案評估指標[edit]

容易犯的錯誤:

  1. 只憑 GitHub 或 GitLab 專案顯示的 MIT License 就判斷可以直接商用
  2. 只看到免費與開源的標示,未深入檢視所有相關組件 (component) 的授權條款
  3. 可以公開檢視原始碼,但授權方案不是「開放原始碼促進會」(Open Source Initiative,縮寫 OSI) 核可的授權方案
Owl icon.jpg 「有些軟體的作者只將原始碼公開,卻不符合「開放原始碼」的定義及條件,因為作者可能設定公開原始碼的條件限制,諸如限制可閱讀原始碼的對象、限制衍生產品等,此稱之為公開原始碼的免費軟體(Freeware,例如知名網路論壇軟體Discuz!),因此公開原始碼的軟體並不一定可稱為開放原始碼軟體。」(資料來源:維基百科)

深入檢查授權方案:

  1. 盤點核心功能與原始碼中使用到的所有外部套件
  2. 確認每個套件的授權文件位置[1] (例如 LICENSE、license.txt)
  3. 詳讀授權條款的商用規範
  4. 注意展示網頁中可能包含的付費元件

商用授權細節評估:

  1. 個人開發者授權費用與範圍
  2. 機構版本授權費用與適用範圍
  3. 客戶使用權限界定
  4. 原始碼使用與再開發的授權要求

建議的授權管理流程:

  1. 建立完整的套件使用清單 e.g. 自由軟體資訊清單 文件範本, e.g.: Third-Party Software Used by PhpStorm[2]
  2. 定期檢查所有使用組件的授權狀態,避免原允許商用的授權,突然改成較嚴格需付費的授權方式或雙重授權模式[3]
  3. 與法務部門協作評估授權風險

相關資料[edit]

References[edit]


網站設計和開發流程