欧洲委员会反对供应商锁定

还没有读者喜欢这个。
Is Occupy Wall St. really an "open source protest?"

Opensource.com

经过长达十年的斗争,欧盟委员会和微软公司就反竞争行为达成的和解协议条款终于在上周达成。官方和解对欧洲消费者来说是一次胜利,但该公司同时发布的关于互操作性的公开承诺对于开源社区来说却差强人意。

官方和解协议是关于 Windows 和 Internet Explorer 浏览器捆绑的协议,欧盟委员会认为这种捆绑行为使微软在网络浏览器市场中获得了不公平的优势。

提交给欧盟委员会的浏览器选择画面,见微软提案附件 B 和 C微软 Windows 的欧洲用户很快将看到一个弹出式选择画面,如上图所示,允许他们选择十二个浏览器之一使用:Internet Explorer、Safari、Chrome、Firefox、Opera、AOL、Maxthon、K-Meleon、Flock、Avant Browser、Sleipnir 和 Slim Browser。根据欧盟委员会的说法,“这应确保基于优点的竞争,并使消费者能够从网络浏览器市场和相关市场(如基于网络的应用程序)的技术发展和创新中获益。”

您可以在欧盟委员会网站上阅读案件文件,并在美联社报道中阅读关于网络浏览器问题和和解协议影响的良好概要。

与此同时,微软发布了修订后的互操作性公开承诺,欧盟委员会的新闻稿小心地指出,这并非和解协议的一部分,尽管政府“欢迎这项改进互操作性的举措”。公开承诺表示,公司将为包括开源社区在内的开发者提供访问 Windows、Windows Server、Office、Exchange 和 SharePoint 等产品的技术文档的权限。这对开源开发者来说听起来非常积极,但当你看到专利承诺重新定义开源以排除商业应用程序时,情况就不同了。

‘开源项目’是指根据开源许可证自由分发、修改或复制的软件开发项目,并且 不由其参与者进行商业分发 如果您从事从开源项目派生的软件的商业分发或进口,或者如果您在创建此类软件代码范围之外制造或使用此类软件,您将不会从此承诺中受益,无论对于此类分发还是对于这些其他活动。” [注:重点为我所加]

首先,我们真的又回到这里了吗 - 争论自由/开源软件是否可以为了盈利而出售?也许我们应该重新审视开源促进会维护的开源定义,该定义非常清楚地表明,如果您愿意,您可以出售该软件。或者不卖。这是您的选择。

这项专利承诺定义通过试图排除商业应用程序而剥夺了这种选择权。这听起来对您来说不“反竞争”吗?具有讽刺意味的是,这与公司反垄断诉讼的和解同时进行宣传?当然,这并不新鲜。您可以在Groklaw上阅读更多相关信息。

但是,在您怒火中烧之前,要记住的关键是,政府领域正在缓慢取得进展。尽管该承诺不是与欧盟委员会和解协议的一部分,但政府机构指出,它“将仔细监测该承诺对市场的影响,并在待决的关于互操作性的反垄断调查中考虑其调查结果。” 凭借这一点和官方和解协议,欧洲委员会向科技行业发出了强烈的信号,即它不会容忍导致供应商锁定的行为。政府机构反而支持消费者,他们应该有自由选择他们想要使用的产品的权利。值得称赞。

User profile image.
Melanie Chernoff | 作为红帽公司公共政策经理,Melanie 负责监控、评估并努力影响美国和国际立法以及影响开源技术和开放标准的政府法规。她还担任公司企业公民委员会主席,协调红帽的慈善活动。

3 条评论

作为 OSA 互操作性小组的联合主席(注意:OSA 最近与 OW2 合并),我与您一样担心“专利承诺”的措辞。Jaspersoft 是 OSA 的众多商业开源(在我们的案例中为“开放核心”)成员之一,在过去 3 年中密切合作,定义和实施互操作性标准。这些标准包括单点登录、数据集成、门户集成以及跨 ERP、CRM、BI、系统监控和数据集成应用程序套件的其他标准。我们现在开始努力加强 OW2 的互操作性战略和路线图。

Mike

Andy Updegrove 曾经告诉我,“开放标准可以在没有开源的情况下存在,但开源不能在没有开放标准的情况下存在。” 因此,感谢你们在互操作性标准方面所做的工作。我们都会因此变得更好。

开源可以在没有标准的情况下存在。

标准旨在允许不同实体在同一空间同时进行竞争,并允许在附近空间工作的实体能够有效地进行接口。

开放标准显然增强了开源。

然而,当我们谈论开放标准和闭源时,情况变得棘手。

即使在开放标准中,闭源几乎也会自动导致互操作性问题,因为大多数开放标准都允许扩展机制(“增长和创新的空间”)并在某些领域规范不足。此外,任何用英语书写的东西都存在歧义、潜在的过度规范和其他错误。

那么开源有什么不同呢?开源使得即使在开放标准不完善的情况下也更容易正确地进行接口,因为所有蓝图都是可访问的。此外,您更有可能更快地发现某些类型的问题(因为同样的源代码访问)。

闭源世界中代码访问的(劣质)替代方案是构建非常全面的测试,以尝试捕获主要问题(请注意,开源也可以构建全面的测试)。但我们发现了两种不同的情况。

有合作兴趣的闭源竞争对手可以积极努力通过测试,并努力使标准非常清晰和正确;然而,任何垄断者都可能从存在的每一个互操作性故障中获利。原因是,当互操作性失败时,现状——打开昨天的文档或运行今天已经创建的代码——更有可能保持不变,而竞争对手则被贴上“损坏的产品”的标签,即使竞争对手实际上是按照规范构建得更好。而且很容易发生意外的互操作故障(“错误”自然存在于预期的人为错误中,即使标准是完美的),更不用说战略上的马虎、前面提到的普通扩展以及为了阻止互操作性而对扩展机制的严重滥用,即使在“几乎”普通的情况下,这些情况也应该包含在核心标准中。

因此,当涉及到互操作性时,开源在所有情况下都能够实现互操作性,即使可能效率不高。然而,即使在开放标准的范围内,闭源也可能导致非常严重的互操作性问题,并且开放标准往往在许多方面都存在不足,使得闭源竞争对手更容易明显比其开源同行更难实现互操作。

请注意,那些赞成闭源的人经常希望通过标准中的扩展来实现“创新”,特别是由于它允许锁定。[无论有没有标准,对锁定的渴望都是首先使用闭源而不是诉诸服务质量竞争的动机。垄断者只是比大多数其他闭源开发者更成功地利用了这一点。]

另请注意,有时互操作性故障是微妙的。它们可能不会立即显现出来,并且可能会在不合时宜的时刻出现,导致买家重新考虑他们对新软件的使用。

最后,请注意,在实践中,我们确实发现了开源的互操作性故障,但关键的区别在于,如果您有非常重要的文档想要保留并向前推进,而新的开源软件在某种程度上失败了,那么至少有可能让人(也许要花钱)找到问题并修复它们(假设您没有时间和技能自己完成这项工作,也没有其他人完成这项工作)。开源存在的风险可以通过源代码的开放性来缓解。事实上,有时为项目贡献最多代码的公司会通过能够提供与此类软件相关的最高质量的服务来利用他们的投资(如果他们表现不佳,他们可以被替换)。相比之下,尝试让专有软件供应商以外的任何人帮助您解决迁移问题。有时第三方会伸出援手,但他们的能力有限(与此同时,供应商实际上可能不想让您修复某些类型的问题,如果这意味着销售额损失)。而且我们不要忘记闭源已经更加成熟。随着开源继续增长并获得更多供应商的支持,差异将会更大。

Creative Commons License本作品根据知识共享署名-相同方式共享 3.0 未本地化版本许可协议获得许可。
© 2025 open-source.net.cn. All rights reserved.