在本文中，我们将讨论一些版权问题，但主要是为 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。 这一点对于投票反对是决定性的。
总的来说，我们的选择最初倾向于 GPL3 正是因为修改后的代码在同一许可证下分发。 我们认为这样可以保护我们的产品，但我们发现 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的开源框架，用于创建基于元数据的高级Web应用程序，不需要严格的编程技能。
应用程序功能的基础是数据注册表 - 注册模块。 这是一个关键模块，直接设计用于处理基于元数据结构的数据 - 包括用于管理项目、计划、事件等。该项目还使用门户模块来显示任意数据模板 - 它实现了存档前端注册表。
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 版（“许可证”）获得许可；
除非符合许可，否则您不得使用此文件。
您可以在以下位置获取许可证副本除非适用法律要求或书面同意，否则软件
根据许可证分发是按“原样”分发的，
不附带任何明示或暗示的保证或条件。
有关管理权限的特定语言，请参阅许可证
许可证下的限制。
许可=合同
免费许可证虽然是免费的，但不允许放纵，我们已经给出了限制的示例。 选择许可证时要考虑到您和用户的兴趣，因为开源软件是专门为用户设计的。 项目的用户应将许可证视为他与版权所有者之间的一种协议，因此在对源代码执行任何操作之前，请仔细研究项目许可证对您施加的限制。
我们希望我们已经对许可证主题有所了解，尽管问题很复杂，但它不应该成为您走向开源之路的障碍。 开发您的项目，不要忘记您和他人的权利。
有用的链接
最后，一些有用的资源可以帮助我们搜索有关现有许可证的信息并选择最适合我们目的的许可证：
- 超级有用 从
来源： habr.com