Commons:Requests for comment/PD review

Previous discussion at:

• Commons:Deletion_requests/All_files_copyrighted_in_the_US_under_the_URAA
• Commons:Village_pump#Organizing_a_US_copyright_status_review

PD review

Background

1. This review is prompted by a recent (18 Jan 2012) US court decision which affirms the URAA, which restores copyright in the US on foreign works if that work was still copyrighted in the foreign source country on the URAA date (1 Jan 1996 for most countries). Before this was affirmed, many files were tagged {{Not-PD-US-URAA}}. Now that it has been, many or most of these files have had their US copyright definitely restored, and need to be reviewed for removal from Commons, since Commons:Licensing says Commons only hosts public domain (PD) works that are public domain in (at least) the US and the source country.
2. At the same, there are wider issues with PD tags not providing enough information on why a work is PD in both the US and the source country. These files should also be reviewed, information improved, and in some cases deleted (if Commons:Licensing is not satisfied).

This RFC aims to cover how best to proceed with these two closely related issues. Rd232 (talk) 14:58, 20 February 2012 (UTC)

Category-based review proposal

Per Commons:Licensing, all files on Wikimedia Commons must be in the public domain (PD) or released under a suitable free license in both their source country and the United States. For historical reasons, we have a very large number of files tagged either with only {{PD-US}} (which for non-U.S. works does not specify why the work is PD in its source country) or only {{PD-old}}, {{PD-old-70}}, etc. (which do not specify why the work is PD in the United States). The goal of PD review is to establish that all PD files on Commons are compliant with policy or else nominate them for deletion (speedy deletion would not be permitted, in light of the intricate nature of copyright status). Generally, this is done by either replacing the existing PD tag with a combined tag (such as {{PD-old-70-1923}}), or by adding a second PD tag.

The basic proposal:

• Files for review would be placed in the category Category:PD review needed by adding [[Category:PD review needed]] to their image description pages.
  • There is an enormous backlog of at least a million such files. Tagging them all for review would be disruptive. Instead, a bot will monitor the category, and if it begins to become empty, will add new files to the category for review automatically up to a maximum number (say 1000).
    • The bot will prioritise works created recently, because they're more likely to be non-policy-compliant.
    • Files outside the category may still be reviewed manually, and they will never be added to the category later. Files that have had been manually removed from the category will never automatically be re-added.
    • We will need a clear way to indicate works first published in the US, so that the bot knows that if they have a PD US tag, they require no further review.
    • It may also be desirable to automatically tag new PD uploads for review.

Other optional measures that would be helpful include the following:

• Adding optional fields for "Year of first publication" and "Country of first publication" to Template:Information (or to a new template such as Template:First published using Template:Infobar-Layout). Given this information and a creator template, a large number of existing images (mainly those which are {{PD-old-70-1923}} or older) could have the correct PD tag automatically applied by a bot. This would also solve the "indicating works first published in the US" problem above, and would be valuable for later use, such as determining the copyright status of the work in a third country of relevance to a content reuser.
• Somehow, it'd be nice if uploaders could be asked to give information about year/country of first publication and automatically add creator templates, where available.
• Your suggestions to be added here

Conservation of effort: My aim here is to make the minimum changes that accomplish the primary purpose of ensuring policy compliance of these works. I've opted to avoid any strategy that involves replacing tags on literally every single PD file's page, however desirable it might be, as the task as outlined above is already Herculean enough, and is sufficient to ensure policy compliance. Prioritizing recent files will also help reviewers avoid wasting time on the many files from the 1700s and earlier which may have been recently published but are probably just fine.

Preservation: Any deleted works that are PD in the US would be copied to local projects accepting works PD in the US. Any deleted works that are not PD in the US but PD in Canada would be copied to Wikilivres. Any deleted work not PD in the US and in use would be re-uploaded as a fair use candidate to local projects with Exemption Doctrine Policies that are using it.

Questions: If the reviewer is "pretty sure it was published before 1923" but is lacking evidence to that effect, what should the strategy be for dealing with them? This applies to many very old works of art for which the date of creation/exhibition may be known but not the date of first publication.

Suggestions, comments, concerns welcome. Dcoetzee (talk) 13:36, 5 February 2012 (UTC)

"[...]The proposed license tags are overly complicated (remember that uploaders even have problems to understand the meaning of "70 years pma" (which does not require more than 70 years after creation but after death) and nearly no-one will understand this system; especially if it uses some template parameters which need to be set. I saw the file pages you created in your last bot run (which you have reverted): much more than one screen page full of public domain (we are not talking of license templates with restrictions...) tags? Ugly and scaring away everybody who looks at (probably the reaction: they are crazy). --Saibo (Δ) 14:22, 5 February 2012 (UTC)" - this is a quote of the materially relevant comment from an exchange moved to the talk page. Rd232 (talk) 23:38, 29 February 2012 (UTC)

I like the idea of having a template containing the year of death, the year of publication and the country of origin since it would be easier for users to understand. This way, it would also be possible to present copyright information for most countries in the world in an easy way. I think that it would also be useful to list PD-old-YY templates for US works (whenever known) since it would help reusers in other countries. {{PD-US-no notice}} tells nothing about the copyright status in Mexico, Canada, Germany and other countries, so reusers in those countries might have to exclude all {{PD-US-no notice}} images altogether.

How would the bot determine what's the US tag? For example, {{PD-ineligible}} could be either a US tag (combined with {{PD-old-70}} for a British work), or it could be a foreign tag (combined with {{PD-1996}} for a German work). --Stefan4 (talk) 01:18, 10 February 2012 (UTC)

I hesitate slightly to have year of author death, since it may be redundant with creator templates - however it's easy enough to have the bot use the creator template when it's available, or else look for the year of author death field. You're quite right that PD-old-XX (when applicable) can also be valuable for US-published works for content reusers in nations that don't use the rule of the shorter term, so should definitely be considered. Arguably, tags like {{PD-ineligible}} should be split on the basis of country, since different countries have different thresholds of originality - however I think a reasonable interpretation for the base template is "this work is probably ineligible for copyright in both the US and source country" - any extra tags just remove all doubt in their respective regions. Dcoetzee (talk) 02:00, 10 February 2012 (UTC)

• Info we have Category:PD files for review. Trusted users can review the files by adding {{PDreview}}. --MGA73 (talk) 19:50, 18 February 2012 (UTC)

Internationalization

Can you list the templates which are affected by this and which templates you're introducing? I'm afraid the internationalization side of this isn't really properly taken into account. Multichill (talk) 14:31, 5 February 2012 (UTC)

Hi Multichill. The basic proposal does not introduce any templates. The optional extension would introduce fields for "Year of first publication" and "Country of first publication" to Template:Information (or to a new template such as Template:First published using Template:Infobar-Layout), which would only require internationalization of those two terms and nothing else. The {{PD-old-70-1923}}, etc. templates already exist and are in the process of being internationalized. Dcoetzee (talk) 15:00, 5 February 2012 (UTC)

{{PD-old-70-1923}} and friends were introduced less than a year ago. That's pretty new. Templates have less than 10 translations and it's all done localy per template. Conclusion: Internationalization sucks right now for these template. If we're going to do an overhaul of the system we should do internationalization properly from the start. So let's do that right away. As far as I can see we have three messages:

• This work is in the public domain in the United States because it was published before January 1, 1923.
• This work is also in the public domain in countries and areas where the copyright term is the author's life plus $1 years or less.
• The author died in $1, so this work is also in the public domain in countries and areas where the copyright term is the author's life plus $2 years or less.

I can enable these at Translatewiki so that we get much more translations. Multichill (talk) 15:38, 5 February 2012 (UTC)

I agree and that would be very helpful. For what it's worth, most of the translations of {{PD-old}}, {{PD-old-70}}, {{PD-old-80}}, etc. are also currently out-of-date, incorrectly stating that the work is in the public domain in the US. It would be very helpful if Translatewiki could assist in updating these as well. Dcoetzee (talk) 22:25, 5 February 2012 (UTC)

Against more Translatewiki - that moves control away from us to whatever translators and updates take ages. I even tried to register there once - couldn't change anything since I was not "approved" or similar. --Saibo (Δ) 00:00, 6 February 2012 (UTC)

I don't see Translatewiki as a problem. To me, fixing a Translatewiki translation is easier than fixing a translation in some Javascript file in the MediaWiki namespace on Commons. In this case, I think that it would be better than using the current system since the texts affect so many languages and since less common year variants of PD-old-YY and PD-old-YY-1923 tend to get very few translations. It would provide a useful way to get the whole set translated. --Stefan4 (talk) 01:04, 10 February 2012 (UTC)

Notification where used

I hope the projects where a file is used will get notified in time. Clear cases can be solved on Commons, where there is much expertise on the copyright side, but when information is lacking, those using the file might very well know something or be interested in doing research.

Being notified about a problem by CommonsDelinker is very frustrating. Going through Commons:Undeletion requests should be avoided where possible. On the other hand projects cannot be expected to check copyright status of all files used.

Above deleted images are suggested to be handled as "fair use candidates" on projects which allow fair use. That is not a solution for projects that do not allow unfree media, but being notified in time helps avoiding unnecessary deletions.

--LPfi (talk) 13:04, 20 February 2012 (UTC)

Agreed - maybe we can use a bot to construct lists of candidates that local projects can then look at? Especially for m:Non-free content projects that would be worthwhile, I think. Rd232 (talk) 13:26, 20 February 2012 (UTC)

There is a bot on English Wikipedia which posts a notice to talk pages of articles containing images proposed for deletion on Commons. It would be practical to have this on all projects since users may be watching the talk pages. --Stefan4 (talk) 13:36, 20 February 2012 (UTC)

Yes. I asked the bot owner about that a while ago. It would be worth asking again now. Rd232 (talk) 13:59, 20 February 2012 (UTC)

Deadline for resolving URAA issues

I think we should set a deadline for resolving all outstanding {{Not-PD-US-URAA}} issues. I suggest that we agree a deadline, and anything left tagged at that point speedy-deleted. I suggest that maybe 31 December 2012 could be a deadline: that's over 9 months to get this issue completely resolved, that ought to be enough. If we don't set a deadline, I think there's a risk this becomes just another backlog, hanging around indefinitely, once this RFC is over and attention fades. Because of the way {{Not-PD-US-URAA}}-tagging was supposed to be temporary pending legal decisions, I think that would be wrong. Rd232 (talk) 13:26, 20 February 2012 (UTC)

Agreed. If there are still Not-PD-US-URAA images left at the end of the year, let's tag the remaining images as "no permission" with a notice on the uploaders' talk pages, unless there is an ongoing deletion discussion. That gives the uploaders an extra week to fix anything obviously incorrectly tagged files. Is it time to start requesting deletion of Not-PD-US-URAA files or are we waiting for something before starting the deletion requests? --Stefan4 (talk) 13:39, 20 February 2012 (UTC)

Well, I was hoping we might find some ways to make the process more efficient, by using bots to find similar files, and/or bring files to the attention of users or projects with particular interests. I'd be tempted to leave manually going through the fileset one-by-one for a bit later in the year, if there's any risk of automated processes helping things. Rd232 (talk) 13:53, 20 February 2012 (UTC)

I'm just hoping that people will record the year of first publication when proposing deletion so that undeletion categories can be listed. --Stefan4 (talk) 14:07, 20 February 2012 (UTC)

Interesting way to fight backlogs -- simply delete files outright. Strongly oppose to this proposal. Trycatch (talk) 13:49, 20 February 2012 (UTC)

The proposal is for a deadline, and for a deadline to mean anything, it needs consequences. Deletion of any unprocessed files is the obvious one here. Do you want to propose less obvious ones? Say, if come deadline day unprocessed files remain, new uploads to Commons are blocked until the problem is gone? Well that's not going to happen, I'm just illustrating that feasible alternatives to deletion, as a consequence to attach to the deadline, are hard to come by. The best thing is to set a really achievable deadline. 31 December 2012 too soon? Fine, how about 31 December 2013? Or are you really willing to allow such files to exist on Commons indefinitely? Rd232 (talk) 13:57, 20 February 2012 (UTC)

The files are not allowed on Commons, so they need to be deleted. If files are on Commons without any source of permission from the copyright holder, the normal thing would be to tag them for no permission, and that's what I think would be the natural thing to do after the deadline. If new {{Not-PD-US-URAA}} files are uploaded, it may be practical to tag them as no permission directly upon upload without waiting for the deadline. This also prevents damage caused by the images being used on other projects for a long time prior to deletion. --Stefan4 (talk) 14:07, 20 February 2012 (UTC)

new {{Not-PD-US-URAA}} should not be allowed. But I'm not best sure how to achieve that. Add a parameter to the template requiring a tagging date, and have a bot go and fill it in? Then if the parameter isn't filled (or the date is more recent than some cutoff date), the template can show an error. Rd232 (talk) 14:19, 20 February 2012 (UTC)

Yes, that sounds good: if there is no or a too recent date, {{Not-PD-US-URAA}} could include the {{Copyvio}} template. I have lately tagged some images on Commons as {{Not-PD-US-URAA}} because the tag was missing - should I report them for deletion instead? --Stefan4 (talk) 14:25, 20 February 2012 (UTC)

If they're recent uploads, definitely. If not, it would probably be helpful to tag them, at least for the time being whilst doing some automated processing/notification is a possibility. Rd232 (talk) 14:39, 20 February 2012 (UTC)

I think setting a deadline now is premature. We do not know how many files we are talking about (unless we restrict discussion to files already correctly tagged) and we might find large batches later. Having an absolute deadline might mean deleting files more or less randomly at the end (the dead line was not about files without permission - files lacking permission are deleted at sight or in a week already - but about files lacking the right templates, which the uploader might not have been told about).

What we could do is make a timetable for what has to be done. And we can set a dead line on any single well understood step. As long as the process goes on at reasonable speed I think we are all right.

--LPfi (talk) 10:17, 21 February 2012 (UTC)

I agree. Keep in mind, many of these files will be ambiguous cases that require extensive deletion request discussions. The large majority of Not-PD-US-URAA images have not yet been discovered. I think it's more realistic to target completing review of a certain number or files within a certain timeframe (like say, 200 each month, or something). Dcoetzee (talk) 10:22, 21 February 2012 (UTC)

Have we found out what should happen? Perhaps we should find out what to do first. When that is done we can find out how long it should take. Example:

1. Set up a project page to coordinate all this. That way we would have a place we can link to when we post notices on other wikis.
2. Inform Wikis:
   1. Inform all Wikis that the result of the discussion is that we can't keep the files. And add a link to the project page.
   2. Do a query of all the files used in each wiki and inform the wikis about the numbers of "their" files that may be deleted.
   3. Give all the wikis a deadline to decide if they can and will have the files copied to their wiki.
3. Whats the problem?
   1. Make a list of all templates that may be a problem.
   2. Make a list of all files that may be deleted (or at least a list of the number of files with each template).
4. Check files
   1. Agree on a method to get this working
   2. Update license pages etc. so we all have a better chance to figure out which files are ok and which files are not
   3. Start checking
      1. Mark as ok.
      2. Mark as NOT ok.
5. Files that is not ok
   1. Have a bot to mark file with no permission and inform uploader
   2. Have a bot inform local wikis where the file used
   3. If the wiki has opted in for "copy to wiki" then a bot copies the file to the wiki
   4. When file has been copied to local wiki (or if they do not want it) mark it with "ready for deletion"
   5. Delete when the 7 days have passed and uploader (or anyone else) have not provided a valid permission.
6. Everything I forgot above :-)

Things can most likely not be done in the order above and the list is not complete. Just an example. But I think it is important that wikis are informed. As you can see there is much that should be done. Unless we work fast or want to delete without checking we need a lot of time. --MGA73 (talk) 12:12, 21 February 2012 (UTC)

Setting up the project page, with information separated from discussion, should be a first step. When it is in decent condition all projects could be informed, but we cannot give any lists or numbers of files as we won't know that before at least halfway through the project.

The "list of templates that may be a problem" has to be done, but it is not that easy. Probably it has to be done the other way round, "list of templates that mean the file is ok", and the "list of templates that mean the file might be ok". The latter includes PD-old with variations, if we can assume the image was published early on (which is a strategic decision: there is no guarantee, but better leave it to later).

When we have reason to believe a big part of a certain batch of images have to be deleted we should inform wikis, authors and other interested parties. At that stage we might want to have internationalization of the project page, certain templates and the messages in order. We might want to ask for a dedicated page on each project so that we do not have to spam the village pumps.

One week is very much too little for the uploader to react. The uploader may be inactive and even very active editors may be away from Internet connections for a week. And when notified they have to start their research, possibly including physically visiting libraries or meeting people. We have no hurry in that stage, as waiting files consume no resources.

To "check" an image can mean either to manually check the needed template is missing or trying to guess where to find the author, year of death, year of publication etc. Sometimes the time when an image was taken is clear for those in the know, sometimes not. Often we have no idea about where to find those in the know. We should have some system of finding them for batches of images at the time, so files should be handled not only by PD-template but also by subject categories. And we should have people who know different parts of the world - maybe recruiting should be a priority quite early on.

I'd guess setting up the project and finding how to handle different categories will take most of the spring, and during (Northern Hemisphere) summer many people will be on vacation. Hopefully we are up to speed in the autumn.

--LPfi (talk) 14:29, 21 February 2012 (UTC)

I agree that one week is not long time. But if we know that the file is not free then we have to delete it at some point. In the example above my suggestion was that the file was first tagged for deletion when it has been checked by someone and found not ok.

We could have a bot send a notice to all uploaders once we have a list of files that is possibly not ok: "Hi. You have uploaded these files and as you may know xxx we will therefore need to check all the files. You can help us by xxx. Once a file have been checked it will either be marked as "ok" or if it is not ok you will recieve a notice asking you if you have (or want to try to get) a permission. If that is not the case the file will be deleted."

But perhaps we should take the discussion somewhere else. Perhaps on "the project page" :-) --MGA73 (talk) 15:52, 21 February 2012 (UTC)

I think this is one of the things we have to decide if we are going to have deadlines (and this sort of is the project page until we have a proper one). A week is too short a time for anything needing research or even getting a message. It is ok for new uploads, as we can suppose the uploader mostly is watching the file for a while and has the needed information available. A dead line of e.g. three months will only delay the project with three months, which is nothing (and we can use those three months for work with other files). But your suggestion about notifying uploaders before we start our own research about individual files in a batch of files lacking information is good. --LPfi (talk) 21:58, 21 February 2012 (UTC)

I agree that plenty of time is needed for users to respond after notification; 3 months seems OK. I still think we should have at least a target of finishing everything, and then if we miss the target we'll at least be able to judge if we need to do something different. And 31 December 2012 seems a good target to me. Rd232 (talk) 23:43, 29 February 2012 (UTC)

URAA Wikiproject

If discussion is drifting now, maybe we should start thinking about what to do next. I think we'll need a WikiProject so that we have somewhere to point people to; and we'll need to get at least brief translations of the issue. Then we can start building the list of templates and notifications. What's confusing me a bit though is how to link this with the parallel effort to improve clarity of PD status more generally. Maybe we should just get started with the URAA review project (Commons:WikiProject URAA review/COM:URAA?), and leave the RFC open to discuss the wider issues. Any broader PD-template conclusions here can feed into the project later, I think, since the first stage is analysis and notification. Rd232 (talk) 23:34, 29 February 2012 (UTC)

Template:PD-in

The new template {{PD-in}}

Is this work in the public domain in my country?

Asia China Not public domain until 50 years after author's death India Not public domain until 60 years after author's death Iran Not public domain until 50 years after author's death Iraq Not public domain until 50 years after author's death Israel Not public domain until 70 years after author's death Japan Not public domain until 50 years after author's death Pakistan Not public domain until 50 years after author's death Philippines Not public domain until 50 years after author's death Taiwan Not public domain until 50 years after author's death Vietnam Not public domain until 50 years after author's death Europe European Union, all countries, unless listed below Not public domain until 70 years after author's death Albania Not public domain until 70 years after author's death Andorra Not public domain until 70 years after author's death Russia Not public domain until 70 years after author's death Switzerland Not public domain until 70 years after author's death Turkey Not public domain until 70 years after author's death North America Canada Not public domain until 50 years after author's death United States of America Not public domain until 70 years after author's death Oceania Australia Not public domain until 70 years after author's death New Zealand Not public domain until 50 years after author's death South America Argentina Not public domain until 70 years after author's death Chile Not public domain until 50 years after author's death Peru Not public domain until 70 years after author's death Venezuela Not public domain until 60 years after author's death

was raised at Commons:Village_pump/Archive/2012/02#New_template_for_printout_copyright_information_for_all_countries. How does this fit in here? And can it be converted to a system like Javascript? Rd232 (talk) 23:48, 29 February 2012 (UTC)