Build-in SIL licensing in FontForge

Problem

When the font is generated from the FontForge project, in this case a TTF file, the copyright/licence is incorrect because the SIL 1.1 licence is not displayed/integrated and is therefore not valid.

Context

Solution 1:
Set the copyright to a disclaimer stating that SIL 1.1 is used and a copy of the licence is provided as a separate file.

Solution 2:
FontForge has a built-in feature for adding a SIL 1.1 licence, which is then also integrated into the generated TTF font file.

It is important that you only have a SIL 1.1 licence or direct copyright. However, I would always recommend the SIL 1.1 solution, which is integrated into the font, as the licence is then part of the font itself. This is secure and robust. The goal of the entire SIL 1.1 licence in this project is to have it at the end for the final generated font.

More details -> #30 (comment)

Please give an overview of the problem which needs to be solved.

I noticed SIL recommends including the license in the font itself: https://openfontlicense.org/how-to-apply-the-ofl/

I guess this is probably because a .ttf is likely to become isolated (e.g. someone copies the font into their web project... I definitely have done this!)

Maybe this hints at a problem statement kaj? 😄

That's what I meant. The SIL must be included in the font itself. That's why I mentioned using the built-in function for this in FontForge. Otherwise, the generated font will not be correctly licensed. This will replace the whole copyright with the new SIL 1.1 licence. I hink you have to add the contributors by your self in this process. There is also the scripts.sil.org/OLF button, maybe thats the automatic way of doing this.

When I read the actual OFL text, it seems like the license can be distributed alongside the "Font Software" and not necessarily inside the font itself:

Original or Modified Versions of the Font Software may be bundled,
redistributed and/or sold with any software, provided that each copy
contains the above copyright notice and this license. These can be
included either as stand-alone text files, human-readable headers or
in the appropriate machine-readable metadata fields within text or
binary files as long as those fields can be easily viewed by the user

🤷

But SIL's informal recommendation suggests putting the license inside the font, and doesn't explain exactly why...

@kaj-se

Anyway @kaj-se if you think you can describe what the problem is, edit the issue up top and write

### Problem

...

### Context

...

The Problem is the important part 😉

Edited the Problem, hope it's clear now.

Hmm ok but

the copyright/licence is incorrect because the SIL 1.1 licence is not displayed/integrated and is therefore not valid.

But OFL license says itself that

These [the copyright notice and this license] can be included [...] as stand-alone text files [...]

How do you conclude that the license is "not valid" if not included in the .ttf file itself?

If you say the problem is "it's better to include the license inside the font because what if someone distributes the font without distributing the license" then I agree 😄

@kaj-se

Extra clarification: the "add OFL" button doesn't change the Copyright field at all. Instead it adds a License and License URL field (as recommended in SIL's informal recommendations).

If I understand correctly, the Copyright field is correct as is no matter the license. After your PR, it will be incomplete if it doesn't mention you, @kaj-se! (I guess?)

(Oops misclick.)

Side question: do the .woff and .woff2 binaries include the "TTF Names" metadata? I think probably not:

user@computer:~/Documents/hm/white-bunnybat$ strings release/white-bunnybat.ttf | grep Matt
 1999 by Matthew Welch - Copyright 
user@computer:~/Documents/hm/white-bunnybat$ strings release/white-bunnybat.woff | grep Matt
user@computer:~/Documents/hm/white-bunnybat$ strings release/white-bunnybat.woff2 | grep Matt

It would be convenient to track copyright/licensing only in the git repo. This is perfectly "valid," as far as I can tell???

But if the .ttf ends up getting redistributed by itself -- in violation of the OFL license -- this would be unfortunate.

I think this is the reason the Copyright and License TTF fields exist and are recommended by SIL, even though not required by the actual license...

The other reason is that TTF is just the most commonly used font format over the past decades! There is no "WOFF Names" tab in Fontforge?

Ok actually there is a WOFF tab:

TL;DR:

I think the issue could be rehabilitated as:

The ttf file is likely to be redistributed in isolation, in violation of the OFL license. Therefore we should set the License and License URL fields in the ttf metadata.

There can also be another issue:

The .woff/.woff2 files are likely to be redistributed in isolation, in violation of the OFL license. Therefore we should put something in the metadata XML (??)

But these files are, I guess, somewhat less likely to be redistributed in isolation?

However... if we are worried about binary fonts being redistributed in isolation, and hoping that some metadata will provide copyright/license info, shouldn't the metadata point back to https://github.com/comcode-org/white-bunnybat? For example, shouldn't the hypothetical user who received a .ttf/.woff/.woff2 file in isolation be able to find Matthew Welch's original MIT-like license??

@hmdunce

The following is my interpretation of rights and licences.

To ceep in mind, this repo is open and everyone can take the SFD file and generate the font them self!

SIL OPEN FONT LICENSE Version 1.1
[...]
PERMISSION & CONDITIONS
[...]
2) Original or Modified Versions of the Font Software may be bundled,
redistributed and/or sold with any software, provided that each copy
contains the above copyright notice and this license. These can be
included either as stand-alone text files, human-readable headers or
in the appropriate machine-readable metadata fields within text or
binary files as long as those fields can be easily viewed by the user.
[...]
TERMINATION
This license becomes null and void if any of the above conditions are
not met.

This means all font files (TTF, OTF, WOFF, EOT, SVG, ...) must include all copyright and license information in their metadata fields, or you place the license, copyright, statement of modification and readme files at the place where the font files are located, because they will be sold/redistributed by the game itself if you use them in there. But it would be the easiest to put them in the metadata; that's why SIL recommended that.

How do you conclude that the license is "not valid" if not included in the .ttf file itself?

@hmdunce, if the font is generated the licence is not valid because of the incorrect copyright, the missing OFL 1.1, missing readme and missing "Statement of Modification", in metadata or as files.

If I understand correctly, the Copyright field is correct as is no matter the license. After your PR, it will be incomplete if it doesn't mention you, @kaj-se! (I guess?)

That is what I was trying to point out. But it is still not valid because of the missing parts I mentioned above. It's not about if someone wants to be in the copyright; it's a must, unless a copyright transfer agreement is being signed, and this would be far too complicated. Therefore, ALL contributors must have their own copyright line, as required.

To address @hmdunce question of

"[...] shouldn't the hypothetical use [...] in isolation be able to find Matthew Welch's original MIT-like license?"

The "Statement of Modification" needs to be included; we can do it under a project name like "White Bunnybat Font Project" and list the contributors. You have something similar in the repo -> https://github.com/comcode-org/white-bunnybat/blob/main/NOTICE.txt
I personally would do it like that:

Copyright (c) 2026 White Bunnybat Font Project
  
This font is a modified version of "White Rabbit" by Matthew Welch
licensed under MIT License. This modified version is licensed under SIL OFL 1.1.  
  
Contributors:  
- [Contributor 1]  
- [Contributor 2]
- ...

The original MIT file of Matthew Welch is in the repo (https://github.com/comcode-org/white-bunnybat/blob/main/release/LICENSE_MatthewWelch-MIT.txt) that's good. It's important that ALL files from this archive (http://mattwelch.net/fonts/whitrabt.zip) are included in the repo. Those are license.txt, whitrabt.ttf and whitrabt.txt. The simplest way would be to make a folder named "whitrabt" and place the files from the archive in it. Then make a reference to that folder in the NOTICE.txt (https://github.com/comcode-org/white-bunnybat/blob/main/NOTICE.txt) file.

That's a lot to consider, but once we have it set up, we can use it everywhere. We should perhaps create a new issue to clarify the license issue before we add anything in the SFD file or so. This is also something important for the white-bunnybat repo.

Here the official link to the SIL Open Font License 1.1
https://interoperable-europe.ec.europa.eu/licence/sil-open-font-license-11

The licence is also available in various expot formats:
https://interoperable-europe.ec.europa.eu/licence/sil-open-font-license-11/rdf-export

The game situation is a separate and very different issue (not one for this repo.)

For this repo, I stand by this comment #33 (comment)

To be honest, I have no idea. Could you make a short list of things you think need to be done to achieve this?

@hmdunce

We can leave it as it is and Sean can merge it, so we can move on. And do more of what's missing. I know the licence issue can be sorted out to the point where we do real publishing or so. For testing purposes, we can refer back to https://github.com/comcode-org/white-bunnybat as mentioned by @hmdunce.

I could add a TTF field in FontForge with:
String ID Pre-Licence
String https://github.com/comcode-org/white-bunnybat

This one will need some additional review.
We are not at legal risk, as our repo is the source of truth and is set up correctly with the correct instructions for font consumers. My understanding of the issue / problem statement is: people could do it wrong in their usage.

What I don't want to do is introduce multiple sources of truth for the license (which could lead to very bad issues with them not being in sync if we change stuff.), so I'm definitely more interested in having a reference to license rather than duplicating.

Still need to come back to this issue, though. Let me know if I'm misunderstanding anything here.

The tag needs investigation is good. I mean, doing stuff as "Font Project" would be nice, so you can use the name of the Project with a link to the license and all other important files. I'm optimistic that we will find a good solution to that.

Navigation Menu

Repository navigation

Build-in SIL licensing in FontForge #33

Problem

Context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Build-in SIL licensing in FontForge #33

Description

Problem

Context

Activity

seanmakesgames commented on Feb 10, 2026

hmdunce commented on Feb 10, 2026

kaj-se commented on Feb 10, 2026

hmdunce commented on Feb 10, 2026

hmdunce commented on Feb 10, 2026

kaj-se commented on Feb 10, 2026

hmdunce commented on Feb 10, 2026

hmdunce commented on Feb 10, 2026

hmdunce commented on Feb 10, 2026

hmdunce commented on Feb 10, 2026

hmdunce commented on Feb 10, 2026

hmdunce commented on Feb 10, 2026

hmdunce commented on Feb 10, 2026

kaj-se commented on Feb 11, 2026

kaj-se commented on Feb 11, 2026

hmdunce commented on Feb 11, 2026

kaj-se commented on Feb 11, 2026

kaj-se commented on Feb 11, 2026

kaj-se commented on Feb 11, 2026

seanmakesgames commented on Feb 14, 2026

kaj-se commented on Feb 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions