深色模式
协议包含
ZSFT 会在下载包内绝对性的包含字体授权许可,以便作为字体授权许可的凭据。
但因为字体各异,所以在这里列出目前 ZSFT 应对不同情况的处理方法。
正式协议
使用 OFL、MIT、Apache 等正式法律许可协议或字体所有者所编写的自定许可协议会被视为正式协议。
使用正式协议的字体会在下载包内提供一个正式的法律许可协议文本文件(或文件内包含许可协议段落),其名称通常是:
- LICENSE
- LICENSE.txt
- LICENSE.md
- README
- README.txt
- README.md
也可能是字体所有者的其它命名,我们会尊重并保留这一点,它们通常以
.txt
或.md
结尾。
当权威文本使用非 UTF-8 编码时导致乱码时,下载包内会额外提供一份 UTF-8 编码修复的副本。
- README_ZSFT UTF-8 Fix.txt
- [Example]_ZSFT UTF-8 Fix.txt
- [Example]_ZSFT UTF-8 Fix.md
如果许可协议权威文本文件丢失但字体元数据中仍然可用时,下载包内会提供一份从字体元数据中提取的字段文件:
- metadata.txt
其中通常包含版权信息、设计师、描述信息、许可协议等。
非正式声明
对于字体所有者在公开发布字体时,并没有声明使用正式协议,也没有专门编写许可协议,而是在发布的文章中表示出允许行为、限制、免责声明等信息时,会被视为非正式声明。
不同于 ZSFT 中的作者声明,因为有时,作者声明是一个正式的自定许可协议。
这时,下载包内会额外提供一份字体发行页面的快照:
- ZSFT-Image_[YYYY]_[MM]_[DD].jpeg
快照是字体的发行说明,其中包括所有者的 “非正式声明”。
FontsAPI 协议包含
当字体的 FontsAPI 以 CSS 方式提供时, result.css
文件顶部的注释通常会包含字体的所有元数据。
除非字体所有者显式决定抛弃注释以便更简洁的 result.css
调用, ZSFT 尊重这一点。