Font-Awesome 5 no build system DFSG compatibility

[Alexis Murzeau]

Hi,

I have a question regarding the font-awesome v5 [0] and the DFSG.

Since version 5, font-awesome upstream repository contains both source
files and generated files but not the build system [1].

So it is not possible to regenerate generated files from source files
without guessing which file are generated and which are sources.
I've asked upstream about that [2] (but no response yet).

It's a bit as if this upstream repository was a tarball containing
binaries and sources but without makefiles used to generated the
binaries, just being a git repo instead of a tarball file.

The program must include source code, and must allow distribution in
source code as well as compiled form.

is font-awesome 5 upstream repository DFSG compatible ?

Thanks for your help :)


----
[0]: https://github.com/FortAwesome/Font-Awesome
[1]:
https://github.com/FortAwesome/Font-Awesome/issues/12199#issuecomment-363168281
[2]: https://github.com/FortAwesome/Font-Awesome/issues/13467

Font Awesome Free is free, open source, and GPL friendly. You can use
it for commercial projects, open source projects, or really almost
whatever you want.
Icons — CC BY 4.0 License [4]
In the Font Awesome Free download, the CC BY 4.0 license applies to
all icons packaged as .svg and .js files types.
Fonts — SIL OFL 1.1 License [5]
In the Font Awesome Free download, the SIL OLF license applies to all
icons packaged as web and desktop font files.
Code — MIT License [6]
In the Font Awesome Free download, the MIT license applies to all
non-font and non-icon files.
Attribution
Attribution is required by MIT, SIL OLF, and CC BY licenses.
Downloaded Font Awesome Free files already contain embedded comments
with sufficient attribution, so you shouldn't need to do anything
additional when using these files normally.
We've kept attribution comments terse, so we ask that you do not
actively work to remove them from files, especially code. They're a
great way for folks to learn about Font Awesome.

[3]: https://fontawesome.com/license/free
[4]: https://creativecommons.org/licenses/by/4.0/
[5]: https://scripts.sil.org/OFL
[6]: https://opensource.org/licenses/MIT

--
Alexis Murzeau
PGP: B7E6 0EBB 9293 7B06 BDBC 2787 E7BD 1904 F480 937F

[Simon McVittie]

Post by Alexis Murzeau
Since version 5, font-awesome upstream repository contains both source
files and generated files but not the build system [1].

I think this is a technical issue, but not a DFSG violation; and I think
it would be appropriate to track it as a bug, but not a release-critical
bug.

The same situation exists in any package where some hard-to-modify,
non-executable data file (perhaps an icon) is accompanied by its
easier-to-modify source form (perhaps in GIMP format or as a SVG) but
a manual export step is required to transform the source form into the
modifiable form.

We generally hold executable code (must be compiled at build time,
with some rare exceptions) to a higher standard than "pure data" (not
necessarily recompiled at build time), because in practice it is far
more likely that we will find ourselves in a position where we need to
exercise our right to modify for executable code, to be able to fix bugs
in that code; and because in most cases fixing bugs in executable code
by direct modifications to a generated format is much les practical than
doing the same with many non-executable data formats (for instance if
you need to, you can perform many edits to an icon in its bitmap form
without going back to its source form).

Post by Alexis Murzeau
So it is not possible to regenerate generated files from source files
without guessing which file are generated and which are sources.

We do not require that packages are modifiable by people who do not
know how to modify that particular language or format. People with the
necessary knowledge presumably know which file is in a preferred form
for modification and which file is generated from it; if they didn't,
then that would preusmably have to be because the generated file was a
reasonable form for modification in its own right.

Post by Alexis Murzeau

The program must include source code, and must allow distribution in
source code as well as compiled form.

The "program" (package, module) includes source code: [x]

The license allows distribution of that source code: [x]

So yes I think this is fine for the DFSG.

smcv

[Walter Landry]

Post by Simon McVittie

The program must include source code, and must allow distribution in
source code as well as compiled form.

The "program" (package, module) includes source code: [x]
The license allows distribution of that source code: [x]

You may or may not consider this dispositive, but the definition of
source code from GPL v3 is

The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities.

So a makefile or equivalent is required.

On a more practical level, Debian has to be able to rebuild all of the
binaries from source. If you can not do that, then that would be an RC
bug.

Cheers,
Walter Landry

[Alexis Murzeau]

Post by Walter Landry

Post by Simon McVittie

The program must include source code, and must allow distribution in
source code as well as compiled form.

The "program" (package, module) includes source code: [x]
The license allows distribution of that source code: [x]

You may or may not consider this dispositive, but the definition of
source code from GPL v3 is
The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities.
So a makefile or equivalent is required.
On a more practical level, Debian has to be able to rebuild all of the
binaries from source. If you can not do that, then that would be an RC
bug.

I was thinking about this.

Actually, many files are text files and could be considered as sources
files (excluding minified files which are obviously generated).

But many of them contains the same thing:
- javascript code:
- js files meant to be used with node.js [0]
- js files for svg webfont [1]
- glyph data (shape paths):
- single svg containing all glyphs [2]
- multiple svg containing only one glyph each [3]
- glyphs metadata contain glyph svg in a "raw" field [4]
- js files for node.js contains glyph path data [5]
- typescript files (*.d.ts) for node.js seem to be all the same, see 2
examples:
[6], [7]
- advanced-options/use-with-node-js/fontawesome-free/ [8] folder seems
to contain many files also in web-fonts-with-css/ [9] and in
advanced-options/use-with-node-js/fontawesome-free-webfonts/ [10]
- [11] and [12] seems to be the same (beside the version in comments)
- There are multiple fonts format (otf, ttf, woff2, ...), by reading
trough issues on github, it seems that there are all generated from the
.otf ones, but using an online website ([13])
- There are also svg files containing all glyphs along with webfonts
[14], maybe same as [2]

There are probably other files duplicated.

All files are just text files that can be patched easily beside fonts
and .min.* files.
I mean, there are not opaque binaries that can't be patched without
specialized tools and knowledge.

But one issue in one of them will probably require modification in some
other files too.

This can be OK though ("just" a maintenance burden to remember that a
bug might span multiple files)
Not sure what to think about generated webfonts.

At least, minified files can be regenerated at package build time with
known tools that does this (maybe upstream can help to use the same tool
as them)

I also think of the many potential reverse dependencies once
python3-sphinx will move to font awesome 5. It would be great to have
font awesome 5 in main avoiding them to move to contrib.



Keeping minified files appart, given the nature of generated files
(either correctly indented files or font files), I'm leaning toward
Simon's way to think about this.

What do you think Walter ?

Thanks

Post by Walter Landry
Cheers,
Walter Landry

[0]
https://github.com/FortAwesome/Font-Awesome/blob/master/advanced-options/use-with-node-js/fontawesome/index.js
[1]
https://github.com/FortAwesome/Font-Awesome/blob/master/svg-with-js/js/fontawesome.js

[2]
https://github.com/FortAwesome/Font-Awesome/blob/master/advanced-options/svg-sprites/fa-solid.svg
[3]
https://raw.githubusercontent.com/FortAwesome/Font-Awesome/master/advanced-options/raw-svg/solid/address-book.svg
[4]
https://raw.githubusercontent.com/FortAwesome/Font-Awesome/master/advanced-options/metadata/icons.json
[5]
https://github.com/FortAwesome/Font-Awesome/blob/master/advanced-options/use-with-node-js/fontawesome-free-solid/faAddressBook.js

[6]
https://github.com/FortAwesome/Font-Awesome/blob/master/advanced-options/use-with-node-js/fontawesome-free-solid/faAddressBook.d.ts
[7]
https://github.com/FortAwesome/Font-Awesome/blob/master/advanced-options/use-with-node-js/fontawesome-free-solid/faAddressCard.d.ts

[8]
https://github.com/FortAwesome/Font-Awesome/tree/master/advanced-options/use-with-node-js/fontawesome-free
[9]
https://github.com/FortAwesome/Font-Awesome/tree/master/web-fonts-with-css
[10]
https://github.com/FortAwesome/Font-Awesome/tree/master/advanced-options/use-with-node-js/fontawesome-free-webfonts

[11]
https://github.com/FortAwesome/Font-Awesome/blob/master/advanced-options/use-with-node-js/fontawesome-svg-core/styles.css
[12]
https://github.com/FortAwesome/Font-Awesome/blob/master/advanced-options/use-with-node-js/fontawesome/styles.css

[13] https://www.fontsquirrel.com/tools/webfont-generator

[14]
https://raw.githubusercontent.com/FortAwesome/Font-Awesome/master/web-fonts-with-css/webfonts/fa-solid-900.svg

[Ian Jackson]

Post by Simon McVittie
I think this is a technical issue, but not a DFSG violation; and I think
it would be appropriate to track it as a bug, but not a release-critical
bug.

I have a different analysis, at least, as far as I currently
understand the situation.

What is going on here is that upstream are keeping some of the actual
source code (and yes, I think the Makefiles count - I agree with the
GPL's definition of source in this context) secret (perhaps
unintentionally). We need to obtain it. If we can't, then perhaps we
can produce an equivalent build sequence to replace the missing parts.

IMO for files which are built automatically by upstream, they should
be built automatically in Debian too.

Post by Simon McVittie
The same situation exists in any package where some hard-to-modify,
non-executable data file (perhaps an icon) is accompanied by its
easier-to-modify source form (perhaps in GIMP format or as a SVG) but
a manual export step is required to transform the source form into the
modifiable form.

This is quite different. In those cases there is no other build
system. When there is no other build system, then upstream are doing
the same manual thing that we are expecting ourselves, our users, and
our downstreams to do.

Thanks,
Ian.

[Karan, Cem F CIV USARMY RDECOM ARL (US)]

-----Original Message-----
Sent: Monday, July 23, 2018 3:42 PM
Subject: [Non-DoD Source] Re: Font-Awesome 5 no build system DFSG compatibility

Post by Simon McVittie
I think this is a technical issue, but not a DFSG violation; and I
think it would be appropriate to track it as a bug, but not a
release-critical bug.

I have a different analysis, at least, as far as I currently understand the situation.
What is going on here is that upstream are keeping some of the actual source code (and yes, I think the Makefiles count - I agree with the
GPL's definition of source in this context) secret (perhaps unintentionally). We need to obtain it. If we can't, then perhaps we can
produce an equivalent build sequence to replace the missing parts.
IMO for files which are built automatically by upstream, they should be built automatically in Debian too.

Post by Simon McVittie
The same situation exists in any package where some hard-to-modify,
non-executable data file (perhaps an icon) is accompanied by its
easier-to-modify source form (perhaps in GIMP format or as a SVG) but
a manual export step is required to transform the source form into the
modifiable form.

This is quite different. In those cases there is no other build system. When there is no other build system, then upstream are doing the
same manual thing that we are expecting ourselves, our users, and our downstreams to do.
Thanks,
Ian.
--

I agree with Ian on this; build systems can have extra code in them that we may need (e.g., a build system that generates new files for a given computer that are then compiled into the final executable). They aren't optional, not in Free software.

My personal rule of thumb is that if a human being generated the file, then we need that file. Anything that is generated from human generated files (e.g., the icon that was generated from the GIMP file, or the executable from the original source files), doesn't need to be included.

From a security point of view, I'd prefer **not** to have any of the generated binaries as I can then look at all the sources (code, icon files, build system files, etc.) and choose if I'm going to run the final output or not. A convenience binary that claims to be the output of a compilation step may or may not be, and it may be difficult to prove one way or the other (if the creator is caught, they may claim that they compiled using 'better' flags than the build system supplies).

Moreover, where do we draw the line? I've written code generators before that generate VAST amounts of highly optimized code (think on the order of a million lines of C code in one file). I could create a project where I open source the generated code, but keep the code generator to myself. At that point, there is no simple method of checking the file; I might have hand-edited a few of the generated functions to do something 'extra'. If you had the code generator in hand, you could check it, then compare its output against the file I supply to see if there are any differences. The important thing here is that one human being is approximately equal to another human being in terms of level of effort required to generate or check material; if someone else had access to my code generator, it would take them approximately as long to check it as it took me to write it, so my ability to hide anything nefarious is dramatically limited[1].

So, I vote for requiring the build files **and anything else created by a human** before accepting it as open source.

Thanks,
Cem Karan

[1] Yes, you can do some really, really clever things to obfuscate what you're doing; witness The International Obfuscated C Code Contest (https://www.ioccc.org/), or The Underhanded C Contest (http://www.underhanded-c.org/). However, you can't do the equivalent of a DOS attack on all people that are checking your code; I believe that the time to check human generated code versus create it is O(1) (although the constant that is hidden in there may be high). A computer can generate infinite amounts of code in relation to the amount of input. At that point, no human checker (or even team of checkers) can verify the output.

[Paul Wise]

Post by Alexis Murzeau
I have a question regarding the font-awesome v5 [0] and the DFSG.
Since version 5, font-awesome upstream repository contains both source
files and generated files but not the build system [1].

I would like to point out here that the build system exists, but is
both secret and proprietary, because upstream have a proprietary
version of the fonts that they are selling:

"Because Font Awesome sales a Pro version our build system will for
the time being remain private (we've got all of our for-pay icons in
there)."

Post by Alexis Murzeau
So it is not possible to regenerate generated files from source files
without guessing which file are generated and which are sources.
I've asked upstream about that [2] (but no response yet).

Personally, I don't consider things proper Free Software unless they
are built using an automatic, repeatable and
reproducible/deterministic mechanism from freely licensed source using
only tools that are themselves proper Free Software. Modification of
that source also must be possible using only tools that are themselves
proper Free Software. In addition I don't accept something as proper
Free Software if upstream has created one form of data from another,
truer, source form, thrown away the source form (or never saved it)
and then distributes only the prebuilt form, which they use as if it
were source but in truth intend to keep it read-only.

Debian's standards are somewhat lower, we require source be available
and DFSG-freely licensed. In addition the ftp-master policy (not sure
about the rest of Debian) has a policy that packages be buildable (but
not necessarily built) using tools only in main. We don't yet require
an automated build process, we don't yet require rebuilding from
source by Debian, we don't yet require reproducible/deterministic
builds, we don't have a policy about tools to modify the source, we
err on the side of taking upstream's word for it about source and we
don't have any policy about what counts as proper source.