6.1 Copyright Papers

If you maintain an FSF-copyrighted package, certain legal procedures are required when incorporating legally significant changes written by other people. This ensures that the FSF has the legal right to distribute the package, and the standing to defend its GPL-covered status in court if necessary.

GNU packages need not be FSF-copyrighted; this is up to the author(s), generally at the time the package is dubbed GNU. When copyright is assigned to the FSF, the FSF can act to stop GPL violations about the package. Otherwise, legal actions are up to the author(s). The rest of this section is about the case when a package is FSF-copyrighted.

Before incorporating significant changes, make sure that the person who wrote the changes has signed copyright papers and that the Free Software Foundation has received and signed them. We may also need an employer’s disclaimer from the person’s employer, which confirms that the work was not part of the person’s job and the employer makes no claim on it. However, a copy of the person’s employment contract, showing that the employer can’t claim any rights to this work, is often sufficient.

If the employer does claim the work was part of the person’s job, and there is no clear basis to say that claim is invalid, then we have to consider it valid. Then the person cannot assign copyright, but the employer can. Many companies have done this. Please ask the appropriate managers to contact [email protected].

To check whether papers have been received, look in /gd/gnuorg/copyright.list. If you can’t look there directly, [email protected] can check for you. Our clerk can also check for papers that are waiting to be entered and inform you when expected papers arrive.

The directory /gd/gnuorg mentioned throughout this document is available on the general GNU server, currently fencepost.gnu.org. If you are the maintainer of a GNU package, you should have an account there. If you don’t have one already, see https://www.gnu.org/software/README.accounts.html. Such GNU login accounts include email (see https://www.fsf.org/about/systems/sending-mail-via-fencepost).

You can request for accounts for people who significantly help you in working on the package; we will do this in special cases when there is a good reason.

In order for the contributor to know person should sign papers, you need to ask per for the necessary papers. If you don’t know per well, and you don’t know that person is used to our ways of handling copyright papers, then it might be a good idea to raise the subject with a message like this:

Would you be willing to assign the copyright to the Free Software Foundation, so that we could install it in package?

or

Would you be willing to sign a copyright disclaimer to put this change in the public domain, so that we can install it in package?

If the contributor then wants more information, you can send per the file /gd/gnuorg/conditions.text, which explains per options (assign vs. disclaim) and their consequences.

Once the conversation is under way and the contributor is ready for more details, you should send one of the templates that are found in the directory /gd/gnuorg/Copyright/; they are also available from the doc/Copyright/ directory of the gnulib project at https://savannah.gnu.org/projects/gnulib. This section explains which templates you should use in which circumstances. Please don’t use any of the templates except for those listed here, and please don’t change the wording.

Once the conversation is under way, you can send the contributor the precise wording and instructions by email. Before you do this, make sure to get the current version of the template you will use! We change these templates occasionally—don’t keep using an old version.

For large changes, ask the contributor for an assignment. Send per a copy of the file request-assign.changes. (Like all the ‘request-’ files, it is in /gd/gnuorg/Copyright and in gnulib.)

For medium to small changes, request a personal disclaimer by sending per the file request-disclaim.changes.

If the contributor is likely to keep making changes, person might want to sign an assignment for all per future changes to the program. So it is useful to offer per that alternative. If person wants to do it that way, send per the request-assign.future.

When you send a request- file, you don’t need to fill in anything before sending it. Just send the file verbatim to the contributor. The file gives per instructions for how to ask the FSF to mail per the papers to sign. The request- file also raises the issue of getting an employer’s disclaimer from the contributor’s employer.

When the contributor emails the form to the FSF, the FSF sends per an electronic (usually PDF) copy of the assignment. This, or whatever response is required, should happen within five business days of the initial request. If no reply from the FSF comes after that time, please send a reminder. If there is still no response after an additional week, please write to [email protected] about it.

After receiving the necessary form, the contributor needs to sign it. Contributors residing in the USA or Italy may use GPG in order to sign their assignment. Contributors located anywhere else can print, sign, and then email (or fax) a scanned copy back to the FSF. (Specific instructions for both cases are sent with the assignment form.) They may use postal mail, if they prefer. To emphasize, the necessary distinction is between residents and non-residents of these countries; citizenship does not matter.

For less common cases, we have template files you should send to the contributor. Be sure to fill in the name of the person and the name of the program in these templates, where it says ‘NAME OF PERSON’ and ‘NAME OF PROGRAM’, before sending; otherwise person might sign without noticing them, and the papers would be useless. Note that in some templates there is more than one place to put the name of the program or the name of the person; be sure to change all of them. All the templates raise the issue of an employer’s disclaimer as well.

You do not need to ask for separate papers for a manual that is distributed only in the software package it describes. But if we sometimes distribute the manual separately (for instance, if we publish it as a book), then we need separate legal papers for changes in the manual. For smaller changes, use disclaim.changes.manual; for larger ones, use assign.changes.manual. To cover both past and future changes to a manual, you can use assign.future.manual. For a translation of a manual, use assign.translation.manual.

For translations of program strings (as used by GNU Gettext, for example; see Internationalization in GNU Coding Standards), use disclaim.translation. If you make use of the Translation Project (https://translationproject.org) facilities, please check with the TP coordinators that they have sent the contributor the papers; if they haven’t, then you should send the papers. In any case, you should wait for the confirmation from the FSF that the signed papers have been received and accepted before integrating the new contributor’s material, as usual.

If a contributor is reluctant to sign an assignment for a large change, and is willing to sign a disclaimer instead, that is acceptable, so you should offer this alternative if it helps you reach agreement. We prefer an assignment for a larger change, so that we can enforce the GNU GPL for the new text, but a disclaimer is enough to let us use the text.

If you maintain a collection of programs, occasionally someone will contribute an entire separate program or manual that should be added to the collection. Then you can use the files request-assign.program, disclaim.program, assign.manual, and disclaim.manual. We very much prefer an assignment for a new separate program or manual, unless it is quite small, but a disclaimer is acceptable if the contributor insists on handling the matter that way.

When a copyright holder has signed an assignment for all future changes to the package, and contributes a change made up of new files which require no change to any of the old files, we want to avoid any uncertainty about whether these files are intended as a change to the package and thus covered by that assignment. The way to do this is to ask the contributor to say so in a message to you — for instance, “My modules ‘frog’ and ‘kangaroo’ are intended as changes to the program Hoppers.” Forward the message to [email protected], who will save it permanently. A variation on this procedure: the contributor who wrote the new files can send copies of the new files which contain such a message.

If a contributor wants the FSF to publish only a pseudonym, that is ok. The contributor should say this, and state the desired pseudonym, when answering the request- form. The actual legal papers will use the real name, but the FSF will publish only the pseudonym. When using one of the other forms, fill in the real name but ask the contributor to discuss the use of a pseudonym with [email protected] before sending back the signed form.

Although there are other templates besides the ones listed here, they are for special circumstances; please do not use them without getting advice from [email protected].

If you are not sure what to do, then please ask [email protected] for advice; if the contributor asks you questions about the meaning and consequences of the legal papers, and you don’t know the answers, you can forward them to [email protected] and we will answer.

Please do not try changing the wording of a template yourself. If you think a change is needed, please talk with [email protected], and we will work with a lawyer to decide what to do.