核心观点 - 事实收集是软件谈判中首要且最重要的任务，律师和采购专业人员应避免做出会损害自身信誉和拖延谈判的事实假设，要与实际执行或监督工作的员工基于相同知识库工作，以节省时间并达成更好协议和关系 [4][7][46] 各部分总结 软件并非静态 - 开发的软件会在开发过程中不断演变，如今要求详细最终规格再开始工作会导致产品错过市场价值，协议应聚焦于建立合作开发的流程 [9][10] - 软件在正常生命周期内会持续变化，需不断更新以适应环境变化和消除安全漏洞，协议不应基于开发会在软件生命周期结束前某点结束的假设编写 [12] 软件供应商并非所有交付软件的作者和版权所有者 - 软件供应商几乎不会是所提供软件的唯一作者和版权所有者，软件包含第三方组件并依赖相关软件 [14] - 开发者会利用模板和库进行开发，第三方组件和接口对软件运行必不可少，软件运行依赖第三方生态系统 [15][16] - 现代软件生态系统中依赖情况更复杂，供应商可能不直接交付依赖，依赖使用会影响软件售价 [18][19][20] 软件将使用一组工具进行开发 - 软件开发者使用软件工具提高开发效率，这些工具复杂且代码量常超开发交付物，了解相关事实很重要 [22] - 开发环境可能是第三方产品，也可能是特定公司的独特环境及相关技术人员 [23][24] - 工具在复杂环境中运行，交付整个开发环境不切实际，交付代码需有维护计划，源代码托管安排作用有限 [26][28] 许多最有价值的第三方组件和工具以开源许可证提供 - 开发中几乎不可能不使用开源软件，多数系统中70 - 90%的代码由开源软件构建，使用开源软件可提升竞争力 [31] - 若使用开源软件，应关注代码选择、维护和许可证合规性等问题 [32] 软件许可证可无限分类 - 软件许可证种类繁多，有开源、类似开源、非开源、商业或专有等多种类型，SPDX许可证列表涵盖许多常见许可证 [35] - 合同中关注第三方软件组件的许可证问题时，不应纠结于许可证分类，要求仅使用OSI批准的许可证可能有害 [36][38] 一些最重要且广泛使用的软件以GPL和其他Copyleft许可证提供 - 很多有价值的软件组件和工具以GPL或Copyleft许可证提供，GPL许可的软件被广泛使用，商业公司可遵守相关义务 [40][41] - 软件分发可能触发Copyleft义务，GPL并非不可行的开源许可证，若不重新分发GPL代码，要求“禁止使用GPL”条款会减少权利 [42][43] - 除非技术人员同意，否则不应要求无Copyleft软件的声明或保证，应关注代码选择、维护和许可证合规性 [44]

报告核心观点 - 许多行业依赖开源软件并将其融入研发和发展模式 开源协作带来的创新速度是关键 顶级四分位公司采用开源对创新的影响是其他四分位公司的三倍[5][6][7] - 各垂直行业因创新压力、供应链等挑战 向软件定义模式转变 依赖开源协作解决问题[12][13][14] - 各行业通过开源协作实现了降低成本、缩短上市时间、提高质量等成果 推动了行业创新[114] 各行业情况总结 电信行业 - 行业有144 + 年历史 近六年创新加速 传统网络专有、标准且设备定制 升级成本高且缺乏灵活性[16] - 向软件定义模式转变时 电信公司选择协作开展开源项目 如LF Networking（LFN） 超70%全球用户的网络基于LFN开源项目 全球贡献者六年来贡献7800万行源代码 按COCOMO估值模型需超73亿美元研发投资重现[18][20] - AT&T是行业开源先驱 2013年发布白皮书 2017年开源平台 中国移 动发起Open - O项目 双方合作推出Open Networking Automation Platform（ONAP） 服务全球70%移动用户[21][22][28] - LFN开源项目包括FD.io、OpenDaylight、OPNFV、ONAP等 提供完整网络软件栈 实现网络自动化 降低互操作性成本 未来云网络、边缘和接入网络将基于开源创新[34][37][40] 汽车行业 - 消费者对汽车软件功能需求增加 但传统研发模式导致行业碎片化 汽车代码量多 开发周期长 车内系统功能落后 供应链交易模式阻碍软件创新[44][45][47] - 2012年Linux基金会与丰田等合作推出Automotive Grade Linux（AGL） 构建通用开源软件平台 消除行业碎片化 AGL统一代码库（UCB）可作为行业标准 支持代码复用[53][54] - AGL获十一家主要汽车制造商支持 已应用于丰田、雷克萨斯、斯巴鲁、梅赛德斯 - 奔驰等车型[55] 电影行业 - 电影行业软件基础设施碎片化 超80%行业参与者使用开源软件 但缺乏协作 存在构建系统、依赖版本、代码维护和法律等问题[56][57][58] - 2018年Linux基金会与电影艺术与科学学院合作成立Academy Software Foundation（ASWF） 提供中立论坛和基础设施 采用开放治理结构[59][60] - ASWF有六个主要项目 包括OpenVDB、OpenColorIO、OpenEXR等 已用于众多电影制作 项目加入ASWF后 协作增强 贡献增加[64][71][74] 金融行业 - 金融服务行业传统技术开发封闭 存在系统重复建设问题 有开源协作的机会[76] - 2018年成立Fintech Open Source Foundation（FINOS） 2020年加入Linux基金会 已成为金融机构开源协作的可信论坛 有超30家成员 提供资源协助成员参与开源[75][77] - 金融机构开源参与度增加 实现了降低总成本、加快上市时间、提高软件质量、吸引人才、降低投资风险、简化工作流集成等好处[78][81][82] - FINOS包含多个开源项目 如FDC3、Plexus、Perspective等[85] 能源行业 - 能源行业有150年历史 能源需求增长 但能源分配低效 浪费资源 产生近一半的碳排放 电网效率低 电子损失约60% 需解决低效问题 整合可再生能源[88][89][95] - 由Linux基金会与法国电力传输机构RTE合作成立LF Energy（LFE） 使命是构建共享数字投资 转变世界与能源的关系[99][100] - LFE有8个项目 包括OperatorFabric、PowSyBl、RIAPS等 利用开源最佳实践和标准 促进电力系统数字化转型 实现能源高效利用[101][102][104] 公共卫生行业 - 因COVID - 19大流行 Linux基金会成立LF Public Health（LFPH） 其首批项目COVID Green和COVID Shield是开源的暴露通知应用 分别用于爱尔兰和加拿大[107] - LFPH通过实施者论坛提供协作服务 讨论信号强度、隐私等话题 为公共卫生当局提供中立协作论坛[109]

报告核心观点 - 开源已成为技术领域主导力量 但开源革命仍未完成 其自动化、可视化、分析和管理的工具链分散且质量参差不齐 组织和开发者都面临开源项目管理难题 Linux 基金会的 LFX 平台旨在解决这些问题 助力开源运动更好发展 [2][3][8] 各部分总结 开源世界 - 开源项目类似行星 相互影响 编程语言是基础组成 人们和组织在不同层面为项目做贡献 开源世界很多数据信息公开 可聚合构建数据层 促进创新和采用 [14][15][20] 运营开源项目的沉重负担 - 开源项目维护者除编写代码 还需处理行政、法律、安全和运营等任务 包括选择许可证、建立治理结构、进行营销等 项目发布后任务更多 企业需考虑资源投入 [21][22][29] 开源软件供应链风险 - 过去三年 开源世界的互联性成为安全漏洞关键来源 组织、企业和维护者都易受供应链上下游依赖影响 需重视供应链安全 [34][35][37] 企业大规模管理开源参与的挑战 - 领先科技公司和其他行业组织都有开源战略和 OSPO 随着开源重要性增加 企业需管理开源存在 但手动聚合信息或自建工具成本高、难度大 [39][40][42] LFX：将开源力量转化为可操作、可扩展的数据层 - Linux 基金会基于经验创建 LFX 平台 其模块化、可扩展、API 驱动 能集成现有工具 收集指标和工作流 提供全面视图 保护用户数据隐私 [45][48][52] LFX 开源供应链管理工具 - LFX 提供组织仪表盘、个人仪表盘、项目控制中心洞察等功能 其数据引擎可查询和可视化数据 支持用户自定义自动化工作流 [56][57] LFX 面向技术领导和 OSPO - LFX 的组织仪表盘为企业提供多种工具和数据分析能力 可查看员工参与、代码贡献、活动参与等情况 支持合规、内容、通信等管理 还能分析项目健康和安全评级等 [58][62][63] LFX 面向开源维护者和项目支持团队 - LFX 平台将管理开源项目的最佳实践提供给维护者和参与者 可用于管理成员、自动化任务、简化财务和法律流程、搭建技术基础设施等 [64][65][66] LFX 面向开源安全 - LFX 平台整合现有安全工具 提供依赖风险分析、安全测试覆盖、漏洞管理等功能 助力项目提升安全水平 [67] 结论：用更好的数据和工具放大开源力量 - LFX 平台将扩展更多功能 借助智能数据和集成等可克服开源运动障碍 该平台能促进交流协作、简化管理、加速开源创新 [68][69][71]

报告核心观点 - 开源软件对企业业务成功至关重要 许多专注于专有产品的公司也普遍使用和发布开源软件 这体现了商业策略和商业模式的重大变化 [2] 开源软件定义 - 开源软件指公开可访问 可修改和共享的计算机源代码 其不仅意味着代码访问 还需遵循分发 许可标准以及社区精神与协作 [11] 开源软件现状 - 开源软件已在各商业领域成为主流 其协作模式从开发者个人协作发展到大型竞争公司协作 以解决共同问题和开发共享解决方案 [13] - 近年来 单一行业内竞争对手的协作趋势催生了特定行业的开源软件项目和基金会 用于生产通用软件 [14] 开源软件的机会和好处 - 开源软件具有成本降低 上市速度快 协作市场优势 功能差异化 安全增强 效率提高和创新加速等商业优势 [18] - 使用并贡献开源软件项目的公司在开发者招聘和留用方面有显著改善 还能从外部贡献中受益 降低成本和风险 加快开发速度 [19] - 开源软件社区在推动标准化 商品化和采用率方面发挥重要作用 有助于代码和项目稳定 集成便利和项目成熟 并创造新的商业模式机会 [22] 开源软件的风险及应对 - 使用开源软件需承担责任 主要是遵守许可条款 积极贡献 维护和共享代码及相关工作 重度用户可能需提供项目资金 [24][25] - 开源软件社区存在知识产权问题 公司需了解相关规则和条件 以避免问题 [26] - 开源软件安全性通常较高 但代码库不断变化 需定期更新 且因其受欢迎程度易成为攻击目标 应加强安全保障 [27] - 应将回馈开源软件项目和社区纳入整体计划 支持内部开发者参与外部项目 投入时间 精力 指导和资金 确保项目成功 [28] 开源软件案例分析 欧洲汽车行业 - 汽车制造业向软件公司转型 开源软件成为加速发展的途径 因其已有大量可用代码且可复用 [37][38] - 开源软件团队的协作性质有助于快速解决共同问题 缩短上市时间 如Automotive Grade Linux和Eclipse Kuksa等项目 [40][41] - 开源软件降低了进入壁垒 使竞争激烈的行业参与者能够协作并获利 且避免了单一供应商依赖 目前汽车软件栈50 - 70%源自开源 [42][44] - 沃尔沃旗下Polestar选择开源软件Android以减少开发时间和成本 满足客户期望 HERE Technologies利用开源软件开发产品并回馈社区 新业务前景广阔 [45][48] 欧洲智慧城市倡议 - 欧洲在智慧城市发展方面处于世界领先地位 如斯德哥尔摩因GrowSmarter项目获2019年智慧城市奖 巴塞罗那将70%的新开发预算投入自由软件开发 [50][51] - 巴塞罗那等欧洲城市通过使用和推广自由软件和开放技术 促进政府间协作 避免供应商锁定 并分享最佳实践 开展跨城市和国家的协作 [51][52] - 巴黎开发的开源软件平台Lutèce用于提供政府服务 并已在其他地区得到应用 [54]

报告核心观点 - 容器技术改变软件部署、分发和执行方式 Docker 简化容器技术但带来法律合规复杂性 文章聚焦分析合规挑战及应对方法 [9][11][12] 历史视角 - 容器历史可追溯到 20 世纪 60 年代 IBM 大型机 Unix 系统中 chroot 实现部分隔离 FreeBSD 改进为 jails Linux 容器进一步发展 Docker 是 Linux 容器主导技术 [19][22][24] 相关技术 - 硬件虚拟化软件可模拟完整系统 如 VMware、QEMU 等 超管理器控制和管理虚拟机启动 如 Xen Project Docker 管理 Linux 容器 与超管理器不同 这些技术可混合使用 [25][28][29] Docker 容器技术 - Docker 简化容器化应用创建和部署 容器化应用是自包含环境 不同容器可基于不同发行版 有优缺点 [31][32] - 容器是镜像运行实例 镜像存储软件 可在仓库复用 [33][34][37] - 镜像由多层堆叠 可共享层 修改存储为新层 容器实例含运行时数据 存于数据层 [38][39][43] 部署流程 - 部署 Docker 容器步骤为创建或下载镜像 创建容器实例 运行容器 [44][47] - 创建或下载镜像方式有从无到有构建 加载完整镜像 用 Dockerfile 组装 常用后两种 [45][48] - Dockerfile 含指令 描述如何组装镜像 可据此创建和加载镜像 [49][51] - 可搜索和下载 Docker 镜像 用 docker search 和 docker pull 命令 [58][60][61] - 用 docker create 命令创建容器 输出容器标识符 [63][64][66] - 用 docker start 命令运行容器 日志用 docker logs 查看 [67] 仓库与注册中心 - Docker 镜像可从仓库获取 除 docker.io 还有 quay.io 等 社区和公司有公共或私有仓库 [69] - 可配置仓库搜索 不同系统和公司配置不同 [70] - 拉取镜像时 已有层不重复下载 元数据必下载 [71] - 可用 docker push 命令发布镜像 可能上传全量或唯一层 [73] 磁盘表示 - Docker 镜像可分析 了解合规影响 安装位置因系统而异 [74][75] - 以 hello - world 为例 镜像下载后 信息存于 repositories.json 等文件 可据此找到层信息和内容 [76][78][82] - 完整 Docker 镜像可用 docker save 导出为 tar 归档 含层目录和元数据文件 [88] 合规问题 - 合规与其他软件分发类似 但因镜像组装不可重现等因素更复杂 [90] - 需考虑分发软件内容 包括全量镜像和 Dockerfile 分发情况 全量镜像需检查所有层 [91][93][98] - 分发 Dockerfile 时 软件可能来自多方 责任界定复杂 且存在许可证误解问题 [100][104][107] - Dockerfile 许可证与容器内软件独立 [112] - 分发镜像需确保所有层合规 [113][114] - 收集和发布源代码存在问题 因镜像创建不可重现等因素 尚无解决方案 [116][118] 合规清单 - 需确认是否有软件分发 若仅分发 Dockerfile 且未参与仓库相关操作 可能仅分发 Dockerfile 本身 [120] - 分析所有层软件确定分发内容和许可证 [121] - 根据分发方式确定责任方 [122][123] - 明确分发软件主体 各方应制定合规政策和流程 [125] 现有工具与研究 - Tern 项目工具可分析 Docker 容器镜像内包信息 [127] 结论 - Docker 简化软件部署 但带来法律挑战 解决方案不明 应关注开发自动收集和发布源代码的工具和流程 [129][131][132]

报告核心观点 - 软件成分分析（SCA）工具可帮助软件开发团队从许可合规性和安全漏洞角度跟踪和分析引入项目的开源代码 但缺乏标准方法比较和评估此类工具 本文旨在推荐评估多个SCA工具的一系列比较指标 [3] 评估指标 知识库 - 衡量知识库大小 包括开源项目数量和跟踪文件数量 列出主要跟踪的存储库、生态系统、源语言 区分包级别检测和特定语言支持 明确知识库更新频率、客户请求添加到知识库的时间和流程 [7] 检测能力 - 具备校正/配置分析器的能力 说明检测方法 处理部分代码片段 提供校正和验证结果的选项 支持对结果进行排名 能够自动识别代码的来源和许可 减少误报 支持多种类型的分析 明确支持的语言及分析类型 [10] 易用性 - 具有直观的设计和用户界面 提供本地客户端、浏览器插件或移动客户端 运行所需培训极少或无需培训 但提供结果检查和评估的培训 [11] 操作能力 - 提高源代码扫描速度 确保工具可用于并购活动且无使用模式的许可限制 支持不同的审计模型 具备编程语言无关性 能够在组织内复用扫描说明 与构建系统无关 提供API和命令行界面（CLI） [13] 集成能力 - 支持用户界面集成 能够将组织的合规政策集成到工具中 并根据声明的政策和规则标记代码 [14] 安全漏洞数据库 - 关注漏洞数据库的大小、更新频率和漏洞信息来源 了解工具提供商为验证漏洞警报所做的额外研究 评估漏洞检测的精度、召回率和上下文漏洞优先级排序能力 [14] 高级漏洞发现 - 支持高级漏洞发现 能够识别复制到新组件中的漏洞代码 [15] 相关成本 - 考虑基础设施成本、运营成本、年度许可成本、与现有工程/IT工具和基础设施集成的初始成本、导出项目和其他信息的能力、锁定成本以及工程定制成本 [15] 支持的部署模型 - 支持现场部署、云部署或混合部署 明确代码和项目信息离开网络的情况 [16] 报告能力 - 能够生成所需的合规通知 明确通知的依据和包含的内容 支持多种报告格式和开放标准格式 [16] 相关项目 - 开放合规计划 为开发者和律师提供开源合规工具和最佳实践的学习起点 [21] - ACT（自动化合规工具） 旨在改进检测和遵守开源许可证的软件工具 提高开源合规工具的互操作性 [21] - OpenChain 定义组织开源合规计划的关键要求 建立一致性计划 使公司能够自我认证 [21] - SPDX（软件包数据交换） 以标准化、人机可读的格式传达软件物料清单信息 促进组织间信息沟通和合规工具的互操作性 [22] - 面向软件开发人员的开源许可基础培训 为开发者提供免费的在线开源许可和合规培训 [22] - 白皮书和博客文章 定期发布关于解决日常实践中出现的开源法律问题的内容 [22]

报告核心观点 - 开源并购评估清单可评估组织开源实践 需坦诚评估开源项目优缺点 组织应根据自身情况调整合规方法 [7][9][10] 评估类别 开源软件发现 - 产品开发周期早期进行开源软件发现 系统识别需合规分析的软件和材料 [13][17] - 第三方供应商披露交付物中的开源软件 组织审查披露内容准确性和完整性 [19] - 组织定期审计开源软件使用情况 准备开源物料清单 [19] 开源软件使用的审查和批准 - 组织审查所有产品和服务中使用的开源软件 定义触发重新批准的情况 [21] - 采用系统方法识别代码基线变化 有效进行增量合规 [21] - 开源审查委员会审查和批准开源软件使用 定义相关程序并记录审议情况 [23] 义务履行 - 组织验证第三方供应商提供满足开源许可义务的信息 定义触发许可义务的软件传输模式 [27] - 组织以一致和规范的方式履行义务 提供许可证文本和义务要求的存储库 [27] - 开发团队按要求提供完整源代码 进行验证活动确保源代码可构建和符合要求 [29] 社区贡献 - 社区贡献按定义流程审查和批准 确定员工贡献是否与工作相关 [34] - 明确计划贡献的版权归属 跟踪公司对开源社区的贡献 [34] 政策 - 制定政策使公司能够在产品和服务中使用开源软件 由高级管理人员倡导并传达给整个公司 [35] - 政策涵盖合规行动的角色和职责、开源软件使用的审查和批准流程等内容 [38] 合规人员配置 - 提供有技能和知识的人员参与合规工作 明确合规职能的工作描述 [38] - 从跨职能部门抽调人员参与合规 提供培训和学习机会 [38] 业务流程调整 - 估算合规工作的总工作量和持续时间 制定人员配置计划以满足产品发布周期 [41] - 修改现有业务流程以纳入开源合规活动 进行流程失效模式与影响分析 [42] 培训 - 为接触开源软件的人员提供基本培训 定义培训对象并记录培训情况 [46] - 提供开源相关主题的额外培训 鼓励内部开源用户和贡献者社区的发展 [46] 合规流程管理 - 明确实现组织级开源合规的责任 合规支持团队可获取相关专业资源 [48] - 应用项目管理原则管理合规项目和团队活动 设定合规目标和优先级 [48] 开源软件清单 - 跟踪产品合规活动的进度 系统跟踪开源问题的解决情况 [52] - 维护产品和服务中开源内容的准确记录 开源审查委员会维护审查记录 [52] 自动化和工具支持 - 评估合规流程以确定自动化和工具支持的机会 定期调查相关工具 [56] - 采用系统方法评估工具 计划和执行工具获取或开发项目 [56] 验证 - 使用批准的方法确定产品中开源软件的内容和需合规分析的文件 跟踪开源问题至解决 [59] - 合规团队按定义程序进行验证活动 确保产品发布时满足开源许可义务 [60] 流程遵守审计 - 进行流程遵守审计以确定组织是否遵循定义的合规流程 评估合规结果 [64] - 审计确定组织是否维护准确的开源软件内容和合规活动记录 [64] 收购目标公司的审计准备 了解代码内容 - 维护完整的软件清单 包括软件组件的来源和许可信息 具备识别和跟踪开源组件的流程 [66] - 制定开源合规政策和详细流程 输出开源物料清单 [67][70] - 大型企业的开源合规团队是跨学科团队 小型公司或初创企业可由工程经理和法律顾问组成 [71][73] - 提供开源和合规培训 提高员工对开源政策和策略的认识 [74] - 使用工具自动化源代码审计、发现开源代码和识别许可证 [75] 保持合规 - 跟踪所有开源软件的使用 编制最终的开源物料清单 履行开源许可义务 [76] - 每次发布软件更新时重复合规流程 及时认真响应合规查询 [79] 使用最新版本以确保安全 - 利用合规计划查找并替换不安全的开源组件版本 升级时确保组件许可证不变 [77][78] - 企业开发者应订阅并监控相关邮件列表 关注安全漏洞和修复信息 [78] 评估合规工作 - 参与OpenChain项目并获得“OpenChain Conformant”状态 确认组织有开源软件合规流程或政策 [79] 收购公司的审计准备 选择合适的审计方法 - 传统审计模型由第三方审计公司的合规审计员远程或现场扫描源代码 按流程执行并交付报告 [82][87] - 盲审计模型由FOSSID AB利用专有技术在不查看源代码的情况下进行审计 提供高度保密性 [89] - 自行审计方法使收购方或目标公司可使用开源合规云工具自行扫描 适合有内部经验的公司 [92] 明确关注重点 - 确定关键的许可证和用例 关注相关信息 [97] 提出正确问题 - 利用清单中的问题与目标公司沟通 澄清或确认合规相关问题 [98] 确定交易前需解决的事项 - 识别开源审计中发现的不可接受的许可证或合规实践 要求目标公司解决 [99][100] 制定收购后合规改进计划 - 收购大公司收购小初创企业时 帮助目标公司建立正式合规政策和流程 提供培训和支持 [101] 推荐的合规相关开发实践 推荐实践 - 使用开源软件前请求批准 链接代码时遵循相关规定 [104] - 更新修改日志 记录代码与开源软件的接口信息 [104] - 保存开源软件包的许可证信息 升级时验证许可证是否变化 [104] 避免常见错误 - 不删除或干扰现有许可或版权信息 不重命名开源组件 [107] - 未经批准不复制粘贴代码 不将开源或第三方代码提交到内部产品源代码树 [107] - 未经批准不合并不同许可证的源代码 不与公司外部人员讨论合规实践 [107] 结论 - 开源尽职调查是并购交易中重要的一部分 若双方做好准备并与高效的合规服务提供商合作 可快速完成 [108] - 目标公司应保持良好的开源合规实践 收购公司应明确关注重点并具备解决问题的能力 [109] - 开源合规是持续过程 公司应投资建设和改进开源合规计划 [110]

报告核心观点 - 开源发展能实现跨边界协作 透明公开且跨越组织和地域界限 促使全球人员和组织共同成就伟大开源技术 开源发展是全球性活动 涉及软件跨国界分享 一些国家出口管制法规可能要求开源项目采取额外措施确保遵守当地法律 美国《出口管制条例》一般不会对开源模式造成影响 公开发布的开源技术通常不受制于该条例 [4][5][8] 美国《出口管制条例》（EAR）介绍 - EAR是美国联邦政府限制出口的主要条例 由美国商务部下的产业与安全局发布并定期修订 适用于所有“受制于EAR”的物品 管制其出口、再出口或境内转让 EAR下“出口”定义宽泛 包括多种行为 但公开发布给全世界的开源技术通常不受制于EAR [10][11][14] 将EAR应用于开源软件 - EAR界定可能受出口限制事项范围 并为不同物品提供ECCN编码 有些物品受制于EAR 需满足一定条件才能出口 开源技术优势在于EAR明确豁免大多数开源软件和技术 公开发布且无传播限制的开源技术被视为“已发布” 不受EAR管辖 欧盟也有类似可公开获取软件和技术不受出口管制的政策 与EAR范围内事项无关的活动不受EAR限制 若项目含非标准加密技术 开源社区可能需额外措施满足“已发布”要求 [16][17][26] 实施非标准加密技术进行加密 - 2021年后EAR的电子邮件通知要求仅适用于实施“非标准加密”的可公开获取加密软件 “非标准加密”指结合或使用专有或未公布加密功能 软件开发者关注的加密技术是EAR重要内容 EAR管理特定加密软件和技术出口 “加密软件”定义广泛 具备标准加密功能的软件常见ECCN类别是5D002 加密软件若受制于EAR 出口到加拿大以外国家需确认例外适用或获取出口许可证 但首先要确定其是否在EAR管辖范围内 [28][29][30] - 属于ECCN 5D002的加密源代码满足“可公开获取”且实施标准加密技术或实施非标准加密技术并发送邮件通知两个条件 则不受EAR管辖 相应目标代码也不受EAR管辖 开源软件项目中发现非标准加密罕见 使用此类加密应咨询法律顾问 [32][33] - Linux基金会项目源代码包括加密软件均可公开获取 多数为标准加密 且提供邮件通知并公开通知内容 所以其项目源代码及对应目标代码不受EAR加密限制 但修改项目代码或其衍生产品的下游再分销商在源码未公开时 仍需评估是否符合EAR规定 [36][38] 神经网络驱动的地理空间分析训练 - 2020年1月6日BIS宣布的新EAR规定 对专门训练深度卷积神经网络自动分析地理空间图像和点云的地理空间图像软件进行管控 “点云”指坐标系统界定的数据点集合 规定虽立即生效但可能发展变化 可公开获取的软件如开源软件不受EAR管辖 [40][42] - 新规定适用范围狭窄 软件需同时具备提供图形用户界面识别物体、对阳性样本进行归一化、训练深度卷积神经网络、利用训练好的网络识别物体等功能才受管辖 不具备所有功能的软件不受新规定管辖 现有或新创建的可公开获取开源项目不受EAR管辖 [41][42][46] 开源软件社区的最佳实践 - 公开化和公众化 社区应保持技术交流开放公开 公开社区决策和结果 安全问题信息交换可在修复后公开 公开交流虽有时不适但利于建立透明信任社区 [49][50][53] - 使用标准加密法加密 避免在开源项目中使用未公开的非标准加密技术 若项目提供ECCN 5D002项下加密功能并实施非标准加密 需按EAR要求向BIS和NSA发送通知 还可采取公开通知、附加联系方式和负责方名称、建立证据保留系统等措施 [56][58][62] - 确保相应的加密源代码是能够公开获取的 以目标代码形式公开分享加密软件时 要确保源代码可公开获取 项目维护者应审查加密功能分发形式 必要时确保对应源代码公开 除人工审核外 扫描工具可辅助识别大型代码库中的加密软件 [63][64][66]

报告核心观点 - 提出向Linux基金会构建并运营名为信任与安全倡议（TSI）的项目的提案，及其他需投资和帮助的安全问题的建议 [4] - TSI包含八项最佳实践及认证计划，旨在提升开源项目的安全性，且该提案基于此前行业大规模实施软件安全的工作，借鉴微软的可信计算（TWC）和安全开发生命周期（SDL），并针对开源社区和现代软件开发团队进行调整 [5][6] - 实施TSI最佳实践虽不能完全避免安全问题，但能提升软件安全性和用户信心，且该方案会根据反馈和采用情况不断更新和完善 [8] 各部分总结 概述 - 软件安全面临挑战，但有解决的希望，此前已有实现软件安全的经验，且可根据团队文化匹配技术和工具，减少对开发的影响 [11][12] - 文档分为八项最佳实践、认证计划和其他需投资和帮助的安全问题三个主要部分，各部分采用先说明意图和目标，再以表格形式描述具体实践的结构，且该方案可灵活实施 [13][14] 八项最佳实践 角色与职责 - 明确团队安全计划中各角色的职责，缺乏明确角色和职责是导致安全问题的重要原因 [22] - 包括指定首席安全官、首席安全工程师、首席安全架构师等角色，确保每个人了解自己的安全职责，并参加相关培训，大型项目可设立专职安全团队 [23][25] 安全策略 - 定义团队安全计划的内容，组织应发布安全策略，包括组织级和项目级的策略，并确保相关人员阅读和确认 [27][28] 了解贡献者 - 目的是让组织信任贡献者，消费者信任软件，可通过验证贡献者身份、使用强认证、基于角色的访问控制、实施贡献者许可协议和公布贡献者列表等措施实现 [30][31][33] 软件供应链 - 软件供应链攻击常见，需锁定工具链并验证其中的内容，如仅接受拉取请求、使用受保护分支、数字签名提交、立即处理安全问题等 [35][36] 技术安全指南 - 技术安全指南可缩小安全解决方案范围，Linux基金会可维护核心技术指南并允许组织扩展和定制，包括应用安全、操作系统安全配置、云安全配置等指南 [42][43] 安全剧本 - 定义特定安全流程的执行方式，如事件响应和漏洞管理流程，Linux基金会可开发和维护集中的剧本并允许组织定制 [47][48] 安全测试 - 描述多种安全测试技术，优先推荐自动化测试，也包括一些手动测试，如安全检查、威胁建模、静态分析安全测试等 [50][51] 安全发布和更新 - 对最终用户很重要，组织应定义安全发布标准，对发布进行数字签名，发布安全构建证书，公布不安全版本信息并实施自动安全更新系统 [58][59] 认证计划 - 可基于云安全联盟（CSA）的STAR计划模式构建和运营认证计划，该计划对软件生产者、消费者和安全咨询行业都有好处，Linux基金会可提供相关资源和优惠 [63][64][66] 其他需投资和帮助的安全问题 安全构建证书 - 行业面临难以了解产品安全性的问题，建议Linux基金会构建规范和工具，生成可附加到软件发布的安全构建证书，以提高开源软件和互联网的安全质量 [69][70] 缺乏优秀的开源安全测试工具 - 缺乏可信的免费开源安全测试工具阻碍了安全测试的广泛应用，建议Linux基金会投资开发，可参考一些有前景的项目，并推荐Jacob West领导该工作 [73][74][77] 开源软件包分发对互联网构成风险 - 开源软件包分发存在问题，建议Linux基金会开发和运营中央库分发系统，并内置适当的安全功能 [79] 漏洞披露存在问题 - 通用漏洞披露（CVE）系统存在格式、披露流程、规模和商业冲突等问题，需要重新思考适用于DevOps和开源时代的漏洞披露方式 [82][83][85]

报告行业投资评级 未提及相关内容 报告的核心观点 - 报告研究欧盟私营企业政治参与模式，发现企业政治参与模式差异大，政治影响力得分高的企业绩效更好，且存在政治竞争现象 [1] - 企业政治参与形式多样，包括加入商业协会和建立政治联系等，不同形式的参与受多种因素影响，且对企业绩效有不同作用 [1][23] - 企业政治参与行为受同行影响，政治影响力高的企业比同行表现更优，未来企业政治参与的复杂性可能持续 [64][65] 根据相关目录分别进行总结 欧盟是分析企业集体和政治行动参与的关键焦点 - 欧盟许多国家商业协会、贸易团体和工会等参与政治行动历史悠久，私营企业政治参与持续存在，公私利益在多层次复杂互动 [2][3] - 虽有研究探索企业集体参与公共产品及利用政治联系的方式，但不清楚企业如何结合现有政治参与手段，报告用WBES数据探索欧盟27国企业政治参与和影响模式 [4] 商业协会成员差异主要由跨国差异驱动 - 欧洲政治组织历史悠久且多样，不同国家政治制度、文化和价值观使商业协会发展轨迹不同，现代欧盟结构为商业组织影响政治提供更多途径 [9] - 欧盟27国超半数私营企业属于商业或贸易协会，但各国差异大，部分国家成员率超75%，部分国家低于25%，且成员率在国家间差异大于次国家区域 [10][11][12] 企业对商业协会服务的重视程度取决于成员性质 - 商业协会可为成员提供游说、信息、网络建设和认证等服务，企业加入集体协会取决于边际收益与成本，克服搭便车问题可提高非成员成本或强制成员资格 [13][15] - 多数企业认为商业协会服务“有用”，但克罗地亚、匈牙利和希腊等强制成员制国家多数企业认为服务无用，“公法”国家成员企业认为服务有用的比例低于“私法”国家 [16][18][22] 不同地区的各类企业保持政治联系 - 商业协会成员是欧盟私营企业常见政治参与形式，但存在搭便车和委托代理问题，企业可能寻求更直接政治参与，如利用政治联系，政治联系能为企业带来物质利益 [23][26][27] - WBES调查显示，欧盟4%企业有政治联系，低于商业协会成员率，不同国家和地区政治联系率不同，可能与公私部门工资吸引力有关 [32][33][34] 政治影响力也因政治和商业环境而异 - Francis和Kubinec开发的“政治影响力”指数综合多种企业与官员互动因素，可分析政治参与方式的替代或互补关系，发现政治联系与商业协会成员互补，与腐败经历替代 [37][38][39] - 欧盟27国政治影响力指数差异大，部分国家地区间差异明显，指数高意味着企业需政治参与获更多利益，制度质量弱的地区政治活动收益可能更高 [40][43] 政治影响力在企业绩效方面似乎有明显回报 - 商业协会成员与企业销售和劳动生产率正相关，政治联系与企业固定资产投资正相关，“政治影响力”得分与企业多项绩效指标显著相关 [44][47][49] - 政治影响力高的企业更易受政治活动影响，但并非因贿赂请求增加，可能是对政治交换更敏感或因环境需要而参与政治 [49][50][55] 企业政治参与行为受同行影响 - 企业商业协会成员行为与同行关系不显著，但同行政治影响力高时，企业更可能建立政治联系和提高政治影响力指数 [62][63][64] - 企业政治影响力高于同行时，其销售、规模、生产率和投资等绩效指标表现更好 [64] 私营部门政治参与的复杂性可能持续 - 欧洲政治制度复杂多样，私营企业集体和个体政治行动将继续，商业协会参与历史悠久，但强制成员制国家企业参与度或对服务认可度低 [65][66] - 许多企业会寻求多种政治参与形式，政治影响力在制度环境弱的地区回报明显，同行政治参与会引发类似行为，政策制定受制度环境、企业对集体行动的重视和回报影响 [67]