1. 自由度

1.1. 自由運行程序，無論出于何種目的（自由度0）?

1.2. 自由研究程序的工作原理并對其進行更改，以便讓它按照你的意愿進行計算（自由度1）?

• 1.2.1. 訪問源代碼是實現這一目標的先決條件

1.3. 重新發布副本的自由，以便你可以幫助其他人（自由度2）?

1.4. 將修改后的版本的副本分發給其他人的自由（自由度3）

• 1.4.1. 這樣做你可以讓整個社群有機會從你的更改中受益

• 1.4.2. 訪問源代碼是實現這一目標的先決條件

2. 開源許可證

2.1. 一個好的軟件開發者會沉迷于代碼中類似的細節，如縮進、語句內的間距、括號的位置、注釋和變量命名

2.2. 代碼樣式指南的目的是為希望擴展代碼的下游用戶以及未來的項目維護者節省時間，許可證和知識產權管理也是如此，它們都為相關人員節省時間，使代碼更容易在項目下游使用

2.3. 旨在提供清晰一致的指導和文檔，明確代碼的使用方式，貢獻代碼的期望和義務，以及品牌使用的規范

2.4. 開源許可證的類型很多，如果我們歸納所有的許可證，就會發現有的許可證較為寬松，有的則較為嚴格（非寬松許可證，也稱為copyleft）?，規定了開源代碼的用戶責任和限制

2.5. 開源有這些選擇是一件好事，但是選擇太多也會帶來困惑

• 2.5.1. 所選許可證的義務

• 2.5.1.1. 看到許多許可證在關于如何履行義務方面的條款并不清楚

• 2.5.2. 一個許可證下的代碼如何被另一個擁有不同許可證的項目利用或使用

• 2.5.2.1. 根據許可證的不同，這可能導致代碼需要獲取新的許可證才能符合要求

• 2.5.3. 許可證變體的差異以及為什么你會選擇其中一種

• 2.5.3.1. BSD許可證系列是一個很好的例子，它有4種官方變體，還有許多衍生變體

• 2.5.3.2. 每種許可證都有不同的小規定來解決不同的情況

2.6. 寬松許可證

• 2.6.1. 寬松許可證通常是最簡單的開源許可證類型

• 2.6.2. 還允許用戶在最小的義務下使用代碼

• 2.6.3. 寬松許可證會盡量避免對項目本身、授予的軟件專利，以及任何其他保證承擔責任

• 2.6.4. 項目或代碼的作者只想讓代碼公開并供人們使用

• 2.6.5. Apache-2.0許可證屬于寬松許可證類別，但為下游用戶提供了更多保證

• 2.6.5.1. 它是項目貢獻者向每個下游用戶授予的許可證，在版權許可方面較為明確

• 2.6.5.2. 確保項目貢獻者擁有的任何軟件專利都被授予下游用戶的許可證

>  2.6.5.2.1. 有助于解決在貢獻者協議或其他文檔中明確專利使用的問題

• 2.6.5.3. 通常在開源領域中，Apache-2.0許可證變得非常受歡迎，因為它對企業更友好

2.7. 非寬松許可證或copyleft

• 2.7.1. 通常寬松許可證不會明確定義下游用戶的特定責任，而非寬松許可證或copyleft則明確地設定了這些預期

• 2.7.2. 在這類許可證中最著名的可能是GNU通用公共許可證，Linux內核項目和許多作為開源構建的桌面應用程序（如Blender、Inkscape、LibreOffice等）都使用了該許可證

• 2.7.3. copyleft的目的是確保項目中的代碼以及下游所做的任何改進都保持在與項目相同的許可證下

• 2.7.4. 這種許可模式在Linux內核項目、GNU工具鏈等越來越受歡迎的項目中起著非常重要的作用

• 2.7.5. 對copyleft開源代碼的擔憂，可以歸結為將其整合到其他專有軟件中的能力

• 2.7.5.1. 促使產品供應商遠離copyleft軟件

• 2.7.5.2. 無論是不將其整合到他們正在構建的專有軟件中，還是完全不使用它

• 2.7.6. Tivo

• 2.7.6.1. Tivo機頂盒的軟件將Linux內核和GNU工具鏈的代碼合并到所使用的軟件中

• 2.7.6.2. 雖然Tivo遵守了GNU通用公共許可證第2版的條款，但他們的硬件中集成了數字權利管理(Digital Rights Management，DRM)，使得無法在硬件上運行修改后的代碼，這被稱為Tivo化

• 2.7.6.3. 雖然Tivo化在許可證的字面意思上是允許的，但違背了許可證的精神，它在很大程度上推動了GNU通用公共許可證第3版的出現

• 2.7.7. 云服務提供商使用開源軟件

• 2.7.7.1. 該軟件根本沒有被分發，而是由用戶在共享系統上使用，這個概念直到21世紀初才被普及

• 2.7.7.2. 像GNU Affero通用公共許可證和Commons Clause這樣的許可證應運而生，解決了這些問題，它們要求提供在這些系統上運行的開源許可證軟件

2.8. 對許可證違規者采取法律行動是明智的，但在絕大多數情況下，與他們聯系是更好的解決方案

• 2.8.1. 依據許可證維權是項目維護者或作者應該關注的焦點，畢竟他們是直接受到影響的人

3. 哪種類型的許可證對項目有意義

3.1. 用戶是誰？你希望用戶如何使用代碼？

3.2. 否需要設定將代碼和開發推向上游（即項目的主要代碼倉庫）的期望？或者這已經在社群文化中了？

3.3. 你是否期望商業使用？作為項目維護者，你對此有何感想？

3.4. 這是什么類型的項目？庫？現成的應用程序？還是框架？

3.5. 一個好的開源項目會把用戶放在第一位

3.6. 庫、框架和集成層，在寬松許可證下它們可以工作得更好

• 3.6.1. 其原因在于代碼使用的意圖，它將與專有代碼混合在一起，因此copyleft的義務將是一個主要問題

3.7. 對于更多的終端用戶應用程序，如桌面或Web應用程序，一般趨勢是選擇copyleft

• 3.7.1. 主要是為了鼓勵上游開發并使版本和發布節奏更加一致，同時也使希望構建商業模型的供應商不要太過關注銷售副本，而應更多地提供支持和培訓等附加服務

3.8. 在軟件進入一個競爭激烈的領域，且存在多個商業解決方案時，使用copyleft是有幫助的

3.9. 一旦你選擇了一種許可證，要改變它就需要付出很多努力

• 3.9.1. 最大的問題在于，要改變許可證，每個為該項目作出貢獻的貢獻者都必須同意重新授權他們貢獻的代碼

3.10. MongoDB原來使用的是GNU Affero通用公共許可證第3版(AGPL v3)

• 3.10.1. 因為擔心云服務提供商利用MongoDB賺錢，而MongoDB公司卻得不到任何收益，所以他們改用了新的服務器端公共許可證(Server Side Public License，SSPL)

3.11. Redis Labs由于對云服務提供商有一些擔憂，在其開源代碼中添加了Commons Clause

3.12. SugarCRM最初在自己的SugarCRM公共許可證下提供其社群版，后來轉向AGPL v3，最后轉向完全專有的產品

4. 版權和貢獻簽署

4.1. 當人們考慮許可證和知識產權管理時，談話通常集中于出站許可證，也就是項目使用的許可證

4.2. 同樣重要（甚至更重要）的是代碼進入項目所遵循的條款，因為如果代碼進入項目的許可證或條款與代碼發布的許可證不兼容，那么下游用戶就難以使用該代碼

4.3. CLA

• 4.3.1. 簽署貢獻者許可協議(Contributor License Agreement，CLA)

• 4.3.2. CLA是由貢獻者簽署的法律文件，它在項目和貢獻者之間就貢獻者對項目所作貢獻的條款和條件提供了一份協議

• 4.3.3. CLA可以是與個人或組織達成的協議，分別稱為個人貢獻者許可協議(Individual Contributor License Agreement，ICLA)或公司貢獻者許可協議(Corporate Contributor License Agreement，CCLA)

• 4.3.4. CLA的條款常常有點零亂，除非使用標準模板（如Apache CLA）?，否則組織往往需要法律審核才能放心地為項目作出貢獻

• 4.3.5. 使用CLA可以解決一些開源項目許可證可能存在的不明確之處

• 4.3.6. 像Apache-2.0這樣的許可證通常會使CLA變得多余，從而消除對CLA的需求，這是它在商業供應商驅動的開源項目中受歡迎的一個因素

• 4.3.7. 即使使用CLA，也可以使用自動化工具（如LFX EasyCLA）執行，堅持使用標準模板可以降低摩擦

4.4. DCO

• 4.4.1. 開發者原創聲明(Developer Certificate of Origin，DCO)

• 4.4.2. 在Linux內核項目中存在一種貢獻由集體共有而非個體所有的文化

• 4.4.2.1. 它確保了技術可以公開發展，沒有特定供應商能夠在未征得所有貢獻者同意的情況下將項目引向某個方向

• 4.4.2.2. 可以將該項目看作某種公共資源

• 4.4.3. 貢獻者通過在其源代碼提交消息中添加“Signed-off-by:”行來進行聲明

5. 品牌和標志管理

5.1. 管理項目的知識產權不僅僅是代碼，因為品牌、項目名稱和其他資產對開源項目的成功也非常重要

5.2. 對于一個較小的項目，這可能看起來不是什么大問題，但對于一個較大的項目，則可能對其成功至關重要

5.3. 確定項目的名稱

• 5.3.1. 一個項目應該先確定自己的品牌是什么

• 5.3.2. 這在很大程度上涉及它對用戶的獨特性

• 5.3.3. Apache HTTP Server之所以被命名為這個名稱，是因為它是原始NCSA Web服務器的補丁

5.4. 品牌一致性

• 5.4.1. 一旦項目有了一個名字，下一步就是建立品牌

• 5.4.2. 保持全面的一致性

• 5.4.3. 標志也是如此

• 5.4.3.1. 應該具有相同的顏色、比例和設計元素

• 5.4.3.2. 看起來可能是次要的細節，但卻在品牌管理中至關重要，不僅有助于減少混淆，還可以為項目塑造一個專業的、運行良好的形象

5.5. 保護品牌

• 5.5.1. 保護品牌的最佳方法就是始終保持一致性

• 5.5.2. 保護品牌的下一個層次是商標注冊

• 5.5.2.1. 商標的用途描述為“用于區分一個賣家或提供商的商品/服務與其他賣家或提供商的商品/服務，并指示商品/服務的來源。?”

• 5.5.2.2. 注意注冊商標是一個明智的做法

• 5.5.2.3. 注冊和維護商標的成本可能比較高昂

• 5.5.3. 通常項目會尋求轉向中立供應商實體（如Linux基金會、Apache軟件基金會或軟件自由保護協會等）的領域，他們在管理商標方面擁有豐富的經驗和專業知識

5.6. 讓其他人使用你的品牌

• 5.6.1. 計劃使用客觀標準進行管理，通常第三方將參與評估過程，以確保沒有供應商偏見

• 5.6.2. 一致性計劃不會侵犯其他人使用代碼的能力

• 5.6.2.1. 代碼在項目許可證下仍然可用