我国软件业欲发展Linux无奈涉及问题过多

　　2003年3月6日，拥有Unix操作系统专利权的SCO公司，向总部所在地美国犹他州盐湖郡的第三地方法院提出诉讼，控告IBM公司盗用SCO拥有的Unix技术并擅自植入Linux内，要求赔偿10亿美元以上，IBM涉嫌的罪名包括盗用商业机密、不公平竞争、违约和非法干预SCO的商业经营。据说，SCO获得到了有利证据，声称2.4版的Linux内核中包含有来自SCO公司Unix系统V内核的代码。
　　　　
　　
　　　　5月14日，SCO继续扩大法律行动，再次发函给全球1500家大企业，警告称，使用Linux可能触犯法津。SCO公司近日宣布，将在“本月的某个时候”，给Linux商业用户邮寄发票，要求这些公司为每台的Linux服务器支付699美元的使用许可费用。
　　　　
　　　　9月4日，对于Linux知识产权上的纷争，IT业巨头戴尔公司表示：一些大客户要求戴尔向他们做出保证，一旦SCO起诉他们使用戴尔安装了Linux产品的计算机时，戴尔应为他们提供保护，戴尔明确说不提供这样的保护。
　　　　
　　　　近几个月以来，在SCO与IBM这场热烈争论的法律案子里，是何种知识产权问题？我们看到，在国内鲜有人研究SCO诉讼的真实影响，去研究GPL许可协议，业内人士称，实际上，国内厂商发展Linux已经把GPL协议完全抛在一边，而就在这里隐藏着诸多潜在的知识产权风险，同时使用用户也存在被索赔及起诉的风险。在一系列纠纷和诉讼下，各种开发源码的版权和许可权的问题值得密切关注。
　　
　　　　一、LINUX存在隐蔽的知识产权陷阱
　　　　
　　　　国内一些专家对完全基于Linux发展自主操作系统、开发产品提出异议。实际上，Linux的创始人LinusTorvalds本人始终没有放弃对于核心程序的版权要求，只要其愿意，可以在任何时间收回Linux的开放协议，将其重新变为独家的专利，或者他完全有自由随时修正软件的许可证条款，事实上，Linus转向现在的GPL协议也经历了这样一个过程。如果有朝一日，他将操作系统内核又封闭起来，我国软件产业紧跟的结果是再一次摔跟头。
　　　　
　　　　仔细分析起来，Linux核心的一部分被判定存在侵权的可能性的确存在。事实上，Linux的代码侵权具有多种潜在的可能性，而且Linux的开发机制和代码审核流程并不像自从问世起就遭受版权问题磨练的FreeBSD等开放源代码操作系统那样严谨。
　　　　
　　　　在GPL(下文有详细介绍)的使用中，经常遇到的一个问题就是程序衍生作品的版权问题。依版权法理论，修改、翻译已有作品而产生的作品，其版权归修改翻译人享有，也就是归再创作作者享有版权。受GPL约束的自由软件亦不例外，GPL许可证的接受者，当然合法地获得程序或基于程序作品的修改权利，也就是说他有修改程序的法律依据。修改之后的新作品的版权应归他所有。但是，重要的是，修改者在重新发布经修改的程序(衍生作品)时，必须满足GPL对他的要求：“你必须使你发布或出版的作品允许第三方作为整体按许可证条款免费使用”。并且GPL条款规定“当你重新发布程序(或任何基于程序的作品)时，接受者自动从原始许可证颁发者那里接到受这些条款和条件支配的复制、发布或修改程序的许可证”。
　　　　
　　　　显然，当修改者重新发布经修改的衍生作品时，除了可以在衍生作品上表明修改者身份之外，他已对衍生作品丧失了任何的支配权。所有用户的许可证，不管是谁直接发放的，都视为从原始许可证颁发者获得。衍生作品的作者对作品享有著作权，但他重新发布衍生作品时，实际上是将权利让渡于许可证的原始发行人。衍生作品的用户也视为从许可证原始发行人处获得复制、再发行和修改作品的权利。
　　　　
　　　　经过修改的程序，形成基于程序的衍生作品，再发布时受GPL条款的约束。但是，如果能够证明再发布作品的某一部分并非是程序的修改或其衍生作品，而是独立的部分，则形成“不同作品”。不同作品独立发布时，不受GPL条款的约束，作者对该作品享有完整的著作权。即使是不同作品，但当它作为衍生作品的一部分发布时，作为一个整体它仍受GPL的约束。
　　　　
　　　　在法律意义上，我们无法引用工业时代的规则条文对利用Linux开发的软件产品进行明晰的产权界定。根据现有通行的软件版权登记办法，只有是著作权人独创而非抄袭、复制的软件产品，才能依法进行登记注册，受到法律的保护。因此，澄清软件权属及其合法来源就成为在法律上对产权界定的首要条件。
　　　　
　　　　反过来看我国利用LINUX的应用程序开发，其核心是通过免费获取而非独立开发，而不同开发商各自添加的安装、使用界面和外挂软件包，也有很多取材于“他山之玉”——这些自由软件世界里的必然，用现行法律的准绳约束，就会明显感到缚手缚脚的羁绊。
　　　　
　　　　事实上，就在前不久，Turbo Linux公司试图在中国软件登记中心登记其Linux版本的版权时受挫，其原因就是如此。
　　　　
　　　　二、要命的“GNU GP”许可证
　　　　
　　　　Linux是依照GPL发布的，因此，它的版权问题与其它依GPL发布的自由程序相同。
　　　　
　　　　Richard在倡导自由软件联盟计划时,从软件的版权许可协议入手,创设了一种与其开放源代码软件发展相适应的“通用公共许可协议”( General Public License，GPL)，它是自由软件联盟GNU的开放源代码软件许可证的一种，是开放源代码软件领域最富盛名的一种许可证，但同时，GPL许可证也是开放源代码软件领域对被许可人权利限制最严的。
　　　　
　　　　GPL许可证只约束有关程序的复制、分发和修改行为。但作为一个例外，如果运行程序的输出构成基于程序的作品时，运行行为同样受到许可证条款的约束只要遵守GPL有关程序的复制、分发与修改规则，你有权以执行代码的形式来复制和分发程序，但必须与执行程序一同附上源代码，或者提供获得源代码的书面报价信息。获取源代码的报价以实际完成源程序发布的成本为限。
　　　　
　　　　Linux的版权问题与其它依GPL发布的自由程序相同经过修改的程序，形成基于程序的衍生作品，再发布时受GPL条款的约束。但是，如果能够证明再发布作品的某一部分并非是程序的修改或其衍生作品，而是独立的部分，则形成“不同作品”。不同作品独立发布时，不受GPL条款的约束，作者对该作品享有完整的著作权。即使是不同作品，但当它作为衍生作品的一部分发布时，作为一个整体它仍受GPL的约束。
　　　　
　　　　GPL的核心原则是，任何基于GPL软件开发的衍生产品在发布时必须采用GPL许可证方式，且必须提供源代码。目前，涉及到SCO与IBM关于LINUX的侵权官司的事件，IBM认为，既然SCO先前作为一个Linux厂商(现在SCO实际上是以前的Linux厂商Caldera)基于GPL发布了包括Linux核心源代码在内的Linux系统，其中包括了这次SCO认为所谓“侵权”的部分，由于这种许可证的发放是不可撤销的，因此SCO不再享有对这些代码的权利。这里的潜在风险在于，GPL虽然已经诞生了十几年，但从未真正经过法律的考验。最近一段时间，GPL侵权事件屡屡见诸报道，却无一例真正通过法律程序解决。可以说，这次判决的结果将直接影响自由软件的命运。
　　　　
　　　　三、探究开放源码的历史由来
　　　　
　　　　在上个世纪80年代，随着个人计算机的出现，使得硬件的价格能够被个人和中小企业所接受，这给广大用户带来了广泛使用Unix系统的可能。但是，由于INTEL8086芯片的个人计算机能力比较差，在其上不能实现真正正常工作的UNIX多用户系统。进入九十年代之后，英特尔公司推出的80386芯片使个人计算机的计算能力大大提高，在个人计算机上构建一个可以真正使用的Unix也成为了可能。
　　　　
　　　　事实上此时能运行在X86平台上的Unix相当有限，Mircosoft的Xienx是一种(后来发展成为SCO Unix)，但不能指望能自由、免费使用这个商用系统。要移植Unix到PC平台上便需要Unix的源代码，而此时受AT&T的许可权的限制，Unix代码还不能被自由获得(但在BSD与AT&T的法律纠纷之后的4.4 BSD Lite不再受这个限制了，可以在BSD许可下自由使用，这为后来的FreeBSD许可带来诸多便利)。很多计算机爱好者为了实现一个可以自由使用的操作系统，不断进行着努力。自由软件基金会的GNU计划的目的就是打算创建一个自由的、与Unix类似的操作系统，为了实现这个目的，GNU开发了很多非常有效的工具、包括编译器和很多系统命令，然而GNU计划中的操作系统内核──HURD，却进展缓慢，从而无法构建一个完整的操作系统。很快，就有计算机爱好者开始考虑在个人计算机平台上构建一个Unix内核。芬兰一位计算机研究生Linus Torvalds开始了这个工作，他通过学习Minix，一个用于教学目的的简单Unix系统，在x86平台上构建了Linux内核，这个内核和GNU的系统工具结合起来，取得了相当大的成功，成为当前非常流行的GNU/Linux系统。
　　　　
　　　　与这些Linux方向的努力相比，BSD方面的研究人员的行动因为AT&T与BSD的法律纷争使得BSD的发展受到了阻碍。但是仍然有两个将BSD移植到80386平台的开发工作同时进行，一个是BSD/386小组，他们的研究结果为商业版本的BSD/OS，属于商业公司BSDI。另一个就是386BSD计划，后来发展成为FreeBSD。
　　　　
　　　　386BSD计划由Bill Jolitz等研究人员发起，将4.3BSD Net/2移植到80386平台上，并使用386BSD的名称发布。但是移植工作是一个复杂的任务，直到386BSD 0.5版本，系统中仍然存在相当多的问题没有解决。在1993年，另一些研究者决定加入这个计划，打算和Bill Jolitz一起修正系统中存在的问题。但是这时计划的组织者Bill Jolitz突然决定退出，使得386BSD计划面临停止的危险。Bill Jolitz作为计划的发起者和负责者并没有对该如何发展给出具体意见，因此386BSD计划是到此为止还是继续发展，就取决于其他开发者的决定。不过，该项目的另三个参与者Nate Williams, Rod Grimes和Jordan K. Hubbard决定继续这项工作，他们创造