As far as I can tell, the OpenType binaries have data structures that map 1:1 to their source project files, so it is trivial to regenerate the sources from the binaries.
If there's any specific case in which this is not true, I'd be glad to learn about. Given that, I think the lack of sources in this case is OK, because it is trivial to recompute them. Let me know if you have additional information. cheers, Felipe Sanches Em sáb., 10 de ago. de 2024 às 13:39, Pip Cet <pip...@protonmail.com> escreveu: > My apologies if this issue has been discussed before or resolved > otherwise. > > The Debian project contains TrueType fonts without sources. The "source" > packages provide .ttf files which contain binary information compiled > from secret sources. > > This is not about the license the .ttf files are made available under; > it's about whether these distributions include source code, as > required by the DFSG and the OSI Open Source definition. > > Fonts are, of course, nontrivial computer programs. In addition > (usually, see below) to the glyph outlines, which can be retrieved > from the TTF files, they contain a large amount of code and additional > data. For example, the "fpgm" table may specify a sub-program for > which source code is not available. > > Some fonts even specify entire font families as "variable font" > programs which take various parameters, so the outlines are very > little help at all since they vary depending on the parameters, in > non-trivial, non-modifiable ways hidden in the binary files. > > In particular, this affects at least the following fonts: > > Noto CJK: in this case, something *closer* to the source is available > from Adobe's GitHub pages > (https://github.com/adobe-fonts/source-han-sans), but even that font > (a Type 1 PostScript font packed in a CID) was produced by a > "proprietary application" > (https://blog.typekit.com/2014/08/14/interview-with-ryoko-nishizuka/). I > believe it's highly likely this proprietary tool consumed additional > source data which is not available. > > Noto Emoji Color: the GitHub repository indicates > ( > https://github.com/adobe-fonts/noto-emoji-svg?tab=readme-ov-file#generating-png-and-svg-files > ) > that there are Adobe Illustrator files which constitute "the original > Ai artwork". These files, which may include valuable information, are > not included, only SVGs and PNGs generated from them. > > Droid Sans Mono: the font includes a non-trivial "fpgm" table which > changes the appearance of some glyphs. No source code or instruction > for rebuilding this table has been made available. > > It is not unusual for intermediate files to be independently editable; > for example, the Perl source code includes perly.c, which "was > originally generated as an output from GNU bison version 1.875, but > now the code is statically maintained". In this case, as with the > fonts, complete source code includes both the original file and the > modified generated file. > > Quite possibly, the source code to some or all of these fonts has been > lost. That means they cannot ever again meet the DFSG or satisfy the > "Open Source" definition, though of course the binary files remain > redistributable. > > This issue is, of course, not about the "encryption" used by some > fonts. > > Some questions raised by this are as follows: > > 1. What is the source code for fonts? Is there some argument that .ttf > files, by some process, become the source code even when they're > generated from other sources? > > 2. Can we even know what the source code is without a statement by the > copyright holder, or even the original author? > > 3. What is the source code of a font which has been "remastered" based > on bitmaps produced from another font? This is happening, for > example, at https://github.com/notofonts/noto-cjk-varco. Is this > a way to make a non-free font, such as, I suspect, Noto CJK/Source > Han, free again? > >
