Prioprietary fonts in test/data about fontkit HOT 21 CLOSED

+1

You also need to include the libre licenses alongside the libre fonts

from fontkit.

Yes, this is on my list to fix. My problem is that I need fonts that test a wide variety of features (OpenType, AAT, different scripts, different glyph formats, etc.). This means I need to either find open source test fonts or create them somehow. Especially for the AAT stuff, this could be challenging, and I'm not sure what the license is for fonts included with OS X. I thought of creating subsets of the fonts to only include glyphs used by the tests, which might be better, but I'm not currently aware of font subsetting tools supporting the AAT tables.

I'll work on this as soon as I can, but if you guys have any suggestions of ways I can fix this while still maintaining a full test suite, I would really appreciate it.

from fontkit.

Devon,

the fonts included with OS X are licensed under the terms of OS X. You cannot upload the OS X Yosemite DMG here, or any Apple-owned apps, and the same goes for fonts. You can have the fonts on the machine where your OS X is installed, you can create documents using them (including PDFs), but you cannot distribute the fonts standalone or bundled with any apps that you create. Most certainly, you cannot upload them to public forums or file sharing sites, which Github is. Also, most fonts you have in your test folder aren't actually property of Apple, they're licensed by Apple from other vendors such as Monotype. I sympathize with your goals, and I am willing to help, but every hour you keep the files up, you keep infringing the copyright for fonts created by my colleagues, so you're not helping :)

Best,
Adam

from fontkit.

from fontkit.

OK my mistake. Removed all the fonts for now, until I figure out what to do about this. Sorry!

from fontkit.

The following fonts from the https://github.com/google/fonts repo have a significant "morx" table. Noto Serif Khmer seems to be the only one that has not been authored with FontForge.
apache/nokora/Nokora-Regular.ttf
apache/notoserifkhmer/NotoSerifKhmer-Regular.ttf
ofl/angkor/Angkor.ttf
ofl/battambang/Battambang-Regular.ttf
ofl/bokor/Bokor.ttf
ofl/chenla/Chenla.ttf
ofl/content/Content-Regular.ttf
ofl/dangrek/Dangrek.ttf
ofl/freehand/Freehand.ttf
ofl/hanuman/Hanuman.ttf
ofl/kdamthmor/KdamThmor-Regular.ttf
ofl/khmer/Khmer.ttf
ofl/moul/Moul.ttf
ofl/nanumpenscript/NanumPenScript-Regular.ttf
ofl/play/Play-Regular.ttf
ofl/sarabun/Sarabun-Regular.ttf
ofl/suwannaphum/Suwannaphum.ttf
ofl/taprom/Taprom.ttf
ofl/tharlon/Tharlon-Regular.ttf

There is also Lateef Reg AAT available under an "freeware" license that allows redistribution, and a corresponding OT Layout font available under OFL, from
http://scripts.sil.org/Lateef

They're all non-Latin, though. It's possible to convert Latin fonts with OT Layout tables into AAT using FontForge but I've never tested the quality.

You may want to talk to Grzegorz Rolek who is interested in AAT and might be able to produce some AAT test fonts for you:
https://github.com/grzegorzrolek/narzedzia-sukcesu
https://github.com/grzegorzrolek/kif-compiler

from fontkit.

Ps. And I'll hook you up with some worthy Skia replacements soon ;)

from fontkit.

Great, thanks!

from fontkit.

small note here that might, or might not, be a problem - unless you delete the repo and then recreate it with the code as you have it right now (with the .git dir deleted and then rebuilt using git init) those files will still be in the git history, and available for download by navigating to an older commit in the project (git prune only works locally, pushing a pruned git log will not clear it on github.com). So if people check out the project, they will download those font files too as part of the full history clone (git clone --shallow won't grab them, but this is certainly not the way github recommends you clone a repo)

from fontkit.

Good point. I just used git filter-branch as described here to remove all references to the files from previous commits, while preserving the rest of the history. This should solve the problem.

from fontkit.

As far as I know that removes all traces of the files, by rewriting the history, but all the old commits (which are now orphan commits) still exist. People just need to know they exist to even get to them, so it's a pretty solid approach... I wonder if github finally added orphan commit deletion now, in which you're entirely good! Otherwise if anyone links to specific commits in your history (which are now orphaned) they might still find those fonts, since those commits will still be based on the original revision history rather than the pruned one. I think I'll fire off a mail to github to ask them to clarify what happens these days.

from fontkit.

I believe Github runs git gc periodically. Not sure how often.

from fontkit.

I have rewritten the tests using freely available fonts in #12. The readme in test/data lists them by license, and links to where you can find them online.

The only tests missing still are the AAT variation font tests, which currently only run if you're on a Mac, using the built-in Skia font. I hope to find some more variation fonts to test with at some point...

from fontkit.

I'm sorry to bug you about this but the SIL OFL and Apache license requires that the license be distributed alongside the fonts, so you do need to include a copy of the license files in that directory; 1 copy of the apache license, and separate copies of the OFL for each font family because of the peculiar way the OFL is written to reference the copyright notice of the fonts at the top of the document.

Also, the OFL has a "Reserved Font Name" option which, if you modify the fonts, requires you to rename the fonts to a name that does not include the reserved names in whole or in part; and you say

Note that the fonts may have been converted from their original formats for testing purposes.

so you should check the RFN requirements are being met in this case.

from fontkit.

Ugh, seriously? Seems like a link would be good enough. Can I at least put all of the licenses in a single file?

As for conversion to other formats, the only things I did were to make compressed WOFF/WOFF2 versions, and make TTC/dfont bundles. Both of these things do not modify the original fonts: if you decompressed/extracted them, they would be the same as the originals. This FAQ entry seems to say that this kind of conversion is OK without violating the Reserved Font Name requirement.

from fontkit.

That's the problem with licenses. for Apache, one copy is plenty, since it's generic. For SIL, however, the licenses are tied to individual families, so the actual license text itself contains the name of the family it applies to, and the copyright holder + contact information.

In terms of modification, the rules are a little more relaxed because these fonts are not "for distribution" but exclusively for testing so even though they get downloaded, they're not distributed "as fonts" but "as test data". Reasonably, they're not going to get installed (but if fontkit can ignore the permissions bits during testing, you could also make sure the fonts can't be installed from the test dir, by setting their permission bits to "you can't do anything with this font")

from fontkit.

from fontkit.

The TTC/dfont doesn't matter because it was of NotoSans, which is Apache licensed.

They specifically say WOFF is ok unless other modifications are made, in the FAQ. They don't specifically mention WOFF2, but it's the same idea (compressed font), so I don't see why it would be different. Do you have a source on that? If it is the case, I can just make a WOFF2 of one of the Apache licensed fonts.

from fontkit.

SIL’s opinions on how to interpret the Open Font License may have informational value but have no legal bearing. SIL merely authored the text of the license, and provide some explanations of their intentions.

The OFL license ( http://scripts.sil.org/OFL_web ) states “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.”

The phrase “contains the above copyright notice and this license” means that the copyright notice is not part of the license. If it were, there would be no “and”. So, according to the OFL, there are two textual elements that distributors need to take into account: the “copyright notice” and “the license” (this view is further strengthened by the word “These” in the subsequent sentence).

In fact, the license talks about “text files” when it refers to the “copyright notice and this license”. So the text of the license suggests that the copyright notice should be in a separate file from the license.

This is a bit contradictory to the “Using the OFL” explanatory section on http://scripts.sil.org/OFL that states “If you are the copyright owner you only need to do the following: Put your copyright and Reserved Font Names information at the beginning of the main OFL.txt file in place of the dedicated placeholders (marked with the <> characters). Include this file in your release package. [...]”. But that section only provides answers to “the copyright owner”.

Both the OFL text and the OFL FAQ ( http://scripts.sil.org/OFL-FAQ_web ) consistently talk about “either stand-alone files or metadata”. Section 1.10 of the FAQ states:
“Does the full OFL license text always need to accompany the font? The only situation in which an OFL font can be distributed without the text of the OFL (either in a separate file or in font metadata), is when a font is embedded in a document or bundled within a program. In the case of metadata included within a font, it is legally sufficient to include only a link to the text of the OFL on http://scripts.sil.org/OFL, but we strongly recommend against this. Most modern font formats include metadata fields that will accept the full OFL text, and full inclusion increases the likelihood that users will understand and properly apply the license.”

This answer makes it evident to me that the authors of OFL consider the link or full text of the OFL as put into the font file’s name table as being equivalent to providing a separate text file. The phrase “either in a separate file or in font metadata” makes it clear that both methods are considered fully equivalent.

Sections 2.2 and 2.8 address the question of “modification”. While the concept of Functional Equivalence is not part of the core OFL license text, the discussion provided by SIL clearly states their intentions. As such, in my opinion, simple packaging of OTF or TTF fonts in WOFF, WOFF2, TTC or .dfont containers results in functionally equivalent fonts. Those processes are fully reversible.

The only issue I’m aware of where packaging into WOFF, WOFF2 or TTC would modify the original font files in a non-functionally equivalent way is if the original font files contain a “proper” DSIG table (digital signature). As far as I can tell, there is no way to create a “functionally equivalent” font (in one of these other packaging flavors) from a font that has been digitally signed. The SIL FAQ says that functional equivalence happens if the “optimized” font “preserves original author, project and license metadata”. The digital signature is obviously an author metadata, and a strong one.

I would even go so far as to say that an OFL font author has three mechanisms to control what may or may not happen to their font:

• not use the RFN, in which case others can make any modifications of their font (including subsetting or converting to other formats) without changing the naming, as long as the results are also distributed under the OFL terms
• use the RFN, in which case others can make modifications that fulfil the criteria of “functional equivalence” without changing the naming (that would, in my opinion, include simple packaging into WOFF, WOFF2, TTC, .dfont), but any further changes (such as subsetting) require naming change
• use the RFN and a “proper” DSIG, in which any change requires naming change, because achieving “functional equivalence” is not possible with any kind of modification, even very lightweight.

But, just like Dave Crossland, I’m not a lawyer, so my opinions expressed above are just my personal views on the matter.

from fontkit.

Thanks for the info guys. I think I will make folders for each font family, and include the font files and the license text file in that folder. That's how the Google Fonts repo does it, and it seems to hit all the requirements of the SIL license.

The format conversions I made are very minor (compression and bundling) so I think it's probably fine, for the reasons listed above by Adam.

from fontkit.

Done. Hopefully that puts this issue to bed. 😜

from fontkit.