KarenCopenhaver是
美国Choate,Hall%26;amp;Stewart律师事务所的合伙人，他给《CIO》的记者讲述了有一次自己为某家大公司主持研讨会的故事。这个研讨会的目的在于帮助公司弄清这样一个事实：
软件开发人员要遵守公司特定的代码工作规则，并对此负责任。这些特定的工作规则涉及对开放
源代码、免费代码和第三方提供代码的使用。Copenhaver认为当时研讨会进行的很顺利。然而开发部门的经理接着找到她说，“这些开发人员不能完成需要每天做完的开发工作，并且担心很多事情，他们总是要求助于开放或免费资源”。
3 p- |: u5 A1 A& c[color=#FFFFFF']
! g- s) }* n9 e' H# f这位经理的话体现了一个关键问题，这个难题已经影响到今天遍布全球的无数开发部门。面临预算紧缩、开发
时间紧迫、担心业务被转给更低的
报价方，以及对前所未有复杂软件日益增加的
需求，
程序员被诱使从各种第三方资源那里找来小部分、片断甚至大量的源代码，目的是为了让手头的工作完成的更快。这种外借代码的情况会造成一定的不良后果，它的作用
类似于镇痛剂，一时痛快，但遗患无穷；也就是说，可能永远不会有人留意你的代码内容、产品在内部的流转或外部发货，借用代码之后，你的生活可能还会继续。反过来说，这种后果有可能是灾难性的，但是未发生之前你却不会感觉到风雨预来。按照
知识产权律师的说法，在很多收购案中，不洁代码（DirtyCode）已经导致了收购拖延，代价可谓昂贵。这个过程中，由于一位独立
程序员Linux代码的核心贡献者HaraldWelte的呼吁、诉讼的努力，至少有100家公司被迫从自己的产品中删除或放弃多段开放GPL代码（GPL，通用公共许可证，GeneralPublicLiscence），他们没有恰当遵守代码提供方的许可协议就借用了这些内容。
6 l) u9 y, v6 x& |7 C! Q8 o) X2 G# ~[color=#FFFFFF']
' P( f8 L0 g3 G6 ]3 E其实大可不必如此麻烦。公司本可以避免出现使用
开放源代码的不利后果。《CIO》访谈了部分法律专家，他们提供了不少技巧和策略，这些专业建议和实务总结能让公司和开发部门保持必要的灵活性，从而更恰当、更有效和更稳妥地利用好每个软件开发人员工具箱里都有可能找得到的这种重要开发工具，这些方法实施得当特别能够限制未来的法律纠纷的发生。
- m0 H6 T; F" A& }& h$ ^- C4 X8 m
[color=#FFFFFF']
s7 \1 [' I. W7 x V. n) X2 o
假设被捉程序员会复制一些代码，会改变外部代码的函数变量，调整空行等等，他们这么做时有人指导要注意什么前提吗？审查不正当使用他人开发的部分代码这种事情，过去也许可能性不是很大。但是现在时代变了。像BlackDuck和Palamida这样的软件兼容性
测试工具已经出现，它们能扫描数百万行的代码，并且把这些代码和包括了大量已知软件的庞大后台
数据库中的代码样本进行对比，这让公司得以定位查找（并且相当快速）之前已经写出来的代码是否符合开发和知识产权要求即便是对修改过的那部分变量命名和空格的搜索也是如此迅速而精确。
# f" f {4 o! }2 ~* z[color=#FFFFFF']
9 k8 P- s p6 L8 K9 Y5 @+ GBlackDuck公司的客户名单在过去一年当中已经增加了300％，目前包括了财富500强及全球500强中的跨国公司中的11家（BlackDuck公司，开放软件开发公司，其产品帮助企业有效、合法利用开放源代码软件，同时确保他们满足与使用这些代码相关的规范。）。根据公司提供的
信息，由他们提供的代码评估服务程序“ProtexIP/OnDemand”被上百家公司
下载，并且在超过140宗企业并购案中被使用，这些并购案中的尽职审查交易费用估计总额达到了90亿美元。
3 I) I4 _# t- \- r2 |
[color=#FFFFFF']
" n( R* b" w* h) H' N) i2 ?9 k2 o
开放源代码和
免费软件的文化因素对借用企业的行为也有影响。Whistle-blowers公司曾经因为员工不当使用开放源代码而开除他们。一些违反通用公共许可证（GPL）的案例也引起世界性的关注，关注者是那些有经济权益在里面的用户，他们注意到在商业软件产品中可能也有类似代码不当使用的行为。举个例子，
网络硬件制造商Linksys在2003年被
思科收购不久，就高调发布其WRT54G型
路由器的
防火墙产品，当时有证据在手的用户发现这个产品中的部分代码是以Linux开放源码为基础改写的。专注的通用公共许可证（GPL）捍卫者Welte拥有Linux防火墙软件代码的
版权，他使用这一版权鼓动超过100家的公司删除产品中的侵权代码，或公开自己的商业源代码，对此他已经在德国法庭提起诉讼。涉讼公司包括一些小型公司，也包括Asus、Belkin、Fujitsu和Siemens这样的信息产业巨头。Welte计划在德国创建一家非营利组织以更积极地追究侵权，这样一个计划可能有助于促进他的工作。“在我看来，有必要提高公众的知情权，并且让案件本身公开审理”，Welte说。但是他坚持：“这并非政治迫害或某种宗教信仰斗争。这只是让公司级的开放源代码用户按照规则操作，这些规则曾经被这些公司忽视，不管是出于什么样的原因”。即便如此，开放资源的制作者得到的不公正对待依然被关注甚少。然而，随着开放源代码软件进入公司一些非常关键的
系统，如果公司被抓住有侵权行为，那么他们风险就会急剧提高。有很多类似这样的律师对话：MPL有什么特别专利权法律规定吗（MPL，MozillaPublicLicense）？GPL能保护二次开发（derivativework）多远？告诉我什么是二次开发？简单地回避难题可能比较容易，但是避难就易的做法会增加公司的风险。“要明白，代码来源是真正必须回答清楚的认识其重要性是CIO和IT经理人的义不容辞的责任所在”，MarkRadcliffe警告说，他是DLAPiperRudnickGrayCary（一个全球法律服务组织，其会员是独立的法人实体）的合伙人和一个致力于开发GPL3的委员会的主席。然而，并不只是因为引入律师的工作，就意味着你得到了解决所有授权问题的决定性答案。开放源代码判例法不是这些律师经常涉足的法律。“如果这个领域中有更多的判例存在，那么我们就很容易给客户提供相关法务建议”，IraHeffan承认，他是GoodwinProcter事务所的合伙人，GoodwinProcter在1997年写了一篇法律审查方面的文章，探讨GNU公共许可证的可实施性。但是他指出，有很多人在努力实现开放源代码纠纷领域的司法意见一致，包括2006年初在华盛顿大学设立一个所谓的“模拟法庭”（由
法学专业实习学生主持），这个法庭审判后出具法律简报，这有助于和联邦巡回法院法官建立对话，就各种开放源代码案件展开交流。 重大规则的制定
! ^$ B3 Q; a; d. d
[color=#FFFFFF']
' {9 M4 d: P: V
在和法律代表会谈的同时，你也要留意请他们帮助确立有关开放源代码使用的内部规则。“有的开发主管或CIO
习惯下达简单禁令的
管理模式，可是这种做法并不具有现实主义功效”，Radcliffe说。相反，他说公司必须建立规则。在他的经验看来，这些规则的发挥作用时具有非常大的差异。举个例子，他知道一家“
硅谷重量级公司”，在他们的软件开发协议里，把开放源代码称作“传染性软件”。他说其他公司开发完全不同的尽职审查程序，来处理并购过程中的开放源代码事务。而且他指示某家公司在内部使用开放源代码，但是在给客户提供的产品中却禁止这么做。关键在于给开发人员设立规则，让他们知道什么时候采用什么方式把某类外部代码整合进他们的开放资源项目。“非常清楚的一点是，如
果实际写码的人没有获得指示，并且没有某类执行机制的制约与引导，那么他们就会在
互联网上抓来任何能够抓下的东西”。审查你的程序代码尽管几年之前有人声称“我们不了解这些开放源代码是什么东西”，这种辨词在法庭上会对判决产生影响，或者在和潜在收购合作伙伴沟通时发挥烟雾弹作用，但是这种情况现在已经不复存在了。开放源代码已然成为主流，这已经不是什么秘密，而且负责任地使用开放资源已经成为一种既定准则。法律专家说，公司主动设置一个流程，来对产品代码的出处进行核查很重要。Choate事务所的Copenhaver也是BlackDuck公司的辩护律师，她说公司应该为高层执行官设立一个就重大开发主题下达指令的计划，并且在代码核查结束后的某个时间点上进行尽可能的修正。她说，这个流程也应高包括和开发人员的日常会面环节，开发人员总是被发现在缺乏恰当的授权许可的情况下就使用免费或开放资源。这些开发人员需要被告知不遵守工作规章的严重后果规章不仅是公司要遵守，他们本人更要遵守。“有些人有过这样的经历：只有对产品彻底分解，并重新进行质量评估之后，产品才算最终通过，任何有过这样经历的人”都不想重复这一经历，Copenhaver说。而且为了防止开发人员秘密在别处抓取代码，管理层需要帮助他们。“有CIO或开发主管会说，‘这些家伙（开发人员）不能完成工作，并且担心后果的严重性’，这话的问题在于，这么讲话的人不曾建立这样一种机制，这种机制能给开发人员提供支持，从而让他们的问题能够快速得到回答和解决”，Copenhaver说。
- ^9 S/ z7 f) k, ?* x' G6 d[color=#FFFFFF']
9 m4 @% b/ R s4 w$ | L) x$ m她断言，开发人员能否得到这些答案，将是关乎开发团队和法务专家之间能否建立信任的大事。“我们真正想得到的就是一次真诚的谈话。如果你说‘就对开发人员说‘不’好了，我们不使用任何开放源代码的东西’，这句话等于告诉面临困难的开发人员，‘不要问我们，我们不告诉你’。而这个时候你的正确做法是，告诉他们：‘最大限度地利用这些可用代码资源，我们能获得巨大的制衡力量和竞争优势’，但是我们需要在完全明白遵守规则责任之后才能这样做”。 来自一位读者的观点：
$ U T" ]+ h% m
[color=#FFFFFF']
% B9 V# s- r$ A) C5 ?
这是一个如此简单的命题。作者认为任何人都应该理解。这个命题包括了所有的代码开发模式包括开放的和不开放的。对此我本人提供的答案如下：1)大学里允许欺骗吗？你被允许复制我的考试答案吗？如果不，那么是什么让你认为你已经得到了复制我开发出来的软件代码的许可。2)还记得安然公司吗？商业诚信是一个选项，如果你不想待在牢狱里，那这就是唯一的答案。任何未经许可就复制外部资源的开发人员都应改立即终止自己的侵权行为，这和商店警卫帮助自己从钱柜里往提包里装钱一个道理。
v# m }- i' i" \# w( L[color=#FFFFFF']
7 ^ Y/ j3 ?1 r# `# A3)如果管理层告诉你继续欺骗，那么就从这里撤吧。你不值得冒丧失自己声誉的风险去为这样一家公司工作。4)如果你发现下列情形，就马上寻求法律援助：a)你自己打算使用外部代码资源；b)你发现有人未经授权就使用外部代码资源；c)你发现一位经理人实施自己的职权，来使用外部代码资源。 就像我说的那样这是件简单的事情。如果有人打破了规则，他们就应该被解雇。如果你发现因为有公司的人打破规则而让公司陷于不守规的境地，那么就立刻承认事实，并且改正错误。 诚实是一种如此令人尊敬的品德而且是得到如此尊重的原因之一，这正是我们近来在开放源代码领域四处碰壁所得到的真谛。 原文链接：http://www.chinahrd.net/zhi_sk/jt_page.asp?articleid=108300
