Notices by Sarah Jamie Lewis (sarahjamielewis@mastodon.social)

@feld strictly no, there is an inherent processing right ascribed in sending a post to a remote service - (and for the behaviour, the "post visibility" / to /cc fields already cover closely equivalent semantic meaning.

(also important: the idea related solely to distribution, and potentially transformation, rights; not to the full gamut of terms that might apply; and such a field is designed to strictly limit the liability of instance admins - which is the fundamental topic of discussion)

The more conversations I have, the more convinced I am that if larger actors in the fediverse wish to move from an implicit licensing to an explicit one; the only sound strategy is for all accounts to communicate licenses on a per-note/activity basis.

It would sidestep many (but not all) annoying legal questions like "if you author a public post, and send it to a remote server, are you considered a "user" on that server for the purposes of licensing of public posts for wider distribution"

Just because you use a middle-party (your local instance) to send a post to a remote instance it does not automatically exclude you from being bound to the terms of the remote service - especially if you have been notified of the terms.

If is arguable that follower-only posts and tights scopes are much more limited in how they can be bound to ToS conditions than public posts (as they are email-like)

(tl;dr if you wanna make things legally explicit, the fediverse becomes legally complicated)

To be clear, in the case of remote parties mastodon instances sometimes act like email servers (distributing private content to defined parties) and sometime act like public noticeboards/social media sites (when remote public posts get boosted / end up in "trending" etc.)

These two cases are distinct enough that they both technically and legally have different considerations when it comes to how content is treated and the expectations users have.

Do I think it's a good use of energy to append a "licensing" field to every activitypub json object in existence?

No, adding more bloat to more json to the world will always make me a little sad (and see also: https://mastodon.social/@mcc/114711054937026982)

But it would have some nice properties, for some definitions of nice and other definition of properties e.g. allowing tighter user control over transformation, and possibly some additional weight in tackling non-consensual distribution.

And as a general response to "this has always been our policy, and we are just putting it into words" because that is a favourite of 2025.

Words mean things, when the words you write on legal agreements are overly broad, they assert overly broad rights and restrictions.

Also...you're missing "transform" and "modify" in the rights you actually do need to assert. When I publish content to a mastodon service via another instance you necessarily transform it...

"You may not, without our prior written permission, scrape the Instance or incorporate into another website or other service any of our material, content or intellectual property, unless you are otherwise permitted by us to do so in accordance with a license or subject to separate terms."

This also seems like a very badly thought out term that requires all mastodon instance admins to make explicit agreements with each other in order for mastodon to function at all...

In Summary:

- if you federate with mastodon.social. after June 30th, you, and by extension users on your instance, now seem to have an explicit IP assignment agreement with mastodon.social - this has consequences...

- if you federate with mastodon.social. after June 30th, you will also likely be violating some aspect of mastodon.social's terms of service; unless you have an explicit written agreement on how to distribute content originating from that service - this has consequences...

There is no technical difference between an activity pub peer instance, and a "LLM scraper" or a "archival service"; only a moral one.

We could move to a world where all instance relationships have to be explicitly approved and opt-in; and there are indeed server networks that are that.

But that is a very different kind of fediverse and should be given informed consideration, not haphazardly constructed through inconsistent application of broad terms.

As a reminder, in order to verify content from an activity pub instance it is required to make several automated requests to various service endpoints in order to "scrape" content - and instances tend to like displaying some of the received information on their own instance for many different purposes.

Presumably all mastodon instances may have some kind of implicit prior written permission as part of the default terms...but activity pub is a very loosely defined protocol by design...

Legal Question: If I have an activity pub instance, and someone on a mastodon instance operating under the new terms of service follows an account on that instance - to what extent does my instance become a "user" of the mastodon instance.

- Arguably user profile info is out of scope, as such content is explicitly requested by the mastodon instance.

However, a "Create" request is submission of content, it is generally posted *to* a server, for the purposes of mirroring content on that server.

Because as an instance, the only tool you have to reject such ToS is to refuse to federate to instances that adopt the ToS (which you are prohibited from automatically discovering btw...)

(and because it will be default, you should probably default approximate it to all mastodon instances post some time period unless explicitly checked out)

This is an untenable position and goes against the values inherent to the fediverse.

As far as I can tell not only does the new Mastodon ToS apply to activity pub flows, it also heavily restricts the kinds of activity pub flows permitted by Mastodon instances that adopt the ToS, and also restricts what can be done with the results of those flows; while also claiming disproportionate rights to any content submitted to the service (i.e. we can use your content, you can't use ours).

Unless the ToS is more tightly scoped, this has very broad implications for the fediverse at large.

Further thoughts on this, now that I have drank some coffee, and read my emails where this ToS has more context:

"Use, launch, develop, or distribute any automated system....to access the Instance, except in each case as may be the result of standard search engine or Internet browser and local caching or for human review and interaction with Content on the Instance"

I presume "local caching" is there to cover *some* activity pub functions...but umm....this is way too general a restriction.

Activity pub could have been designed such that the content of a create activity had to be explicitly fetched by the target instance, but it wasn't.

That protocol works in a world where reserved-IP rights apply. It does not work in a world where federated instances want to start claiming explicit perpetual licenses over any content submitted.

Either the ToS should be explicitly scoped to web interfaces, or there need to be protocol extensions so instances can describe IP-fallout.

This might be a very long shot, but I'm attempting to track down a song/mix the only thing I definitively remember about it is that it contains lyric or maybe quoted audio that approximates:

"as soon as you start making art for someone else, you're fucked"

I cannot remember if it's a good song, it might not even be a song - if it is a song it's possible it's adjacent to synthwave in genre. It might also be a break in a larger mix.

Anyone have any idea where this might have come from?

@Gargron Thanks for taking a look, and yes there was indeed an issue with the formatting ( https://mastodon.social/@sarahjamielewis/114644834546639642)

Mastodon/Activity Pub question:

As far as I can tell mastodon posts are expected to have a rich text / html-subset representation i.e. https://docs.joinmastodon.org/spec/activitypub/#sanitization)

I'm writing a tiny activity pub service, mastodon is currently stripping out all html tags when displaying posts from my dev account (see e.g. https://mastodon.social/@sarah@tap.resistant.tech/114643976114333084), plain text posts work fine (see e.g. https://mastodon.social/@sarah@tap.resistant.tech/114643533179472725)

I'm attempting to work out why that is the case, but this is proving to be a hard thing to search for.

I have officially ran out of ideas...probably time to take a break....

Request: If anyone who knows anything about mastodon internals has any idea why plain text messages would show fine, but basic html formatted messages would show empty (see above) - I would greatly appreciate any insight.

What we have learned so far:

- taking the json my service produces and mirroring on another AP service results in mastodon rendering the HTML on the mirrored post - so it unlikely to be an issue with the Note object at least...

- just in case, I've tweaked a couple of things in webfinger, nodeinfo, and http header signing to better align the behaviour that mastodon is has, to no effect.