背景

本站上线即将抵达第一个年头，老朋友们应该知道，本站的博客主题 zola-theme-jiaxiang.wang 是站在“巨人的肩膀”上，由我移植自开源项目 halo-theme-hao ，博客设计延用了张洪博客的精美设计。

在张洪博客的文章中，我注意到关于“主题授权”的说明，并提到“不再新增授权主题”。作为后来者，本站的博客主题是否需要获得张洪本人的授权？是否存在侵犯他人知识产权的风险？

走得稳，才能走得远。

今天我们深入研究一下这个课题。

前世今生

在开始前，我们需要梳理本站的博客主题的前世今生。

涉及到的博客主题如下：

他们的关系是：

起源主题，是一个Hexo的开源主题叫做 hexo-theme-melody，后来衍生出魔改的开源主题 hexo-theme-butterfly，再后来，张洪对 hexo-theme-butterfly 进行了魔改，形成自己的闭源张洪博客。

由于张洪主题的设计精美，备受欢迎，在博客圈有许多人“抄作业”，后来有一些开发者在得到张洪的授权后，形成了多个近乎完全复刻张洪主题设计的开源主题，其中之一是 halo-theme-hao。

去年建站之初，我计划采用张洪博客的设计，并基于 halo-theme-hao 主题的代码进行移植，最终发布了基于 Zola 静态网站生成器的开源主题 zola-theme-jiaxiang.wang。

博客上线后，我对于开源主题的计划是使用简单且无需维护的工具（更新、依赖、插件等），构建体验优秀的博客站点，提供长期的维护。

法理分析

开源协议解读

在分析之前，需要简单理解本文主题涉及到的开源协议。

• AGPL3.0 使用其代码的服务哪怕跑在网络上，也必须开源所有修改代码。
• GPL3.0 使用其代码的任何项目，都必须以相同协议开源整个项目。
• Apache2.0 允许自由使用和修改，但需要明确标注修改和专利声明。
• MIT 几乎无限制，只要在软件中包含原协议和版权声明即可随意使用。
• 996ICU 严格意义上非开源协议，是反对996工作制的抗议许可证，核心是阻止违法公司使用相关代码。

在开源社区中，开放性高的协议往往可以被衍生项目流转到开放性低的协议，例如MIT协议的上游项目可以衍生出GPL3.0协议的项目，但是若反过来，则违反了开源协议的约束，因为MIT的开放性强于GPL3.0。

在实践中，开源协议的条款和约束被大多数国家和地区的法律所支持。

代码资源的权利链条

按照时间顺序，本站主题的上游开源权利链条如下：

hexo-theme-melody 起源主题衍生出 hexo-theme-butterfly 张洪上游主题，这个过程是从原MIT协议的项目衍生出Apache2.0协议的项目。张洪上游主题诞生之后，起源主题修改协议为996ICU协议，新的996ICU协议没有声明开源权利，只是禁止996公司使用其代码。然而，由于协议变更发生在张洪上游主题诞生后，因此张洪上游主题不受后发生事件的影响。综上，张洪上游主题遵守了上游开源协议的要求，开源协议流转到Apache2.0满足开源社区公约，在下文的分析中不再涉及本主题。

hexo-theme-butterfly 张洪上游主题衍生出张洪博客主题，这个过程是Apache2.0协议的项目被衍生出闭源的项目，根据Apache2.0协议的规则，张洪主题的闭源衍生遵守了开源协议的要求，作者拥有新增/修改部分代码的著作权，在下文的分析中不再涉及本主题。在张洪博客中，采用了自行设计的拥有著作权的图标等美术素材，张洪在博客中特别声明了这部分设计资源需要授权才能使用。

张洪主题衍生出一系列复刻设计的开源主题，其中之一是 halo-theme-hao 上游主题，采用GPL3.0开源协议。张洪主题的衍生开源主题获得了张洪的授权（原文链接：https://blog.zhheo.com/update/ ），授权的细节我们不得而知，但由于发生了授权的行为，且出现了授权后的GPL开源项目，就构成了张洪主题的权利释放，自愿将其拥有的那部分私有代码放入了GPL的开源框架下。

这个操作不可逆，一旦代码以GPL发布，任何人都获得了GPL赋予的四大自由（使用、复制、修改、分发），无需再追溯征求原始作者的同意。

halo-theme-hao 上游主题衍生出了本站主题 zola-theme-jiaxiang.wang ，本站主题的开源协议，在上游主题的GPL3.0基础上，流转到APGL3.0协议，进一步限制了商用范围。在开源协议方面，从GPL3.0到AGPL3.0的转递满足开源社区公约，并且符合从自由到限制的开源协议转递方向。

总结，在代码资源方面，本站主题只需对上游主题的GPL3.0开源协议负责，而无需获取张洪主题、张洪上游主题、起源主题等项目的许可。

设计资源的单独说明

在张洪主题中，特别说明了对于其原创美术设计成果（图片、图标、表情、形象等）的权利所有，在其授权衍生主题中（如上游主题），均没有直接集成张洪主题的原创美术设计资源。

同样，本站主题没有使用张洪主题的设计素材，所以在设计资源方面，本站主题没有这方面风险。

软件著作权是否保护设计布局样式

在上一章，我们分析了美术设计的权利说明，但是我想作者的本意，应该指的是更广义的设计，包括UI设计（布局、样式）、交互设计（动画、特效）等，在张洪博客中，提到了关于设计的保护：

设计作为主题的最基础部分，如果发现其他主题未经授权盗用、分发并违法盈利，欢迎联系举报。

为了强调自身权利，原文还附上软件著作权证书。对于创作者来说，作品相关权力自作品诞生后自然存在，但创作者为了保护自身合法权利、强调完成时间还是要花钱申请证书，心感悲哀。

回到本站主题，上文已经完成对代码的权利分析，那么代码的运行产物──UI界面，是否受到软件著作权的约束呢？

当然！

然而，由于张洪博客授权了开源衍生项目，使用权被释放。只要是通过开源主题合法衍生出来的，代码的使用、UI的相同也是被许可的。

还是从上游主题的GPL3.0协议出发，GPL协议通常被认为覆盖了程序本身。如果上游项目的前端代码（HTML/CSS/JS）生成了特定的UI，那么这个UI设计通常被视为包含在GPL授权范围内。

张洪博客授权衍生主题时，实际上也开放了张洪博客的设计风格和视觉呈现的使用权。 一旦设计以GPL发布，社区就有权复刻这个设计，包括用完全不同的技术栈去复刻。

总结，本站主题是通过上游主题的开源协议合法衍生出来的，虽然软件著作权保护张洪博客的著作权，但是本站主题还是只对上游主题负责，软件著作权无法影响到原作者授权的开源项目的衍生作品。

其他风险

张洪主题的授权撤回

本站主题的合规性依托上游主题的开源许可，如果上游主题出现许可问题（如撤回许可等），本站主题是否会被影响呢？

并不会。当软件以开源许可证的形式发布后，该授权在法律上通常被视为一种不可撤销的许可。任何已经根据该许可证获得源代码的人，都有权继续使用、修改和分发该开源版本，无法追溯性地剥夺他们已获得的权利。

甚至可以归纳成，本站主题自衍生后，只要符合上游GPL协议框架，且无美术设计方面的版权问题，就没有合规问题的担忧。

张洪主题的新功能复刻

张洪主题对衍生主题的授权是其较早版本的代码，随着张洪主题的更新，新版并没有持续授权。也就是说，将会出现断档，开源衍生版的张洪主题将越来越落后。

那么，如果直接从张洪主题复刻未来的新功能，是否侵权？

还是回到软著本身，著作权的核心原则是保护“表达（代码）”，不保护“创意（功能）”。举个栗子：未来，张洪主题实现了一个新功能，广大粉丝想“抄袭”到自己的博客，如果粉丝直接复制张洪主题的代码并实现了新功能，则构成了侵权，而如果自己写代码实现了相同的新功能，则不构成侵权。

有一个词叫“净室技术”，即不同的人员，在隔离环境下，仅参考功能效果而独立编写代码，在这里就能用于规避版权问题。很多游戏玩法的互相抄袭也是因为“净室技术”的合法性导致维权困难。

总结，照着功能自己写，不侵权，直接复制代码，侵权。

另，单独说明的美术设计需单独授权。

如何强化软件作品的版权保护

随着分析，我们不仅明确了本站主题的合规性，同时也能认识到如何更好地保护自身软件作品的版权。

• 保护业务逻辑和功能，申请软件著作权。
• 保护网站外观设计，同时申请作品著作权。
• 在公开上线之前，申请外观设计专利。
• 如果希望免费使用并且保留最终控制权，不要流入开源社区，以免造成不可逆的权利释放。

如何优雅衍生/Fork开源项目

虽然开源协议开放了软件许可，但作为后来者，我们需要保持对上游的尊重，特别是我们打算开辟一个衍生项目时。

最简单的方法时保留致谢，在衍生项目的 README 或 LICENSE 文件中明确注明上游项目， 这既是法律上的归属声明要求（很多开源协议要求注明），也是开源社区的礼仪。

结论

基于本文的讨论范围和上文的分析结果，本站主题没有法律上的风险。

我们走在前人开辟的道路，站在巨人的肩膀上，应饮水思源，心怀感恩，主动维护前人的权益。

另外，作为业余音乐人，作品的版权保护是我长期关注的领域。一方面，希望自己的作品被广泛传播，另一方面，也希望作品的合法权益得到保护。

回想起几十年前的在线音乐产业，那时音乐版权保护匮乏，但也让草根歌手脱颖而出，让优秀作品流传更大群体范围，产生了时代的旋律。

今天，版权保护带来了垄断，但音乐人的受益增加了吗？音乐新人的成长环境真正得到改善了吗？

也许，作品的传播和收益，是一种平衡的艺术。

作为法律爱好者，这篇文章仅从几个简单的角度对开源权利和设计成果分析，目的是为了识别自身的法律隐患，法律知识参考了多个AI模型，非专业意见，如有不当之处，请多多谅解。

欢迎在评论区讨论。