The Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA) and the GNU Free Documentation License (GFDL), which Wikipedia uses to license all of its content, both have provisions requiring that the attribution history of an article be preserved. CC BY-SA, section 3(a), states that:

You must... retain... identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner requested by the Licensor (including by pseudonym if designated)

The GFDL, section 4-I, states that:

... you must ... Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page.

These licensing terms require that when one article is merged into another, either the history of the merged text must be preserved, or the authors' names must be recorded for attribution. At Wikipedia:Articles for deletion, when an editor wishes for an article to be merged to another article but does not regard the article's title as a useful redirect, the editor sometimes suggests something like, "Merge and delete". The objection is then frequently made that such an action is not possible under the licensing requirements. This may not be strictly true since attribution of authorship can be maintained in other ways, but it is troublesome and so a merge and delete is not usually done unless there is a specific and pressing problem with the redirect.

Redirects are cheap, however, and unless the article title is confusing or objectionable, it may be preferable just to leave it as a redirect to the merge target, in which case the usual interpretation of the licensing requirements requires only that the edit summary about the merge states the name of the article from which the merged information is derived.

Unless there is a particular reason to delete a redirect, admins should feel free to interpret "Merge and delete" votes as "Merge." A new editor may make such a vote without understanding the licensing requirements; this can be safely read as a merge vote. An advanced editor who wishes to argue for a merge and delete should make clear why the redirect would be unacceptable.

What can 'merge and delete' look like?[edit]

On the rare occasion that the article title is not suitable as a redirect, there are several options:

Rename to another title and redirect

Shortcut

The best option is to simply rename the page with the unsuitable title. If the to-be-merged article's title is not suitable as a redirect, it could be renamed to another title that is suitable for a redirect. In this way the article's history is maintained just like a normal merge and the old redirect will be left with no history and can be deleted.

Move to subpage of talk page

The merged article is moved into, for example, a subpage of the target article's talk page, and then linked to permanently from the main italk page. If the merged article is moved, the history can be accessed in the same way as any other page. This may be necessary if the title of the merged article is confusing or objectionable enough to make it an exceptionally poor redirect, although in such cases deletion often results.

When the talk page gets archived, a link to the subpage must be maintained so that attribution is not lost. It is questionable if attribution is ever properly achieved since there is no link from either the article or its history to the attribution history. Therefore, this approach is almost never used on Wikipedia at present.

Paste history to talk subpage

The text of the merged article history can be copied onto a subpage, and linked. The list that results must often be edited for coherence. This approach does not have favor among Wikipedia administrators at this time.

History fixing

An administrator merges the article history into the merge target along with the content. This action is done by moving the merged article over the target article, which automatically causes the target to be deleted, and then undeleting the history of the target article. Another edit usually needs to be made to make sure the correct version is displayed. See Wikipedia:How to fix cut-and-paste moves for more information. Ensure that deletion log and edit summaries make clear what you are doing, as there should be a record of the merge itself.

This technique is normally only used on Wikipedia for repairing cut-and-paste moves where the history of an article has become accidentally fragmented across several titles.

Note that this procedure can get complicated; you should not attempt it unless you feel confident that you know what you're doing. Also note that it may misrepresent an editor's intention at the boundaries between article histories, and thus should only be used in a situation in which two articles are essentially identical, such as a cut-and-paste move in which both articles have continued to develop since the move.

Nevertheless, it is not normally necessary to leave the source of the merge deleted. It is more usual simply to redirect it to the merge target.

Record authorship and delete history

In 2009, Wikipedia changed from the GFDL license to the Creative Commons Attribution-ShareAlike License. One significant difference is that history preservation is no longer strictly required, so long as all of the article authors are included. If there are only a few authors, their linked usernames can be included in the edit summary documenting the merge. If there are more authors, a list on the talk page or a subpage may be appropriate, with that list clearly marked to indicate that it must remain permanently. Though this method is legally acceptable, however, it is not preferred, since histories are used to track editor contributions in addition to attribution.

Delete and redirect[edit]

A vote for delete and recreate as redirect is unrelated, and presents no problems under the licensing requirements. As long as no content is merged, the old article can be safely deleted and a redirect created in its place.

See also[edit]

Case study
Categories