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

Scott Kitterman debian at kitterman.com
Sat Jan 21 13:41:01 UTC 2017

On January 21, 2017 6:39:17 AM EST, Fabian Greffrath <fabian at debian.org> wrote:
>Hash: SHA256
>I admit it's a bit hard to argue against three, but I'll try anyway. ;)
>Am Mittwoch, den 18.01.2017, 01:12 +0000 schrieb Scott Kitterman:
>> DFSG #2 requires that "The program must include source
>> code".  Preferred form of modification is the definition of source
>> that the FTP team uses.  For Debian DFSG purposes it's not
>> exclusively GPL relevant.
>Is this the FTP Masters' position on this issue or your personal

That's the FTP Masters' position.

Scott K

>> 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).
>> [...]
>> So like C, OTF can be source or not source, depending on the upstream
>> project.
>I find this by far the most convincing argument, although I still find
>it difficult to accept that it should make a difference for Debian as a
>mere downstream distributor. We provide many packages with fonts in OTF
>format and while this is acepted as a proper source for some, it is not
>for others because of upstream design decisions?
>> 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.
>Well, RMS himself told me that the Type1 format in which the fonts are
>distributed is considered a proper source format. Apparently he doesn't
>even care about what tools upstream used to create the fonts as long as
>they are distributed in a proper source format.
>> Please try to submit a git commit to Firacode upstream containing
>> only
>> changes to the generated files. Then you will see that this phrase
>> has
>> meaning in any software context, including in the world of fonts and
>> Firacode in particular.
>Agreed, but I don't think that this (i.e. "is it easy or even possible
>to create a patch that upstream would outright accept in that form?")
>should be a criterion to decide if a package is suitable for Debian
>main or not (as long as it is possible to create the patch in the first
>place, that is).

More information about the Pkg-fonts-devel mailing list