加载失败
这篇帖子来自 Homebrew（macOS/Linux 常用包管理器）维护者，他主张那些在公司里依赖 OSS 的工程师，不必只通过 Open Source Pledge（鼓励企业资助开源维护的倡议）、GitHub Sponsors（GitHub 的赞助工具）或 Open Source Friday（公司留出开源时间的做法）去“请求善意”，而可以直接把维护开源视为工作的一部分。评论区围绕一个老问题展开：如果代码是在 job duties、公司设备或工时内写成，它到底属于员工还是 employer。不同法域的规则差异很大，美国、英国、德国、荷兰等地对 work for hire 或雇主 IP 的处理并不一样，而 California Labor Code Section 2870 之类条款又会限制公司吞掉与工作无关的个人创作。于是讨论很快从“要不要支持 OSS”转向“怎样在合同、审批、CLA 和 DCO 里把权限说清楚”。
不少人认为，争取公司时间维护 OSS 的关键不是讲“做慈善”，而是把它说成对公司直接有利的工程工作。修 bug 并 upstream 之后，可以得到领域专家的免费 review，也能把后续维护成本和补丁分支碎片化降到最低。有人强调，工程师本来就该维护自己依赖的稳定性和可维护性，而不是把“开源”当成额外爱好。也有评论建议把系统设计成可拆分的 agnostic modules，这样未来更容易公开出去。
讨论里反复出现的最大障碍是 IP 归属：在很多法域里，只要代码是在 job duties 内、工作时间内，或者用 company laptop 写的，默认就可能被 employer 认定为其资产。有人补充说，德国、荷兰这类地方对雇主主张更宽，而 California 之类地区则通过劳动法限制公司拿走与工作无关的个人创作。也有更细的说法区分了 copyright ownership 和 exclusive usage rights，说明“员工名义上仍是作者”并不等于能自由授权给别人。很多大项目因此会要求 explicit permission、CLA 或 DCO，来确认贡献者确实有权提交。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12]
很多人分享的不是法条，而是公司内部流程把一件小事拖成大工程：补一个上游 patch 可能要走好几轮 legal 邮件，最后因为没人愿意负责而直接放弃。有人在大厂经历过连 GitHub issue 都不敢碰的严格限制，求职时还遇到独家工作条款，明文禁止在业余时间贡献任何外部项目。另一些人说，manager 在利润导向的环境里通常只关心立刻可见的价值，所以员工一提 OSS 就会被打回去做“下班再说”的事情。也有少数公司给出比较清晰的 policy，比如先找 manager、不要用公司名义、别碰 confidential info。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
反对者把这种做法看成道德问题，认为员工不能替公司擅自决定把受雇创作的代码捐给社区，这本质上是在拿别人的 IP 做善事。另一种更实际的担忧是，commit 时你等于向 upstream 项目保证自己有合法授权；如果没有，这会把 infringement 风险转移给 maintainer 和整个项目。支持者则反击说，现实中几乎没人会真的因为你在午休还是工时内写的 bugfix 去追责，而且公司往往更愿意“放过”而不是打官司。于是整场争论就变成了“白嫖”与“理论风险”之间的拉扯。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8] [来源9] [来源10] [来源11] [来源12]
一些评论没有走极端，而是给出更可执行的折中：先申请 blanket permission，只维护特定 OSS 项目，或者把例外写进合同 carveout，限定在某些工时、某些设备、某些模块上。也有人提到研究机构、实验室和某些团队本来就会把脚本、仪器控制软件或优化补丁公开出去，前提是项目足够独立、没有 patent 或敏感代码包袱。还有人分享了具体经验，比如每周保留少量 on-your-own time，或者在没来得及合并时继续把 PR upstream，最终由后续的维护者接手。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7]
work for hire: 受雇创作规则；员工在职务范围内写出的代码，通常由雇主拥有版权或优先权利。
CLA (Contributor License Agreement): 贡献者许可协议；提交代码前，贡献者授权项目使用、再许可或合并贡献的法律文件。
DCO (Developer Certificate of Origin): 开发者来源证明；提交时声明代码来源合法、自己有权贡献的签名机制。
California Labor Code Section 2870: 加州的一项劳动法条款，用来限制雇主主张员工在个人时间、个人资源下完成且与工作无关的创作成果。