24、开放源码涉及哪些潜在的法律问题或风险？
如前所述，开放源码软件也和专有软件一样，是受版权保护和许可证限制
的。软件业用版权法来保护软件拥有者和开发者的权利，用许可证来约束这些权
利的行使和转移。根据中国最新公布的《计算机软件保护条例》规定，当软件被
首次创建且固定在某种有形物体上，不论是否发表，依照本条例享有著作权。条
例保障和保护软件供应商有关复制、分销、准备派生作品的权利。这些权利是分
离的，可以通过许可证转让给其他方。专有软件供应商通过禁止产品修改、限定
客户可复制的数量和限制其发行，以获得最大投资回报这样的商业利益。开源软
件供应商不仅允许企业运行和复制软件，也允许其在一定条件下修改软件和发布
修改后的版本，具体条件将随着许可证的不同而变化。许可证将用户社区划分成
那些鼓励在企业中进行开放源码开发的群体和反对这样做的群体。
（1）许可还是盗窃？
开放源码软件给予企业用户的自由程度与软件提供者发行该软件的目标相
关。那些希望软件被广泛发布的提供者会放宽许可证限制，允许用户复制、修
改、甚至可以在很小限制的情况下发布修改版本。例如，当AT&T停止向学术机构
免费提供Unix源码时，加州大学伯克利分校开发了BSD（伯克利软件发行版）。
他们的目的是创建一个Unix的克隆版本并尽可能广泛地发行它。其结果是，BSD
通过一个许可证发布其源代码，该许可证允许用户修改源码、附带或不附带源码
的发行修改版本。BSD许可证实现了广泛发行的目标，开源社区修改了BSD代码，
反馈给社区的是FreeBSD、OpenBSD和NetBSD。还有出于商业目的而开发的BSD
OS，BSD已经为企业带来了效益，SUN最初将BSD和硬件一起免费发布，后来将它
开发成一个专有操作系统。BSD代码也存在于微软Windows NT和Apple MacOS X
中。
现行的BSD许可证仅简单地要求在源码或二进制码或二者共同发布时，应保
持原版权声明和一个拒绝明示/暗示担保的声明，同时还要求，在未经许可的情
况下，"不得利用作者来签署或促销该软件的派生产品。"X Window系统适用的
X11许可证更简单。与BSD一样，X11要求发布时保留原版权声明。X11的版权持
有者包括：康柏、惠普、IBM、Hummingbird Communications、Silicon
Graphics、Sun和开放集团。包括企业开发者在内的所有人都从更为宽松的开源
许可证中受益。
当开源许可证强制开发者将源码贡献给开源社区时，例如一个始于GPL源码
的系统，就不再是上述情况了。与BSD、X11许可证一样，受GPL保护的软件可以
被任何人不作任何修改的运行、复制、发布。但是，假如企业开发者对软件作了
修改，则修改后的版本必须与其源码一起发布。因此，将开源代码与专有代码一
起编译将强制开发者将全部成果贡献给开源社区。编译受GPL保护的源代码并将
其作为专有代码的行为等同于盗窃。而且，GPL坚持封闭式的开源社团，对企业
开发者存有敌意。其结果是，一些开源人士对开源许可证进行了灵活处理，以促
进开源软件进入企业。美国的OSI以推动开放源码软件在企业中的运用为宗旨，
对符合开放源码定义（8.1版）的许可证予以认证，并留存通过认证的许可证的
副本以供重用。尽管OSI是促进那些可同时访问源码和编译代码的软件的自由再
发布，但它并不歧视专有软件企业。经OSI认证的许可证包括：BSD、GPL、X11、
IPL(IBM公共许可证)、MPL(Mozilla公共许可证)，SPL(Sun公共许可证)、
APSL(Apple公共源码许可证)等等。
被IPL、MPL保护的开放源代码通过将被保护的开放源代码从修改版本中分离
出来，从而形成企业开发模式（IPL、MPL下受保护的源代码可以与修改后的版本
分离，从而允许了企业参与开发）。企业开发者可以修改专有软件中的被保护代
码，而不必再将其发布。开发者往往愿意将修改后的版本转为己有，而不愿将其
公布于众。SUN公司的SCSL许可也对受保护的代码和修改的代码作了划分，但是
它要求那些依赖Sun的技术来维护与受保护代码兼容性的开发者付给Sun版权税。
（2）许可证问题
以前开发人员必须考虑的只是软件的依赖性和不兼容性，现在他们还得考虑
开源软件项目之间许可证的冲突。如：Mozilla包含四个不同的许可证。参与该
项目的开发需要注意许可证间的冲突。事实上，在开源项目间互借代码很快就会
进入法律上的迷宫。Galeon是一个基于Mozilla的浏览器，利用GPL下发布的
GTK+图形工具包开发。对其的分发将在分别受MPL和GPL保护的模块间产生冲突。
同样，Transarc（IBM子公司）以IPL许可开发了一个Linux分布式网络文件系统
的变体。不幸的是IPL与GPL不兼容，因而禁止其在Linux内核上运行。有人建
议，OSI应该关注一下许可证间的冲突问题，而不是简单的盖印发证的过程。当
开发者获得源代码并且去自由地修改它时，理论上的修改次数与开发者人数是一
致的。因此，对源代码的每个错误修正和改动，都具有"分叉"出一个新版本的潜
在可能。开源项目要求编程人员自愿结合，假如某一项目没有按编程人员的预期
发展，这些编程人员可以撤出，去开发他们自己的项目。在任何市场?quot;分
叉"未必是一件坏事，它增加了选项、促进了个性选择。然而在某种意义上，选
择的增多，稀释了市场以及为突变版本提供支持的资源。BSD就是一个典型的例
子。
BSD是一个强大的、成熟的企业级操作系统，然而分叉使其归入细分市
场。Wind River系统公司的BSD OS定位于服务器市场，并想在嵌入式系统市场
大显身手。而免费的NetBSD瞄准了便携式市场。BSD变体减少了可用的在线支
持，敞开了通过不同BSD版本进行分叉的各种可能性，同时没有为企业提供采用
新技术的机制，除非企业有自己的Unix开发人员。分叉不只是类似BSD这样宽松
的许可证的产物，在GPL这样限制严格的许可证下也可发生。如果开发人员对于
Linux内核发展方向不满，可以设计补丁与内核一起编译，然后按照GPL发布该
派生版本。或者开发者可以借助LGPL来创建独立的模块并保持其专有性。
LGPL的目标是允许专有代码调用GPL代码，专有代码不能与GPL代码一起编译
或静态相连，但可以动态连接并通过API（应用编程接口）调用GPL代码。然而，
静态与动态连接之间的区别是模糊的，新技术更引入了模糊性。例如，CORBA就
允许将各种软件未加编译的组合在一起。开放源码许可证必须考虑在将专有软件
与开放源码结合进行开发和运行时遇到的模糊性问题。否则，企业开发者不敢冒
然将二者结合运用，那样的话，开源社区就难以实现开放源码进入主流开发的目
标。
随着更多的开放软件被不断增长的社区用户所使用和修改，某些软件专利受
到侵犯的风险也随之增大。许多开源支持者赞成所谓"毒药避止"（poison
pill）规则，即如果你造成了侵犯他人专利的事实，那么你随之失去你的开源许
可权利。尽管这一规则抵制了开源社区内的侵权行为，但在开源社区之外仍面临
挑战。在这个世界中，企业开发者经常在谈判桌上交易专利权，而开源社区的活
动则处于黑暗中。尽管为开源软件申请专利以支持社区使用会增加成本，但是它
减少了软件被社区外申请为专利的机会。所有的开源许可证关注软件的发行和发
表，而不是软件的执行。在代码和数据很难区别的场合下很难定义什么是执行，
比如对一个Apache配置文件或者PERL脚本的修改构成了一个执行吗？尽管对软件
的执行是否应加以考虑在社区内尚存在分歧，技术的发展对其有所促进。例如，
客户/服务器技术使你在不必扰乱代码的情况下对代码加以利用，软件可以利用
CGI（公共网关接口）从Web服务器上加以调用，尽管接口不是分布式的，但使用
它不需受任何法律约束。
详细描述执行权是困难的，可能会得不偿失。对于软件而言，执行意味
着"非发行的使用"。其结果是，执行许可证成为最终用户与软件发布者之间的协
议，通常被实践为要求最终用户点击"点击确认"按钮。至于这些机制是否能提供
构成合同的充分要约和承诺还有待观察。同样，开源许可证能否在法庭上被通过
也不清楚。
（3）合法性问题
经过当事人协商签订的单个许可证通常包含合同必需的要约和承诺，而开放
源码许可证的规定则显得不够完善。例如GPL在软件的每次转让中，都授权每个
开发者或使用者可从版权持有者处得到一个直接的许可。随着软件的不断转让，
要约和承诺被稀释，法庭可能发现执行已不能强制实施。开放源码许可证受益于
强大的热衷于编写好代码，而不是搞诉讼的开发者团体。冒犯开放源码社区者必
受社区的谴责而退缩回去，但这也阻碍了法庭对开源许可证的解释。这种状况可
能会随着越来越多企业参与开源运动而逐渐得到改变。开放源码许可证引发了许
多重要的法律问题。有些问题是copyleft与copyright间的相互关系，及条款的
合理使用。有些问题涉及到社区开发项目中源代码的个人拥有权。有些问题是关
于开放源码许可证和其有关条款的法律效力和强制性的，以及对潜在的侵权问题
的法律解决。还有些是有关软件专利权的许可证及其不足条款的解释问题。最后
还应该讨论的一个问题是一个开源项目由谁来负责，当这一开源项目的主要参与
者离开时会有什么情况发生。值得注意的是直接解释开源许可证或某些特定许可
证下的特定条款的法律裁定案例还没有。自由软件基金建立之后就没有经历过
GPL的法律诉讼。而由BSD Unix许可证引发的纠纷已在庭外解决。简而言之，与
开放源码许可证有关的法律问题的解决还没有定论。以下是一些有关开放源码在
法律方面的重要议题：
A、拥有权--在限定的范围内，使用GPL的作者已将他们的版权拥有权交给了
自由软件基金会FSF，这样，FSF就集中拥有了一个项目的所有版权。尽管也有一
些项目试图将版权拥有权集中到项目管理者身上，但是，绝大多数开源项目还涉
及到众多版权拥有者。在这种情况下，就不单涉及项目拥有权问题，还会涉及到
在侵权行为发生时谁将有版权执行权。
B、版权和许可证的强制执行--因为开源项目涉及到众多版权拥有者的作
品，而每个作者都在他/她的作品中应用了一个开源许可证，因此当对某个许可
证的侵权或违约发生时，很难断定该由哪个作者来保护版权和许可证条款。是必
须将所有版权拥有者都找到然后联合行动呢，还是由某个个人代表其他人来采取
行动呢？对这个问题的答案还不清楚。虽然开放源码许可证要求在任何发行版本
上都须包含所有作者和版本日期，但是问题的关键是由谁来执行。FSF在这方面
的作法或许值得借鉴，通过与版权所有者签定合同，FSF可以独立维护许可证，
当侵权行为发生时也可以独立采取行动，而不必召集所有版权拥有人。然而，
FSF的作法在开源运动中并不常见。
C、商业开发--随着商业开发者对开放源码模式越来越感兴趣，出现了大量
有关发布作为开放源码软件的商业软件的问题。例如，当一个商业软件宣布为开
源软件时，其原商业许可获得者有什么权利？当一个商业开发者在一个基于公司
原来的专有软件之上的开源项目中不得不采用部分开源社区贡献的软件时，他有
什么权利？商业开发必然会带来开源许可证数量的激增吗？每个新增的许可证又
会产生众多变体吗？商业开发者及其律师会满足于限定在已有的开源许可证中进
行选择吗？商业开发者会不会为了从开放源码产品中获得收益而滥用开源许可
证？由于缺乏法律裁定，这些问题尚无确定答案。对开放源码的思考必然会产生
很多问题，需要开源运动的参与者对可能的结果和风险作出评估。
D、法律解释--开放源码许可证不是由软件许可证律师制定的，所以它们大
都很简单、直白，却可能漏掉了某些条款，在接受律师或法庭评审时可能会产生
歧义。即使那些试图严格遵循许可证条款每一细节的开发者，也会在特定许可下
究竟什么能做、什么不能做等方面遇到法律解释问题。开源许可证的一个独特之
处是，长期以来它们在开源社区内已经得到一致的解释，常常是社区领导者（如
Stallman）的口头解释。历史上，曾经就许可证的解释有过激烈的交流和争论，
也曾试图对标准开源许可证条款作出修改和"改进"。显然，Stallman对GPL的解
释起了关键作用，但是随着时间的推移，他以及其他元老将退出历史舞台，而留
下了一些不确定成份。随着开源模式的推广，对开源许可证作出法律解释，已变
得越来越重要。而且，对版权法的解释和修改可能对开源许可证的解释产生重大
的影响。尽管为了便于法律解释应限制许可证的数量，但是随着商业软件不断转
移到开源模式，将对增加许可证及其变体有越来越大的需求。开源许可证及其变
体数量的任何增加，都会继续导致许可证条款解释问题和许可证不兼容问题。
E、特定许可证漏洞--开源许可证的简单模式可能会引发大量特殊解释问题
的产生。例如，GPL和其它许可证没有规定许可证的永久性。这个遗漏可能会使
法庭在以后判定一个开源项目案例时，裁定为开源许可证已过时，因为它的"合
理"期限已过。其它的条款缺漏和省略也可能导致类似的问题。再看看BSD许可的
例子。BSD许可证限定了对于包括直接损害在内的所有损害的责任（即"不担
保"）。有人争论说，直接损害责任的限定是合同的关键要素，若不允许某人获
得直接损害赔付会影响到合同成立与否。因此，法庭可能会判定（BSD）合同不
成立，或有关直接损害限定的条款使得合同不合理或不可强制执行。
F、专利--专利是威胁开放源码/自由软件可预见的未来发展的关键性因素，
比如微软为ASF（Active Streaming Format）申请专利保护，从而将开源软件
完全排除在外，一些专有软件厂商发现这威胁到与开源软件的互操作能力。一些
著名开源人士建议通过以下方式缓解专利造成的威胁：鼓励企业通过许可他们的
专利可自由用于开源软件来增进其公关形象，一些企业似乎愿意某种限定方式对
专利进行许可，比如允许GPL软件自由使用，但他们不会允许LGPL库使用，因为
LGPL允许任何人将其用于专有软件；鼓励'开放专利'（Open Patent）的发展，
申请那些可供开源软件自由使用的专利，但这涉及到费用问题；鼓励交叉许可
（cross-licensing），建立所谓专利池（Patent Pool），允许企业将其用于
专有软件，同时要求企业交叉许可自己的专利以供开源软件自由使用，但这也存
在许多问题，比如假设某企业仅有几个专利而另一个企业则有数千专利，如何平
衡二者的付出与获得？等等。