Commons:Village pump/Proposals/Archive/2025/10

The Apache License

The Apache license, like the GFDL license, requires that a copy of the license be included with any use of the licensed material. This makes the material unusable for print applications and difficult for most on-line applications. We have severely limited the use of the GFDL license, see Commons:Licensing#GNU_Free_Documentation_License. We should similarly restrict the use of the Apache license. .     Jim . . . (Jameslwoodward) (talk to me) 12:46, 14 October 2025 (UTC)

•  Support § 4a of the Apache legal text appears quite similar to § 4H of GFDL-1.3, used in {{GFDL-1.3}}. Due to a similar argument, there was an accepted proposal to phase out GFDL for new uploads with few exceptions, see Commons:Village pump/Proposals/Archive/2018/08#No longer allow GFDL for some new uploads. I do not see any reason why should treat {{Apache}} differently from {{GFDL-1.3}}. --AFBorchert (talk) 12:52, 14 October 2025 (UTC)
•  Support not accepting the Apache license for new uploads. Yann (talk) 14:31, 14 October 2025 (UTC)
•  Support Glrx (talk) 15:37, 14 October 2025 (UTC)

 Strong oppose This is making a fool of the project, we will be a laughing stock for all free software developers and it is an insult to all those who worked to support free open source software.

• This is one of the most famous and widely used free software licenses which we need.
• There are many situations where share alike or giving attribution at all is not practical, all the CC BY licenses require listing all the modifications you made which is not practical, we cannot just keep banning all the restrictions because they are not practical sometimes.
• For example France decided that rule of the shorter term does not apply for US works that expired due to no renewal [1], so {{PD-US-not renewed}}, {{PD-US-no notice}} etc may not be in the public domain at all outside the US and totally impractical to use, no one suggested to stop using these tags.
• GFDL is a documentation license, it was never practical for images, Apache is a software license, they are not the same at all. No one is putting photos under Apache, when developers release their software under a free license we need to be able to use it and no one uses CC licenses for software because they are not suitable, see the Open Source Initiative and the Free Software Foundation advise against it, even Creative Commons suggests using software licenses
• Many software licenses require you to include the full license text, which is not impractical at all for software applications, they did it so that if you print out the code or something you have to include the license.
• Finally on the website for the license, it suggests at the bottom for using one file under the license you do not need to include the full license text but just a shorter version with a link to the license.

 $999$REAL 💬 ⬆   16:34, 14 October 2025 (UTC)

The Apache license is OK for software, but Commons is not hosting software. So we could make an exception "only software could be uploaded under the Apache license." Yann (talk) 16:48, 14 October 2025 (UTC)

But we are hosting screenshots, icons, and logos of softwares. Perhaps limit it to only disallow photographic media? --Jonatan Svensson Glad (talk) 17:25, 14 October 2025 (UTC)

•  Oppose The last few paragraphs of this suggest an actual copy of the license is not needed but rather just a link, which we already comply with. --Bedivere (talk) 17:37, 14 October 2025 (UTC)

• OK. If a link is sufficient, there is no reason to disallow this license. Yann (talk) 17:48, 14 October 2025 (UTC)

• Sorry but a link is not sufficient. That section begins with the statement: Include a copy of the Apache License, typically in a file called LICENSE, in your work. In case of a software package, the license does not have to be included in every file using the Apache license. But you have to include the full license nonetheless within the package, just not to every included file. This does not help us as we work with individual media files only, not packages. --AFBorchert (talk) 18:04, 14 October 2025 (UTC)

  No, that is for when you want to release the full package under the license, which you do not have to do because Apache is not share alike, so you can use it in MIT, GPL or even closed source projects, etc, in which case you just need to indicate specifically which files are under Apache.  $999$REAL 💬 ⬆   18:24, 14 October 2025 (UTC)

• It is quite simple. If a software package includes any Apache-licensed file, a full license text must be included as well, usually as a separate file. --AFBorchert (talk) 19:37, 14 October 2025 (UTC)

 Support I think for original new content we should even only accept CC 4.0 licenses and CC0. We of course need to accept Apache license for software screenshots like we do with GFDL/GPL. GPSLeo (talk) 17:40, 14 October 2025 (UTC)

 Oppose We already kick ourselves in the ass with the strictest possible interpretation of copyright, what's the use of adding additional restrictions? Entire operating systems are Apache licensed, this is absurd. -Nard (Hablemonos)(Let's talk) 18:09, 14 October 2025 (UTC)

 Question Is anyone actually using the Apache license for unrelated purposes (i.e, that are not derivatives of works already under the Apache license)? I can't say I've seen any. Pi.1415926535 (talk) 18:44, 14 October 2025 (UTC)

These examples exist and are easily found. Some finds: File:IPv6 CARE Mechanism.PNG, File:Ocean.jpg, File:Winzer classic1.JPG, File:Winzer classic2.JPG, File:Bärlauchlino1.JPG. --AFBorchert (talk) 19:47, 14 October 2025 (UTC)

Sorry, I should have clarified - is anyone currently uploading unrelated files using this license? All the examples I could find were >7 years old. If no one is currently doing it, then it's probably a non-issue, but also it wouldn't affect any current users if we did prohibit it going forward for unrelated files. Pi.1415926535 (talk) 20:21, 14 October 2025 (UTC)

 Oppose This could prevent/restrict the uploading of files under Apache license. I am aware that reuse comes with some challenges, but I don't think we should introduce more restrictions that go far beyond what is required by law (in this case). If possible, the advantages of other licenses should be highlighted, but I am against a ban or restriction of Apache-licensed files --PantheraLeo1359531 😺 (talk) 19:53, 17 October 2025 (UTC)

• The largest, widely approved open source software licenses such as MIT, GPL, also include this restriction, there were already tens of thousands of projects using them 10 years ago, the Commons app uses Apache 2.0, it is making a mockery of the project to claim that these are not free licenses. Commons:Choosing_a_license#Common_license_conditions also states full license text reproduction is an acceptable restriction. The Free Art License requires it too.

The MIT license text is also much shorter, where are we supposed to draw the line for what is acceptable? I looked at the old proposal for GFDL and on just the first comment saw a point that no one addressed, it is impractical to use almost any attribution licensed image on something like a coin that is too small to write it on.

It may be reasonable to restrict usage of Apache for photos, but there is possibly a reason to use GPL for photos; it was ruled by a court that including a CC BY SA image in a book does not require you to release it under CC BY SA, that makes it much less useful for creating new free media, it just keeps your image free. On the other hand the GPL requires you to release the whole program under GPL even if it just including a GPL library, it creates new free software. I am not sure if it would work the same way for images but if it did it would be a reason to use it.  $999$REAL 💬 ⬆   20:55, 14 October 2025 (UTC)

• Hm. It is of course a free license, just like GFDL. It's an easier license to add, as it's not nearly as long as the GDFL. Inside something like an .svg it's not a problem at all. I think there were people actively using GFDL on photos on purpose entirely to make complying more difficult -- not sure we have that same issue with the Apache license. However, it should be heavily discouraged for new image uploads, and always has been I think. I did not think there was an absolute ban on GFDL -- if an image naturally has that license elsewhere, we should still allow it -- thought that was part of the original discussions. Similarly if there is an image in an Apache-licensed software project, we should allow uploading that image. It's just for self-taken images where the user is choosing a license, they should not choose Apache (or other software-oriented licenses). I'm not sure we need to go to the same lengths as the GFDL, but it is in a similar bucket I guess. I would make an explicit exception for images from Apache-licensed software products, and allow .svg files with the license in general (those are closer to code anyways). But, I'd also allow the same for GFDL. If people have translated the restrictions to a blanket ban on new uploads no matter what, then I'd oppose. If we still allow those types of uploads, and just ban say photographic images without any attachment to an Apache software project, I could see that. Carl Lindberg (talk) 21:51, 14 October 2025 (UTC)
• (Edit conflict) Nobody claims here that Apache isn't a free license. And if a file comes out of software package (like tons of Unicode emojis, for example from various open-source fonts), then we should, IMHO, accept such cases as well. But for regular photos (which is the bulk of our uploads) we should not support this option as this makes it unpractical for reusage. So the proposal, as I understand it, is to phase out this template for anything for which we have no good rationale (like screenshots, photos of smartphones with Apache-licensed icons, emojis etc). Similar restrictions have been introduced in regard to GFDL (see links above) without anyone claiming that GFDL is not a free license. --AFBorchert (talk) 21:59, 14 October 2025 (UTC)

@999real - with regard to GPL photos, please do not. The text of the GPL assumes that the licensed work is a piece of computer software; many of the terms of the license cannot be meaningfully interpreted with regards to photographic or other non-software works. Omphalographer (talk) 23:22, 14 October 2025 (UTC)

COM:PHOTOCONSENT and VRT

When releasing the rights of photographs via VRT (COM:CONSENT) I believe there should be a way for photographers to confirm they have consent from people depicted in the photography as well (COM:PHOTOCONSENT). Then VRT members should be able to place {{Consent}} on the picture itself and there should also be {{consent|pending}} (which would be used by uploaders, in a similar way to {{Permission pending}}). It's moon (talk) 06:25, 28 October 2025 (UTC)

Proposal: Add AI-powered visual search for Wikimedia Commons

Hello everyone,

I would like to propose adding an (AI-powered visual search) feature to Wikimedia Commons. Currently, Commons search only works through text-based queries (titles, categories, or structured data). However, many users may have an image but not the exact keywords to describe it.

This new feature would allow users to upload or paste an image, and the system would use AI-based image recognition (such as similarity search or image embeddings) to find visually related files within Commons.

Benefits:

• Improves discoverability of media content.
• Helps editors find similar or duplicate files.
• Useful for GLAM, educational, and research purposes.
• Enhances structured data tagging and metadata accuracy.

A Phabricator task has been created for technical discussion and tracking: 👉 T408018 – Add AI-powered visual search for Wikimedia Commons images

Community feedback is welcome — please share your thoughts and suggestions below. If there’s consensus, the idea can be supported more strongly on Phabricator to attract developer attention.

Thank you! —GoldenJDM (talk) 19:53, 22 October 2025 (UTC)

AI tends to be very computationally expensive. Why would there be any advantage to doing this specifically within Commons to using existing free external tools? - Jmabel ! talk 03:03, 23 October 2025 (UTC)

I don't see the benefit for such software. The lead in AI-based searching that Google and OpenAI already have is most likely uncatchable, there's a gadget in your preferences that you can activate for image-based searches, or what should be the en:killer feature for such a search function here? Regards, Grand-Duc (talk) 03:12, 23 October 2025 (UTC)

I don't think this is needed much or would have a big impact or usefulness. Additionally, it doesn't seem readily possible now or in the near future but would take a lot of resources and effort to implement. Furthermore, there already is Google Images reverse search and Tineye as well as Commons category and Commons search, making this is more or less redundant. There also is a wish in the Community Wishlist about what you're describing: W212: Search Wikipedia with image or sketch search.

More useful would be a way to describe what one is looking for to some AI assistant which then tells you categories and/or a few files that match your description. This is one potential application of the many applications of wish W442: Adopt Wikipedia-trained WikiChat LLM & make it learn about help pages & categories to help newcomers also in the Community Wishlist. When it comes to duplicate files, there already is a check for similar files in the UploadWizard for example and it's not a plausible way what you're suggesting could be used efficiently.

To put things short, I don't think your idea is worth the effort but thanks for thinking about how Commons could be made better via technical development. Prototyperspective (talk) 15:15, 23 October 2025 (UTC)

The last time we tried this it was a huge loss of money, developer and volunteer time: See Commons:Structured data/Computer-aided tagging. GPSLeo (talk) 15:35, 23 October 2025 (UTC)

That this implementation was seriously flawed / low-quality doesn't mean the concept can't work well. However, this is about something entirely different than what's proposed here. Prototyperspective (talk) 15:47, 23 October 2025 (UTC)

In principle, some sort of image similarity or content recognition search would be great to have. But the ultimate deciding factor is going to be technological feasibility - the set of images on Commons is exceptionally large (currently 129M), and a lot of the typical tools for this sort of task will be unsuitable at that scale. (CLIP is probably not what you want; it's geared towards identifying broad classes of objects like "this image may contain a person", which are too broad to be useful on Commons.)

@GoldenJDM - this is probably a better fit for the meta:Community Wishlist than Phab, as it's not immediately actionable and requires planning. Omphalographer (talk) 01:26, 25 October 2025 (UTC)

 Support. As a note here, when making these types of proposals I think it is important to distinguish between Generative AI (GenAI) and other types of AI (or other concepts like CBIR, which is what is used to reverse image search and doesn't necessarily involve machine learning).

I am personally building a MediaWiki gadget tool that will allow users to reverse image search from a filename or URL using multiple engines like Google Lens, Google Classic, Bing, Yandex and TinEye (there is already a similar gadget that does this: GoogleImagesTineye).

I agree however that an engine to search within Commons would be pretty neat. There are multiple open source engines listed on List of CBIR engines that we could possibly look into. See also: Reverse image search.

I do agree this is better suited for the Community Wishlist. @GoldenJDM I can help you drafting a wish if needed. It's moon (talk) 00:16, 29 October 2025 (UTC)

It would likely be declined as a duplicate of the wish I linked above.
If you think this is important, the right place to file a Support vote would be that wish page. As a technical proposal, it's probably not most relevant on this page (instead of VP/T and the Wishlist).
The best place to add info on how it could be implemented would be the talk page of that wish, albeit currently too few people go through Commons-related wishes and their talk pages. If you're currently working on that, the wish could maybe be set to "In progress". Prototyperspective (talk) 09:30, 29 October 2025 (UTC)

That wish is about implementing a Sketch Search, where you draw something, and it gives results of images with the object or concept you drew. While it's similar and could be related, it's not exactly the same as a CBIR engine, where the input is an image sample and it gives links to where the same image can be found. You would typically not use a Sketch Search to search for duplicates. That doesn't mean both wishes could be put into the same focus area later on though. It's moon (talk) 19:28, 29 October 2025 (UTC)

No, the wish is about two things: image search and sketch search. Admittedly, the former part is not well-written and so far extensive edits of wishes aren't done by anybody else other than the wish's initial creator so it may possibly be best to submit a new wish and then let it be declined as duplicate and then merge the wish text into the existing wish.

I meant to point out here the issue that GoldenJDM is talking about searching for images that are loosely similar while TinEye only shows exact duplicates as well as variants that are very similar (such as the same image with extra text on top). However, Google Image search / Lens also show similar images. Now you're saying this would be just about finding duplicate images. I don't think there is much of a need for a duplicate image finder on Commons where the functionality is limited to that (e.g. given that the UploadWizard already does that) and it's not what GoldenJDM wrote about at around visually related files within Commons. Prototyperspective (talk) 00:15, 30 October 2025 (UTC)

What I was trying to say is that Sketch Search tools aren't as accurate and don't usually work like CBIR tools, but I didn't mean to say the tool would be used exclusively for duplicates (sorry, I didn't write that part properly -but I do agree it could also be used for related files-).

Also, when talking about duplicates, the idea would be to find the same image uploaded with a different resolution or compression. I believe UploadWizard only finds exact duplicates (correct me if I'm wrong).

Writting a new wish so that it gets closed and merged with the already existing one sounds like a solid plan. It's moon (talk) 10:26, 30 October 2025 (UTC)

Thanks for explaining. I believe UploadWizard only finds exact duplicates (correct me if I'm wrong). I think it also finds further duplicates but I don't know to what degree and this thread will likely clarify it: Commons talk:WMF support for Commons/Upload Wizard Improvements#Duplicate detection. Prototyperspective (talk) 12:20, 30 October 2025 (UTC)

Maybe an AI tool, not run by Wikipedia, would be the more responsible use of our very limited resources. For the increasingly dependent folk who cant do without. Alexpl (talk) 13:47, 29 October 2025 (UTC)

How should we geocode moving shots?

This is a continuation of a discussion started at Commons talk:Geocoding, about how to geocode videos where the camera and/or subject moves during recording. Such media has a dimension of time and therefore there's more than one location associated. Some ways could be to tag the location of recording start, or make the geocode imprecise enough to cover the entire recording area?

And regardless of which option if any we choose, perhaps we should also tag all such instances to make them machine-detectable and in case of future expansion of geocoding capabilities. I've made a suggestion for how that could look at {{Location variable/sandbox}}.

So my questions are: 1) What should be standard practice for geocoding media with multiple locations? 2) Should we tag such cases in any way? Rose Abrams (talk) 13:50, 28 October 2025 (UTC)

I think the simple location parameter for the template and structured data should be the staring location. The full track could be stored as geojson or tabular data. I think both data formats are suitable but we have to decide which one we use. I think storing as table would be better as tables have less overhead for this very simple list of points we want to store. GPSLeo (talk) 15:36, 28 October 2025 (UTC)

It probably needs at least a gadget and rather some change to the default Commons code to enable specifying the coordinates for varying locations. However, probably not many would do this, e.g. because they don't have the coordinates. Having a template may be good enough for now. I support having the proposed template.

Another approach that may be complementary would be to set the categories and then specify the timings that the category is about via some new qualifiers for categories feature that works similar to the sortkey (e.g. Category:Eiffel tower/0:25-1:01) as proposed here: Commons:Village pump/Proposals/Archive/2024/09#Qualifiers for categories (which parts of videos). For example, when a video shows multiple places of a city like various sightseeing spots, one could set them with qualifiers. Same for a video from a train driving through multiple train stations etc etc. These categories are linked to a Wikidata item with coordinates and one could identify categories as being 'location-categories' for example also via the Wikidata items. Prototyperspective (talk) 20:56, 1 November 2025 (UTC)

Update file description page table

I propose giving the file description page table a much needed fresher look! See the example below of File:Official CSS Logo.svg. See the sandbox at Template:Information/sandbox and styles Template:Information/sandbox/styles.css.

Demo [Click to open]

Example taken from File:Official CSS Logo.svg at Template:Information/sandbox/testcases.

DescriptionOfficial CSS Logo.svg	English: The primary rebeccapurple logo of the CSS specification.
Date	12 November 2024
Source	https://github.com/CSS-Next/logo.css/blob/main/css.svg
Author	Javi Aguilar and The CSS-Next Community Group
Repository InfoField	https://github.com/CSS-Next/logo.css/
Nominal resolutions InfoField	Primary (1000px x 1000px) and small (32px x 32px)
File types InfoField	.avif, .ico, .png, .svg, .webp
Permission ( Commons:Reusing content outside Wikimedia">Reusing this file)

Waddie96 (talk) 22:32, 19 October 2025 (UTC)

We already have {{Information field}} when parameters beyond the usual set are needed. The vast majority of files do not need additional fields (and quite frankly, neither does this file). Pi.1415926535 (talk) 02:01, 20 October 2025 (UTC)

@Pi.1415926535 Hi it's got nothing to do with additional parameters, it's got to do with styling it and refreshing it's look a much needed fresher look. Read again 😄 Waddie96 (talk) 03:41, 20 October 2025 (UTC)

Just FYI the info box is malformed when viewed in a mobile browser on a smartphone in portrait orientation. It looks fine in landscape orientation. I'm also wondering how it would be affected if the text is in another language and has a significantly different length than English. Nakonana (talk) 16:38, 2 November 2025 (UTC)

•  Oppose The existing style works perfectly fine, the new one is less accessible, and any possibility that this change would break any of the myriad of components held together with duct tape and prayers that make up the back end of this site far outweighs aesthetic concerns. The Squirrel Conspiracy (talk) 00:29, 29 October 2025 (UTC)

 Oppose Restyling currently not needed and this isn't much better even if the border was added and the license info moved out of the box again (2 issues with this). Prototyperspective (talk) 09:16, 29 October 2025 (UTC)

webp to png converter

There are several online, how about having out own. At one time we were discouraging webp files, how about our own internal converter? RAN (talk) 17:04, 31 October 2025 (UTC)

We already have a converter, you can just request a thumbnail of the same size as the original file and you will get a file converted to png. GPSLeo (talk) 17:45, 31 October 2025 (UTC)

We really ought to get an mp4 to webm converter before any other file types Trade (talk) 18:59, 4 November 2025 (UTC)

Maybe that would be better filed at Commons talk:WMF support for Commons/Upload Wizard Improvements. Prototyperspective (talk) 20:44, 1 November 2025 (UTC)

Is current limitation of cross-wiki uploads sufficient?

We recently enabled the limitation of cross-wiki uploads to users who are autoconfirmed on Commons. This reduced the uploads of copyright violations and out of scope content using this tool a lot. I now had a look at the current uploads from users whose account is three days old. This shows that there are still more problematic than good uploads. I looked at the last 100 Uploads: 30 of these uploads are definitely fine, 21 are obvious copyvios, 21 are definitely out of scope including 6 self promotion photos with also unclear copyright. The other 28 are unclear with some requiring VRT confirmation on copyright or local evaluation if a that bad quality graphic should be in the article. I therefore want to discuss if we need to limit this tool even more to only autopatrolled users. As only 3 of the last 500 uploads using this tool were from autopatrolled users this would be a de facto ban of the tool. GPSLeo (talk) 08:13, 2 October 2025 (UTC)

Do you have perchance data about the geographic provenience of the still-problematic uploads? Are there any obvious socio-demographic trends visible, are there any language editions especially prone for copyvio uploads?

I fear the the WMF won't take it gladly if the tool gets de facto banned, so more fact-based granularity in restrictions would be needed, if possible. That said, I'm fine with a restriction to "autopatrolled" in order to effectively stymie first copyvios and then OOS media. Regards, Grand-Duc (talk) 08:34, 2 October 2025 (UTC)

I will look if I can analyze the data in relation to this. The amount of uploads per project looks like a simple representation of the project size. I also noticed that uploads on non Wikipedia Wikis (Meta and Wikidata) were fine with all 14 from the last 500. GPSLeo (talk) 09:04, 2 October 2025 (UTC)

I created a dataset from the last 30 days with the number of files uploaded per Wiki and the amount of these files they are already deleted. GPSLeo (talk) 09:43, 2 October 2025 (UTC)

Autopatrolled on which wiki? On Commons? This might be too restrictive. For example, autopatrolled is given manually on Commons and I only got it when I had over 100,000 edits. If I remember correctly, I've even seen users with over 500,000 edits on here who still were not autopatrolled. Nakonana (talk) 05:41, 4 October 2025 (UTC)

Thank you for the datamining, GPSLeo. The dataset would IMHO support a further restricting of cross-wiki uploads to everything that is as bad or worse than the current all-Wiki average, meaning Incubator, AR, EN, ES, PL and RU, with FR data providing the cutoff. Then, we / you(?) do the same datamining in, let's say, 6 months (to catch possible avoidance movements). The other Wikis can currently keep the current status. Regards, Grand-Duc (talk) 06:07, 4 October 2025 (UTC)

Restricting by rights on an other Wiki is technically not possible at the moment. GPSLeo (talk) 07:20, 4 October 2025 (UTC)

Wasn't the restriction enforced by a filter? I thought that filtering for strings (like Cross-wiki upload from XY Wikipedia) would be possible. Regards, Grand-Duc (talk) 07:42, 4 October 2025 (UTC)

There is global_user_editcount in abusefilter which could be used as proxy? --Zache (talk) 10:41, 5 October 2025 (UTC)

This could be an option. Maybe with a requirement of 500 global edits? GPSLeo (talk) 14:00, 5 October 2025 (UTC)

@GPSLeo: No, I don't think it's sufficient. Granularly restricting by source wiki would work, if the filters could be configured that way. On the other side of the coin, all users who can cross-wiki upload here can also upload directly here if they want, bypassing any restriction passed here (source wiki or autopatrolled-here only); it's not a high barrier to public participation.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 17:58, 4 October 2025 (UTC)

The "other side" is not really a counter-argument, if you were thinking that way. I think that even low barriers are helpful, in the same train of thought as modified or blocked DNS records are widely employed for anti-piracy motions. They are not hard to bypass at all, but likely deter casual downloaders. So, if upload restrictions continue to be enforced, we'll also likely deter people who would possibly commit casual copyvios. Regards, Grand-Duc (talk) 04:25, 5 October 2025 (UTC)

Based on the short discussion and some statistical evaluation I would propose the the following limitation that would have prevented 2/3 of the deleted files to be uploaded.

Proposal: We limit the use of the cross-wiki upload tool to users who are (auto)confirmed on Commons and have more than 100 global edits. We do not discriminate based on the project. GPSLeo (talk) 09:34, 6 October 2025 (UTC)

I don't like the idea of cross wiki uploads at all, given all the negative issues that have surfaced, but limiting it as proposed seems good to me. Bedivere (talk) 12:16, 6 October 2025 (UTC)

What are some of those negative issues that have surfaced? whym (talk) 12:11, 9 October 2025 (UTC)

users disproportionally uploading copyright violations instead of good contributions. Bedivere (talk) 19:37, 14 October 2025 (UTC)

What made you believe that it's "disproportionally" so? Can you share data or other evidence to help others see what you see? I did some comparison against general uploads before [2][3] (quarry:94356, quarry:94443), and I found no significant difference there. whym (talk) 08:58, 18 October 2025 (UTC)

I posted about this on AN before I saw this. A lot of the files I see uploaded "while editing an article" are copyright violations, and many of the files that are good don't actually get added to the article. They just sit here uncategorized. Geoffroi 23:20, 4 November 2025 (UTC)

But how do you know if the amount of copyright violation is disproportionate there, or if it's just that there are many copyright violations on Commons in general, regardless of the upload method? As I mentioned, my data indicates the latter answer.

The lack of categorization is a separate issue, which my data mentioned above doesn't deal with (and I don't think it is what is primarily discussed in this section's proposal). Maybe a better solution for that is a bot to remind them for adding categories? whym (talk) 06:09, 9 November 2025 (UTC)

If you give more people the ability to upload images for the articles they're interested in, and simply the awareness that it's easily possible, you'll get more copyright violation images of notable people. As for the category and usage issue with good images, a lot of new users won't be able to figure out proper categories or how to place the image in an article. That's probably just how it is. Geoffroi 19:12, 9 November 2025 (UTC)

I think you are the only person who bring up notable people in this thread. How do you argue that it is the relevant? I'm not saying there is no such images at all, but I don't know if they constitute a significant enough amount in CWU, or CWU is particularly used to make such uploads. whym (talk) 00:33, 23 November 2025 (UTC)

How many good uploads would that have blocked? --Carnildo (talk) 21:18, 7 October 2025 (UTC)

!votes (limit cross-wiki uploads to confirmed on Commons and >100 global edits)

•  Support.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:59, 6 October 2025 (UTC)
•  Oppose seems to me to defeat the main purpose of cross-wiki uploads: that inexperienced users don't have to deal with two sites when developing content for one of our sister projects. "Confirmed on Commons" requires that they have actively edited Commons. Perhaps I could be convinced otherwise, but that is certainly how this strikes me. - Jmabel ! talk 15:01, 6 October 2025 (UTC)

  Perhaps the purpose of cross-wiki uploads was a mistake in the first place Trade (talk) 00:14, 15 November 2025 (UTC)

•  Support --Trade (talk) 20:37, 9 November 2025 (UTC)
•  Support – Most concerning is whether temporary accounts would circumvent one of the existing abuse filters. Also, I'm worried about Autoconfirmed and non-(Auto)confirmed users previously or still using temporary accounts. George Ho (talk) 21:09, 12 November 2025 (UTC); expanded, 21:13, 12 November 2025 (UTC); edited, 04:05, 13 November 2025 (UTC)
  • @George Ho: I don't follow any of that. How would a temporary account circumvent an abuse filter that would otherwise apply? And I totally don't get your second point: what scenario causes you to worry? - Jmabel ! talk 22:28, 12 November 2025 (UTC)

    Sorry for making unclear rationale. I just voted and mentioned "temporary accounts" because they've been released recently. Also, I'm also worried about sockpuppetry becoming harder to trace with temporary accounts hiding IP addresses currently. Also, I didn't want the whole abuse filter to be in vain, i.e. totally useless. I'll strike out the whole (unclear) rationale if you want me to. George Ho (talk) 22:59, 12 November 2025 (UTC)

    • @George Ho: Not asking you to strike it, just explain why you think the interaction of temporary accounts, cross-wiki uploads, and abuse filters creates special problems. As far as I can tell the main problems with cross-wiki uploads stem from user confusion and incompetence, not from anything malicious. And I don't see how temporary accounts would make things any harder to trace: for one thing, admins and a few dozen others will still be able to see the IP addresses if we need to, but for another each given temporary account will be stable for a reasonable period of time. A blocked IP will still be blocked, an IP disguised by a temporary account will still be readily trackable for its activity. You seemed to be suggesting these will somehow trick abuse filters, and I don't see the scenario. - Jmabel ! talk 00:10, 13 November 2025 (UTC)
      • Everything you said about the main problems with cross-wiki uploads and temporary accounts has made me reconsider the rationale I struck out just now.
        just explain why you think the interaction of temporary accounts, cross-wiki uploads, and abuse filters creates special problems Right now, I can't think one legitimately anymore. I'm more of an old-fashioned or old-school type, somewhat. I'm not very innovative when it comes to newer introductions, like temporary accounts. I mean, I've never thought about inventing such accounts... or other ways to legitimately hide IP addresses besides being a registered user.
        Well, I've been more concerned about how many edits would make that account promoted or something, like non-confirmed accounts becoming (auto)confirmed. However, then I read mw:Help:Temporary accounts, realizing now that such accounts last ninety days and that edits can't be transferred to registered accounts at all. Shows how "too" opinionated I am, like sports commentators I've seen onscreen. George Ho (talk) 04:04, 13 November 2025 (UTC)

      Now I remember: logged-out users still can't upload, right? George Ho (talk) 04:09, 13 November 2025 (UTC)

      @George Ho Yes, you can't upload while logged out, and I have tested it for good measure. Tvpuppy (talk) 04:50, 13 November 2025 (UTC)

•  Support What I see with these cross-wiki uploads is a lot of people reading articles about notable people and then uploading copyright violation images of those notable people or uploading good images that they don't know how to categorize or add to the article. I don't mind sorting through uncategorized images, but many of these uploaders are doing their first edits to a Wikimedia project, so something better could be done to help new users do constructive uploads and add freely licensed images to articles. Geoffroi 21:23, 12 November 2025 (UTC)

  Let's be honest. A lot of these are experienced Wikipedia editors who simply does not care as long as the article on their home Wiki gets illustrated without having to deal with the stringent Fair use policies Trade (talk) 00:13, 15 November 2025 (UTC)

  A lot of the copyvios I tag from these cross-wiki uploads aren't added to the corresponding article, something an experienced user would easily know how to do. Geoffroi 00:20, 15 November 2025 (UTC)

  Also, why wouldn't experienced users who want to upload a copyvio just upload them to Commons directly? I'm not seeing much gaming of license/source/author details either, as I would expect from experienced users. Geoffroi 00:25, 15 November 2025 (UTC)

•  Support -- Ooligan (talk) 16:29, 22 November 2025 (UTC)
•  Oppose Insufficient evidence to support yet. I appreciate Data:Cross-Wiki-Data.tab but how does it compare against non-cross-wiki uploads? We need baselines to compare and see if the proposal matches the severity of the alleged problem. (Or for that matter, to see if the current restriction matches it) whym (talk) 00:38, 23 November 2025 (UTC)

Equivalent file extensions

There are multiple file extensions that are currently allowed on Commons that are redundant: .jpg can be used interchangeably with .jpeg (you can simply rename the file extension, they are both exactly the same thing). The same goes for .tif / .tiff, .mpg / .mpeg (and .mid / .midi). I think to prevent duplicates and improve consistency, only one variant (probably the shortest one) should be enabled, and uploaders should be asked to rename files to the preferred extension (or alternatively, Commons should update the file extension automatically if that is possible to configure). It's moon (talk) 23:13, 28 October 2025 (UTC)

 Support Commons should update the file extension automatically if that is possible to configure and the shorter more common file extensions should be used like jpg. But oppose asking uploaders to rename some files mainly because this can be problematic when many files are uploaded at once. Prototyperspective (talk) 09:18, 29 October 2025 (UTC)

 Support --Trade (talk) 18:59, 4 November 2025 (UTC)

I'm not really in favor of making things consistent (on principle). First of all, I don't think this (duplicate files and potential confusion) is a problem that is common enough that we should worry about it too much. Additionally I find discussions like this are similar to discussions about tabs vs spaces for indentation. It shouldn't make a difference to the tooling. And lastly, most of the audience don't care about the file extension (or the file format) to begin with. There's even proposals to hide the file extension from the file title for that reason. —TheDJ (talk • contribs) 12:19, 26 November 2025 (UTC)

Would hiding the file extension from the file title improve search engine indexing? If so, I'd support that. One could instead append (video) (audio) (3D model) (document) or (image). It's not an important issue at all but why not standardize it so e.g. it's more expectable and can for example be queried better and reduce confusion where people think these are two slightly different filetypes? Prototyperspective (talk) 14:10, 26 November 2025 (UTC)

Are "Sum of all paintings" project galleries welcome on wiki commons?

Continuing and summing up a debate started on the administrators' noticeboard:

The Sum of all paintings project contains around a thousand pages, which are wikidata-backed automated lists (edited by Listeriabot) acting as galleries for paintings either made by specific artists or belonging to a certain museum. As was explained to me recently by @Jameslwoodward, gallery pages belonging to the Sum of all paintings project do not conform to COM:Galleries since they do not use <gallery></gallery> tags and a simple caption, and would better be placed on WP. This would imply the deletion of all existing or at least all new pages created using the Sum of all paintings preferred format, the reason why all the non-conforming lists were not deleted before being that their existence and non-conforming structure hadn't been noticed.

My two main arguments for the modifying of the COM:Galleries guidelines in order to allow the preservation of the project on wiki commons are:

• Similar lists on WP are entirely user-made, the commons lists are based on wikidata entries, and are thus completely different (compare this to this, 90 vs around 360 entries). Even copypasting the commons lists to WP would require scrutiny of a thousand lists of different artists in tens of different languages, to check that every entry unique to each project has properly been added to the final WP list.
• The commons lists are in fact duplicates of similar lists found on wikidata (compare here to here). The commons lists are however, due to the structure of commons, much easier to find, as they are properly placed in each painter's Paintings category. By comparison the wikidata lists are only accessible through this category and nowhere else, which is impossible to reach if one is not aware of the existence of the Sum of all paintings project. I must stress that this ListeriaBot automated list is actually one of its kind on the entirety on the Internet: there's basically no other website that present such a detailed global catalogue of paintings, which is much better ordered than the Paintings category, and much more complete than the lists present on WP, as it is wikidata-backed. I think it is in the interest of the scope of the project to make this list as easy to find as possible, which will not be the case if it can be found only on wikidata.

Pinging all previous participants to the discussion : @Jameslwoodward, Yann, Edelseider, Jmabel, and Schlurcher: , pinging contributors to Sum of all paintings project :@Mateus2019, Niketto sr., and Tzim78: , as their work would be affected by the debate. Ostrea (talk) 10:00, 11 October 2025 (UTC)

 Support Yes, these galleries are obviously useful. Yann (talk) 10:02, 11 October 2025 (UTC)

 Support. Edelseider (talk) 10:03, 11 October 2025 (UTC)

 Support. We should be more flexible with galleries including supporting wikidata-based tables. --AFBorchert (talk) 10:21, 11 October 2025 (UTC)

 Support Don't see why wouldn't. Prototyperspective (talk) 12:00, 11 October 2025 (UTC)

 Support One of the examples of a good gallery page long present at COM:Galleries does not use the <gallery> tag at all: Pronunciation of Dutch municipality names. Perhaps we should explicitly add one of these as another such example so that there is no doubt in the future. - Jmabel ! talk 12:56, 11 October 2025 (UTC)

 Support per Yann --Mateus2019 (talk) 13:04, 11 October 2025 (UTC)

 Support Especially comments by AFBorchert and Yann including suggestion by Jmabel. -- Ooligan (talk) 20:05, 11 October 2025 (UTC)

I fail to see what needs to be changed.

How are those pages not acceptable under the current version of Commons:Galleries?

No text and no one say a gallery (or a photo album as a synonym) must be made using <gallery> tags. RoyZuo (talk) 21:20, 11 October 2025 (UTC)

https://www.oxfordlearnersdictionaries.com/definition/english/gallery "a collection of pictures". RoyZuo (talk) 21:21, 11 October 2025 (UTC)

As I said at AN, "I don't understand why Commons should host pages that belong on WP -- there are many pages very similar to these on WP, so why should these be here rather than there? We are a repository for images and other media. We explicitly reject anything that looks like encyclopedic content, so allowing these pages will require not only a change to COM:Galleries, but also to Commons:Project scope." .     Jim . . . (Jameslwoodward) (talk to me) 12:59, 11 October 2025 (UTC)

• support - agree this seems like a good use of gallery pages, and support modifying the guideline accordingly — Rhododendrites ^talk |  13:53, 11 October 2025 (UTC)

 Support per Yann, as also stated on the noticeboard --Schlurcher (talk) 15:41, 11 October 2025 (UTC)

•  Comment @Jameslwoodward, Yann, Edelseider, Jmabel, and Schlurcher: As you might know, I started SOAP in 2014 and I'm probably still one of the more active contributors (wonder why User:Ostrea didn't ping me). We have lists at d:Category:WikiProject sum of all paintings creators and some other places. Back in 2021 User:Mateus2019 started copying these pages to Commons ([4] [5]). Felt more like quantity over quality. I'm quite unhappy how it looks now, so I'm with Jim on this one: In the current form these are not galleries and have no place on Commons. So if we are going to do this, we should change them to galleries like I did on Paintings by Johannes Vermeer. Make good looking galleries or delete them. Multichill (talk) 18:39, 11 October 2025 (UTC)

  The reason's simple: your and your bots' contributions to the project have been of course immense, but I do not think you have ever, except the improvement you've recently created, contributed to a Commons Sum of all paintings page, and the history of these pages were my only way to find out who is involved at all in this slice of the Commons side of the project. It was either this or pinging the first 10 members in the SOAP participants list...

  I have to say the change you're suggesting does look superior to the rather detailed but dry lists we have now... if there's consensus on using it instead of the current format, perhaps a change of rules wouldn't even be needed at all to solve the situation Ostrea (talk) 22:33, 11 October 2025 (UTC)

  @Multichill: It looks good; does this format still provide a decent approach to having a bot maintain it, and does it provide a decent way of indicating pictures for which we do not have images? - Jmabel ! talk 02:33, 12 October 2025 (UTC)

  @Ostrea: it's a wiki project so I created Commons:WikiProject sum of all paintings and Category:WikiProject sum of all paintings a long time ago. We have to look at the category. Probably just have a (hidden) tracker category to keep an overview of automatically updating galleries.

  @Jmabel: I found Category talk:Paintings by Piet Mondrian (pl), bit of a weird place. Had to patch the template so that it now shows File:No-Image-Placeholder-landscape.svg if no image is available.

  Other people also in favor of changing these into real galleries instead of changing our policies? Multichill (talk) 12:32, 12 October 2025 (UTC)

  If we currently do not consider foto-focused lists like Paintings by Édouard Manet - Wikimedia Commons as Galleries, then I'm in favor of changing our policies. In my understand they are. If there is an option to improve their visuals in this case, even better, but this is a separate discussion. As I understand from AN this started as a scope and policy discussion and imho this should not have been the case. --Schlurcher (talk) 12:46, 12 October 2025 (UTC)

  @Schlurcher: These big table lists have no place on Commons in the gallery namespace in the current form. What's the point of having an exact copy of d:Wikidata:WikiProject sum of all paintings/Creator/Édouard Manet here?

  If we go back to the original proposal:  Oppose updating Commons:Galleries to accept these big table lists. Multichill (talk) 13:18, 12 October 2025 (UTC)

 Support They look like a form of gallery to me. I don't see we need a change of project scope at all -- these are not primarily encyclopedic text, nor really even primarily of text. They are simply a listing of images with a bit more factual information about them. If we need a change of wording to COM:Galleries to allow these, then do it. Wikipedia seems to disdain image galleries (en:WP:GALLERY) thinking they are more of a Commons thing. These can't move to WP since they would likely just be deleted under their policy, that they should be moved to Commons. I think these are firmly inside Common's scope. It's just another way to display the media we have -- the images are the focal point. However, if the data is already stored on Wikidata, using a method to query that data and generate galleries that way (as opposed to copying the data) is probably preferable. Carl Lindberg (talk) 22:04, 14 October 2025 (UTC)

•  Question Would this information be better suited to the Data namespace?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 19:44, 11 October 2025 (UTC)

  @Jeff G.: I don't think so, because (unless I'm missing something) it wouldn't provide thumbnails of the pictures at all. - Jmabel ! talk 02:31, 12 October 2025 (UTC)

  @Jeff G.: the data is actually on Wikidata and is retrieved using a SPARQL query. The gallery is just a nice visual representation of it. Multichill (talk) 12:42, 12 October 2025 (UTC)

 Neutral Personally, I think gallery pages as a whole shouldn’t be hosted here and that most of them should just be deleted. If we want a nice visual overview of "good images" for a topic, that should be handled through a proper gallery view or improved category browsing, not random wiki pages pretending to be galleries. Since that's not what this discussion is about, I'll just !vote Neutral. I don't find these Wikidata-based pages any worse than stuff like Farsta, which honestly just makes Commons look neglected. At least the Wikidata ones maintain themselves. --Jonatan Svensson Glad (talk) 23:08, 14 October 2025 (UTC)

For the record, if gallery pages in general are dropped, I will leave the project. Feel free to hold me to that if it occurs. - Jmabel ! talk 00:12, 13 November 2025 (UTC)

I'd much rather see WMF (or someone) develop proper MediaWiki functionality for curating and displaying high-quality galleries than continue relying on these outdated wikipages with tiny thumbnails. Many of them have fewer than five images and haven't been touched in over a decade. A few are excellent, but most just duplicate the corresponding category, often with even less content. To me, that's not something to defend – it's a symptom of technical debt that we should be moving past, not preserving.

Commons should be focusing on structured and maintainable ways to showcase our media, ideally through automated or database-driven tools that actually reflect what's in Commons, not static pages that depend on manual upkeep. The project deserves better than a patchwork of abandoned "galleries" that neither scale nor represent the richness of our collection. --Jonatan Svensson Glad (talk) 00:42, 13 November 2025 (UTC)

Agree with all you said starting at Many of. The question would be what to do about it. I'd support most of them should just be deleted but think many are quite good and deleting them may not be needed or good if Wikipedia articles didn't link to them instead of the categories. Not sure what you mean at develop proper MediaWiki functionality for curating and displaying high-quality galleries – what do you think is missing? And also there already is such functionality or not – listeria which is used in the galleries this thread is about. Prototyperspective (talk) 00:54, 13 November 2025 (UTC)

•  Support for any such uploads from museums or of artists who can be considered notable in the least restrictive logical meaning of the word. Any problems with categorization or gallery organization are secondary to the obvious benefit of having the images. -- Ikan Kekek (talk) 23:11, 16 November 2025 (UTC)
• I think they should not be deleted, but updating guidelines just for these lists is dubious too, as they are plagued by multiple issues:

Discoverability. Pages on Commons are better then pages on Wikidata, but they are still not discoverable enough. When i needed to find certain variation of Madonna and Child, i looked Wikipedia list of paintings by Botticelli and it wasn't there. Then is started looking over dozen websites on the internet and with some effort found it. When i found exact name and location, of course i found it on Commons and using "What links here" i found Listeria lists too. But how are new users are supposed to find them? Wikipedia links to Commons categories, but there's no indication they contain more complete lists than on Wikipedia.

Duplication. There are lists of Wikipedia, lists on Commons and lists on Wikidata, on same topic but slightly different. And lists themselves are sort of duplication of categories. This seems like maintainance hell, could at least some of these redundancy eliminated?

Presentation. For example, Paintings_by_Sandro_Botticelli - it's far below standart of art gallery presentation. Images are too small, but "depicts" column is too bloated, even though it's mostly useless for the reader. Catalog code is stretched vertically which looks very ugly, and it's also not very useful. "Described at URL" shows bare URLs, some of which are to Wayback machine. Width of table exceeds page width, so it partially overlaps with right panel. Way worse then Wikipedia list.

If these are just as maintainance-only for finding duplicates on Commons, they might be good enough. But if these are actually meant as complete painting catalogs for end-users, they need improvement. What prevents just having the single list, complete and with good presentation, and link it from all places? MSDN.WhiteKnight (talk) 04:16, 11 December 2025 (UTC)

•  Support The argument that because Wikipedia has similar lists, that means they don't belong here is a bit silly to me. There is as far as I know no policy or guideline here or anywhere that states projects must not overlap at any point. There's no better place for galleries such as these (or galleries in general) than Commons, what other projects do is their business. --ReneeWrites (talk) 23:20, 13 December 2025 (UTC)

CropTool2

I've been using CropTool2 (see Commons talk:CropTool#CropTool2) and it seems to be equal to or better than the existing CropTool in all respects. I think it should become the main line offered in Preferences, superseding the existing CropTool. - Jmabel ! talk 13:54, 15 October 2025 (UTC)

• Agreed. No reason not to upgrade. --P 1 9 9  ✉ 14:13, 15 October 2025 (UTC).

 Support Makes sense. Moreover, the gadget description should also be updated per Commons:Village pump#Straighten tool. Prototyperspective (talk) 15:47, 5 December 2025 (UTC)

Section restored from archive Jmabel ! talk 06:37, 5 December 2025 (UTC)
 Comment I believe this would fulfill meta:Community_Wishlist/W16. Pinging @Pppery, ZandDev: you supported that wishlist item. Is there any reason this would not solve that issue? - Jmabel ! talk 06:40, 5 December 2025 (UTC)

I have nothing specific to say - I was just reviewing all wishes and must have thought "it would be nice if this were done". * Pppery * _{it has begun...} 06:41, 5 December 2025 (UTC)

Having multiple copies of one file is still a bad solution for the problem. What we need is on demand cropping by the server and not separate filepages for data subsets. GPSLeo (talk) 12:05, 5 December 2025 (UTC)

I think more often, having it as a separate file is preferable. For example, it's easier to use, ready to be used externally, and showing the thumbnail in Web search engine results. On-demand cropping would be overly complex and resource-intensive to develop and maintain with there being no need for it and several downsides. Prototyperspective (talk) 15:13, 5 December 2025 (UTC)

@GPSLeo: there is {{CSS image crop}}. Doesn't save you anything on the download (it's all client-side) but does allow you to do this without creating a new stored file, if you like. I could imagine wrapping that with another template whose parameters might be more intuitive. (It would have to do some math.)

But more to the point: are you saying we should not substitute an already available, better version of the existing tool because you hope that someday WMF will devote resources to solve this in a manner you would prefer? That seems like cutting off your nose to spite your face. - Jmabel ! talk 18:35, 5 December 2025 (UTC)

Further: I'd be astounded if it were practical to do any server-side rotations on the fly other than multiples of 90°. - Jmabel ! talk 18:54, 5 December 2025 (UTC)

Such rotations would be like changing the saturation or exposure of a photo what is also not possible online. The main problem is that the different crops are only linked through templates but there is no API where I can get the original version and all suggested crops. Every slightly different crop is totally different file requiring every change to the original description to be copied. I think we should advertise the new CropTool but we should not consider the problem of crop handling as solved. GPSLeo (talk) 07:13, 6 December 2025 (UTC)

@GPSLeo: you didn't really answer my question. You say we should "advertise" it, but the question is about changing what version of Croptool is offered in the preferences, given that for the foreseeable future one will be offered. You seem to be arguing that we should not make the substitution, but I don't see the case against switching over to a tool that, as far as I can tell, is equal or superior in all ways, and completly backward-compatible. What is the reason not to do that? - Jmabel ! talk 19:36, 6 December 2025 (UTC)

Sorry for the confusion. Replacing most links (including the gadget) to the new crop tool was what I meant by advertising. GPSLeo (talk) 19:49, 6 December 2025 (UTC)

 Support Was involved with its development... and we are happy to fund further improvements. I prefer separate files on Commons rather than cropping on the fly in part due to offline use and separate files just being simpler. Doc James (talk · contribs · email) 13:13, 6 December 2025 (UTC)

 Support --Ooligan (talk) 00:06, 8 December 2025 (UTC)

•  Support as above. Handling big images is a big win for me, as I've sometimes had to locally fall back to ffmpeg to crop big honking JPEGs. JayCubby (talk) 14:27, 10 December 2025 (UTC)

---

Counting in GPSLeo's clarification, this seems unanimous. How do we move this forward technically? - Jmabel ! talk 23:07, 10 December 2025 (UTC)

Just change line 9 of MediaWiki:Gadget-CropTool.js to use the new url (https://croptool2.toolforge.org ) Bawolff (talk) 23:13, 10 December 2025 (UTC)

I apparently don't have the privileges to edit that. - Jmabel ! talk 01:27, 11 December 2025 (UTC)

It needs to be someone in the interface admins group. Bawolff (talk) 07:47, 11 December 2025 (UTC)

 Done GPSLeo (talk) 08:59, 11 December 2025 (UTC)

@Jmabel: Please apply for such group at COM:BN.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:41, 11 December 2025 (UTC)

@Jeff G.: I have no interest in taking on yet another responsibility here. I'm already putting in the equivalent of an unpaid full-time job. - Jmabel ! talk 17:20, 11 December 2025 (UTC)

It was good to ask @Jeff G. and thank you @Jmabel for countless hours dedicated to helping here on Commons. -- Ooligan (talk) 18:24, 13 December 2025 (UTC)

Stricter blocking policy for copyright violations

We still have a huge problem with blatant copyright violations where people upload some photo they found on the internet as their own work. Currently these users are warned multiple times and get blocked for two weeks. After the block they continue with uploading copyright violations. I think we should be more strict and only give one warning. If there are blatant copyright violations after the first warning they should be partially blocked infinitely from uploading files. They should be able to appeal immediately if they explain that they now understand the rules. This process is only valid for blatant copyright violations like wrong own work claims, "source: internet" or source links to obviously non free content. This should not apply to content where the uploaded assumed it would be public domain (also if it is not) or derivative work and FOP problems. GPSLeo (talk) 12:36, 26 October 2025 (UTC)

simply  Strong oppose. modern_primat ^{ඞඞඞ ----TALK} 19:43, 26 October 2025 (UTC)

then put more admins here to cope with workship. modern_primat ^{ඞඞඞ ----TALK} 19:44, 26 October 2025 (UTC)

+ if people get banned then sock puppetery will thrive. current system of blocking for copyvio is good. modern_primat ^{ඞඞඞ ----TALK} 17:45, 27 October 2025 (UTC)

I think the people who upload copyright violations in that way are not the same people who create sockpuppets to continue with their project disruption. The users who are to be blocked from uploading with this rule do not know what Wikimedia is. GPSLeo (talk) 19:16, 27 October 2025 (UTC)

we'll see. hayırlısı olsun. modern_primat ^{ඞඞඞ ----TALK} 05:43, 28 October 2025 (UTC)

•  Strong support, thanks to GPSLeo for pointing this out.--Kadı Message 23:22, 26 October 2025 (UTC)

 Support, having reported overlooked mass copyvios in the past where the uploader turns out to have a talk page of warnings and earlier short blocks that they've waited out, not noticed, or not understood.

The time likely needed for the user to familiarize themselves with relevant policies and adjust their behaviour of an initial week-long block makes sense in nuanced situations where a user might be applying a policy wrongly or interacting inappropriately, while being an otherwise productive Commons user, but it doesn't seem applicable to someone who is claiming "own work" or "public domain" on clearly copyrighted content, and making no constructive contributions. Belbury (talk) 10:09, 27 October 2025 (UTC)

 Support - in my opinion, copyright violations are, at large, one of the most prominent dangers (if not outright number 1) to the integrity of the project. Strong signals like blocks (and knowing + applying en:WP:UBCHEAP for people appealing them) are sensible tools to deal with such uploads. Regards, Grand-Duc (talk) 21:15, 27 October 2025 (UTC)

•  Strong support.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 12:06, 28 October 2025 (UTC)

 Comment Is it possible to partially block a user to prevent them from uploading new files, while still allowing them to edit file descriptions? If so, that seems like it could be a really useful tool to get users to fix licensing information on their uploads before letting them upload more files. Omphalographer (talk) 22:15, 28 October 2025 (UTC)

This is exactly what I propose: Only block them from uploading. This is possible, they still can edit in the file namespace but they can not upload new files. GPSLeo (talk) 22:54, 28 October 2025 (UTC)

is there a reason why this isnt the norm already Trade (talk) 01:29, 3 November 2025 (UTC)

• I started out wanting to weak oppose this, since my own start to this community was uploading copyvios. But when I got a "stop or you'll be blocked"-type message, I actually started to respond on my talk page in order to get a better understanding. When I began writing to oppose a stricter blocking policy, it was because I wouldn’t want to block the next me.

I think every copyvio warning should automatically count as a clear "stop" notice – something unambiguous that the user can't miss amongst all the other boxes that must have already been left from previous deletion warnings (since that is why they are now getting a "stop" warning). But after writing this, I realized that what I was going to propose is almost the same as what's already being proposed here, so  Support.

However, I'd also like to propose a wider overhaul of how we notify users about copyright violations. Compare it to how vandalism warnings work on enwiki: short, conversational messages that invite the user to reply and ask questions, rather than long templates stacked with dense policy text. It's important information, and everything is super-important to know, follow, repeat in their sleep...(/joking aside...) The current system, with multiple boxes repeating similar warnings, doesn't really encourage dialogue or learning. A simplified, human approach could help new users understand why their upload was a problem and how to do better, rather than just overwhelming them with boxes upon boxes, a "stop" box in the middle followed by more boxes. --Jonatan Svensson Glad (talk) 23:07, 28 October 2025 (UTC)

• Supporting it in principle or in spirit but only for actually severe cases like people only or nearly only uploading copyright violations and continuing with it after the block expired. However, I think this can easily backfire and be misinterpreted if not codified well such as blocking users who actually uploaded a copyright violation once in a while and got warned and then accidentally did it again, e.g. because they forgot months later or didn't notice. So I think the phrasing should be well thought through, quite specific and well-written where "for blatant copyright violations like wrong own work claims, "source: internet" or source links to obviously non free content" is not yet sufficient.

Prototyperspective (talk) 09:22, 29 October 2025 (UTC)

+1. Some copyright rules are also complicated or simply not known by new users (many users don't work with copyright or law in their free time). Some just want to contribute some pics in good faith, so we should draw the line between people who don't want to care about the rules and people who are eager to do better and are or become useful contributors and want to learn about the issues to avoid them in the future. When I began, I also had some violations because knowing all rules before beginning is almost not possible, I guess. But for obvious cases, I can follow the proposal --PantheraLeo1359531 😺 (talk) 08:47, 15 December 2025 (UTC)

If the sources to non free content are so obvious then why cant a filter pick them up Trade (talk) 01:27, 3 November 2025 (UTC)

 Support, the partial block should be such that compels the user to respond to the talk page notice. Maybe we should broaden the partial block scope and include File space as a whole. Bcoz if it is a vandal, the second stop (after not being able to upload) will always be files. I agree with @GPSLeo that continued upload of blatant copyvios after first warning should attract a partial indefinite and not temporary block. I also like @Josve05a's proposals regarding TP notices. Thank you. Shaan Sengupta^Talk 07:39, 3 November 2025 (UTC)

• I think any form of intentional dishonesty (e.g. editing an image to hide its source) should be an indefinite ban. Traumnovelle (talk) 06:02, 7 November 2025 (UTC)
  • Agreed. But I'm much more skeptical of the value of blocking a new user over what may be an honest mistake or two. - Jmabel ! talk 23:48, 7 November 2025 (UTC)

  What do you mean with editing an image to hide it's source? Trade (talk) 20:56, 9 November 2025 (UTC)

  A typical example would be taking a stock photo, deliberately editing out a watermark, and claiming it as own work. Omphalographer (talk) 21:54, 9 November 2025 (UTC)

  So if someone did the exact same thing but didn't bother to remove the watermark that would not count as intentional dishonesty in your opinion? Trade (talk) 23:35, 9 November 2025 (UTC)

• What if the user name / user page / contribution history contains what looks like a copyright holder's name, even if the file is available on the internet? Would sysops be responsible for checking those indications before immediately indef-blocking? Shoult it be "blocked until proven legitimate"? I think this "blatant" can be hard to define. A "Disney rep" uploading a recent Disney character might be hard to believe, while a lesser known company might be more willing to do a CC release for visibility. whym (talk) 06:22, 9 November 2025 (UTC)
• Rather  Oppose. I think this addresses an issue the wrong way. The problem is not supposedly lenient admins who let people upload copyright violations. The issue is the lack of people checking real serious copyright violations. Quite of number of people spend a lot of time looking for potential copyright violations in borderline cases, including URAA. But very few people take care of the serious cases (files copied from social media and random websites). In consequence, these copyright violations are not checked, and the violators can continue uploading them. If the priority is changed to serious violations, violators would be warned early, and blocked soon after. Yann (talk) 21:14, 9 November 2025 (UTC)

  The two issues are connected, though. If we're giving social media copyright violators four chances instead of one, the few users who are patrolling for that kind of copyright violation will have to find and verify and report them four times. That spreads their efforts even more thinly.

  There's also (as I understand it) no mechanism for anyone to be alerted that a user who's come out of a temporary block for blatant copyvios has started uploading files again, so it is just going to be luck whether anyone notices a copyvio-only account resuming activity, each time. Belbury (talk) 12:34, 20 November 2025 (UTC)

  For information, my practice is the following: less than 5 copyright violations -> simple warning, more than 5 copyright violations -> last warning. Then one-week block if still uploading after the last warning, and 3-months block if still uploading after one-week block. But I often discover users with 20+ copyright violations and no warning. So what do you suggest in such cases? Yann (talk) 16:26, 20 November 2025 (UTC)

  Oh, that's a point, I wasn't counting warnings among the "chances" above. So as things are, we're often giving blatant copyvio uploaders five or six opportunities to upload problematic content, including before the first and final warnings, and I think we should (as I think GPSLeo is suggesting) only ever give them two: one warning (at whatever level), then an indef block if they continue to upload copyvios. Belbury (talk) 16:49, 20 November 2025 (UTC)

  Is anyone stopping you from only giving one warning Trade (talk) 05:58, 21 November 2025 (UTC)

  I'll sometimes start with a final warning if the user has multiple batches of copyvio deletion notices on their talk page, at least weeks apart, but no first warning. Belbury (talk) 10:18, 21 November 2025 (UTC)

  So why do we need a proposal? Trade (talk) 22:59, 25 November 2025 (UTC)

  The proposal is about what level of block is appropriate after the user ignores that final warning. Belbury (talk) 09:34, 28 November 2025 (UTC)

•  Weak oppose. I support a block after one warning, but I don't think the first block should be indefinite unless the uploader seems to be a vandal or spambot. On Wikivoyage, we normally use a system of escalating blocks, starting with 3 days, then 2 weeks, then 3 months, and then indefinite. However, I feel like admins are really overworked on Commons and struggling to catch up to problems, so I think the first block being a week and the second block being indefinite would be fine. -- Ikan Kekek (talk) 23:18, 16 November 2025 (UTC)

•  Support Reading the headline, my initial response was to oppose this idea outright. But GPSLeo makes a quite nuanced proposal that would only affect blatant copyviolators who continue their practice after the first warning; would not block these people entirely from the project; and would allow for an appeal procedure. IF the guardrails outlined in the proposal are followed, this would hopefully lead to less copyvio uploads in the long run, because notorious copyviolators can either be educated to do better or be stopped entirely in their tracks. --Enyavar (talk) 00:37, 28 November 2025 (UTC)

 Oppose I appreciate what User:Jonatan Svensson Glad wrote, and my thinking goes in that direction, even though my "vote" is different. Jerimee (talk) 22:56, 28 November 2025 (UTC)

•  Support --ReneeWrites (talk) 23:14, 13 December 2025 (UTC)
•  Support --Ooligan (talk) 02:15, 14 December 2025 (UTC)
•  Neutral I understand the proposal and support it in some way, but I fear that the "threat" of sanctioning with blocking may come in some cases too soon (afaik a blocking should be not considered as punishment, but rather as demand to comply with the rules). I saw one case where a long-year contributor had only very few violations and acts in good faith, as I could examine, and he got a warning of being banned. This was way too exaggerated in my opinion, so I would like to limit the stricter policy to (new) users who obviously cause vandalism and do violations on purpose, but not apply stricter bans to users where problems are rare and where they are eager to do great. So, I am neutral on this --PantheraLeo1359531 😺 (talk) 08:41, 15 December 2025 (UTC)
•  Support Although this is de facto applied to problematic users. --Bedivere (talk) 04:00, 18 December 2025 (UTC)