For most practical purposes, it is — sort of. This is a complicated question, so please read on.
"Public domain" is a technical term in copyright law that refers to works not under copyright — either because they were never in copyright to begin with (for example, works authored by U.S. government employees, on government time and as part of their job, are automatically in the public domain), or because their copyright term has finally lapsed and they have "fallen into" the public domain.
Not all jurisdictions have a public domain, and it doesn't always mean exactly the same thing in the jurisdictions that do have it. Furthermore, even where it is clear what it means, it's still not a license. To be subject to a license, a work must still be in copyright. That means there is no way for the "public domain", as a concept, to go through the OSI evaluation and approval process. We wouldn't be evaluating a license text. Instead, we would have to somehow evaluate the laws themselves, in different jurisdictions, and say which jurisdictions have a public domain that meets the Open Source Definition and does not create problems for software authors and users. This would be very difficult, because it would mean evaluating not just the statutes but various bodies of case law (for example, open source licenses usually have a strong disclaimer of liability for the copyright holder — but we don't know how or whether the author would be protected from liability for software released into the public domain in various jurisdictions). This approach would not be useful to the OSI's mission, because open source is an international phenomenon and we only want to approve licenses that meet the Open Source Definition everywhere.
Thus we recommend that you always apply an approved Open Source license to software you are releasing, rather than try to waive copyright altogether. Using a clear, recognized Open Source license actually makes it easier for others to know that your software meets the Open Source Definition. It also enables the protection of attribution, and various other non-restrictive rights, that cannot be reliably enforced when there is no license.
There are certain circumstances, such as with U.S. government works as described above, where it is not easy to apply a license, and the software must be released into the public domain. In these cases, while it would be inaccurate to display the OSI logo or say that the license is OSI-approved (since there is no license), nevertheless we think it is accurate to say that such software is effectively open source, or open source for most practical purposes, even though it is not officially released under an open source license. (This is assuming, of course, that in the laws of releasing jurisdiction the meaning of "public domain" is compatible with the Open Source Definition.) After all, the freedoms guaranteed by open source licenses are still present, and it is possible for the familiar dynamics of open source collaboration to arise around the software.
For a detailed discussion of the complexities of the public domain and open source, search for the words "public domain" and "PD" in the subject headers of the January 2012, February 2012, and March 2012 archives of the OSI License Review mailing list. And if the thought of reading all those conversations is daunting, please take that as more evidence that it's just better to use an approved Open Source License if you can!
See also the CC0 question. For a different viewpoint than the one presented above, see unlicense.org.
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 .
To check whether papers have been received, look in . If you can’t look there directly, email@example.com 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 mentioned throughout this document is available on the general GNU server, currently . 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. You can also ask for accounts for people who significantly help you in working on the package. Such GNU login accounts include email (see https://www.fsf.org/about/systems/sending-mail-via-fencepost).
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 ?
Would you be willing to sign a copyright disclaimer to put this change in the public domain, so that we can install it in ?
If the contributor then wants more information, you can send per the file , 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 ; they are also available from the directory of the 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 . (Like all the ‘’ files, it is in and in .)
For medium to small changes, request a personal disclaimer by sending per the file .
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 .
When you send a 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 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 firstname.lastname@example.org 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 in the USA, Germany, or India 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. Contributors residing outside the USA, Germany or India must mail the signed form to the FSF via postal mail. 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 ‘’ and ‘’, 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 ; for larger ones, use . To cover both past and future changes to a manual, you can use . For a translation of a manual, use .
For translations of program strings (as used by GNU Gettext, for example; see Internationalization in GNU Coding Standards), use . 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 , , , and . 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.
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 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@example.com 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 firstname.lastname@example.org.
If you are not sure what to do, then please ask email@example.com 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 firstname.lastname@example.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 email@example.com, and we will work with a lawyer to decide what to do.