Postulo/postulo

Watch

Fork 0

Social profiles and code repositories: a one-colour mark for every service, LinkedIn first #926

New issue

Closed

opened 2026-10-15 17:19:46 +00:00 by tiagoagueda · 1 comment

tiagoagueda commented

2026-10-15 17:19:46 +00:00

Owner

Decision (2026-10-15)

Every service gets a one-colour mark: alternative brand icon sets fill the gaps, and existing marks are rendered in black and white (options 2 and 3 below; the "none" choices of #654 and #905 are reversed for the link services). The comparison of icon sets, what the owners' pages say, the recommendation and proposed TRADEMARKS.md wording are in the comment of 2026-10-15 below.

What exists today

Marks come from Simple Icons (simple-icons 16.34.0 in package.json), copied by npm run sync:brands from the list in assets/brands.txt (#654). Since #905 (7ff3fd2b5) the service selects draw them in one colour (single-colour mode).
Shipped with a mark: Mastodon, Bluesky, YouTube, GitHub, Forgejo, SourceHut (and ORCID for identifiers).
No mark, Lucide icon instead (plugins/link_services/services.py): LinkedIn (user), X (at-sign), Xing (user), Facebook (user), Instagram (user), Threads (at-sign), GitLab, Codeberg, Bitbucket (git-branch).
Why, as recorded in assets/brands.txt and TRADEMARKS.md ("The rule for plugin logos", rule 2, and the three modes):
- LinkedIn: Simple Icons removed the mark at its owner's request (14.0.0). The project chose not to take one from anywhere else (#654).
- Facebook, Instagram, Codeberg: in Simple Icons, but their owners' guidelines allow only the colour logo or a white one, with no black. A one-colour mark on the light page would break rule 2, so none (#905).
- X, Threads, GitLab, Bitbucket, Xing: published colour fails 3:1 on one of the two pages, and the guidelines could not be shown to allow one colour (X's toolkit returned HTTP 402; Xing's rules page is a 404; Meta's and Atlassian's pages say nothing on it).
Lucide 1.x (lucide-static 1.41.0) ships no brand icons.

The constraint is the rule, not the library

A different icon set does not change what TRADEMARKS.md allows. Another set's licence (MIT, CC BY) covers the drawing, not the trademark, so Facebook in black is still a recolouring Meta's page forbids. Only LinkedIn, and any other mark Simple Icons dropped, is a gap that a library alone could fill.

Options (not decided)

Keep Simple Icons and rule 2; fill gaps from owners' own kits. LinkedIn publishes brand guidelines and logo downloads. If they allow the "in" mark in black and white, vendor it from LinkedIn's own kit with the guidelines' URL in brands.txt, as the single-colour lines already do. Not verified what LinkedIn's page allows. Re-check X, Threads, GitLab, Bitbucket and Xing the same way.
Add a second set for marks Simple Icons lacks, under the same rule. For example Tabler Icons (MIT; its brand-* icons are stroke-drawn like Lucide, so they sit well beside Lucide), Font Awesome Free brands (icons CC BY 4.0; their own notice says brand icons remain their owners' trademarks), or Bootstrap Icons (MIT). Coverage of LinkedIn, X, Xing, Threads, GitLab, Bitbucket and Codeberg in each is not verified here. A second source needs its own line in THIRD-PARTY.md, its NOTICE, and the sync script.
Change rule 2 so a one-colour mark may be shown wherever it only identifies the service (nominative use), even where the owner names other colours. This is a decision for TRADEMARKS.md, and it reverses the choices recorded in #654 and #905.
Leave it as is: Lucide icons for the services without a mark, which is what the rule's neutral fallback is for.

Whatever is chosen

Marks stay decorative beside the service's name (the name is the option's text), in currentColor, clearing 3:1 on both pages.
tests/test_brands.py and the brands.txt header describe the new source or mode.

No new strings.

Related: #654, #867, #905, #305, #301.

Checked against main at 56fc9d531.

Social profiles and code repositories: give every service in the service select a one-colour mark, LinkedIn first. Decide whether that means another icon source, a change to the trademark rule, or both. ## Decision (2026-10-15) **Every service gets a one-colour mark: alternative brand icon sets fill the gaps, and existing marks are rendered in black and white** (options 2 and 3 below; the "none" choices of #654 and #905 are reversed for the link services). The comparison of icon sets, what the owners' pages say, the recommendation and proposed `TRADEMARKS.md` wording are in the comment of 2026-10-15 below. ## What exists today - Marks come from Simple Icons (`simple-icons` 16.34.0 in `package.json`), copied by `npm run sync:brands` from the list in `assets/brands.txt` (#654). Since #905 (`7ff3fd2b5`) the service selects draw them in one colour (`single-colour` mode). - **Shipped with a mark**: Mastodon, Bluesky, YouTube, GitHub, Forgejo, SourceHut (and ORCID for identifiers). - **No mark, Lucide icon instead** (`plugins/link_services/services.py`): LinkedIn (`user`), X (`at-sign`), Xing (`user`), Facebook (`user`), Instagram (`user`), Threads (`at-sign`), GitLab, Codeberg, Bitbucket (`git-branch`). - Why, as recorded in `assets/brands.txt` and `TRADEMARKS.md` ("The rule for plugin logos", rule 2, and the three modes): - **LinkedIn**: Simple Icons removed the mark at its owner's request (14.0.0). The project chose not to take one from anywhere else (#654). - **Facebook, Instagram, Codeberg**: in Simple Icons, but their owners' guidelines allow only the colour logo or a white one, with no black. A one-colour mark on the light page would break rule 2, so none (#905). - **X, Threads, GitLab, Bitbucket, Xing**: published colour fails 3:1 on one of the two pages, and the guidelines could not be shown to allow one colour (X's toolkit returned HTTP 402; Xing's rules page is a 404; Meta's and Atlassian's pages say nothing on it). - Lucide 1.x (`lucide-static` 1.41.0) ships no brand icons. ## The constraint is the rule, not the library A different icon set does not change what `TRADEMARKS.md` allows. Another set's licence (MIT, CC BY) covers the drawing, not the trademark, so Facebook in black is still a recolouring Meta's page forbids. Only LinkedIn, and any other mark Simple Icons dropped, is a gap that a library alone could fill. ## Options (not decided) 1. **Keep Simple Icons and rule 2; fill gaps from owners' own kits.** LinkedIn publishes brand guidelines and logo downloads. If they allow the "in" mark in black and white, vendor it from LinkedIn's own kit with the guidelines' URL in `brands.txt`, as the single-colour lines already do. Not verified what LinkedIn's page allows. Re-check X, Threads, GitLab, Bitbucket and Xing the same way. 2. **Add a second set for marks Simple Icons lacks**, under the same rule. For example Tabler Icons (MIT; its `brand-*` icons are stroke-drawn like Lucide, so they sit well beside Lucide), Font Awesome Free brands (icons CC BY 4.0; their own notice says brand icons remain their owners' trademarks), or Bootstrap Icons (MIT). Coverage of LinkedIn, X, Xing, Threads, GitLab, Bitbucket and Codeberg in each is not verified here. A second source needs its own line in `THIRD-PARTY.md`, its NOTICE, and the sync script. 3. **Change rule 2** so a one-colour mark may be shown wherever it only identifies the service (nominative use), even where the owner names other colours. This is a decision for `TRADEMARKS.md`, and it reverses the choices recorded in #654 and #905. 4. **Leave it as is**: Lucide icons for the services without a mark, which is what the rule's neutral fallback is for. ## Whatever is chosen - Marks stay decorative beside the service's name (the name is the option's text), in `currentColor`, clearing 3:1 on both pages. - `tests/test_brands.py` and the `brands.txt` header describe the new source or mode. No new strings. Related: #654, #867, #905, #305, #301. Checked against `main` at `56fc9d531`.

tiagoagueda added the

enhancement

interface

labels

2026-10-15 17:19:47 +00:00

tiagoagueda commented

2026-10-15 17:35:29 +00:00

Author

Owner

Decision (maintainer, 2026-10-15)

Every service gets a one-colour mark: find alternative brand icon sets where Simple Icons has none, and render the existing ones in black and white. The maintainer's reasoning: Font Awesome and the Simple Icons website both show brand marks in one colour, so the trademark rule is not as restrictive as TRADEMARKS.md assumed. This chooses option 3 (change rule 2) together with option 2 (a second set for the gaps), and reverses the "none" choices recorded in #654 and #905 for the link services.

Research below, read on 2026-10-15 from the packages on npm/unpkg and the owners' own pages.

Icon sets compared

Presence checked file by file in the published npm package (unpkg) at the version given. y = present, – = absent, ? = not checked.

Set (version)	Licence	LinkedIn	Facebook	Instagram	Codeberg	Mastodon	GitHub	GitLab	Bluesky	X	YouTube	ORCID	Also	Monochrome-ready	Attribution
Simple Icons 16.35.0 (Postulo pins 16.34.0)	CC0-1.0 (but its disclaimer says not every icon is CC0, and asks users to follow each brand's guidelines)	– (removed in 14.0.0, PR #11380, after the maintainers asked LinkedIn for permission)	y	y	y	y	y	y	y	y	y	y	Threads, Xing, Bitbucket, Forgejo, SourceHut, Stack Overflow	Yes: one path, no fill, so it takes `currentColor`	None (CC0)
Font Awesome Free brands 7.3.1	Icons CC BY 4.0 (SVG/JS), fonts OFL-1.1, code MIT	y (`linkedin`, `linkedin-in`)	y	y	y	y	y	y	y	y (`x-twitter`)	y	y	Threads, Xing, Bitbucket, Forgejo, Stack Overflow; no SourceHut	Yes: `fill="currentColor"` in every SVG	CC BY 4.0: each SVG carries a comment naming Font Awesome and the licence, and the LICENSE asks that it not be removed. Its "Brand Icons" section: trademarks of their owners, no endorsement, "do not use brand logos for any purpose except to represent the company, product, or service to which they refer"
Tabler Icons 3.49.0	MIT	y	y	y	–	y	y	y	y	y (`brand-x`)	y	–	Threads, Xing, Bitbucket, Stack Overflow; no Forgejo	Yes, but stroke-drawn outlines (Lucide's style), not the filled marks Simple Icons ships	MIT notice
Bootstrap Icons 1.13.2	MIT	y	y	y	–	y	y	y	y	y (`twitter-x`)	y	–	Threads, Stack Overflow; no Xing, Bitbucket	Yes (`currentColor`)	MIT notice
Material Design Icons `@mdi/svg` 7.4.47	Apache-2.0	y	y	y	–	y	y	y	–	? (only `twitter` checked)	y	–	Bitbucket, Stack Overflow	Yes	Apache-2.0 NOTICE
Remix Icon 4.9.1 (`Logos/`)	Apache-2.0	y	y	y	–	y	y	y	y	y (`twitter-x`)	y	–	Threads	Yes	Apache-2.0 NOTICE
Devicon 2.17.0	MIT	y	y	?	–	–	y	y	–	?	?	?	Forgejo, Bitbucket	Mostly coloured "original" variants; aimed at languages and tools	MIT notice

Iconify repackages these same sets (simple-icons, fa7-brands, tabler, bi, mdi, ri, …) under their original licences, so it adds no new artwork; its full-colour logos set does not fit a one-colour rule.

Only Font Awesome Free covers every service in the selects today except SourceHut, and Simple Icons covers every one except LinkedIn. The two together cover all of them in the same filled style.

What the owners' own pages say about one colour

LinkedIn ([in] logo page, brand.linkedin.com/in-logo): "LinkedIn members may only use the [in] Logo in three color variations: blue, black, and white"; blue on white is preferred; in a social-media line-up icons must use one of the three provided colours. So black and white are allowed by LinkedIn itself. Its policies add "Any logos or images found elsewhere on the web are not approved for use" and "only using approved Brand assets from this site", and require that use not suggest sponsorship. The downloads (brand.linkedin.com/downloads) are given "by downloading … you agree to comply with the terms of the LinkedIn Brand and User Agreements".
Facebook (Meta's logo page): primary Facebook Blue with a white "f", secondary white; black is not mentioned; "Do not recolor our logo to your own brand colors". White on the dark page is within the page; black on the light page is the decision's extension.
Instagram: as recorded in brands.txt (full colour or monochromatic white); Meta's current glyph page could not be fetched (404 at the URL tried).
Codeberg (Codeberg/Design): logo material CC0, the name and logo trademarks of Codeberg e.V.; the kit holds blue and white SVGs only (no mono file in the repo tree); "Don't tint the logo in a custom color".
X (brand toolkit still answers HTTP 402) and GitLab (design.gitlab.com now redirects to a sign-in): still not readable.

So under the old rule LinkedIn alone moves from none to single-colour (from LinkedIn's own words); Facebook, Instagram (black) and Codeberg (black) need the rule change the maintainer decided; X, Threads, GitLab, Bitbucket and Xing need it too, because their pages cannot be read.

Recommendation

Keep Simple Icons as the one source wherever it has the mark, and take Facebook, Instagram, Codeberg, X, Threads, GitLab, Bitbucket and Xing from it (they are already in the pinned package). Same filled style as today's seven, no new licence.
LinkedIn: take the black [in] mark from LinkedIn's own download kit (brand.linkedin.com/downloads), since LinkedIn allows black and white and says logos found elsewhere are not approved; record the in-logo page and its sentence in brands.txt like the other single-colour lines. If the kit has no usable SVG, fall back to Font Awesome Free's linkedin (CC BY 4.0), keeping its attribution comment.
Font Awesome Free brands as the general second source (not Tabler: Tabler's outlines would sit beside Simple Icons' filled marks, and it lacks Codeberg, ORCID and Forgejo). Use it only for a mark Simple Icons lacks, so the set stays mostly CC0. If it is used: a THIRD-PARTY.md row (CC BY 4.0, Fonticons, Inc.), the SVG's own comment kept, the licence named in NOTICE.txt, and sync-brands.mjs taught a source field (simple-icons | fontawesome-free | owner-kit) per line in brands.txt.
All marks in one mode, single-colour, drawn in currentColor (black on the light page, white on the dark), beside the service's name, decorative (aria-hidden), never larger than the text it labels, never as a button that looks like the service's own (no "Sign in with"/"Share" look-alikes).
Keep the right of an owner to say no: the existing "If you own a mark used here" paragraph, plus a none line in brands.txt for any owner who objects, with the date.
Tests: tests/test_brands.py checks each line has a source and, for single-colour, either an owner page or the nominative-use reason; the contrast test no longer applies to single-colour marks (black/white clear 3:1 by construction).

Proposed wording for `TRADEMARKS.md` (not edited here)

The current rule 2 ("only where the owner's own published guidelines allow a one-colour version in those colours"), the none bullet that lists Facebook, Instagram and Codeberg, and the closing "LinkedIn has no mark here, and none is taken from elsewhere" contradict the decision. Proposed replacement for the single colour bullet:

single colour: drawn in currentColor, which the stylesheet makes exactly black on the light page and exactly white on the dark one, beside the service's name and only to say which service a link or an option goes to. This is nominative use: the same one-colour rendering icon libraries such as Simple Icons and Font Awesome publish, and that many owners' guidelines name themselves (ORCID, GitHub, Forgejo, SourceHut, Bluesky, Mastodon, YouTube and LinkedIn allow black and white versions; their pages are recorded in assets/brands.txt). Where an owner's guidelines name other colours only, or cannot be read, the mark is still drawn in one colour in a list of services, because a row of coloured logos among black ones would rank the services, and because one colour is the plainest way to identify without decorating. The mark is otherwise unmodified: not redrawn, not combined with anything, not used as a button that imitates the owner's own.

and for the none bullet:

none: a mark whose owner has asked Postulo not to show it, or whose official logo is not a single shape (Wikidata's three bars), is not shipped, and the service shows its generic icon.

and replace the LinkedIn paragraph with:

LinkedIn's mark is taken from LinkedIn's own brand kit, in the black and white versions LinkedIn allows ([in] logo guidelines), because LinkedIn approves only assets from that site. Marks Simple Icons does not carry may come from Font Awesome Free (CC BY 4.0 for the drawing; see THIRD-PARTY.md); a library's licence covers the drawing, never the mark.

Rule 2's "The one exception is a colour the owner's own guidelines name" becomes "The one exception is the single-colour mode below." The "In this repository now" table's row then lists the new marks and both sources.

## Decision (maintainer, 2026-10-15) **Every service gets a one-colour mark: find alternative brand icon sets where Simple Icons has none, and render the existing ones in black and white.** The maintainer's reasoning: Font Awesome and the Simple Icons website both show brand marks in one colour, so the trademark rule is not as restrictive as `TRADEMARKS.md` assumed. This chooses option 3 (change rule 2) together with option 2 (a second set for the gaps), and reverses the "none" choices recorded in #654 and #905 for the link services. Research below, read on 2026-10-15 from the packages on npm/unpkg and the owners' own pages. ## Icon sets compared Presence checked file by file in the published npm package (unpkg) at the version given. y = present, – = absent, ? = not checked. | Set (version) | Licence | LinkedIn | Facebook | Instagram | Codeberg | Mastodon | GitHub | GitLab | Bluesky | X | YouTube | ORCID | Also | Monochrome-ready | Attribution | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | [Simple Icons](https://simpleicons.org) 16.35.0 (Postulo pins 16.34.0) | CC0-1.0 (but its [disclaimer](https://github.com/simple-icons/simple-icons/blob/develop/DISCLAIMER.md) says not every icon is CC0, and asks users to follow each brand's guidelines) | – (removed in [14.0.0](https://github.com/simple-icons/simple-icons/releases/tag/14.0.0), [PR #11380](https://github.com/simple-icons/simple-icons/pull/11380), after the maintainers asked LinkedIn for permission) | y | y | y | y | y | y | y | y | y | y | Threads, Xing, Bitbucket, Forgejo, SourceHut, Stack Overflow | Yes: one path, no fill, so it takes `currentColor` | None (CC0) | | [Font Awesome Free](https://fontawesome.com/license/free) brands 7.3.1 | Icons CC BY 4.0 (SVG/JS), fonts OFL-1.1, code MIT | y (`linkedin`, `linkedin-in`) | y | y | y | y | y | y | y | y (`x-twitter`) | y | y | Threads, Xing, Bitbucket, Forgejo, Stack Overflow; **no SourceHut** | Yes: `fill="currentColor"` in every SVG | CC BY 4.0: each SVG carries a comment naming Font Awesome and the licence, and the LICENSE asks that it not be removed. Its "Brand Icons" section: trademarks of their owners, no endorsement, "do not use brand logos for any purpose except to represent the company, product, or service to which they refer" | | [Tabler Icons](https://tabler.io/icons) 3.49.0 | MIT | y | y | y | – | y | y | y | y | y (`brand-x`) | y | – | Threads, Xing, Bitbucket, Stack Overflow; no Forgejo | Yes, but **stroke-drawn outlines** (Lucide's style), not the filled marks Simple Icons ships | MIT notice | | [Bootstrap Icons](https://icons.getbootstrap.com) 1.13.2 | MIT | y | y | y | – | y | y | y | y | y (`twitter-x`) | y | – | Threads, Stack Overflow; no Xing, Bitbucket | Yes (`currentColor`) | MIT notice | | [Material Design Icons](https://pictogrammers.com) `@mdi/svg` 7.4.47 | Apache-2.0 | y | y | y | – | y | y | y | – | ? (only `twitter` checked) | y | – | Bitbucket, Stack Overflow | Yes | Apache-2.0 NOTICE | | [Remix Icon](https://remixicon.com) 4.9.1 (`Logos/`) | Apache-2.0 | y | y | y | – | y | y | y | y | y (`twitter-x`) | y | – | Threads | Yes | Apache-2.0 NOTICE | | [Devicon](https://devicon.dev) 2.17.0 | MIT | y | y | ? | – | – | y | y | – | ? | ? | ? | Forgejo, Bitbucket | Mostly coloured "original" variants; aimed at languages and tools | MIT notice | [Iconify](https://iconify.design) repackages these same sets (`simple-icons`, `fa7-brands`, `tabler`, `bi`, `mdi`, `ri`, …) under their original licences, so it adds no new artwork; its full-colour `logos` set does not fit a one-colour rule. **Only Font Awesome Free covers every service in the selects today except SourceHut**, and Simple Icons covers every one except LinkedIn. The two together cover all of them in the same filled style. ## What the owners' own pages say about one colour - **LinkedIn** ([in] logo page, [brand.linkedin.com/in-logo](https://brand.linkedin.com/in-logo)): "LinkedIn members may only use the [in] Logo in three color variations: blue, black, and white"; blue on white is preferred; in a social-media line-up icons must use one of the three provided colours. So **black and white are allowed by LinkedIn itself**. Its [policies](https://brand.linkedin.com/policies) add "Any logos or images found elsewhere on the web are not approved for use" and "only using approved Brand assets from this site", and require that use not suggest sponsorship. The downloads ([brand.linkedin.com/downloads](https://brand.linkedin.com/downloads)) are given "by downloading … you agree to comply with the terms of the LinkedIn Brand and User Agreements". - **Facebook** ([Meta's logo page](https://www.meta.com/brand/resources/facebook/logo/)): primary Facebook Blue with a white "f", secondary white; black is not mentioned; "Do not recolor our logo to your own brand colors". White on the dark page is within the page; black on the light page is the decision's extension. - **Instagram**: as recorded in `brands.txt` (full colour or monochromatic white); Meta's current glyph page could not be fetched (404 at the URL tried). - **Codeberg** ([Codeberg/Design](https://codeberg.org/Codeberg/Design)): logo material CC0, the name and logo trademarks of Codeberg e.V.; the kit holds blue and white SVGs only (no mono file in the repo tree); "Don't tint the logo in a custom color". - **X** (brand toolkit still answers HTTP 402) and **GitLab** (design.gitlab.com now redirects to a sign-in): still not readable. So under the old rule LinkedIn alone moves from none to single-colour (from LinkedIn's own words); Facebook, Instagram (black) and Codeberg (black) need the rule change the maintainer decided; X, Threads, GitLab, Bitbucket and Xing need it too, because their pages cannot be read. ## Recommendation 1. **Keep Simple Icons as the one source wherever it has the mark**, and take Facebook, Instagram, Codeberg, X, Threads, GitLab, Bitbucket and Xing from it (they are already in the pinned package). Same filled style as today's seven, no new licence. 2. **LinkedIn**: take the black [in] mark **from LinkedIn's own download kit** (`brand.linkedin.com/downloads`), since LinkedIn allows black and white and says logos found elsewhere are not approved; record the in-logo page and its sentence in `brands.txt` like the other single-colour lines. If the kit has no usable SVG, fall back to Font Awesome Free's `linkedin` (CC BY 4.0), keeping its attribution comment. 3. **Font Awesome Free brands as the general second source** (not Tabler: Tabler's outlines would sit beside Simple Icons' filled marks, and it lacks Codeberg, ORCID and Forgejo). Use it only for a mark Simple Icons lacks, so the set stays mostly CC0. If it is used: a `THIRD-PARTY.md` row (CC BY 4.0, Fonticons, Inc.), the SVG's own comment kept, the licence named in `NOTICE.txt`, and `sync-brands.mjs` taught a `source` field (`simple-icons` | `fontawesome-free` | `owner-kit`) per line in `brands.txt`. 4. **All marks in one mode, `single-colour`, drawn in `currentColor`** (black on the light page, white on the dark), beside the service's name, decorative (`aria-hidden`), never larger than the text it labels, never as a button that looks like the service's own (no "Sign in with"/"Share" look-alikes). 5. Keep the right of an owner to say no: the existing "If you own a mark used here" paragraph, plus a `none` line in `brands.txt` for any owner who objects, with the date. 6. Tests: `tests/test_brands.py` checks each line has a source and, for `single-colour`, either an owner page or the nominative-use reason; the contrast test no longer applies to `single-colour` marks (black/white clear 3:1 by construction). ## Proposed wording for `TRADEMARKS.md` (not edited here) The current rule 2 ("only where the owner's own published guidelines allow a one-colour version in those colours"), the **none** bullet that lists Facebook, Instagram and Codeberg, and the closing "LinkedIn has no mark here, and none is taken from elsewhere" contradict the decision. Proposed replacement for the **single colour** bullet: > - **single colour**: drawn in `currentColor`, which the stylesheet makes exactly black on the light page and exactly white on the dark one, beside the service's name and only to say which service a link or an option goes to. This is nominative use: the same one-colour rendering icon libraries such as Simple Icons and Font Awesome publish, and that many owners' guidelines name themselves (ORCID, GitHub, Forgejo, SourceHut, Bluesky, Mastodon, YouTube and LinkedIn allow black and white versions; their pages are recorded in `assets/brands.txt`). Where an owner's guidelines name other colours only, or cannot be read, the mark is still drawn in one colour in a list of services, because a row of coloured logos among black ones would rank the services, and because one colour is the plainest way to identify without decorating. The mark is otherwise unmodified: not redrawn, not combined with anything, not used as a button that imitates the owner's own. and for the **none** bullet: > - **none**: a mark whose owner has asked Postulo not to show it, or whose official logo is not a single shape (Wikidata's three bars), is not shipped, and the service shows its generic icon. and replace the LinkedIn paragraph with: > LinkedIn's mark is taken from LinkedIn's own brand kit, in the black and white versions LinkedIn allows ([in] logo guidelines), because LinkedIn approves only assets from that site. Marks Simple Icons does not carry may come from Font Awesome Free (CC BY 4.0 for the drawing; see THIRD-PARTY.md); a library's licence covers the drawing, never the mark. Rule 2's "The one exception is a colour the owner's own guidelines name" becomes "The one exception is the single-colour mode below." The "In this repository now" table's row then lists the new marks and both sources.

tiagoagueda referenced this issue from a commit

2026-10-18 18:04:25 +00:00

Give every link service a one-colour brand mark

tiagoagueda referenced this issue from a commit

2026-10-18 18:04:25 +00:00

Your details: browser tests follow the pin, the one-profile rule and the new marks

tiagoagueda referenced this issue from a pull request that will close it,

2026-10-18 18:04:35 +00:00

Your details: twelve fixes and additions (#919–#932) #1005

tiagoagueda referenced this issue from a commit

2026-10-18 20:11:30 +00:00

Give every link service a one-colour brand mark