Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #906035 > unrolled thread

Bug#902981: new upstream (5.1.0)

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#902981: new upstream (5.1.0) Daniel Baumann <daniel.baumann@progress-linux.org> - 2018-07-04 15:10 +0200
    Bug#902981: new upstream (5.1.0) Daniel Baumann <daniel.baumann@progress-linux.org> - 2018-07-17 23:20 +0200
      Bug#902981: new upstream (5.1.0) Alexis Murzeau <amubtdx@gmail.com> - 2018-07-19 00:10 +0200
        Font-Awesome 5 no build system DFSG compatibility Alexis Murzeau <amubtdx@gmail.com> - 2018-07-19 00:40 +0200
          Re: Font-Awesome 5 no build system DFSG compatibility Simon McVittie <smcv@debian.org> - 2018-07-19 13:30 +0200
            Re: Font-Awesome 5 no build system DFSG compatibility Ian Jackson <ijackson@chiark.greenend.org.uk> - 2018-07-23 21:50 +0200
              RE: [Non-DoD Source] Re: Font-Awesome 5 no build system DFSG  compatibility "Karan, Cem F CIV USARMY RDECOM ARL (US)" <cem.f.karan.civ@mail.mil> - 2018-07-25 16:40 +0200
          Re: Font-Awesome 5 no build system DFSG compatibility Paul Wise <pabs@debian.org> - 2018-07-26 01:40 +0200

#906035 — Bug#902981: new upstream (5.1.0)

Package: font-font-awesome
Severity: wishlist

Hi,

font-awesome 5.1 is available, it would be nice if you could upgrade to
this version.

Regards,
Daniel

[toc] | [next] | [standalone]

#908137

Hi,

please remember to CC the submitter explicitly, sending a message only
to the bug does not notify the submitter.

regarding font-awesome 5: I use the package in my own things as well as
some (unimportant) packages I maintain.

How about having fonts-font-awesome5 in parallel to 4.x?

Regards,
Daniel

[toc] | [prev] | [next] | [standalone]

#908259

[Multipart message — attachments visible in raw view] — view raw

On 17/07/2018 23:15, Daniel Baumann wrote:
> Hi,
> 
> please remember to CC the submitter explicitly, sending a message only
> to the bug does not notify the submitter.
Ok thanks, I wasn't totally aware of that.

> 
> regarding font-awesome 5: I use the package in my own things as well as
> some (unimportant) packages I maintain.
> 
> How about having fonts-font-awesome5 in parallel to 4.x?

This is the idea to have it as a separate package with "5" suffix.
But since v5 upstream does not chip build system files, only source and
generated files are available on github without a way to rebuild them.
I asked them a first question about which files are actual sources and
which are generated.
I will ask debian-legal about this, if this cause an issue regarding DFSG.

> 
> Regards,
> Daniel
> 


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

[toc] | [prev] | [next] | [standalone]

#908264 — Font-Awesome 5 no build system DFSG compatibility

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#908330 — Re: Font-Awesome 5 no build system DFSG compatibility

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

[toc] | [prev] | [next] | [standalone]

#909059 — 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 Jackson <ijackson@chiark.greenend.org.uk>   These 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.

[toc] | [prev] | [next] | [standalone]

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

> -----Original Message-----
> From: Ian Jackson [mailto:ijackson@chiark.greenend.org.uk]
> Sent: Monday, July 23, 2018 3:42 PM
> To: Simon McVittie <smcv@debian.org>
> Cc: Alexis Murzeau <amubtdx@gmail.com>; debian-legal@lists.debian.org; 902981@bugs.debian.org; Daniel Baumann
> <daniel.baumann@progress-linux.org>
> 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 Jackson <ijackson@chiark.greenend.org.uk>   These 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.

[toc] | [prev] | [next] | [standalone]

#909448 — Re: Font-Awesome 5 no build system DFSG compatibility

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web