mirror of
https://github.com/Dichgrem/Blog.git
synced 2025-02-23 05:58:36 -05:00
Initial commit
This commit is contained in:
Dichgrem
parent
e6644c1fda
commit
e0e5f19b4c
@ -8,6 +8,14 @@ tags = ["Tech","open","licenses"]
|
||||
|
||||
前言 本文旨在介绍开源软件许可证，这些许可证规定了使用、修改和分发开源软件的条件。通过了解不同类型的开源许可证及其特点，读者将能够更好地理解在开发和使用开源软件时的法律和道德责任。
|
||||
<!-- more -->
|
||||
对于很多刚踏入软件这个行业的小伙伴来说，「开源软件许可证」是个比较陌生的概念。但是随着经手项目逐渐增多，会发现很多项目，尤其是一些大型项目，经常会引用到别人一些优秀的开源代码，而这些优秀的开源代码通常都会在最开始简单地附上一段关于授权的声明或在项目根目录下提供完整的授权声明文件，比如：「The project is licensed under the Apache 2 license.」，诸如此类便是「开源许可证」。
|
||||
|
||||
声明开源许可证，可以让广大开发者看到并获取我们作品的同时又保留了我们作为作者的一些权利。在提高自身业界知名度的同时又能防止有人将作者名字改成自己，拿去谋取利益。
|
||||
|
||||
开源不等于免费，开源也不等于没有约束。
|
||||
|
||||
开源许可证是开源软件的授权许可，里面详尽表述了个人或组织获得开源代码后拥有的权力，包括可以进行哪些操作以及禁止哪些操作。对于绝大部分人来说，与其自己花大把时间去编写一份开源许可证，倒不如直接选择一个广为流传且合适的已有开源许可证，这样做既省心又省力。而且，靠个人完成一份开源许可证的编写也不是一件容易的事情。
|
||||
|
||||
在全球范围内，开源软件社区的活跃程度日益增长，吸引了来自不同领域的开发者和用户。然而，开源协议的法律实际应用在各国略有不同。
|
||||
|
||||
中国开源第一案：`https://linux.cn/article-11683-1.html`
|
||||
@ -48,58 +56,26 @@ tags = ["Tech","open","licenses"]
|
||||
世界上的开源许可证（Open Source License）大概有上百种，而常见的开源协议大致有GPL、BSD、MIT、Mozilla、Apache和LGPL等。
|
||||
|
||||
|
||||
他人修改源码后，
|
||||
是否可以闭源？
|
||||
+--------- No ---------- ---------- Yes ---------+
|
||||
│ |
|
||||
│ |
|
||||
| |
|
||||
| |
|
||||
新增代码是否采用 每一个修改过的文件，
|
||||
同样许可证？ 是否都必须放置版权
|
||||
+---- No ----- ----- Yes ----+ 说明？
|
||||
| | +---- No ----- ----- Yes ----+
|
||||
| | | |
|
||||
| | | |
|
||||
| | | |
|
||||
是否需要对源码的 | | |
|
||||
修改之处，提供说 | 衍生软件的广告， |
|
||||
明文档？ GPL 是否可以用你的 Apache
|
||||
+---- No ----- ----- Yes ----+ 名字销售？
|
||||
| | +---- No ----- ----- Yes ----+
|
||||
| | | |
|
||||
| | | |
|
||||
| | | |
|
||||
LGPL Mozilla BSD MIT
|
||||
|
||||
|
||||
## Apache License
|
||||
|
||||
Apache License（Apache许可证），是Apache软件基金会发布的一个自由软件许可证。
|
||||
|
||||
Apache Licence 是著名的非盈利开源组织 Apache 采用的协议。该协议和BSD类似，同样鼓励代码共享和最终原作者的著作权，同样允许源代码修改和再发布。但是也需要遵循以下条件：
|
||||
|
||||
需要给代码的用户一份 Apache Licence。
|
||||
|
||||
如果修改了代码，需要再被修改的文件中说明。
|
||||
|
||||
在衍生的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
|
||||
|
||||
如果再发布的产品中包含一个 Notice 文件，则在Notice文件中需要带有 Apache Licence。你可以在 Notice 中增加自己的许可，但是不可以表现为对 Apache Licence 构成更改。
|
||||
- 需要给代码的用户一份 Apache Licence。
|
||||
- 如果修改了代码，需要再被修改的文件中说明。
|
||||
- 在衍生的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。
|
||||
- 如果再发布的产品中包含一个 Notice 文件，则在Notice文件中需要带有 Apache Licence。你可以在 Notice 中增加自己的许可，但是不可以表现为对 Apache Licence 构成更改。
|
||||
|
||||
Apache Licence 也是对商业应用友好的许可。使用者也可以再需要的时候修改代码来满足并作为开源或商业产品发布/销售。
|
||||
|
||||
使用这个协议的好处是:
|
||||
|
||||
永久权利 一旦被授权，永久拥有。
|
||||
|
||||
全球范围的权利 在一个国家获得授权，适用于所有国家。假如你在美国，许可是从印度授权的，也没有问题。
|
||||
|
||||
授权免费 无版税， 前期、后期均无任何费用。
|
||||
|
||||
授权无排他性 任何人都可以获得授权
|
||||
|
||||
授权不可撤消 一旦获得授权，没有任何人可以取消。比如，你基于该产品代码开发了衍生产品，你不用担心会在某一天被禁止使用该代码
|
||||
- 永久权利 一旦被授权，永久拥有。
|
||||
- 全球范围的权利 在一个国家获得授权，适用于所有国家。假如你在美国，许可是从印度授权的，也没有问题。
|
||||
- 授权免费 无版税， 前期、后期均无任何费用。
|
||||
- 授权无排他性 任何人都可以获得授权
|
||||
- 授权不可撤消 一旦获得授权，没有任何人可以取消。比如，你基于该产品代码开发了衍生产品，你不用担心会在某一天被禁止使用该代码
|
||||
|
||||
## BSD
|
||||
|
||||
@ -107,11 +83,11 @@ BSD 是"Berkeley Software Distribution"的缩写，意思是"伯克利软件发
|
||||
|
||||
BSD开源协议：是一个给于使用者很大自由的协议。可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。 当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：
|
||||
|
||||
1． 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
|
||||
- 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。
|
||||
|
||||
2． 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
|
||||
- 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。
|
||||
|
||||
3． 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
|
||||
- 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。
|
||||
|
||||
BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。
|
||||
|
||||
@ -155,17 +131,17 @@ EPL协议下,你可以将源码不做任何修改来商业发布.但如果你要
|
||||
|
||||
4.独立的模块(Separate Module),不需要开源。
|
||||
|
||||
Creative Commons 知识共享协议
|
||||
## Creative Commons 知识共享协议
|
||||
|
||||
Creative Commons (CC) 许可协议并不能说是真正的开源协议，它们大多是被使用于设计类的工程上。 CC 协议种类繁多，每一种都授权特定的权利。 一个 CC 许可协议具有四个基本部分，这几个部分可以单独起作用，也可以组合起来。下面是这几部分的简介：
|
||||
|
||||
1、署名 作品上必须附有作品的归属。如此之后，作品可以被修改，分发，复制和其它用途。
|
||||
- 署名 作品上必须附有作品的归属。如此之后，作品可以被修改，分发，复制和其它用途。
|
||||
|
||||
2、相同方式共享 作品可以被修改、分发或其它操作，但所有的衍生品都要置于CC许可协议下。
|
||||
- 相同方式共享 作品可以被修改、分发或其它操作，但所有的衍生品都要置于CC许可协议下。
|
||||
|
||||
3、非商业用途 作品可以被修改、分发等等，但不能用于商业目的。但语言上对什么是"商业"的说明十分含糊不清 (没有提供精确的定义)，所以你可以在你的工程里对其进行说明。例如，有些人简单的解释"非商业"为不能出售这个作品。而另外一些人认为你甚至不能在有广告的网站上使用它们。 还有些人认为"商业"仅仅指你用它获取利益。
|
||||
- 非商业用途 作品可以被修改、分发等等，但不能用于商业目的。但语言上对什么是"商业"的说明十分含糊不清 (没有提供精确的定义)，所以你可以在你的工程里对其进行说明。例如，有些人简单的解释"非商业"为不能出售这个作品。而另外一些人认为你甚至不能在有广告的网站上使用它们。 还有些人认为"商业"仅仅指你用它获取利益。
|
||||
|
||||
4、禁止衍生作品
|
||||
- 禁止衍生作品
|
||||
|
||||
CC 许可协议的这些条款可以自由组合使用。大多数的比较严格的CC协议会声明 "署名权，非商业用途，禁止衍生"条款，这意味着你可以自由的分享这个作品，但你不能改变它和对其收费，而且必须声明作品的归属。这个许可协议非常的有用，它可以让你的作品传播出去，但又可以对作品的使用保留部分或完全的控制。最少限制的CC协议类型当属 "署名"协议，这意味着只要人们能维护你的名誉，他们对你的作品怎么使用都行。
|
||||
|
||||
@ -177,7 +153,7 @@ CC 许可协议更多的是在设计类工程中使用，而不是开发类，
|
||||
|
||||
大型科技公司不仅依赖于开放源码项目，还积极向这些项目贡献代码，或者在开源许可证下提供自家的内部工具，并将这些举措作为企业责任的体现。这表明整个开源生态系统的扩大使得开源许可证的作用变得更加重要。
|
||||
|
||||
随着技术和社会环境的不断变化，可能会出现新的许可证或者对现有许可证的修订，比如之前提到的 Elastic 放弃了 Apache 许可证因此，作为开发者和用户，我们应该时刻关注这些变化，确保我们的项目和行为符合当前的法律和道德标准。
|
||||
随着技术和社会环境的不断变化，可能会出现新的许可证或者对现有许可证的修订，比如 Elastic 放弃了 Apache 许可证。作为开发者和用户，我们应该时刻关注这些变化，确保我们的项目和行为符合当前的法律和道德标准。
|
||||
|
||||
最后，我们希望读者能够在使用和贡献开源软件时，牢记开源精神，尊重他人的劳动成果，并积极参与到开源社区的建设中去。只有通过共同的努力和合作，我们才能够推动开源软件的进步，为全球科技发展贡献自己的一份力量。
|
||||
|
||||
|
||||
@ -97,6 +97,10 @@
|
||||
<div class="post-content">
|
||||
<p>前言 本文旨在介绍开源软件许可证，这些许可证规定了使用、修改和分发开源软件的条件。通过了解不同类型的开源许可证及其特点，读者将能够更好地理解在开发和使用开源软件时的法律和道德责任。</p>
|
||||
<span id="continue-reading"></span>
|
||||
<p>对于很多刚踏入软件这个行业的小伙伴来说，「开源软件许可证」是个比较陌生的概念。但是随着经手项目逐渐增多，会发现很多项目，尤其是一些大型项目，经常会引用到别人一些优秀的开源代码，而这些优秀的开源代码通常都会在最开始简单地附上一段关于授权的声明或在项目根目录下提供完整的授权声明文件，比如：「The project is licensed under the Apache 2 license.」，诸如此类便是「开源许可证」。</p>
|
||||
<p>声明开源许可证，可以让广大开发者看到并获取我们作品的同时又保留了我们作为作者的一些权利。在提高自身业界知名度的同时又能防止有人将作者名字改成自己，拿去谋取利益。</p>
|
||||
<p>开源不等于免费，开源也不等于没有约束。</p>
|
||||
<p>开源许可证是开源软件的授权许可，里面详尽表述了个人或组织获得开源代码后拥有的权力，包括可以进行哪些操作以及禁止哪些操作。对于绝大部分人来说，与其自己花大把时间去编写一份开源许可证，倒不如直接选择一个广为流传且合适的已有开源许可证，这样做既省心又省力。而且，靠个人完成一份开源许可证的编写也不是一件容易的事情。</p>
|
||||
<p>在全球范围内，开源软件社区的活跃程度日益增长，吸引了来自不同领域的开发者和用户。然而，开源协议的法律实际应用在各国略有不同。</p>
|
||||
<p>中国开源第一案：<code>https://linux.cn/article-11683-1.html</code></p>
|
||||
<h2 id="kai-yuan-ruan-jian">开源软件</h2>
|
||||
@ -124,50 +128,38 @@
|
||||
<h2 id="chang-jian-kai-yuan-xu-ke-zheng">常见开源许可证</h2>
|
||||
<p>世界上的开源许可证（Open Source License）大概有上百种，而常见的开源协议大致有GPL、BSD、MIT、Mozilla、Apache和LGPL等。
|
||||
<img src="https://www.ruanyifeng.com/blogimg/asset/201105/free_software_licenses.png" alt="alt text" /></p>
|
||||
<pre style="background-color:#151515;color:#e8e8d3;"><code><span> 他人修改源码后，
|
||||
</span><span> 是否可以闭源？
|
||||
</span><span> +--------- No ---------- ---------- Yes ---------+
|
||||
</span><span> │ |
|
||||
</span><span> │ |
|
||||
</span><span> | |
|
||||
</span><span> | |
|
||||
</span><span> 新增代码是否采用 每一个修改过的文件，
|
||||
</span><span> 同样许可证？ 是否都必须放置版权
|
||||
</span><span> +---- No ----- ----- Yes ----+ 说明？
|
||||
</span><span> | | +---- No ----- ----- Yes ----+
|
||||
</span><span> | | | |
|
||||
</span><span> | | | |
|
||||
</span><span> | | | |
|
||||
</span><span> 是否需要对源码的 | | |
|
||||
</span><span> 修改之处，提供说 | 衍生软件的广告， |
|
||||
</span><span> 明文档？ GPL 是否可以用你的 Apache
|
||||
</span><span>+---- No ----- ----- Yes ----+ 名字销售？
|
||||
</span><span>| | +---- No ----- ----- Yes ----+
|
||||
</span><span>| | | |
|
||||
</span><span>| | | |
|
||||
</span><span>| | | |
|
||||
</span></code></pre>
|
||||
<p>LGPL Mozilla BSD MIT</p>
|
||||
<h2 id="apache-license">Apache License</h2>
|
||||
<p>Apache License（Apache许可证），是Apache软件基金会发布的一个自由软件许可证。</p>
|
||||
<p>Apache Licence 是著名的非盈利开源组织 Apache 采用的协议。该协议和BSD类似，同样鼓励代码共享和最终原作者的著作权，同样允许源代码修改和再发布。但是也需要遵循以下条件：</p>
|
||||
<p>需要给代码的用户一份 Apache Licence。</p>
|
||||
<p>如果修改了代码，需要再被修改的文件中说明。</p>
|
||||
<p>在衍生的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。</p>
|
||||
<p>如果再发布的产品中包含一个 Notice 文件，则在Notice文件中需要带有 Apache Licence。你可以在 Notice 中增加自己的许可，但是不可以表现为对 Apache Licence 构成更改。</p>
|
||||
<ul>
|
||||
<li>需要给代码的用户一份 Apache Licence。</li>
|
||||
<li>如果修改了代码，需要再被修改的文件中说明。</li>
|
||||
<li>在衍生的代码中（修改和有源代码衍生的代码中）需要带有原来代码中的协议，商标，专利声明和其他原来作者规定需要包含的说明。</li>
|
||||
<li>如果再发布的产品中包含一个 Notice 文件，则在Notice文件中需要带有 Apache Licence。你可以在 Notice 中增加自己的许可，但是不可以表现为对 Apache Licence 构成更改。</li>
|
||||
</ul>
|
||||
<p>Apache Licence 也是对商业应用友好的许可。使用者也可以再需要的时候修改代码来满足并作为开源或商业产品发布/销售。</p>
|
||||
<p>使用这个协议的好处是:</p>
|
||||
<p>永久权利 一旦被授权，永久拥有。</p>
|
||||
<p>全球范围的权利 在一个国家获得授权，适用于所有国家。假如你在美国，许可是从印度授权的，也没有问题。</p>
|
||||
<p>授权免费 无版税， 前期、后期均无任何费用。</p>
|
||||
<p>授权无排他性 任何人都可以获得授权</p>
|
||||
<p>授权不可撤消 一旦获得授权，没有任何人可以取消。比如，你基于该产品代码开发了衍生产品，你不用担心会在某一天被禁止使用该代码</p>
|
||||
<ul>
|
||||
<li>永久权利 一旦被授权，永久拥有。</li>
|
||||
<li>全球范围的权利 在一个国家获得授权，适用于所有国家。假如你在美国，许可是从印度授权的，也没有问题。</li>
|
||||
<li>授权免费 无版税， 前期、后期均无任何费用。</li>
|
||||
<li>授权无排他性 任何人都可以获得授权</li>
|
||||
<li>授权不可撤消 一旦获得授权，没有任何人可以取消。比如，你基于该产品代码开发了衍生产品，你不用担心会在某一天被禁止使用该代码</li>
|
||||
</ul>
|
||||
<h2 id="bsd">BSD</h2>
|
||||
<p>BSD 是"Berkeley Software Distribution"的缩写，意思是"伯克利软件发行版"。</p>
|
||||
<p>BSD开源协议：是一个给于使用者很大自由的协议。可以自由的使用，修改源代码，也可以将修改后的代码作为开源或者专有软件再发布。 当你发布使用了BSD协议的代码，或则以BSD协议代码为基础做二次开发自己的产品时，需要满足三个条件：</p>
|
||||
<p>1． 如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。</p>
|
||||
<p>2． 如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。</p>
|
||||
<p>3． 不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。</p>
|
||||
<ul>
|
||||
<li>
|
||||
<p>如果再发布的产品中包含源代码，则在源代码中必须带有原来代码中的BSD协议。</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>如果再发布的只是二进制类库/软件，则需要在类库/软件的文档和版权声明中包含原来代码中的BSD协议。</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>不可以用开源代码的作者/机构名字和原来产品的名字做市场推广。</p>
|
||||
</li>
|
||||
</ul>
|
||||
<p>BSD代码鼓励代码共享，但需要尊重代码作者的著作权。BSD由于允许使用者修改和重新发布代码，也允许使用或在BSD代码上开发商业软件发布和销售，因此是对商业集成很友好的协议。而很多的公司企业在选用开源产品的时候都首选BSD协议，因为可以完全控制这些第三方的代码，在必要的时候可以修改或者二次开发。</p>
|
||||
<h2 id="gpl">GPL</h2>
|
||||
<p>GPL （GNU General Public License） ：GNU通用公共许可协议。</p>
|
||||
@ -189,18 +181,28 @@
|
||||
<p>EPL协议下,你可以将源码不做任何修改来商业发布.但如果你要发布修改后的源码,或者当你再发布的是 Object Code 的时候,你必须声明它的 Source Code 是可以获取的,而且要告知获取方法；</p>
|
||||
<p>当你需要将EPL下的源码作为一部分跟其他私有的源码混和着成为一个 Project 发布的时候,你可以将整个 Project/Product 以私人的协议发布,但要声明哪一部分代码是EPL下的,而且声明那部分代码继续遵循EPL；</p>
|
||||
<p>4.独立的模块(Separate Module),不需要开源。</p>
|
||||
<p>Creative Commons 知识共享协议</p>
|
||||
<h2 id="creative-commons-zhi-shi-gong-xiang-xie-yi">Creative Commons 知识共享协议</h2>
|
||||
<p>Creative Commons (CC) 许可协议并不能说是真正的开源协议，它们大多是被使用于设计类的工程上。 CC 协议种类繁多，每一种都授权特定的权利。 一个 CC 许可协议具有四个基本部分，这几个部分可以单独起作用，也可以组合起来。下面是这几部分的简介：</p>
|
||||
<p>1、署名 作品上必须附有作品的归属。如此之后，作品可以被修改，分发，复制和其它用途。</p>
|
||||
<p>2、相同方式共享 作品可以被修改、分发或其它操作，但所有的衍生品都要置于CC许可协议下。</p>
|
||||
<p>3、非商业用途 作品可以被修改、分发等等，但不能用于商业目的。但语言上对什么是"商业"的说明十分含糊不清 (没有提供精确的定义)，所以你可以在你的工程里对其进行说明。例如，有些人简单的解释"非商业"为不能出售这个作品。而另外一些人认为你甚至不能在有广告的网站上使用它们。 还有些人认为"商业"仅仅指你用它获取利益。</p>
|
||||
<p>4、禁止衍生作品</p>
|
||||
<ul>
|
||||
<li>
|
||||
<p>署名 作品上必须附有作品的归属。如此之后，作品可以被修改，分发，复制和其它用途。</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>相同方式共享 作品可以被修改、分发或其它操作，但所有的衍生品都要置于CC许可协议下。</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>非商业用途 作品可以被修改、分发等等，但不能用于商业目的。但语言上对什么是"商业"的说明十分含糊不清 (没有提供精确的定义)，所以你可以在你的工程里对其进行说明。例如，有些人简单的解释"非商业"为不能出售这个作品。而另外一些人认为你甚至不能在有广告的网站上使用它们。 还有些人认为"商业"仅仅指你用它获取利益。</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>禁止衍生作品</p>
|
||||
</li>
|
||||
</ul>
|
||||
<p>CC 许可协议的这些条款可以自由组合使用。大多数的比较严格的CC协议会声明 "署名权，非商业用途，禁止衍生"条款，这意味着你可以自由的分享这个作品，但你不能改变它和对其收费，而且必须声明作品的归属。这个许可协议非常的有用，它可以让你的作品传播出去，但又可以对作品的使用保留部分或完全的控制。最少限制的CC协议类型当属 "署名"协议，这意味着只要人们能维护你的名誉，他们对你的作品怎么使用都行。</p>
|
||||
<p>CC 许可协议更多的是在设计类工程中使用，而不是开发类，但没有人或妨碍你将之使用与后者。只是你必须要清楚各部分条款能覆盖到的和不能覆盖到的权利。</p>
|
||||
<h2 id="hou-ji">后记</h2>
|
||||
<p>在过去几年，我们可以清晰地观察到商业公司对开源的日益重视，传统企业对开源软件和技术态度的开也在不断提升。IBM 以340亿美元收购了开源软件制造商 Red Hat，而Salesforce 也以65亿美元收购了 Mulesoft；微软加入了开放发明网络（OIN）并贡献了6万项专利，随后又以75亿美元收购了 GitHub ；这些都是显著的例子。</p>
|
||||
<p>大型科技公司不仅依赖于开放源码项目，还积极向这些项目贡献代码，或者在开源许可证下提供自家的内部工具，并将这些举措作为企业责任的体现。这表明整个开源生态系统的扩大使得开源许可证的作用变得更加重要。</p>
|
||||
<p>随着技术和社会环境的不断变化，可能会出现新的许可证或者对现有许可证的修订，比如之前提到的 Elastic 放弃了 Apache 许可证因此，作为开发者和用户，我们应该时刻关注这些变化，确保我们的项目和行为符合当前的法律和道德标准。</p>
|
||||
<p>随着技术和社会环境的不断变化，可能会出现新的许可证或者对现有许可证的修订，比如 Elastic 放弃了 Apache 许可证。作为开发者和用户，我们应该时刻关注这些变化，确保我们的项目和行为符合当前的法律和道德标准。</p>
|
||||
<p>最后，我们希望读者能够在使用和贡献开源软件时，牢记开源精神，尊重他人的劳动成果，并积极参与到开源社区的建设中去。只有通过共同的努力和合作，我们才能够推动开源软件的进步，为全球科技发展贡献自己的一份力量。</p>
|
||||
<h2 id="can-kao">参考</h2>
|
||||
<ul>
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user