fyi, fsf machine use policy

[Ian Kelling]

This was something we are mainly using for new projects.

# FSF Machine Usage Guidelines

This document describes the policies for volunteers using servers owned
by the Free Software Foundation.

Version 1.1

changelog
1.1: change freenode to libera.chat
1.0: initial version

This policy is not meant to be exhaustive and to cover every
situation. Use your best judgment and ask the FSF sysadmins on IRC in
\#fsfsys on libera.chat or email <sysadmin@fsf.org> if you have any
questions.

## Introduction:

There are FSF -owned and -hosted machines where volunteers have
privileged access and often do the vast majority of administration.

Each machine has a dedicated purpose for furthering the cause of free
software, such as running bug trackers for free software projects or
hosting information about free software.

Multiple machines with the same volunteers and same overall purpose
may be called a project or a cluster, but this document refers to them
as a single machine.

For each machine, there is a version control repository called the
system info repo which contains a description of the machine's purpose
and a list of volunteers.

## Volunteer information:

A volunteer is someone who has privileged access to a
machine. Privileged access is defined on a per machine basis. In
coordination with volunteers, the FSF approves a written definition of
privileged access and records it in the system info repository. Every
volunteer must be listed in the system repo info before getting
privileged access. Privileged access must never be transferred or shared
to third parties, it is for the named volunteer only.

Volunteers for a machine have read access to the system info
repository. FSF may decide to give write access to some of the
volunteers for a machine so they may edit the volunteer list and any
information the FSF does not need to approve. Anyone who adds or removes a
volunteer must inform the FSF sysadmins and the existing volunteers. Any
volunteer who no longer intends to do volunteer work on a machine must
inform the FSF sysadmins or otherwise get their name removed.

Volunteer contact information that must be recorded in the system info
repo includes:

* Full name.
* An email address that does not deliver via FSF or GNU.
* Postal mailing address.
* Phone number.
* GPG key fingerprint.

If the FSF attempts to contact a volunteer and does not hear back in
response to 3 emails and a phone call over a period of 6 weeks with no
indication they are in the midst of a vacation or otherwise indisposed
over the majority of that time, FSF may revoke that volunteer's
access. If a volunteer run machines loses all its volunteers, FSF may
decommission the machine.

## Machine purpose and acceptable uses:

In coordination with volunteers, the FSF approves a written description
of the current purpose for each machine and records that in the system
info repository.

Volunteers must limit the functionality of FSF-hosted servers to their
designated purpose. CPU use, disk space, disk IO and network bandwidth
are limited shared resources on our servers. Providing them costs money,
and their use impacts the functioning of other virtual machines
and physical servers. There are no precise limits, so using Emacs to
write an email is ok, but using the machine to store or serve backups of
your personal photos is not.

If for whatever reason a machine is significantly used for a purpose not
clearly part of the machine's written purpose, any volunteer who is
aware of this must inform the FSF sysadmins, who will then coordinate
with the volunteers to prevent this usage or adjust the machine purpose
description to include it.

### Notable prohibitions:

* Use or distribution of nonfree software.
* Spamming or any unsolicited bulk email.
* Any malicious or illegal purpose.
* By any willful, deliberate, reckless, or unlawful act: interference with
  the work of another user or jeopardizing the integrity of data
  networks, computing equipment, systems programs, or other stored
  information.
* Network testing which can commonly be classified as malicious (port
  scanning, ddos simulation, etc), even if the involved machines are all
  allowing it. This can trigger automatic measures that prevent proper
  functioning of the network.

### Response to policy violations:

The FSF will determine whether any violation of these rules is minor
or major.

A major violation will lead to the volunteer's access being revoked
and could possibly also lead to loss of access to other GNU and FSF
services.

A minor violation consists of a warning. The offender must, within 7
business days, in an email to sysadmin@gnu.org, acknowledge the warning
and commit to the FSF that it will not happen again. Repeated minor
violations or nonresponse to warnings can be considered major
violations.

## FSF sysadmin responsibilities:

FSF sysadmins will make an effort to keep systems up and running but
give no guarantees. The FSF sysadmins may edit any files on any machine
for various reasons, for example to keep the machine working properly or
to reallocate resources urgently needed elsewhere. The FSF sysadmins may
add firewall rules or turn off the machine at any time due to security
threats or misbehavior of the machine. They will endeavor to keep
volunteers informed as best they can, and give prior warning whenever
possible.

## Security:

Volunteers must follow best practices to ensure that the secrets
required to gain access to the machine remain secure. For example:
keeping your SSH key on a secure computer, protecting it with a
password, and replacing your SSH key with a new one if there was a
situation where its security was in doubt. **Volunteers must
immediately inform the FSF sysadmins of any suspected leak or
compromise of access secrets, or any other possible security issue.**