了解開源的法律意涵
與世界分享您的創意作品可能是一件令人興奮且有成就感的事情。但也可能意味著一堆您不知道需要擔心的法律問題。 值得慶幸的是，有了本指南，您不必從頭開始。（在深入研究之前，請務必閱讀我們的免責聲明。）
為什麼人們如此關心開源的法律面向？
很高興您問了！當您創作創意作品（例如寫作、圖形或程式碼）時，該作品預設受獨有著作權保護。 也就是說，法律假定作為您作品的作者，您有權決定其他人可以對其做什麼。
一般而言，這表示未經許可，任何人都不得使用、複製、散布或修改您的作品，否則將面臨下架、勒索或訴訟的風險。
然而，開源是一種不尋常的情況，因為作者期望其他人會使用、修改和分享作品。 但由於法律預設仍然是獨有著作權，因此您需要透過授權條款明確授予這些權限。
這些規則也適用於有人貢獻到您的專案時。 如果沒有授權條款或其他協議，任何貢獻都由其作者獨有。 這表示沒有人——甚至您——可以使用、複製、散布或修改他們的貢獻。
最後，您的專案可能具有您未意識到的授權條款要求的相依性。 您的專案社群或您雇主的政策也可能要求您的專案使用特定的開源授權條款。 我們將在下面涵蓋這些情況。
公開的 GitHub 專案是開源的嗎？
當您在 GitHub 上建立新專案時，您可以選擇將儲存庫設為私有或公開。
將您的 GitHub 專案設為公開與授權您的專案不同。 公開專案受 GitHub 服務條款的約束，該條款允許其他人檢視和 fork 您的專案，但您的作品在其他方面未經許可。
如果您希望其他人使用、散布、修改您的專案或為其貢獻，您需要加入開源授權條款。 例如，除非您明確授予權利，否則即使是公開的，任何人也無法合法地在其程式碼中使用您 GitHub 專案的任何部分。
直接告訴我保護我的專案的重點。
您很幸運，因為如今，開源授權條款已標準化且易於使用。 您可以直接將現有的授權條款複製貼上到您的專案中。
MIT、Apache 2.0 和 GPLv3 是流行的開源授權條款，但還有其他選項可供選擇。 您可以在 choosealicense.com 上找到這些授權條款的完整文字以及有關如何使用它們的說明。
當您在 GitHub 上建立新專案時，系統會要求您新增授權條款。
哪種開源授權條款適合我的專案？
如果您從頭開始，使用 MIT 授權條款 很難出錯。 它簡短、易於理解，並允許任何人做任何事情，只要他們保留授權條款的副本，包括您的著作權聲明。 如果您需要，您可以根據不同的授權條款發布專案。
否則，為您的專案選擇正確的開源授權條款取決於您的目標。
您的專案很可能具有（或將具有）相依性，每個相依性都有自己的開源授權條款，您必須遵守這些條款。 例如，如果您正在開源一個 Node.js 專案，您可能會使用來自 Node Package Manager (npm) 的程式庫。
具有像 MIT、Apache 2.0、ISC 和 BSD 等寬鬆授權條款的相依性允許您以您想要的任何方式授權您的專案。
具有Copyleft 授權條款的相依性需要更密切的關注。 包含任何具有「強力」Copyleft 授權條款的程式庫，例如 GPLv2、GPLv3 或 AGPLv3，要求您為您的專案選擇相同的或相容的授權條款。 具有像 MPL 2.0 和 LGPL 等「有限」或「弱」Copyleft 授權條款的程式庫可以包含在使用任何授權條款的專案中，前提是您遵循它們指定的額外規則。
您可能還想考慮您希望使用和貢獻您的專案的社群
- 您是否希望您的專案被其他專案用作相依性？ 最好使用您相關社群中最流行的授權條款。 例如，MIT 是 npm 程式庫最流行的授權條款。
- 您是否希望您的專案吸引大型企業？ 大型企業可能會因所有貢獻者的明確專利授權而感到安心。 在這種情況下，Apache 2.0 可以讓您（和他們）都滿意。
- 您是否希望您的專案吸引不希望其貢獻用於封閉原始碼軟體的貢獻者？ GPLv3 或（如果他們也不希望為封閉原始碼服務貢獻）AGPLv3 會很受歡迎。
您的公司可能對開源專案授權條款有政策。 一些公司要求您的專案帶有寬鬆的授權條款，以允許與公司的專有產品整合。 其他政策則強制執行強 Copyleft 授權條款和額外的貢獻者協議（請參閱下文），因此只有您的公司可以在封閉原始碼軟體中使用該專案。 組織也可能有某些標準、社會責任目標或透明度需求，這些可能需要特定的授權策略。 請諮詢您公司的法務部門以尋求指導。
當您在 GitHub 上建立新專案時，系統會讓您選擇授權條款。 加入上述授權條款之一將使您的 GitHub 專案成為開源專案。 如果您想查看其他選項，請查看 choosealicense.com，以找到適合您專案的授權條款，即使它不是軟體。
如果我想變更專案的授權條款怎麼辦？
大多數專案永遠不需要變更授權條款。 但偶爾情況會發生變化。
例如，隨著專案的成長，它會增加相依性或使用者，或者您的公司變更策略，所有這些都可能需要或想要不同的授權條款。 此外，如果您從一開始就忽略了為您的專案授權，則新增授權條款實際上與變更授權條款相同。 在新增或變更專案的授權條款時，有三個基本事項需要考慮
這很複雜。 確定授權條款的相容性和合規性以及誰擁有著作權可能會變得非常複雜和令人困惑。 為新版本和貢獻切換到新的但相容的授權條款與重新授權所有現有的貢獻不同。 在任何想要變更授權條款的初步跡象時，請讓您的法務團隊參與進來。 即使您有或可以獲得專案著作權持有者對授權條款變更的許可，也要考慮變更對專案的其他使用者和貢獻者的影響。 將授權條款變更視為專案的「治理事件」，透過清晰的溝通和與專案利害關係人的協商，更有可能順利進行。 這更有理由從專案一開始就選擇和使用適當的授權條款！
您專案現有的授權條款。 如果您專案現有的授權條款與您想要變更的授權條款相容，您可以直接開始使用新的授權條款。 這是因為如果授權條款 A 與授權條款 B 相容，您將在遵守 B 條款的同時遵守 A 條款（但反之亦然則不一定）。 因此，如果您目前使用的是寬鬆授權條款（例如，MIT），您可以變更為具有更多條件的授權條款，只要您保留 MIT 授權條款和任何相關的著作權聲明副本（即，繼續遵守 MIT 授權條款的最低條件）。 但是，如果您目前的授權條款不是寬鬆的（例如，Copyleft，或者您沒有授權條款），並且您不是唯一的著作權持有人，您就不能只是將您專案的授權條款變更為 MIT。 本質上，透過寬鬆授權條款，專案的著作權持有人已預先授權變更授權條款。
您專案現有的著作權持有人。 如果您是您專案的唯一貢獻者，那麼您或您的公司就是專案的唯一著作權持有人。 您可以新增或變更為您或您的公司想要的任何授權條款。 否則，可能會有其他著作權持有人，您需要獲得他們的同意才能變更授權條款。 他們是誰？ 在您的專案中有 commit 的人是一個好的開始。 但在某些情況下，著作權將由這些人的雇主持有。 在某些情況下，人們只會做出極少的貢獻，但沒有硬性規定，程式碼行數少於某個數量的貢獻不受著作權保護。 該怎麼辦？ 這取決於情況。 對於相對較小且年輕的專案，讓所有現有的貢獻者同意在 issue 或 pull request 中變更授權條款可能是可行的。 對於大型且歷史悠久的專案，您可能必須尋找許多貢獻者甚至他們的繼承人。 Mozilla 花費了數年時間（2001-2006 年）重新授權 Firefox、Thunderbird 和相關軟體。
或者，您可以讓貢獻者透過額外的貢獻者協議預先批准某些授權條款變更（請參閱下文）。 這會稍微轉移變更授權條款的複雜性。 您需要法務人員預先提供更多協助，並且在執行授權條款變更時，您仍然需要與專案的利害關係人清楚溝通。
我的專案是否需要額外的貢獻者協議？
可能不需要。 對於絕大多數開源專案，開源授權條款隱含地兼作 inbound（來自貢獻者）和 outbound（給其他貢獻者和使用者）授權條款。 如果您的專案在 GitHub 上，GitHub 服務條款將「inbound=outbound」設為明確的預設值。
額外的貢獻者協議——通常稱為貢獻者授權條款協議 (CLA)——可能會為專案維護者帶來管理工作。 協議增加多少工作取決於專案和實作。 簡單的協議可能要求貢獻者點擊確認他們擁有在專案開源授權條款下貢獻的必要權利。 更複雜的協議可能需要法律審查和貢獻者雇主的簽核。
此外，透過新增一些人認為是不必要、難以理解或不公平的「文書作業」（當協議接收者獲得比貢獻者或公眾透過專案的開源授權條款獲得的更多權利時），額外的貢獻者協議可能會被認為對專案社群不友善。
您可能想要考慮為您的專案使用額外貢獻者協議的一些情況包括
- 您的律師希望所有貢獻者明確接受（簽署，線上或線下）貢獻條款，可能是因為他們認為開源授權條款本身不足以（即使它足夠！）。 如果這是唯一的疑慮，則確認專案開源授權條款的貢獻者協議應該就足夠了。 jQuery 個人貢獻者授權條款協議是輕量級額外貢獻者協議的一個很好的例子。
- 您或您的律師希望開發人員聲明他們做出的每個 commit 都已獲得授權。 開發人員原產地證明要求是許多專案實現此目的的方式。 例如，Node.js 社群使用 DCO 代替他們之前的 CLA。 在您的儲存庫上自動強制執行 DCO 的一個簡單選項是 DCO Probot。
- 您的專案使用不包含明確專利授權的開源授權條款（例如 MIT），並且您需要所有貢獻者的專利授權，其中一些貢獻者可能在擁有大型專利組合的公司工作，這些專利組合可用於針對您或專案的其他貢獻者和使用者。 Apache 個人貢獻者授權條款協議是一種常用的額外貢獻者協議，它具有與 Apache 授權條款 2.0 中找到的專利授權相同的專利授權。
- 您的專案在 Copyleft 授權條款下，但您也需要散布專有版本的專案。 您需要每位貢獻者將著作權轉讓給您，或授予您（但不是公眾）寬鬆的授權條款。 MongoDB 貢獻者協議是這種類型協議的一個範例。
- 您認為您的專案在其生命週期中可能需要變更授權條款，並希望貢獻者預先同意此類變更。
如果您確實需要為您的專案使用額外的貢獻者協議，請考慮使用諸如 CLA assistant 之類的整合，以最大程度地減少對貢獻者的干擾。
我公司的法務團隊需要了解什麼？
如果您以公司員工的身分發布開源專案，首先，您的法務團隊應該知道您正在開源一個專案。
無論好壞，即使是個人專案，也要考慮讓他們知道。 您可能與您的公司簽訂了「員工 IP 協議」，該協議賦予他們對您的專案的某些控制權，尤其是當它們與公司的業務完全相關或您使用任何公司資源來開發專案時。 您的公司應該很容易給予您許可，並且可能已經透過對員工友善的 IP 協議或公司政策這樣做了。 如果沒有，您可以協商（例如，解釋您的專案符合公司對您的專業學習和發展目標），或者避免從事您的專案，直到您找到一家更好的公司。
如果您正在為您的公司開源一個專案，那麼絕對要讓他們知道。 您的法務團隊可能已經根據公司的業務需求和確保您的專案符合其相依性的授權條款的專業知識，制定了使用哪種開源授權條款（以及可能的額外貢獻者協議）的政策。 如果沒有，您和他們都很幸運！ 您的法務團隊應該渴望與您合作以找出這些問題。 一些需要考慮的事情
-
第三方材料： 您的專案是否有其他人建立的相依性，或者是否包含或使用他人的程式碼？ 如果這些是開源的，您需要遵守這些材料的開源授權條款。 這首先要選擇一個與第三方開源授權條款相容的授權條款（請參閱上文）。 如果您的專案修改或散布第三方開源材料，那麼您的法務團隊也希望知道您是否符合第三方開源授權條款的其他條件，例如保留著作權聲明。 如果您的專案使用沒有開源授權條款的他人的程式碼，您可能必須要求第三方維護者新增開源授權條款，如果您無法獲得，請停止在您的專案中使用他們的程式碼。
-
商業機密： 考慮專案中是否有任何公司不想向公眾提供的內容。 如果是這樣，您可以開源您專案的其餘部分，在提取您想要保密的材料之後。
-
專利： 貴公司是否正在申請專利，而開源您的專案會構成公開揭露？ 可惜的是，您可能會被要求等待（或者公司可能會重新考慮申請的明智之舉）。 如果您期望從擁有大型專利組合的公司的員工那裡獲得對您專案的貢獻，您的法務團隊可能希望您使用具有來自貢獻者的明確專利授權的授權條款（例如 Apache 2.0 或 GPLv3），或額外的貢獻者協議（請參閱上文）。
-
商標： 仔細檢查您的專案名稱是否與任何現有商標衝突。 如果您在專案中使用自己的公司商標，請檢查它是否會造成任何衝突。 FOSSmarks 是理解免費和開源專案背景下的商標的實用指南。
-
隱私： 您的專案是否收集使用者資料？ 「Phone home」到公司伺服器？ 您的法務團隊可以幫助您遵守公司政策和外部法規。
如果您正在發布貴公司的第一個開源專案，以上內容已足夠應付（但別擔心，大多數專案都不應引起任何重大疑慮）。
從長遠來看，您的法務團隊可以做更多事情來幫助公司從其參與開源中獲得更多收益，並保持安全
- 員工貢獻政策： 考慮制定公司政策，明確規定您的員工如何為開源專案做出貢獻。 明確的政策將減少員工之間的混亂，並幫助他們以符合公司最佳利益的方式為開源專案做出貢獻，無論是作為他們工作的一部分還是在他們的空閒時間。 Rackspace 的 模型 IP 和開源貢獻政策 就是一個很好的例子。
