Add DTS

[PeterShaggyNoble]

Issue: Closes #3610
Alexa rank: ~413k

Checklist

• I updated the JSON data in _data/simple-icons.json
• I optimized the icon with SVGO or SVGOMG
• The SVG viewbox is 0 0 24 24

Description

No official vector version of this that I could find but this page does state that there is a library coming soon so we should keep an eye on that until this is merged. We should also keep an eye on its Alexa rank which has declined since the original request was made. Colour from website stylesheet.

[adamrusted]

In the DTS Terms and Conditions it states:

The use of any DTS trademark or service mark without our express written consent is strictly prohibited. In order to maintain the value of these marks, it is important that they are used correctly. If you have any questions, you may contact our Legal Department at legal2@dts.com .

Does this therefore mean we shouldn't be including it?

[PeterShaggyNoble]

Does this therefore mean we shouldn't be including it?

Probably, yes. I missed that myself. We do have plenty of other icons in our library with similar restrictions on their usage, though.

[adamrusted]

Pinging @simple-icons/maintainers for feedback regarding point raised in #4629 (comment) - do we go ahead and add this anyway, or go by the wording there? As @PeterShaggyNoble says, we likely have a lot of icons already in the library that have similar terms.

[fbernhart]

I'm in favour of asking for permission to use the logo.

It would be pretty bad if Simple Icons ever gets confronted with trademark infringements or something similar because we didn't have the permission to use the logo.

We do have plenty of other icons in our library with similar restrictions on their usage, though.

Just because we (maybe) haven't been doing it in the past doesn't mean that we should continue doing it in the future. 😄

How about setting up an internal email address, that we could use to get such permissions? We could create a template email that we could then use to ask for permissions. Something like:

• We're the maintainers of Simple Icons
• This is what this whole project is about
• This is why we would like to add your logo to our website
• Are you ok with the suggested monochrome treatment?

If we get an answer, we could publicly post it under the corresponding issue/pull request.

[PeterShaggyNoble]

I think, for me at least, this is now rendered moot by the addition of the "brand guidelines" key to simple-icons.json and that the onus should be (and, to some degree, always has been) on our users to ensure they are using our icons in adherence to those guidelines. The problem with us requesting permission is that the company will want to know the use cases of our users, which is something we can't definitively answer so a lot will end up denying us out of hand for that reason.

It would be pretty bad if Simple Icons ever gets confronted with trademark infringements

That we haven't, in all this time and with all these icons, received a single takedown notice or cease-and-desist yet amazes me. Any icon library that includes brand icons should be expecting to receive them - FontAwesome, for example, recently had one from Adobe - and should we ever receive one we will, of course, act on it immediately but I don't think it should factor into our decision to add an icon with some obvious exceptions like DIsney.

[adamrusted]

I think if we link to the specific trademark terms as the guidelines tag, and @ericcornelissen is able to add some kind of 'warning' alongside icons with guidelines highlighting that users should read them before use - that should cover us.

As you say, should the project receive a takedown for an icon we can of course act on that immediately.

[ericcornelissen]

I think if we link to the specific trademark terms as the guidelines tag, and @ericcornelissen is able to add some kind of 'warning' alongside icons with guidelines highlighting that users should read them before use - that should cover us.

If you mean "depending on the contents of the guidelines add a warning", then theoretically but not in practice 😅 Given #2846 the best we can practically do is add a link that is styled the same for all brands (that have guidelines).

[adamrusted]

If you mean "depending on the contents of the guidelines add a warning", then theoretically but not in practice 😅 Given #2846 the best we can practically do is add a link that is styled the same for all brands (that have guidelines).

Yeah - I just meant that if there is a guidelines entry, then there is an obvious 'guidelines' button which screams "read me before using this icon" 😆

[PeterShaggyNoble]

I think we'd need to be wary of drawing too much attention to the guidelines with regards to requesting permission for an icon's use as we want to avoid suggesting

1. that the presence of guidelines means you have to seek permission,
2. that the guidelines we've linked to are the most up-to-date ones, and,
3. much worse, that the absence of guidelines means that you don't need to seek permission.

A disclaimer somewhere on the site or in our README would probably work better, pointing out that while we put every effort into providing guidelines, it's an ongoing project and existing guidelines are subject to change so it's up to the user to do their own due diligence to ensure they are using each icon correctly and with permission. They won't, of course, but at least it covers us! We could also include some more legalities in that disclaimer along with information on how to request a brand's removal from our library.

[ericcornelissen]

I think we'd need to be wary of drawing too much attention to the guidelines with regards to requesting permission for an icon's use as we want to avoid suggesting

1. that the presence of guidelines means you _have_ to seek permission,

2. that the guidelines we've linked to are the most up-to-date ones, and,

3. much worse, that the absence of guidelines means that you don't need to seek permission.

A disclaimer somewhere on the site or in our README would probably work better, pointing out that while we put every effort into providing guidelines, it's an ongoing project and existing guidelines are subject to change so it's up to the user to do their own due diligence to ensure they are using each icon correctly and with permission. They won't, of course, but at least it covers us!

I think that is a good point, and it also avoid ugly design to draw the users attention on the website 😄 I'd say the disclaimer should be there both in the README and the website, and, to the extend we're able to, maybe even in the README's of third party extensions.

We could also include some more legalities in that disclaimer along with information on how to request a brand's removal from our library.

That is an interesting idea that I'm in favor of. Not sure how to execute it, I would avoid putting the details in the README or on the website 🤔 Maybe a LEGAL.md file that is being linked to from everywhere? Not sure if this is a convention like README, LICENSE, CONTRIBUTING, and SECURITY are but it seems to me like a decent approach.

[PeterShaggyNoble]

I feel like I've seen DISCALAIMER.md in a few repos. Whether I'm imagining that and if it's a standard, I don't know, though.

Would it not be better on the website, though, than buried in our repo? For the benefit of people unfamiliar with GH.

[ericcornelissen]

I feel like I've seen DISCLAIMER.md in a few repos. Whether I'm imagining that and if it's a standard, I don't know, though.

That works for me, if there is any filename that is already being used that fits our purposes I'd vote in favor of that. Is any of the @simple-icons/maintainers or someone from the community good with GitHub search that can figure out which one of these, or something else, is more common?

Would it not be better on the website, though, than buried in our repo? For the benefit of people unfamiliar with GH.

I think it should be available on both, I don't expect those who use the NPM or Packagist packages to necessarily look at the website but I do expect them to look at the README. Luckily it is easy to covert MarkDown into HTML (both with the current website and the redesign).

[adamrusted]

Is any of the @simple-icons/maintainers or someone from the community good with GitHub search that can figure out which one of these, or something else, is more common?

disclaimer.md and legal.md are both used fairly widely, though disclaimer seems to be more popular. I think it's the better wording also, as we're not giving legal advice, just airing that while we catalogue icons and share guidelines etc, people should do their own research.

[ericcornelissen]

With #4868 for the discussion regarding the disclaimer, we still need to decide what to do with this one. I would be inclined to say no (and remove any brands with similarly strict guidelines) because of "The use of any DTS trademark or service mark without our express written consent is strictly prohibited". On the other hand, I can also see the argument for saying that the onus is on the end-user because of #2846, they can remove it for themselves if requested by DTS and so can we. The reason I'm inclined against this is that the icon being available in our collection can be signal to many users that it's fine for them to use as well - and having a DISCLAIMER.md and link to the guidelines isn't enough to convince most users to request written consent from DTS.

[PeterShaggyNoble]

The reason I'm inclined against this is that the icon being available in our collection can be signal to many users that it's fine for them to use as well

I think that's exactly what our legal documentation and the guidelines entry should be for. As with any other legal documentation, the responsibility is on the user to ensure they read and adhere to it. Of course we all know that, in practice, nobody reads such documents but us providing them should cover us if the users uses an icon that isn't in accordance with the brand's guidelines. It doesn't, though, cover us for the mere presence of an icon in our library and on our website but we can add a note to DISCLAIMER.md about contacting us if you object to your brand being included in our library.

My bigger worry is that if we set the precedent here by rejecting this, we're going to have to do a full review of our icons to remove all others that have similarly strict requirements and there will be a lot of them.

[ericcornelissen]

Fair enough @PeterShaggyNoble, I'm really just slightly included to not allow it but the combination of he arguments 1) the guidelines field, 2) the DISCLAIMER.md, and 3) precendent+existing icons seems good enough to me to include it anyway.

However, I think that does mean this and similar PRs should stay on hold until #980(*) and #4912 are resolved - unfortunately I don't think we can do anything about the icons with similarly strict requirements already in the collection, but we can at least do are best with new inclusions.

---

(*): or if we add the guidelines links to the existing website.

[service-paradis]

If we take the decision to include those icons, we should probably ignore them for the Open Graph generation to minimize the use.

The use of any DTS trademark or service mark without our express written consent is strictly prohibited.

In fact, I'm still not sure that we can display those icons on the website even with a disclaimer.

[adamrusted]

No longer pending, following the inclusion of the DISCLAIMER.md.

[ericcornelissen]

While the SVG looks perfect as is, shouldn't the registered trademark symbol of the source be kept?

[PeterShaggyNoble]

While there's nothing explicit stating that we should include it, @ericcornelissen and I'd personally prefer to omit it, the fact that they include it everywhere the logo appears themselves suggests to me that we should keep it. I'll leave this over the weekend for the other @simple-icons/maintainers to have their say before updating, though.

[jorgeamadosoria]

current Alexa (08/14/2021) is ~643k. (https://www.alexa.com/siteinfo/dts.com)
Perhaps we should wait a bit before merging this one and see if it recovers?
Also, I think the registered symbol should be added. They seem to preferred it that way (they have even in their own website logo, which is a bit extreme in my opinion).

[jorgeamadosoria]

follow up check on Alexa: ~589k. Still low.
I vote that if it doesn't break 500k in the next 25 days, we close this PR as "won't add" for that reason. What do you think @ericcornelissen @PeterShaggyNoble @adamrusted?

[ericcornelissen]

Hmm, interesting 🤔 I wonder what happened on August 10...

Given the clear drop off on August 10, I feel like we can close it on September 10 (i.e. one month) if it doesn't appear to be recovering by then. Alternatively 25 days from today works as well. We should probably agree on an amount of time an Alexa rank is allowed to be too low before an icon is rejected or removed.

[jorgeamadosoria]

Hmm, interesting 🤔 I wonder what happened on August 10...

Given the clear drop off on August 10, I feel like we can close it on September 10 (i.e. one month) if it doesn't appear to be recovering by then. Alternatively 25 days from today works as well. We should probably agree on an amount of time an Alexa rank is allowed to be too low before an icon is rejected or removed.

agreed on the definition of an amount of time a brand is allowed to be under 500k after acceptance / before inclusion. I think a month is ample time, perhaps even too much.

[ericcornelissen]

It's been well over a month, and while the Alexa rank has been climbing steadily towards 500k, I'm going to close this now as it still hasn't quite reached the 500k to clear the backlog of PRs a bit. Happy to revisit this here or in a new PR if it manages to surpass the 500k.