Replace Font Awesome icons with MIT fork (Fork Awesome) #1729
Conversation
m3nu
force-pushed
the
remove-fontawesome-icons
branch
from
55684cf to
fedc5c6
Compare
m3nu
changed the title
There was a problem hiding this comment.
Is this icon from Fork Awesome?
There was a problem hiding this comment.
Luckily yes. It was already there before the fork. I just recolored it a bit for Vorta.
There was a problem hiding this comment.
Small correction: The tray menu icons we use are from Fork Awesome (the hdd-o.svg icon linked above specifically).
The main app icon is from Twitter Bootstrap now, but recolored and with the circles moved to match the other icons.
m3nu
force-pushed
the
remove-fontawesome-icons
branch
4 times, most recently
from
c29fc4c to
fe6c3c1
Compare
m3nu
force-pushed
the
remove-fontawesome-icons
branch
from
fe6c3c1 to
5421445
Compare
|
Hi Manu, Thanks for the quick response! Some corrections: Font Awesome's proprietary license is not compatible with any source redistribution, including github. Fork Awesome's SVG fonts are not MIT licensed; they are SIL OFL 1.1. https://forkaweso.me/Fork-Awesome/license/ There's also a moral clause for attribution when using any icons in Bootstrap that were donated by the GlyphIcons creator. While optional, legally speaking, it would be nice to see this attribution. |
|
What a rabbit hole. I've update the license for Fork Awesome in the README. Regarding the GlyphIcons Halflings icons that were donated to Bootstrap, I can't find this icon on their website. So maybe only some Bootstrap icons are from there? |
|
Manu ***@***.***> writes:
What a rabbit hole.
Yeah, it really is :/ Likewise, it seems like
src/vorta/assets/icons/copy.svg (in this PR) should actually have CC-BY
4.0 in the header, and not Apache License 2.0, because it's a Vaadin
icon. CC-BY 4.0 doesn't allow sublicensing like this, even accidentally.
https://www.tldrlegal.com/license/creative-commons-attribution-4-0-international-cc-by-4
I've update the license for Fork Awesome in the README.
Thanks! Please note minimum and recommended terms of compliance here:
https://scripts.sil.org/cms/scripts/page.php?item_id=OFL-FAQ_web#36914bf6
Regarding the GlyphIcons Halflings icons that were donated to Bootstrap, I can't find this icon on their [website](https://glyphicons.com/sets/halflings/). So maybe only some Bootstrap icons are from there?
Yes, exactly. The GlyphIcons that were donated (with special non-free
conditions) are a small subset of the Bootstrap icons.
|
|
Changed the Vaadin license. Looks like it's shown wrongly on the search site I used. 
|
|
Manu ***@***.***> writes:
Changed the Vaadin license. Looks like it's shown wrongly on the search site I used.
Thanks :) This PR looks good to me now. I looked into and have now
discovered some of these sites... Some of them are like warez sites for
icons. Yikes!
Please send me a note when you merge it. For now I'm testing 0.9.0 with
commits cherry-picked from this PR (and plan to upload tomorrow or the
next day)
|
|
Merging now. The 0.9 branch will see many changes, while our Google Summer of Code guys are working on it. It will be the new stable release after the program finishes. Hopefully with many useful improvements. The icon aggregators are useful because often one set won't have the perfect icon for a use case. Would still be good if they got the licenses right. |
|
Manu ***@***.***> writes:
Merging now.
Cool. P.S. While reading the CC-by-4.0 license I noticed that we're not
quite in compliance with it for src/vorta/assets/icons/copy.svg. Ie:
1. If You Share the Licensed Material (including in modified
form), You must:
a. retain the following if it is supplied by the Licensor
with the Licensed Material: [https://github.com/vaadin/vaadin-icons/]
i. identification of the creator(s) of the Licensed
Material and any others designated to receive
attribution, in any reasonable manner requested by
the Licensor (including by pseudonym if
designated); [ vaadin.com/icons ]
ii. a copyright notice; [ Copyright 2019 Vaadin Ltd ]
iii. a notice that refers to this Public License;
[ Minimum, a link in the README, recommended full licence
in a LICENSES subdir ]
iv. a notice that refers to the disclaimer of
warranties; [ If you keep full-text copies of
licenses in a LICENSES subdir then you've complied
with this ]
v. a URI or hyperlink to the Licensed Material to the
extent reasonably practicable;
[ https://github.com/vaadin/vaadin-icons/blob/master/assets/svg/copy.svg ]
[ \/ This one appears to be not applicable \/ ]
b. indicate if You modified the Licensed Material and
retain an indication of any previous modifications; and
[\/ TODO, either in README or the recommended full-text copy \/ ]
c. indicate the Licensed Material is licensed under this
Public License, and include the text of, or the URI or
hyperlink to, this Public License.
The 0.9 branch will see many changes, while our Google Summer of Code guys are working on it. It will be the new stable release after the program finishes. Hopefully with many useful improvements.
Thanks for the heads-up :) Does this mean you'd like to see Vorta 0.8.2
as the most recent fully supported version uploaded to Debian, and that
you'd like me to upload 0.9 as "experimental" until fall?
The icon aggregators are useful because often one set won't have the perfect icon for a use case. Would still be good if they got the licenses right.
Fair point. Please note that whoever redistributes copyrighted material
must remain in compliance with the licenses, or else they're liable for
unlicensed distribution of copyrighted material. When the success of a
piece of FLOSS software begins to threatens commercial software, then
license compliance suddenly becomes important. In the spirit of
Google's Noto (no tofu) fonts, I'd like to see Breeze become a complete
and headache-free icon set. These license investigations aren't fun.
Even if you don't use them, I think it'd be useful to file a bug about
what was missing so the Breeze team can work towards fulfilling the
ideal :)
|
|
P.S. Please CC/@ me when you fix the current license issue
|
|
Sounds simpler to just swap this icon. |
|
Removed this one icon in #1735, @sten0 Sorry that you went overboard on this license before. I'm not overly attached to a single icon.
Yes, running this as experimental makes sense. The 0.9 branch has some breaking changes, like Qt6. |
|
Manu ***@***.***> writes:
Removed this one icon in #1735, @sten0
Sorry that you went overboard on this license before. I'm not overly attached to a single icon.
...yeah, I don't enjoy doing license checks either. If icon-related
licence issues emerge again, I will patch Vorta for Debian (and
derivatives) to use a consistent icon set that is legal to redistribute
without risk of statutory damages in countries where such things exist.
|
|
Better tell us and we'll fix it here. I also want legal icons. 😄 |
|
Better tell us and we'll fix it here. I also want legal icons. 😄
I don't want this to become an issue when I take a sabbatical, so here is
how to have legal icons:
1. Avoid using those warez icons sites, but if you insist, find out what
the actual source of the icon is, and download a copy from the original
site. This helps guard against incorrect metadata in the icons.
2. Read any licensing info on the copyright holder's website. Sometimes
they modify the license in nasty ways and you don't get the license you
think you're getting (ie: Font Awesome, Vaadin, etc.). Be careful about
code, styling, layout, and icon distinctions, because they may have
different licenses. Sometimes bitmap vs svg makes a difference. Also,
take notes about anything license-related in their git repository. Often
you'll need to do things like add a full-text copy of the license to your
repo if they have one, but not if they don't.
3. Once you know what license applies to the icons you want to use, use
your search engine of choice to look up: tldr $name_of_license. Anyone can
do this.
4. Comply with the requirements from the tldr version of the licence when
you add the icons. Either check your notes, or double check your website
and git repo review at this time.
5. Having done your due diligence, feel free to ask me to double check your
work.
Message ID: ***@***.***>
… |
|
You have work to do for license-compliance with one new icon set
…On Wed, 21 Jun 2023 at 17:26, Nicholas D Steeves ***@***.***> wrote:
Better tell us and we'll fix it here. I also want legal icons. 😄
>
I don't want this to become an issue when I take a sabbatical, so here is
how to have legal icons:
1. Avoid using those warez icons sites, but if you insist, find out what
the actual source of the icon is, and download a copy from the original
site. This helps guard against incorrect metadata in the icons.
2. Read any licensing info on the copyright holder's website. Sometimes
they modify the license in nasty ways and you don't get the license you
think you're getting (ie: Font Awesome, Vaadin, etc.). Be careful about
code, styling, layout, and icon distinctions, because they may have
different licenses. Sometimes bitmap vs svg makes a difference. Also,
take notes about anything license-related in their git repository. Often
you'll need to do things like add a full-text copy of the license to your
repo if they have one, but not if they don't.
3. Once you know what license applies to the icons you want to use, use
your search engine of choice to look up: tldr $name_of_license. Anyone can
do this.
4. Comply with the requirements from the tldr version of the licence when
you add the icons. Either check your notes, or double check your website
and git repo review at this time.
5. Having done your due diligence, feel free to ask me to double check
your work.
Message ID: ***@***.***>
>
|
You mean for those new Google icons using Apache 2 license? At this point I feel it will be better to restrict it to one icon set only and accept worse icons. I don't know why will keep up with this. |
|
You have work to do for license-compliance with one new icon set
You mean for those new Google icons using Apache 2 license? At this point
I feel it will be better to restrict it to one icon set only and accept
worse icons. I don't know why will keep up with this.
Yup, those ones, and yes, that license. The fix is pretty quick by the
way, and there are only about a dozen very concise points to read at
tldrlegal.com. P.s. The most common requirements for license compliance
tends to be attribution and providing a full-text copy of the license
alongside the copyrighted material.
Yes, sticking with a single set and downloading icons from their actual
upstream source saves time.
For the record, if you want to curate a small set of perfect icons, and you
are committed to using every icon long term, then I think it makes sense to
invest the time. The headache is really when you (or someone else) needs a
new icon for a new function...but here you can say in the README that all
new icons must be introduced from existing upstream sets (ie, currently
Fork Awesome and Material). The automatic git metadata of the commit where
an icon was introduced indicates the point when it was copied from the
canonical upstream set, and this can be used to establish which license the
icon falls under, if ever upstream relicenses...which is to say, you don't
have to worry about "keeping up" with upstream. Many of those icon
catalogue sites make this method unreliable and untrustworthy though, due
to corrupt metadata.
… |
|
Then we'll stick with Fork Awesome (since we already use many icons from there) and Google Material Icons (as backup) for now. Updated the contributor docs to say as much. For the Apache license, I read up on it on and think the needed changes are:
On the right track here? 😬 |
|
Then we'll stick with Fork Awesome (since we already use many icons from
there) and Google Material Icons (as backup) for now. Updated the
contributor docs to say as much.
For the Apache license, I read
<https://fossa.com/blog/open-source-licenses-101-apache-license-2-0/#requirements>
up on it on and think the needed changes are:
Thank you!
- The original copyright notice: There is none in the SVGs. I added
one anyways in a previous PR.
Thanks, you're right will make it easier to keep things organised (makes
copying things around more convenient too)
- A copy of the license itself: We don't have that yet. I wonder if I
can put icon licenses in the icons folder?
I believe this is permitted, yes. Are you also thinking about adding a
copy of OFL to this location? Totally up to you, but it could be nice to
have this for clarity in the long-term. BTW flatpaks and Python sdists
count as "distribution" so please take care to ensure a copy of the Apache
2.0 license ends up in these.
- statement of any significant changes made to the original code:
Didn't make changes.
- A copy of the NOTICE file with attribution notes (if the original
library has one): There is none, but attribution is already given in the
README.
You're right, a NOTICE file isn't necessary in this case. Which branch
has attribution for Material icons in the README?
On the right track here? 😬
Yes! :) You've identified all the issues, and you have a good handle on
things.
|
|
New PR to add licenses and update README. New README is here Also verified inclusion of those files on PyPi. As per |
No, these are the build steps it follows at the moment: |
|
I only see a few SVGs included. How do the other icons get included? |
Ah yes, they get included by setuptools. |
Description
Font Awesome's latest license is not compatible with FOSS distros like Debian.
Hence this PR clarifies that icons used are either from Fork Awesome, which was forked off FA in version 4.7 and has a permissive MIT license or (if icons were added after v4.7) replaces them with a free and similar alternative (Google Material icons mostly)
I provide my contribution under the terms of the license of this repository and I affirm the Developer Certificate of Origin.*
I will also update the developer guide to clarify where icons can come from.
Fixes #1218