tms tck
在上个月提议将Websocket API包含在Java EE 7中之后, Java执行委员会EE / SE对JSR 356进行了投票,尽管他们投票赞成,但有关规范的TCK许可证仍然存在问题。
正如您在上面看到的那样,在16个投票中,有11个投票赞成将WebSocket API作为Java的一部分包括在内,但RedHat和Twitter都弃权了。 Google投票否决。瑞士信贷和高盛决定不参加,再次对某些成员对JCP的承诺提出质疑。
是RedHat早早敲响了警钟,仔细指出,尽管它们全都是出于JSR的优点,但围绕TCK许可条款仍存在一些悬而未决的问题。 他们认为,TCK测试对于感兴趣的各方应该是免费的,而不是必须付费才能使用它。 他们评论说:
与Web套接字jsr相关的RI许可条款规定:
7.费用,特许权使用费和付款。a)年费。 每年35,000美元,用于以源代码形式(部件号J2E88-UPD1-A889)访问该技术,仅当您同时订购或同时订购部件号J2E88-TC4-A889(许可Web套接字1.0 TCK的Java API)。
这似乎与该JSR受其约束的JCP 2.8术语冲突。
我要论证的违反JCP 2.8的条款包括:-“ TCK许可条款必须允许实施者自由和公开地与所有有关方面讨论测试过程和详细的TCK测试结果。”允许EC根据4.2最终批准投票中的指南评估TCK的质量,因为不必一定是被许可方才能查看源代码,并且由于希望对社区透明,非EC成员应能够参与评估TCK和RI。
RedHat补充说,他们希望“在此JSR最终获得批准之前解决许可问题”,否则他们将在开放,公平的竞争环境中坚持不懈。 投票赞成的其他人也回应了RedHat的观点,恳请他们在最终投票之前额外考虑TCK许可。
世界上最大的Java用户组巴西的SouJava选择保持乐观:
尽管我们同意对其他EC成员提出的TCK许可存在担忧,但是在过去的几天里,规范负责人已经提出,并采取了重要步骤开始解决提出的问题。 我们希望这一趋势将继续下去,因此我们投票批准JSR继续其进程。
我们希望这一问题能尽快解决,并且我们可以获得社区肯定渴望的API。
翻译自: https://jaxenter.com/concerns-raised-on-websocket-jsr-over-tck-license-terms-104248.html
tms tck