笔记
0工具
0此页用于记录用户反馈问题后的每一次改进
关于
“写笔记”支持四种格式——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）。
这个网站最早只是一个人的笔记仓库，后来慢慢长成现在的知识中枢。设计上很克制——没有广告、没有追踪、没有推荐算法，只是干干净净地存放一些东西；既然做好了，就公开出来，万一有人用得上呢。
不做大而全，不做平台梦，保持简单、保持克制、保持好奇。所有内容都由用户贡献、由用户维护：不会突然冒出付费墙，不会在角落塞广告位，也不会把你的数据卖给第三方。
产品会持续迭代，站内日志页记录着每一次改动，改了什么都有迹可循；想了解这个站是怎么一步步走到今天的，翻翻日志就能看到来龙去脉。
如果在这里看到涉嫌违规的内容，点对应卡片右侧的“举报”按钮就能提交，我们会尽快核实处理；也谢谢你花一点时间，一起把这里维护干净。
趋势
谷歌复制Java API被裁定合理使用：一场影响深远的版权之战
美国最高法院裁定谷歌复制Java SE API属合理使用，为软件接口版权划下重要界限。
谷歌诉甲骨文案：API版权与合理使用的里程碑判决
案件背景
这场持续了十余年的法律大战，始于2010年甲骨文（Oracle）收购Sun Microsystems后，随即对谷歌（Google）提起版权侵权诉讼。甲骨文声称，谷歌在开发Android操作系统时，未经许可复制了Java SE平台中约11,500行API声明代码（即Java API的37个包的结构、命名和组织方式），侵犯了其版权。
该案的核心法律问题在于：计算机程序的应用程序编程接口（API）是否受版权保护？如果受保护，谷歌的复制行为是否构成"合理使用"（fair use）？
技术背景：什么是API？
API（Application Programming Interface，应用程序编程接口）是软件组件之间交互的约定。它定义了函数、类、方法等的名称、参数和返回类型，使开发者能够调用特定功能而无需了解内部实现细节。
以Java为例，java.lang.Math.max(int a, int b) 这个方法的签名（包括包名、类名、方法名和参数类型）就是API的一部分。开发者只需要知道这个签名，就能调用求最大值的功能，而不需要知道底层是用什么算法实现的。
API的价值在于互操作性和可移植性——如果两个系统使用相同的API，开发者就可以无缝地在它们之间迁移代码。这正是Java最初的设计理念："一次编写，到处运行"（Write Once, Run Anywhere）。
案件历程
第一轮：地方法院与联邦巡回上诉法院的反复
2012年，加州北区地方法院法官William Alsup裁定，API的声明代码不受版权保护，因为它们是"创作与功能的融合"（merger doctrine），即表达思想的唯一方式。但联邦巡回上诉法院（CAFC）在2014年推翻了这一判决，认为API声明代码具有足够的创造性，应受版权保护。
第二轮：合理使用之争
案件发回重审后，陪审团在2016年认定谷歌的复制行为构成合理使用。但CAFC再次推翻了这一裁决，认为谷歌的复制行为不构成合理使用，理由是：
- 谷歌的复制是"商业性"的
- 谷歌没有改变API的"表达性"特征
- 谷歌复制了全部代码，而非部分
- 这可能损害甲骨文的市场
最终判决：最高法院的裁决
2020年10月，美国最高法院受理此案。2021年4月5日，最高法院以6比2的投票结果（Justice Barrett未参与），裁定谷歌对Java SE API的复制构成合理使用。
最高法院的推理
最高法院的判决由Justice Breyer撰写，其核心推理围绕合理使用的四要素展开：
1. 使用的目的和性质（Factor 1）
法院认为，谷歌的复制是"变革性"的（transformative）——虽然API代码本身是功能性的，但谷歌将其用于创建一个新的、不同的平台（Android），服务于不同的目的（移动设备），而非简单地复制Java SE以替代它。
关键点在于：
- 谷歌只复制了为让程序员编写可在Android上运行的代码所需的API声明，而非实现代码
- Android面向智能手机市场，而Java SE主要面向桌面和服务器市场
- 谷歌的目标是让数百万Java程序员能够利用已有技能开发Android应用
法院强调，合理使用分析不应过于机械地看待"变革性"，而应关注复制行为是否服务于新的目的。
2. 被复制作品的性质（Factor 2）
法院承认API声明代码属于可受版权保护的表达，但同时指出其"处于版权保护核心的边缘"——这些代码是功能性的，其价值主要在于功能性而非表达性。API的设计者选择了特定的名称和组织方式，但这种选择很大程度上受制于功能需求和兼容性考虑。
3. 复制部分的数量和实质性（Factor 3）
谷歌复制了约11,500行代码，占Java SE API全部代码（约2,860万行）的0.4%左右。更重要的是，谷歌只复制了声明代码（即接口定义），而非实现代码——这些声明代码是程序员调用API所必需的，而具体的实现逻辑（占代码的绝大部分）则完全是谷歌自己编写的。
法院指出，复制"为程序员的创造性工作所必需的部分"是合理的。
4. 对原作品市场的影响（Factor 4）
法院认为，谷歌的Android并未损害Java SE的市场价值。相反，证据显示：
- Java SE的市场份额在Android出现后仍在增长
- Android和Java SE面向不同的市场（移动设备 vs 桌面/服务器）
- 甲骨文未能证明Android对Java SE的市场造成了实质性替代
法院特别指出，如果允许甲骨文控制API的使用，反而可能损害创新和竞争——因为API是开发者与系统交互的"语言"，过度保护会阻碍整个软件生态的发展。
判决的意义与影响
对软件产业的深远影响
这一判决为软件产业提供了重要的法律确定性：
API互操作性受保护：开发者可以自由地实现兼容现有API的替代实现，只要不复制其实现代码。这为开源社区和竞争对手提供了安全港。
鼓励创新而非诉讼：判决倾向于保护那些为了互操作性和创新目的而复制API的行为，而非鼓励通过版权诉讼来垄断接口标准。
对云计算和兼容层的影响：该判决对云服务提供商（如AWS、Azure等）实现兼容API，以及开源项目（如OpenJDK的替代实现）都产生了积极影响。
批评与争议
并非所有人都赞同这一判决。持异议的Justice Thomas（Justice Alito加入）认为，法院的推理偏离了版权法的传统原则，"变革性使用"的概念被过度扩大，可能导致版权保护被削弱。甲骨文和商业软件联盟也警告，这可能降低软件创新的激励。
技术社区的视角
在HN的讨论中，许多开发者对这一判决表示欢迎，认为它保护了软件生态的开放性。一些评论者指出：
- API本质上是"语言"或"协议"，就像英语的语法规则一样，不应被任何人垄断
- 如果甲骨文胜诉，可能会对开源软件和整个软件产业产生寒蝉效应
- 谷歌的复制行为是"最小必要"的——只复制了接口定义，而所有实现都是自己写的
但也有评论者持保留态度，认为判决的"变革性"标准仍然模糊，未来可能引发更多诉讼。
结语
谷歌诉甲骨文案堪称"软件版权领域的世纪审判"。最高法院的判决确认了一个重要原则：API的复制，如果是出于互操作性和创新目的，且未实质性损害原作品的市场，可能构成合理使用。
这一判决不仅解决了谷歌和甲骨文之间的争端，更为整个软件产业划定了清晰的边界：功能性的接口可以自由实现，创造性的表达仍需尊重。在软件日益成为基础设施的今天，这一平衡显得尤为重要。
对于开发者而言，这一判决意味着可以更加放心地构建兼容性软件、开源替代品和跨平台工具，而无需担心因API兼容而陷入版权诉讼。
原文链接：https://www.supremecourt.gov/opinions/20pdf/18-956_d18f.pdf