On 11/10/16 19:51, Dammina Sahabandu wrote:
Hi Wim,

On Tue, Oct 11, 2016 at 11:44 PM, Wim Hueskes <whues...@gmail.com> wrote:

Hi Dammina,

I saw your message including this question:

The fontawesome-webfont.svg file can be converted into a .png file. WDYT?
I think that is something which you should not do. I'll try to explain;

You want to avoid non-binary files based on this text:

In particular: "software under the [SIL Open Font License] may be
included in binary form within an Apache project if the inclusion is
appropriately labeled." There is also some justification of the
position in
that section.
The main justifications is that there is less exposed surface to create
a derived work.

But when you create a .png from a .svg, you do create a derived work.
So you do exactly what must be avoided.

You are absolutely correct and thank you very much for pointing that out. :)

But also read the text of the SIL OFL license. Condition 3 forbids you
to use the original font name if you create a modified version.
(unless you ask for permission). So you would have to rename the
font and also license it under the SIL OFL.

Noted and I guess we will be accountable if something like this happens in
the future.

The goal to use only binary files is based on the assumption that
non-binary files can easily be modified, and binary files not. In this
case it is different. Software like FontForge[1] can easily modify
those binary files like .ttf and woff2. In particular the .svg file is
likely not the source file belonging to those binary files.

So I don't believe there is a larger risk of someone editing the
.svg compared to - for example - the .ttf file.

You might add the svn:needs-lock attribute to svn for the files
licensed under the SIL OFL. It will be checked out read-only
by default, so you will get a warning if you try to modify it.


[1]: https://en.wikipedia.org/wiki/FontForge

  I completely understand the concern and now I feel it will be best to
leave this library aside. Because as Gary has pointed out earlier we will
not be the only ones who will modify our work and we cannot assume the
third parties who will alter our code will completely read, understand and
adhere to the licenses of third party libraries that we are shipping with
the code.

So after seriously considering all the things that have been pointed out in
this thread, I conclude, given this enhancement that I proposed is not
critical to the project, we can safely put it aside if there are no


Thanks Wim,

I agree with the interpretation that we shouldn't do any conversion of files. I would also be wary of looking to remove specific files from the distribution. I would be surprised if we were allowed to include the code in question that the svn:need-lock attribute would really add much protection.

If we decide that it is worth pursuing further we may need to take these questions to be clarified by Apache Legal.

Another alternative would be to use a CDN which absolves us of the problem of distribution but I'd prefer to have something where there is the option to serve directly.

As it is, given this was brought up, it suggests that there is a need for an expanded set of icons. Perhaps we should consider alternative ways of achieving this.


Reply via email to