[Pkg-fonts-devel] Bug#851339: Bug#851339: Bug#851339: Bug#851339: Bug#851339: fonts-firacode: package in Debian with non-Debian build dependencies

[Paul Wise]

On Tue, Jan 17, 2017 at 10:29 PM, Fabian Greffrath wrote:

> But the OTF format itself is just as suitable a source format for fonts as
> any other format. Why is it so important what upstream has chosen? It is
> not that font composition is a human-readable-to-binary-one-way-road like
> compilation C source files into object code or HTML documentation to PDF.

FYI, you are mistaken that C code is always "source". C is sometimes
generated from other forms, via transpilers or lexer generators etc.
It can also be obfuscated C code from the real C source (cf #383465).

Likewise for HTML, it is often generated from templates or simple text
languages like markdown.

So like C, OTF can be source or not source, depending on the upstream project.

C to ELF is not a one-way process, there are disassemblers and decompilers.

Likewise for HTML and PDF. LibreOffice and other software can even edit PDF.

Likewise, the conversion from Glyphs to OTF definitely throws away
information. Even the conversion from Glyphsapp to UFO format (which
is sometimes used as a font source format) throws away information
according to the Glyphsapp documentation:

https://glyphsapp.com/tutorials/working-with-ufo

> Thought experiment: Would it feel more "correct" if I forked the firacode
> upstream project, converted their OTF files into fontforge's SFD format,
> checked these into a GIT repo and then distributed these?

That would be a disingenuous workaround for the choices that Firacode
upstream has made and the reality of the Free Software ecosystem for
fonts in 2017. If you convinced Firacode upstream to switch their
source format then that would be different. Or if FontForge or
FontTools or another piece of Free Software started to support
Glyphsapp format, then their choice would be fine for main.

I have a better thought experiment:

Would Debian put a free Java program in main or contrib in the time
when the official JDK was proprietary and GCJ hadn't been implemented
yet?

> Another thought experiment: We have a fairly prominent example of
> binary-only Type1 fonts available in the gsfonts package. They are
> licensed under the GPL, so there is even a "preferred form for
> modification" term that applies to them. Nobody knows how URW++ created
> these fonts and what tools they used, nevertheless a number of viable
> forks have been developed from them, among them GNU FreeFont and TeX Gyre.
> Now, what would happen if URW++ suddenly revealed that they used
> proprietary software to create the fonts and that the files that we have
> are not the canonical sources. Why should it make a difference at all?

It is unfortunate that the gsfonts upstream didn't ask the right
questions before integrating these files into the project. They really
should have done that. At that point in time we would have to remove
the URW++ fonts from Debian since we would not be in compliance with
the GPL.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise