blob: 4e110585008e3910fa3739f8fc5beb593321e415 (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
注意: 本译文仅供参考。若因译文错漏引发任何问题，译者概不承担责任。MNV 许可证的
完整英文版本为唯一法律依据。如有任何疑问，以英文原文为准。
MNV 许可证
I) 可以任意发布没有修改的 MNV 的拷贝，但是必须保证包含本许可证。您也可以发布
未经修改的部分 MNV，同样也必须包含这份许可证。发布由未经修改的 MNV 源代码
所编译出的 MNV 可执行文件，外加您自己的应用实例和 MNV 脚本也是允许的。
II) 在满足以下全部四个条件的前提下，您可以发布经过修改 (或扩充) 的 MNV 版本，
包括可执行文件 和/或 源代码:
1) 本许可证必须包含在内，并且不能被修改。
2) 经过修改的 MNV 必须以下述五种方式之一发布:
a) 如果您本人对 MNV 做了改动，您必须在发布版本里清楚地说明如何与您联系。
当 MNV 的维护者 (以任何方式) 向您索取您所发布的 MNV 时，您必须把所做
的改动包括源代码无偿地提供出来。维护者保留把这些改动加入 MNV 正式版本
的权利。至于维护者怎样处理这些改动，以及用什么许可证发布，可以协商。
如果没有协商，那么，本许可证，或者它更新的版本，同样适用于您做出的改
动。MNV 现在的几位维护者可见:
https://github.com/orgs/mnv/people
如果维护者发生变动，会在合适的地方 (很可能是 mnv.sf.net、www.mnv.org
和/或 comp.editors) 公布，当完全不能与维护者联系时，发送变更的约定自
动终止。一旦维护者确认收到了您所做的修改，您就不必再次发送了。
b) 如果您得到的是一个修改过的 MNV，并且它是在条件 a) 下发布的，那么您可
以不加改动地在条件 I) 下发布它；如果您又做了额外的改动，则这些改动受
到 a) 款条文的约束。
c) 在您发布的经过修改的 MNV 的每一份拷贝里，提供所有的变更部分，包括源代
码。提供的形式可以采用上下文风格的差异比较记录 (context diff)。您可以
为添加的新代码选择许可证，但是这些更改和为其选择的许可证不能限制他人
对 MNV 正式版本作出自己的改动。
d) 在满足以下全部三个条件的前提下，您可以继续发布带有条件 c) 所提及之变
更的经过修改的 MNV，而不必在发布时提供更改部分的源代码:
- 这些变更所附带的许可证允许您把这些变更无偿地并且没有任何限制地提供
给 MNV 的维护者，而且允许 MNV 的维护者无偿地并且没有任何限制地把这
些更改加入到 MNV 的正式版本中。
- 从您最后一次发布更改的 MNV 之日起，您要保存这些改动至少三年时间。在
这期间，维护者或别人 (以任何方式) 向您要求提供这些变更时，您必须提
供给他。
- 您要在发布版本中清楚地说明如何与您联系，这个联系方式必须保证自最后
一次发布相应的经过修改的 MNV 之日起至少三年有效，或尽可能长。
e) 当这些变更以 GPL (GNU General Public License，GNU 通用公共许可证) 发
布时，您可以在 GPL 版本 2，或更高版本的 GPL 下发布修改过的 MNV。
3) 必须添加一条改动的信息。至少要放在 "version" 命令的输出和启动画面里，好
让用户知道自己用的是一个修改过的 MNV。当以 2)e) 条件发布时，只有不与变
更适用的许可证冲突，这个信息的添加才是必要的。
4) 在 2)a) 和 2)d) 条件里要求的联系方式不能随便更改或删除，除非是作者自己
作出的更正。
III) 如果您发布一个更改过的 MNV，强烈建议您对变更部分使用 MNV 的许可证，并且对
维护者提供变更部分并开放源代码。最好的方式是通过电子邮件或者把文件放到服
务器上，通过电子邮件传送 URL。如果只修改了很少的部分 (例如，只是一个修改
过的 Makefile)，那么传送一个上下文风格的差异比较记录 (context diff) 就可
以了。电子邮件的地址是 <maintainer@mnv.org>
IV) 不允许从 MNV 的源代码的发行版本或其中部分的源代码里删除本许可证，即使来自
更改过的版本也是如此。您可能想用这份许可证代替以前版本的 MNV 里的许可证，
这可以由您自行决定。
|
