跳轉到內容

FOSS 許可證/場景

Add links
來自華夏公益教科書

不同的利益相關者將對 FOSS 有不同的用途。開發人員可能會比終端使用者更密集地使用某個程式，這意味著開發人員的活動可能比終端使用者受到更多的限制。以下部分試圖提供一些場景作為示例，以解釋不同利益相關者可能遇到的不同法律問題。

終端使用者（個人/企業/政府）

[編輯 | 編輯原始碼]

阿布林是一名公立高中教師。他的學校負擔不起昂貴的專有辦公應用程式許可證費用。儘管專有軟體公司為學校提供特別優惠，但阿布林希望找到一種替代解決方案，以減少學生對專有軟體的依賴。他的朋友納茲莉是一位參與過 FOSS 專案的程式設計師，向他介紹了一款 FOSS 辦公應用程式。然後，阿布林和他的同事下載了 FOSS 辦公解決方案，並教授學生專有和 FOSS 應用程式。他對效能感到滿意，並向他的同事介紹了納茲莉的程式。逐漸地，學校行政部門開始使用 FOSS 解決方案進行行政工作。

在這種情況下，無論是阿布林（個人）還是他的學校（公共政府機構）都沒有對他們從網路下載的軟體進行任何修改。他們只是終端使用者。

終端使用者的狀況相對簡單。軟體程式的終端使用者可以是個人、政府機構或商業實體。這些個人或法人實體可能出於不同的原因使用 FOSS。有些人可能試圖找到更便宜的解決方案或更適合他們需求的解決方案；其他人可能希望使用 FOSS 進行更好的定製；還有一些人可能希望減少對專有公司的依賴。

涉及的法律問題
終端使用者使用 FOSS 解決方案的方式可能與他們使用專有解決方案的方式沒有太大區別。他們下載 FOSS 解決方案的副本或購買副本（通常是為了換取一些支援和服務），將其安裝在計算機中（從而在硬碟上製作副本），執行程式，並讓其功能滿足他們的需求。這裡關注的權利是複製程式和執行程式的權利。（執行程式的行為也可能算作複製行為，但在一些 FOSS 許可證中有所不同。例如，GNU GPL 對執行 GPL 程式沒有限制，但確實規範了複製行為。）這些權利是由所有 FOSS 許可證授予的。因此，涉及終端使用者的法律糾紛較少。但是，終端使用者確實需要考慮一些問題。
  • 問題 1：技術支援 由於終端使用者可能不是電腦高手，因此在選擇 FOSS 解決方案時，他們可能對技術支援存在顧慮。因此，他們可能不會簡單地免費下載 FOSS 解決方案的副本，而是選擇在專有解決方案也提供的商店購買一盒 FOSS，有時價格大致相同。區別在於，購買時，假設是商用 Linux 發行版，終端使用者不是在為許可證付費，而是在為服務和支援付費。軟體和 FOSS 文件的額外副本可以自由分發，例如分發給學生，或安裝在其他計算機上；這些額外的使用者或安裝通常不包含在支援範圍內，除非在協議中明確包含。當服務期限到期後，終端使用者可以選擇支付另一期限的服務費用，或向其他可用提供商請求類似的服務。
  • 問題 2：定製 當現有的 FOSS 解決方案不符合他們的需求時，終端使用者可能需要請個人開發人員或供應商定製解決方案。在這種情況下，由於終端使用者可能沒有足夠的專業知識來發現可能的侵權行為，因此他們可能希望在合同中加入書面條款，確保供應商或開發人員將承擔任何可能的版權侵權行為的全部責任，並賠償因侵權指控可能造成的任何損失。買方在與供應商或開發人員談判時，可以自由地將這些條款新增到合同中。
  • 問題 3：政府採購 由於 FOSS 許可證與傳統軟體許可證不同，因此政府在為軟體解決方案招標或與供應商簽訂合同時，應特別注意這些差異。現有的政府招標和合同模板可能是在傳統版權法傳統的專有模型下起草的，如果它們不能平等地對待 FOSS 和專有軟體，則需要檢查或修改。

開發人員（個人，企業）

[編輯 | 編輯原始碼]

開發人員（個人和商業實體）在使用 FOSS 時需要更加註意不同許可證的條款和條件。開發人員通常不僅執行和複製軟體，而且還會從軟體中建立衍生作品，並將這些衍生作品與原始程式一起分發。因此，為了讓開發人員能夠為某個 FOSS 程式的開發做出貢獻，必須擁有執行程式、複製程式、分發程式和準備衍生作品的權利。

這些權利是由所有 FOSS 許可證 授予的，因為這些基本權利被認為在 自由軟體定義 和 開源定義 中都很重要。然而，不同的 FOSS 許可證可能對行使這些權利有不同的限制，尤其是在建立和分發衍生作品方面。開發人員應特別注意這一點，並在需要時諮詢他們的律師，瞭解他們具體的情況。

在軟體開發的不同階段，開發人員會考慮不同的因素。

啟動新專案時

[編輯 | 編輯原始碼]

阿布林的同事喬莉是學校圖書管理員。學校圖書館不是很大，但對村民開放。喬莉向她的朋友尋求幫助，編寫一個程式，以便她能夠準確地記錄圖書館的書籍。

  • 涉及的法律問題 - 選擇自己的許可證
開發人員
這個專案對我個人和其他人意味著什麼？我希望其他人如何參與？FOSS 許可證怎麼說？FOSS 許可證之間有什麼區別？
如果開發人員是在不使用任何現有模組的情況下啟動新專案，那麼情況就比較簡單，因為她不需要檢視可能使用的現有模組的許可證。
但是，啟動新專案也不是一件容易的事。她選擇的 FOSS 許可證的不同特點將對專案的可能開發路徑產生重大影響。開發人員應該在選擇許可證之前確定她最關心的問題。
例如，如果開發人員是 copyleft 的支持者，她可能會堅持使用 GNU GPL 或 LGPL。如果開發人員認為她不需要要求人們在 FOSS 許可證下許可他們的修改作品，那麼 BSD 風格的許可證 比較合適。或者，當開發人員認為最好以堅定而集中的方式控制開發時，她可能對 BSD 風格的許可證不感興趣。但如果在未來的發展中更傾向於分支，那麼 BSD 風格的許可證可能是更好的選擇。
開發人員
我可以更改我的專案許可後改變主意嗎？
專案的版權持有者始終可以決定為程式選擇其他許可證，即使先前版本已經根據某些自由軟體許可證獲得許可。這不會影響先前版本接收者的權利，因為許可證授予是不可撤銷的。如果社群的貢獻已被納入新版本，情況會更加複雜，這意味著這些其他貢獻者可能會對新版本中程式碼的某些部分主張版權。在這種情況下，除非事先達成協議，否則許可證必須由所有貢獻者選擇。
開發人員
我不喜歡任何現有的自由軟體許可證。我可以建立一個新的嗎？
雖然已經存在許多自由軟體許可證，但開發人員可能會發現自己不喜歡任何可用的許可證。只要開發人員擁有程式碼，她就有權為專案選擇任何許可證，包括她自己起草的新的許可證。但是，建立新的自由軟體許可證需要法律知識和技能，以避免含糊不清和漏洞。此外，已經存在許多自由軟體許可證，理解這些許可證的交易成本很高。除非開發人員有充分的理由，否則不建議建立新的許可證。

修改現有模組時

[編輯 | 編輯原始碼]

阿布林和他所在的學校使用的辦公應用程式有一個英文介面。它不支援當地語言。對於高中生來說，使用英文介面可能不會造成問題。然而，當阿布林試圖教村民時，卻遇到了困難。他向納茲莉諮詢了這個問題。納茲莉一直為自由軟體專案做出貢獻，並且也對該辦公應用程式的原始碼非常熟悉。她和幾個朋友一起討論了這個問題，並作為一個團隊開始對應用程式進行本地化。

  • 相關法律問題：確定要修改的程式的許可證

當開發人員試圖修改現有模組，並且修改不僅僅是為了她自己的使用，而是為了進一步分發（例如，本地化專案）時，她需要首先識別模組的許可證。

開發人員
根據許可證，我被授予了哪些權利，以及在行使這些權利時有哪些限制？
例如，在分發自由軟體作品時，一些自由軟體許可證（例如GNU GPL、LGPL）可能要求分發者提供目的碼和原始碼，或者至少提供有關如何訪問原始碼的資訊。在修改自由軟體作品時，一些自由軟體許可證（例如GNU GPL、LGPL、BSD）可能要求修改者提供所做更改的文件。在分發衍生作品時，複製左許可證要求衍生作品以與原始作品相同的許可證獲得許可，而其他自由軟體許可證允許修改者選擇不同的許可證（BSD、MIT）。
如果納茲莉和她的朋友們試圖對雙重許可的OpenOffice進行本地化，並且他們決定使用根據GNU GPL許可的版本，那麼本地化的 OpenOffice 也將是 GPL 許可的。使用原始的許可證方案（雙重許可），本地化可以輕鬆地整合到原始專案中，並且至少可以部分地維護在原始專案中。使用更嚴格的方案意味著本地化可能必須在本地維護。允許額外的許可證（例如，為了將來能夠在其他專案中使用部分作品）通常沒有問題。
一些自由軟體許可證（例如MIT 許可證）可能允許使用者對原始作品進行再許可。這意味著在分發原始作品的逐字副本時，在原始版權持有者授予的範圍內，分發者可以選擇不同的許可證併成為許可者。在這種情況下，當開發人員建立衍生作品並將其與原始作品一起分發時，他/她可以選擇成為原始作品和衍生作品的許可者，這將法律關係簡化為僅存在於雙方之間的關係。如果不允許再許可，那麼收到修改後作品的人將有兩個許可者。原始作品的許可者將是原始作品的作者，而衍生作品的許可者將是準備衍生作品的開發人員。

將不同的自由軟體模組整合到一項服務中時

[編輯 | 編輯原始碼]

納茲莉在 AA 軟體公司工作。為了更好地監督公司正在開發的許多不同的專案，該團隊透過整合不同的自由軟體模組構建了一個專案管理系統。該管理系統目前僅供內部使用，但由於它非常方便，因此該公司還計劃將來以商業方式分發它。

自由軟體許可證不對為內部使用而進行的修改施加限制。但是，當基於這些修改建立公開分發時，開發人員必須考慮正在使用的所有模組的許可證。

  • 相關法律問題：識別正在整合的程式的許可證，並檢視這些許可證是否相容。
在釋出包含多個不同模組的專案時，必須確定每個模組的許可證。如果它們碰巧是在相同許可證下獲得許可的，例如GNU GPL，那麼整合系統將根據該許可證獲得許可。當所有模組都在BSD 許可證下獲得許可時，情況類似。但是，在這種第二種情況下，因為 BSD 許可證更加寬鬆，所以 AA 能夠為修改後的模組和整合系統選擇其他自由軟體許可證或專有許可證。（BSD 許可證的寬鬆性允許 AA 透過新增更多條件來“縮小”許可證，而 GPL 不允許這樣做。）
但是，如果某些模組具有不同的許可證，那麼 AA 將不得不檢視這些許可證的相容性。當兩個許可證相容時，根據這兩個許可證獲得許可的兩個模組可以合併成一個更大的作品，同時遵守兩個許可證。[1]
在將一個根據GPL許可的程式和一個根據BSD許可（與 GPL 相容）的程式組合成一個更大的程式時，更大的程式必須是 GPL 許可的，以滿足 GPL 許可的程式和 BSD 許可的程式的要求。如果某些模組是 GPL 許可的，而其他模組與 GPL 不相容，則 AA 必須決定哪個模組對他們來說更重要，並將另一個模組替換為具有相容許可證的模組。[2]
不同模組中使用的許可證以及它們組合在一起的方式將決定如何對整合系統進行許可和分發。
  • 其他注意事項——法律選擇和管轄範圍選擇條款
最後，對於能夠為他們的程式選擇許可證的人，無論是他們建立了自己的程式，還是他們被允許為他們準備的衍生作品選擇許可證，他們應該意識到許多 OSI 批准的許可證是由專有軟體公司開發的。有些是為了滿足他們公司的政策和策略而設計的，因此對於一般的開發人員來說可能不是一個好的選擇。某些技術問題，例如關於法律選擇和管轄範圍的條款（可以在Qt 公共許可證、Mozilla 公共許可證、通用公共許可證等中找到），在提起訴訟時可能會變得很重要。

供應商/生產者（企業）

[編輯 | 編輯原始碼]

納茲莉和她的朋友們已經發布了本地化的自由軟體辦公軟體版本。AA 軟體公司對該應用程式感興趣。他們還開發了一些其他小型但有用的程式，用於行政工作。他們將本地化的辦公軟體與他們自己的程式（根據其專有許可證獲得許可）一起打包。該軟體包大受歡迎。幾個月後，AA 還決定以商業方式分發他們從不同的自由軟體模組整合的專案管理系統。

單純分發
在這種情況下，自由軟體和專有程式都包含在一個軟體包中。對於自由軟體應用程式，AA 只是一個分發者，並且必須按照其自由軟體許可證的要求進行分發。對於專有程式，AA 持有版權，並且能夠選擇許可證和分發方式。將自由軟體和專有應用程式放入一個分發軟體包中（例如一張 CD-ROM）是可以的，如果這些應用程式分別執行，並且不會連結在一起建立任何衍生作品。
整合系統的分發
在整合系統分發的情況下，關鍵的是不同整合模組的許可證以及這些模組組合在一起的方式。如前所述，AA 需要首先確保不同模組的許可證允許 AA 將它們組合在一起。這些許可證也將決定 AA 可以分發整合系統的方式。
其他注意事項——驅動程式和認證
FOSS 供應商可能會遇到的一個困難是，硬體供應商可能沒有意識到 FOSS 軟體，因此無法提供驅動程式來使 FOSS 應用程式能夠在硬體上執行。在硬體供應商中推廣 FOSS 的理念非常重要。當有更多 FOSS 使用者時，這將更容易。

同樣，有時需要認證才能使 FOSS 與特定專有軟體正常工作。更大的 FOSS 使用者群將鼓勵專有軟體公司認證可能與他們的程式一起使用的 FOSS 應用程式。

其他考慮因素 - 嵌入式系統或裝置中使用的 FOSS
FOSS 也用於電子裝置中的嵌入式系統，例如手機、手持裝置、數碼相機和 DVD 播放器。使用 FOSS 可以幫助裝置製造商在開發新產品時降低成本。裝置的分配不同於 FOSS 本身的分配。關於後者，特定許可的規則仍然適用。

GPL 版本 3 要求不僅提供嵌入式裝置的原始碼，還描述如何將軟體的本地修改版本安裝到裝置中，除非裝置無法更新（例如，因為軟體在 ROM 中）。

其他考慮因素 - 原始碼
許多 FOSS 許可證堅持要求原始碼可用。這必須是已分發的編譯程式的實際原始碼。由於對軟體的更改會導致難以察覺的錯誤，使其在使用它的環境中變得不可用，因此僅提供最新版本的原始碼是不夠的。避免跟蹤每個版本的簡單方法是始終將原始碼與編譯後的軟體一起分發（或在透過提供下載進行分發時，將它們保持在一起）。

政府資助的專案

[編輯 | 編輯原始碼]

FOSS 運動和快速的 FOSS 發展不僅引起了 FOSS 社群的關注，也引起了學術界和政策制定者的關注。在一些亞洲國家，政府與 PC 製造商/供應商合作，提供捆綁了 FOSS 作業系統 和辦公應用程式的經濟實惠的 PC。[3] 政府還支援 FOSS 開發，生成與 FOSS 相關的專案，並推廣 FOSS 作為國家技術和產業政策。[4] 但早在政府開始注意到 FOSS 的潛力並制定出明確的立場之前，一些與政府相關的學術機構就已經在進行與 FOSS 相關的專案。

FSF 維護的關於 GNU GPL 的常見問題解答還列出了關於美國政府是否可以在 GNU GPL 下發布程式或釋出對 GPL 程式的改進的問題。[5] 情況可能因國家而異，也可能因不同國家不同的政府法規而異。大多數關於政府資助專案的政府法規通常是在其國內版權和專利法下起草的，並可能受到更保護主義的思想的影響，因此可能不熟悉，甚至對 FOSS 許可和開發模式不友好。

以下是兩個政府資助的 FOSS 研究案例。第一個是關於在政府研究機構中進行的與 FOSS 相關的研究，沒有相關的政府政策，而第二個是關於一個國家 FOSS 專案。

政府資助的 FOSS 專案：來自亞太地區的案例

[編輯 | 編輯原始碼]

政府關聯研究機構下的一個 FOSS 專案：多語言編輯器，日本

[編輯 | 編輯原始碼]

Emacs 是由 理查德·斯托曼 在 麻省理工學院 開發的多語言文字編輯器。在 GNU 專案 於 1984 年 開始後，GNU Emacs 的開發開始，並在 1985 年 首次釋出，根據 GNU GPL。

日本政府研究機構電子技術綜合研究所 (ETL)[6] 在 1990 年代中期 開始研究多語言資訊處理和整合 GNU Emacs 和 Mule（基於 Emacs 的多語言文字編輯器，後來併入 GNU Emacs 作為 MULE），但存在各種版權問題。

ETL 是一個政府研究機構，GNU GPL 中的許可模型與日本版權法大不相同，因此沒有人能夠確定 ETL 是否可以將程式碼分配給 FSF 並在 GNU GPL 下發布程式碼。結果，ETL 從未正式釋出程式碼，而是釋出了試用版。後來，ETL 和 FSF 之間進行了更多談判，並達成了一項特殊協議。FSF 同意不要求 ETL 將修改後程式碼的版權分配給 FSF，ETL 同意授予 FSF 使用程式碼的權利。這是 Emacs 中一部分程式碼不屬於 FSF 的第一次。

在 2001 年，ETL 被重組為國家先進工業科學技術研究所 (AIST)。雖然 AIST 仍然是一個政府資助的研究所，但它是一個獨立的組織，其資產不是國家財產。似乎 AIST 將能夠在 GNU GPL 下正式釋出程式碼。但是，最初，AIST 的高層仍然很難做出最終決定。他們又花了一年的內部談判時間來決定 AIST 有權釋出他們的作品並選擇他們作品的許可證。說服人們接受 GNU GPL 的優勢也不容易。據 AIST 首席研究員半田健一博士說，AIST 管理層做出最終決定的原因從未清楚。

這發生在日本政府對 FOSS 開發形成明確立場之前。在 2003 年 亞洲國家舉辦的開源會議上，半田博士受邀發表關於 Emacs 開發的演講，經濟產業省領導的日本 FOSS 專案領導人田代修一表示，日本政府已經做出了必要的監管修訂，以賦予政府資助專案的開發者版權（以及選擇許可的權利），只要該法律從專案開始就適用。

在本例中，我們可以看到，當政府不熟悉 FOSS 許可和開發模式時，相關的政府法規可能會給尋求全面參與 FOSS 開發的政府關聯研究機構帶來不必要的困難。AIST（前身為 ETL）花了數年時間才最終能夠在 GNU GPL 下正式釋出程式碼。即使現在有特殊法規促進政府資助的開源專案的 FOSS 許可證的使用，但它們仍然被視為例外。

一個國家 FOSS 專案：自由軟體產業發展專案，臺灣

[編輯 | 編輯原始碼]

在國會的壓力下，臺灣政府於 2002 年 開始規劃一個國家 FOSS 專案，並在 2003 年 為一個為期五年的 FOSS 專案分配了大量預算。經濟部 (MoEA) 被指定來構建、贊助和監督所有子專案。

根據由國家科學委員會 (NSC) 管理的一般政府法規，雖然結果可以由執行政府資助專案的實體擁有版權，但這些結果的應用仍然受到某些監管原則的約束。除非對國家科技發展更有利，否則結果必須

  1. 付費許可。
  2. 許可給臺灣機構或公司。
  3. 在臺灣管轄範圍內使用或製造。

儘管 FOSS 專案可能會做出例外，但法律還沒有以這種方式正式解釋，沒有人想冒違反法規的風險。

此外，國家 FOSS 專案被分配給了經濟部，而經濟部擁有保護國家利益和經濟競爭力的更重要任務。因此，他們的規定比一般規則更具保護性和限制性。這些限制性規定被應用於國家 FOSS 專案。根據經濟部的規定，只有第三項原則（在臺灣管轄範圍內使用和製造）可以豁免。這意味著國家 FOSS 專案的產出必須付費許可，並且只能許可給臺灣的機構或公司。這些原則與 FOSS 許可模型不一致，使得國家 FOSS 專案下的所有子專案都很難釋出他們的程式碼。

這個問題在五年期 FOSS 專案啟動後就被提出來了。不同的政府機構多次會面，試圖找到解決方案。由於 FOSS 許可模型對於他們慣用的模型來說太陌生了，直到第二年（2004）年中才解決這個問題，第一年開發的程式碼也沒有及時正式釋出。

這尤其成問題，因為國家 FOSS 專案下的一個子專案正在整合一個現有的 FOSS 程式。與此同時，該子專案打算參與並貢獻到這個特定的 FOSS 專案。當社群準備將所有最新發展合併並在2004 年 3 月下GNU GPL釋出其更新版本時，他們發現很難將臺灣政府資助的子專案下開發的程式碼合併到一起。

直到2004 年 5 月舉行了一次談判後，不同的政府機構才最終找到了解決方案。經濟部將該案件提交給行政院（最高行政機構），以獲得政府關於 FOSS 專案是否符合例外條款並因此免除這些原則的正式解釋。同時，經濟部開始研究修訂其限制性規定的可能性。

行政院最終在2004 年 7 月做出了正式解釋，這距離國家 FOSS 專案正式啟動已經過去了 18 個月。根據新的解釋，政府資助的 FOSS 專案符合一般 NSC 規則的例外條款，可以免除與 FOSS 許可衝突的原則。雖然經濟部的規定尚未修改，但一些程式碼生成 FOSS 專案被分配給了 NSC 和一般 NSC 規則，而不是更嚴格的經濟部規則。希望 FOSS 專案能夠此後在 FOSS 許可下發布程式碼。

這個案例表明，雖然政府已經開始認識到 FOSS 開發的重要性，但其監管和行政結構可能還沒有準備好適應 FOSS。在臺灣國家 FOSS 專案的案例中，在相關政府和專案人員的共同努力下，這個問題最終在一定程度上得到了解決。但這已經造成了一些嚴重的問題，特別是在與國際和本地 FOSS 社群合作方面。由於許多國家現在也認識到 FOSS 開發的重要性，並且正在開始或計劃開始他們政府的 FOSS 專案，因此審查和更新相關法律結構以促進 FOSS 開發至關重要。

腳註

[edit | edit source]
取自 "https://wikibook.tw/w/index.php?title=FOSS_Licensing/Scenarios&oldid=3324899"
華夏公益教科書