开放源代码的定义 (转)[@more@]
作者：COSOFT
关于开放 源代码的定义
译者的声明:
本文是 开放源代码定义、开放源代码定义原理以及OSI Certified标志与纲要的中文译文。
本文由王立在1999年8月翻译。
本人在翻译时为确保译文与原文在含义上一致性付出了最大 努力，但是本人不能对：由于译文与原文在含义上的差异而造成的任何误解；或对译文的误解；所造成的任何直接的、间接的损失承担任何责任。
王立 1999年8月
关于开放源代码的定义 （1.7版）
开放源代码并不仅仅意味着对源代码的访问权。开放源代码 软件的发布 条款必须满足以下条件：
1． 自由地再发布
如果被发布的软件是由不同来源的 程序组成的，许可证不得限制任何当 事人或组织（party）销售或赠送作为被发布软件成分之一的开放源码软件。
许可证不得从此项销售中索取使用费或其它任何费用。（理由）
2． 源代码 程序必须包括源代码，必须允许以源代码方式发布、还必须允许以编译 后的形式发布。如果产品的某个部分没有与源代码一同发布，那么必须提供通行的、不需要支付合理范围之外的任何费用的手段以获得源代码---从 网络上免费 下载是一种可取的方式。源代码必须是程序员对其进行修改的最佳形式。故意地使源代码变得含混晦涩是不允许的。也不允许给出预处理 器或翻译器处理的中间结果。（理由）
3． 派生作品
许可证必须允许修改软件和派生软件，并且必须允许它们按照原软件的 许可证的条款进行发布。（理由）
4． 作者的源代码的完整性 只有在许可证允许与源代码一同发布" 补丁 文件"（该"补丁文件"以在创建时对程序进行修改为目的）时，许可证才能限制对修改形式的源代码的 发布。许可证必须明确地允许发布由修改后的源代码生成的程序。许可证可以要求派生的作品采用不同的名称或不同的版本号以区别于原来的软件。 （理由）
5． 不得歧视任何个人或团体
许可证不得歧视任何个人或者由多人组成的团体。（理由）
6． 不得歧视任何应用领域（fields of endeavor） 许可证不得限制任何人把程序应用于任何领域。例如，不得规定程序不能应用于商业领域或基因研究领域。（理由）
7． 许可证的发布 与程序有关的权利必须适用于该程序的任何使用者，并且程序的使用者 也不需要为了使用该程序而获得其它许可证的许可。（理由）
8． 许可证不能针对于一个产品 与程序有关的权利不能由该程序是否作为某个软件产品的一部分来决定。
如果程序从那个发布中被抽出来，并且按照程序的许可证的条款进行使用 和发布，那么得到该程序的当事人或组织将获得与得到原程序的使用者相同的权利。（理由）
9． 许可证不能影响其它软件 许可证不得向与采用它的软件一同发布的其它软件提出任何限制。例如，
许可证不能坚持要求在同一 媒体上发布的其它程序都是开放源代码软件。 （理由）
Conformance （本节不是开放源代码定义的一个部分）
我们认为本开放源代码定义涵盖了由绝大多数软件团体使用的术语"开放 源代码"的最初含义和当前含义。然而，该术语被广泛地应用，并且它的含义变得不精确了。OSI Certified标志是某个软件发布许可证是否服从开放 源代码定义的OST 认证方式。一般的术语"开放源代码"并不提供这种担保，但我们仍然鼓励使用"开放源代码"这一术语以表明它符合"开放源代码定义"。 关于OSI Certified标志的信息，以及已经通过了OSICertified、符合"开放 源代码定义"的许可证，请参见OSI Certified标志与纲要。
开放源代码定义之原理
给出开放源代码的定义的目的是：把我们所确信的、由 软件开发团体所公 认的"开放源代码"的含义作为一组具体的准则写下来---该准则确保按照开放源代码许可证发布的软件可以得到与其它软件同样认真的评审、使软件可 以不断地得到改良和遴选，从而提供非开放软件所难以提供的可靠性与能力。
为了使此项工作持续发展，我们必须抵制人们为了短期利益而中止为软件开发做出贡献。这意味着，许可证的条款必须防止人们藏匿（lockup）源代 码从而导致只有很少的人才能够阅读和修改它。 当软件的开发者按照由OSI认证的许可证发布他们的软件时，他们可以在软件中使用"OSI Certified"标志。这种认证标志告知 用户，该软件所采用的许可 证符合开放源代码定义。关于我们的认证标志的更多信息及其纲要，请参见OSI Certified标志与纲要。
1． 自由地再发布
通过强制要求许可证允许自由地再发布，我们抵制了任何为了获得少量短期 销售金额而放弃长期效益的诱惑。如果我们不这样做，就会有很多压力迫使合作者放弃承诺。
2． 源代码 由于软件只有通过修改才能够得到改进，因此我们要求获得易于理解的源代 码。因为我们的目的是使软件易于改进，我们也就希望软件易于修改。
3． 派生作品 仅仅提供可以阅读的源代码，对于实施认真的评审、对于软件的 快速改良与 遴选来说都是不够的。为了加快改进软件的速度，人们需要能够进行试验和对修改进行重新发布。
4． 作者的源代码的完整性 鼓励对软件进行各种改进是一件好事，但使用者有权知道谁应该对他们所使用的软件负责。软件的作者和维护者都有权知道需要他们提供支持的软件是什 么，以维护他们的名誉。 因此，开放软件许可证必须保证可以容易地得到源代码，但可以要求源代码以原始源代码和一组补丁文件的形式发布。按照这种方式，就可以获得"非正 式的"的修改而同时又可以轻易地把它们从原始源代码中区分出来。
5． 不得歧视任何个人或团体 为了从该进程中获得最大的收益，应该给尽可能多的个人和团体以同等资格对开放源代码软件做出贡献。为此我们禁止开放源代码许可证把任何人排除在 这个进程之外。
6． 不得歧视任何应用领域（fields of endeavor） 该条款的主要目的是禁止许可证中含有使开放源代码软件无法在商业上使用的规定。我们需要商业用户参与我们的工作，而不让他们感到被排除在外。
7． 许可证的发布 本条款的目的是禁止通过非直接的手段，例如需要签署非公开的协定，使软 件无法公开。
8． 许可证不能针对于一个产品 本条款用于预防其它许可证陷阱。
9． 许可证不能影响其它软件 开放源代码软件的发布者有权为他们自己的软件做出选择。 是的，GPL满足这条要求。按GPL发布的库只影响（contaminate）在运行时与之连接的软件，于仅仅和它一同发布的软件无关。
OSI Certified标志与纲要
开放源代码定义给出了开放源代码软件的基本性质。不幸的是，术语"开放源 代码"遭到了滥用，并且由于它的描述性，它不能作为一个商标（这是我们的首选）被保护。由于社团需要一种可靠的方式以确定一份软件是否真正是开放源 代码软件。OSI为此目的而注册了一个认证标志，OSICertified。如果你在一份 软件上看到了该标志，那么该软件就是必定是按照遵从开放源代码定义的许可证 发布的，否则，该发行人就是在滥用该标志而且违反了法律。
OSI Certified标志被用于软件而不是许可证：人们需要知道的是组成软件的 包和它们的许可证是开放的源代码。此外，单独的许可证可能不是"货物"，它由美国专利和商标局注册认证标志。但是软件的作者显然必须能够在不询问我们的 情况下（自我认证）、在适当的时刻确认他们的软件是按照OSICertified的开放 源代码方式发布的。所以认证按照两步进行：
* OSI提供一个满足开放软件源代码定义的开放源代码许可证表。这些许可证经过 公众的详细审查并且被我们所批准。如果你有一个希望加入该列表的许可证，请与license-approval@open source.org联系，它启动了获得许可证批准的程序。 * 如果你希望在你的软件上设置OSICertified标志，你可以从列表中选择一个获 得批准的许可证并根据它发布软件，并且适当地为软件做标志。 上面仅仅是一个概括。下面给出申请批准许可证和把OSICertified标志应用在你 的软件上的详细说明。
获得许可证的批准
1． 通过电子 邮件把许可证发送给license-approval@opensource.org。在电子邮件中说明你是否愿意以你的签名或者匿名地把许可证发送到许可证讨论列表中。（我们 愿意考虑那些根本不希望被发送的许可证，但由于社团的评审是批准的一个重要组成部分，我们将不得不把该许可证私下地发送给评审者：因此，对没有被发送到许可证 讨论列表中的许可证的批准，要花费更长的时间，并且通常要更多地与你交流。）
2． 如果我们发现你的许可证不符合开放源代码的定义，我们将与你一同解决这个问题。
3． 同时，我们将关注许可证论坛列表，并且与你一同工作以解决大家提出的任何未 包含的问题。
4． 作为该过程的一部分，我们还将就许可证问题向外界寻求法律上的建议。
5． 一旦许可证符合了开放源代码定义，并且在许可证论坛上经过了充分的讨论或者 其它的评审者没有提出我们认为重要的问题，我们将通知你，许可证已经被批准了，同时它被复制到我们的网站上，并且被加入以下的许可证列表。
使用该标志
你可以在这两种软件的发行上使用OSI Certified标志。该软件的发布包括并且达到 了被批准的许可证列表中某个许可证的要求，或者该软件的源代码已经被明确地放到公众可以得到的位置。
为了表明你的软件是按照OSI Certified发布的，你必须不加任何修改地把下面两者之一，按照下述方式加入你的软件。完整的声明是：
This software is OSI Certified open source Software.
OSI Certified is a certification mark of the Open Source Initiative.
较简短的声明是： OSI Certified Open Source Software
你的软件的每种发布形式都有自身的要求：
* 如果软件以电子的形式发布（而不是实物（tangible）的形式），你必须把完整 的声明放在README文件或者类似的、人类用户将首先阅读的文件中。
* 如果软件以实物形式发布，你必须完成以下所有可行的任务：
. 如果软件的发布包括印刷品，你必须把完整的声明加入该印刷品。
. 如果软件发布在可擦写的媒体（例如软 磁盘）、CD-ROM、磁带等媒体上，它们在物理上可以添加能够被人的裸眼所阅读的简短声明，而不影响它们的功能，你必须把完整的声明或简短的声明标注在该媒体上。
. 如果软件的发布是一个的包，从而使其中的声明不能被阅读。你必须在包的外 面放置完整的声明。
如果不能把以上任何条款用于发布，请与我们联系，我们将把你选择的位置加入本列表。
获得批准的许可证
以下许可证满足开放源代码的定义，并且已经被批准用于OSI Certified的开放源 代码软件。没有给出批准日期的许可证是在1999年1月1日以前批准的。
* The gnu General Public License（GPL）；
* The GNU Library（Lesser） General Public License（LGPL）；
* The bsd License；
* The X Consortium License；
* The Artistic License；
* The Mozilla Public License（MPL）；
* The QPL；
其它符合定义的许可证包括：libpng许可证、 zlib许可证、IJG JPEG许可证和OPL （Open LDAP Public License）许可证
<%}%>
关于开放 源代码的定义
译者的声明:
本文是 开放源代码定义、开放源代码定义原理以及OSI Certified标志与纲要的中文译文。
本文由王立在1999年8月翻译。
本人在翻译时为确保译文与原文在含义上一致性付出了最大 努力，但是本人不能对：由于译文与原文在含义上的差异而造成的任何误解；或对译文的误解；所造成的任何直接的、间接的损失承担任何责任。
王立 1999年8月
关于开放源代码的定义 （1.7版）
开放源代码并不仅仅意味着对源代码的访问权。开放源代码 软件的发布 条款必须满足以下条件：
1． 自由地再发布
如果被发布的软件是由不同来源的 程序组成的，许可证不得限制任何当 事人或组织（party）销售或赠送作为被发布软件成分之一的开放源码软件。
许可证不得从此项销售中索取使用费或其它任何费用。（理由）
2． 源代码 程序必须包括源代码，必须允许以源代码方式发布、还必须允许以编译 后的形式发布。如果产品的某个部分没有与源代码一同发布，那么必须提供通行的、不需要支付合理范围之外的任何费用的手段以获得源代码---从 网络上免费 下载是一种可取的方式。源代码必须是程序员对其进行修改的最佳形式。故意地使源代码变得含混晦涩是不允许的。也不允许给出预处理 器或翻译器处理的中间结果。（理由）
3． 派生作品
许可证必须允许修改软件和派生软件，并且必须允许它们按照原软件的 许可证的条款进行发布。（理由）
4． 作者的源代码的完整性 只有在许可证允许与源代码一同发布" 补丁 文件"（该"补丁文件"以在创建时对程序进行修改为目的）时，许可证才能限制对修改形式的源代码的 发布。许可证必须明确地允许发布由修改后的源代码生成的程序。许可证可以要求派生的作品采用不同的名称或不同的版本号以区别于原来的软件。 （理由）
5． 不得歧视任何个人或团体
许可证不得歧视任何个人或者由多人组成的团体。（理由）
6． 不得歧视任何应用领域（fields of endeavor） 许可证不得限制任何人把程序应用于任何领域。例如，不得规定程序不能应用于商业领域或基因研究领域。（理由）
7． 许可证的发布 与程序有关的权利必须适用于该程序的任何使用者，并且程序的使用者 也不需要为了使用该程序而获得其它许可证的许可。（理由）
8． 许可证不能针对于一个产品 与程序有关的权利不能由该程序是否作为某个软件产品的一部分来决定。
如果程序从那个发布中被抽出来，并且按照程序的许可证的条款进行使用 和发布，那么得到该程序的当事人或组织将获得与得到原程序的使用者相同的权利。（理由）
9． 许可证不能影响其它软件 许可证不得向与采用它的软件一同发布的其它软件提出任何限制。例如，
许可证不能坚持要求在同一 媒体上发布的其它程序都是开放源代码软件。 （理由）
Conformance （本节不是开放源代码定义的一个部分）
我们认为本开放源代码定义涵盖了由绝大多数软件团体使用的术语"开放 源代码"的最初含义和当前含义。然而，该术语被广泛地应用，并且它的含义变得不精确了。OSI Certified标志是某个软件发布许可证是否服从开放 源代码定义的OST 认证方式。一般的术语"开放源代码"并不提供这种担保，但我们仍然鼓励使用"开放源代码"这一术语以表明它符合"开放源代码定义"。 关于OSI Certified标志的信息，以及已经通过了OSICertified、符合"开放 源代码定义"的许可证，请参见OSI Certified标志与纲要。
开放源代码定义之原理
给出开放源代码的定义的目的是：把我们所确信的、由 软件开发团体所公 认的"开放源代码"的含义作为一组具体的准则写下来---该准则确保按照开放源代码许可证发布的软件可以得到与其它软件同样认真的评审、使软件可 以不断地得到改良和遴选，从而提供非开放软件所难以提供的可靠性与能力。
为了使此项工作持续发展，我们必须抵制人们为了短期利益而中止为软件开发做出贡献。这意味着，许可证的条款必须防止人们藏匿（lockup）源代 码从而导致只有很少的人才能够阅读和修改它。 当软件的开发者按照由OSI认证的许可证发布他们的软件时，他们可以在软件中使用"OSI Certified"标志。这种认证标志告知 用户，该软件所采用的许可 证符合开放源代码定义。关于我们的认证标志的更多信息及其纲要，请参见OSI Certified标志与纲要。
1． 自由地再发布
通过强制要求许可证允许自由地再发布，我们抵制了任何为了获得少量短期 销售金额而放弃长期效益的诱惑。如果我们不这样做，就会有很多压力迫使合作者放弃承诺。
2． 源代码 由于软件只有通过修改才能够得到改进，因此我们要求获得易于理解的源代 码。因为我们的目的是使软件易于改进，我们也就希望软件易于修改。
3． 派生作品 仅仅提供可以阅读的源代码，对于实施认真的评审、对于软件的 快速改良与 遴选来说都是不够的。为了加快改进软件的速度，人们需要能够进行试验和对修改进行重新发布。
4． 作者的源代码的完整性 鼓励对软件进行各种改进是一件好事，但使用者有权知道谁应该对他们所使用的软件负责。软件的作者和维护者都有权知道需要他们提供支持的软件是什 么，以维护他们的名誉。 因此，开放软件许可证必须保证可以容易地得到源代码，但可以要求源代码以原始源代码和一组补丁文件的形式发布。按照这种方式，就可以获得"非正 式的"的修改而同时又可以轻易地把它们从原始源代码中区分出来。
5． 不得歧视任何个人或团体 为了从该进程中获得最大的收益，应该给尽可能多的个人和团体以同等资格对开放源代码软件做出贡献。为此我们禁止开放源代码许可证把任何人排除在 这个进程之外。
6． 不得歧视任何应用领域（fields of endeavor） 该条款的主要目的是禁止许可证中含有使开放源代码软件无法在商业上使用的规定。我们需要商业用户参与我们的工作，而不让他们感到被排除在外。
7． 许可证的发布 本条款的目的是禁止通过非直接的手段，例如需要签署非公开的协定，使软 件无法公开。
8． 许可证不能针对于一个产品 本条款用于预防其它许可证陷阱。
9． 许可证不能影响其它软件 开放源代码软件的发布者有权为他们自己的软件做出选择。 是的，GPL满足这条要求。按GPL发布的库只影响（contaminate）在运行时与之连接的软件，于仅仅和它一同发布的软件无关。
OSI Certified标志与纲要
开放源代码定义给出了开放源代码软件的基本性质。不幸的是，术语"开放源 代码"遭到了滥用，并且由于它的描述性，它不能作为一个商标（这是我们的首选）被保护。由于社团需要一种可靠的方式以确定一份软件是否真正是开放源 代码软件。OSI为此目的而注册了一个认证标志，OSICertified。如果你在一份 软件上看到了该标志，那么该软件就是必定是按照遵从开放源代码定义的许可证 发布的，否则，该发行人就是在滥用该标志而且违反了法律。
OSI Certified标志被用于软件而不是许可证：人们需要知道的是组成软件的 包和它们的许可证是开放的源代码。此外，单独的许可证可能不是"货物"，它由美国专利和商标局注册认证标志。但是软件的作者显然必须能够在不询问我们的 情况下（自我认证）、在适当的时刻确认他们的软件是按照OSICertified的开放 源代码方式发布的。所以认证按照两步进行：
* OSI提供一个满足开放软件源代码定义的开放源代码许可证表。这些许可证经过 公众的详细审查并且被我们所批准。如果你有一个希望加入该列表的许可证，请与license-approval@open source.org联系，它启动了获得许可证批准的程序。 * 如果你希望在你的软件上设置OSICertified标志，你可以从列表中选择一个获 得批准的许可证并根据它发布软件，并且适当地为软件做标志。 上面仅仅是一个概括。下面给出申请批准许可证和把OSICertified标志应用在你 的软件上的详细说明。
获得许可证的批准
1． 通过电子 邮件把许可证发送给license-approval@opensource.org。在电子邮件中说明你是否愿意以你的签名或者匿名地把许可证发送到许可证讨论列表中。（我们 愿意考虑那些根本不希望被发送的许可证，但由于社团的评审是批准的一个重要组成部分，我们将不得不把该许可证私下地发送给评审者：因此，对没有被发送到许可证 讨论列表中的许可证的批准，要花费更长的时间，并且通常要更多地与你交流。）
2． 如果我们发现你的许可证不符合开放源代码的定义，我们将与你一同解决这个问题。
3． 同时，我们将关注许可证论坛列表，并且与你一同工作以解决大家提出的任何未 包含的问题。
4． 作为该过程的一部分，我们还将就许可证问题向外界寻求法律上的建议。
5． 一旦许可证符合了开放源代码定义，并且在许可证论坛上经过了充分的讨论或者 其它的评审者没有提出我们认为重要的问题，我们将通知你，许可证已经被批准了，同时它被复制到我们的网站上，并且被加入以下的许可证列表。
使用该标志
你可以在这两种软件的发行上使用OSI Certified标志。该软件的发布包括并且达到 了被批准的许可证列表中某个许可证的要求，或者该软件的源代码已经被明确地放到公众可以得到的位置。
为了表明你的软件是按照OSI Certified发布的，你必须不加任何修改地把下面两者之一，按照下述方式加入你的软件。完整的声明是：
This software is OSI Certified open source Software.
OSI Certified is a certification mark of the Open Source Initiative.
较简短的声明是： OSI Certified Open Source Software
你的软件的每种发布形式都有自身的要求：
* 如果软件以电子的形式发布（而不是实物（tangible）的形式），你必须把完整 的声明放在README文件或者类似的、人类用户将首先阅读的文件中。
* 如果软件以实物形式发布，你必须完成以下所有可行的任务：
. 如果软件的发布包括印刷品，你必须把完整的声明加入该印刷品。
. 如果软件发布在可擦写的媒体（例如软 磁盘）、CD-ROM、磁带等媒体上，它们在物理上可以添加能够被人的裸眼所阅读的简短声明，而不影响它们的功能，你必须把完整的声明或简短的声明标注在该媒体上。
. 如果软件的发布是一个的包，从而使其中的声明不能被阅读。你必须在包的外 面放置完整的声明。
如果不能把以上任何条款用于发布，请与我们联系，我们将把你选择的位置加入本列表。
获得批准的许可证
以下许可证满足开放源代码的定义，并且已经被批准用于OSI Certified的开放源 代码软件。没有给出批准日期的许可证是在1999年1月1日以前批准的。
* The gnu General Public License（GPL）；
* The GNU Library（Lesser） General Public License（LGPL）；
* The bsd License；
* The X Consortium License；
* The Artistic License；
* The Mozilla Public License（MPL）；
* The QPL；
其它符合定义的许可证包括：libpng许可证、 zlib许可证、IJG JPEG许可证和OPL （Open LDAP Public License）许可证
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/10752043/viewspace-987517/，如需转载，请注明出处，否则将追究法律责任。
请登录后发表评论
登录
全部评论
<%=items[i].createtime%>
<%=items[i].content%>
<%if(items[i].items.items.length) { %>
<%for(var j=0;j
<%}%> <%if(items[i].items.total > 5) { %>
<%}%>
<%=items[i].items.items[j].createtime%>
回复
<%=items[i].items.items[j].username%> 回复 <%=items[i].items.items[j].tousername%>： <%=items[i].items.items[j].content%>
还有<%=items[i].items.total-5%>条评论
) data-count=1 data-flag=true>点击查看
<%}%>
-
博文量6241
-
访问量2395969
最新文章
- 可怕的 C# (转)
- Unify the Role-Based Security Models for Enterprise and Application Domains with .NET (转)
- Building Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication (转)
- [Sample] Playing with music file (转)
- 中文web-app_2_3.dtd (转)
- 使用ASP.NET加密口令 (转)
- C++ Builder 高手进阶 （五）用BCB编写多线程应用程序 (转)
- 24点游戏探秘系列6：用概率统计的眼光看24点游戏 (转)
- Schema-oriented message destination (转)
- J2EE vs. Microsoft.NET (转)
转载于:http://blog.itpub.net/10752043/viewspace-987517/
1180
到【灌水乐园】发言
