开源法律风险
职务软件认定看三情形，不看是否下班时间
《计算机软件保护条例》第十三条规定，自然人在任职期间开发的软件，符合任一情形即由法人或其他组织享有著作权： 针对本职工作中明确指定的开发目标所开发的软件；从事本职工作活动所预见的结果或者自然的结果； 主要使用了单位的资金、专用设备、未公开的专门信息等物质技术条件所开发并由单位承担责任的软件。
条文限定的是"任职期间"而非"工作时间"，因此业余时间加个人设备开发并不当然排除职务作品认定。 与公司业务同领域的工具库，即使周末在家完成，也可能因构成"本职工作预见的结果"而归公司。 此时员工擅自将其以 MIT 等许可证开源，构成对单位权利的无权处分，公司可以主张开源授权无效。
劳动合同可以把职务作品著作权约定归单位
《著作权法》第十八条将职务作品分为两类：一般职务作品著作权归作者，单位仅在业务范围内享有优先使用权； 特殊职务作品（包括主要利用单位物质技术条件创作并由单位承担责任的计算机软件）仅署名权归作者。 同条第二款第（三）项进一步允许"合同约定著作权由法人或者非法人组织享有"，给劳动合同留下了约定空间。
实践中常见的"任职期间一切创作成果归公司"式 IP 归属条款（IP Assignment），对与岗位完全无关的创作未必获得法院支持； 但软件开发与程序员岗位职责高度重合，条款被支持的风险显著更高。 入职签署文件时应确认措辞是"任职期间"还是"工作时间及工作任务"，两者覆盖范围差别很大。
公司使用员工开源软件仍受许可证约束
即使著作权确实归员工个人，公司使用其开源软件也必须遵守对应许可证：MIT、BSD 要求保留版权声明（Attribution）； GPL 系的传染性条款（Copyleft）仅在公司内部使用时不触发义务， 一旦把 GPL 代码集成进对外分发的闭源产品，就须以同一许可证公开衍生作品源码，违反则授权终止、继续分发构成侵权。 Apache-2.0 在 MIT 基础上增加了明确的专利授权与专利报复条款，是企业采用员工项目时更稳妥的选择。
员工是唯一作者时更干净的做法是双重授权（Dual Licensing）：开源版本面向社区，另向公司签发一份独立商业授权， 剥离开源许可证对公司侧的约束。项目一旦接收外部贡献，变更许可证需要全体贡献者同意，除非事先签有 CLA。
见：GNU General Public License v3.0
把公司代码带进开源项目可能触及侵犯商业秘密罪
员工将公司代码片段、未公开接口设计或业务逻辑混入个人开源项目，首先构成对公司著作权的侵犯。 若相关信息符合商业秘密要件（不为公众所知悉、具有商业价值、经权利人采取保密措施）， 还构成《反不正当竞争法》第十条规定的侵犯商业秘密行为，情节严重的可触及《刑法》第二百一十九条侵犯商业秘密罪。
2025 年第二次修订的《反不正当竞争法》已于 2025 年 10 月 15 日施行，商业秘密条款由旧版第九条移至第十条， 引用旧资料中的条号时需要相应更新。
业余开发的风险隔离实务
工程上应把归属争议的举证材料前置准备：使用个人设备、个人账号与个人邮箱开发， git commit 时间戳自然落在非工作时间，这些痕迹在争议中是证明非职务作品的核心证据。 与公司业务相关的项目应书面报备，取得公司明确放弃权利主张的书面豁免（Waiver）， 一封确认邮件即可消除大部分归属风险。
推动公司采用自己业余开发的项目属于利益冲突（Conflict of Interest），正确做法是主动披露作者身份， 并让公司走与第三方开源软件相同的合规审查流程留痕，而不是以作者身份直接引入。 给公司用的项目优先选择 Apache-2.0，避免 GPL 系进入对外分发的商业产品。