许多人将波士顿联邦法院正在进行的新诉讼描述为“首次测试通用公共许可证 (GPL) 的有效性和可执行性的诉讼”。那又怎样？

这场诉讼真的会影响 Linux 程序员的未来吗？对于那些将商业模式押注于开源趋势的公司来说，这场纠纷重要吗？正如一些 OSS 倡导者所建议的那样，法官是否会借此机会惩罚一家傲慢的美国软件供应商，因为它违反了 GNU 的长期规则，从而捍卫 OSS 的事业？

抱歉，可能不会。是的，这个案例很重要。是的，根据共识，这显然是首次 GPL 法庭测试。但这并不能预示 OSS 的未来，因为这是一场关于一份极其糟糕的合同的纠纷，而且发生在双方混乱且不断变化的沟通背景下。

你无法通过分析一个用某种编程语言编写的简短且文档记录不佳的应用程序来预测该编程语言的前景。而且在本例中，基础合同是一个异常值，它与现代审慎的软件管理和许可实践规范相去甚远，以至于在许多数量级上，它都超出了范围。最终，它将更适用于“软件产品管理 101”和“初级软件合同”培训，而不是用于改进 OSS 策略。

故事在公开的法庭文件中讲述。诉讼当事人争议的基础合同是著名的 MySQL OSS 数据库的芬兰作者对美国软件发行商/经销商提起的诉讼所提交的答辩状的公开附件。（因此，合同以及各方的各种论点、电子邮件和宣誓书对于技术经理、律师和培训师来说都是“开源”的，可以用来学习和改进工作流程。）

作者从法庭文件中获得了原始国际协议，根据该协议，一家总部位于马萨诸塞州的公开交易、历史悠久的企业软件公司从芬兰一家年轻的、离岸的、小型开发商那里获得了转售权。令人震惊的意外：这两家公司同意在一份仅有九段的合同上进行一项影响巨大、金额巨大的交易。该协议总共只有 1.25 页。

Progress Software 同意向一家充满活力的外国公司支付大约 30 万美元的费用，该公司位于一个新的、Progress 不熟悉的行业领域，相当于众所周知的信封交易。芬兰公司 MySQL AB 通过一份简短的声明，表示未来的合同将在“稍后”使用，从而批准了马萨诸塞州供应商采购其关键产品，从而触发“总计高达 250 万美元”的费用。由此产生的争吵清楚地表明了为什么经验丰富的商人（包括律师）对“让我们彼此信任，稍后再弄清楚交易和细节”的乐观想法皱眉头。

简洁和信任有什么问题吗？换个角度想：为什么要先做手术，然后再拍 X 光片或查看病史？为什么不头朝下跳进一条陌生的河流？如果你在没有先弄清楚基本规则的情况下启动一项重大的软件计划——OSS 或专有软件——你可能会伤害自己，也可能会伤害他人。这就是这里发生的事情。

大多数合同的一个目的类似于许多数据处理的规范：基准测试、测试和标准。在这里，零散的代码被交付了。也就是说，一个不完整的“协议”被用于过多的行动，而且太仓促了。

这份简短且最终令人痛苦的合同遗漏了什么？大多数软件协议中发现的大部分条款和条件，就是这样。除了其他要点外，最明显的缺失是：1) 预期的“稍后、取代协议”何时完成？2) 业务条款的参数范围是什么？3) 技术支持需要和提供的服务程度究竟是多少？他们所说的“企业级支持”和“现有电子支持渠道”是什么意思？4) 谁将是公司间协调的指定联络人？5) 正如 MySQL AB 在这里所认可的那样，给予你的被许可人“合理使用”你的关键商标的权利意味着什么？允许和排除哪些特定的变体？6) 原始作者将保证哪些持续的产品增强服务？7) 如果有必要，争议将如何解决或仲裁？8) 如果由于一方的过错而发生争议，未违约方是否会从违约方获得其执行成本和损害赔偿？9) 为什么省略所有通常被嘲笑的通用或“样板”条款，而这些条款包含在大多数合同中正是因为它们有助于防止争议并实现执行？

大多数现代成熟的软件企业都认识到软件分销交易中可能并且确实会出现的许多问题。他们设计他们的交易（例如，在“条款清单”或大纲中），然后“编码”（即，编写合同草案），然后测试并记录他们的 协议（即，协商和完善基本合同，并编写和修订必要的附件），就像他们对他们的 应用程序 所做的那样。

例如，许多软件项目详细且提前地识别“用户需求”。这项交易显然缺少一份联合“条款清单”或“交易摘要备忘录”作为协议的锚点。

大多数应用程序都会由程序员同事进行质量控制检查。自动化代码测试工具被部署在一些复杂的环境中。这份合同大概是作为一个人的作品，或者至少是一个非常小的团队的作品而发布的。

精明的软件专业人士会包含错误消息功能。这份含糊的协议缺少典型的“违约通知，然后有机会补救违约”条款。

经验丰富的程序员会在他们的工作中包含头文件和其他技术文档，以协助以后的修订和调试。在您的软件交易中，包括作者和发行商公司之间指定的沟通模式。预先确定哪些特定人员有权向对方组织中的某些指定人员传递商业指示、异议和建议。

合同的简洁意味着各方可能会提出法律问题，这些问题会使情况变得复杂，或者至少会推迟结果。请记住，司法系统的车轮可能转得很慢，至少在美国是这样。

希望法院确认 GNU 模式的 OSS 拥护者可能会感到失望：诉讼双方都已经提出了与 OSS 问题无关的法律论据。例如，MySQL AB 已经（在 2 月 28 日）获得了针对 Progress 及其年轻的 OSS 子公司 NuSphere 的部分禁令，但这是基于商标法，而不是 GPL 的执行。联邦法官认为，GPL 问题在本次诉讼的早期总结阶段过于不确定，无法做出裁决。

然后是“共同错误”的法律原则。当双方无意中对交易的前提和条款持有不同但合理的解释时，合同有时可能会无法执行。经典的案例涉及类似的跨境事故。

这个传奇故事的草率性因其多国背景而更加突出。跨国交易值得额外的思考和条款，就像跨国应用程序通常需要更模块化的屏幕消息传递、双字节代码（用于亚洲字符集）、适应不同的操作系统迭代和其他精明的编码一样。

与外国公司进行交易需要额外的考虑。例如，许多离岸公司更喜欢（或坚持）使用仲裁来解决争议，这既是强大的文化传统的一部分，也是为了避免传闻中美国人倾向于过早、旷日持久且昂贵的诉讼。（在这里，诉讼当事人在案件的最初九个月内提交了 73 份不同的法庭文件，而且看不到尽头。）

世界旅行者在出发之前安排翻译、确认补给线并确定当地的通信协议。在国际合同中，许多公司采取类似的额外步骤。他们预先商定最低限度的协作产品计划，在合同中承诺访问彼此的总部并在主要的全球贸易展览会上会面，并包括其他合同“粘合代码”以帮助改进关系。常识告诉我们，当冒险进入不熟悉的领域时，要制定地图。在这里，双方迷路了，最终对簿公堂，导致了营销灾难、巨额诉讼费用和不确定的产品路线图。

OSS 社区中的一些人攻击了 Progress 和 NuSphere，理由是 MySQL 代码被修改，然后通过专有许可证而不是 GPL 或其他 OSS 许可证进行营销，这是一个准确但零碎的故事。诚然，NuSphere 修改了其模型以使用 GPL，在 NuSphere 看来，这仅仅纠正了一个短期的疏忽。但这并不是全部故事。诉状表明了另一种观点：相反，批评 Progress 让一些产品经理签署了一份文档记录不佳的合同，据推测，这并没有与律师和其他同事协调。判处此人参加许可研讨会。也许由于上市时间的竞争压力而减刑。然后，可以肯定的是，在花费巨资聘请诉讼律师并损失时间、管理精力和市场商誉之后，下次两家公司都将使用传统的、连贯的、完整的软件合同。

Progress-NuSphere-MySQL 的争斗最终可能被证明只是那些在没有充分“瞄准”的情况下就练习“准备，开火”的公司漫长历史书中的又一章。

糟糕代码的例子