讨论:Licenses - 版本历史

Allen：/* 链接 */

2022-04-26T07:03:17Z

‎链接

Allen：/* 链接 */

2022-03-29T12:16:30Z

‎链接

2022年3月29日 (二) 12:11 Allen

2022-03-29T12:11:32Z

Allen：/* 链接 */

2022-03-29T12:09:26Z

‎链接

Allen：/* 贡献 */

2020-09-30T12:30:11Z

‎贡献

2011年5月14日 (六) 08:06 Allen

2011-05-14T08:06:23Z

2010年9月11日 (六) 11:30 Allen

2010-09-11T11:30:40Z

显示差异

Allen：/* 11 贡献 */

2010-09-11T11:22:46Z

‎11 贡献

Allen：/* 1.2 关于软件的修改权我认为下面的说法是比较全面的 */

2010-09-11T11:20:55Z

‎1.2 关于软件的修改权我认为下面的说法是比较全面的

Allen：以内容'各种许可协议探讨 ==1 GPL许可证研究和扩展== GPL许可证是自由软件的应用最广泛的软件许可证。但是我最近看过GPL许可证内容后，...'创建新页面

2010-09-11T11:20:15Z

以内容'各种许可协议探讨 ==1 GPL许可证研究和扩展== GPL许可证是自由软件的应用最广泛的软件许可证。但是我最近看过GPL许可证内容后，...'创建新页面

显示差异

@@ 第330行： / 第330行： @@
 *[https://choosealicense.rustwiki.org/ 选择一个开源许可证]
 *[https://ewen0930.github.io/2016/11/open-source-licenses/ 几种开源协议的比较(BSD,Apache,GPL,LGPL,AGPL,MIT)]
 [[category:licenses]]

@@ 第328行： / 第328行： @@
 ==链接==
 *本文章的最初作者是：tomz [http://docs.huihoo.com/open-source/License.txt TXT文件]
 *[https://ewen0930.github.io/2016/11/open-source-licenses/ 几种开源协议的比较(BSD,Apache,GPL,LGPL,AGPL,MIT)]
 [[category:licenses]]

@@ 第1行： / 第1行： @@
 各种许可协议探讨
-[[文件:Popular-open-source-licenses.png|right|thumb|选择许可协议]]
 ==GPL许可证研究和扩展==
@@ 第323行： / 第323行： @@
 ==图集==
 <gallery>
-image:open-source-licenses-select.png|开源许可证选择
+image:Popular-open-source-licenses.png|选择开源许可证
 </gallery>

←上一版本		2022年3月29日 (二) 12:09的版本
第320行：		第320行：

	GPL要求所有和GPL软件链接的代码都要开源，那么GPL软件将不能链接一些商业软件的库，这对GPL软件的开发不利。		GPL要求所有和GPL软件链接的代码都要开源，那么GPL软件将不能链接一些商业软件的库，这对GPL软件的开发不利。
		+
		+	==图集==
		+	<gallery>
		+	image:open-source-licenses-select.png\|开源许可证选择
		+	</gallery>

	==链接==		==链接==

@@ 第321行： / 第321行： @@
 GPL要求所有和GPL软件链接的代码都要开源，那么GPL软件将不能链接一些商业软件的库，这对GPL软件的开发不利。
-==贡献==
+==链接==
 *本文章的最初作者是：tomz [http://docs.huihoo.com/open-source/License.txt TXT文件]
-{{Comment}}
+[[category:licenses]]
-−
-[[Category:Licenses]]

@@ 第15行： / 第15行： @@
 你可以以下面的四种方式修改自由软件作品：
-  第一种方式：如果只是对原始程序进行局部修改，那么应该使修改以补丁文件的形式进行修改，以使修改和原始程序完全脱离。并且，有修改的说明文档，包括每项修改的说明和修改者的联系方法和修改时间。这样，首先当用户使用你的修改版软件出现问题时，可以明确地知道问题应该找原始程序作者还是修改者解决，以免原始程序作者为修改内容负责。另外，当原始程序升级时，也方便使用者同时使用修改内容和升级程序。并且，也方便修改者把修改代码和修改文档反馈给原始程序作者，以便融入原始程序中使修改内容被更多的人使用。建议尽量反馈给原始程序作者，但不是强迫的。
+第一种方式：如果只是对原始程序进行局部修改，那么应该使修改以补丁文件的形式进行修改，以使修改和原始程序完全脱离。并且，有修改的说明文档，包括每项修改的说明和修改者的联系方法和修改时间。这样，首先当用户使用你的修改版软件出现问题时，可以明确地知道问题应该找原始程序作者还是修改者解决，以免原始程序作者为修改内容负责。另外，当原始程序升级时，也方便使用者同时使用修改内容和升级程序。并且，也方便修改者把修改代码和修改文档反馈给原始程序作者，以便融入原始程序中使修改内容被更多的人使用。建议尽量反馈给原始程序作者，但不是强迫的。
-  第二种方式：并不修改原始程序代码，但增加程序文件，使原始程序的功能得到增强和扩展。如增加更多的库函数，增加更多的软件功能模块。如果增加程序要和原始程序同时发行，那么，GPL许可应该应用于软件整体，这就是GPL许可中说明的同时发布的相关程序，只要其中有GPL许可程序，那么GPL许可扩大到全体相关程序。如果以这种形式修改，那么那么第一种方式的修改方法是适用的。
+第二种方式：并不修改原始程序代码，但增加程序文件，使原始程序的功能得到增强和扩展。如增加更多的库函数，增加更多的软件功能模块。如果增加程序要和原始程序同时发行，那么，GPL许可应该应用于软件整体，这就是GPL许可中说明的同时发布的相关程序，只要其中有GPL许可程序，那么GPL许可扩大到全体相关程序。如果以这种形式修改，那么那么第一种方式的修改方法是适用的。
-  第三种方式：在自己创作的软件中引用GPL程序的代码，如果创作的软件也是GPL许可覆盖的软件那么，这种引用是许可的，但要在版权说明中说明参考了那些程序的代码，并尽可能在程序源代码中注释出那些是引用的代码及引用代码的作者和联系方法。这种引用可以不用征得被引用代码作者得同意。
+第三种方式：在自己创作的软件中引用GPL程序的代码，如果创作的软件也是GPL许可覆盖的软件那么，这种引用是许可的，但要在版权说明中说明参考了那些程序的代码，并尽可能在程序源代码中注释出那些是引用的代码及引用代码的作者和联系方法。这种引用可以不用征得被引用代码作者得同意。
-  第四种方式：在原始程序的基础上进行修改并重新发布，那么修改内容可以不必和原始程序脱开，但也要有说明文档说明修改内容，原始程序的作者和联系方法，及修改的日期和作者。并且如果能够对原始程序有贡献，那么尽量通知原始程序作者，以便原始程序的作者也享受修改带来的好处。在这种情况下，修改者应该对用户发现的问题负全部责任，而不要麻烦原始程序作者解决。以这种方式修改的结果就是建立了一个原始程序的分支，以实现更自由的修改，但对于享受原始程序的升级的好处则带来了困难。这是修改者的很大的权利，即建立分支的权利。这样的选择适于不满意原程序发展方向和进度或满足特定需要的情况。由于这种方式引入了竞争，这要求补丁程序能够共享，任何人都有权获得和原始程序作者同样多的补丁程序的反馈的拷贝，这样才能避免补丁程序的浪费。可能被抛弃的补丁正是某些用户需要的。提倡开放的补丁的发布方式，更有利于软件的进步。
+第四种方式：在原始程序的基础上进行修改并重新发布，那么修改内容可以不必和原始程序脱开，但也要有说明文档说明修改内容，原始程序的作者和联系方法，及修改的日期和作者。并且如果能够对原始程序有贡献，那么尽量通知原始程序作者，以便原始程序的作者也享受修改带来的好处。在这种情况下，修改者应该对用户发现的问题负全部责任，而不要麻烦原始程序作者解决。以这种方式修改的结果就是建立了一个原始程序的分支，以实现更自由的修改，但对于享受原始程序的升级的好处则带来了困难。这是修改者的很大的权利，即建立分支的权利。这样的选择适于不满意原程序发展方向和进度或满足特定需要的情况。由于这种方式引入了竞争，这要求补丁程序能够共享，任何人都有权获得和原始程序作者同样多的补丁程序的反馈的拷贝，这样才能避免补丁程序的浪费。可能被抛弃的补丁正是某些用户需要的。提倡开放的补丁的发布方式，更有利于软件的进步。
 ====和GPL许可条款相比====