编程与软件工程writing.kemitchell.com
逐行解读 MIT 许可证
The MIT License, Line by Line
2016 — 2021，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
作者逐句拆解 MIT 许可证文本，解释每一条款的法律含义，包括版权声明、许可授予、免责声明背后的美国版权法与担保法原理。文章还澄清了一个常见误解：GitHub 上发 pull request 并不会自动按项目许可证授权你的贡献，美国法律默认是强版权保护。
为什么经久不衰：MIT 许可证人人都在用却少有人真正读懂，这篇逐条解读把开源许可的法律基础讲得清晰透彻，多年后仍是理解贡献授权问题的最佳入门。
HN 评论精选
澄清 inbound=outbound 的真正含义：它是贡献治理规则而非法律默认，DCO 和特定许可证条款都能实现它
Red Hat 的 Richard Fontana 澄清："inbound=outbound" 并非指美国法律不承认某规则，而是一种贡献治理规则——即贡献（如 pull request）被视为按项目的对外许可证授权。这其实是大多数开源项目自古以来的运作方式。DCO 是让这一规则更明确的方式之一，他越来越认为应该鼓励使用（至少可以对抗 CLA 的做法）。此外还有其他增强确定性的办法，比如使用 MPL 这类 copyleft 许可证，或 Apache 2.0（其第 5 条把 inbound=outbound 作为许可授予的条件）。
richardfontana查看英文原文
Despite the assumption of some newer open-source developers that sending a pull request on GitHub “automatically” licenses the contribution for distribution on the terms of the project’s existing license—what Richard Fontana of Red Hat calls “inbound=outbound”—United States law doesn’t recognize any such rule. Strong copyright protection, not permissive licensing, is the default. That isn't quite what I mean by "inbound=outbound". Rather, inbound=outbound is a contribution governance rule under which inbound contributions, say a pull request for a GitHub-hosted project, are deemed to be licensed under the applicable outbound license of the project. This is, in fact, the rule under which most open source projects have operated since time immemorial. The DCO is one way of making inbound=outbound more explicit, and I increasingly think one that should be encouraged (if only to combat the practice of using CLAs and the like). But under the right circumstances it works even where the contribution is not explicitly licensed (I think this is what Kyle may be questioning). There are other ways besides the DCO of creating greater certainty, or the appearance of greater certainty, around the inbound licensing act, such as PieterH's suggestion of using a copyleft license like the MPL, or the suggestion of using the Apache License 2.0 (whose section 5 states an inbound=outbound rule as a kind of condition of the outbound license grant).
用 share-alike 许可证（如 MPLv2）可以让 fork+PR 流程在法律上自动成立，免去 CLA 的额外负担
好文章。关键点：fork + pull request + merge 流程在法律上并不自动生效，除非有 CLA 等显式步骤。ZeroMQ 早期要求贡献者声明"我特此按 MIT 许可此补丁"，但这增加了维护者负担，也吓退了需要走公司审批的企业贡献者。他们现在的方案更优雅：使用 MPLv2 这类 share-alike 许可证——fork 一个 MPLv2 项目时，fork 本身也按 MPLv2 授权，修改自然可以合并回去。
PieterH查看英文原文
This is a really good article. There's one part in particular that struck me: "Despite the assumption of some newer open-source developers that sending a pull request on GitHub “automatically” licenses the contribution for distribution on the terms of the project’s existing license—what Richard Fontana of Red Hat calls “inbound=outbound”—United States law doesn’t recognize any such rule. Strong copyright protection, not permissive licensing, is the default." In other words the fork + pull request + merge flow does not work on a project unless you have an explicit step like a CLA, or an alternative solution. We faced this problem early on in ZeroMQ, that asking contributors to take this extra step increased the work for maintainers (to check, is this the first time person X contributes, and have they made a CLA?) It also scared off contributors from businesses, where this often took approval (which took time and was often denied). Our first solution in ZeroMQ was to ask contributors to explicitly state, "I hereby license this patch under MIT," which let us safely merge it into our LGPL codebase. Yet, again, another extra step and again, needs corporate approval. Our current solution is I think more elegant and is one of the arguments I've used in favor of a share-alike license (xGPL originally and MPLv2 more these days) in our projects. That works as follows: * When you fork a project ABC that uses, say, MPLv2, the fork is also licensed under MPLv2. * When you modify the fork, with your patch, your derived work is now also always licensed under MPLv2. This is due to the share-alike aspect. If you use MIT, at this stage the derived work is (or rather, can be) standard copyright. Admittedly if you leave the license header in the source file, it remains MIT. Yet how many maintainers check the header of the inbound source file? Not many IMO. * When you then send a patch from that inbound project, the patch is also licensed under MPLv2. * Ergo there is no need for an explicit grant or transfer of copyright. I wonder if other people have come to the same conclusion, or if there are flaws in my reasoning.
指出一个流行误解：MIT 许可证其实明确要求保留完整许可文本，并非"随便用不用署名"
有趣的是，MIT 许可证常被当作"不关心署名、或要求署名不合理时选的许可证"。但正如文章指出的，MIT 许可代码的副本不仅要保留版权行，还必须附上整个许可证文本。
gakada查看英文原文
It's funny that the MIT license has the reputation of being "The license you choose when you don't care about attribution, or it would be unreasonable to require attribution". As the article points out, copies of MIT licensed code must include not only the copyright line but the whole damn license.
npm 生态中几乎没人遵守 MIT 许可证的署名条款，这种普遍违规的风险值得警惕
这篇文章触及了我一直疑惑的一点：JavaScript 和 npm 生态依赖极重，即使你只直接引入几个包，一个简单应用的子依赖也常有数百个。为什么"所有人"都忽略了依赖和子依赖的署名要求？是懒惰，还是被起诉的风险太低？如果 Oracle 买下了世界上所有的 left-pad 会怎样？
thed查看英文原文
This article touches a point I have been wondering about regarding the Notice condition: "But web developers, as a whole, haven’t got the memo.". The JavaScript and npm ecosystem are extremely dependency-heavy. Even if you only take a few yourself, the number of sub-dependencies of even a simple application are often in the hundreds. Why does "everyone" ignore the attribution of their dependencies and sub-dependencies? Laziness? Risk of getting sued too low? What happens if Oracle buys all the left-pads in the world?
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选