Adding ® and ™️ to icons

[dhruvkb]

Just coming from #2460. I think the outcome of the issue was that some icons in some circumstances will have the TM as a part of the icon itself. As a user of the icons, I wanted to preserve my ability to access the raw icon without such symbol, while also allowing the symbols to be there to prevent legal issues.

Regarding the implementation of these symbols in the icons, I wanted to propose some ideas:

SVG

Trademark symbols should added in different path compared to the main SVG and have the .trademark class. Currently we have a mandate of having a single path in the SVG file so we can update that rule so that the trademark path is separate and other paths are flattened to one. Adding the class to the path allows end-users to optionally remove the icon if they are allowed.

JS

Addition of multiple paths might break the way the path attribute (a string) works right now. To maintain backwards compatibility, path could serve the icon without the trademark i.e. the main path of the SVG and a different trademarkPath attribute can serve the trademark symbol path.

JSON

The JSON file can have the information about which trademark symbol is required in the SVG, and maybe some additional legal information that might then be served in the UI for informing the users of the icons about the way trademarks are handled and also about the legal requirements they must oblige by when provided with the power to show or hide the trademark symbol.

I'm not sure if there are other icons in the project with trademark symbols baked into the icon. They might need some tweaking so how to maintain backwards compatibility might be a goal of the discussion. This might be a pretty big feature change so if I wanted to discuss if this is something we can incorporate into the roadmap for the project.

[adamrusted]

Thanks for starting this discussion @dhruvkb - it's always been something we've debated on a case-by-case basis.
Further to @PeterShaggyNoble's comments in your original message - I've detailed my thoughts below.

I've always worked to the idea that this project is to provide SVG paths in the simplest possible format, with no classes or styling affecting anything at all. The ability to search a brand, and either save the SVG or copy the path directly for use in other projects has been a big plus for me personally, and I know that's how this project is used by a lot of other people - who may have struggled to find a decent SVG otherwise.

That being said, and given the global reach of the project we do need to pay attention to any trademark / copyright guidance, no matter how ambiguous that guidance may be. When it is clear that the trademark path isn't needed, we of course remove it before including it in the icon pack - to save space and provide cleaner paths to our users - but when it's ambiguous or differs between jurisdictions - it's safer for us to include it to avoid ourselves or any of our end users landing in hot water legally for not including the relevant symbols.

Your proposed idea of de-facto not including the trademark in the path entry of the JSON would mean a lot of our users would end up breaching trademark terms simply by continuing to use our pack without adapting their codebase (pulling the path data from the JSON, as opposed to using the actual SVG itself) - which doesn't seem right to me. I also don't see the need to include it as a separate path within the SVG. If the brand insists on it's inclusion then we shouldn't be making it easier for our users to remove it - and 9/10 times when it isn't required, we don't include it anyway (I'd be more than happy to review any icons that you think have it erroneously included at present).

When specific guidance is given surrounding the use of a icon including placement / specific colours / trademark terms, we are starting to apply the guidelines entry in the JSON which will display on the new website - and I feel that's a non-obtrusive way to provide our users with the reasoning behind the inclusion of such icons - as well as how they should use the icons in their projects.

While our JSON is getting quite busy now, I think it's important to keep the SVGs themselves as simple as possible - both in their appearance, but also in their drag-and-drop usability in all regions by including the necessary icons in the core path.

[ericcornelissen]

I agree that the SVG should stay as simple as possible, but I disagree that adding a second path makes the SVG to complex for end-users.

For contributors having an optional second path complicates things a bit, but I think that is okay. Not all SVG contributions need to be super simple, and sometimes having to split a path in two should be doable.

[ericcornelissen]

As a user of the icons, I wanted to preserve my ability to access the raw icon without such symbol, while also allowing the symbols to be there to prevent legal issues.

I understand that users want to do that, but it's not up to the user, it's up to the company who's logo it is who have the right to specify how their logo should be used. I personally agree that company shouldn't require any of these symbols in their logos, at least not in all circumstances, but unfortunately they do.

And for the record, yes, there are still going to be people who use the logo without the symbol. That is not a reason for us not to include it.11

Trademark symbols should added in different path compared to the main SVG and have the .trademark class. Currently we have a mandate of having a single path in the SVG file so we can update that rule so that the trademark path is separate and other paths are flattened to one. Adding the class to the path allows end-users to optionally remove the icon if they are allowed.

I do want to point out that this is really interesting and we should consider it, at least in some scenarios. However, I think this should be used sparingly, only when it is ambiguous if the symbol should be included or potentially when it depends on the region. I definitely don't think we should always have the symbol as a separate path, if the brand requires it, we should not make it easy to remove. This makes it a little bit difficult from our side to support this, as it makes reviewing Pull Requests more subjective than necessary. Still, I like the idea. If @simple-icons/maintainers that actually review icons regularly are okay with it I would like to investigate how feasible this is with our linters.

Addition of multiple paths might break the way the path attribute (a string) works right now. To maintain backwards compatibility, path could serve the icon without the trademark i.e. the main path of the SVG and a different trademarkPath attribute can serve the trademark symbol path.

Though this is an interesting proposal, I think we're better of using a solution that works for everyone and not only for people that use the NPM package.

The JSON file can have the information about which trademark symbol is required in the SVG, and maybe some additional legal information that might then be served in the UI for informing the users of the icons about the way trademarks are handled and also about the legal requirements they must oblige by when provided with the power to show or hide the trademark symbol.

I'd be against putting text in the JSON as that is very subject. As pointed out by @adamrusted, the guidelines field in the JSON data should contain most of the information related to TM or copyright symbols.

[dhruvkb]

The main idea behind my message was keeping the trademark symbols separate from the brand image itself and not flatten them into a single path. People using the SVG directly would still get both the icon and the trademark but knowledgeable users could then, fully aware of what they are doing, hide the symbols if their situation allowed for it.

This gives us the advantage of providing fully compliant versions of logos by default, but providing enough metadata (using classes on the paths) to the advanced users to customise the icons without having to fork and manually edit the SVG paths.

[ericcornelissen]

I understand, but I disagree to an extend. If the brand is explicit about the inclusion of such symbols I don't think we should even "allow" hiding it through a separate path. Indeed, if it is ambiguous or only required in certain regions (or something else I can't think of now) we can split the paths making it easier to hide it for end users if they so wish, shifting the burden to them in that case.

[...] but knowledgeable users could then, fully aware of what they are doing, hide the symbols if their situation allowed for it.

Consider the following scenario: one developer adds a Simple Icons SVG to the project where they think the symbol can be omitted. So they add some CSS (e.g. svg > .trademark { display: none } to hide it. Later, another developer adds another Simple Icons SVG where the symbol should never be removed (i.e. the brand is explicit about it's inclusion). However, as we split the path of the symbol this symbol is now also hidden.

This may be a bit of an extreme case, but the point is that there is no reason to even allow hiding the symbol on icons where the brand is explicit about its inclusion, because it could go wrong.

This actually brings up some more questions, such as: should we provide multiple classes so that it is easier to hide e.g. the symbols only in certain regions - considering that IBM only seems to require it in the US (ref. #5522).