报告行业投资评级 未提及相关内容 报告的核心观点 - 尽管文盲率高，但受访者能有效理解音频计算机辅助访谈问卷，且先通过音频计算机辅助访谈私下回答问题，能使后续面对面访谈中亲密伴侣暴力的披露率显著提高41% - 57%，表明从私下提问开始能增强敏感话题报告的开放性和一致性，是改善亲密伴侣暴力数据收集的可行有效方法 [3] - 对巴基斯坦旁遮普省莱亚赫地区6135名农村妇女的两项测量实验结果显示，音频计算机辅助访谈调查问题的理解度高，且先私下回答敏感问题再进行面对面访谈会增加后续亲密伴侣暴力的披露 [31] 根据相关目录分别进行总结 1. 引言 - 收集亲密伴侣暴力准确数据困难，面对面访谈缺乏匿名性会抑制披露，自我完成调查对文盲受访者不实用，且低收入或农村环境存在隐私和报复风险，但确保准确披露对预防和应对亲密伴侣暴力至关重要 [9] - 为解决这些问题，研究调整现有测量工具以适应农村贫困环境，并开展两项实验，一是评估受访者对调整后工具问题的理解，二是比较面对面访谈和音频计算机辅助访谈对亲密伴侣暴力报告的影响 [10] - 实验于2023年2 - 3月进行，涉及巴基斯坦旁遮普省莱亚赫地区6000多名农村贫困家庭已婚妇女，受访者大多为文盲，使用人口与健康调查标准亲密伴侣暴力模块的问题 [14] 2. 修改音频计算机辅助访谈体验 - 此前研究表明农村利比里亚和马拉维妇女使用音频计算机辅助访谈存在理解问题，可能高估亲密伴侣暴力发生率 [17] - 为使音频计算机辅助访谈对受访者更友好，研究与当地调查员合作开发图像，让受访者更易将图像与李克特量表上基于频率的答案选项关联，并在音频计算机辅助访谈模块开始时添加非敏感问题，以保护受访者隐私并减少其他家庭成员的不信任 [18][19] 3. 实验1：受访者是否理解音频计算机辅助访谈？ - 为测试视觉回答选项的修改是否提高女性对音频计算机辅助访谈的理解和使用，进行两项测量实验，一是随机排列频率答案选项顺序，结果显示不同顺序下暴力频率无显著差异，表明受访者能准确理解图像与答案选择的映射 [20][21] - 二是用面对面和音频计算机辅助访谈两种方式向女性询问关于食物消费的通用（非亲密伴侣暴力）问题，发现两种方式的回答一致性很高，进一步证明受访者理解如何使用音频计算机辅助访谈 [23] 4. 实验2：使用音频计算机辅助访谈回答敏感问题是否会改变面对面披露情况？ - 研究同一受访者通过面对面或音频计算机辅助访谈回答暴力经历问题是否影响亲密伴侣暴力报告率，选择两个问题进行实验，一半受访者先面对面后音频计算机辅助访谈，另一半反之 [24][25] - 结果显示，先通过音频计算机辅助访谈回答问题的受访者，面对面报告的暴力频率和发生率显著更高，如报告的耳光频率高57%，割伤频率高47%，报告耳光发生率的可能性高3.2个百分点（52%），报告割伤发生率的可能性高1.6个百分点（41%），表明受访者先私下回答后可能更愿意向调查员披露敏感信息 [26] 5. 结论 - 对巴基斯坦旁遮普省农村6135名妇女的两项测量实验表明，尽管文盲率高，但受访者对音频计算机辅助访谈调查问题理解度高，且先私下回答敏感问题再进行面对面访谈会使亲密伴侣暴力的后续披露显著增加41% - 57% [31]

报告核心观点 - 企业级开源软件改变组织开发和交付产品的方式 企业需制定开源战略 从被动应对转向主动引领 以充分利用开源软件的优势并规避风险[7][8] 根据相关目录总结 为什么选择开源 - 开源软件可共享开发 降低研发成本 加速产品开发和上市 还能助力企业引领行业 吸引顶尖人才[13][14] - 软件是各行业的关键价值因素 各行业对开源软件的依赖度在20% - 85%或更高[16][17] - 开源软件支持多种商业模式 包括构建开源、基于开源构建、为开源构建和在开源基础上构建[20][22][24] - 企业很难不使用开源软件来构建产品 参与战略开源项目有助于提升企业利润和加快上市时间[27] - 开源软件可让企业专注于软件栈的高层差异化 为消费者提供独特价值[28][29] - 开源软件可通过直接和间接方式促进产品开发 直接方式包括满足研发和产品团队的开源开发请求等 间接方式包括稳定上游代码、参与内部政策讨论等[32][37] - 开源研发是企业创新管道的一部分 可与多种实践结合 发挥更大作用[41] 二十年企业开源经验教训 - 识别对开源软件的依赖 关注多业务部门使用的软件或合规风险高的软件 并专注于对公司战略和产品有益的上游项目[47][48] - 识别开源技能组合 从社区招聘关键开发者 招聘时需考虑技术领域专业知识、开源方法和经验等因素[51][53] - 制定开源战略需考虑目标开源项目、项目社区、内部治理和企业文化等关键要求 并回答开源战略如何帮助实现企业总体目标、知识产权战略和抓住独特机会等问题[54][55][58] - 开源软件有消费、参与、贡献和领导四种主要战略 企业需确定当前和目标位置 并规划实现路径[63][64][68] - 实施开源基础设施 包括支持社区参与、开源贡献、开源合规和开源使用的四个关键支柱[82] - 加入Linux基金会合规倡议 如OpenChain和SPDX 以支持开源合规实践[101] - 聘请或提拔开源团队的领导者 该领导者需具备深厚的工程背景、对开源许可证的理解等特质[107][110] - 正式确定开源职业发展路径 调整绩效奖金以包含开源开发工作目标 并允许开源开发者远程工作[108][112] - 创建或外包开源培训 包括技术培训和合规培训 以提高员工对开源政策和战略的认识[113][114] - 创建有意义的指标来跟踪进度 如提交或提交的补丁数量、补丁类型、补丁接受率等[118][119] - 与开源基金会建立关系 选择与产品或利益相关的基金会 以扩大在开源社区的影响力[130] - 制定计划以开源许可证发布专有源代码 可使用清单和模板指导代码发布过程[131] - 鼓励内部协作 与使用相同开源项目的业务部门合作 可采取提供培训、开展研讨会等形式[134][135] - 提供灵活的IT基础设施 支持开源开发者与开源项目的沟通和协作 并与外部工具相匹配[135][137] - 举办开源活动 支持开发者参加开源会议和活动 以建立人际关系、参与技术讨论和提高外部知名度[138][140] - 与大学合作开展开源研发项目 这对企业和大学都有益 可培养和吸引新人才[141][142] - 探索内部项目的内源实践 借鉴开源开发方法 促进内部协作和创新[143] - 采用开源原则可带来更快的发布节奏、更高的源代码质量等好处 实践中需开放源代码库 并建立代码管理团队[144][147] - 企业重要的开源工作流实践包括可见性、分叉、拉取/合并请求、同行评审等[149][152] - 加入TODO Group 该组织为企业提供开源项目办公室的指南和最佳实践[161] - 更新并购实践 确保合规计划提供必要的披露和陈述 并在并购前评估源代码的合规性[162][163] - 更新外包开发协议 确保协议反映开源合规程序 并对收到的源代码进行合规审查[164] 面临的挑战 - 开源项目面临文化、流程和工具三个方面的挑战 文化方面需缩小传统软件开发实践与开源开发要求的差距 流程方面需适应开源开发的动态性和合规要求 工具方面需构建与开源开发模型兼容的工具[167][168][173] 结论 - 掌握开源需要涵盖消费、参与、贡献和领导的强大战略 并在每个阶段进行增量努力和投资 遵循书中的步骤和原则 企业将在开源领域取得进展[179]

报告核心观点 - 《Practical GPL Compliance》是面向初创企业、小企业和工程师的GPL合规指南 旨在提供实用信息解决常见问题 助力合规团队高效处理开源事务 推动各规模组织解决开源合规问题 [11][234][235] 根据相关目录分别总结 第1章：方法 - **背景**：聚焦GPL合规工程 GPLv2是最常用版本 合规工作主要围绕实体产品和固件下载展开 [24][25] - **合规要求**：GPLv2要求分发时提供许可证副本 分发二进制代码时提供对应源代码访问途径 [28] - **合规目标**：确保产品附带完整对应源代码或提供书面供应提议 确保许可证副本和完整对应源代码可用 [29][30] - **工具包**：默认工具为Linux系统及自带工具 分析二进制有BAT、binwalk等工具 分析源代码可用FOSSology等工具 [40][42][47] - **二进制文件分析**：“二进制”含义多样 分析可借助BAT或binwalk 但部分二进制文件因混淆或加密无法分析 [49][50][51] - **源代码分析与重建**：需查找问题二进制文件、重建源代码并查找许可错误代码 重建要准确描述构建环境和提供完整指令 并验证结果 [55][67][77] 第2章：常见陷阱 - **工具链**：工具链常不合规 如GCC和GNU binutils以二进制形式提供却无源代码或供应提议 且嵌入式Linux需提供完整工具链源以重建二进制 [94][95][97] - **安卓和嵌入式设备**：安卓预构建工具可能缺少对应源代码或书面提议 安卓部分工具和程序存在许可证文件缺失或错误问题 [99][103] - **“树外”Linux内核模块**：需查明其许可证和对应源代码情况 可通过modinfo等工具提取相关信息 [107][108][109] - **救援模式/安装模式系统**：嵌入式Linux设备的救援分区常被遗忘 需确保所有Linux系统都有完整对应源代码 [114] - **引导加载程序**：GPL许可的引导加载程序易被忽视 应提供其源代码 [117] - **缺失构建系统**：只发布源代码目录而不包含构建系统会导致源代码不完整 无法成功重建二进制 [119] - **BusyBox配置文件错误或缺失**：BusyBox配置文件是完整对应源代码的必要部分 常见问题有缺失、错误或多个实例只有一个配置文件 [121] - **Linux内核配置文件错误或缺失**：类似BusyBox 内核配置文件也常缺失或错误 需查明实际使用的配置 [126] - **固件和源代码存档文件名未包含版本号**：文件名无版本和设备名易出错 应使用包含设备名、固件版本等信息的命名约定 [133] 第3章：软件发布场景 - **设备上的软件/离线分发**：可随设备提供完整对应源代码或添加书面供应提议 各有优缺点 建议两者结合 [138][139][141] - **网站手动下载**：有提供源代码、书面提议、单独下载三种选择 与离线分发优缺点类似 但更易纠错 [143][144] - **自动/空中更新**：因源文件大、设备空间有限等问题 实用方案是包含书面提议 并需解决版权和许可文本交付问题 [146][147][148] - **现场工程师应用更新**：建议工程师携带CD/DVD并在更新后交给用户 [149] 第4章：软件购买场景 - **上下文**：产品推向市场的公司对许可证合规负责 供应链各方应合作预防合规问题 [152][153] - **SoC供应商的供应链解决方案**：选择标准SDK、积极参与上游项目、让第三方检查审计许可证合规性 [154] - **ODM的供应链解决方案**：与使用标准SDK或芯片组受标准SDK良好支持的SoC供应商合作等 [161] - **其他方的供应链解决方案**：与开源利益相关者合作 选择使用标准SDK的ODM 明确要求使用认证/审计的SDK等 [164][166] 第5章：构建FOSS代码中心 - **背景**：公司常设FOSS代码中心 虽能满足用户需求 但不能替代传统合规方法 [171][172][173] - **FOSS代码中心作为一项要求**：部分公司将其作为事后补充 网站更新时易遗漏 可能导致不合规 [175] - **保持固件和源代码在一起**：建议将固件和源代码下载放在一起或在固件下载页面提供对应源代码位置参考 [177] 第6章：跟踪任务和流程 - **检查表**：正确使用检查表可有效管理GPL合规任务 小组织通用检查表包括发现FOSS、提供培训等步骤 也可制定特定检查表 [180][181][183] - **流程图**：使用流程图可管理GPL合规流程 如Flowchart 0等示例流程图可提供参考 [187][190][191] 附录 - **附录1：开放合规计划**：介绍其他开源合规出版物 提供自我评估检查表、通用FOSS政策、批准请求表单等合规模板 [213][219][221] - **附录2：合规标准**：Linux基金会项目推动行业制定合规标准 如OpenChain、SPDX规范等 [224][225] - **附录3：专业网络**：Linux基金会主办专业网络 帮助合规专业人员交流合作 如TODO Group、合规目录等 [227][228] - **附录4：工具和基础设施**：介绍FOSSology、FOSS条形码跟踪器等开源工具和基础设施 助力实现合规 [229][230]

报告行业投资评级 无 报告的核心观点 - 企业在采用多源开发模式融入开源软件时面临合规挑战，需建立完善开源合规计划确保遵守开源许可义务，保护知识产权，实现有效利用开源软件的目标 [31][33][40] 根据相关目录分别进行总结 第一章 开源合规简介 - 商业环境变化，从传统专有软件模式转向多源开发模式，开源软件大量融入，企业需通过合规计划和工程实践管理风险 [31][33][39] - 开源合规是遵守开源许可义务的过程，能实现合规许可、有效利用开源、遵守第三方合同、保护知识产权四个目标 [40][41][45] - 确保开源合规可带来技术优势、利于外部合作、助力企业交易等好处 [42][43][44] - 合规失败包括未提供归属通知、许可通知等多种情况，会导致知识产权、许可合规、流程等方面的问题 [45][46][48] - 应在产品发货或服务启动前确保合规，不合规成本高，且要重视与开源社区关系和员工培训 [58][61][64] 第二章 建立开源管理计划 - 开源管理计划涵盖开源软件各方面，核心要素包括策略、政策和流程、团队、工具、教育、自动化、沟通和行业倡议 [66][68][70] - 合规策略驱动政策和流程实施共识，询问响应策略用于应对合规挑战 [71][74] - 企业建立合规计划面临平衡与现有流程关系、长期目标与短期执行等挑战，可通过获得高管支持、制定轻量级政策等方式解决 [93][94][101] 第三章 实现合规：角色和职责 - 实现合规有核心团队（开源审查委员会）和扩展团队，各团队成员有不同职责 [127][128][129] - 开源审查委员会负责确保相互合规、促进开源使用等多项任务 [135] - 法律、工程和产品团队、合规官等角色在开源合规中承担不同职责 [139][144][149] 第四章 开源合规流程 - 合规流程核心要素包括识别开源、审查和批准使用、满足义务，有效合规能带来诸多好处 [167][170][171] - 端到端合规流程包括识别、审计、解决问题、审查、批准、注册、通知、预分发验证、分发、最终验证十个步骤 [172][173] 第五章 合规流程和政策 - 合规政策需规定工程师使用开源需获批准、所有软件需审计等基本规则 [219] - 合规使用流程包括源代码扫描、识别和解决问题、法律审查、架构审查、最终审查等阶段 [221] - 增量合规是在基线版本基础上维护合规的过程，可通过部署物料清单差异工具等方式实现 [264][267][269] 第六章 推荐实践 - 合规过程包括识别、源代码审计、解决问题、架构审查、批准、通知、验证等阶段 [109] - 可使用源代码识别工具、项目管理工具等工具和自动化手段辅助合规 [116] 第七章 管理合规询问 - 应对合规询问包括确认、告知、调查、报告、关闭询问、纠正、改进等步骤，并需考虑一般因素和不同动机的执法活动 [121] 第八章 其他合规相关实践 - 包括员工评估、网络门户、消息传递、培训等实践，以及源代码修改、通知、分发、使用、归属等方面的考虑 [125] 第九章 扩展开源法律支持 - 提供实用法律建议、许可证手册、许可证兼容性矩阵、许可证分类、软件交互方法、清单等支持 [136] 第十章 OpenChain项目 - OpenChain项目确定有效开源管理的关键推荐流程，包括规范、自我认证和培训课程，能促进多市场采用 [146] 第十一章 软件包数据交换（SPDX） - SPDX是提供软件物料清单信息的开放标准，包括许可证列表、ID、规范等内容，有相关工具支持 [154] 第十二章 评估源代码扫描工具 - 可从知识库、检测能力、易用性、操作能力、集成能力、安全漏洞检测能力、成本等

报告核心观点 - 开源在减少技术债务方面有重要作用，使开发工作与上游开源项目保持一致可直接减少组织承担的技术债务，虽短期内技术债务难以避免，但长期应尽量消除，通过适当政策、流程、培训和工具可降低技术债务 [62] 技术债务相关内容 定义 - 软件开发中技术债务指因偏离联合开发主分支而产生的维护源代码成本，专有代码本身也可构成技术债务，上游代码在缺乏维护资源时也存在技术债务 [8] 症状 - 代码由单一组织开发和维护，依赖合作伙伴维护；发布节奏变慢；新开发者入职时间增加，留用和招聘困难；安全问题增多；代码维护工作量增加；与上游开发周期不一致 [11] 类型 - 临时技术债务：为加速产品开发，在开发和集成过程中临时产生，最终目的是与上游分支合并 [12] - 未知技术债务：因不良工程实践无意识产生，如编写质量差且无法被上游接受和复用的代码 [13] - 故意创建的技术债务：组织为保留专属功能而创建独立分支，随时间推移导致技术债务增加和维护成本上升 [14] - 过时技术债务：因“非此处发明”综合征或孤立开发，导致开发成果与行业标准不兼容而产生 [15] - 组织技术债务：代码开发位置与应开发位置不匹配，开发者无法正确编写或贡献代码，产生不必要的代码 [16] 原因 - 低质量代码无法上游化；自利代码对社区用处不大；组织缺乏技术领导力和对上游技术方向的了解 [18][19] 后果 - 开发碎片化，导致重复工作和竞争实现；缺乏将代码推向上游的努力；代码具有侵入性，需跨组件协调；代码被上游接受时间长，产生临时技术债务；缺乏测试和文档；技术领导力差，与技术社区互动不足；内部需求不断变化；技术不标准或与标准不一致；代码维护成本高；创新和开发周期变慢；需支付技术债务利息；可能错过主分支新功能或需回移植开发；与主分支重复工作 [20][21] 积累方式 - 以开发周期无上游集成的示例说明技术债务的产生和延续 [22][23] 应对方法 识别 - 通过思考团队工作内容、软件栈相关问题等帮助识别技术债务 [25][29] 最小化 - 选择高级编程语言，便于招聘开发者、第三方解决问题、代码移植和维护，且容错性高 [27][29] - 选择与自身目标一致的生态系统，评估和选择合适的依赖项并为重要依赖项做贡献，且持续评估依赖项 [31][32] 示例相关内容 自定义构建系统的作用 - 维护操作系统需确保其可靠安全运行、组件可重现构建、正确评估测试、遵守许可和有更新机制；选择ARM服务器发行版可减少维护自定义操作系统的需求，便于开发者转移知识和招聘人员，未来嵌入式设备开发可选择有长期支持的标准Linux发行版 [34][36] 用户界面框架 - 编写和维护UI框架是长期任务，选择UI框架意味着选择社区，需依靠社区承担技术债务并必要时提供帮助；注意许可证和知识产权归属，参与上游依赖项开发以满足自身需求 [38][39] 上游开发相关内容 作用 - 以开发周期有上游集成的示例说明，遵循持续集成和交付、尽早频繁发布、同行评审、持续测试等实践，可使功能更快可用、代码质量更高、便于理解调试和成熟化、建立信任等 [41][43] 统一努力 - 与上游保持一致开发可减少技术债务，但需参与和贡献上游开源项目，可通过贡献影响上游方向 [47] 大规模解决技术债务相关内容 政策和流程层面 - 为开源开发者提供全面贡献批准；设置快速批准路径；提供灵活IT支持；构建奖励减少技术债务开发者的绩效评估体系；保证开发者与上游项目合作时间 [53] 开发层面 - 向工程师解释业务目标；确保开发者了解技术债务；对合并贡献有合理预期；接受审查反馈；参与对上游有益的任务；鼓励开发者在添加技术债务时注释；短期工作与长期规划结合 [54] 已有技术债务的解决方法 - 选择需保留的功能；识别有用代码；移除不再维护的代码；减少分支需求；重构、清理和上游化可上游化的代码；考虑迁移到能提供所需功能的开源项目；放弃技术债务并弃用代码 [58][56][57] 推荐实践 - 采用上游优先理念；谨慎评估不向上游提交的自定义代码；计划与主分支合并；使内部开发与上游发布节奏一致；快速批准上游贡献；更新绩效指标纳入技术债务相关内容；培训开发者和管理者识别和减轻技术债务；要求代码正确文档化；遵循尽早频繁发布实践；跟踪不向上游提交的代码并重新评估 [60][61]

核心观点 - 事实收集是软件谈判中首要且最重要的任务，律师和采购专业人员应避免做出会损害自身信誉和拖延谈判的事实假设，要与实际执行或监督工作的员工基于相同知识库工作，以节省时间并达成更好协议和关系 [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]