首页
/ RealWorld 开源仓库的第三方框架 Logo 许可与商标合规:frameworks.svg 的 LICENSES_LOGOS.md 深度解读

RealWorld 开源仓库的第三方框架 Logo 许可与商标合规:frameworks.svg 的 LICENSES_LOGOS.md 深度解读

2026-09-04 18:13:39作者:劳婵绚Shirley

RealWorld 仓库的 README 顶部嵌有一张在五个框架 Logo 之间循环轮播的动画 SVG(frameworks.svg)。当你在一个 MIT 许可的开源仓库中内嵌 Angular、React、Vue.js、Django、Hono 五个第三方框架的 Logo 时,这张合成图究竟受什么许可约束、哪些使用方式有商标侵权风险?仓库中的 LICENSES_LOGOS.md 正是对此的逐条合规分析。读完本文,你将掌握:逐 License 判定第三方素材的方法、"最限制性条款"合成作品推导逻辑,以及"商标政策 + 许可证"双轨约束下的合规实操清单。

frameworks.svg 动画在 Angular、React、Vue.js、Django、Hono 五个框架 Logo 之间循环轮播

文档定位与适用边界

docs/non-included/LICENSES_LOGOS.md 开头有明确的免责声明:该文档由 Claude (Anthropic) 生成,仅供参考,不构成法律建议,正式法律问题需咨询合格律师。它的职责边界是:覆盖 frameworks.svg 这张动画 SVG 中用到的五枚框架 Logo 的许可与商标状态

仓库中两处引用点可以佐证这份文档的实际作用:

  • LICENSE 末尾显式声明:assets/media/frameworks.svg 中的第三方框架 Logo 不受本 MIT 许可证覆盖,需查阅 docs/non-included/LICENSES_LOGOS.md 了解各自许可与署名要求。也就是说,仓库整体是 MIT,但这张合成图被刻意"剥离"出仓库许可证的适用范围,单独按各 Logo 原始许可处理。
  • README 第 52 行也以链接形式指回该文档,向所有浏览者公示 Logo 许可细节。

值得注意的细节:该文档位于 docs/non-included/ 目录。从 docs/astro.config.mjs 的侧边栏配置看,Astro Starlight 文档站只收录 implementation-creationspecificationscommunity 三组页面——non-included 目录并不在其中。可以推断,这个目录的命名语义就是"仓库保留但不发布到文档站"的元文档,LICENSE 合规文档正属于这一类。

五枚 Logo 的逐条许可判定

文档按 Logo 逐一给出了许可证类型、来源渠道与使用要求,这是整篇文章的核心事实基础。

CC BY 4.0 系:Angular 与 React

  • Angular:CC BY 4.0(Creative Commons Attribution 4.0 International),素材来源为 Angular 官方 press kit;要求署名 Google;"ANGULAR" 为 Google LLC 的注册商标。
  • React:CC BY 4.0,素材来源为 facebook/react 仓库(react.dev repo);要求署名 Meta Platforms, Inc.;React 的名称与 Logo 均为 Meta Platforms, Inc. 商标。文档特别注明:这一许可状态在 facebook/react 的 issue #12570 中得到官方确认。

两者均为宽松的"署名即可"型许可,是五个 Logo 中风险最低的一档。

CC BY-NC-SA 4.0:Vue.js

Vue.js Logo 的许可明显更严格:

  • 许可证:CC BY-NC-SA 4.0(署名-非商业性使用-相同方式共享 4.0),素材来源为 vuejs/art 仓库;
  • 要求:署名、禁止商业性使用、衍生作品须以相同(或兼容)方式共享;
  • 显式允许:与 Vue.js 相关的开源/非营利项目使用——这一点正是 RealWorld 这类 demo 仓库能够合规使用 Vue Logo 的关键依据;
  • 商标:VUE.JS 为 Evan You(尤雨溪)持有的美国注册商标。

这一条是整个 SVG 合成图中唯一的"非商业 + 相同方式共享"来源,直接决定了合成图的有效许可(见后文"合成 SVG 的有效许可"一节)。

纯商标政策管辖:Django

Django 是唯一没有开放许可证的 Logo,受 Django Software Foundation (DSF) 的商标政策约束,素材来源为 djangoproject.com 的社区 Logo 页面:

  • 要求:不得暗示得到 DSF 的背书(endorsement);不得修改 Logo(颜色、比例、附加文字均不可动);
  • 商标:Django Software Foundation 的注册商标。

frameworks.svg 源码可以看到,Django 一栏直接内嵌了来自 djangoproject.com 的官方 negative logo(深绿 #092E20 底 + 白色字标),保持原色原比例,仅在外层 <g> 上叠加了透明度动画——这正好对应后文风险表中"仅使用最小化淡入/淡出动画、Logo 视觉上未改动"的合规说明。

MIT / CC0:Hono

Hono Logo 的许可最宽松:

  • 作为 honojs/hono 仓库 docs/images 目录的一部分,遵循 MIT,要求保留 MIT 版权声明;
  • 同时在第三方集合(gilbarbara/logos、Wikimedia Commons)中另有 CC0 1.0(公有领域) 版本可用。

frameworks.svg 中的注释明确写着 Official Hono logo from Wikimedia Commons (CC0),说明仓库实际采用的是 CC0 公有领域版本,连署名义务都进一步弱化了(尽管文档仍保留了对 Hono 作者 Yusuke Wada 的署名,属于更稳妥的做法)。

合成作品推导:为什么有效许可是 CC BY-NC-SA 4.0

frameworks.svg 是一张将五枚 Logo 合在一起的衍生作品(derivative work)。文档给出的推导原则是:对合成作品适用"最限制性且兼容的条款"(most restrictive compatible terms)。由此逐条展开出六项治理约束:

约束 来源 影响
署名 (Attribution) Angular、React、Vue、Hono 必须为全部项目及其各自权利人署名
非商业 (NonCommercial) Vue.js(CC BY-NC-SA 4.0) 该动画 SVG 不得用于商业目的
相同方式共享 (ShareAlike) Vue.js(CC BY-NC-SA 4.0) SVG 的衍生作品须采用 CC BY-NC-SA 4.0 或兼容许可
不得修改 Django(商标政策) SVG 中的 Django Logo 必须保持未修改状态(颜色、比例)
链接要求 Django(商标政策) "凡技术上可行处" Logo 应链接到 djangoproject.com——在循环动画的 SVG 中,为单帧 Logo 建立专用超链接技术上不可行,故该条在此场景不适用
不得暗示背书 全部(商标) 不得暗示与任何项目存在官方关联

综合下来,文档给出的有效许可结论是:CC BY-NC-SA 4.0,附加 Django 的商标约束。具体含义:

  • 可以免费分享与改编,但仅限非商业用途;
  • 必须为全部五个项目署名
  • 衍生作品须以相同许可(或兼容许可)共享;
  • Django Logo 部分必须保持未修改,并在技术上可行时链接到 djangoproject.com;
  • 使用方式不得暗示任何项目的官方背书

这里有一个典型的许可叠加推演:CC BY 4.0(Angular/React)、MIT/CC0(Hono)都可以并入 CC BY-NC-SA 4.0 的组合框架,但 Vue.js 的 NC(非商业)与 SA(相同方式共享)条件无法被放松;Django 则不走许可证轨道,而以商标政策的"不可修改 + 不背书 + 尽量链接"三条附加义务形式叠加。最终约束集 = 五者并集中最严的那一份。

风险评级与落地建议

文档给出的逐 Logo 风险评级表:

Logo 风险 说明
Angular CC BY 4.0 非常宽松
React CC BY 4.0 非常宽松
Vue.js 显式允许开源项目使用
Django 仅商标政策管辖;Logo 参与动画可能被视为"修改"。仓库仅使用最小化的淡入/淡出动画,视觉上未改动 Logo
Hono MIT / CC0,最宽松

基于该评级,文档给出的使用建议共四条,对任何想复用此类"多 Logo 合成图"的仓库都有参考价值:

  1. 保留 LICENSES_LOGOS.md 在仓库中作为署名载体;
  2. Django Logo 不得被扭曲、重着色或视觉改变(淡入/淡出可接受);
  3. 技术上可行时让 Django Logo 链接到 djangoproject.com;
  4. 仓库不得暗示五个项目中任何一方的官方背书。

从 SVG 源码验证"动画未修改 Logo"的承诺

Django 被评为唯一"中风险",理由是"动画可能被视为修改"。frameworks.svg 的实现可以印证仓库确实把动画限制在了商标政策允许的范围内:

  • 整图采用 SMIL 声明式动画,<svg viewBox="0 0 720 100">,注释写明动画规格为"12 秒一个循环,5 个状态,左右交替切换;每个状态 2s 停留 + 0.4s 过渡(先 0.2s 淡出、再 0.2s 淡入,无重叠)";
  • Django 分组 为例,<animate attributeName="opacity" dur="12s"> 配合 keyTimes="0;0.3667;0.3833;0.7833;0.8;1" 控制该 Logo 在 0.4s 与 9.6s 两个 0.2s 窗口内做 0→1 或 1→0 的透明度渐变;配套的 animateTransform(type="translate")只让 Logo 在 y = ±15 之间做位移动画;
  • Logo 本体(#092E20 深绿矩形 + 白色 "DJANGO" 字标的官方 negative logo path)仅被 translate(482, 23) scale(0.25) 整体缩放摆放,颜色、比例、文字均未做任何改动

"透明度 + 位移动画不改 Logo 内容物"这一实现方式,与文档风险表中"minimal fade-in/out animation only, keeping the logo visually unaltered"的表述逐字对应——这正是把商标政策下唯一的"中风险"项压到可接受水平的工程做法。

同样的模式应用于其余四枚 Logo:Angular 使用 2023 官方渐变(#F72585#9C27B0SVG 第 3-7 行linearGradient 定义)加官方 lockup path;React 为官方 #61DAFB 原子轨道图形;Vue 为 #34495E + #41B883 双层 V 字形 path;Hono 为 Wikimedia Commons 的 CC0 官方 Logo。五组 Logo 通过错开的 keyTimes 区间在左右两个 slot 中接力显示,中间以一个 shuffle 图标衔接。

署名清单(Attribution)

文档末尾的署名区块是合规落地的最小必备内容,任何转载该合成 SVG 的地方都应当完整保留:

  • Angular logo by Google — CC BY 4.0
  • React logo by Meta Platforms, Inc. — CC BY 4.0
  • Vue.js logo by Evan You — CC BY-NC-SA 4.0
  • Django logo by the Django Software Foundation — Trademark Policy
  • Hono logo by Yusuke Wada — MIT License

其中 Angular、React、Vue、Hono 四个条目的署名义务直接来自其 CC/MIT 许可证,Django 条目则来自商标政策惯例——把商标素材也纳入统一署名清单,是文档对"Attribution 覆盖全部五方"这一约束的执行方式。

方法论小结:在开源仓库中内嵌第三方 Logo 的通用路径

虽然本文事实主体是 RealWorld 仓库的 LICENSES_LOGOS.md,但其分析框架对所有需要展示第三方品牌素材的开源项目都成立:

  1. 逐素材查原始许可:优先找官方渠道(press kit、官方仓库、官方商标政策页),并尽量找到官方书面确认(如文档中 React 许可的 issue 佐证);
  2. 区分"许可证"与"商标"两条轨道:CC/MIT 管代码与图形文件的复制分发,商标政策管"使用方式"(不可修改、不可暗示背书、尽量链接)——Django 案例说明后者可能比前者更紧;
  3. 对合成作品取并集最严条款:任何一枚 NC 素材都会把整个合成物拉进非商业轨道,任何一枚 SA 素材都会给衍生作品上相同方式共享的锁;
  4. 用最小化动画/排版消化"不可修改"条款:透明度与位移动画不触碰 Logo 内容物,是当前 SVG 动画场景下的通行合规做法;
  5. 在仓库许可证中显式排除第三方素材(如 LICENSE 的 Note),并留一份 LICENSES_LOGOS.md 式的署名与合规文档随仓库分发。

需要重申的适用前提:上述结论全部基于 docs/non-included/LICENSES_LOGOS.md 当前的文档内容,且文档自身声明其由 AI 生成、仅供参考、不构成法律建议;商标政策与 CC 许可的官方解释以各权利方(DSF、Meta、Google、Evan You、Yusuke Wada)的最新公开政策为准,实际商用前请自行核实或咨询律师。

登录后查看全文
热门项目推荐
相关项目推荐

项目优选

收起
kernelkernel
deepin linux kernel
C
33
18
ops-transformerops-transformer
本项目是CANN提供的transformer类大模型算子库,实现网络在NPU上加速计算。
C++
1.12 K
2.72 K
ops-nnops-nn
本项目是CANN提供的神经网络类计算算子库,实现网络在NPU上加速计算。
C++
903
1.82 K
docsdocs
暂无描述
Markdown
888
5.78 K
pytorchpytorch
作为 Ascend for PyTorch 社区的核心组件,TorchNPU 是昇腾专为 PyTorch 打造的深度学习适配插件,使 PyTorch 框架能够直接调用昇腾 NPU,为开发者提供昇腾 AI 处理器的超强算力。
Python
854
1.34 K
kernelkernel
openEuler内核是openEuler操作系统的核心,既是系统性能与稳定性的基石,也是连接处理器、设备与服务的桥梁。
C
527
590
jiuwenswarmjiuwenswarm
JiuwenSwarm 是一款基于openJiuwen开发的智能AI Agent,它能够将大语言模型的强大能力,通过你日常使用的各类通讯应用,直接延伸至你的指尖。
Python
3.51 K
1.01 K
ops-mathops-math
本项目是CANN提供的数学类基础计算算子库,实现网络在NPU上加速计算。
C++
1.33 K
1.45 K
AscendNPU-IRAscendNPU-IR
AscendNPU-IR是基于MLIR(Multi-Level Intermediate Representation)构建的,面向昇腾亲和算子编译时使用的中间表示,提供昇腾完备表达能力,通过编译优化提升昇腾AI处理器计算效率,支持通过生态框架使能昇腾AI处理器与深度调优
C++
540
384
flutter_flutterflutter_flutter
本仓库是 Flutter SDK 与 Flutter Engine 的 OpenHarmony 适配版本,由 CPF-Flutter 团队维护。开发者可使用熟悉的 Flutter 技术栈开发 OpenHarmony 应用,3.35.7 及以后的适配版本可基于本仓库源码构建支持 OpenHarmony 的 Flutter Engine。
Dart
1.17 K
341