www.delorie.com/gnu/docs/GNU/maintain_6.html   search  
Buy GNU books!

Information For Maintainers of GNU Software

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

4.2 Copyright Papers

If you maintain an FSF-copyrighted package, then you should follow certain legal procedures when incorporating changes written by other people. This ensures that the FSF has the legal right to distribute the package, and the right to defend its free status in court if necessary.

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 a disclaimer from the person's employer.

To check whether papers have been received, look in `/gd/gnuorg/copyright.list'. If you can't look there directly, fsf-records@gnu.org 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' is found on the GNU machines; if you are the maintainer of a GNU package, you should have an account on them. Contact accounts@gnu.org if you don't have one. (You can also ask for accounts for people who help you a large amount in working on the package.)

In order for the contributor to know person should sign papers, you need to ask 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 program?


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

If the contributor wants more information, you can send per `/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 `/gd/gnuorg'. 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 `/gd/gnuorg/request-assign.changes'.

For medium to small changes, request a disclaimer by sending per the file `/gd/gnuorg/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 `/gd/gnuorg/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 a copyright disclaimer from the contributor's employer.

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 `/gd/gnuorg/disclaim.changes.manual'; for larger ones, use `/gd/gnuorg/assign.changes.manual'. To cover both past and future changes to a manual, you can use `/gd/gnuorg/assign.future.manual'. For a translation of a manual, use `/gd/gnuorg/assign.translate.manual'.

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.

Although there are other templates besides the ones listed here, they are for special circumstances; please do not use them without getting advice from assign@gnu.org.

If you are not sure what to do, then please ask assign@gnu.org 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 assign@gnu.org 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 assign@gnu.org, and we will work with a lawyer to decide what to do.

[ < ] [ > ]   [ << ] [ Up ] [ >> ]         [Top] [Contents] [Index] [ ? ]

  webmaster     delorie software   privacy  
  Copyright 2003   by The Free Software Foundation     Updated Jun 2003