Re: Font-Awesome 5 no build system DFSG compatibility

[Paul Wise]

On Thu, Jul 19, 2018 at 6:38 AM, Alexis Murzeau wrote:

> 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)."

> 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.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

RE: [Non-DoD Source] Re: Font-Awesome 5 no build system DFSG compatibility

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

> -Original Message-
> From: Ian Jackson [mailto:ijack...@chiark.greenend.org.uk]
> Sent: Monday, July 23, 2018 3:42 PM
> To: Simon McVittie 
> Cc: Alexis Murzeau ; debian-legal@lists.debian.org; 
> 902...@bugs.debian.org; Daniel Baumann
> 
> Subject: [Non-DoD Source] Re: Font-Awesome 5 no build system DFSG 
> compatibility
> 
> Simon McVittie writes ("Re: Font-Awesome 5 no build system DFSG 
> compatibility"):
> > 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.
> 
> > 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.
> 
> --
> Ian JacksonThese opinions are my own.

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.

Re: Font-Awesome 5 no build system DFSG compatibility

[Ian Jackson]

Simon McVittie writes ("Re: Font-Awesome 5 no build system DFSG compatibility"):
> 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.

> 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.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Re: Font-Awesome 5 no build system DFSG compatibility

[Alexis Murzeau]

On 19/07/2018 15:46, Walter Landry wrote:
> Simon McVittie  writes:
>>> Considering DFSG #2:
 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

> 
> 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

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



signature.asc
Description: OpenPGP digital signature

Re: Font-Awesome 5 no build system DFSG compatibility

[Walter Landry]

Simon McVittie  writes:
>> Considering DFSG #2:
>> > 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

Re: Font-Awesome 5 no build system DFSG compatibility

[Simon McVittie]

On Thu, 19 Jul 2018 at 00:38:15 +0200, Alexis Murzeau wrote:
> 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).

> 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.

> Considering DFSG #2:
> > 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

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.

Considering DFSG #2:
> 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 5 licensing is [3]:
> 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






signature.asc
Description: OpenPGP digital signature