Commons:Village pump/Archive/2026/08

Question about PD status of a Czechoslovak photograph

Ukrainian National Union (1939)

Hi all. As part of a good article review about the Ukrainian National Union, I have to verify the public domain status of this photograph of a UNO election truck. The PD tag states, per Czechoslovak copyright law, that it should have come into the public domain 50 years after publication, however it does not provide evidence of its original publication; I tried searching around to see if I could find it, but wasn't able. It also doesn't provide an author, nor could I find one. I think it'd be a shame for the article to lose this image, as this is the only photograph of the UNO we have available on commons (the other images are all posters), so wanted to ask here if someone can help verify the PD status of this image. Thanks in advance. --Grnrchst (talk) 08:37, 4 August 2026 (UTC)

Hi, this kind of question is more appropriate in Commons:Village pump/Copyright. HyperAnd [talk] 01:32, 5 August 2026 (UTC)

Ach, thanks, moved it there. --Grnrchst (talk) 08:54, 5 August 2026 (UTC)

This section was archived on a request by: (discussion continues elsewhere) Jmabel ! talk 23:47, 5 August 2026 (UTC)

ESO astronomy pictures

Hey everyone, I want to know why the site doesn't allow to upload images from ESO Flickr account like for example https://www.flickr.com/photos/esoastronomy/55321043227/in/dateposted/ Abdullah1099 (talk) 05:03, 2 August 2026 (UTC)

@Abdullah1099 sure you can. Don't know about terms on Flickr, but you can upload images from the official website providing that you will provide proper attribution (state source and author). See: https://www.eso.org/public/about-eso/privacy/ Nux (talk··dyskusja) 09:52, 2 August 2026 (UTC)

Pasted wrong link :), this has copyright info: https://www.eso.org/public/copyright/ Nux (talk··dyskusja) 09:53, 2 August 2026 (UTC)

@Nux bro, I know that Images can be uploaded from ESO Website but what about ESO Flickr account. Also i want can request VRTS for a Template:Copyrighted free use images Abdullah1099 (talk) 13:42, 2 August 2026 (UTC)

coz User:Hedwig in Washington blacklisted it special:diff/370891134. see Commons_talk:Questionable_Flickr_images/Archive_5#c-BevinKacon-2019-08-26T19:00:00.000Z-ESO_Account. RoyZuo (talk) 18:28, 2 August 2026 (UTC)

I don't think this Flickr account should be blacklisted. Is there any way to remove it from blacklist Abdullah1099 (talk) 01:41, 3 August 2026 (UTC)

@Abdullah1099 please be asolutely sure that the files are not already on Commons before trying to import ESO pictures from Flickr. My bot systematically import all pictures from their website in quasi real time so there is a huge probability that you will import a duplicate if you import files from their Flickr account. vip (talk) 07:34, 3 August 2026 (UTC)

I know that @Don-vip, I just want to know why it is not allowed as in theory Flickr can also be used as source for ESO images by there official ESO Flickr account Abdullah1099 (talk) 07:39, 3 August 2026 (UTC)

@Abdullah1099 just find the files you want to upload on the official site. Flickr has lower quality images as is shown with examples under the link posted by Roy. Nux (talk··dyskusja) 09:10, 3 August 2026 (UTC)

Yeah @Nux, Thanks i know that and i am kind of ok with it Abdullah1099 (talk) 09:14, 3 August 2026 (UTC)

Personality rights for children in PD US DoD photographs?

Portrait of unnamed young teenager, c.30 years ago.

Portrait of unnamed child, perhaps 3 or 4 years old.

Looking at some mass uploads of DoD related photographs, and raising an album for possible out of scope duplicates, raises a secondary question I am unsure about and would welcome feedback, especially if a good consensus to refer to already exists!

The specific photograph is up for deletion, but the pdf of the album is not. Should we be concerned about photographs like this, which are not "historic" but within the last 30 years, are not outdoors or at obvious large public events but in this case might be at indoor gym training and where the subject would not have expected to give consent? Further the specific date and name of the photographer is not recorded, despite these being part of a military archive. There are other photos in this same album of younger people, ages probably about 2 to 6 years, where they could not possibly have consented or potentially understood they were being photographed and would later be published.

The related DR is here, please keep in mind that DR is on Scope grounds, not personality rights or copyright, and copies of all photos would remain on Commons, just the jpg duplicates are up for deletion not the pdf.

Note more generally, that in my own upload projects are a very large collection of DVIDs and DoD related photographs, I have no idea at this point how to identify which have detailed portraits of children, however the use of AI to help with subject identification and estimating age is making this possible for volunteers to work out and better retrospectively classify if this is a hosting problem for Commons. Fæ (talk) 14:16, 2 August 2026 (UTC)

In the example the subject looks at the camera. I would therefore assume that there was consent for publication. It is not something like a birthday party where the people might assume the photos to be used only within family and friends. GPSLeo (talk) 15:00, 2 August 2026 (UTC)

Given the age of these photos (I think they're substantially older than Fæ estimated), these children are probably in their 40s or 50s by now, if not older. Coupled with the fact that the photos will remain publicly accessible through DPLA / DVIDS, I wouldn't get too concerned about the personality rights issue. Omphalographer (talk) 15:57, 2 August 2026 (UTC)

The date at the source is given as "10/2/1994 - 1999". So the photographs in the album may be 27 to 32 years old^*. There's no estimation, these are the dates in the archive. I'll add a second image better to illustrate the younger models used. There issue is there cannot be consent at that age, further the archive has no record about consent or even a named photographer, despite this being recent enough to expect the models to still be living.

^*Recognizing some inconsistencies I'm doubting this analysis. Effectively these are like badly organized shoe boxes of holiday photos with years written on the label, however with so little information, like a named photographer or specific dates, there seems reason to distrust even these date ranges. If we are going to make assumptions about personality rights or similar, all the information needs to be taken as effectively absent. --Fæ (talk) 16:40, 2 August 2026 (UTC)

But they are definitely government works and therefore public domain? If they are that bad organized my main concern would be that DPLA does not have the rights to publish these files as public domain. GPSLeo (talk) 17:23, 2 August 2026 (UTC)

Keep in mind that on a military base, especially before the ramp-up of contractors in the 2000s, just about everyone likely to be around with a camera is a government employee. - Jmabel ! talk 00:58, 3 August 2026 (UTC)

This particular album has family accommodation, family events and portraits of families with children. There is no information on the archive record for who took these photographs, it could easily have been someone living on the base who was not a government employee but married to one. It is another assumption that the photographs were taken by the same person, given the unreliability of the dates which is the only consistent bit of information, but even that has been shown to be wrong. Fæ (talk) 06:12, 3 August 2026 (UTC)

Personality rights in the U.S. are very limited. Mostly, they have to do with not implying an endorsement of a product or company; some states have rules against certain kinds of deepfakes, but there is nothing at a federal level. As long as we are not talking about CSAM (and clearly in these examples we are not), I'm not aware of anything that makes a legal distinction for photographs of people who are underage, so unless someone's got something they can point to, any issue of this sort would be one of Commons policy, not one based in personality rights. - Jmabel ! talk 00:52, 3 August 2026 (UTC)

I thought Commons:Personality rights was a useful reference and does not limit Commons to only being concerned about extremes like CSAM. The statement "A child or a person judged incompetent by a court of competent jurisdiction should be considered with even greater care, as they probably cannot give valid consent even if they appear to." is relevant and is clearly how organizations like NSPCC define these situations, refer to the section on consent at https://learning.nspcc.org.uk/online-safety/photographing-filming-children. These photos may have been taken 30 to 50 years ago, but these same considerations apply if the sources we are harvesting have no records about consent, or who took the photograph, or the date, or the context. Everything being assumed is just that, assumptions in the absence of facts, which is not a good basis for judging if there has been appropriate consent from a child. Fæ (talk) 06:08, 3 August 2026 (UTC)

We can choose to have a more restrictive policy, but that is not a right, it's a courtesy. - Jmabel ! talk 22:55, 3 August 2026 (UTC)

Courtesy is fine. Nobody has mentioned rights. This is more about making the best ethical choice for potentially intrusive photographs of children and how we apply our understanding of the need for consent when photographs of potentially identifiable children are hosted. It seems appropriate to reconsider whether hosting close up photographs of children that have no realistic educational value, are not "historical", and are not of superior quality as portraits, is what Commons is for. Fæ (talk) 01:32, 4 August 2026 (UTC)

If the photo had first been posted by a random person, I might share the concern about consent, but presumably the DoD made such evaluations before posting. - Jmabel ! talk 00:56, 3 August 2026 (UTC)

@Jmabel: with Personality rights in the U.S. are very limited, you're certainly right, but only for scenes shot in the US, no? It's funny that this issue about personality rights came up again, as I opened Commons:Deletion requests/Files in Category:2 girls in Japan which includes File:Navy Misawa sailors participate in Career Day 140328-N-DP652-002.jpg and File:Brought together through music 130420-M-PZ610-505.jpg. Both are DoD images from a foreign base used by the US. I harbour the apprehension that US military photographers may operate only with US laws in mind, not regulations from abroad. Regards, Grand-Duc (talk) 07:04, 3 August 2026 (UTC)

I don't know in what degree Japanese civil law applies on a U.S. base in Japan. Do you have anything substantive on that? - Jmabel ! talk 23:01, 3 August 2026 (UTC)

I did some quick googling and found en:U.S.–Japan Status of Forces Agreement: Although the Japanese court system has jurisdiction for most crimes committed by American servicemembers in Japan, there are exceptions if the American was "acting in official duty," or if the victim was another American. In those cases the American system has jurisdiction, unless it is voluntarily waived.

That indicates that indeed US laws take precedence for military photographers, and your sentence "any issue of this sort would be one of Commons policy, not one based in personality rights." is all the more true: Commons:Photographs of identifiable people#Legal issues unmistakably states Commons requires photos to respect the legal rights of the subject in all of the following countries: (a) the country in which the photo was taken; (b) the country from which the photo was uploaded; (c) the United States (where Commons images are stored)., and military bases aren't embassies or the like, so definitively part of whichever country they are situated in, not some extraterritorial part of the country/countries using the base. It would have us follow the table in Commons:Photographs of identifiable people#Country specific... Regards, Grand-Duc (talk) 00:42, 4 August 2026 (UTC)

Proposal: Moratorium on the deletion of photographs from Ukraine

I propose an immediate moratorium on the deletion of freely licensed photographs taken in Ukraine when the sole or principal reason for deletion is the absence of a Commons-compatible freedom of panorama exception under Ukrainian law.

This proposal is not based on the mistaken assumption that deletion permanently destroys a file. Deleted files can be restored through processes such as Commons:Undeletion requests, including when the copyright in the depicted work eventually expires.

The problem is that restoration may only become legally possible seventy years after the death of the architect, sculptor or other author, as described at Commons:Copyright rules by territory/Ukraine.

In many cases, the author is unknown, their date of death cannot be established, or they are still alive. The photograph may consequently remain unavailable for a century or longer.

By then, the people who knew the place may be dead, communities may have been displaced, the subject may have been destroyed, and the social and historical context required to understand the image may have disappeared. A file preserved invisibly in a deletion archive is not serving education, research, public memory or cultural preservation.

Restoring an image after the history surrounding it has been forgotten is not meaningful preservation. It is preservation after relevance.

Destruction is taking place now

Ukraine is at war, and its cultural environment is being destroyed in real time.

As of 1 July 2026, UNESCO had verified damage to 540 cultural sites in Ukraine, including 154 religious sites, 280 buildings of historical or artistic interest, 41 museums, 33 monuments, 22 libraries, five archaeological sites and one archive.

The figures documented by the Ukrainian authorities are substantially higher. As of 25 November 2025, the Ministry of Culture of Ukraine had recorded 1,630 cultural heritage sites damaged or destroyed by Russia's aggression, including 36 sites that had been completely destroyed. It had also recorded damage to 2,437 cultural infrastructure facilities, 498 of which had been completely destroyed.

These totals are necessarily incomplete. Large parts of Ukraine remain occupied or inaccessible, making a comprehensive assessment impossible.

Photographs of buildings, monuments, public artworks, landscapes, cultural practices and community spaces may therefore become the only publicly accessible evidence that those subjects ever existed.

The proposal is to stop applying this restriction

This is not a proposal merely to interpret Ukrainian copyright law more carefully, delay deletion discussions for a few weeks or wait for legislative reform.

It is a proposal that Wikimedia Commons deliberately cease applying Ukrainian freedom-of-panorama restrictions to freely licensed photographs with substantial documentary, educational, cultural or historical value, even where Ukrainian law would otherwise be interpreted as requiring their removal.

The photographer must still be entitled to license the photograph itself. The exception would concern proprietary claims arising solely from the work, structure, monument or other subject depicted in that photograph.

This is a deliberate proposal for institutional non-compliance with an unjust and destructive restriction.

The law should not be treated as an absolute moral limit when its practical effect is to suppress historical evidence during the period in which that evidence remains socially relevant. A copyright rule intended to regulate the economic exploitation of a work should not be allowed to erase the public record of a place or cultural environment destroyed by war.

Where the original subject no longer exists, the supposed proprietary interest becomes particularly difficult to defend. Copyright cannot restore a destroyed building, monument or artwork. It cannot protect that object from further damage. In such cases, its principal practical effect may be to prevent the public from seeing and studying the surviving photographic record.

A person may possess copyright in the design of a structure. That should not include the power to impose public amnesia after the structure itself has ceased to exist.

There is no meaningful reason to preserve exclusive control over the representation of something that no longer exists while suppressing its educational and historical value for the communities that remember it.

Heritage must take priority

The relevant question should not be limited to:

Is this photograph fully compatible with Ukrainian freedom-of-panorama law?

The community should also ask:

Would deleting this photograph deprive the public of a significant record of something that has been destroyed, irreversibly altered, endangered or made inaccessible by war?

Where the answer is yes, the photograph should remain publicly available on Commons regardless of the Ukrainian restriction.

This principle should not be confined to conventional architectural monuments. Wikimedia must establish mechanisms for retaining records of:

• material heritage, including architecture, monuments, public artworks, archaeological sites, objects and community spaces;
• natural heritage, including landscapes, ecosystems and natural features destroyed or irreversibly altered by military activity;
• intangible heritage, including cultural practices, ceremonies, traditional knowledge, crafts and forms of community life whose continuity has been interrupted by war;
• places and practices that have become inaccessible because of occupation, displacement, contamination, destruction or military restrictions.

The historical importance of such records must take priority over proprietary restrictions where those restrictions would otherwise remove the material from public access for several generations.

Proposed measures

1. Establish an immediate moratorium on deletions of photographs from Ukraine where the sole or principal issue is the absence of commercially compatible freedom of panorama.
2. Suspend existing systematic deletion campaigns based on Ukrainian freedom-of-panorama restrictions.
3. Restore files previously deleted under that rationale where they have plausible documentary, educational, cultural or historical value.
4. Establish a permanent presumption in favour of retention for photographs depicting subjects that have been destroyed, irreversibly damaged, substantially altered or made inaccessible.
5. Establish a presumption in favour of retention whenever war creates a reasonable possibility that an image is, or may become, a unique historical record.
6. Create a preservation mechanism covering material, natural and intangible heritage rather than limiting consideration to officially recognised monuments.
7. Coordinate an effort involving the Wikimedia Foundation Legal team, Wikimedia Ukraine, Creative Commons, the Open Knowledge Foundation and other civil-society, cultural-heritage and digital-rights organisations to remove restrictions on freedom of panorama from Ukrainian law.

The legal-reform effort is necessary, but it must not be used as an excuse to continue deleting files while reform is pursued. Legislative change may take years or decades. Destruction and displacement are taking place now.

Property must not prevail over history

The Wikimedia movement must decide whether its purpose is merely to reproduce the most restrictive interpretation of national copyright law or to preserve and disseminate human knowledge.

Waiting until seventy years after an author's death is not a neutral compromise. It means withholding history until the people for whom that history matters are gone.

The slow process of forgetting will have already removed the names, memories, witnesses and cultural context that made the photograph meaningful. Returning the file after that process is complete does not repair the damage caused by excluding it when it was needed.

There is legal risk in refusing to enforce an unjust restriction. There is also a profound cultural and historical cost in continuing to enforce it.

Property must not prevail over history. No property right should include a right to erase public memory.

Discussion

• -- Rodrigo Tetsuo Argenton ^m 14:12, 1 August 2026 (UTC)

  But who is going to deal with all the potential copyright law suits that keeping such photos on Commons will lead to?

  The photos can be hosted on local Wiki projects under a fair use rationale, too. And, if I remember correctly, Ukraine does have freedom of panorama — just not one that allows for commercial use. So, in theory, one could upload such images to any website that hosts images with a "no commercial use" license. The problem is just that Commons doesn't allow such licenses. Nakonana (talk) 14:48, 1 August 2026 (UTC)

  The legal risk exists, but it appears to be low. We should acknowledge it without allowing a largely hypothetical possibility to become a permanent veto on preserving culturally and historically significant material.

  If a concrete claimant brings a case, that litigation could also create useful case law challenging these claims and clarifying the public’s right to document and share images of public spaces. An adverse decision is possible, as the Swedish case demonstrates, but avoiding every legal dispute guarantees that restrictive interpretations will never be tested.

  In my view, Wikimedia Sverige did not frame or pursue that case as effectively as it could have. I also still do not understand why the Wikimedia Foundation did not invest more in public advocacy around the case and use it to build pressure for legislative reform. Treating the judgment merely as a reason for greater caution allowed an absurd restriction on documenting public space to remain largely unchallenged.

  Moving these photographs to an external archive would not eliminate the legal issue. It would simply transfer the same risk to a smaller organisation with fewer resources to defend the public interest. -- Rodrigo Tetsuo Argenton ^m 22:34, 4 August 2026 (UTC)

  @Rodrigo.Argenton "The legal risk exists, but it appears to be low." Unlikely to be low as you suppose. Ukraine might be a "lite" version of France, in terms of perspective on commercial FoP. Page 23 of Freedom of Panorama: The EU Experience (by Anna Shtefan) mentions:

  The examples all concern the same work, a sculpture dedicated to the founders of Kyiv which was erected in 1982. In the second half of the 1990s and early 2000s, various individuals independently of each other began to use an image of this sculpture in their business operations. The image appeared in a bank's advertising, on the cover of a book of a non-educational nature, and on the packaging of some foods (several types of cheese and sausages). None of the users asked the permission of the rights holder to use the image of the work. All these cases went to trial and in each case the courts came to the conclusion that the author's rights were not respected.

Relevant casefiles (all in Ukrainian):

http://reyestr.court.gov.ua/Review/4611925 Case 22-5874 Joint-Stock Bank 'Ukrgasbank' v Vasyl' Boroday (2008)

http://reyestr.court.gov.ua/Review/5749072 Case 3/109/08 Vasyl' Boroday v Limited Liability Company 'FOLIO Publishing House' (2008)

http://reyestr.court.gov.ua/Review/8795295 Case 22-51 Open Joint Stock Company 'Molochnik' v Vasyl' Boroday (2009)

http://reyestr.court.gov.ua/Review/560241 Case 3/60/07 Vasyl' Boroday v Private enterprise 'VK and K' (2007)

Do note, though, that Boroday v. FOLIO concerned the said publishing house's usage of a photo of the Ukrainian heritage monument "Founders of Kyiv" as the cover of their "Explanatory Dictionary of the Ukrainian Language" (translated). Despite the publishers claiming that the work was educational in nature (which, IMO, really is), the court denied the argument. Being able to distribute the copies en masse in commercial outlets, the educational work is a commercial work. The court awarded Boroday's camp UAH 26,250 in copyright damage that the publisher was supposed to pay.

I can assume there are several more casefiles concerning commercial use or distributions of likenesses of Ukrainian monuments, but perhaps many of them are in Ukrainian. Do note that the aforementioned cases were during the time their law had no explicit FoP; they only added the restrictive panorama rule just before 2023.

There is also an implied strong protection on Ukrainian buildings. While the US law does not prohibit wanton destruction of buildings without permissions from building designers under Sec. 120(b) of Title 17 or the US Copyright Act, the Ukrainian law prohibits. The case on the aborted demolition of Kvity Ukrainy building, using copyright law as the basis to stop building demolition. Indeed, Ukraine is a "lite" version of protectionist France. JWilz12345 (Talk|Contributions) 16:20, 5 August 2026 (UTC)

• I have no opinion on the larger issue, but there are no copyright lawsuits, the offended party, or their representative, sends a takedown notice and the WMF comply. RAN (talk) 15:15, 1 August 2026 (UTC)

  What about commercial re-users? Nakonana (talk) 16:37, 1 August 2026 (UTC)

  The files are not physically deleted. When FOP laws change or the copyright of the derivative work expires, we can restore these files immediately. GPSLeo (talk) 16:51, 1 August 2026 (UTC)

  You did not read the intro of the proposal.

  "This proposal is not based on the mistaken assumption that deletion permanently destroys a file. Deleted files can be restored through processes such as Commons:Undeletion requests, including when the copyright in the depicted work eventually expires. The problem is that restoration may only become legally possible seventy years after the death of the architect, sculptor or other author [...] Restoring an image after the history surrounding it has been forgotten is not meaningful preservation. It is preservation after relevance."

  Please, do read at least the intro. -- Rodrigo Tetsuo Argenton ^m 22:07, 4 August 2026 (UTC)

  One (although not ideal) solution could be Commons:Upload, delete and undelete --PantheraLeo1359531 😺 (talk) 17:07, 1 August 2026 (UTC)

  It's particularly unsuitable for photos because we can't create organized collections of deleted files. Upload/delete/undelete is better suited to single files which are currently copyrighted, but which will become free in the near future, like books or films. Omphalographer (talk) 17:32, 1 August 2026 (UTC)

  that's why i advocate for rethink of commons' whole infrastructure special:permalink/1217401596#Reimagined_file_management_and_storage. RoyZuo (talk) 20:09, 2 August 2026 (UTC)

  + 1. Commons:Upload, delete and undelete it would the best solution now. Юрий Д.К. 18:03, 1 August 2026 (UTC)

• we dont follow copyright law just for the sake of it. Bawolff (talk) 17:01, 1 August 2026 (UTC)
•  Oppose. It is a central principle of Commons that files we host must be in the public domain or freely licensed; we cannot make exceptions simply because we disagree with those laws. Preserving these photos is a laudable goal, but it is not a project which is suitable for Commons. I would encourage you to set up an external project to archive these photos. Omphalographer (talk) 17:30, 1 August 2026 (UTC)

  This conflates copyright licensing with separate statutory restrictions on use. These photographs are freely licensed. The restriction on commercial use does not arise from their copyright licence, but from a separate legal prohibition.

  Commons’ own policy explicitly recognises that freely licensed or public-domain material may remain subject to non-copyright restrictions. Such restrictions do not alter the material’s copyright status and, unless they make hosting the files themselves unlawful, are generally a matter for reusers rather than grounds for deletion.

  We are therefore not asking Commons to make an exception to its free-licensing requirement or to disregard the law. -- Rodrigo Tetsuo Argenton ^m 22:20, 4 August 2026 (UTC)

  • The copyright in question is not the copyright of the photograph, it is the copyright of the building, for which we lack a license. Jmabel ! talk 23:36, 4 August 2026 (UTC)

  The lack of commercial FOP is precisely a copyright issue - building architecture can be copyrighted, and photographs of it are derivative works. There is a statutory exception to allow the non-commercial use of these photos, but this is insufficient for Commons. Omphalographer (talk) 08:36, 5 August 2026 (UTC)

• It's a real pain that Ukraine has non-commercial FOP. Ukraine is full of beautiful modern buildings and statues. But we can't just host photos of them here which will have "independent economic value". There was a proposal to allow non-commercial licenses on Commons to serve photos from noFOP countries, but unfortunately, I doubt it will be implemented. Yes, Commons is non-commercial, but external reckless re-users may use a photo for commercial purposes, thus violate copyright. And we've decided to protect these reckless re-users to our own detriment, sadly. Юрий Д.К. 18:21, 1 August 2026 (UTC)
•  Oppose By our charter from the WMF, Commons is not allowed to have an meta:Non-free_content#Exemption_Doctrine_Policy. Ukraine has a functioning government that could certainly change this law if they wanted to. - Jmabel ! talk 22:37, 1 August 2026 (UTC)

  “By our charter from the WMF” misunderstands the relationship between the Foundation and the Wikimedia community. The WMF does not grant the community a charter. It exists to support the Wikimedia movement, while the community shapes its strategic direction and mandate, including through movement strategy and the community and affiliate selection of trustees.

  Yes, Ukraine will stop to talk about copyright during a war. Makes total sense. -- Rodrigo Tetsuo Argenton ^m 22:15, 4 August 2026 (UTC)

  • WMF is in a position to say to Commons, "Don't do that, or we'll pull the plug." They are in a position to shut us down, boot off any individual, keep our existing content without keeping us, etc. We are not in a symmetric position, let alone one giving us more control of the situation than them. - Jmabel ! talk 23:40, 4 August 2026 (UTC)

• I'll note in my Unpopular Opinion Lightning Talk concerning allowing noncommercial licensing, I did bring up Ukraine as an example if we did accept non-commercial FoP. User:Doc James did also show me an interesting Metawiki page on noncommercial licensing. Abzeronow (talk) 03:58, 2 August 2026 (UTC)
•  Neutral I personally strongly support the idea of allowing non-commercial FOP restricted photos on Commons - neither Commons nor any of it's sister projects are in any way commercial, so the deletion of such images are not an inevitable legal necessity, but 100% our own choosing. In fact many "Commons No-FOP" countries actually have freedom of panorama exceptions - only for non-commercial and/or educational purposes, which we clearly are however. The problem is, as already mentioned, the WMF's definition of "free work" & only allowing those on Commons [1]. This would need to be changed first. ~TheImaCow (talk) 11:19, 2 August 2026 (UTC)

  Maybe we can create a place for very important NC files :) --PantheraLeo1359531 😺 (talk) 13:14, 2 August 2026 (UTC)

• Generally  Oppose, per the aforementioned licensing policy as enshrined by Wikimedia Foundation. Copyright still exists even in wartime. Do note that countries become more protectionist after the effects of war, as we have seen in the cases of wartime copyright extentions for French works made by poets, painters, sculptors, architects, composers, singer-songwriters, and other authors who died while defending the sovereignty of the country and safety of the French troops. "Somehow"  Support on the seventh proposed suggestion: "Coordinate an effort involving the Wikimedia Foundation Legal team, Wikimedia Ukraine, Creative Commons, the Open Knowledge Foundation and other civil-society, cultural-heritage and digital-rights organisations to remove restrictions on freedom of panorama from Ukrainian law." This would need a series of serious discussions (possibly face-to-face or in real time) between representatives of all involved parties. I'd add also the US-based Computer & Communications Industry Association, who took exception the non-consistency of FoP rules throughout the EU (see meta:Talk:Freedom of Panorama#CCIA comments on FoP in 2024). The pro-user stakeholders may need to prove how a commercial FoP in Ukraine, that does not impose restrictions on images with "independent economic value," would be advantageous for the cultural heritage of the country while at the same time not allowing the Kremlin to exploit online platforms like Wikimedia Commons to "destroy" the reputation of the Ukrainian heritage in any way. I have read an online article before that the Ukrainian parliament purposely followed the restrictive paths of France, Lithuania, and Romania instead of the more open paths of Germany and the Netherlands, likely due to the concern that Russian government officials could access and exploit Ukrainian monuments and buildings in a harmful way. I'll post here the online article as soon as I find it. JWilz12345 (Talk|Contributions) 04:22, 3 August 2026 (UTC)

  “enshrined by the Wikimedia Foundation”: this reflects a misunderstanding of the WMF’s role. We, the community, determine what the WMF supports and advocates for. -- Rodrigo Tetsuo Argenton ^m 22:09, 4 August 2026 (UTC)

Reminder https://nccommons.org exists as a sister project, specifically with a mission to provide a place for Non-Commercial images. If copyright law applies a NC restriction on this FOP, then any photos under deletion discussion can be copied there for later use or referencing. --Fæ (talk) 09:50, 2 August 2026 (UTC)

Thanks Fae :-) Yes please join us. Happy to give folks editing privileges. And maybe one day it will become a WMF hosted project. Doc James (talk · contribs · email) 20:06, 2 August 2026 (UTC)

•  Oppose: there are other websites for hosting non-commercially licensed images, such as archive.org, Flickr, or the aforementioned NC-Commons. Commons at its core is meant to allow commercial use. --– Howardcorn33 (💬) 16:35, 5 August 2026 (UTC)

  To be clear, what I am opposed to is making a policy carve-out or moratorium on Commons to address such photos. I have no objection against efforts to advocate a reform of the FOP law in Ukraine. – Howardcorn33 (💬) 16:41, 5 August 2026 (UTC)

1949 Clothing

• 
• 
• 

I am not an expert on clothing and fashion and could use some help in classifying clothes. I notice that all three have visible legs beneath the knees. I also find that the boy wearing a skirt is unsual. Smiley.toerist (talk) 10:28, 5 August 2026 (UTC)

Plus fours are below the knees. Though it's common enough for schoolboys to wear a kilt, this case looks like baggy shorts. Fæ (talk) 11:10, 5 August 2026 (UTC)

Security personnel at Wikimania 2026, Paris

Now in Commons:Deletion requests/Files in Category:Security personnel at Wikimania 2026, Paris. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:34, 5 August 2026 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Most if not all of the 48 images in Category:Security personnel at Wikimania 2026, Paris (taken and uploaded, I am sure, in good faith, by User:Nitesh Gill) don't seem to be in scope for Commons. They are "personal images", with little scope for reuse on any Wikimedia project.

I could not find a tool for, or a page about, bulk deletion nominations. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:04, 5 August 2026 (UTC)

@Pigsonthewing: I think you are looking for Help:VisualFileChange.js? – Howardcorn33 (💬) 16:49, 5 August 2026 (UTC)

Thank you. Does that put all the nominated files in one deletion discussion? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:51, 5 August 2026 (UTC)

Yes. If you would like I can nominate the files in that category for you to demonstrate. – Howardcorn33 (💬) 16:52, 5 August 2026 (UTC)

No, I've got it, thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:34, 5 August 2026 (UTC)

---

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Wikimania ISS video

Has the video made aboard the ISS, for the Wikimania 2026 opening ceremony, been uploaded to Commons, or will it be?

I can't find it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:07, 5 August 2026 (UTC)

There is this category Category:Sophie Adenot video at Wikimania 2026 opening ceremony, but it doesn't seem the actual video is in there. However, the video can be seen at the opening ceremony's full recording File:Wikimania 2026 – Opening Ceremony featuring Wikimedian of the Year.webm around 18m20s. Thanks. Tvpuppy (talk) 17:18, 5 August 2026 (UTC)

Thank you. I hope we can soon have the full, standalone video at high res.

Meanwhile at least we now have Category:Wikimedia aboard the International Space Station. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:51, 5 August 2026 (UTC)

There is also a better quality video on YT. Starts here as far as I can understand French ;) https://www.youtube.com/live/jcFHu20jtgI?si=VlUPZCRjrHkRUwiw&t=24524 Nux (talk··dyskusja) 20:39, 5 August 2026 (UTC)

See all my deletion requests

This section is resolved and can be archived. If you disagree, replace this template with your comment. ReneeWrites (talk) 19:07, 11 August 2026 (UTC)

Hi, is there any possibility to see every deletion request I have issued with my account? I currently keep track of it manually, but this is getting kind of annoying. Also, is there a possibility to get a notification when someone answers to a specific deletion request (without getting notifications for every edit on the whole deletion requests page)? Kind regards, Aciarium ⚒ (talk) 09:49, 6 August 2026 (UTC)

Put the deletion subpage on your watchlist and check your watchlist regularly.

(The part about subscribing to the whole deletion request page upon creating a deletion request is a bug.) Nakonana (talk) 10:48, 6 August 2026 (UTC)

It's not precisely what you're asking about, and I don't know of a way to filter these results further within Commons' interface, but this returns every page creation in the Commons space for your account, and if you filter (with CTRL+F for instance) for "N Commons:Deletion requests" it highlights all created deletion + mass deletion requests (of which there are 18 currently). ReneeWrites (talk) 12:35, 6 August 2026 (UTC)

Who can help to categorise the 60,000 media as of 2023?

So far, we have reduced the files in Category:All media needing categories as of 2023 from 95,000 to 60,000. Now we need more volunteers please, to reduce this number to zero. Who can help categorising the rest manually by going through the files one by one? Or can you make a suggestion, please, on how to do this more effectively, based on the guidance in Commons:WikiProject Minimum One Category? — Preceding unsigned comment added by NearEMPTiness (talk • contribs) 07:18, 31 July 2026 (UTC)

Still 56,000 media as of 2023 to be categorised. We need more volunteers or a better method, to clear the backlog, please. --NearEMPTiness (talk) 14:03, 4 August 2026 (UTC)

When you add a category, does a bot automatically remove it from the backlog? I tried a couple, but did not get the impression that would happen. Fæ (talk) 20:02, 5 August 2026 (UTC)

@Fæ: depends on how you add it. If you use a tool, that's going to depend on the tool. They don't all behave the same (some even pop up a choice). - Jmabel ! talk 23:45, 5 August 2026 (UTC)

I did it by hand and then a couple using VFC. Neither way seemed to automatically recognize the 'All media needing categories' category should be removed. This feels like a bot could regularly pull the recent changes and judge if a non-hidden category was added. We also have auto-removing categories if someone was hot for those sort of active templates (I don't Lua, I'm agnostic). Fæ (talk) 07:39, 6 August 2026 (UTC)

@Fæ: It is correct that neither of those to methods will do it automatically.

The problem with having a bot do it is that not every visible category really counts for this, and some intuition is still needed. For example, Category:New York City in the 2020s is probably not sufficient categorization to remove the tag. Ditto for Category:Unidentified buildings. - Jmabel ! talk 19:56, 6 August 2026 (UTC)

Should the commons logo be changed?

The wikipedia logo is easy to understand, an incomplete global library translated into many cultures where you can help put the pieces together, while the commons logo is harder to understand. Maybe the logo should be changed to a DVD (digital image library) with images on it and different languages??? idk, maybe the commons logo SHOULD remain the same Anonymsiy (talk) 10:32, 4 August 2026 (UTC)

I think it could be challenging to change a logo, after these many years. A logo means identity 🥺 --PantheraLeo1359531 😺 (talk) 11:06, 4 August 2026 (UTC)

well wikipedia's has much more of it! Anonymsiy (talk) 11:07, 4 August 2026 (UTC)

Logos are seldom superb, but if it is adequate, unproblematic, and in long use, there's generally no pressing need to change them. IMO that's the case here. So the answer to your question would be "no". (Though if you think you can create an amazingly splendid new logo and freely license it to Wikimedia, fell free to submit it for discussion.) -- Infrogmation of New Orleans (talk) 01:53, 5 August 2026 (UTC)

Category:Wikimedia Commons logo variants has some useful alternatives. The logo could evolve if there was a really popular new version, we would just run a consensus vote on it. "Should" is a harder question. Fæ (talk) 07:57, 5 August 2026 (UTC)

Thanks! also, are there any wikimedia projects without logos i could make one for? Anonymsiy (talk) 08:59, 5 August 2026 (UTC)

If you're good at making images, I'm sure COM:Graphic Lab could help with finding logo requests. Arlo James Barnes 07:28, 6 August 2026 (UTC)

I think it would be a waste of resources to go about the process of changing the logo. It's good enough as it is. – Howardcorn33 (💬) 16:48, 5 August 2026 (UTC)

Discussion on Saudi Arabia's new copyright law and new FoP rule

Kindly visit Commons:Village_pump/Copyright#New_Saudi_Arabia_copyright_act_-_an_update for the still-open discussion. Regards, JWilz12345 (Talk|Contributions) 00:38, 7 August 2026 (UTC)

Bad action by "Túrelio"

• Cold_District_heating,_schematic_function.svg&action=history
• Cold_District_heating,_schematic_function.svg&action=log
• de.wikipedia
• other file: page=File:Italy_1864_ca.svg&action=log

Taylor 49 (talk) 22:14, 5 August 2026 (UTC)

@Taylor 49: You are going to have to spell out what was "bad" here. I only looked at the first of four items in your list, but it seems reasonable. When a file is deleted as a duplicate, it is perfectly normal to redirect it to the file it duplicated. If that is not the reason for deletion, then the deletion log is misleading. - Jmabel ! talk 23:53, 5 August 2026 (UTC)

It seems unlikely that these SVGs (at least one of which was in use) were actually duplicates of the test SVG. Omphalographer (talk) 00:51, 6 August 2026 (UTC)

Ah, indeed. Looks like an error on Túrelio's part. You really could just have contacted him rather than bring it here, or at least pinged him, but Pinging @Túrelio, you probably want to look into this. - Jmabel ! talk 04:20, 6 August 2026 (UTC)

@User:Jmabel Sure: "Túrelio" deleted at least two files that were both INUSE and INSCOPE, apparently even without any discussion. There should not be any redirects to garbage File:Test.svg. Claiming that something is dupe of File:Test.svg is nonsense. Taylor 49 (talk) 01:08, 7 August 2026 (UTC)

@Taylor 49, why didn't you notify me directly on my talkpage?

Anyway, I've restored File:Cold District heating, schematic function.svg in order to be able to understand what happened back then (deletion was on May 10th!). As you can see from the version-history, the file had been tagged by OptimusPrimeBot as a duplicate of File:Test.svg, which was technically accurate at this time (Test.svg from May 9, 2026: [2]). My fault seems to be that I didn't check whether the Bot-edit/tagging made sense. Sorry for that.

Now for File:Italy 1864 ca.svg. That file had been tagged by its creator, User:Manlleus, for speedy deletion[3] on december 23, 2024, which I then performed on december 24, 2024.

Generally, FYI: files may be tagged as duplicate of an existing file by the system (MediaWiki) itself, by OptimusPrimeBot (and other Bots) or manually. Duplicate is a speedy-deletion rationale (F8) and does not require discussion. However, as of recently it seems that these Bots sometimes duplicate-tag files which aren't actually duplicates, but that is different issue than the one discussed here.--Túrelio (talk) 07:19, 7 August 2026 (UTC)

The problem is fixed now.

> been tagged by OptimusPrimeBot as a duplicate of "File:Test.svg", which was technically accurate at this time

YES but duplicates of "Test.*" obviously should be excluded from the process. And maybe there should be a harder policy against using "Test.*" in serious wiki pages.

> file had been tagged by its creator, User:Manlleus

Well then the deletion was justified, but not the redirect to "File:Test.svg".

Taylor 49 (talk) 10:34, 7 August 2026 (UTC)

Photo challenge June 2026 results

Bokeh: Entries • Votes • Scores

Rank	image	Title	Author	Score
#1		Domestic pigeon	NBlart23	11
#2		Gruppo di funghi della specie Mycena renati su un ceppo di faggio, in un bosco misto nell'area di Sorano (Toscana)	Albarubescens	8
#3		Greater Flamingo in the evening golden hours of Pulicat,Tamil Nadu	BKadhiravan	7

Street foods: Entries • Votes • Scores

Rank	image	Title	Author	Score
#1		Two men order from a falafel truck during a heavy snowstorm in New York City	Sashimi-b	15
#2		This is a delicious job!	Maryam Yazdanisheldareh	11
#3		Sweetfish skewers being grilled and sold in Ueno Park, Tokyo, Japan.	Ka23 13	8

Congratulations to @NBlart23, @Albarubescens, @BKadhiravan, @Sashimi-b, @Maryam Yazdanisheldareh and @Ka23 13. Sekidoki (aka Taiwania Justo) is speaking (Reception Room) 11:19, 8 August 2026 (UTC)

Janwikifoto, Daniel Aufgang

This section is resolved and can be archived. If you disagree, replace this template with your comment. ReneeWrites (talk) 06:29, 14 August 2026 (UTC)

I'm not at all sure this is the best place to ask this, but I can't think where else.

I happen to have run across File:P b b9dn631 0751.jpg, uploaded as "own work" by User:Janwikifoto, who stopped editing a few years ago for unknown reasons. In this edit, User:Photo Archives (later blocked as a sockpuppet, but someone the majority of whose edits seem to have been good), placed this in Category:Photography by Daniel Aufgang, a widely-traveled Flickr user. I would guess that this was simply a mistake, that Janwikifoto and Daniel Aufgang are two completely different people, and the category should be removed. Does anyone else know more? FWIW, User:Janwikifoto is a "verified account". - Jmabel ! talk 02:48, 13 August 2026 (UTC)

The caption 'blah blah blah for automated' suggests Janwikifoto was using automation to upload the photos; is it possible that the source was a Flickr post? Arlo James Barnes 18:04, 13 August 2026 (UTC)

@Jmabel: They're different people. Daniel Aufgang is Canadian, Janwikifoto is Swedish. I noticed a few more files in the category added by Photo Archives, such as File:P (252448165).jpeg which is credited to Tomasz Tom. So there are probably more photos miscategorized. I will take a more thorough look at this later. ReneeWrites (talk) 18:21, 13 August 2026 (UTC)

@ReneeWrites: thanks! Does this mean you plan to follow this up and I can let go of it? - Jmabel ! talk 19:32, 13 August 2026 (UTC)

@Jmabel: Yes! I had some errands to run, but I'm back now. ReneeWrites (talk) 20:23, 13 August 2026 (UTC)

@ReneeWrites: so you will be removing this category where it is wrong? - Jmabel ! talk 20:42, 13 August 2026 (UTC)

@Jmabel:  Done --ReneeWrites (talk) 21:04, 13 August 2026 (UTC)

Results of Wiki Loves Folklore 2026 are out!

Greetings! We are thrilled to announce that the winners of Wiki Loves Folklore 2026 have been selected! We are so excited to share these breathtaking images of cultural heritage with you. Thanks to our vibrant global community, this year's campaign was a monumental success: 100,343 media uploaded to Commons 128 countries participated 1,754 passionate uploaders Click here to explore the 2026 Winning Media A massive thank you to all the photographers, jurors, local organizers, and cultural documentarians who helped make Wiki Loves Folklore 2026 a worldwide phenomenon. Your dedication ensures that local traditions and folklore are preserved and shared under free licenses for generations to come. We hope you'll join us again and continue contributing to the campaign next year! Warm regards, Wiki Loves Folklore International Team

--✝iѵɛɳ२२४०^{†ลℓк †๏ мэ} 14:22, 9 August 2026 (UTC)

Consolidating file requests pages

I've noticed that there are many pages that deal with file requests, which I will list here:

• Commons:File requests
• Commons:Video and audio requests
• Commons:Pronunciation files requests
• Commons:Graphic Lab/Illustration workshop
• Commons:Graphic Lab/Map workshop
• Commons:Permission requests

As such, there are many file requests that are spread across several different pages, making it more difficult to keep track of the number of open requests. Is there a way that file requests could better be organized in one central location? ForeverFlying (talk) 01:13, 16 August 2026 (UTC)

Isn't this the same topic as #Clean up old requests? I don't think graphic labs are the same thing because it requires some back-and-forth design work between the requesters and the graphists, as opposed to just going and photographing the place, or recording the bird, or pronouncing the word. So whether it's a forum format or just a big list of requests by topic or date would determine the relevant page. — Arlo James Barnes 02:12, 16 August 2026 (UTC)

Yes it is the same topic, my bad! ForeverFlying (talk) 02:21, 16 August 2026 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. --ForeverFlying (talk) 02:22, 16 August 2026 (UTC)

Using Commons as a cloud service

Hi!

I have discovered thousands of photos uploaded by a cretain user that I really think is totally out of COM:SCOPE. Selfies, the user's house, garden, car. Photos from holiday trips, tomb stones of most likely relatives, etc. etc. To me it looks like some sort of personal "cloud storage", which directly violates COM:HOST. The vast majority of the files are not used anywhere within the Wikimedia system.

What's the next step? Is there a way to list all the unused files, or the opposite, list all the used files? With somewhere between 5500 and 6000 photos, it will take forever to check all of them manually, if they're used or not. Not to mention individually delete request all of them, except the few of them that might be in use.

As of now, I'm not "outing" the username, so try to answer in general terms.

Regards, 1000mm (talk) 14:10, 8 August 2026 (UTC)

PS! If this post is misplaced and should be at COM:HD, feel free to move it, or let me know and I'll post it there instead. Thanks! 1000mm (talk) 14:12, 8 August 2026 (UTC)

@1000mm: You can use a combination of Special:ListFiles for the relevant user and COM:VFC. When you're beginning a batch editing process (the default for me being a DR), you'll see a white question mark on the right below the loaded thumbnails. Click on one of these, and you'll see the number of uses on projects. A zero on grey indicates that (zero uses on projects) any number higher will bei white-on-red and show that the file is used. It doesn't filter between user pages and pages "relevant" for COM:INUSE, as far as I'm aware, though. And the check doesn't survive the loading of more thumbnails in VFC, so you've to load the amount of images you want to process before doing the check. Regards, Grand-Duc (talk) 14:49, 8 August 2026 (UTC)

@Grand-Duc, what an awesome tool!! Thanks a lot.

After a quick check, there's 5741 photos, and ~150 are in use. I have naturally not checked if any of all the unused ones are "relevant". Some are probably, but some of the ~150 are also "irrelevant" or redundant. A gallery wtih 55 photos of a marina in a small Norwegian town, for instance. My browser allowed me to scroll and list all 5741, but a thumbnail didn't load on nearly all of them, so to create deletion request with a bulk of images would need to do segments based on date, I guess.

In addition, I found that the same person have used at least one other username, with 2000+ uploads. Not checked those with the VisualFileChange tool, but the type of photos are very much the same. 😖

1000mm (talk) 15:45, 8 August 2026 (UTC)

@1000mm: Could you disclose the username, now? Such an amount of media and accounts may warrant a review by several people. That's IMHO not snitching, but asking for curating assistance. Regards, Grand-Duc (talk) 16:33, 8 August 2026 (UTC)

Sure. The user I was initially talking about: Special:ListFiles/Ranværing. Six out of seven of the gallery photos in no:Mo i Rana havn is uploaded by Ranværing. However, all seven of them have "Magne Aga" as byline, and the last photo is uploaded by Special:ListFiles/Sandivas. 1000mm (talk) 16:51, 8 August 2026 (UTC)

For what it's worth: VFC does attempt to ignore uses of images in user pages, sandboxes, and drafts. Omphalographer (talk) 16:51, 8 August 2026 (UTC)

Oh, I wasn't aware of that, Omphalographer, thanks, good to know!

And my opinion about the Norwegian images: the external views of cottages, streets, nature, even if not really spectacular by themselves (example), are quite certainly in scope (near the lower threshold for acceptability, sure, but still well within and not straddling the limits). It's similar to Streetview imagery; I got the feel that a Wikimedian endeavoured to provide a more or less complete coverage of a (part of a) municipality at a given date. This is a legitimate ground for providing photos via Commons. The interior shots, on the other hand, are more of a SCOPE issue (-> COM:PERSONAL), and I spotted 4 copyvios too (the calendars with animal photos on them). Regards, Grand-Duc (talk) 17:46, 8 August 2026 (UTC)

I've scrolled through a couple hundred images, and almost everything I've seen are high-quality images which are absolutely in scope, maybe a handful or so which aren't. Most are geotagged & properly categorized too. ~TheImaCow (talk) 17:46, 8 August 2026 (UTC)

i see no reason to delete, especially when the files cover topics about which people rarely upload (e.g. inside their homes) in remote places. i once proposed Commons:Photo challenge/2025 - August - Home interiors but commons still doesnt have enough files on such topics. RoyZuo (talk) 18:10, 8 August 2026 (UTC)

To be honest, I find a bit surprising that you seem to take it so lightly. Yes, of course there are a lot of these images that could be used, but my oh my, there are many that are really of no good use, or simply garbage.

To name a few of the type of photos:

• several images of the same tree in his garden
• several images of his car, often the same angle and location
• several images of a table on the balcony, with different amount of snow
• quite a few images taken late in the evening or at night, that are nearly pitch black
• multiple images of the same couple of gravestones, from various perspectives and at different seasons
• random people appearing in photos, etc. etc.

Obviously uploading everything, or at least a lot, from the camera roll, i.e. using Commons as a cloud service.

COM:HOST: "Although we do host media and images on Wikimedia Commons, all content must be within our project's scope, which requires, among other things, that all media must be realistically useful for an educational purpose. Unless your images areeducationally useful and in the scope of this project, Wikimedia Commons is not a place to store personal photos or files." many of these really aren’t. A couple of examples:

• File:Overlege Wingesvei 4A balkong 20240621 013508.jpg
• File:AMORC 20140906 IMAG0417.jpg
• File:Overlege Wingesvei 4A balkong 20221015 104342.jpg
• File:Overlege Wingesvei 4A hage 20150522 IMAG0455.jpg
• File:Selforssjøen_bru_20200501_111011.jpg

Where’s the realistically usefulness for an educational purpose here? 1000mm (talk) 19:44, 8 August 2026 (UTC)

@1000mm Did you already ask the user about the purpose? We can only guess, an answer by the uploader might be more useful --PantheraLeo1359531 😺 (talk) 19:48, 8 August 2026 (UTC)

File:Selforssjøen_bru_20200501_111011.jpg looks useful (although the accidental finger is not optimal), but would need geocoordinates --PantheraLeo1359531 😺 (talk) 19:49, 8 August 2026 (UTC)

That one was included because of the finger partially covering the lens, yes. 1000mm (talk) 19:50, 8 August 2026 (UTC)

I geotagged it, now someone has to cut off the finger. Ymblanter (talk) 20:01, 8 August 2026 (UTC)

I used the tool with the scissors in the icon :P Arlo James Barnes 20:08, 8 August 2026 (UTC)

@Ymblanter: that sounds painful. - Jmabel ! talk 22:38, 8 August 2026 (UTC)

Some of the photos aren't really in scope, but honestly, it does seem like the guy is actually trying to upload things that would be useful, evidence by the uploading of the occasional photo that is not his which is under Creative Commons and is properly sourced. But either way, I can see the frustration with some of the images. I think some of them are fine to delete, kindly, by explaining that they are out of scope but that the other images are appreciated. Aplucas0703 (talk) 16:49, 11 August 2026 (UTC)

As an aside - if anyone is up for a large categorization/weeding process, Special:Uploads/Sony 19th has nearly 30,000 largely uncategorized photos, mostly of streets and outdoor areas in the Los Angeles area. There are probably some useful photos of notable buildings in there which should be better categorized; there's also a lot of completely unremarkable and/or low quality images which are unlikely to be of any use. Some assistance would be appreciated. :) Omphalographer (talk) 21:03, 11 August 2026 (UTC)

Edit summary reminder

When editing a page on Commons there is a small field labeled "Edit Summary" or "Summary" under the main edit-box. It looks like this:

Edit summary: 

 

The text written here will appear on the Recent changes page, in the page revision history, on the diff page, and in the watchlists of users who are watching that article. See m:Help:Edit summary for full information on this feature.

Filling in the Edit Summary field greatly helps your fellow contributors in understanding what you changed, so please always fill in the Edit Summary field. If you are adding a section, please do not just keep the previous section's name in the Edit Summary field - please fill in your new section's name instead. Thank you.

This is a repeat on this topic from 2007, and earlier. It would seem that ever increasing, numbers of edits are being made without the courtesy of filling in the Edit summary: field. Is it so hard or unnecessary to show some courtesy here? It's hardly a major task? Why have the field without using it? Chrome amongst others actually can assist with it, so hardly a chore. - Broichmore (talk) 06:32, 11 August 2026 (UTC)

There is also option Prompt me when entering a blank edit summary (or the default undo summary) in Special:Preferences#mw-prefsection-editing. EugeneZelenko (talk) 15:10, 11 August 2026 (UTC)

Is it actually useful to use an edit summary like "new section" when that is already obviously implicit in the edit itself, and it adds nothing more than what is already obvious from the edit?

Edit summaries are useful for content space edits, when their function can't be explained by adding more text to the edit (we don't inline commentary) and the reason for an otherwise unclear edit can be added through them. But this is a talk: space. What needs to be covered in an edit summary here that can't just be included in the edit itself? Andy Dingley (talk) 19:47, 11 August 2026 (UTC)

Edit summaries are really useful when looking through page history to work out when something happened and who was responsible. Also, when looking through a user's contributions, they can really help to understand what sort of work that user does here. Also, on less experienced but clearly well-intentioned editors, they are often a really good clue which of their edits I'd want to check. (Not so much for the ill-intentioned, whose summaries are likely to be lies.) Less importantly, they are also sometimes a timesaver when going through the changes on a big watchlist. Consistently good editor said they just refined a category, or are reverting vandalism? I often don't even need to click through. - Jmabel ! talk 22:41, 11 August 2026 (UTC)

Public domain photo of Robert Johnson

I believe I have ascertained the first truly public domain photo of the legendary musician Robert Johnson. It is a 1937-1938 self-portrait in a photo booth that was never published until 2020. I have uploaded two copies, one is the highest quality scan I could find of the book cover (cropped to remove the letters), and the second is what I believe is the initial physical print of the photo.

The former is high quality, but is somewhat awkwardly cropped to eliminate the book title. The latter is the uncropped photo but is low quality. If anyone can find a HQ scan of the photo without the lettering, I would be thankful. – Howardcorn33 (💬) 22:31, 11 August 2026 (UTC)

Request rare illustration of Bananas in Pyjamas

Hello everyone! I am looking for a very rare illustration of four bananas in pyjamas: two wearing the classic blue-and-white striped pyjamas, one in red-and-white, and one in green-and-white. It can be found exclusively in the book Nursery Play Rhymes, illustrated by Jenny Press and published by Video Collection International between 1990 and 1991 (ISBN/EAN: 5014138110062). Does anyone happen to have this book and could upload a scan of this page to Commons? Thanks! DanielParoliere (talk) 11:00, 14 August 2026 (UTC)

See COM:L. Wikimedia Commons can not host any images that are in copyright, as the cartoons would be. Fæ (talk) 12:15, 14 August 2026 (UTC)

Should new, complete maps contain name of creator in legend or margin?

I was talking to someone, and they said that maps in Wiki Commons often violate professional mapping guidelines, because the maps did not identify the creator of the map. (The creator is typically a company, government agency, or individual). They said that high-quality, professional maps contain the identity of the creator embedded in the map itself, typically in a legend or in the margin. I'm pretty sure that is not a requirement for maps in Commons. Question: Has there ever been a proposal that maps in Commons (particularly new, complete maps uploaded to Commons) should contain the identity of the creator somewhere in the map image? Or, more generally, that new, full maps should contain a legend with scale, data source, etc? Noleander (talk) 14:32, 14 August 2026 (UTC)

How this will coexists with Commons:Watermarks? EugeneZelenko (talk) 15:08, 14 August 2026 (UTC)

This guide from ESRI opens with: "A successful design begins with knowing why the map is being made. [...] The topic and intended audience will dictate many of a map's characteristics." which implies that some maps require more details (such as a legend and scale and so on) but others eschew these aspects to better emphasize other facets of the cartographic data being conveyed. Arlo James Barnes 15:11, 14 August 2026 (UTC)

That is what the description is for. The description is actually shown in the corner when you enlarge a picture with the standard media viewer. It is even larger then in most maps which have a tiny copyright information somewhere on the edge. Personally I wouldn't mind a small watermark, but it works differently on Commons, and attribution is quite well done in many cases. Nux (talk··dyskusja) 16:59, 14 August 2026 (UTC)

I think it depends on the type of map. As we have vector data maps should only be uploaded as files if it is really needed. For simple maps without a legend I would not add it to the file itself. For every map with a legend I would add the sources of the data directly to the file. I would not add the composer directly to the file for the use cases we have here usually. GPSLeo (talk) 19:12, 14 August 2026 (UTC)

Okay, so I gather (from the responses so far) that there has not been a proposal (made in the past) to mandate that information such as creator or data source be depicted in the images of new, full maps uploaded to Commons. That's good to know. I wasn't suggesting that it become a guideline; I was simply curious. It appears that the equivalent information in the file's Description page is sufficient. Noleander (talk) 21:31, 14 August 2026 (UTC)

Here is a example where I included the source in the file: File:DWD RADOLAN and stations precipitation southern Germany 2024-05-30 to 2024-06-03.png. GPSLeo (talk) 21:38, 14 August 2026 (UTC)

Thanks for that example. That is exactly what the other person was suggesting: that the creator (and data source, etc) be identified in the map's image (in addition to the Description page). I think the reasoning for the proposal was that the map image should conform to professional map guidelines and the creator is permanently named in the map itself. That way, the creator is known, even if the map file gets separated from its Commons Description page. Noleander (talk) 21:44, 14 August 2026 (UTC)

@GPSLeo thanks for the example. There is unfortunately an immediate problem with that image, which is that Commons is a multilingual project. Daten is a German word and it cannot be translated in the image. It could be translated in the description. Nux (talk··dyskusja) 23:53, 15 August 2026 (UTC)

i think you have a good point.

most if not all professional maps produced before the internet have names and years on them.

it makes sense that modern maps, even svg maps created by commons users, should follow that convention. RoyZuo (talk) 14:04, 15 August 2026 (UTC)

It does make it necessary to l10n the file instead of relying on the i18n of leaving it uninscribed. Arlo James Barnes 22:34, 15 August 2026 (UTC)

Clean up old requests

Commons:Audio and video requests; Commons:Pronunciation files requests and its many different versions, contain many old, unattended requests. maybe they could all be merged into commons:File requests?--RoyZuo (talk) 15:00, 15 August 2026 (UTC)

 Support Arlo James Barnes 22:35, 15 August 2026 (UTC)

 Support I'm also wondering if file requests could be organized similarly to Commons:Deletion requests, in that there are several subpages that are included in one main page, and the subpages could then be organized by topic? That way there could still be categorization by file type or topic if desired but everything could still be in a central location. Perhaps archiving topics would be easier too. ForeverFlying (talk) 02:24, 16 August 2026 (UTC)

@ForeverFlying all request are already on Commons:Deletion requests/2026/08 which is quite long might I add and also you cannot subscribe to them which is problematic. Nux (talk··dyskusja) 17:36, 16 August 2026 (UTC)

That's true, I hadn't thought of that. ForeverFlying (talk) 18:00, 16 August 2026 (UTC)

User script for Trove article images

Tim Sherratt has written a Tampermonkey script for downloading from Trove, the Australian archive, images of newspaper articles (from which, subject to copyright, photographs can then be extracted).

I have tried it and (subject to the caveats he states, about its slowness) it works well.

He describes it in "A new way of downloading Trove newspaper images". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:07, 17 August 2026 (UTC)

'The Gazette' - Wikimedian in Residence

From today, I am Wikimedian in Residence at The Gazette (aka The London Gazette).

Please see en:Wikipedia:GLAM/The Gazette for details, and let me know if you have any suggestions or requests. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:13, 11 August 2026 (UTC)

I wonder if the gazette publishes any images... probably not. – Howardcorn33 (💬) 17:18, 11 August 2026 (UTC)

Seems like it does. For anyone with w:WP:TWL, https://newspaperarchive.com/london-gazette-feb-01-1913-p-1 seems to be the most recent page in that particular archive, and https://thegazette.co.uk/London/issue/60017/page/1 at the main site? — Arlo James Barnes 18:29, 11 August 2026 (UTC)

What's the TWL URL for your 1913 link, please? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:39, 12 August 2026 (UTC)

Do you mean https://access-newspaperarchive-com.wikipedialibrary.idm.oclc.org/gb/middlesex/london/london-gazette/1913/02-01 or a different URL? I see it is labelled 'The Middlesex Gazette, a weekly constitutional journal' so perhaps it is misfiled in the archives of the daily London Gazette. — Arlo James Barnes 14:47, 12 August 2026 (UTC)

That's certainly not the Gazette in question. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:07, 12 August 2026 (UTC)

I haven't seen any photographs, but am in the process of confirming.

Of course, each page scan is published as an image. We have a few in Category:The London Gazette and yesterday I created Category:Edinburgh Gazette and, just now, Category:Belfast Gazette, and uploaded sample images for each. I don't plan a bulk import, though. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:45, 12 August 2026 (UTC)

Update: The Gazette team tell me the only other images they're aware of are royal coats of arms, one postage stamp (date of publication not recalled), and this simple diagram of a coffin which was used a few times. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:19, 12 August 2026 (UTC)

Here's a list of crests/ arms - I'll be uploading an example of each in due course. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:15, 18 August 2026 (UTC)

That would be good for cross-referencing how coats of arms are meant to look, I think. – Howardcorn33 (💬) 19:25, 18 August 2026 (UTC)

User stat tools

i'm gonna make a template that aggregates links to tools that analyse or compile stats about a user. i know these. could you please add more?

• https://glamtools.toolforge.org/
• https://ptools.toolforge.org/uploadsum.php
• https://wikimap.toolforge.org/
• https://commons.wikiscan.org/users
• https://xtools.wmcloud.org/

RoyZuo (talk) 15:00, 15 August 2026 (UTC)

https://quarry.wmcloud.org/ can also execute queries about one user's uploaded files like amount of data, but only with SQL --PantheraLeo1359531 😺 (talk) 17:44, 15 August 2026 (UTC)

@RoyZuo, this tool maps a user's files using this Quarry query as input. It is vibe-coded, but the bugs have mostly been beaten out and it works well with prolific uploaders. See here for discussion.

Example at Data:Charlesjsharp uploads Africa.map. JayCubby (talk) 21:47, 19 August 2026 (UTC)

ohiomemory.org

Commons currently has over 64,000 images of various kinds, including page scans and screenshots from "Ohio Memory". Unfortunately the website terms of use page spell out a number of conditions that do not meet Wikimedia Commons policies. For example:

One-Time Use.
The right to reproduce materials held in the collections of the Ohio History Connection is granted on a one-time basis only, and only for private study, scholarship or research. Any further reproduction of this material is prohibited without the express written permission of the Ohio History Connection.

Use Agreement.
Materials are reproduced for research use only and may not be used for publication, exhibition, or any other public purpose without the express written permission of the Ohio History Connection. Reproduction of any materials that are a part of Ohio History Connection’s collection without submission of a request for reproduction to Ohio History Connection, using the organization’s forms for such requests, is prohibited. Reproduction of any materials submitted by or owned by any institution participating in the Ohio Memory program without that institution’s permission is prohibited.

We have an example deletion request at Deletion requests/Files found with 2052def8d8d0287275ea8e069f7bf5e2, though general comments about what should be done to either clarify copyright or delete all images from this source would be welcome here. Fæ (talk) 14:38, 19 August 2026 (UTC)

The source has plenty of uploads which are obviously public domain regardless of their claims, eg.:

• File:Catherine Cooper Hopley with turtle.jpg
• File:Amos Sutton Hayden portrait photograph.png
• File:Sardis Birchard, 1871 engraving by Alexander Hay Ritchie.jpg

Any deletion request would have to be selective enough to at least exclude such images. – Howardcorn33 (💬) 14:46, 19 August 2026 (UTC)

Yes, though I'm thinking that a simple search for works stating publication after 1931 could be a starting point, though a non-controversial deletion request could be everything from this source claimed as published after 1977. Fæ (talk) 14:59, 19 August 2026 (UTC)

To be truly non-controversial would be to start at publication after February 1989, but post-1930 is probably more acceptable as a starting point. – Howardcorn33 (💬) 15:03, 19 August 2026 (UTC)

As an experiment, populating Category:2020 publications from ohiomemory. Looking at a couple of photographs these seem specifically created with a public domain dedication, but it needs checking each time. There are a lot of Covid related documents, these were published by state agencies, which do not automatically make them copyright free based on Ohio state copyright legislation. Without specific releases these can be rationalized for deletion. There are also more generic documents like File:Semi-annual report - for the period (2020-07-01 to 2020-12-31) - DPLA - 8c0b7139c2173ffe8269c29b58f87bda.jpg which are probably out of scope for Commons but in addition there is no required copyright statement and though it is a government document, it is an Ohio State government document not a federal work, so may have copyright, plus the source quoted no longer exists so this front cover screenshot is very unhelpful in providing any evidence of a copyright release.

It's messy. Fæ (talk) 15:36, 19 August 2026 (UTC)

The literal first image in that category is clearly not from 2020. I hope there isn't further such miscategorization. – Howardcorn33 (💬) 15:53, 19 August 2026 (UTC)

That's not a surprise, this is a basic search looking for 2020 anywhere, so the Women in Red category was picked up even though this had nothing to do with date of publication. In fact these particular uploads are incredibly difficult to filter on as the wikitext has been made deliberately blank by the DPLA. Even worse in the samples looked at so far, the SDC data doesn't have anything accurate to say about publication dates, even though the publication may have the year (2020) in the title.

It's messy. Fæ (talk) 18:45, 19 August 2026 (UTC)

Sample DR based on this filtering, entirely manual confirmation, so unfortunately it's not going to be possible to do this for the tens of thousands of uploads in this painstaking way. This is wrong, the *burden of proof* for copyright must be on the uploader, not everyone but the uploader.

1. Deletion requests/Files in Category:DPLA AR no source
2. Deletion requests/Files in Category:DPLA auditor of state bulletin ohiomemory
3. Deletion requests/Files in Category:DPLA Consumer Advocate ohiomemory
4. Deletion requests/Files found with "Ohio--Census
5. Deletion requests/Files found with "Combating COVID-19." ohiomemory

--Fæ (talk) 19:04, 19 August 2026 (UTC)

"Information and education only"

I want to upload this video (or a still frame of it) from the European Commission Audiovisual Service using the relevant license, but it states in the conditions of use that its for "Information and education only". Does Commons fall under this use? Hsnkn (talk) 04:55, 19 August 2026 (UTC)

@Hsnkn: Commons as project itself is educational, yes, but you can't upload media with such restrictions nevertheless. This is because any file hosted here has to be free and must fulfil the requirement of re-usability for any and all purposes, including commercial endeavours. Please refer to COM:Licensing for further details. Regards, Grand-Duc (talk) 05:26, 19 August 2026 (UTC)

Understandable. Looking at the shotlist section, only the "Exterior view of the Breydel building, in Brussels" from 0:08 to 0:13 is marked as educational, while the other parts don't have any copyright restrictions written. Would this mean that anything in video that isn't in that timeframe is permissible for uploading? Hsnkn (talk) 05:53, 19 August 2026 (UTC)

Yes. If you are going to make this a mini project, then it would be sensible to make sure the evidence about which parts are freely licensed is well presented and preferably linked to archive.org as permalinks. Video is complicated, so keep in mind music, graphics, screenshots, artworks that might be in the background can be problems for copyright. However if you've made reasonable efforts, nobody would blame you if an upload were challenged for something you missed. Fæ (talk) 07:07, 19 August 2026 (UTC)

Actually I wasn't thinking about editing the video, just uploading a screenshot. Hsnkn (talk) 07:31, 19 August 2026 (UTC)

@Hsnkn: I took a peek at the {{EC-Audiovisual Center}} tag, apparently, it's designed to call for a license review. That's helpful. So, I'd suggest that you upload your extracted video still with that licensing tag, and please do not forget to mention the timestamp from where your image is taken. Then, come back here and show the link to your upload - I am (and Fæ too) a license reviewer, and if nobody beats me to it, I'll make the review.

And if I'm not mistaken, the video is actually a legit CC-By file, that statement "Scopes : Information and education only" is seemingly outside the licensing statement and thus irrelevant for the copyright status. Regards, Grand-Duc (talk) 08:08, 19 August 2026 (UTC)

Here it is. Hsnkn (talk) 21:58, 19 August 2026 (UTC)

@Hsnkn: I've provided the review. And, just as a side note, as I saw you cropped the image: I would always recommend to use the lossless mode of the CropTool, not the precise mode if it can be avoided. The reason is: using the precise mode engenders a new encoding which causes en:generation loss in lossy file formats like JPEG. The lossless mode doesn't do that, it keeps the encoding that's already present. Regards, Grand-Duc (talk) 09:24, 20 August 2026 (UTC)

File needs to be fixed

This file isn't playing and needs to be fixed. PublicDomainFan08 (talk) 08:49, 15 August 2026 (UTC)

This is a large video file and Commons is quite poor at coping with videos over 1GB. If you want to try re-uploading, do so using one of the urls, such as the internet archive version. I tried with the 2GB IA version, but the mediawiki system gave up before it finished. Fæ (talk) 12:57, 15 August 2026 (UTC)

it looks like the file was not converted to webm properly Bawolff (talk) 17:03, 15 August 2026 (UTC)

You can try this an as upload tool https://image-annotation-tool.wmcloud.org/ It should convert from MP4 and is supposed to have a 2 GB upload limit. Doc James (talk · contribs · email) 21:39, 21 August 2026 (UTC)

CropTool vs. Geograph template

I used CropTool to crop File:Houses on Calton Hill - geograph.org.uk - 1944687 (cropped).jpg from File:Houses on Calton Hill - geograph.org.uk - 1944687.jpg.

The latter uses {{Geograph from structured data}}, which has carried over to the new image, where it finds no data and causes warning messages. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:43, 18 August 2026 (UTC)

@Pigsonthewing The original file uses SDC data for its information, and I don't think CropTool will transfer any SDC data to the cropped files. So, you will need to manually, or perhaps use the MoveClaim Tool, to transfer the SDC data over to the cropped file. Thanks. Tvpuppy (talk) 20:57, 18 August 2026 (UTC)

It very cautiously started transferring SDC in recent updates: depict statements can now be curated before the upload is completed. I decided this on my own, since I was already adding interface elements to curate categories. There might need to be a broader discussion on what SDC should be moved forward by default and how much expansion the curation after the crop is suitable. I've had some request to make the category curation as expansive as cat-a-lot. Vera ^(talk) 05:47, 19 August 2026 (UTC)

Please avoid "hiding" information in SDC. It's a lot easier on reusers, other tools, other volunteers if SDC stuff only duplicates what is in the wikitext somewhere. Fæ (talk) 07:09, 19 August 2026 (UTC)

That ship sailed a long time ago. Holding data in a structured form is always going to be preferable to doing so using free text. The best practice of don't repeat yourself also applies. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:14, 19 August 2026 (UTC)

I think at some point commons needs to decide if it wants to do this whole SDC thing or not. The status quo of basically duplicating metadata in both places seems really bad and kind of worst of both worlds. In the long term we should pick a method and stick with it. Bawolff (talk) 21:38, 19 August 2026 (UTC)

"Depicts" like the category list, is tricky, because a subject may be cropped out of the image, or made prominent where it originally was not. The same for "caption". But creator, date, location (usually; there are edge cases) and camera details, etc are consistent.

It might be possible to detect that, say, only 10% or less of the image is lost, and assume that all SDC persists. Or to have a "Has the subject(s) of the image changed?" check-box. Or to add cropped images to a "Cropped images needing SDC check" category (perhaps via a template), which experienced CropTool users can then remove. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:05, 21 August 2026 (UTC)

Thank you I'm aware of the cause, and the solution. My point is that we direct inexperienced users to use CropTool, yet there is no advice or warning for them about this issue, which is likely to occur with increasing regularity. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 08:10, 19 August 2026 (UTC)

Philippine proposed law: House Bill 9981 of 20th Congress

The PDF file of this bill

I felt it is best to share this House Bill here, since that it hasn't been incorporated in the law yet. This House Bill concerns granting a new threshold for AI-generated works. As the proponent stated, "this Bill addresses this gap by amending R.A. 8293 to introduce distinct legal thresholds. It explicitly clarifies that while purely AI-generated materials belong in the public domain, AI-assisted works are protectable only to the extent of the human author's creative control, modification, and arrangement. It also introduces a mandatory disclosure mechanism during registration to maintain transparency and protect the integrity of the intellectual property system."

It proposes to add a new Section 172.4 under the current PH copyright law, to be read as:

172.4. Copyright in AI-Assisted Works. – AI-assisted works shall be eligible for copyright protection, subject to the following conditions:
(a) Protection shall only extend to the original elements of human expression, arrangement, selection, or modification added by the natural person, and shall not cover the underlying AI-generated content itself.
(b) To determine eligibility, the Bureau of Copyright shall apply the 'De Minimis Non-Curat Lex' standard to the AI's contribution. If the AI-generated portions are mechanical, automated, or subordinate to the independent creative execution of the human author, the work as a whole is copyrightable.
(c) Prompt engineering alone, consisting of standard descriptive commands or strings of text, shall not satisfy the threshold of original human authorship unless accompanied by substantial post-generation modification, arrangement, or creative synthesis by the natural person.

It may likely institutionalize de minimis for the first time as a copyright concept here in the Philippines, something that isn't for a very long time, considering that fair use is a usual standard by the courts in testing the claimed infringement. However, it instead applies de minimis in the context of the degree of AI's contribution. De minimis isn't formally recognized as a copyright concept here, but rather is a term in customs duties and tax-exempt employee benefits. JWilz12345 (Talk|Contributions) 15:01, 21 August 2026 (UTC)

MIME Type Problems upload jpg file

I try to upload this file. But the uploader doesen't want to upload it, as it has the wrong MIME type. I tried to change it from jpg to jpeg (all lowercase letters) but that doesn't help. Can some body tell me how the file extension should be correctly?--Sanandros (talk) 19:51, 22 August 2026 (UTC)

I downloaded the file from https://media.defense.gov/2023/Feb/16/2003162697/-1/-1/0/230212-A-LU981-003.JPG and took a look at it with a HEX editor, looking for the en:Magic number (programming) for JPEG. The starting FF D8 is actually present, so I can't provide any other clues as for why the upload fails. JPEG should be correct when going by the innards of the file. Maybe you could try a new download? It's not excluded ATM that your file is corrupted. Or past your {{Information}} contents that you wish to use here, I could try an upload myself, Sanandros. Regards, Grand-Duc (talk) 20:14, 22 August 2026 (UTC)

Ja ein neuer Download hat geklappt siehe File:Arctic Forge 23 Logo 230212-A-LU981-003.jpeg. thx. Falls ich gewusst hätte dasst du so schnell reagieren würdest hätte ich gleich beim Forum gefragt.--Sanandros (talk) 20:30, 22 August 2026 (UTC)

@Sanandros: Bite bitte. :-) Ich habe VP und Forum beide auf der Beobachtungsliste und war eh vor dem Bildschirm, daher die schnelle Reaktion. Grüße, Grand-Duc (talk) 21:19, 22 August 2026 (UTC)

How to categorize 45,000 media needing categories as of 2023?

How to categorize 45,000 media needing categories as of 2023 most efficiently? I think that more volunteers will be required, because it is unlikely that this can be done automatically. Most low hanging fruit such as sunsets, beaches, diagrams, charts and maps have already been categorized, and now we need your expertise, please, to allocate the most appropriate categories to these files. Could you help, please, or at least leave a comment, please, how to tackle this task more efficiently? --NearEMPTiness (talk) 05:23, 14 August 2026 (UTC)

Why would you expect this to be significantly different than the prior years, which have been done reasonably successfully? As far as I can tell, the rate of progress has been about the same here. - Jmabel ! talk 06:05, 14 August 2026 (UTC)

I have a feeling that more and more uncategorized media are being uploaded each year, and that more volunteers and/or more efficient procedures are required, to tackle the backlog. Putting some files in a temporary category, such as category:unidentified men might be a solution, hoping that someone, who is interersted in identifying them, can do this more easily that by scrolling to 45,000 files showing all sorts of media. --NearEMPTiness (talk) 06:47, 14 August 2026 (UTC)

We need to improve categorization at, or immediately after, upload time. The tools are the same as I remember them for the last twenty years! How have we had so little progress here?

We need a strong incentive to categorize. Such as speedy deletion of uploaded and uncategorized content a day after upload, with massive warnings at upload time. Will we really lose anything? Obviously that can only work if categorization is at least vaguely useful, so this should also be incentivised to reduce mis-categorization. Dumping new content into 'objects', 'people', 'landscapes' ('influencers' and 'digital creators' too?) or any category that's already over-populated should likewise generate strong warnings.

WMF clearly have no interest in any technical support to do any of this. Andy Dingley (talk) 10:43, 14 August 2026 (UTC)

I remember proposing making category field compulsory when uploading a file, maybe one year ago or so. The proposal received mostly negative votes, with voters arguing that miscategorized files were a bigger problem than uncategorized ones. I agree that people who don't categorize their uploads are highly likely to miscategorize them, if categorization is compulsory. But maybe miscategorization is not such a big problem, in the sense that miscategorized files are easily detected when looking at a category, and they are few at each individual category. This is a complex issue and I don't have a clear viewpoint.

There is also the possibility that, for all files that are currently uploaded uncategorized, maybe a relatively small % of them would be miscategorized (for example, 20%). People being lazy or unexperienced does not mean they lack common sense. Another thing is that they would be more likely to do a poor categorization, but I think this is clearly a lesser evil when compared to uncategorized or miscategorized files.

A different case is removing all categories from an existing file: my opinion is that this should not be allowed at all. MGeog2022 (talk) 11:26, 14 August 2026 (UTC)

Do you have a link to that old discussion? Andy Dingley (talk) 11:43, 14 August 2026 (UTC)

I've had a quick look just now to my edit history of about 1 year ago, and I haven't been able to find it. The edit history is too long (and it includes many edits to Village Pump), I don't remember the exact date (it could well have been two years ago and not one), and I don't know the exact words of the edit summaries. I'm sorry :( MGeog2022 (talk) 12:31, 14 August 2026 (UTC)

Apologies for not working on this as much as I did previously, I have been working on AI cleanup on enwiki mostly Gnomingstuff (talk) 04:12, 23 August 2026 (UTC)

It's worth noting that rather than putting a focus on volunteers uploading their photos, the example of the funded DPLA project has created a far larger backlog of poorly categorized files going back several years and hardly anyone has asked for better categorization up front. In 2025 the bot uploaded 4,358,048 files. Of these 1,567,037 are shown on the database as having visible categories but 2,791,011 still have no visible category, but rely on large hidden source categories like Category:Media contributed by National Archives at College Park - Motion Pictures (which I happen to be looking at for a deletion request), which as a source category has 134,531 files in it. Categorization can be automated, for example my uploads to Early English Books which may have over 67,000 books in it when complete, are gradually retrospectively sorted by publication year in sub-categories. However automated categorization is itself a technical headache of what is going to be meaningful and not artificially hide stuff under complex over sub-categorization for the sake of it. --Fæ (talk) 11:09, 14 August 2026 (UTC)

Some of those hidden categories are still quite useful, and quite specific. I've done some work with the Anefo collection, a large Dutch news image library covering the second half of the 20th century. Just that label alone is quite a good starting point. Which is handy, as it's tens of thousands of images, auto-identifiable by author, date, 75% chance of being in the Netherlands, and the rest depending on parsing a para of description and hoping for a town name. But 'Anefo' alone is so much better than nothing, and so much easier to start from than the images in this post. Andy Dingley (talk) 11:42, 14 August 2026 (UTC)

Thanks for your comments. From my point of view, it is effective, to search with GlamTools for files that are already used in an article, or to check Commons:WikiProject Minimum One Category for further hints. Basically, a larger number of volunteers would simplifiy the task. NearEMPTiness (talk) 04:47, 16 August 2026 (UTC)

Difference between Category:People on boats vs Category:People in boats?

Is there a difference between those two categories or are they just two different phrasings to express one and the same thing? If they are the same, then which one would be the more common phrasing and which should be a redirect? Nakonana (talk) 08:42, 22 August 2026 (UTC)

For canoes and small barges the distinction is moot, but for larger vessels there are definitely separate interiors and 'topsides'. Arlo James Barnes 23:32, 22 August 2026 (UTC)

Native American English speaker: this is a distinction without a difference to me. Even in the case that Arlo mentions of someone being topside, I could just as easily say that he's "in a boat" and someone in the guts of the boat is "on a boat". ―Justin (koavf)❤T☮C☺M☯ 23:42, 22 August 2026 (UTC)

Also a native American English speaker: I would certainly never say someone was "on" a canoe or small rowboat. Once you get even up to a liferaft or a very small sailboat, they become pretty interchangeable. Much larger than that and "on" is almost inevitable (you'd never say someone was "in" a cruise ship or a merchant vessel, though oddly now that I think of it you could for a submarine). So if we intend to cover that whole range, the choice is pretty arbitrary. - Jmabel ! talk 04:33, 23 August 2026 (UTC)

Aside: that submarine case is weird. You can equally say "Chuck lived in/on a submarine for six months" but probably not "Chuck lived in the U.S.S. Nautilus for three months," once you bring in the name it has to be "on" even though it's a submarine. English is weird. - Jmabel ! talk 04:33, 23 August 2026 (UTC)

Now that you've mentioned the canoe example I realize that German actually also makes this distinction. Looks like this is more complex than I thought. Nakonana (talk) 19:18, 23 August 2026 (UTC)

I agree that 'in' is the more generic/ambiguous usage, so I'd redirect that to 'on', and if it is necessary to specify then people inside boats could be used. Arlo James Barnes 17:56, 23 August 2026 (UTC)

CCTV images related to the killing of Brian Thompson

Several images in the category Category:Killing of Brian Thompson are of an individual caught on CCTV in December 2024 who was suspected of carrying out the killing of Brian Thompson. Since the recent guilty plea of Luigi Mangione to the killing, his English Wikipedia article and his Wikidata entry use an image from the CCTV footage and explicitly identify him as Mangione. Can Commons now also explicitly identify the individual in the CCTV footage as Mangione in file descriptions and move the images into the category Category:Luigi Mangione? – Howardcorn33 (💬) 09:59, 22 August 2026 (UTC)

Unlike Wikipedia, files on Commons are a snapshot. There's no expectation or 'by design' that media uploaded with descriptions or file names correct at the time of upload would ever be updated; though they can if a volunteer wants to, preferably adding information and preserving the nature of the record of the original upload. However certainly moving categories around to be a more accurate taxonomy is a conventional thing to do. Fæ (talk) 13:22, 22 August 2026 (UTC)

If it were to be mentioned in the description, it should be something like "later identified as". - Jmabel ! talk 04:45, 23 August 2026 (UTC)

Show Wikidata item P18 usage alongside "File usage"

Currently the image file File:The hand that will rule the world.jpg shows wikipedia usage, but it is does not show wikidata usage (typically P18 image property), unless you go to "global usage". I believe this should be more prominent. This is not an issue of too many links, for example File:Tarifmappe Haustarifvertrag Volkswagen.jpg links to 3 Wikipedia pages but doesn't show Wikidata still, even though d:Q163887 links to it via P18 image property Shushugah (talk) 08:45, 23 August 2026 (UTC)

I see it is mentioned in File:Tarifmappe_Haustarifvertrag_Volkswagen.jpg#globalusage which makes me think it is an issue of database syncing, and which wikis are sorted first when there are too many mentions. Is there a way to sort/personalize the hierarchies of wikis shown? My hunch is most users want to see their home wikis first, and perhaps multi-lingual wikis because they are less common/have a global value, whereas language specific wikis are specific? Shushugah (talk) 10:01, 23 August 2026 (UTC)

It's there, just like any other sister wiki; it's just that when a certain limit is exceeded, it won't all end up on the first page. - Jmabel ! talk 17:44, 23 August 2026 (UTC)

UK govt falsely claims photography of people in public is illegal

UK Home Office issues incorrect guidance that "In the UK, you should not take pictures or videos of someone without their permission", and that doing so could lead to arrest. This is contrary to the law, and to their own police guidance. They even tell people to report being photographed in public to the police.

Reported in "The Home Office Needs To Get Photographic Law Right". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:38, 23 August 2026 (UTC)

LOL. Side-bar. Once I was stopped by a police officer when taking shots on my 'proper' camera of the cast ironwork at one of London's oldest train stations. I was polite and mostly amused, having recently read up on the legislation. I quizzed him if there were special reasons to stop me, then if this was a public space. He resorted to mentioning the terrorism act, but crumbled and let me carry on, mostly due to my raised eyebrows and asking exactly what part of the act would necessitate me not taking photos at that moment when there was no incident. He even let me take a portrait photograph of him; which I politely requested.

Anyway, I rarely take shots with people, and if anyone genuinely does not want to be personally photographed I am always courteous and reassuring that I respect their wishes. If anyone runs into threats of arrest, please make careful notes of exactly what words they use, remain excessively polite, follow their orders but preferably take video and publish on YouTube later, there's lots of photographers in the UK that will be interested in what the police think the law is. As for "Home Office" guidance, considering they are run by Shabana Mahmood, sure, their documents are going to be absolute pants. --Fæ (talk) 18:55, 23 August 2026 (UTC)

Isn't it similar in other European countries (like Germany[4][5]? And in Japan, too? You may photograph (large) groups of people per the logic that any individual in the group will be "de minimis", so to speak. But if you are photographing single individuals (or small groups) then you actually need to ask people for permission (even outside in public, unless the people in question are public people like politicians, performers, famous people). And yeah, going by the law, a prison sentence is possible under certain circumstances in case of violation. Nakonana (talk) 16:27, 24 August 2026 (UTC)

If what you say about Germany and Japan is true, then, no that is not similar to the UK, where no such restrictions apply. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:34, 24 August 2026 (UTC)

Proposal for making Template:No watermarks 1% more understandable and friendlier

Hi :) Join this talk about a widely used warning:

See also: Template talk:No watermarks/en.

Thanks! bozz (talk) 12:43, 24 August 2026 (UTC)

Re-examination of the colors of the flag of Taiwan (Republic of China)

It has been 17 years since the colors of the flag of the Republic of China/Taiwan were 'finalized'. They were based on sources available to Wikipedians at the time. I think there are more than enough new sources for us to re-examine this issue again.

1. The Ministry of the Interior's and the Presidential Office's Illustrator masters.

In 2011 and 2014 respectively, Taiwan's Interior Ministry and Presidential Office released an example of the national flag in .ai format. Both are identical in color, with the only differences being their image size, it would seem. As the original files were made using a CMYK format and the exact color profile is not saved, I cannot say definitively what display is necessarily correct. I have, however, managed to narrow down the likelihood of the color profile being Japan Color 2001 Coated, considering how close its output is compared to the government's JPEG preview of the same AI file. Blue is C100-M80-Y0-K20 and Red is C0-M100-Y100-K5; which when converted into sRGB with the Japan Color 2001 profile yields #003686 for blue and #DF0012 for red. The presidential office's JPEG version yields #003487 and #DE0011 respectively. This aligns with the Ministry of Interior's recommendations.

2. Web logos

taiwan.gov.tw uses #CF1400 and #000095 for its main logo; later it uses #E60012 #0B3190 in its 'About Taiwan' section. The Presidential Office uses Wikipedia's present color palette in its logo. However, it also uses this color palette in a section about the national flag: #DF0012 and #013686. Please take note of how close this is is to the Ministry of Interior's color specifications.

3. Photographic evidence

1, 2; and many others show generally darker colors, not neon red and blue. While it's true that photographs are not perfect given lighting conditions, the pattern still remains.

4. Conclusion

The Ministry of the Interior has already provided color specifications, multiple masters/examples and the like. The presidential office has provided an example which aligns with the MoI's specifications. Other sources may use alternative colors, but we have actual color specifications and numerous examples prepared by the Taiwanese government which all have nearly identical colors.

5. Display

Current colors & proposed colors

• 
  Current colors
• 
  Proposed colors, from the Presidential Office

Please give comments and thoughts below. — TheodoresTomfooleries, 24 August 2026

References

Once again, I would *greatly* appreciate your feedback. — TheodoresTomfooleries, 25 August 2026 — Preceding unsigned comment added by TheodoresTomfooleries (talk • contribs) 16:35, 25 August 2026 (UTC)

It seems well-researched, so I would support replacing uses on a wiki-by-wiki basis. Arlo James Barnes 17:13, 25 August 2026 (UTC)

New LicenseHelper Userscript (soliciting feedback)

I've always found updating the licenses on Wikimedia Commons files a bit tedious and hard to do at times, since you have to hunt down the template name sometimes and then switch them out. I've just created a new userscript (LicenseHelper) that should hopefully help with it. (Disclosure: Coded with Google Gemini and human tested)

Features: Add, delete, or replace a license tag with a few clicks. The menu has preloaded options with the standard licenses and other license sets to choose from with more options. You can also save a license tag not pre-loaded and use it anywhere else you need it (useful if you upload files PD in a foreign county).

The options are available from the licensing section on every file. If there is no section, a bar at the bottom will appear with the options, and it will add the licensing section if you use it.

It is located at User:Aplucas0703/LicenseHelper.js. You can import it by adding "importScript("User:Aplucas0703/LicenseHelper.js")" to a line in your common.js file. Let me know if you have any feedback or find any bugs. You can use File:Test-Sandbox file for Aplucas0703.jpg to test it out if you don't have a file to use it on. Aplucas0703 (talk) 03:59, 25 August 2026 (UTC)

@Aplucas0703, some things that come to mind:

1. As you've already mentioned, not all files have a == {{int:license-header}} == section. License template are also often found within {{Information}} or simply pasted somewhere on the file page. Does your script deal with this by moving the data into the license section?
2. Monobook is still used, by me, for instance. I didn't see any option to change licenses on File:Test-Sandbox file for Aplucas0703.jpg nor on File:IMO 9516416 Containership COSCO France - Cuxhafen 2020-08-27 HBP 01.jpg (one of my images). -> You may have to check for skin incompatibilities or collisions with other tools (my sets are defined by User:Grand-Duc/monobook.js, User:Grand-Duc/common.js and m:User:Grand-Duc/global.js.

Regards, Grand-Duc (talk) 04:12, 25 August 2026 (UTC)

@Grand-Duc Thanks for the feedback. I double checked with Monobook and all other skins and it does indeed appear to work in all skin types. it might be a collision. The extra edit buttons script could be the culprit since that is essentially how the options appear (like edit buttons on the section). Script is not currently equipped to handle other license locations at this time but that can be done too. Aplucas0703 (talk) 04:27, 25 August 2026 (UTC)

If you meant the Help:QuickDelete gadget - that appears in a sidebar, not within the licensing section, I wouldn't assume that this is source of a collision. The thing in my monobook.js (de:MediaWiki:Gadget-Extra-Editbuttons.js) is disabled (shouldn't load as made into a commentary by the //).

Speaking of gadgets, I'm using COM:Adiutor too, maybe that could also a suspected "collider"? Regards, Grand-Duc (talk) 04:56, 25 August 2026 (UTC)

I use Auditor, too, and I'm not having the collision myself, so I would rule that one out. Aplucas0703 (talk) 05:25, 25 August 2026 (UTC)

@Grand-Duc Check again and see if its working now. I tried to make a change to its operations to be more isolated from other scripts, but I'm not sure if it worked. Aplucas0703 (talk) 05:37, 25 August 2026 (UTC)

It was a dumb error on my part: I made a copy-paste error that I just spotted. Now, the editing buttonhs show up. Regards, Grand-Duc (talk) 05:54, 25 August 2026 (UTC)

Okay, glad that's solved! You'll have to let me know how it's working now. Aplucas0703 (talk) 06:19, 25 August 2026 (UTC)

I'm confused: what are the circumstances in which you would "update" a license? (Perhaps the problem is that "update" is not really the relevant term; also, the mention of "PD in a foreign count[r]y" suggests that this is not strictly about licenses.) - Jmabel ! talk 05:01, 25 August 2026 (UTC)

@Jmabel Sometimes users upload under the wrong tag or there is some other issue with the license (like it not even having been added to the file). I've also noticed some applying CC licenses to works that are ineligible for copyright (text logos and maps). I might not have been clear in stating that "license" also means PD tags. One example for us is needing to switch out the YouTube license tags (common problem), or a CC license was put under the wrong version. During license reviews I've found the need to switch them out pretty common. Also, some of the PD tags are hard to find and this provides an easier layout than having to manually hunt for the right template. Aplucas0703 (talk) 05:35, 25 August 2026 (UTC)

@Aplucas0703: So "license" here also includes PD tags, and "update" just means "modify". May I also assume that when you say "wrong version" you mean that it is third-party work, and the license stated on Commons does not match the license stated in the source, not that we are somehow second-guessing anyone's licensing of their own work? - Jmabel ! talk 17:53, 25 August 2026 (UTC)

@Jmabel Yes, you have that right. Aplucas0703 (talk) 19:21, 25 August 2026 (UTC)

Any way to enforce need for US copyright tags?

A lot of media on Commons lacks the necessary US copyright tags and only shows a foreign copyright tag. Is there any way we can make it so that way media with a foreign copyright tag appears in a category if it lacks the needed US copyright tag. It really isn't optional, but a lot of people are treating it that way. Aplucas0703 (talk) 00:14, 16 August 2026 (UTC)

Perhaps we could create a version of {{No license since}} called {{No US license since}}, for files which specify that the work is of foreign origin but fail to provide a justification for public domain status under US law, such as {{PD-US-expired}}, {{PD-US-unpublished}}, {{PD-1996}}, or {{PD-URAA-simul}}. – Howardcorn33 (💬) 11:34, 16 August 2026 (UTC)

In many cases files that don't have a US license could have one, so it's largely a housekeeping issue. And even those that should be deleted need a DR and not a speedy because of the peculiarities of URAA (and also because many local wikipedias accept them locally). So, if we want to add a tag it's fine, but I think it'd be detrimental to delete those files after 7 days as we do with files without any license. Friniate (talk) 17:48, 18 August 2026 (UTC)

And by the way, there have been cases in which it was decided that for specific categories (buildings) there was no need to add also a US license template, so for those files we'd need more templates. Friniate (talk) 17:50, 18 August 2026 (UTC)

Then in that case there can be a template that says: "No US Tag Needed" and that lays out exceptions to the need for a US tag. Aplucas0703 (talk) 20:55, 18 August 2026 (UTC)

Yes sure, my point is only that if you want to make mandatory the presence of a US tag everywhere, then we have to create them, because Template:FoP-US and Template:PD-US-architecture for example are only for American buildings and when I tried to use them on an Italian building I got reverted very quickly. Friniate (talk) 22:19, 18 August 2026 (UTC)

Even for photos of buildings, you still need to prove that the photo is in the public domain in the United States. Aplucas0703 (talk) 00:50, 19 August 2026 (UTC)

@Aplucas0703 These were all photos of buildings that fell under the US FoP (or were built before 1990), the only reason why I couldn't use a US tag is that apparently those templates are being used only for American buildings, but that is only because of Commons' categorization reasons, there's no reason to think that an American court wouldn't apply US FoP also towards foreign buildings. If your proposal is to delete PD foreign buildings built less than 95 years ago, then my comment would become a strong oppose. Friniate (talk) 09:43, 19 August 2026 (UTC)

That's not what I just said. As I said, the photo requires a US tag, not the building. Aplucas0703 (talk) 14:55, 19 August 2026 (UTC)

@Aplucas0703 Oh, ok, you meant the copyright of the photographs themselves? That was fine, they were all own works uploaded by Wikimedians. This was the discussion I was referring to: as you can read there was no reason why we should doubt that those buildings (or at least DW of them) are free under the US copyright law, but nevertheless there was no usable US license, so, if you want to enforce your proposal also to PD foreign buildings (and PD foreign stamps, and I'm sure other categories of objects that I can't remember right now) we first need to create new US license templates. Friniate (talk) 15:01, 19 August 2026 (UTC)

I'd be perfectly fine with making that new template for those cases on photos of the work or even applying the {{FoP-USA}} tag if we determine that to be sufficient (even if confusing). Could add a note to it or other related tags stating that it could be applied to a foreign building to show its US status, even if not in the United States. Aplucas0703 (talk) 17:03, 19 August 2026 (UTC)

Yes, yes, my point was only practical: before requiring users to do something we must actually put them in the position of being able to do it ;-) Friniate (talk) 17:19, 19 August 2026 (UTC)

I feel that it might be helpful to have some concrete examples, or specific types of media where there is a particular risk that an item that is PD in the source country might not have that designation respected under US law. Perhaps it would make sense to focus on those areas in particular. Are there, for example, situations where a building photo is FOP in a source country but would still carry copyright risk in the US? -- Visviva (talk) 04:20, 19 August 2026 (UTC)

Say a person uploads Dylan Thomas's poems. They are public domain in the United Kingdom (origin) because it is more than 70 years after his death. It is still copyrighted in the United States because 95 years have not elapsed since publication.

Many corporate works abroad expire after 50 years at their origin countries (The Philippines, for example) but are protected for 95 years in the United States. Aplucas0703 (talk) 04:45, 19 August 2026 (UTC)

And then why restricting this discussion to just US copyright law? Do we need to map every file to assert every copyright laws in the world? Certainly no. IMHO, the copyright for the file from its source is sufficient. Otherwise it will be very complex to upload files in Commons if they must be asserted against hundreds of copyright laws for files whose protection in fact do not originate from most of these juridictions. The licencing tag may/should include its origin (and date of application, plus some other protections like personal rights or ad hoc database rights). Then each licence source can be assessed automatically to see if they match the US copyright (which is not even universal every in US, for some states or territories and in specific domains!). If we need the "US exception", it's only because the file will be hosted by Commons in US (but Wikimedia alerady has exceptions in many projects so that contents for other countries are not excluded). The US "fair use" is also not recognized internationally and considered abusive in many countries as it violates their protected rights. And the fact that US extends the copyright to longer periods than the original copyright is a nuisance in Commons (e.g. contents which have fallen public domain in the Philippines would be blocked in Commons if US law is applied to them and so these contents cannot be used in Wikimedia; the solution is of course to make sure these contents are explicitly stating that they originate from the Philippines that have liberated these contents; any extended protection added by US would impair contents publication from he Philippines, complicating a lot the contributions and free reuse in Commons for the Philippines even if they are perfectly legal there, if some Philippines corporation unfairly makes claims in the US against any reuse of free Philippines content outside the Philippines). For me the licence tag explicitly stating the country of origin and date is sufficient to display a correct licence that will restrict their reuse ONLY in the US, but NOT in the Philippines or elsewhere. The international conventions and treaties are clear about that: the origin is more important than every other rules and this is what Wikimedia should enforce (i.e. NOT the US local laws). IF we enforce the US law only, we immediately create a severe bias in Wikimedia, favoring contents originating ONLY from the US and excluding all other countries.verdy_p (talk) 05:21, 19 August 2026 (UTC)

The discussion restricted to US copyright law because Commons is hosted in the US, which does not apply the rule of shorter term. That makes a US copyright tag a necessity. The fact that it would be unfair for it to be a copyright violation does not change the laws we have to follow. Aplucas0703 (talk) 07:10, 19 August 2026 (UTC)

As Aplucas stated, yes, Commons has to comply with both US copyright law and the law of the source country (if different). This is a fundamental policy of the website as stated in Commons:Licensing. – Howardcorn33 (💬) 08:34, 19 August 2026 (UTC)

Conditional  Support only in cases where the interaction with US law is at high risk, like concerning old/vintage photos (PD-old-expired/PD-old-assumed/PD-US no notice and other similar things). These are typically not authored by Flickr users, Panoramio users, or Wikimedia users themselves. For freely licensed images taken by Wikimedians, Flickr users, or Panoramio users themselves, case-to-case basis. High risk ones that may need US tags include uploaders' images of paintings, drawings, bottle labels, newspaper pages, films/TV programs, logos, and product packaging (I'll leave to other users regarding choice of depicted object needing third tag [which is the US copyright tag]).

For users' images of buildings, I support an exemption in policy requiring compliance to both the US law and the law of the country. Instead, for users' own images of buildings, the copyright law of the country of the building's physical location is solely taken into account. Two main reasons. One thing, you'll complicate things to users in countries where the local laws are of strong emphasis, like Filipino users. An average Pinoy user does not care of the building's status in the US, and instead defaults to the building's status here in the Philippines. Another thing, there is virtually zero interaction risk under US law in exploiting buildings. The US FoP law came from AWCPA, which garnered criticisms from the minority group of scholars and architects like Architect Clark Thiel and lawyer Jane Ginsberg. They claimed the amendment law wasn't strongly protective of architect's extended and moral rights. However, this is actually advantageous, in the sense that Commons can exploit buildings with no conditions. The US FoP (Sec. 120a) does not mandate attribution of architects, nor it does mandate that buildings' image integrity are respected. Therefore, I do not see the need to mandate PD/FoP US architecture tags to images of copyrighted buildings from yes-FoP countries as well as images of public domain buildings in all countries, unless there is a major change in US law that requires architects to be attributed and the buildings in the images to be depicted as they are found by the photographers or re-users. This hypothetical change won't happen soon in my opinion. For images of buildings by the Commons/Flickr/Panoramio users themselves, the photo creators' license tags as well as the specific YesFoP country's FoP tag or PD tag suffice. Use only both {{FoP-US}} and {{PD-US-architecture}} on images of buildings physically located on US soil (including American external territories like Guam, Northern Marianas, and Puerto Rico). Images of buildings are at very low interaction risk under US law (again, because: no need for attribution, no need to respect the integrity of the buildings, no need to meet the "depicted building should be as it is found there"). JWilz12345 (Talk|Contributions) 15:49, 19 August 2026 (UTC)

Some more clarity, what I meant in the "very low interaction risk" with US law, is that the lack of a specific US tag to "own work" images of copyrighted buildings from yesFoP countries or public domain buildings of all countries (own work images taken by Wikimedians, Flickr users, Panoramio users) outside US does not endanger re-users within the US. Without the US specific tags on images of Tokyo Skytree (supposedly eligible for FoP-US) or the Roman Colosseum (supposedly eligible under PD-US-architecture), all Americans can freely exploit these in any way. Are they at risk under US law? None, because Sec. 120(a) of the US copyright law does not mandate citing the names of the architects or respecting the visual images of the buildings. Furthermore, there are no strong moral rights for architects under US law, as opposed to those in most of the other countries. Building owners in the US can freely disfigure the facades of, manipulate the appearances of, or even destroy the buildings they own without clearancces from the architects, something that the Ukrainian or Saudi (2026) law forbid. No strong moral rights for architectural works under US law, and no conditions under Title 17/Sec.120(a). This is why I see the users' own work images of yes-FoP countries' buildings or all countries' public domain buildings as practically under zero risk of interaction with US law. JWilz12345 (Talk|Contributions) 16:05, 19 August 2026 (UTC)

@JWilz12345 I think we should just make a tag variant that says its an architectural work in the public domain in the foreign country and explains that we don't apply US copyright to those buildings (for listed reasons) and that it is thus okay for the United States. That way if we make a category showing which files are missing a US copyright tag with an applied foreign tag, it can be removed from the backlog needing processing. Aplucas0703 (talk) 17:30, 19 August 2026 (UTC)

I'm not at all getting why people think we need a tag that lets us say that a particular building does not raise issues with U.S. copyright law, given that no building raises issues with U.S. copyright law. - Jmabel ! talk 01:22, 20 August 2026 (UTC)

Agree completely on this point. At most, a short hat-note at the top of the parent category "Buildings in the United States" explaining that situation. Tagging every single building in the USA seems a substantial waste of effort without benefit. -- Infrogmation of New Orleans (talk) 01:35, 20 August 2026 (UTC)

@Infrogmation I don't think anyone has proposed requiring the tag on all (or any) US buildings? Aplucas0703 (talk) 01:41, 20 August 2026 (UTC)

@Jmabel Most foreign copyright tags require a US copyright tag; this satisfies that for potential maintenance purposes being proposed here. Aplucas0703 (talk) 01:36, 20 August 2026 (UTC)

@Aplucas0703 I propose making an exemption to the Commons rule that mandates all foreign copyright tags requiring US copyright tags. In the case of images of modern buildings found in countries with suitable FoP rules and images of public domain buildings in all countries outside US, no US copyright tag is required since there is very low-risk of issues under US law for wanton exploitations of photos of buildings. Any user living in the US do not need to be notified of US copyright status of the buildings hosted here.

Re: problems faced by maintenance, I suggest all maintainers should focus on high-risk group of works, most of which are not wholly produced by the uploaders (or Flickr/Panoramio users) themselves. As I said, the high-risk tier includes old/vintage photos, paintings and drawings, and pages of books/novels/documents, and stills or screenshots of video games/TV broadcasts/films. However, I'd consider non-Japanese logos as low-risk too and we do not need to consider US status, since COM:TOO US is clear that US has a very high bar of threshold of originality for logos. Japanese logos might be under medium-risk since COM:TOO Japan implies a ToO slightly higher than that of US ToO standard.

So, I'd  Support two types of works that exempt the requirement of a US copyright tag: "own work" photos of copyrighted buildings from yesFoP countries or PD buildings of all countries outside US (taken by Wikimedia/Flickr/Panoramio users), and non-US logos except Japanese logos. JWilz12345 (Talk|Contributions) 02:29, 20 August 2026 (UTC)

We can fix this problem entirely by just setting up the category to check to see if at least one license is valid in the United States. This could mean a US public domain tag or any other copyright license tag (incl. Creative Commons, etc.) that is valid for the United States. Since photos of the structures still need a valid tag for the photo, this takes care of that problem entirely. Only photos lacking a license valid in the United States would appear.

Ideally we could enforce this requirement on all new uploads automatically just like we do for uploads missing any license. If we wanted we could create a new delayed speedy deletion tag for missing a US license as originally suggested. For older uploads it could provide a 30 day (or even 90 day) period to repair the issue and a shorter period of 7 days on new uploads. Aplucas0703 (talk) 04:06, 20 August 2026 (UTC)

Besides buildings, there's also the issue of foreign works not protected in the country of origin (for example foreign stamps), for whom we do not enforce US copyright. So we'd need first to do other templates similar to Template:Not-free-US-FOP.

I  Oppose a speedy deletion criterion, there are too many works without a US license, the vast majority of whom I expect to be fine (almost all the PD-old ones for example), such a requirement would deprive us of perfectly fine images because of an housekeeping issue. Isn't there a way to automatically block the upload of new files without a US-license template? Friniate (talk) 09:33, 20 August 2026 (UTC)

@Friniate I disagree entirely blocking all new uploads just because of the lack of US copyright template. As I said, there is absolutely no need for US copyright tags on "own work" images of buildings (except those physically located in the US), and possibly non-Japanese logos (since based on my experience on reading CRT pages it seems Japan has a higher bar of ToO compared to US ToO). Remember we seem to forgot the whole point on what audience WikiCommons serves. WikiCommons is meant to serve readers and reusers globally, not just Americans alone. Adding too many tags to low-risk images (users' own images of buildings, non-Japanese logos) is a sign of excessive bureaucracy disguised as compliance to the US law, despite the fact that US law is clear on low-risk works. No American will ever be sued by wanton exploitation of buildings, and architects do not have moral rights over American public users exploiting photos of their works (as long as 17/Sec 120 stays the same for all time). Confine only the use of multi-copyright tags (perhaps third, fourth, fifth and so on representing US copyright status) to, as I repeat, high/medium-risk works or objects, such as paintings, old photos, and others that I mentioned above. For copyrighted public monuments that are usually objects of w:en:Wiki Loves Monuments contests of yes-FoP ones, {{Not-free-US-FOP}}. JWilz12345 (Talk|Contributions) 10:59, 20 August 2026 (UTC)

@JWilz12345 I was just trying to avoid a requirement involving speedy deletions. Blocking automatically the uploads seems better to me than deleting everything after 30 days, and with speedies that are even untraceable so we'll never be able to undelete those images when copyright expires. Maybe we can block the uploads but with an exemption for certain categories, I don't know, but I certainly prefer any solution that avoids unnecessary speedy deletions. Friniate (talk) 11:18, 20 August 2026 (UTC)

Moreover blocking uploads will encourage hopefully the uploaders to seek help at village pumps, so that we can help them. Friniate (talk) 11:20, 20 August 2026 (UTC)

@Friniate noted. As I said, I suggest exemptions to at least two low-risk works or objects: a) modern buildings from yesFoP countries and public domain buildings from all countries outside the US (provided that the photos are own works of Wikimedia, Flickr, and/or Panoramio users), and b) non-US logos except Japanese ones. For others, I do not oppose having US copyright tag as a mandatory requirement. For example, Japanese logos must also be PD in the US, since Japanese ToO level is higher than that of the US. JWilz12345 (Talk|Contributions) 11:23, 20 August 2026 (UTC)

Yes yes, I was not disagreeing with you, I'm just trying to find a solution that doesn't throw out the baby with the bathwater. Friniate (talk) 11:29, 20 August 2026 (UTC)

Once again, we're getting way too caught up on a single thing here. A photo of a building ALWAYS requires a license valid in the US because ALL PHOTOS require valid licenses in the US. If it doesn't have a single valid license in the US, that's a problem. When a work is ineligible for copyright in its home country, the tag does not say that it is necessary to have a US tag, and therefore the tag counts as valid in the US. Aplucas0703 (talk) 15:38, 20 August 2026 (UTC)

When I process old files, they were originally under German copyright, which is often stricter in protection lengths --PantheraLeo1359531 😺 (talk) 18:36, 20 August 2026 (UTC)

Well no. We do not need to have a US tag for all buildings. We only need a US tag 1. for public domain documents, and we do not need one for files under a Creative Commons license; 2. for derivative works (e.g. artworks). Yann (talk) 19:33, 20 August 2026 (UTC)

@Yann We don't upload buildings to Commons. We upload photos of them, and all photos require a tag valid in the US, whether it's a US public domain tag or Creative Commons tag (which is a copyright license valid in the US). Aplucas0703 (talk) 19:51, 20 August 2026 (UTC)

Sorry, but no. We do not need a US tag for pictures of buildings, because 1. old buildings are not under a copyright in USA, 2. new buildings are under a freedom of panorama exemption. Let's not create unnecessary bureaucracy when it is not needed. Yann (talk) 20:15, 20 August 2026 (UTC)

@Yann So can I just start uploading other people's photos of buildings posted on Flickr today without their permission then? Aplucas0703 (talk) 20:28, 20 August 2026 (UTC)

I think that it very much depends if we want to track also DWs or not. If we say "if there is a PD-own, it is sufficient", then we won't have the issue with buildings, since all the photos will have a license (for the photograph) that will be valid also in the US. But that for example won't solve the issue with foreign PD stamps and other categories of objects that are not protected in their countries of origin and on which we don't enforce US copyright. So you'll need a template for these cases nevertheless.

Anyway the biggest issue IMHO is how we intend to oblige people to use US license templates. Friniate (talk) 20:35, 20 August 2026 (UTC)

That's my point. Any photo on Commons has to have a license valid in the US (for the photo itself), so the problem vanishes. We're not trying to catch FoP issues here, just ones where someone failed to put a license for the file.

As for how we oblige, I'd say like any other file. A notification to the user telling them that they need to add a US tag and why and directing them to a list of options they can choose from. If they uploaded with a foreign copyright tag they can certainly learn how to add a US tag. Aplucas0703 (talk) 20:48, 20 August 2026 (UTC)

@Aplucas0703 I see two problems:

1. You're proposing to enforce this policy also towards existing files if I understand correctly. A user who is inactive since, let's say, an year, won't see your warning and we'll end up deleting perfectly fine files.
2. A file without any license is likely to be copyrighted. In most cases it's a photo taken from the net without any care about the copyright situation. That's why the current system for files without any license makes sense. A file with a valid license for the country of origin but without a US license it's the opposite: it's a file that in most cases is free (even in the US). So IMHO creating a system under which we'll automatically speedy delete it it's not worthy. So I agree with a warning (even added by a bot), both on the file and on the user's talk page, but then I think that we still need an human to review the situation and open a DR, without any automatic (or semi-automatic) system.

Friniate (talk) 11:03, 21 August 2026 (UTC)

 Comment There are a few separate issues that have been raised above, but have been jumbled together in a way that makes this very hard to discuss.

1. There are important differences between a license and a PD tag. A license is virtually always worldwide. It would be very difficult to construct a scenario where a piece of intellectual property has a license acceptable to Commons that is not valid in the U.S. A PD tag, on the other hand, is always specific to some jurisdiction or jurisdictions.
2. There are a small number of scenarios where Commons has agreed to host classes of images that are not entirely clean in terms of U.S. copyright law. Most of these have had lengthy discussion and reached a consensus. Yes, these are exceptions to our usual policy and yes, they smack of an Exemption Doctrine Policy that Commons is not supposed to have, but presumably if the Foundation had a problem with these decisions we would have long since heard about it, and if they represented a real-world problem it would have long since manifested itself in the form of a series of DMCA takedown notices. There are two cases I can think of, both alluded to above; there might be something else that I'm not thinking of.
   • Photographs of 2-dimensional or 3-dimensional artworks where permitted by the relevant local FoP laws.
   • Reproductions of currency and/or postage stamps of countries that permit that.

In all of these cases, we will host the image even if the artwork/currency/postage stamp is, or might be, copyrighted in the U.S. If the image in question is more than just a faithful reproduction of a two-dimensional work, then the derivative work needs a license or (rarely) a US PD tag. About the only case I can think of in which a US PD tag is likely is if the derivative work is a photo (or video, etc.) by a U.S. government employee working abroad.

Obviously, for these artwork/currency/postage stamp cases, no "clean" U.S. tagging is possible, especially not one that would give a clean grounds for commercial reproduction. And that's OK. - Jmabel ! talk 04:56, 21 August 2026 (UTC)

The issues here have gotten far too jumble to navigate at this point. The original question was if we could create the maintenance tools and deletion tags for uploads missing a US-valid license, and it has ballooned well past that original question now. Aplucas0703 (talk) 14:53, 21 August 2026 (UTC)

I still think we can do something where we focus on making sure at least one license on each file is valid in the United States. Aplucas0703 (talk) 15:38, 25 August 2026 (UTC)

Assuming your proposal makes sense, I still don't understand it (given some of the cases noted above). If your "at least one license on each file is valid in the United States" is taken literally, then every file that is simply marked with {{PD-auto-expired}} or {{PD-ineligible}} would be viewed as a problem, because there is nothing to license, so no license is involved. So presumably you mean something else. And are you saying that we would have to argue a DR for every file in the two classes I mentioned above (about FoP and currency/stamps) or would there be some way they are accounted for? You can't proceed on a large project with a hand-wave for a definition. - Jmabel ! talk 17:45, 25 August 2026 (UTC)

They are valid tags in the US, aren't they? If a tag is sufficient to indicate its copyright status in the US, then it suffices. Also, I'm not understanding why PD-auto-expired would be an issue when it explicitly includes the US copyright status? Aplucas0703 (talk) 18:43, 25 August 2026 (UTC)

Absolutely the are valid tags. And equally absolutely, they are not licenses.

But that wasn't my main point. My main point was about the two cases I mentioned above (about FoP and currency/stamps). - Jmabel ! talk 05:36, 26 August 2026 (UTC)

Regardless of FoP rules, the photo itself still needs to be licensed or in the public domain. Most currency and stamps already have a unique copyright tag so it shouldn't really be a problem (just classify those tags as US valid). Aplucas0703 (talk) 17:31, 26 August 2026 (UTC)

Photos by day by Australian state

~2026-43571-17 (talk · contributions · Move log · block log · uploads · Abuse filter log) block user has been creating subcategories for Australian states by day, despite most of these only ever having a very small number of photos. This seems excessive to me, and makes the daily categories harder to navigate. I know that some, such as Category:Australia photographs taken on 2026-02-08, have lots of photos, but as the vast majority of those are taken in the same state (i.e. Mapillary photos in South Australia) I don't think that diffusing is going to help. (I've left a message for the user on their temp account talk page.) Sam Wilson 23:03, 17 August 2026 (UTC)

There seems to be a lot of those:

Category:Photographs by date by country. I don't think that should be useful, you should be able to derive this from structural data... But using structural data is not easy... Nux (talk··dyskusja) 23:32, 17 August 2026 (UTC)

That kind of intersection category is not useful. If the TA continues, I will take administrative action. Pi.1415926535 (talk) 23:56, 17 August 2026 (UTC)

Thanks! I forgot to mention, one big source of these categories is {{Taken on}}, and the |location= parameter there specifically says it's for the country. Sam Wilson 00:37, 18 August 2026 (UTC)

Then perhaps the template should be modified to not do that? Categories by country by date provide extremely little practical value, especially for modern photos. There is probably more time being spent by users maintaining these categories than time spent browsing them. Omphalographer (talk) 00:45, 18 August 2026 (UTC)

I don't personally like the country-by-date categories, but there's some argument for their utility. Sub-national-division-by-date categories, like these categories being created by the TA, are almost never useful. Pi.1415926535 (talk) 00:54, 18 August 2026 (UTC)

@Omphalographer: Whether we should have the country-by-date categories is a separate question, I think. This is about the sub-country divisions, which certainly if the country ones are over the top then they also are. But anyway, it seems like we're all in agreement, and User:~2026-43571-17 seems to have given up for the time being (although there's of course now lots of clean up to do). Sam Wilson 03:33, 18 August 2026 (UTC)

@Pi.1415926535: They're still doing it, and they keep reverting me on File:Anglesea Fremantle 01.jpg. Sam Wilson 12:57, 18 August 2026 (UTC)

I support some sort of administrative action on this TA. It appears they are unwilling to be collaborative with others, since they are refusing to engage on their talk page or here in this thread, while continuing the behavior in question. Thanks. Tvpuppy (talk) 21:11, 18 August 2026 (UTC)

@Samwilson: I've blocked the underlying IP from page creation. Let me know if anything else is needed. Pi.1415926535 (talk) 16:53, 19 August 2026 (UTC)

@Pi.1415926535 there're lots of this kind of stuff like Category:Photographs of Main-Taunus-Kreis by date Category:Wertheim photographs taken on 2007-08-10. see who created those? RoyZuo (talk) 18:06, 20 August 2026 (UTC)

I would rather see the by-day categories stay at the national level. I could imagine (I haven't looked) that there might be enough photos for Sydney or Melbourne to handle those specially, but I don't think there is any gain in a breakdown by state, other than a dopamine hit for the person categorizing them.- Jmabel ! talk 00:03, 18 August 2026 (UTC)

 Done I cleaned up Category:Australia photographs taken on 2026-02-08 --PantheraLeo1359531 😺 (talk) 17:36, 20 August 2026 (UTC)

users handling this (with regard to australia) are essentially creating different and unwritten rules.

as i pointed out above, thousands of granular categories splitting to the town level exist, e.g. Category:Photographs of Hockenheim by date Category:Photographs of Rhein-Neckar-Kreis by date. RoyZuo (talk) 09:58, 26 August 2026 (UTC)

Updating authorship of 1.7 million files

Wine production (example of final product of this work)

We have had folks from UN agencies request that we add them to the author line when they are providing the underlying data for an OWID graph. We would like to make a bunch of edits like this.

Basically replacing the author "Our World in Data" with the Source line as listed in the accompanying reference such as this which is "AQUASTAT - FAO's Global Information System on Water and Agriculture, FAO, via World Bank (2026) – processed by Our World in Data". Any concerns? Doc James (talk · contribs · email) 17:25, 20 August 2026 (UTC)

@Doc James: Is their request about the author, or the required attribution, or both? - Jmabel ! talk 05:07, 21 August 2026 (UTC)

The plan is to adjust the author line like this... so we mention the source of the data https://commons.wikimedia.org/w/index.php?diff=1262506461 Doc James (talk · contribs · email) 05:13, 21 August 2026 (UTC)

@Doc James: That isn't what I asked. I'm trying to understand if this lengthy string is now requested by the relevant UN agencies as the required attribution for the CC licenses. - Jmabel ! talk 06:13, 21 August 2026 (UTC)

Their request is reasonable IMO. Currently attribution of them is two clicks rather than one click away. So I have no issue with adding this. Doc James (talk · contribs · email) 06:18, 21 August 2026 (UTC)

That still doesn't answer my question. So I guess I'll just get to what I am driving at, without knowing whether it is relevant or not. If they want this as an attribution, and they are not just asking for this in the "author" field on Commons, I strongly suggest that we also add it explicitly as an attribution parameter in the template for the CC license for the file. Otherwise, reusers are very likely to get this wrong. - Jmabel ! talk 06:40, 21 August 2026 (UTC)

Not sure what you mean? Can you show me an example? Doc James (talk · contribs · email) 06:46, 21 August 2026 (UTC)

Author is: who is the copyright holder (by ownership or by creation). Attribution: how and who do you (per the license) want to be advertised for credit.

What Jmabel is trying to determine, is which of these need needs to be updated. One of them, or both. The copyright of the graph image is with OWD (if it even is copyrightable as a pure data visualization), the pure data is not copyrightable (in most jurisdictions). So they just want the data source to be known to people (as part of their license requirement, irrespective of copyright owners). So that is attribution. In practice, we treat our own author field as a random data collection (not just copyright owner, but also sourcing and sometimes attribution or an entire Wikidata subgraph rendering) so we might as well update it there as well. —TheDJ (talk • contribs) 08:52, 21 August 2026 (UTC)

The author is not necessarily the copyright holder. We have many images with a named creator, whose copyright is held by their employer. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:52, 21 August 2026 (UTC)

The license is CC-BY and the version of that deed linked to states You must give appropriate credit, provide a link to the license, and indicate if changes were made.
it then also states No additional restrictions — You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.
So a technical reading of this is that care should be taken to define precisely who the creator (author) was and that should be presented in a way that is unambiguously the legal attribution required. The implication is that someone could be sent take down notices if they do not get that attribution precisely correct. Additional information like any changes or who processed it later can be added but that's not the legally required attribution. My guess is that is what is wanted, fair credit to later processors but not legal constraints as those changes are intentionally minor.

There's a potential twist here (feel free to ignore this observation, it's getting hypothetical but it illustrates possible downstream questions) as there could be cumulative attributions (despite in theory the license ruling them out) depending on whether changes made infer enough creativity to require their own attribution. If this is what is wanted because the formats of charts is thought to be creative work by those that design and implement them, that's fine, but we might need to spell out the different parts to the attribution that would be legally required. A twist that probably does not exist here is that additional work does not have to have the same copyright, so that could be less restrictive, like CC0 or more like CC-BY-SA. Ugh, there's another twist around data, but that's a can of regional copyright worms that I don't want to open. --Fæ (talk) 08:33, 21 August 2026 (UTC)

So both OWID and the UN agencies would be happy to have both listed in the author line on Commons as they see themselves both as contributing to the authorship of these graphs. What is legally required, I am not sure. But regardless of what is required I think adding them both to the author line is reasonable per User:TheDJ explanation "we treat our own author field as a random data collection (not just copyright owner, but also sourcing and sometimes attribution" Doc James (talk · contribs · email) 17:32, 21 August 2026 (UTC)

@Doc James: With 1.7 million files, you definitely want to get these changes right the first time, whatever "right" may mean. Using your example of File:Agricultural water as a share of total water withdrawals, World, 2022 (cropped).svg, and going by the above, it is possible that besides the edit to the author field they would really want the license tag to read "{{cc-by-4.0|attribution=AQUASTAT - FAO's Global Information System on Water and Agriculture, FAO, via World Bank (2026) – processed by Our World in Data}}", which produces:

If that's what they want, let's make sure we get it right in a single pass through this large set of files. If you're not sure, then it would be worth asking again before a massive batch job starts. - Jmabel ! talk 20:39, 21 August 2026 (UTC)

Thanks that makes sense. Will reach out. Doc James (talk · contribs · email) 20:43, 21 August 2026 (UTC)

Is the intention to use the exact same text on all 1.7 million files? Or is "AQUASTAT - FAO's Global Information System on Water and Agriculture, FAO" just one example of several? If the latter, how many variants are there? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:55, 21 August 2026 (UTC)

No, the plan is to go to the source in question for the image in question and use either "Data source" in the caption or "Source" in the metadata on OWID. See here for example[6] were it would be "National statistical organizations and central banks, OECD national accounts, and World Bank staff estimates (2026) – processed by Our World in Data"

We have already updated the OWID SVG upload tool to do this going forwards. Doc James (talk · contribs · email) 20:57, 21 August 2026 (UTC)

You haven't really answered what I asked.

I also note that it appears that the image in your first example is a crop, and that the text you want to include is what was cropped from the original. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:12, 21 August 2026 (UTC)

Q: "Is the intention to use the exact same text on all 1.7 million files?" Answer: "No". Q: "how many variants are there?" Answer: "Lots I imagine, likely a few housand anyway" Doc James (talk · contribs · email) 21:37, 21 August 2026 (UTC)

@Doc James: My apologies for adding to the already impressive level of pedantry in this thread, but it seems to me that the UN agencies should be properly credited as the source of the data, not as authors of the infographics, which were created by Our World in Data. These are very different things from a copyright perspective, and I think it would be unfortunate to muddle them together. What's worse is that the wording in your example seems to give primary attribution for the infographic to the UN agency, while listing Our World in Data almost as an afterthought "– processed by Our World in Data". From a copyright perspective, Our World in Data is probably the only copyright holder for that graphic and thus the only party that technically needs to be attributed for the CC license. In my opinion, it would make much more sense to list the UN agency explicitly as the source of the data in the author or source fields (or even using the 'other fields' field) and leave the licensing template unchanged (or if we do want to set an explicit attribution, set it to 'Our World in Data'). Do you think that would be acceptable to the agencies in question? Nosferattus (talk) 10:24, 23 August 2026 (UTC)

Nosferattus we are proposing using the exact same wording that OWID uses. OWID list ways to cite their graphs and they use "AQUASTAT - FAO's Global Information System on Water and Agriculture, FAO, via World Bank (2026) – processed by Our World in Data" under "How to cite this data" as one recommended option.

Whatever we propose needs to be doable by a bot, so needs to have a clearly defined method to it. Doc James (talk · contribs · email) 21:32, 24 August 2026 (UTC)

@Doc James: Yes, I suppose that is fine for how to attribute the data, but it is not fine for attributing the infographic. Those are two different things. To keep it simple, I suggest attributing the data how it is attributed on the OWID pages (within either the author or source fields) and attributing the infographic to "Our World in Data" in the licensing template. Nosferattus (talk)

User:Jmabel, User:TheDJ, User:Pigsonthewing, User:Fæ, User:Nosferattus do we have consensus on what you want me to do? Is an update like this[7] reasonable and can we go ahead? Doc James (talk · contribs · email) 07:33, 26 August 2026 (UTC)

No, please see my latest comment above. Here is an example of what I have in mind (doesn't have to be exactly like this): [8]. Nosferattus (talk) 18:43, 26 August 2026 (UTC)

Okay will try to do this[9]. Doc James (talk · contribs · email) 23:05, 26 August 2026 (UTC)

I don't have any particular thing in mind. Besides what Nosferattus mentioned, what I'm concerned with is that before you start a big batch job, you circle back to whoever it is who asked for this, make sure they understand that both the "author" field and the "attribution" field exist, and make sure that the edits you are about to make on each are acceptable to them. We don't want to have to edit 1.7 million files twice. - Jmabel ! talk 21:20, 26 August 2026 (UTC)

Sure, have followed up. The UN agencies and OWID are both fairly large organizations. Doc James (talk · contribs · email) 23:23, 26 August 2026 (UTC)

I again note that it appears that the image in your first example is a crop, and that the text you want to include is what was cropped from the original. Are all 1.7 million images similarly cropped? Why? Do some retain the requested attribution embedded in the image? If the latter, is the intention still to edit them? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:03, 26 August 2026 (UTC)

Q "Are all 1.7 million images similarly cropped?" A: No. Q "Why?" A: Because the cropped images are used in a different way than the uncropped ones. See here as an example[10]. The cropped images is what is displayed directly on Wiki, the uncropped ones are used within the visualization when the play button is pressed. Q"Do some retain the requested attribution embedded in the image?" A: Yes 99+% still include it embedded in the image Q: "If the latter, is the intention still to edit them?" A: Yes it is, because clearer metadata is still useful. Doc James (talk · contribs · email) 23:09, 26 August 2026 (UTC)

Angel with devil or demon

Do we have a category for an image of an angel with a devil or demon? I would think something like that should be a parent to categories like Category:Saint Michael beating the Devil but also to images like File:Cabin in the Sky (1943 film poster).jpg, which is actually why I thought of it. - Jmabel ! talk 00:47, 22 August 2026 (UTC)

There's also the popular shoulder angel/devil trope a la file:CaptMarvelAdventures31.jpg... Arlo James Barnes 04:07, 22 August 2026 (UTC)

Yes, the Cabin in the Sky example is like that, even if they are not on the shoulders. - Jmabel ! talk 04:22, 23 August 2026 (UTC)

I decided to pluralise it, but otherwise followed your suggested name: category:angels with devils or demons Arlo James Barnes 18:53, 26 August 2026 (UTC)

Demolition or Demolitions - in "country name"?

I accidentally created Category:Demolition in the Philippines without knowing that Category:Demolitions in the Philippines exists, using the Japanese categories as the template. Category:Demolition in Japan. What is the standardized category naming for demolition/s? JWilz12345 (Talk|Contributions) 08:25, 22 August 2026 (UTC)

I'd lean toward "demolition" (the activity) rather than "demolitions" (individual projects of demolishing things). For example, a demolition firm or demolition equipment would fit under the former, but not the latter. - Jmabel ! talk 04:24, 23 August 2026 (UTC)

There must be unified rules for all countries' categories. JWilz12345 (Talk|Contributions) 05:14, 23 August 2026 (UTC)

You may want to check Demolitions in the United States and Demolition in the United States, and Demolition by country as well as Demolitions by country. Both category trees exist and are differently populated, so this might be complicated.

Either, this is intentional and follows a rule that I may not have grasped immediately, or this is accidental and there should only be one of them, standardized and the other branch as a redirect like in Japan. It's not my area of expertise, so I leave the creation of the CfD to others. --Enyavar (talk) 05:42, 26 August 2026 (UTC)

Policy on AI-generated image descriptions?

So this is a twofold question:

• Does Commons have a policy on using AI to generate/edit descriptions of image or other related text? COM:AI seems to be strictly limited to images.
• If not, should it?

Based on searching, egregious AI usage is nowhere near as widespread as it is on enwiki, but it's not nonexistent either. — Gnomingstuff, 24 August 2026

Well, even if Commons by itself does not regulate AI generated texts (yet), including them on file pages will probably run afoul of other projects who ban such data, making the files formally not usable there (at least not e.g. in the German Wikipedia, see de:WP:KI). Regards, Grand-Duc (talk) 03:49, 25 August 2026 (UTC)

To my knowledge this is not something that has come up at least on enwiki, everyone is swamped with articles and I don't know of anyone who's even looking at the File namespace including myself Gnomingstuff (talk) 00:03, 26 August 2026 (UTC)

I don't think there is (or should be) a hard-and-fast rule. If you run a third-party image through Google Lens and it says what it "thinks" is there, and you validate that, there is no deep reason not to cut-and-paste relevant portions. If you post some quasi-essay, the problem is pretty much the same whether you wrote it your self or it was written by generative AI. At least in the U.S., there is no copyright issue. Do you have any examples where this sort of thing has been a problem? - Jmabel ! talk 05:43, 26 August 2026 (UTC)

about Deletion requests/File:Homo Eternus vol. 1 - capa do álbum.jpg

Please. reopne the subject about: Commons:Deletion requests/File:Homo Eternus vol. 1 - capa do álbum.jpg. The Homo Eternus cover is mine. I am the author of Homo eternus, and I inserted in my "Gazy Andraus" in Wikipedia. So, it does not against authoral rights. I ask you to allow insert again the cover. — Preceding unsigned comment added by Gazy Andraus (talk • contribs) 03:17, 26 August 2026 (UTC)

@Gazy Andraus: we don't do this by reopening a DR once it is closed. COM:VRT explains what you have to do to clear up the authorship issue via confidential correspondence. Once you've cleared that up to their satisfaction, a member of the VRT will undelete the file. - Jmabel ! talk 05:48, 26 August 2026 (UTC)

Rather than the VTRS, if as the author you control the cover of the book, this is more often up to the publishing contract, then you can instead include the same copyright release like CC-BY-SA on a website you have control over. The difference with VTRS is that it is not public, but there seems no need for confidentiality in this case. Fæ (talk) 09:00, 26 August 2026 (UTC)