了解開源的法律含義

向世界分享你們具有創(chuàng)造性的工作，這是一個多么令人激動和有價值的經(jīng)歷。這也意味著你們必須擔心一堆你們不清楚的法律問題。幸運的是，你們不必從頭開始。我們已經(jīng)涵蓋了你們的法律需求。（在你們行動前，請確定閱讀了我們的免責聲明。）

為什么大家非常擔心有關(guān)開源的法律問題？

很高興你們提問！當你們行創(chuàng)造性工作（例如寫作，圖形或代碼）時，默認情況下該作品屬于專有版權(quán)（copyright）。也就是說，法律承認你們是你們作品的作者，他人在沒有經(jīng)得你們同意的情況下不能使用你們的工作。

一般來說，這意味著沒有人可以在沒有你們授權(quán)的情況下使用，復制，分發(fā)或者修改你們的工作。

然而，開源有著不一樣的情況。因為作者希望他人使用，修改以及分享他們的工作。但因為法律默認依然是專有版權(quán)（copyright），所以你們需要一個明確說明這些權(quán)限的協(xié)議。

如果你們不應用開源許可協(xié)議，那么對你們項目做出貢獻的人也都將成為其工作的專屬版權(quán)（copyright）所有者。這意味著沒有人（也包括你們）可以使用，復制，分發(fā)后者修改他們的貢獻，

最后，你們的項目可能具有你們不知道的許可證要求的依賴關(guān)系。你們的項目社區(qū)，或者你們的雇主政策也可能要求你們使用特定的開源許可協(xié)議。

公開的GitHub項目是開源的嗎？

當你們在GitHub上創(chuàng)建一個新項目 時，你們可以選擇將倉庫設(shè)置成private或者public。

image.png

Making your GitHub project public is not the same as licensing your project. Public projects are covered by GitHub's Terms of Service, which allows others to view and fork your project, but your work otherwise comes with no permissions.
讓你們的 GitHub 項目公開與許可你們的項目是不同的。公開項目是由 GitHub 的服務(wù)條款保護，它允許他人瀏覽以及 fork 你們的項目，但是沒有權(quán)限參與你們的工作。

如果你們想讓他人使用，復制，修改你們的項目，或者參與貢獻你們的項目，那么你們的項目就需要包含一個開源許可協(xié)議。例如，即使你們的項目是公開的，但沒有你們的授權(quán)，一些人是不能合法在他們的代碼中使用你們 GitHub 項目中的任何部分。

請告訴我該如何保護項目

你們很幸運，開源許可協(xié)議已經(jīng)標準化了同時使用簡單。你們可以直接復制粘貼一個已經(jīng)存在的許可協(xié)議到你們的項目里。

MIT，Apache 2.0 和 GPLv3 都是非常流行的開源許可協(xié)議，但是也有其它選擇。你們可以在 choosealicense.com 上找到這些許可協(xié)議的全部文本，同時說明了如何使用他們。

當你們在 GitHub 上創(chuàng)建了一個新項目，你們會被要求添加一個許可協(xié)議。

image.png

一個標準化的許可協(xié)議可以作為沒有法律培訓的人員的代理，以準確地知道他們可以和不能用軟件做什么。除非絕對要求，否則應避免使用定制，修改或非標準術(shù)語，這將成為他人使用代碼的障礙。
— @benbalter, "Everything a government attorney needs to know about open source software?licensing"

哪個開源許可協(xié)議適合我的項目？

如果你們是小白，那么使用 MIT License，不容易出錯。它很短，很容易理解，并允許任何人做任何事情，只要他們保留許可證的副本，包括你們的版權(quán)聲明。如果你們需要，您們能夠根據(jù)不同的許可協(xié)議發(fā)布項目。

然而，為項目選擇合適的開源許可協(xié)議這取決于你們。

你們的項目非常可能有（或?qū)⒂校?strong>依賴。例如，如果你們開源了一個 Node.js 的項目，你們將可能使用來自 npm（Node Package Manager）的庫。你們依賴的這些庫都有它們自己的開源許可協(xié)議。如果他們的許可協(xié)議“允許”（對使用，修改和分享給予公共權(quán)限，而對有關(guān)項目的許可協(xié)議沒有要求），這樣你們就可以使用任何你們想要的許可協(xié)議。共同允許許可協(xié)議包括 MIT，Apache 2.0，ISC 和 BSD。

另一方面，如果你們的依賴中有一個的許可協(xié)議是“強硬的 copyleft”（他們也給同樣的允許，但條件是有關(guān)項目得使用同樣的許可協(xié)議），那么你們的項目將使用與之相同的許可協(xié)議。copyleft 許可協(xié)議包括 GPLv2，GPLv3 和 AGPLv3。

你們也會想到考慮希望你們的社區(qū)使用以及貢獻你們的項目：

• 你們是否想讓你們的項目成為其它項目的依賴？在你們的相關(guān)社區(qū)最好盡可能使用最流行的許可協(xié)議。例如，MIT 是 npm libraries 使用的最流行的許可協(xié)議。
• 你們的項目是否想吸引大企業(yè)？大型企業(yè)可能需要所有貢獻者的明確專利許可。在這種情況下，Apache 2.0 適合你們。
• 你們的項目是否想吸引不愿自己的貢獻用于其它同類型軟件的貢獻者？GPLv3 和 AGPLv3 適合你們。

你們的公司可能為自己的項目準備了特定的許可協(xié)議。例如，它可能需要許可許可證，以便公司可以在公司的閉源產(chǎn)品中使用你們的項目。或者你們的公司要求強大的 copyleft 許可協(xié)議同時要求貢獻者贊成，這樣項目只屬于你們公司，沒有人能在有關(guān)的軟件中使用你們的項目。或者你們的公司可能有與標準，社會責任或透明度相關(guān)的某些需求，其中任何一個都可能需要特定的許可策略。與你們公司的法律部門談?wù)劇?/p>

當你們在GitHub上創(chuàng)建了一個新項目，它給你們提供了選擇許可協(xié)議的機會。包括上面提到的可以使你們的GitHub項目開源的許可協(xié)議。如果你們想要了解其他選擇，可以通過查閱 choosealicense.com 找到適合你們項目（即使它不是軟件）的許可協(xié)議。

如果我想更換項目的許可協(xié)議，該怎么辦？

大多數(shù)項目絕不需要更換許可協(xié)議。但是情況偶爾有變。

例如，隨著你們項目的壯大，它添加了新的依賴或用戶，或者你們的公司改變了策略，或者其他的要求要更換不同的許可協(xié)議。如果你們在開始項目的時候沒有添加許可協(xié)議，那么再添加一個許可協(xié)議和更換許可協(xié)議是一樣的效果。當你們要添加或者更換項目的許可協(xié)議時，需要考慮以下三件事：

這件事很復雜。確定許可協(xié)議的兼容性和合規(guī)行，以及誰擁有版權(quán)，這會非常快速地變得復雜和混亂。為新的發(fā)布和貢獻選擇一個新的且合適的許可協(xié)議與重新許可已存在的貢獻是不同的。一旦你們有任何想改變許可協(xié)議的想法，請首先讓法律團隊知道。即使你們已經(jīng)或者能獲得可以更換許可協(xié)議的權(quán)限，請考慮者會給項目的其他用戶和貢獻者帶來怎樣的影響。將更換許可協(xié)議視為“管理事件”，只有通過與項目的利益相關(guān)者進行明確的溝通和咨詢，才更有可能順利進行。請謹記，從一開始就為你們的選擇和使用合適的許可協(xié)議。

你們的項目已經(jīng)有了許可協(xié)議。如果項目的現(xiàn)有許可證與您要更改的許可證兼容，則可以開始使用新許可證。這是因為如果A許可協(xié)議與B許可協(xié)議兼容，你們將遵守A的條款，同時遵守B的條款（但不一定反之亦然）。因此，如果你們目前正在使用許可型的許可協(xié)議（例如 MIT），則可以更改為具有更多條件的許可協(xié)議，只要你們保留 MIT 許可協(xié)議的副本和任何相關(guān)的版權(quán)聲明（即繼續(xù)遵守 MIT 許可協(xié)議的最低條件）。如果你們現(xiàn)在的許可協(xié)議不是許可型的（例如，copyleft 或者你們還沒有許可協(xié)議）以及你們不是版權(quán)的唯一所有者，那么你們不能將許可協(xié)議改為 MIT。基本上，只要是使用的許可型的許可協(xié)議，版權(quán)所有者能事先更換許可協(xié)議。

你們的項目已經(jīng)有版權(quán)所有者。如果你們是你們項目的唯一貢獻者，然后你們或者你們的公司是項目版權(quán)的唯一所有者。你們可以添加或更換任何你們或者你們公司心儀的許可協(xié)議。不然你們需要取得其他版權(quán)所有者的同意。他們是誰？他們是已經(jīng)參與你們項目提交的人。但有些情況是項目版權(quán)掌握在這些人的雇主手中。在某些情況下，人們只是做了微小的貢獻，但沒有硬性規(guī)定，在一些行代碼下的貢獻不受版權(quán)保護。對與這樣的情況該怎么辦？對于一個相對較小以及年輕的項目來說，取得所有貢獻者對更換許可協(xié)議的同意是可行的。。但對于大項目和老項目來說，你們必須尋求很多貢獻者以及他們繼承者的共識。Mozilla 花費了多年重新授權(quán) Firefox，Thunderbird 和相關(guān)軟件。

或者，你們可以讓貢獻者事先同意（通過額外的貢獻者協(xié)議 - 見下文）在某些條件下更改某些許可協(xié)議，這些更改將超過現(xiàn)有的開源許可協(xié)議。這會改變許可協(xié)議改的復雜性。如果在執(zhí)行許可協(xié)議更改時，你們?nèi)匀幌胍晚椖坷嫦嚓P(guān)者進行溝通，你們需要從你們律師那得到更多幫助。

我的項目需要額外的貢獻者協(xié)議嗎？

]可能不要。對于大多數(shù)的開源項目，一個開源許可協(xié)議可作用與所有貢獻者和用戶。

貢獻者協(xié)議會給維護者帶來額外的管理工作。這些協(xié)議增加了多少工作得取決去項目和實施。簡單的協(xié)議可能要求貢獻者確認和點擊，在項目的開源許可協(xié)議下他們有權(quán)利貢獻。更復雜的協(xié)議可能需要法律的審查和貢獻者的雇主的簽字。

此外，貢獻者協(xié)議有時被認為對項目社區(qū)不友好。他們也增加了人們參與社區(qū)的障礙。

image.png

我們已經(jīng)刪除了 Node.js 的 CLA。這樣做降低了 Node.js 貢獻者的參與門檻，從而吸引更多的貢獻者。

— @bcantrill, "Broadening Node.js Contributions"

一些情況下你們可能想要為你們的項目考慮一個額外的貢獻協(xié)議：

• 你們的律師想要所有的貢獻者明確接受貢獻者條款，或者因為他們覺得只有開源許可協(xié)議還遠遠不夠。如果這是唯一的問題，那么有肯定項目開源許可協(xié)議的貢獻者協(xié)議就足夠了。jQuery 個人貢獻者許可協(xié)議就是一個很好的輕量級的個人貢獻者協(xié)議。對于一些項目來說，Developer Certificate of Origin 是一個很好的先擇。
• 你們的項目使用的開放源許可協(xié)議不包括明確的專利授權(quán)（如 MIT），你們需要所有貢獻者的專利授權(quán)，這些可能適合用于你們公司的專利組合或者項目的其他貢獻者和用戶。Apache 個人貢獻者許可協(xié)議是一種常用的附加貢獻者協(xié)議，其具有與 Apache 許可 2.0 中的專利許可相同的專利許可。
• 如果你們的項目使用的是 copyleft 許可協(xié)議，但你們也需要分發(fā)項目的專有版本。那你們需要每個貢獻者分配版權(quán)給你們或者授予你們許可權(quán)。MongoDB 貢獻者協(xié)議就是這中類型的。
• 你們認為你們的項目在其有效期內(nèi)需要更換許可協(xié)議，以及事先得到貢獻者的同意。

如果您們實需要在您的項目中使用額外的貢獻者協(xié)議，請考慮使用諸如 CLA 助手之類的集成，以最大限度地減少貢獻者的分心。

我的公司的法律團隊需要知道什么？

作為一名公司的雇員，如果你們在發(fā)布一個開源項目，你們首先需要讓法律團隊知道。
即使只是一個個人項目，請考慮讓他們知道。你們可能和公司有一個“員工知識產(chǎn)權(quán)協(xié)議”，這給了公司一些對你們項目的控制權(quán)，特別是當項目和公司的業(yè)務(wù)有著很多的聯(lián)系或者你們使用公司的資源發(fā)展項目。你們的公司應該很容易給們許可，也許已經(jīng)通過一個員工友好的知識產(chǎn)權(quán)協(xié)議或公司政策。如果不是這樣，你么可以談判（例如，解釋你們的項目為公司的專業(yè)學習和發(fā)展目標服務(wù)），或者你們在找到一個更好的公司前停止你們項目的工作。

如果你們的開源項目是為了你們的公司，者絕對需要讓他們知道。根據(jù)公司的業(yè)務(wù)需求和專業(yè)知識，你們的法律團隊可能已經(jīng)制定了有關(guān)開放源代碼許可協(xié)議（以及可能還有其他貢獻者協(xié)議）的政策，以確保您的項目符合其依賴關(guān)系的許可協(xié)議。如果不是這樣，你們和他們很幸運！你們的法律團隊應該渴望與你們合作，把這個東西搞清楚。你們需要思考這些事：

• 第三方資源：你們的項目有其他人創(chuàng)建的依賴或者使用他人的代碼？如果這些事開源項目，你們需要遵守第三方資源的開源許可協(xié)議。首先，選擇與第三方資源的開放源許可協(xié)議一起使用的許可協(xié)議（見上文）。如果你們的項目修改或者發(fā)布第三方開源資源，那么你們法律團隊還想知道你們符合第三方開源許可協(xié)議的其他條件，例如保留版權(quán)聲明。如果你們使用了其他沒有開源許可協(xié)議的代碼，那么你們可能會要求第三方資源的維護者添加一個開源許可協(xié)議，要是你們得不到許可，你們只能停止使用他們的代碼。

• 商業(yè)機密：請考慮項目中是否有公司不想對外公開的東西。如果是這樣的話，你們只能開源項目的一部分，得保護好公司的商業(yè)機密。

• 專利：你們公司是否申請了與你們項目有關(guān)的專利？如果開源源代碼，這會對公司的專利進行公開披露。可悲的是，你們可能被要求等待（或者公司會重新思考應用程序）。如果你們期望從擁有大量專利組合的公司的員工那里得到貢獻，們的法律團隊可能希望你們使用來自貢獻者的明確專利授權(quán)的許可協(xié)議（例如 Apache 2.0 或 GPLv3）或其他貢獻者協(xié)議（見上文）。

• 商標：認真檢查你們的項目名[沒有與已經(jīng)存在的商標沖突](https://github.com/liadbiz/opensource-contribute-guide-chinise/blob/master/github-open-source-guide-02.md# 避免命名沖突)。如果你們將自己公司的商標用于項目，請檢查它有沒有造成沖突。FOSSmarks 是在自由和開源項目的背景下理解商標的實用指南。

• 隱私：你們的項目是否收集了用戶數(shù)據(jù)并存儲到公司的服務(wù)器？你們的法律團隊可以幫助你們遵守公司政策和外部法規(guī)。

如果你們發(fā)布了公司的第一開源項目，為了能通過，以上這些綽綽有余（不要擔心，大多數(shù)項目不會引起重大關(guān)注）。
長期來說，們的法律團隊可以做更多的事情，以幫助公司從開源中獲得更多，并保持安全：

• 員工貢獻策略：考慮制定一個公司策略，指明你們的員工如何為開源項目貢獻。明確的政策將減少你們員工的迷惑，并幫助他們?yōu)楣镜淖罴牙嫦蜷_源項目做貢獻，無論是作為他們工作的一部分還是在自由時間。Rackspace的Model IP和開源貢獻策略就是很好的示例。

image.png

放棄與補丁相關(guān)的只是產(chǎn)權(quán)以構(gòu)建員工知識庫和信譽。它表明，公司關(guān)心員工的發(fā)展，以及讓員工有種被賦權(quán)和自主的感覺。所有這些好處還導致更高的士氣和更好地保留員工。
— @vanl, "A Model IP and Open Source Contribution Policy"

• 發(fā)布什么：（幾乎） 所有？如果你們的法律團隊了解并投資于你們公司的開源策略，他們將是你們最好的幫助，而不是阻礙你們的努力。

• 合規(guī)性：即使你們公司沒有發(fā)布任何開源項目，他們也會使用別人的開源軟件。意識和過程可以避免麻煩，產(chǎn)品延遲發(fā)布和訴訟。

  組織必須具有適合[“允許”和“copyleft”]類別的許可協(xié)議和合規(guī)性策略。首先，記錄適用于你們所使用的開源軟件的許可條款（包括子組件和依賴項）。
  — Heather Meeker, "Open Source Software: Compliance Basics And Best Practices"

• 專利：你們的公司可能希望加入開放發(fā)明網(wǎng)絡(luò)，一個共享的專利防御池，以保護成員使用主要開源項目，或探索其他替代專利許可。

• 管理：特別是當如果將項目轉(zhuǎn)移到公司以外的法律實體是有意義的。