• Allegedly "open source" fonts and the DFSG

    From Pip Cet@21:1/5 to All on Sat Aug 10 18:40:01 2024
    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?

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Felipe Sanches@21:1/5 to All on Sat Aug 10 20:10:02 2024
    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 <[email protected]> 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?



    <div dir="ltr"><div>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.</div><div><br></div><div>If there&#39;s any specific case in
    which this is not true, I&#39;d be glad to learn about.</div><div><br></div><div>Given that, I think the lack of sources in this case is OK, because it is trivial to recompute them.</div><div><br></div><div>Let me know if you have additional information.<
    /div><div><br></div><div>cheers,</div><div>Felipe Sanches<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sáb., 10 de ago. de 2024 às 13:39, Pip Cet &lt;<a href="mailto:[email protected]">[email protected]</a>&
    gt; escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">My apologies if this issue has been discussed before or resolved<br>
    otherwise.<br>

    The Debian project contains TrueType fonts without sources. The &quot;source&quot;<br>
    packages provide .ttf files which contain binary information compiled<br>
    from secret sources.<br>

    This is not about the license the .ttf files are made available under;<br> it&#39;s about whether these distributions include source code, as<br>
    required by the DFSG and the OSI Open Source definition.<br>

    Fonts are, of course, nontrivial computer programs. In addition<br>
    (usually, see below) to the glyph outlines, which can be retrieved<br>
    from the TTF files, they contain a large amount of code and additional<br> data. For example, the &quot;fpgm&quot; table may specify a sub-program for<br> which source code is not available.<br>

    Some fonts even specify entire font families as &quot;variable font&quot;<br> programs which take various parameters, so the outlines are very<br>
    little help at all since they vary depending on the parameters, in<br> non-trivial, non-modifiable ways hidden in the binary files.<br>

    In particular, this affects at least the following fonts:<br>

    Noto CJK: in this case, something *closer* to the source is available<br>
    from Adobe&#39;s GitHub pages<br>
    (<a href="https://github.com/adobe-fonts/source-han-sans" rel="noreferrer" target="_blank">https://github.com/adobe-fonts/source-han-sans</a>), but even that font<br>
    (a Type 1 PostScript font packed in a CID) was produced by a<br> &quot;proprietary application&quot;<br>
    (<a href="https://blog.typekit.com/2014/08/14/interview-with-ryoko-nishizuka/" rel="noreferrer" target="_blank">https://blog.typekit.com/2014/08/14/interview-with-ryoko-nishizuka/</a>). I<br>
    believe it&#39;s highly likely this proprietary tool consumed additional<br> source data which is not available.<br>

    Noto Emoji Color: the GitHub repository indicates<br>
    (<a href="https://github.com/adobe-fonts/noto-emoji-svg?tab=readme-ov-file#generating-png-and-svg-files" rel="noreferrer" target="_blank">https://github.com/adobe-fonts/noto-emoji-svg?tab=readme-ov-file#generating-png-and-svg-files</a>)<br>
    that there are Adobe Illustrator files which constitute &quot;the original<br> Ai artwork&quot;. These files, which may include valuable information, are<br> not included, only SVGs and PNGs generated from them.<br>

    Droid Sans Mono: the font includes a non-trivial &quot;fpgm&quot; table which<br>
    changes the appearance of some glyphs.  No source code or instruction<br>
    for rebuilding this table has been made available.<br>

    It is not unusual for intermediate files to be independently editable;<br>
    for example, the Perl source code includes perly.c, which &quot;was<br> originally generated as an output from GNU bison version 1.875, but<br>
    now the code is statically maintained&quot;. In this case, as with the<br> fonts, complete source code includes both the original file and the<br> modified generated file.<br>

    Quite possibly, the source code to some or all of these fonts has been<br> lost. That means they cannot ever again meet the DFSG or satisfy the<br> &quot;Open Source&quot; definition, though of course the binary files remain<br>
    redistributable.<br>

    This issue is, of course, not about the &quot;encryption&quot; used by some<br> fonts.<br>

    Some questions raised by this are as follows:<br>

    1. What is the source code for fonts? Is there some argument that .ttf<br>
       files, by some process, become the source code even when they&#39;re<br>    generated from other sources?<br>

    2. Can we even know what the source code is without a statement by the<br>
       copyright holder, or even the original author?<br>

    3. What is the source code of a font which has been &quot;remastered&quot; based<br>
       on bitmaps produced from another font?  This is happening, for<br>
       example, at <a href="https://github.com/notofonts/noto-cjk-varco" rel="noreferrer" target="_blank">https://github.com/notofonts/noto-cjk-varco</a>.  Is this<br>
       a way to make a non-free font, such as, I suspect, Noto CJK/Source<br>
       Han, free again?<br>

    </blockquote></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Pip Cet@21:1/5 to Felipe Sanches on Sat Aug 10 21:00:01 2024
    "Felipe Sanches" <[email protected]> writes:

    As far as I can tell, the OpenType binaries have data structures that
    map 1:1 to their source project files,

    I don't believe that is true at all! I'm not quite sure what you mean by "source project files", to be honest. This is not about converting Type
    1 or TrueType to OpenType: it's about whether any of these formats can reasonably be considered source code, i.e. the preferred form for
    editing the program.

    so it is trivial to regenerate the sources from the binaries.

    Really? How, for example, do I generate the source code for the fpgm or
    prep programs contained in the Droid Sans Mono binary?

    I don't think it's trivial at all. It involves decompilation, just like
    any other compiled binary program without its source code available.

    If there's any specific case in which this is not true, I'd be glad to learn about.

    See the examples. The case of Noto Color Emoji is particularly clear,
    since it is the repository itself that explains how to build the SVGs
    from the "original Ai artwork" (their words, not mine) after,
    presumably, editing said original artwork files. I don't know whether
    those files contain additional valuable information beyond what is
    available in the SVGs, perhaps comments or a modification history, but I believe they do.

    Given that, I think the lack of sources in this case is OK, because it is trivial to recompute them.

    I must insist it is not. But that's not sufficient, anyway: a
    hand-written assembly program may be entirely re-derivable from its
    assembled form, assuming there are no comments or non-standard
    instruction mnemonics, but that doesn't make the binary the source code, because no programmer would edit the binary directly rather than
    reassembling it from a text file.

    Let me know if you have additional information.

    I'm not sure what information you require. Please let me know.

    Pip

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Felipe Sanches@21:1/5 to All on Sat Aug 10 22:00:01 2024
    If you prove me wrong I'll be happy to help you demand proper sources. But
    I haven't yet seen any need for that.

    Em sáb., 10 de ago. de 2024 às 16:37, Felipe Sanches <[email protected]> escreveu:

    The OpenType spec and its binary format encoding is, afaik, precisely 1 to
    1. There's not much magic (or optimization) left to be done. If you have
    the binary you effectively have the sources.

    Em sáb., 10 de ago. de 2024 às 15:39, Pip Cet <[email protected]> escreveu:

    "Felipe Sanches" <[email protected]> writes:

    As far as I can tell, the OpenType binaries have data structures that
    map 1:1 to their source project files,

    I don't believe that is true at all! I'm not quite sure what you mean by
    "source project files", to be honest. This is not about converting Type
    1 or TrueType to OpenType: it's about whether any of these formats can
    reasonably be considered source code, i.e. the preferred form for
    editing the program.

    so it is trivial to regenerate the sources from the binaries.

    Really? How, for example, do I generate the source code for the fpgm or
    prep programs contained in the Droid Sans Mono binary?

    I don't think it's trivial at all. It involves decompilation, just like
    any other compiled binary program without its source code available.

    If there's any specific case in which this is not true, I'd be glad to
    learn about.

    See the examples. The case of Noto Color Emoji is particularly clear,
    since it is the repository itself that explains how to build the SVGs
    from the "original Ai artwork" (their words, not mine) after,
    presumably, editing said original artwork files. I don't know whether
    those files contain additional valuable information beyond what is
    available in the SVGs, perhaps comments or a modification history, but I
    believe they do.

    Given that, I think the lack of sources in this case is OK, because it
    is trivial to recompute them.

    I must insist it is not. But that's not sufficient, anyway: a
    hand-written assembly program may be entirely re-derivable from its
    assembled form, assuming there are no comments or non-standard
    instruction mnemonics, but that doesn't make the binary the source code,
    because no programmer would edit the binary directly rather than
    reassembling it from a text file.

    Let me know if you have additional information.

    I'm not sure what information you require. Please let me know.

    Pip



    <div dir="ltr">If you prove me wrong I&#39;ll be happy to help you demand proper sources. But I haven&#39;t yet seen any need for that.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em sáb., 10 de ago. de 2024 às 16:37, Felipe
    Sanches &lt;<a href="mailto:[email protected]">[email protected]</a>&gt; escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">The OpenType spec
    and its binary format encoding is, afaik, precisely 1 to 1. There&#39;s not much magic (or optimization) left to be done. If you have the binary you effectively have the sources.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Em
    sáb., 10 de ago. de 2024 às 15:39, Pip Cet &lt;<a href="mailto:[email protected]" target="_blank">[email protected]</a>&gt; escreveu:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)
    ;padding-left:1ex">&quot;Felipe Sanches&quot; &lt;<a href="mailto:[email protected]" target="_blank">[email protected]</a>&gt; writes:<br>

    &gt; As far as I can tell, the OpenType binaries have data structures that<br> &gt; map 1:1 to their source project files,<br>

    I don&#39;t believe that is true at all! I&#39;m not quite sure what you mean by<br>
    &quot;source project files&quot;, to be honest. This is not about converting Type<br>
    1 or TrueType to OpenType: it&#39;s about whether any of these formats can<br> reasonably be considered source code, i.e. the preferred form for<br>
    editing the program.<br>

    &gt; so it is trivial to regenerate the sources from the binaries.<br>

    Really? How, for example, do I generate the source code for the fpgm or<br> prep programs contained in the Droid Sans Mono binary?<br>

    I don&#39;t think it&#39;s trivial at all.  It involves decompilation, just like<br>
    any other compiled binary program without its source code available.<br>

    &gt; If there&#39;s any specific case in which this is not true, I&#39;d be glad to learn about.<br>

    See the examples. The case of Noto Color Emoji is particularly clear,<br>
    since it is the repository itself that explains how to build the SVGs<br>
    from the &quot;original Ai artwork&quot; (their words, not mine) after,<br> presumably, editing said original artwork files. I don&#39;t know whether<br> those files contain additional valuable information beyond what is<br> available in the SVGs, perhaps comments or a modification history, but I<br> believe they do.<br>

    &gt; Given that, I think the lack of sources in this case is OK, because it is trivial to recompute them.<br>

    I must insist it is not. But that&#39;s not sufficient, anyway: a<br> hand-written assembly program may be entirely re-derivable from its<br> assembled form, assuming there are no comments or non-standard<br>
    instruction mnemonics, but that doesn&#39;t make the binary the source code,<br>
    because no programmer would edit the binary directly rather than<br> reassembling it from a text file.<br>

    &gt; Let me know if you have additional information.<br>

    I&#39;m not sure what information you require. Please let me know.<br>

    Pip<br>

    </blockquote></div>
    </blockquote></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)