Freedom Issue #2331

[awesome-terminal-fonts] Contains at least one nonfree logo

alieberman - over 2 years ago - . Updated over 2 years ago.

% Done:



This font contains at least one nonfree logo: Twitter's. It may be confirmed as proprietary according to and the "guidelines" PDF to which the page links. I've attached this file. On p. 13, some guidelines are numerically listed. I inferred from the first in this list, among others, that Twitter's logo doesn't qualify as free. Chiefly, it states:

You may not alter the Twitter trademarks in any manner, including, but not limited to, changing the proportion, color or shape of the Twitter trademarks, or adding or removing any elements from the Twitter trademarks.

Hence, users of this font are not free to modify the logo.

Please note that I conservatively put logo in the singular form in the subject of this issue. However, it's reasonable to consider that certain other logos in this font, such as those belonging to Facebook and LinkedIn, are also nonfree.

Naturally, we may consider the removal of offending characters as a viable solution.


twitter-brand-guidelines_v2.0.pdf (589 KB) twitter-brand-guidelines_v2.0.pdf alieberman, 2019-06-09 10:20 AM

Related issues

Related to Packages - Freedom Issue #1648: [awesome-terminal-fonts] has logos for non-free software.fixed

Related to Packages - Packaging Request #3081: lsdinfo needed




Updated by bill-auger over 2 years ago

  • Related to Freedom Issue #1648: [awesome-terminal-fonts] has logos for non-free software. added

Updated by bill-auger over 2 years ago

  • Status changed from unconfirmed to duplicate

duplicate of #1648

it looks like this one had slipped through the cracks - i think we should just blacklist this package - fonts are abundant - surely that would not be removing any important functionality from the distro


Updated by alieberman over 2 years ago

bill-auger wrote:

duplicate of #1648

it looks like this one had slipped through the cracks - i think we should just blacklist this package - fonts are abundant - surely that would not be removing any important functionality from the distro

Blacklisting works; however, the package lsd requires awesome-terminal-fonts. So, will both be blacklisted at least temporarily?


Updated by freemor over 2 years ago

Here I was thinking, "Fixing lsd should be trivial... let me just knock that off before my morning coffee..'. But it seems lsd requires Cargo which is a TPPM and thus it may wall pull in non free stuff during the build making it a candidate for blacklisting too.
I'll try building it (without the awesome-terminal-fonts requirement) in a VM. dDon't want cargo messing up my daily driver.

I'll watch the build logs carefully and then have to chase down every thing it pulls and check the licensing. (oh joy)


Updated by freemor over 2 years ago

It builds fine without the awesome-terminal-fonts, but as I feared it pulls a bunch of Rust packages during the build:

  Downloaded ansi_term v0.11.0
  Downloaded unicode-width v0.1.5
  Downloaded version_check v0.1.5
  Downloaded clap v2.32.0
  Downloaded terminal_size v0.1.8
  Downloaded lscolors v0.5.0
  Downloaded term_grid v0.1.7
  Downloaded wild v2.0.1
  Downloaded users v0.9.1
  Downloaded time v0.1.40
  Downloaded chrono-humanize v0.0.11
  Downloaded atty v0.2.11
  Downloaded textwrap v0.10.0
  Downloaded bitflags v1.0.4
  Downloaded vec_map v0.8.1
  Downloaded term_size v0.3.1
  Downloaded strsim v0.7.0
  Downloaded libc v0.2.55
  Downloaded chrono v0.4.6
  Downloaded num-traits v0.2.6
  Downloaded num-integer v0.1.39

Updated by freemor over 2 years ago

The Licenses seem ok:

ansi_term v0.11.0 -     MIT
unicode-width v0.1.5    MIT/Apache-2.0
version_check v0.1.5    MIT/Apache-2.0
clap v2.32.0            MIT
terminal_size v0.1.8    MIT OR Apache-2.0  (Or? What I get to choose?) 
lscolors v0.5.0         MIT/Apache-2.0
term_grid v0.1.7        MIT     
wild v2.0.1             MIT
users v0.9.1            MIT
time v0.1.40            MIT/Apache-2.0
chrono-humanize v0.0.11 MIT/Apache-2.0
atty v0.2.11            MIT
textwrap v0.10.0        MIT     
bitflags v1.0.4         MIT/Apache-2.0
vec_map v0.8.1          MIT/Apache-2.0
term_size v0.3.1        MIT/Apache-2.0
strsim v0.7.0           MIT     
libc v0.2.55            MIT OR Apache-2.0   (Again with the "OR")
chrono v0.4.6           MIT/Apache-2.0
num-traits v0.2.6       MIT/Apache-2.0
num-integer v0.1.39     MIT/Apache-2.0

So I looks like lsd may get to live for now.. But I'm not happy with this pulling from a TPPM. Thats basically a lot of hidden depends that could change with each build. Doesn't Arch have precepts about building packages like that. If not shouldn't we. Because if that is o.k. I could just make a PKGBUILD that downloads and runs a bash script which does: curl | bash
and then foo just wgets everything it needs and builds a thing.


Updated by bill-auger over 2 years ago

presumably, those rust packages it downloads are binaries, and not itemized in the sources() array of the PKGBUILD, so the network must be enabled in the chroot in order to get them

i asked eli about this a few days ago - arch does not have any policy against any of those, and in fact some packages are known to require the build system to pull in whatever at build time - for that reason, it is likely that we will see more of them in the future

even if disregarding the binary build deps, anything that is not itemized in the sources() array is something that may become unobtainable in the future (or in the case of pulling the the daily HEAD of a VCS repo, non-trivial to resolve which repo state was the original source)

from the parabola perspective, this should be considered as "not built from source"; if only because the end result is an incomplete source package - there are already several package on the blacklist for that reason - i think there already is the consensus that each of those caveats are unacceptable on their own - i think all three of those concerns would need to be addressed before we could consider the package fit for parabola

  • binary build deps
  • network-enabled chroot
  • incomplete source package

the proper solution is to package each of the sources separately, which adds a significant amount of work to the overall maintenance of the distro - that amount is roughly gagued by my rule of thumb metric in such cases:

(n_users + importance) / (cost_of_packaging + cost_of_maintenance)


Updated by freemor over 2 years ago

Thanks for the feedback.

In this case it was pulling and compiling source crates. but that seill leaves most if not all of those problems. So Guess the thing to do is blacklist both and call it a day.
I should have realized the needing internet in the chroot issue as I saw you and oaken-source discussing some package with a similar issue.

Busy with other things for the rest of the day so if you want to go ahead and blacklist them, have fun. Otherwise I'll get to that when I have a couple of spare moments.


Updated by eschwartz over 2 years ago

In theory, rust guarantees that any dependency will always be available (albeit over the internet). Unlike golang, cargo dependencies must be pulled from the official source package index for rust crates, and is then compiled from source -- usually with all sorts of interesting compiler flags based on the project in question as well as your arch/CPU support (there are nightly rust language features, --enable-foo equivalents which different packages opt in to, etc.)

I'm not aware of any rust policy to allow takedown of crates, so unless the whole index disappears, packages should always continue to work.

Yes, it is ugly, yes, the rust language like golang and nodejs basically demands network, but quite frankly rust is the least offensive of the lot IMO.


Updated by freemor over 2 years ago

  • % Done changed from 0 to 100
  • Assignee set to freemor

Blacked both awesome-terminal-fonts and lsd.
close this and the dup.


Updated by freemor over 2 years ago

  • Status changed from duplicate to fixed

Updated by bill-auger 2 months ago

Also available in: Atom PDF