修订Eclipse IP策略：第三方内容

Eclipse Foundation正在对我们的知识产权政策进行重大更新。 此更新的很大一部分是对我们管理第三方内容的方式的更改。

在Eclipse IP策略的上下文中，“第三方内容”是Eclipse开源项目利用的内容，而不是由Eclipse开源项目以其他方式产生或管理的内容。 由Apache开源项目产生的库被视为第三方内容。 如今，IP策略要求所有第三方内容必须先由Eclipse IP团队审查，然后才能由Eclipse Project使用。 在获得Eclipse董事会批准之前，我们正计划解决这个问题。

这些更新获得批准后，项目团队将能够在开发周期中引入新的第三方内容，而无需事先与IP团队核实。 也就是说，项目团队可以将构建脚本，代码引用等提交给第三方内容到其源代码存储库中，而无需先创建贡献调查表（CQ）来请求IP团队审查和批准第三方内容。 至少在两次发行之间的开发期间，项目团队有责任（有合理的信心）确保他们引入的任何第三方内容与项目许可证兼容。 在任何内容都可以包含在任何正式版本中之前，项目团队必须验证第三方内容许可证与项目许可证兼容。

传统上，在发布之前先进行发布审查，并且作为该发布审查的一部分，Eclipse IP团队将对项目的知识产权贡献记录和第三方内容使用记录（IP日志）进行审查。 在IP日志审查期间，IP团队将验证许可证兼容性状态。 我说“传统上”，是因为我们改变了传统，或更具体地说，我们在2018年末改变了Eclipse开发流程，以使项目团队可以在成功完成之后的整个一年中参与任何数量的主要和次要版本发布审查。 如果发布不需要审阅（因此无需触发进行IP日志审阅），则项目团队有责任确保所有引用的第三方内容的许可证兼容性。 但是，我们并不会动摇项目团队的精力：即使不需要进行正式审查，IP团队仍然可以帮助进行验证。

我们一直在尝试各种流程和工具，以帮助我们进行许可证兼容性验证。 这些工具将由IP团队在评估期间使用，并且也将提供给项目团队。 理想情况下，项目团队将许可证兼容性验证工具集成到其内部版本中，以便该工具可以识别需要进一步审查的内容，并将其提交给IP团队以在开发周期的早期进行解决，以便在我们运行该工具时在发布周期结束时验证内容-所有已标识的内容都将已经解决，并且IP团队可以对其进行“橡皮戳”。

这应该为项目团队提供极大的灵活性，使其可以尝试不同的库和版本，同时还可以使IP尽职调查过程更加简化和可预测。

进行这项工作的重要部分是利用现有信息数据库。 多年来，我们积累了许多图书馆的大量知识，但其他图书馆也做了很多工作。 新流程将利用其他受信任的信息源（在以后的文章中将对此进行更多介绍）。 我们将自己摆脱扫描源代码的每一件事，而要信任我们自己的数据库和其他信息源（并为这些其他信息源做出贡献）。

我们的原型工具专注于物料清单。 物料清单中的每个条目都标识一个特定的第三方库。 为了标识特定的第三方库，我们决定采用ClearlyDefined项目的五个部分标识符，这些标识符包括内容类型，其软件存储库源，名称空间和名称以及版本。 显然，定义的坐标大致类似于Maven坐标，后者通过groupid ， artifactid和版本明确标识了特定软件（例如org.junit.jupiter:junit-jupiter:5.5.2明确标识了已知在EPL之下的内容） -2.0）。 ClearlyDefined坐标系将内容的类型添加为“ maven”，并将其源添加为“ mavencentral”，因此org.junit.jupiter:junit-jupiter:5.5.2变为maven/mavencentral/org.junit.jupiter/junit-jupiter/5.5.2 （请注意，至少从理论上讲，源可能是其他Maven存储库）。 我们选择ClearlyDefined坐标至少部分是因为我们有使用非Java语言和非Maven Central软件仓库的项目。 使用这些坐标，我们还可以标识例如NPM内容（例如npm/npmjs/@babel/generator/7.6.2 ）。

物料清单就是一个ClearlyDefined坐标列表（原型工具会自动将Maven依赖关系列表或节点包锁定文件转换为该坐标系）。

Maven Dependency插件可用于生成依赖项列表（作为Maven坐标）：

 gt; mvn dependency:list -DoutputFile=project.deps -DappendOutput= gt; mvn dependency:list -DoutputFile=project.deps -DappendOutput= true 

Maven Dependency插件的输出采用以下形式：

 The following files have been resolved:    org.apache.commons:commons-lang3:jar: 3.4 :compile    org.slf4j:slf4j-api:jar: 1.7 . 21 :compile    org.slf4j:slf4j-log4j12:jar: 1.7 . 21 :compile    log4j:log4j:jar: 1.2 . 17 :compile    commons-logging:commons-logging:jar: 1.1 . 1 :compile    ... The following files have been resolved:   org.apache.commons:commons-lang3:jar: 3.4 :compile    com.clearspring.analytics:stream:jar: 2.9 . 6 :compile    ... 

原型工具生成的物料清单如下所示：

 maven/mavencentral/org.apache.commons/commons-lang3/ 3.4 , Apache- , approved maven/mavencentral/org.slf4j/slf4j-api/ 2.0 , approved maven/mavencentral/org.slf4j/slf4j-api/ 1.7 . , MIT, approved maven/mavencentral/org.slf4j/slf4j-log4j12/ 21 , MIT, approved maven/mavencentral/org.slf4j/slf4j-log4j12/ 1.7 . , MIT, approved maven/mavencentral/log4j/log4j/ 21 , MIT, approved maven/mavencentral/log4j/log4j/ 1.2 . 17 , Apache- 2.0 , approved maven/mavencentral/commons-logging/commons-logging/ 1.1 . 1 , Apache- 2.0 , approved maven/mavencentral/com.clearspring.analytics/stream/ 2.9 . 6 , Apache- 2.0 , approved ... 

输出实际上还包括带有输出的少数URL（例如，已知源代码时指向它们的指针），但是我已删除它们以专注于重要的位。 您还将注意到，在依赖项列表中重复的内容在输出中仅出现一次。

对于每个库，该工具都会确定许可证以及许可证是否被批准使用（我将在以后的文章中讨论它的工作方式）。 IP小组必须先审查并解决任何被列为受限而非批准的内容，然后才能将其包含在任何正式项目版本中（我将在以后的文章中讨论）。

目前，原型工具仅标识许可证并评估兼容性，以确定内容是否得到批准。 可以轻松地分析输出以识别有问题的内容，但是我们的目的是在不需要高级bash-fu技能的情况下立即提供帮助。 有很多进一步自动化的机会，包括将原型滚动到Maven插件中，以直接整合到构建中并支持其他构建系统。

该物料清单成为项目IP日志的第三方内容部分。 这具有100％准确度的额外好处，而无需背piggy式贡献问卷（CQ）之类的东西。 至少在短期内，IPzilla系统和CQ仍将是项目提交者与IP团队进行交互的主要手段，但仅限于需要调查的内容。

翻译自: https://www.javacodegeeks.com/2019/10/revising-the-eclipse-ip-policy-third-party-content.html