“写笔记”支持四种格式——Word 文档、Excel 表格、Markdown、纯文本,起稿或二次编辑时都能随时切换,同一篇笔记想用哪种形态来记,都由你说了算。
md、txt、csv、json 这类纯文本则原样载入,不做多余加工。拿一张现成的表倒进来、改几笔、再导出去,等于白用一台免费的格式转换器。
要带走就在右上角点“下载”,可导出 PDF、Word、Markdown、Excel、TXT 等格式;列表卡片“⋯”菜单里,也有同样的下载入口。
在“工具”页点“+ 上传工具”即可发布:填好名称与链接,再用 Markdown 把使用方法写清楚——能解决什么问题、怎么装、怎么用,比堆介绍实在。
要分发安装包就一并上传压缩包(ZIP、RAR、7Z、TAR.GZ,最大 35MB),别人在详情页一键下载;只放链接不带附件也可以。
工具按大家的收藏热度排序,好用的自然会被顶上来。发布后可在详情页或卡片菜单里编辑、下架。
写笔记时勾上“隐藏”,这篇就只存在于你自己的账号里:不进列表、不进搜索、不上首页精选,也不会出现在任何公开的页面,链接发给别人同样打不开。
适合放密码、草稿、日记这类只给自己看的内容;想公开,去“发布”打开它,把“隐藏”的勾去掉再保存,之后编辑会默认保持原状态,不会悄悄变回公开。
你的内容会同时保存在多个副本上,系统定期做备份与完整性校验,再配合异地容灾机制:就算某台机器出问题,数据也不会丢,可以长期放心存放;特别重要的资料,仍建议你另外再留一份备份。
全站跑在容器化、模块化的现代架构上,更新、部署、回滚都很快,扩展性和稳定性都按长期运营的标准来设计(Built for reliability, designed to scale)。
这个网站最早只是一个人的笔记仓库,后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法,只是干干净净地存放一些东西;既然做好了,就公开出来,万一有人用得上呢。
不做大而全,不做平台梦,保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护:不会突然冒出付费墙,不会在角落塞广告位,也不会把你的数据卖给第三方。
产品会持续迭代,站内日志页记录着每一次改动,改了什么都有迹可循;想了解这个站是怎么一步步走到今天的,翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容,点对应卡片右侧的“举报”按钮就能提交,我们会尽快核实处理;也谢谢你花一点时间,一起把这里维护干净。
Google’s copying of the Java SE API was fair use [pdf]
{"category":"法律政治","title_cn":"谷歌复制Java API被判合理使用:技术视野下的里程碑判决","content":"> 美国最高法院判定谷歌复制Java SE API属合理使用,重塑了软件版权保护的边界,对开发者与创新意义深远。\n\n这是一份来自美国最高法院的判决书PDF文件,在Hacker News上引发了4103分的高热度与932条热烈讨论。这份判决书的核心裁决是:谷歌在开发Android系统时对Oracle(甲骨文)Java SE API(应用程序编程接口)的复制行为,构成版权法下的"合理使用"(fair use)。\n\n对于长期关注科技与法律交叉领域的开发者而言,这一判决的分量不言而喻。这不仅是谷歌与甲骨文之间长达十余年专利与版权拉锯战的法律终点,更是对整个软件行业未来创新模式的一次重磅定调。本文将从技术笔记的视角,深度剖析这份判决书的技术与法律内涵。\n\n---\n\n## 一、 案件回溯:一场跨越十年的软件版权之战\n\n在深入理解判决书的技术分析前,有必要先厘清案件的来龙去脉。\n\n### 1.1 争议的焦点:Java SE API 是什么?\n\nJava SE(Standard Edition)API 是Java编程语言的标准库接口集合。它定义了开发者调用系统功能时所需的方法名、类名、接口签名以及相应的调用约定。例如,开发者要比较两个字符串,就需要使用 java.lang.String.compareTo() 这类API。它相当于操作系统的"系统调用表",是连接应用程序与底层实现之间的功能性桥梁。\n\n### 1.2 争议的实质:谷歌用了多少,怎么用的?\n\n2005年,谷歌在为Android系统选择编程语言基础时,出于对开发者生态的考虑,决定采用Java语言的语法和核心API库。然而,谷歌并未获得Sun Microsystems(Java的原始开发者,后被Oracle收购)的授权。谷歌通过独立编写代码,复制了Java SE API的声明部分(即函数的名称、参数类型、返回类型等"签名"),但并未复制这些API背后的具体实现代码(即方法内部如何工作的逻辑)。\n\n具体数据上,谷歌复制了约11,500行Java SE API代码,但谷歌独立的实现代码则多达数百万行。甲骨文据此提起诉讼,声称谷歌复制API声明侵犯了其著作权。\n\n### 1.3 诉讼历程:从地方法院到最高法院\n\n* 第一阶段(联邦地方法院):2012年,法官William Alsup裁定API结构不受版权保护,谷歌胜诉。\n* 第二阶段(联邦巡回上诉法院):2014年,上诉法院推翻了地方法院的裁决,认为API的结构、顺序和组织(SSO)具有版权。\n* 第三阶段(最高法院首次介入):2015年,最高法院在考虑了各方意见后,将案件发回重审(granted certiorari并vacated原判决),要求上诉法院重新考虑可版权性问题。\n* 第四阶段(重审与陪审团裁决):2016年,案件回到地方法院重审。陪审团认为谷歌的行为构成"合理使用"。\n* 第五阶段(上诉法院再次审理):2018年,联邦巡回上诉法院再次推翻了陪审团的裁决,认定谷歌的行为不属于"合理使用",理由是谷歌复制API的目的具有"商业性",且对Java市场造成了潜在损害。\n* 最终阶段(最高法院终审):2021年4月5日,最高法院以6比2的投票结果(Justice Thomas未参与审理)推翻了上诉法院的判决,认定谷歌的复制行为属于合理使用。\n\n---\n\n## 二、 判决书的核心技术分析与法律论证\n\n最高法院的判决书由Justice Breyer主笔,其论述逻辑严密,技术视野清晰,将复杂的软件工程概念与传统的版权法四要素分析深度融合。\n\n### 2.1 关键前提:API"声明代码"的性质\n\n判决书首先明确了争议代码的性质。谷歌所复制的11,500行代码,主要是为了调用Java预编好的方法而必须使用的"声明代码"。这如同用户使用一台复杂的机器,必须按照其面板上标注的"按钮"名称和顺序来操作。API声明就是软件世界的"用户操作手册"。\n\n最高法院区分了"声明代码"与"实现代码",并指出:谷歌复制的是前者,用以让Android应用的开发者可以调用API底层用Java编写的功能;而谷歌本人并未逐行复制实现代码。这使得本案与传统的"代码剽窃"案有本质区别——谷歌是想要让自家的代码能和其他代码(利用Java API写出来的既有程序)协同工作,其本质是追求"互操作性"(interoperability)。这也是法院分析的重要技术背景。\n\n### 2.2 "合理使用"四要素的深度展开\n\n美国版权法第107条规定了判断合理使用的四个法定要素,最高法院在其判决中对每个要素都进行了详尽的论证。\n\n#### 要素一:使用的目的和性质(The Purpose and Character of the Use)\n\n法院认为谷歌的使用具有"变革性"(transformative)和"非侵袭性"。\n\n* 变革性:谷歌并非简单地对Java API进行再版或销售(这属于纯粹的复制),而是将API用作编写无数新应用(Android APP)的软件基础。谷歌创作了一个全新的、功能强大的移动计算平台,服务于智能手机用户。它借用了Java API的"用户操作手册",但创造了全新的产品。法院引用了著名的"谷歌图书案"(Authors Guild v. Google, Inc.),指出谷歌搜索引擎对图书的复制(为了索引和展示片段)具有变革性,因为它创造了新的信息检索功能。同样,谷歌复制API声明,其核心目的是为了实现创作者和生态系统的全新表达方式。\n\n* 商业性:甲骨文反复强调谷歌用Android赚钱,是典型的"商业性使用",这通常对合理使用构成不利。但法院指出,商业性并不是一票否决。合理使用制度允许商业性使用,关键在于使用行为是否超越了"复制以实现原作本来功能"的范畴,而谷歌的行为正是后者,它是目标不同、目的迥异的二次创作。\n\n* 非侵袭性:这是常被技术圈忽视但法院强调的一点——谷歌的复制并未抢占Java本身的市场。使用谷歌API开发的Android应用,无法直接在基于Java SE的桌面系统或企业服务器上运行,反之亦然。两者的市场并不重叠,谷歌没有用它复制的代码去直接替代或竞争Java SE API本身的市场。它更像是借用了Java的语言框架来发展出一个全新的"方言"市场。\n\n#### 要素二:被复制作品的性质(The Nature of the Copyrighted Work)\n\n法院认为,Java SE API的声明代码属于功能性、系统性的接口定义,其表达性的内容非常有限甚至几乎不存在。它更像是一种"系统或方法",尽管版权法不保护思想只保护表达,但API声明作为命令给定功能的"开关",其表达形式已经被其功能目的所束缚。因此,这种代码比典型的文学或艺术创作(比如小说或音乐)更靠近"功能工具"的边界,从而使得版权保护的范围应该更窄,赋予了复制者更大的合理使用空间。这好比字典中对单词释义的安排,虽具表达性,但为了帮助查阅,其功能属性更重。\n\n#### 要素三:复制部分的数量和实质性(The Amount and Substantiality of the Portion Used)\n\n甲骨文和谷歌在此争辩激烈。甲骨文指出,谷歌复制了API名称、参数结构,尽管只是代码片段(11,500行),但它们是整个Java API的"食谱"、"目录"和"组织架构",是一个庞大的系统——共有超过6000个方法可供调用。谷歌在Android的代码中大量且完整地使用了很多关键类的声明。然而,法院从比例和$\textbf{与合理使用目的的相符性}$的角度看问题:谷歌需要复制的“总计13,000行(判决书附录中的数据)”,只占整个Java SE API声明总量(Oracle估算约286万行)的很小比例。更重要的是,谷歌复制的这些部分,恰恰是为了实现其变革性目的所必要的部分——它需要这些接口以让Java开发者的代码在新平台上工作。与实现整体功能所需的百万行代码相比,复制这部分\u201ctip of the iceberg\u201d是不可或缺的。法院认为,这种“为了新目的而复制必要部分”的行为,是合理的。\n\n#### 要素四:对原作品潜在市场或价值的影响(The Effect of the Use upon the Potential Market for or Value of the Copyrighted Work)\n\n甲骨文的核心主张是,若谷歌赢得此案,Java将失去其市场主导地位,因为它们原本可以授权Java SE给谷歌用于Android来获利,而且Sun(现Oracle)本来就在拓展Java在智能手机领域的征程。\n\n法院对此进行了深入驳斥,侧重于市场事实:当谷歌Android在2007-2008年横空出世时,Java在智能手机市场的渗透率几乎为零或者非常有限。当时主要的移动平台是Symbian、BlackBerry OS、iOS等。Sun公司错失了移动端的先机。法院明确指出,如果Sun(或Oracle)确实拥有一个完全独立的、可行的针对智能手机的Java牌市场,那么谷歌的进入会取代这个市场收入。但事实是,该市场从未存在过。Android的成功恰恰是构建了一个全新的市场,而这个市场的成功并非源于从Java SE市场中\u201c抢客户\u201d,而是通过提供开源的Android操作系统,吸引了开发者。法院还引用了一个重要的技术/市场现实:即便谷歌当初不借用Java API,它完全可以借用C++ API,或者干脆开发一套全新的API。Sun和Oracle的损失并非因为谷歌\u201c抢走\u201d了它们原本能赚到的钱,而是因为它们没能在新市场抓住机遇。\n\n### 2.3 判决书中的"政策"考量\n\n在四个法定要素之外,法院还重点强调了一个宏观的公共政策与技术生态视角:软件是创新的平台。如果允许对API声明的版权保护形成一种"锁定",那就意味着任何公司一旦在某个领域发布一套API并形成规模(如同Java在PC时代的作用),后来者(如Android)就无法开发兼容或互操作的系统,这等同于允许对一种"语言"的语法进行垄断,极大地扼杀创造性。法院还特别提及了开源社区的价值以及"公平使用"对促进新作品诞生的重要性,认为从PC(Java靠API形成生态)到移动互联网(Android靠Java API形成生态),这种代码层面的互操作是技术迭代的核心推动力。\n\n---\n\n## 三、 判决的技术与法律影响:对开发者意味着什么\n\n1. API版权保护的黄昏:互操作性优先\n 此判决为整个行业确立了强有力的先例。简单来说,为了与其他系统协同工作而复制一个软件的API(接口定义)以使其代码能运行,不会被认定为侵犯版权,只要行为满足合理使用四要素。这对许多依赖模拟器、兼容层、跨平台框架(如Wine, React Native等)的企业和开源项目是一剂强心针,极大地降低了它们被巨头以版权名义追诉的风险。\n\n2. "代码签名"区别于"代码实现"的胜利\n 判决书在行业中强化了一种理解:你不能通过把一个接口的\u201c抽象表达\u201d注册成版权,就让所有为这个接口编写独立实现的人都变成盗版。开发者现在可以更放心地对现有API进行洁净室(clean-room)重实现,只要不抄袭实现代码本身。\n\n3. 商业性使用不等于必然侵权\n 对于通过兼容API来商业化运营的公司(如曾经的微软针对Java对Sun,现在的各种云服务商重新实现开源API),本案指出:纵使有强烈的商业动机,只要对该API的使用具有全新的和变革性的目的,且不对原API的市场构成实质替代,就可能被豁免。这使得整个软件专利与版权战场的重心可能会向专利权倾斜——专利保护更适用于功能实现层面的独特方法。\n\n4. 对开发者社区的直接红利\n 判决有力地维护了Java开发者向Android生态迁徙的合法性。如今,数百万的Android应用开发是基于此判决的庇护——它们所使用的java.lang、java.io、java.util等核心库的Java API命名空间,都是建立在由公平使用规则支持的合法基础上。\n\n---\n\n## 四、 独到的判例观点与后续争议\n\n当然,该判决并非没有反对声音。判决书中另一份有力的反对意见(由Justice Thomas撰写,Justice Alito加入)认为,多数派的结论错误地忽略了API的\u201c结构\”。反对意见认为,即使复制的是声明代码,但整个API的特定组织结构(哪个类在哪个父包下,方法之间如何依赖)这种系统的创建本身就是创造性的表达,谷歌对这种 SSO 的复制超出了合理使用的范畴。这提醒我们,围绕API的版权边界和合理使用的定义并未完全封闭,还可能在未来的案件中(如更纯粹地对某个API结构进行全盘抄袭而不加任何变革性包装)再次被测试。\n\n另一个有争议的技术视角是:如果我们把API比作一种"网络协议",是否应该有统一的立法保护?本案中,最高法的裁决实际上承认了为互操作性而复制协议逻辑的合法性,但它仍保留了在四要素测试下案例为的灵活性。这在一定程度上可能缓解了全球范围内关于API版权问题的普遍焦虑。\n\n---\n\n## 五、 回归技术本质:代码与法律的共生\n\n从技术笔记的角度看,这远超于一场法律诉讼。它是一堂非常宝贵的:详细展示了技术架构(API设计)是会如何被法律合理性所接纳并影响宏观产业生态的公开课。\n\n一个优质的编程抽象(如API)往往是一种向开发者呈现的“哲学”——像Unix哲学一样,一切都是文件;像Java,强调可移植性。这决定了它的实用性来自于其开放的接口。谷歌用无数代码行证明了如何借助一套公开的技术词汇(API),开创新的技术境界。\n\n> 最终,最高法院以6-2的票数确认了谷歌行为的合法性,不仅为持续12年的 Java API 之争画上句号,也为数以百万计的软件构建者描绘了一幅清晰的远景:代码的世界是互联的,接口是众人的,创新是自由的。\n\n参考阅读:原文PDF链接"}