Should temporary brand logo changes be ignored?

[LaoshuBaby]

Recently, some editors from China (not me) noticed that McDonald's logo has turned into a purple monster(?), thinking that the data in OSM maybe affected or linked wrong, linked to another wikidata, but after my research found that it was actually because McDonald's (US business department?) changed Twitter and Facebook's avatar to promote their new campaign.
For regions that have these events - people obviously easy to spot and even feel surprise(?), but for regions that don't, does a change to the very familiar logo make editors wonder Puzzled. (For example, at least in Greater China, I have never heard of it)

I know it's not NSI's fault - it's just very faithfully scraping the Twitter/Facebook avatar data from Wikidata - and showing it, but I wonder if there is a way for us to avoid this abrupt change, for example setup a cache? (But I think there must be a copyright issue)

[1ec5]

This happens occasionally with high-profile brands: openstreetmap/iD#6361 #2798 #3122 #8042. The best we’ve come up with so far has been to hard-code a list of brands that always get a logo from Commons via Wikidata, which would work for McDonald’s too:

name-suggestion-index/scripts/dist_files.js

Lines 287 to 294 in 21597bd

	// Prefer a wiki commons logo sometimes.. openstreetmap/iD#6361
	const preferCommons = {
	Q177054: true, // Burger King
	Q524757: true, // KFC
	Q779845: true, // CBA
	Q1205312: true, // In-N-Out
	Q10443115: true // Carlings
	};

I guess we could’ve foreseen Grimace’s birthday plans based on the controversy on Fandom. But overall, this is a pretty reactive approach to mitigating against social media cheekiness. By the time we fix it, the campaign is already over. I don’t know how the social media managers would feel about knowing their hijinks show up in such a different context.

I know it's not NSI's fault - it's just very faithfully scraping the Twitter/Facebook avatar data from Wikidata - and showing it, but I wonder if there is a way for us to avoid this abrupt change, for example setup a cache? (But I think there must be a copyright issue)

Caching Facebook or Twitter profile photos en masse would definitely be a copyright issue.

Fetching more logos from Commons was considered in #2641, but the concern then was that many of the logos were the wrong aspect ratio or format, and that filtering candidate Commons images was too much work for too little gain. Let’s just hope Grimace doesn’t inspire more copycats in the hamburglar joint industry.

[Cj-Malone]

copyright

Has any brand ever contacted NSI in any way? Caching logos may (or may not) be an issue legally, but I doubt it'd be an issue in reality.

However even if we decided we wanted to cache/pin logos, it may be an issue with time/maintainability.

[Cj-Malone]

I didn't know how the Facebook logos worked, so I just looked.

We have https://graph.facebook.com/mcdonalds/picture?type=large with currently redirects to https://scontent-lcy1-1.xx.fbcdn.net/v/t39.30808-1/352182966_933826537731666_7750752210836834314_n.jpg?stp=dst-jpg_p200x200&_nc_cat=1&ccb=1-7&_nc_sid=dbb9e7&_nc_ohc=DkdgToLe0XcAX_fOGL9&_nc_ht=scontent-lcy1-1.xx&edm=AKsJ254EAAAA&oh=00_AfD11ebznoJ-pISlfWzgb2KEY5G2fBbEAi6lu8m0jPb4cg&oe=64AEE6BA (purple monster). But does the old redirected url still work? I don't know.

[1ec5]

Has any brand ever contacted NSI in any way? Caching logos may (or may not) be an issue legally, but I doubt it'd be an issue in reality.

More precisely, the fact that we aren’t redistributing the logos mitigates concerns about copyright infringement: openstreetmap/iD#5167. That said, proxying the APIs has been floated in the past as a mitigation for privacy concerns: openstreetmap/iD#7028. The terms-of-service implications of either step are unclear to me. If proxying is OK then maybe caching would be too, but this is a lot of complexity compared to, say, fetching more logos from Commons.

[Cj-Malone]

The raw url has a time in it, so will expire soon, so we can't cache the URLs.

Commons

Commons makes it clear they don't want (most) logos. And relying on it for more logos will lead to the opposite problem: us having old logos. I think that'd annoy brands more than caching logos. And there is the possibility of malicious edits to Wikidata.

Adding McDonalds to preferCommons is a valid quick fix, but I don't think it's the long term solution. I've asked Wikidata people before if they know of a service that has some kind of item to logo map. So far nobody knows of one.

[bryceco]

Hosting a private copy of the logos is the route I took for my app. Sites like
https://logodix.com and https://www.brandsoftheworld.com/
seem to have no problem hosting and distributing logos.

If you read this article (scroll down to the section titled “Fair Use of Logos”) it seems that hosting the logo should be fair use:

• There’s no attempt to confuse or mislead the user through its use
• There’s no profit derived from use of the logo
• It doesn’t diminish or dilute the brand owner

[Cj-Malone]

I'm getting a little off topic, but fetchFacebookLogo currently downloads the image. If we add redirect=false we get JSON eg. It's probably smaller, and so faster.

[1ec5]

Commons makes it clear they don't want (most) logos. And relying on it for more logos will lead to the opposite problem: us having old logos. I think that'd annoy brands more than caching logos. And there is the possibility of malicious edits to Wikidata.

I've asked Wikidata people before if they know of a service that has some kind of item to logo map. So far nobody knows of one.

What you were hearing about the Commons route was misinformed. Commons only stores the images. It’s Wikidata itself that maps items to logos, and we’re already using it for quite a few NSI entries, especially in the transit tree, just not preferring it over Facebook and Twitter. When Commons can’t cover the latest logo design over copyright concerns, Wikidata says so (novalue or somevalue).

[Cj-Malone]

What you were hearing about the Commons route was misinformed. Commons only stores the images. It’s Wikidata itself that maps items to logos, and we’re already using it for quite a few NSI entries, especially in the transit tree, just not preferring it over Facebook and Twitter. When Commons can’t cover the latest logo design over copyright concerns, Wikidata says so (novalue or somevalue).

I know Wikidata links to Commons. I should have been clearer in that comment. I don't know of another service (that will host logos) that can be linked with Wikidata, either Wikidata linking to it, or it linking to Wikidata.

[LaoshuBaby]

This happens occasionally with high-profile brands: openstreetmap/iD#6361 #2798 #3122 #8042. The best we’ve come up with so far has been to hard-code a list of brands that always get a logo from Commons via Wikidata, which would work for McDonald’s too:

It seems that the original problem has been solved (oh no, not a solution, only a workaround)
Let's keep adding McDonald's QIDs to this list - but @1ec5 is right, “ignore” the temporary change means tag it separately, we can't keep up with the jokes of these brands, we're always going to be reactively updating this list - unless we take some proactive defensive measures like automatically adopted the common icon for brands whose total count exceeds a threshold, to prevent sudden bad jokes from getting us confused.

I added it, so I close this issue, but looks like discussion on how to solve still continue, about copyright or about a threshold?

[bhousel]

I'm getting a little off topic, but fetchFacebookLogo currently downloads the image. If we add redirect=false we get JSON eg. It's probably smaller, and so faster.

Hey this is cool and I didn't know about it - I'll open a separate issue to see whether we can just use this result instead of actually fetching the image.

IIRC, the main reason for fetching the Facebook image was these lines of code to determine whether the result actually has a logo or returns a question mark placeholder image. #2750

name-suggestion-index/scripts/build_wikidata.js

Lines 609 to 611 in 5dddc11

	if (response.headers.get('content-md5') !== 'OMs/UjwLoIRaoKN19eGYeQ==') { // question-mark image #2750
	target.logos.facebook = logoURL;
	}

But I see the graph api does return a property like "is_silhouette": false so maybe that's just as good.

[bhousel]

Oh and about this issue - I am pretty ok with just updating the preferCommons list whenever we find that a brand is changing their social media profile picture in a way that might confuse our users. It's a very small list, and a thing that happens rarely, and a very quick fix.

name-suggestion-index/scripts/dist_files.js

Lines 287 to 296 in 5dddc11

	// Prefer a wiki commons logo sometimes..
	// Related issues list: openstreetmap/iD#6361, #2798, #3122, #8042, #8373
	const preferCommons = {
	Q177054: true, // Burger King
	Q524757: true, // KFC
	Q779845: true, // CBA
	Q1205312: true, // In-N-Out
	Q10443115: true, // Carlings
	Q38076: true // McDonald's
	};

I understand that for some apps it might make sense to download and cache all the logos, or to try to build something special to try to work around this issue, but I just don't see this as an important enough problem to spend development time on right now. It would be awesome if all the logos were public domain or in Commons, but we don't have that.

If someone wants to make another project that just takes all the logo URLs that NSI has gathered, and saves those files somewhere, and it turns out to be helpful to someone, then yeah someone can build and maintain that. 👍