在本文中，我們將討論一些版權問題，但主要是為 RAD 框架選擇免費許可證 以及基於它的開源產品。 我們將告訴您有關許可的信息 阿帕奇2.0，關於是什麼導致我們這樣做以及我們在過程中面臨哪些決定。
選擇許可證的過程是相當勞動密集型的，應該在充分閱讀的情況下進行，如果您不是法律教育的快樂擁有者，那麼關於各種免費許可證的未開發的信息領域就會在您面前展開。 主要要做的是製定一些限制標準。 透過討論和反思的過程，您和您的團隊將能夠了解您希望允許使用者使用您的產品以及禁止什麼。 當您手中已經有了某種描述時，您需要將其疊加在現有許可證上，並選擇最多點重合的一個。 當然，這聽起來很簡單，但實際上，即使在討論之後，問題仍然存在。
首先，附上一個鏈接 ，一個我們廣泛使用的有用網站。 特別注意 根據 13 項主要標準頒發許可證。 願英語和耐心與你同在。
選擇的痛苦
讓我們從許可證的一般特徵開始 。 開源軟體意味著完全免費的許可證，不根據模型限製商業和非商業分發 。 因此，以免費授權將軟體放在網路上並不能完全限制第三方的轉讓、分發和銷售，您只需為此做好心理準備即可。
免費授權賦予使用者參與軟體逆向工程或以其他可用方式更改軟體的權利。 大多數授權不允許您重新命名產品或對其進行任何操作，從而更改系統作者和/或所有者的權利。
我們對免費許可證感興趣的主要問題是：
- 對軟體所做的更改是否應該被記錄並且與系統的版權所有者無關？
- 衍生軟體的名稱是否不應與版權人的軟體名稱相同？
- 是否可以將任何新版本的授權更改為另一個版本，包括專有版本？
在仔細查看最常見的許可證清單後，我們選擇了幾個我們更詳細考慮的許可證。 潛在的許可證 分別是：GNU GPLv3、Apache 2.0、MIT 和 MPL。 麻省理工學院 幾乎立即被排除，這是一個寬鬆的非 Copyleft 許可證，它允許以幾乎任何方式使用、修改和分發程式碼，但我們對這個選項並不滿意，我們仍然希望該許可證能夠規範版權之間的關係持有者和使用者。 GitHub 上的大多數小型專案都是在 MIT 授權或其各種變體下發布的。 許可證本身很短，唯一的禁令是表明軟體創建者的作者身份。
接下來是許可證 MP2.0。 誠然，我們並沒有立即想到它，但在更詳細地研究之後，我們很快就排除了它，因為主要缺點是許可證不適用於整個項目，而是適用於單個文件。 另外，如果使用者更改了文件，則無法更改許可證。 事實上，無論你多麼努力地改變一個開源項目，你永遠無法因為這樣的許可證而將其貨幣化。 順便說一句，這與版權所有者無關。
許可證也存在類似問題 GNU GPLv3。 它要求任何文件都保留在其下。 GNU GPL 是 Copyleft 許可證，要求衍生作品開源並保持在同一許可證下。 也就是說：透過重寫兩行程式碼，您將被迫提交更改，並在進一步使用或分發期間將程式碼保存在 GNU GPL 下。 在這種情況下，這對我們專案的使用者來說是一個限制因素，而不是對我們來說。 但禁止將 GPL 更改為任何其他許可證，即使在 GPL 版本中也是如此。 例如，如果你改變 LGPL （GPL 的附加）到 GPL，那就沒有辦法回到 LGPL。 這一點對於投票反對是決定性的。
總的來說，我們的選擇最初傾向於 通用公共許可證3 正是因為修改後的程式碼在同一許可證下分發。 我們認為這樣可以保護我們的產品，但我們發現 Apache 2.0 中的風險更少。 根據自由軟體基金會的說法，GPLv3 與 Apache License v2.0 相容，這意味著始終可以將授權從 Apache License v2.0 更改為 GPL v3.0。
阿帕奇2.0
— 平衡的許可許可，強調版權。 以下是她對我們感興趣的問題的回答。 對軟體所做的更改是否應該被記錄並且與系統的版權所有者無關？ 是的，所有更改都必須記錄在案，我們不對原始程式碼或修改後的程式碼負責。 包含變更的檔案必須附加到您進行這些變更的程式碼中。 衍生軟體的名稱是否不應與版權人的軟體名稱相同？ 是的，衍生軟體應以不同的名稱和不同的商標發布，但應註明版權所有者。 是否可以將任何新版本的授權更改為另一個版本，包括專有版本？ 是的，它可以在不同的許可證下發布，Apache 2.0 不限制任何非商業和商業許可證的使用。
此外，在發布基於 Apache 2.0 開源程式碼的新產品或具有附加功能的產品時，無需使用相同的授權。 您可以在下方看到包含 Apache 2.0 授權的條款和限制的圖片。
該許可證強加了保留和提及版權以及發佈軟體所依據的許可證的要求。 強制性可用性 版權聲明 帶有版權所有者名稱和許可證的軟體可以保護軟體原作者的權利，因為即使它被重新命名、贈送或根據不同的許可證出售，作者的標記仍然會保留。 您也可以使用該文件來實現此目的 注意事項 並將其附加到原始程式碼或專案文件中。
我們根據 Apache 2.0 授權在 GitHub 上公開發布所有產品，除了 其原始碼於今年 3 月由遠東社會技術中心以 GPLvXNUMX 許可在 GitHub 上發布。 目前，除了 和 發表 框架上做出來的。 在集線器上我們已經討論過 和關於 .
那些。 有關框架的詳細信息
離子病毒。 Framework是一個基於node.js的開源框架，用於創建基於元資料的高級網路應用程序，不需要嚴格的程式設計技能。
應用程式功能的基礎是資料註冊表 - 註冊模組。 這是一個關鍵模組，直接設計用於處理基於元資料結構的資料- 包括用於管理專案、計劃、事件等的資料。該專案還使用入口網站模組來顯示任意資料模板- 它實現了存檔前端註冊表。
MongoDb 用於 DBMS - 它儲存應用程式設定、元資料和資料本身。
如何為您的專案申請許可證？
新增文件 許可 使用專案儲存庫中的授權文本，瞧，這是一個受 Apache 2.0 保護的專案。 您需要註明版權所有者，僅此而已 版權聲明。 這可以在原始碼或檔案中完成 注意事項 （一個文字文件，列出了 Apache 許可證下許可的所有庫及其創建者的姓名）。 將文件本身放在原始碼中或隨作品分發的文件中。 對我們來說，它看起來像這樣：
版權所有 © 2018 ION DV LLC。
在 Apache 許可下獲得許可，版本 2.0
Apache 2.0 許可證文本
Apache許可證
2.0版，2004年XNUMX月
使用，複製和分發的條款和條件
-
定義。
「許可」指使用、複製、
以及本文檔第1至9節定義的分發。「授權人」指版權所有者或經其授權的實體
授予許可的版權所有者。「法人實體」指行為實體和所有實體的聯合體
控制，受其控製或受其控制的其他實體
該實體的控制權。 出於此定義的目的，
「控制」是指 (i) 直接或間接導致
對該實體的指示或管理，無論是通過合同還是
否則，或（ii）擁有百分之五十（50％）或以上的所有權
已發行股份，或（iii）該實體的實益擁有權。「您」（或「您的」）是指個人或法人實體
行使本許可證授予的權限。「來源」形式是指進行修改的首選形式，
包括但不限於軟件源代碼，文檔
來源檔案和設定檔。「物體」形式是指由機械產生的任何形式
源形式的轉換或翻譯，包括但
不限於已編譯的目標代碼，生成的文檔，
並轉換為其他媒體類型。「作品」是指作者的作品，無論是來源或
對象表，根據許可證提供，如
作品隨附或隨附的版權聲明
（下面的附錄中提供了一個範例）。「衍生作品」指任何作品，無論是來源作品或物件作品
表格，該表格基於（或衍生自）作品，並且
編輯修訂，註釋，細化或其他修改
總體上代表原創作品。 出於目的
在本許可的範圍內，衍生作品不應包括剩餘的作品
與以下接口可分離或僅鏈接（或按名稱綁定）：
作品及其衍生作品。「貢獻」指任何原創作品，包括
作品的原始版本以及任何修改或增補
該作品或其衍生作品，是有意的
提交給許可方，以供版權所有者將其包含在作品中
或由有權代表提交的個人或法人實體
版權所有者。 就本定義而言，“已提交”
指發送的任何形式的電子，口頭或書面通訊
給許可人或其代表，包括但不限於
在電子郵件列表，源代碼控制系統，
和由或代表其管理的問題跟踪系統
出於討論和改進工作的目的而授予許可的人，但是
排除明顯標記或其他方式的通信
由版權所有者書面指定為“非貢獻”。「貢獻者」指授權人和任何個人或法人實體
許可方代表誰收到了捐款，並且
隨後納入工作。 -
授予版權許可。 受條款及細則約束
本授權書，每位貢獻者特此授予您永久的，
全球性，非排他性，免費，免版稅，不可撤銷
複製，準備以下作品的版權作品的版權許可：
公開展示，公開表演，再許可和分發
源或對象形式的作品和此類衍生作品。 -
授予專利許可。 須遵守以下條款與條件
本授權書，每位貢獻者特此授予您永久的，
全球性，非排他性，免費，免版稅，不可撤銷
（本節中規定的除外）已取得，已經取得，
使用，提供要約，出售，進口和以其他方式轉讓作品，
此類許可僅適用於應許可的專利權利要求
被此類貢獻者侵犯的貢獻者
單獨貢獻或將其貢獻合併
提交此類貢獻的作品。 如果你
針對任何實體（包括
在訴訟中提出交叉要求或反要求），指控該作品
或作品中包含的貢獻直接構成
或共同專利侵權，然後是任何專利許可
根據本許可協議授予您的作品應終止
自提起此類訴訟之日起。 -
重新分配。 您可以複製和散佈以下內容的副本
在任何媒介中，無論是否帶有或不帶有其作品
修改，並以“源”或“對象”形式提供，前提是您
滿足以下條件：（a）您必須將作品的其他任何收件人或
衍生作品本許可的副本； 和(b) 您必須讓任何修改的文件有顯著的通知
說明您更改了文件； 和© 您必須以任何衍生作品的源形式保留
您分發的所有版權，專利，商標和
作品來源形式的出處通知，
排除與本手冊任何部分無關的那些聲明
衍生作品； 和(d) 若作品包含「通知」文字檔案作為其一部分
發行，那麼您發行的任何衍生作品都必須
附上一份清晰的歸屬通知書副本
在此類通知文件中，不包括那些不包含的通知
與衍生作品的任何部分有關，至少有一個
以下位置： 在分發的 NOTICE 文字檔案內
作為衍生作品的一部分； 在“源”表單中或
文件（如果與衍生作品一起提供）； 或者，
在衍生作品產生的顯示中，如果且
通常在此類第三方通知出現的任何地方。 內容
NOTICE 文件的內容僅供參考，且
不要修改許可證。 您可以添加自己的歸屬
您分發的衍生作品中的通知
或作為“作品”中“通知”文本的附錄（已提供）
這樣的附加歸屬通知不能被解釋
作為修改許可證。您可以在修改內容中添加自己的版權聲明，
可能會提供其他或不同的許可條款和條件
供您使用，複製或分發您的修改，或
對於所有此類衍生作品，只要您使用，
作品的複制和分發符合
本許可證中規定的條件。 -
提交貢獻。 除非您另有明確說明，
有意提交以包括在作品中的任何貢獻
您授予許可方的條款和條件
本許可，無任何其他條款或條件。
儘管有上述規定，本文中的任何內容均不得取代或修改
您可能已執行的任何單獨許可協議的條款
與許可方就此類貢獻進行協商。 -
商標。 本許可證不授予使用該貿易的許可
許可方的名稱，商標，服務標記或產品名稱，
除非出於合理和習慣使用的目的描述了
作品的起源並複製通知文件的內容。 -
免責聲明。 除非適用法律要求或
書面同意，由許可方提供作品（每個
貢獻者以「原樣」提供其貢獻，
沒有任何明示或明示的保證或條件
暗示的，包括但不限於任何擔保或條件
的標題，不侵權，可銷售性或適用性
特殊用途。 您應全權負責確定
使用或重新分發作品的適當性並承擔任何責任
與您在本許可下行使許可有關的風險。 -
責任限制。 在任何情況下，在沒有法律理論的情況下，
無論是侵權（包括過失），合同還是其他方式，
除非適用法律要求（例如故意和嚴重
疏忽大意的行為）或書面同意，任何貢獻者應
對您負責，包括任何直接，間接，特殊，
由於以下原因而產生的任何性質的偶然或間接損失
本許可的結果，或者由於不使用或無法使用
工作（包括但不限於因商譽損失，
停工，計算機故障或故障或任何其他原因
其他商業損害或損失），即使該貢獻者
已被告知可能造成此類損害。 -
接受保固或附加責任。 重新分配時
您的作品或其衍生作品，您可以選擇提供，
並收取以下費用：接受支持，保修，賠償，
或與此相關的其他責任義務和/或權利
執照。 但是，在接受此類義務時，您只能採取行動
代表您自己並獨自承擔責任，而不是代表
任何其他貢獻者，並且只有在您同意賠償的情況下，
捍衛每個貢獻者，並使他們不承擔任何責任
該貢獻者因理由引起或主張的索賠
您接受任何此類保證或其他責任。END條款和條件
附錄：如何將Apache許可證應用於您的工作。
要將Apache許可證應用於您的工作，請附加以下內容
樣板通知，其中字段用括號“[]”括起來
替換為您自己的識別信息。 （不包括
括號！）文本應放在適當的位置
文件格式的註解語法。 我們也建議
文件或類別名稱以及目的描述包含在
與版權聲明相同的“列印頁”，更容易
第三方檔案中的標識。版權[yyyy] [版權所有者名稱]
根據 Apache 許可證 2.0 版（“許可證”）獲得許可；
除非遵守許可，否則不得使用此文件。
您可以在以下位置獲得許可的副本：除非適用法律要求或書面同意，否則軟件
根據許可證分發是按“原樣”分發的，
沒有任何明示或暗示的保證或條件。
有關特定語言的管理權限，請參閱許可證。
許可中的限制。
許可=合約
免費許可證雖然是免費的，但不允許放縱，我們已經給出了限制的範例。 選擇許可證時要考慮到您和使用者的興趣，因為開源軟體是專門為使用者設計的。 專案的使用者應將許可證視為他與版權所有者之間的協議，因此在對原始程式碼執行任何操作之前，請仔細研究專案許可證對您施加的限制。
我們希望我們已經對許可證主題有所了解，儘管問題很複雜，但它不應該成為您走向開源之路的障礙。 開發您的項目，不要忘記您和他人的權利。
有用的鏈接
最後，一些有用的資源可以幫助我們搜尋有關現有許可證的資訊並選擇最適合我們目的的許可證：
- 超級有用 從
來源： www.habr.com