Licensing and attribution for custom Emojis

[ghost]

The Custom Emoji feature currently makes the assumption that uploaded Emojis are under a public domain license.

Instance admins should be able to include licensing and attribution information for Emojis that can be reviewed by others and is copied along with the Emoji.

This will allow artists to receive credit for their work while allowing admins to decide whether or not they agree with the licensing terms, helping them prevent copyright and licensing disputes.

---

• I searched or browsed the repo’s other issues to ensure this is not a duplicate.

[nightpool]

The Custom Emoji feature currently makes the assumption that uploaded Emojis are under a public domain license.

can you explain a little bit more? Where is this assumption made?

[ghost]

@nightpool
That may have been badly-worded.

Due to the lack of information in the UI, an admin could be unwittingly breaking the licensing terms of the artwork they're using.

For example, it was previously safe to use an Emoji set licensed under CC BY-NC-SA, such as @dzuk@a.weirder.earth's Mutant Standard, provided that attribution and license information is kept intact (or placed on the instance about page).

With the introduction of the copy feature, there is not a way to send the licensing information along with the Emoji artwork, which leads to me believe that a public domain image is expected.

This could also break the distribution terms of the Emoji that have already been uploaded.

[dzuk-mutant]

I'm basically just +1'ing, but as the creator of Mutant Standard (which as far as I know, many of it's emoji are rather popular on Mastodon instances that currently do custom emoji) features that maintain licensing are really important to me.

The copy feature (as it is) worries me because as @monsterpit-daggertooth said, my emoji could be shared quite easily without the copiers knowing what the licensing is.

[Gargron]

Instance admins should be able to include licensing and attribution information for Emojis that can be reviewed by others and is copied along with the Emoji.

The assumption seems to be that all instance admins are careful enough to write down license/attribution information when uploading an emoji. In that case wouldn't they also be careful enough not to use an image that does not have permissive-enough license? I think the limitation of this approach is that the uploads come not from the artists themselves (unless the admin is the artist)

While I can see ways to have this information be storeable, I don't see a way to display it to the end-user, and I doubt the practicality of it. To start with, things like Mutant Standard are emoji packs, which are meant to, for example, take the place of Twemoji or EmojiOne, not be "custom emoji" - I think that is a misuse regardless of license.

I think this issue is asking for a technical solution to a social problem. However, I could add a checkbox to the emoji upload screen, with the words: "The author of the image has given me permission to redistribute it without attribution", which needs to be checked or the file won't upload. Would that be good enough?

[akihikodaki]

#5145; tracking the source of emoji is related to attribution problem. It is more important when a dispute happen, not when preventing.
So what happens in a dispute when emoji copy feature is enabled? The entity whose copyright is violated should determine where is the source. It is difficult if the copied emoji is so common (A copied from B, B copied from C, ... such kind of a case is common on the Internet.) Even if he found the source and managed to take it down, he should ask to the admins of literally all instances which has the copied emoji. That is really tough and does not scale.

[dzuk-mutant]

@Gargron Some of the emoji are meant to be replacements, and some are not, but it's structured in such a way where they can be either. I was meaning the latter with this kind of situation in particular but this could happen to any of them.

I don't see how it's a purely social issue when software can lead people to make wrong decisions because the right information isn't available. With the way this is currently set up, an admin could very innocuously copy an emoji without realising licensing requirements. As @monsterpit-daggertooth kinda said, the fact it can't allow people to make informed decisions on this front basically does assume public domain.

Asking admins to make sure they know what the rights are does not address this issue. When it's just a bunch of images in a list, how are they going to know where the emoji came from to be able to determine the licensing?

There is something that could lead to a more viable option - an emoji creator can embed licensing metadata directly into the emoji files with XMP metadata in PNG and <metadata> in SVG (both of which I do with my emoji). This way, an admin doesn't have to do anything, the software just has to make sure it doesn't scrub it in the uploading process and makes that information viewable to an admin.

[dzuk-mutant]

Another viable option IMO would be simply to remove the copy feature. I'm guessing developer resources are rather limited and that might mean there's not an easily attainable solution that enables copying and gives admins the information they need to make informed decisions about licensing.

Admins might find another way to copy like this in a relatively ignorant way but at least Mastodon itself wouldn't be facilitating it. Not having it (I assume) would probably force most admins to seek emoji themselves, and thus, find the emoji with the licensing their creators gave them.

It means that Mastodon's custom emoji systems wouldn't conflict with the needs of certain licenses and it wouldn't make it Mastodon's responsibility (in my opinion) to make that information available so artists don't go without being credited where appropriate.

[NFGman]

Hi! I'm a content creator. Specifically, a photographer. I've also been a writer, and I dabble in art and whatever. I make stuff. Copyright and how my stuff is handled by society at large means something to me. I'm invested.

You can't control the users. You can't attach attribution or licensing detail in a way that can be enforced, or that functionally matters to the end user. You just can't. Whatever you do, they can work around. Your stuff is out there, and it can't be controlled or retrieved and put back in a box.

I'm not unsympathetic, but I've been online since 1200 baud was four times faster OMG. I follow the debates, I make stuff too. I get it.

What you're asking for is an impossibility. The very first person to right-click save-as completely breaks your attribution metadata, forever.

When I release an image, I know it's out of my control forever. Hell, I put that on my model release, with a checkbox for the model [✔] I understand how the internet works.

I can't say that you should do it my way, you gotta do what you think is right, but chasing after the breakers of your license is an endless job. There are no solutions, technical or otherwise. It's unreasonable to expect anyone to be able to fix this in a meaningful way.

[dzuk-mutant]

@NFGman It's not about chasing people. It's about Mastodon taking responsibility at a systematic level so people who don't intend to break licenses or go against the wishes of the creators don't do it without knowing what they were in the first place. It's really simple. I have no interest in chasing everyone on the internet, this has nothing to do with that.

[NFGman]

Yeah, fair enough.

But you're seeking to create a reduced user experience and more work for the devs in pursuit of a system that can be trivially broken by everyone with a working mouse.

As I say, I sympathize. I love your emojis, they're excellent. But I hope you see why I don't think it's a good idea.

[yiskah]

I don't see how metadata creates a reduced user experience. No user would see it but it would be attached to the file so long as it is a proper copy.

[NFGman]

Well one assumes there's a way to view it, complicating the UI at some point, right? "I don't understand this stuff, can I use this or not?"

If the metadata isn't front and center, no one knows it's there. If it is, it's clutter. I dunno, maybe you have an idea for making this invisible but still obvious, there's almost certainly something I'm not seeing. What do you propose?

And the metadata only works so long as no one saves and re-ups your emoji. Then it's broken and all that work was for naught.

[dzuk-mutant]

@NFGman But that's a pretty out there scenario, and not the kind of situation I'm talking about. I'm explicitly addressing a situation where someone wouldn't want to go out of their way to not pay attention to licensing or would want to actively remove licensing information.

Plus with federation and the fact my emoji (with RDF metadata) are already out there, the version that is more likely to be available (providing a hypothetical solution where someone would actually want to go out of their way to remove my RDF metadata) would be the original one.

[NFGman]

Sorry, I'm not quite sure which scenario is 'out there'. Right clicking, saving and re-uploading an image?

Correct me if I'm wrong, please: you want the Mastodon network to carry and make users aware of an emoji creator's identity, and intended licence, isn't that the case?

All I'm saying is that no matter how you do this it'll be bypassed with a trivial amount of effort and add weight to the UI (and developer time etc).

Assuming I've got your desire right, and given what I've said, why does this seem like a good idea to you? What are you thinking that I don't get?

[yiskah]

What Dzuk is saying that the information should be made available to admins so that they at least are able to know the license it’s not about preventing people from stripping the metadata but allowing it to be possible for someone to even know the license so they are able to follow it.

I can’t know who made an image or what the license is if that information is not available. It’s one thing to know a license and choose not to follow it. This is just about even giving the option to follow a license by knowing it’s there at all.

Image files carry metadata and if you save the file it should perverse the metadata when you download it. The metadata can be stripped if want to do so but that’s not the point. The point is that it’s there at all if somoneone isn’t set it on stripping it.

[NFGman]

I understand what you're saying, and I appreciate the ideas behind it.

If the only thing that you really want is a license input field on upload, and a way to view that metadata, I think that's perfectly reasonable.

[ghost]

an emoji creator can embed licensing metadata directly into the emoji files with XMP metadata in PNG and in SVG

Sounds like the way to go, maybe we could append the instance's name too? The existing metadata (if any) could be displayed to the admin during the creation, with a simple field to add stuff if necessary. Boom, they're now served with attribution and info about which instance it originally came from, with no need to change the user UI.

[aschmitz]

XMP metadata is arguably the right place for this data (as it's nominally carried along with the image, and takes a bit of effort to strip). However, it looks like we currently strip all metadata (presumably for the space savings?): https://github.com/tootsuite/mastodon/blob/master/app/models/custom_emoji.rb#L27 . It might be worth looking into leaving XMP around even if we want to strip other things.

[aschmitz]

If we want to make this change, this should just be a matter of changing -strip to -define png:exclude-chunk=EXIF,iCCP,sRGB,tEXt,zCCP,zTXt,date in the line I linked to. I can spin that out a PR if appropriate.

(References: see "png:include-chunk" under ImageMagick's -define documentation for the default -strip options, and section 1.1.5 of Part 3 of the XMP spec to show that XMP should go in the iTXt chunk.)

[nightpool]

@aschmitz I don't think png / xmd metadata is the right place for this. Nobody supports it and it'll be practically impossible to reference from any client. Now that emoji are a full activitypub object we should just at an attribution text field there.

…

On Tue, Oct 17, 2017 at 11:49 PM aschmitz ***@***.***> wrote: If we want to make this change, this should just be a matter of changing -strip to -define png:exclude-chunk=EXIF,iCCP,sRGB,tEXt,zCCP,zTXt,date in the line I linked to. I can spin that out a PR if appropriate. (References: see "png:include-chunk" under ImageMagick's -define documentation <https://www.imagemagick.org/script/command-line-options.php#define> for the default -strip options, and section 1.1.5 of Part 3 of the XMP spec <https://wwwimages2.adobe.com/content/dam/acom/en/devnet/xmp/pdfs/XMP%20SDK%20Release%20cc-2016-08/XMPSpecificationPart3.pdf> to show that XMP should go in the iTXt chunk.) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5239 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAORV3RaR18v4VnK8LAjTLlJJUhzvnFSks5stXU3gaJpZM4PwCoq> .

[aschmitz]

Well, XMP does make it a lot easier for emoji creators to embed the metadata once and be done, rather than hope that every user of the image also applies the correct metadata to it when uploading. It's a defined standard that people seem to use, so I figured piggybacking on it makes sense (and is nigh-infinitely easier) rather than inventing our own.

With that said, I'm not in a position where I'm likely to be creating many custom emoji or worrying about having them attributed to me if I do (though I support people who want credit for their work), so if people who will actually be affected by it want something-that's-not-XMP, I won't quibble much either.

[yiskah]

We could have it so Mastodon reads XMP metadata and if present puts it in the AP field automatically

[joyeusenoelle]

Digging up a five-year-old issue isn't usually my style, but I had an idea for a suggestion and wanted to make sure I wasn't duplicating effort, and I find myself baffled by the conversation that went on here.

Of course someone can simply right-click > save > re-upload an emoji. That's not the issue at hand; it's a distraction. The issue is Mastodon automating the process. It's been five years, apparently, since the ability to seamlessly copy custom emoji from another instance was added to Mastodon, and many custom emoji have been spread across the fediverse, each time with a single click, with little concern for how sourcing or licensing works. I have in the past week had someone be absolutely astounded at the idea that I had created one of the emoji they use regularly.

This is long overdue, but here's my suggestion (note that I am using the capitalized words and phrases MUST, MUST NOT, SHOULD, SHOULD NOT, and MAY in a standardized, idiomatic way):

• Add a Source text field to the Add new custom emoji page. This should be auto-populated with the fully-qualified URL of the instance on which the emoji is being uploaded. It MUST accommodate text of a length sufficient to permit URLs of a reasonable length. It SHOULD accommodate linkable URLs, which can link to a user's profile, a repository, a licensing document, etc. It SHOULD NOT accommodate extended text, like the full text of a license. It SHOULD be nullable (i.e. contain an empty value).
• Add a Copyable checkbox to the Add new custom emoji page. This SHOULD be checked by default. If the Copyable checkbox is unchecked, the emoji MUST NOT be able to be automatically copied by other instances.
• Add an entry to the emoji list on the Custom emojis page for the emoji's Source. This SHOULD be wide enough to display a substantial portion of the existing source. This should be an editable field, so that if a source is found for an emoji uploaded with unknown provenance, it can be amended. This should abide by the following rules:
  ** For custom emoji that were uploaded to the local instance: this field MUST be available and editable. The edit history SHOULD be preserved.
  ** For custom emoji that were copied to the local instance: this field SHOULD be available and MAY be editable, but if it is editable, the edit history MUST be preserved.
  ** For custom emoji that have not been copied to the local instance: this field SHOULD be available and SHOULD NOT be editable.
  ** If no source information has been provided, the field SHOULD be populated with a default value: for example, Unknown source.
• If an administrator copies a custom emoji from a remote instance, and that emoji has a source listed, the administrator SHOULD be prompted to view the source before copying the emoji.

Again, of course an administrator can bypass all of this by simply right clicking, saving the image, and re-uploading it. However, implementing this suggestion makes it clear that when they do this, they are doing it potentially against the wishes of the emojis' creator. It avoids, through automated processes, giving their action the color of legitimacy and of official Mastodon approval.