企业使用开源代码，二次开发和商业交付有哪些许可要求？
开源代码通常允许修改和商业使用，但企业仍须履行具体许可证规定的义务。能查看源码，不等于已经获得二次开发和再发布许可；能够收费，也不意味着可以忽略声明保留或源码提供要求。
企业把网上找到的组件加入产品时，应同时记录代码来源、许可版本和实际使用方式。只有明确这三项，才能判断交付客户或者提供网络服务前需要完成什么工作。
一、先区分开源与仅仅公开源码
按照开放源代码促进会的开源定义，许可证应允许修改及衍生作品等活动。仅允许查看、却普遍禁止修改或者再发布的安排，不宜直接当作通常意义上的开源许可。
公开仓库没有许可证，也不意味着作者放弃著作权。企业不能把“能够下载”作为复制、改编和对外交付的充分依据，应进一步核实授权。
二、宽松许可证也有需要履行的条件
MIT许可证通常允许使用、修改、分发和商业销售，但要求在软件副本或其重要部分保留相应版权及许可声明。企业交付安装包、源代码或含组件的产品时，应把声明保留落实到实际文件。
不能只在内部清单写下“MIT”就结束审查。还应检查组件是否包含其他第三方代码、图片、字体或者数据，这些内容可能适用不同许可。
三、源码提供义务取决于协议和使用方式
GPL、AGPL等许可证并非禁止商用，但可能在修改、对外传递软件或者网络交互等特定条件下产生提供相应源码等义务。是否触发，应按许可证版本和实际结构分析。
例如GPL下的对外传递，与仅在企业内部运行，需要分别判断；AGPL还需关注修改后的程序通过网络与用户交互时的附加要求。不能把不同许可证及版本的规则混成一句“用了就必须全部开源”。
独立调用、链接、直接合并代码、修改组件或者形成组合作品，可能带来不同结论。复杂集成应保留技术架构说明，并由技术与法律人员共同核对。
四、把合规动作放进交付流程
首先，保存取得时的LICENSE、NOTICE、版本号、下载地址和修改记录。项目日后更换许可证时，企业才有材料说明自己取得的是哪个版本。
其次，列出产品中的第三方组件，注明是否修改、是否向客户交付及如何集成。按许可证落实声明、修改标注、许可副本和源码提供等要求。
再次，检查不同组件的许可是否兼容，核对客户合同中的保密、独占授权、源码交付和知识产权保证条款，避免合同承诺与组件义务冲突。
五、保留一次完整的发布审查记录
研发人员负责说明组件及集成方式，产品或交付人员确认使用场景，法务人员核对许可义务，最后保存随产品交付的声明和履行记录。
企业使用开源软件的关键，是把取得许可时的条件持续落实到开发和交付中。先查清许可证，再决定如何修改、部署和销售，能够减少产品成熟后再替换组件的成本。