![[staff profile]](https://www.dreamwidth.org/img/silk/identity/user_staff.png){kind=small}
I posted a thread on Twitter about potential legal liabilities for United States people who decide to run a Mastodon instance, and the response made it clear there's a lot of people who could use the extended background. So here is a guide to potential liability pitfalls for people who are running a Mastodon instance, and how to mitigate them. This is mostly US-specific, but I noted which things to think about are likely to apply worldwide. This is not legal advice and you should contact a lawyer licensed in your jurisdiction for the exact details of the liability you're exposed to and a detailed risk assessment.
This is not about just creating a Mastodon account: it's for people who are running a Mastodon server. If you just made an account on someone else's server, you can safely ignore this.
Mastodon calls each specific server an "instance". My Twitter thread made it super clear that people, even people who are running instances, don't know what this means, so having used the Mastodon technical language in the intro, I will now shift to calling them "servers" from here on out. (In several places I am using more commonly understood terms rather than the correct technical terms.)
I'm only addressing legal/liability issues, not the practicality of running a service. Things like "make backups", "keep backups offsite/on a different network", "try restoring from backup occasionally to make sure they're working", "evaluate every release of every new package installed on the machine you're hosting on to weigh security fixes vs potential for your platform breaking", "lock down the machine you're hosting on to minimize network intrusions", "what kind of content moderation policies you should have for social other than legal purposes" etc, are all outside the scope of this document.
A very kind internet lawyer on Twitter provided a few posts that you may want to read for this, although the second was written in 2010 and doesn't cover some of the other stuff I'm going to get into:
* Copywrong Again: Founding the Next Pinterest or Napster?
* If You Build It, They Will Abuse It
( A guide to potential liability pitfalls for running a Mastodon server in the US )
This is not about just creating a Mastodon account: it's for people who are running a Mastodon server. If you just made an account on someone else's server, you can safely ignore this.
Mastodon calls each specific server an "instance". My Twitter thread made it super clear that people, even people who are running instances, don't know what this means, so having used the Mastodon technical language in the intro, I will now shift to calling them "servers" from here on out. (In several places I am using more commonly understood terms rather than the correct technical terms.)
I'm only addressing legal/liability issues, not the practicality of running a service. Things like "make backups", "keep backups offsite/on a different network", "try restoring from backup occasionally to make sure they're working", "evaluate every release of every new package installed on the machine you're hosting on to weigh security fixes vs potential for your platform breaking", "lock down the machine you're hosting on to minimize network intrusions", "what kind of content moderation policies you should have for social other than legal purposes" etc, are all outside the scope of this document.
A very kind internet lawyer on Twitter provided a few posts that you may want to read for this, although the second was written in 2010 and doesn't cover some of the other stuff I'm going to get into:
* Copywrong Again: Founding the Next Pinterest or Napster?
* If You Build It, They Will Abuse It
( A guide to potential liability pitfalls for running a Mastodon server in the US )
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}