RfC: Changes to the public domain license options in the Upload Wizard menu

An editor has requested comment from other editors for this discussion. If you have an opinion regarding this issue, feel free to comment below.

Should any default options be added or removed from the menu in the Upload Wizard's step in which a user is asked to choose which license option applies to a work not under copyright? Sdkb ^talk 20:19, 19 December 2024 (UTC)

Flag galleries

Enforce Cross-Wiki upload restrictions

"Culture of", "Society of" and similar categories

Abstract categories like "Culture of X", "Nature of X", "Politics of X" and "Society of X" are now widespread (where X is a country, region, or a city). But the problem is that such categories often get messy without following a consistent definition across a given topic. So, my proposal is to define the categories as follows:

• Nature of X – non-human aspects of X, like environment, landforms, organisms etc.
• Society of X – human aspects of X.
  • Culture of X – topics of X related to arts, beliefs, cuisine, customs, festivals, philosophy, religion, science, technology, traditions etc.
  • Politics of X – topics of X related to government, elections, royalty etc.

Sbb1413 (he) (talk • contribs • uploads) 08:23, 17 May 2025 (UTC)

Nature of X – non-human aspects of X, like environment, landforms, organisms etc. — where to put human-made parks or similar aspects of landscape architecture in this case? Where to put photos of flowereds that are maintained by a city's administration? Where to put agriculturally used fields? Also, where to put human-made water canals? Or what about rivers that got altered by humans (e.g. Category:Straightening of the Rhine)? Nakonana (talk) 09:17, 17 May 2025 (UTC)

I would move most what is currently in Nature of categories to the also existing Geography of categories. I think Nature of should only contain close up photos of individual plants or animals but then also if they are cultivated. GPSLeo (talk) 09:50, 17 May 2025 (UTC)

I oppose hiding "culture" under "society". Not intuitive for the average end user.

I'd put royal families under "society", but probably not under "politics", as a rule (though of course ruling monarchs do belong under "politics". I think it is ridiculous, for example, to have things like the current irrelevant Bonapartist and Bourbon claimants to the French throne under "politics"; similarly, some highly collateral relation of the British royal family.

I'd put parks both under "nature" and (indirectly) under "culture". - Jmabel ! talk 18:44, 17 May 2025 (UTC)

 Comment - any ruling/reigning dynasty would still belong under the politics of that country/-ies (i.e.; not just the monarch, but line of succession, other involved family members, etc.). SAUDI ARABIA & the house of saud is a brilliant working example of this, but so, in their own way, are the british royal family (with their set of "working" royals). any "aspiring" dynasty with any serious political history would also qualify; in the country's "historical" section at least, & i do not see any particularly good way to "split" a royal family category btwn those members who are politically relevant, & those who are not...?

i have no problem with multi-categorising parks, & i could think of a few cats more to add there...  :) Lx 121 (talk) 11:28, 30 June 2025 (UTC)

@Jmabel: Yeah, I confused royalty with monarchy, and the latter is a form of government. Regarding "culture" under "society", although I see how unintuitive it might be to put "culture" under "society", I know that separating the two is not always a good idea for the follwoing reasons:

• Culture refers to shared aspects of the society of a given region.
• Having two categories separately can confuse people. Especially categories like "ethnic groups" and "religion" would be put under both "culture" and "society" if they are categorized separately.

A better compromise would be to have a unique sortkey for subcats like "culture", "economy", "people", and "politics" under "society", so that they don't appear "hidden". Plus, a navbar can be used to access the important categories, albeit being "hidden" by larger categories. Sbb1413 (he) (talk • contribs • uploads) 04:48, 18 May 2025 (UTC)

Please remember, this is more about helping people find things than about ontology; the latter is more of a Wikidata concern. If people won't think to look for "culture" under "society", then it does not matter how ontologically correct it is. And there is nothing wrong with having a fair number of categories be under both, it's not like it has a significant cost. - Jmabel ! talk 19:43, 18 May 2025 (UTC)

As an aside: it's important to avoid excessive generalization in "TOPIC of PLACE" categories. An example of how this can be taken way too far can be seen at Commons:Categories for discussion/2025/05/Category:Cultural history of New South Wales, where a relatively small number of photos, mostly of grain silos, got spun out into dozens of effectively unrelated categories like Category:Cultural history of New South Wales. Omphalographer (talk) 20:21, 18 May 2025 (UTC)

Proposal to convert Fake SVG to timed deletion template

There are just under 2,500 fake SVGs - which Commons defines as files that use the .svg (vector file) extension but are entirely composed of raster (non-vector) data.

If I have some time, I'd like to go through them and either reupload them under raster image formats or nominate them for deletion. Once we get the number down though, I think it makes sense to convert {{FakeSVG}} to a timed deletion notice (a "fix this or it will be deleted 7 days after being tagged" template like {{Dw no source since}}). I can't think of any good reason to host raster graphics under a vector format. The Squirrel Conspiracy (talk) 00:31, 3 June 2025 (UTC)

Many are in use though...? --Jonatan Svensson Glad (talk) 00:38, 3 June 2025 (UTC)

•  Oppose. Fake SVG files are legitimate images; they will have a modest bloat because the underlying JPEG or PNG file goes through another level of encoding. A few years back some Commons users debated ripping out the underlying bitmap image, uploading it, and then deleting the original SVG. That seems an enormous waste of effort. The files work right now, so they can be left alone. If they are used, then great. If they are not used, then leave them around and do not spend any effort on them. Many of the bitmap-only files could be (or should be) improved to use the SVG vector format, so you get into this strange cycle of uploading the embedded PNG file but then immediately tagging that PNG with {{Convert to SVG}}. The proper course is to consider {{FakeSVG}} as an invitation to improve that SVG file by uploading better versions rather than a slightly misused format that should be eliminated. See Category:Fake_SVG#Replacing_fakes_by_real_SVG Glrx (talk) 01:34, 3 June 2025 (UTC)

•  Support The files that are in use should be removed from other projects and replaced with better versions first. Otherwise, I'd probably support it. I'm actually kind of surprised there isn't already efforts being made to phase the files out. I'm willing to support this when, or if, that happens though. --Adamant1 (talk) 07:23, 3 June 2025 (UTC)

  I guess I wasn't clear. That was always my plan. The Squirrel Conspiracy (talk) 14:21, 3 June 2025 (UTC)

@The Squirrel Conspiracy: OK. Thanks for clarifying things. I support it then. --Adamant1 (talk) 01:27, 4 June 2025 (UTC)

•  Oppose any arbitrary deletions for this reason. KEEPING or DELETING files should be based on the merits of the file, not whether it has been "correctly labelled" or not. I HAVE NO PROBLEM WITH sorting out & correcting the mislabeled items though (& i might be willing to help doing so).

STRONGLY  'Oppose the idea of automatically deleting files ("timed" or not) simply because they are mis-labeled as svg's. that just seems really dumb & arbitrary & problematic, in so many ways... Lx 121 (talk) 11:45, 30 June 2025 (UTC)

 Oppose. I'm fully in favor of deleting "fake SVGs" which have been converted to real raster images (or to better SVGs). But we shouldn't delete newly uploaded images without replacement just because they're technically imperfect. Omphalographer (talk) 23:15, 20 July 2025 (UTC)

•  Oppose As others have mentioned, the files are totally usable, just could be improved. If they're the best we have of a subject, then keep until such time as we have a better one--then delete as a poorer technical version compared to another we have. That said, I would support (semi-)automated "un-wrapping" process, whereby the internal raster is extracted and uploaded itself, with preservation of metadata. but I wouldn't support blind (semi-)automated vectorizing, because I've seen numerous examples where someone who doesn't actually understand the subject gets actually poorer results due to "better looking graphics" not realizing the meaning is weaker or less-standardly presented. DMacks (talk) 23:56, 20 July 2025 (UTC)

  Agreed all around. As an aside, it'd be great to have the same "unwrapping" process available for single-image PDFs. Omphalographer (talk) 00:05, 21 July 2025 (UTC)

remove mandatory username verification from username policy

The previous proposal now archived at Commons:Village_pump/Proposals/Archive/2024/11#username_verification_at_Commons was closed without conclusion.

As the given arguments prevail, I'm repeating the proposal:

Commons:Username policy since Special:Diff/355439634 says: "Use of the names of organizations is allowed on Commons only if you verify your account, proving that you are or represent the respective organization."

It has never been Common sense since then that account verification is mandatory at Commons. There are currently only 550 transclusions of Template:Verified account.

Compared to Wikipedias, either company accounts are discouraged completely, or account verification is done to lay open concflicts of interest, or to grant company accounts some leeway when uptating employee numbers or similar without proof. Nothing of all that applies to Commons, account verification doesn't make any sense here, not least as it doesn't and cannot replace file permissions. The Volunteer Response Team doesn't have procedures for account verification at Commons, nor any capacity to handle them.

At Commons:Volunteer Response Team/Noticeboard once in every while there are discussion about such verification, sometimes requested by third party users, sometimes requested by the affected users themselves, but in nearly all cases for no practical reason, but just because the policy says so.

To adjust the username policy to common practice and common sense, I suggest to replace:

Use of the names of organizations is allowed on Commons only if you verify your account, proving that you are or represent the respective organization.

to:

Use of the names of organizations is allowed on Commons. Account verification, proving that you are or represent the respective organization, shall happen only in controversial cases.

Please comment. Thank you. --Krd 14:35, 4 June 2025 (UTC)

• Support I agree with the stated proposal to remove the current text. I care so much about this issue that I wrote manifestos for reform at en:Wikipedia:Identity verification and Commons:Role account. My further opinions are beyond the scope of this stated proposal, and I could accept this proposal as is, but I do not like perpetuating the current system of identity verification even though this proposal would reduce it. As an alternative or supplement to this proposal, I would like to reform the identity verification process to be public with what users post on-wiki rather than private in VRT email, especially for corporate identity verification. If the process were more public and automated, then organizations could verify their own identities at will instead of getting a haphazard private review, and the wiki community could better review their identity evidence. This proposal is not about identity verification in general, but only about corporate identity verification. I think it would be too disruptive to quickly reform all of our processes, but starting only with corporate identity verification is a great start. Perhaps we could have a recommended user page template for corporations, and if they want to verify identity, then they fill it out and post to their userpage. Bluerasberry (talk) 15:09, 4 June 2025 (UTC)

  • If There are currently only 550 transclusions of Template:Verified account then where is the problem? If companies and other orgs don't want to have to verify which doesn't all that much effort, then they could just use a name that isn't their company name.
  • Could you or Krd, please respond to the concern and reason for why this policy exists, namely the potential problem of impersonation and otherwise misleading people (for example making them think badly about the org)?

  All in all I see no need for this change but a very clear problem that would result from it. Prototyperspective (talk) 10:35, 6 June 2025 (UTC)

• I saw the policy grounded in the wish to alleviate any fears about mischievous impersonifications, as it is actually already worded "[...]proving that you are or represent the respective organization." This is IMHO sensible and should be kept, I do not see the verification as proxy for copyright statements or the like. Regards, Grand-Duc (talk) 15:12, 4 June 2025 (UTC)

  How could such mischievous impersonifications look like at Commons? Is there any know case? Who can handle this in the future, if VRT cannot? Krd 15:35, 4 June 2025 (UTC)

  Before I could construct a hypothetical case, Jmabel said something below (-> "doing some borderline shitposting") that is likely in the same vein as my thinking. I do not know about an actual case, and as VRT handles the "Benutzernamensverifizierungen" in DE-WP, I do not see any technical hurdle to do the same for Commons (may it be a manpower issue?). Correct me please if I'm wrong. Regards, Grand-Duc (talk) 22:51, 4 June 2025 (UTC)

  As I already mentioned in my initial post, the fact that other projects do it is a moot argument. Perhaps it makes sense for them, perhaps not, but Commons is not Wikipedia. If one user misbehaves, they will be blocked, and then perhaps renamed, but that doesn't mean all user have to verify because one could or could not do wrong. Krd 04:11, 5 June 2025 (UTC)

   Oppose per Grand-Duc's explanation. And maybe one could allow/better-enable orgs to prove they actually run the account without VRT involvement. Prototyperspective (talk) 21:33, 5 June 2025 (UTC)

• Re "The Volunteer Response Team doesn't have procedures for account verification at Commons, nor any capacity to handle them": We do occasionally do account verifications (see {{Verified account}}) so that prolific uploaders who also upload their work elsewhere do not have to repeatedly send permissions to VRT. To me, whether verification is required does not depend on whether the account represents an organization or a person - it depends on whether the account represents some person/entity that is famous or has an alternate online presence (such as social media or personal website) that would make it theoretically possible for someone to impersonate them by downloading their images from their website and uploading them to Commons. -- King of ♥ ♦ ♣ ♠ 17:00, 4 June 2025 (UTC)

I'm trying to understand how this fits in with other policies. (1) If an account is verified as belonging to an organization, and that account uploads content for which that organization clearly holds copyright, am I correct that we can skip the VRT process for those uploads? Because that is the main context in which I have seen accounts with organizational names used. (2) If we do not require that accounts with names of organizations be verified, am I correct that we will still have to have a process by which an organization can say, "That account does not represent us" and have it renamed or blocked? For example, someone could wreak quite a bit of havoc opening an account as, say, User:General Motors or User:UNESCO and doing some borderline shitposting. - Jmabel ! talk 18:30, 4 June 2025 (UTC)

Per all VRT experience, account verification cannot replace any file permisison at all. That a file is uploaded by User:General Motors doesn't at all mean the GM company is copyright holder of the files they upload. For the exact scenario VRT does have a permission procedure, i.e. Category:Custom license tags with ticket permission. Krd 04:06, 5 June 2025 (UTC)

If they upload content with a free license on their website we normally trust them that they have the permission to do so. If they do not upload it to their website but directly on Commons we require additional proof beyond who operates the account? This does not make sense. Independent of this I think account verification should not be done on every Wiki but centralised on meta. GPSLeo (talk) 05:12, 5 June 2025 (UTC)

Yes, the VRT offers them additional support to make them aware that they mistaken and are not copyright holder, which is the case in the majority of such cases per my VRT experience. Creating the impression that an upload by a verified account is more trustworthy than an unverified account, puts additional risk on the re-user. You can of course say that it's not our business to care. That's a valid argument, but I'd disagree. We can achieve a better result and at the same time have less work, without user verifications. Krd 07:28, 5 June 2025 (UTC)

Support I agree with this. Nemoralis (talk) 19:56, 5 June 2025 (UTC)

•  Support admittedly this isn't something I have much experience on. Nor do I necessarily understand how it fits with other policies per Jmabel's comment. That said, Krd has enough experience on here to know what their doing and there isn't any obvious issues with the proposal from what I can tell. So it makes sense. Except for the parts that don't, but whatever. I trust Krd knows what their proposing even if I don't completely understand it myself. --Adamant1 (talk) 07:20, 6 June 2025 (UTC)

•  Support I have never requested verification differently as in the proposed phrasing. As a VRT agent however, I did process requests from institutions that requested verification because the username policy says so.

In general, it makes uploads done by accounts with for instance the names of GLAM orgs and (well known) artists more trustworthy, and those users don't have to request VRT permission for every image, or every batch of images, anymore since the account is already verified through VRT. The verification that the account actually is who they say they are, helps them to re-use images they own the copyrights to, and that for instance they might have used on their websites or in communications before. This brings down the work load in image patrolling, in deletion requests, in restoring deleted images, and in VRT.

However it does not mean they are knowledgeable on the topic of copyrights, and does not mean that, for instance, if any GLAM org would upload an image of a work by Karel Appel, there is no need to request a validation for this specific image. Commons users need to be aware that the verification tag is for the account, and they can still raise concerns about the individual image copyrights as they see them. Ciell (talk) 07:40, 8 June 2025 (UTC)

• CONDITIONAL Support - the wording on the proposed change is a bit sloppy (no offense intended). i would suggest change the wording to THIS instead (the all caps is optional, using it to draw attention to the alteration):

Use of the names of organizations is allowed on Commons. Account verification, proving that you are or represent the respective organization, shall *BE REQUIRED* only in controversial cases." 

i see no reason to stop orgs from VOLUNTARILY verifying their username? which is what the original text of the proposed change would seem to mandate:

Use of the names of organizations is allowed on Commons. Account verification, proving that you are or represent the respective organization, shall happen only in controversial cases.

see the difference? Lx 121 (talk) 09:36, 29 June 2025 (UTC)

Certainly "shall be required" is better wording. - Jmabel ! talk 18:22, 29 June 2025 (UTC)

A reason for not offering voluntary verifications could be, as stated above, that there is no defined procedure and no ressources. Who will be handling these voluntary verifications? Krd 17:56, 20 July 2025 (UTC)

•  Support for the proposal, albeit with the Lx 121-proposed modified wording. --Túrelio (talk) 10:47, 4 July 2025 (UTC)

•  Oppose as worded The reason why we allow organization accounts on Commons is because we want to make it easy for organizations to upload files under free licenses. The reason why we want to verify such accounts is because, if there's any question as to whether an account is actually controlled by the organization it claims to be, per the precautionary principle, we have to delete. I'm not sure what "controversial cases" actually means here, but I can see it being misinterpreted in ways that are counterproductive (interpretations of "controversial cases" where the organization is controversial in the opinion of the person demanding enforcement.) What I would support is a revision that doesn't make it mandatory, but that's much more explicit about why verification for organization exists. For example, Use of the names of organizations is allowed on Commons. Whether an account uses the name of an organization or not, if an account uploads a work that was previously published elsewhere not under a free license, or if there is another reason to doubt that the account is authorized to release the work under a free license, the account will be required to verify that they are authorized by the copyright holder to release that work. When an organization account goes through this verification process for the first time, their account will be marked as verified, so that they won't need to go through the same process for every upload. Organization accounts can also proactively verify before they begin uploading, to make the process smoother. (The wording can get tweaked / condensed; I'm more fussed about the rationale for verification being explicit). The Squirrel Conspiracy (talk) 11:06, 4 July 2025 (UTC)

  Please see above: There seldom is any doubt that an organization account is operated by the organization. Even if there is some merginal doubt, is it not relevant, and to prove that is not the point. The point is that organizations often think they are copyright holders of their stuff, i.e. their CEO photo or their shop front photo, while they are not. Having such account verified not only addresses the wrong part of the problem, but also creates the wrong impression about a verified permission, which it isn't at all.

  Copyright cases are different from one file to the next. It doesn't make any sense at all to verify an account because the first file is a work-for-hire portrait when the next photo has no permission from the photographer and is a DW / has FOP issues. If an upload of an organization is doubtful, permission should be obtained for the doubtful file. Regardless if the account is verified. It it doesn't matter anywhere if an account if verified, account verification is useless work. --Krd 06:31, 6 July 2025 (UTC)

 Comment - i have no problem with tightening up the wording on "controversial". i do think it would certainly apply in any case where the claim to represent a particular org is disputed & there is a clear need for verification (which covers most of the big legal concerns), &/or when the user account in question is acting strangely or problematically. (whether the org itself is "controversial" is a MUCH stickier problem...) Lx 121 (talk) 15:51, 5 July 2025 (UTC)

• • I don't believe that corresponds to what Krd said is how the VRT views the matter. @Krd: would you care to comment? - Jmabel ! talk 00:21, 5 July 2025 (UTC)
•  Oppose I would like the current policy to be more diligently enforced. Any account who uploads on behalf of an organization should be verified. Yann (talk) 15:41, 4 July 2025 (UTC)

•  Support as Túrelio. Trusting Krd here if he says that the Commons VRT team does not have any capacity to handle account verifications at Commons and regular file permissions would be needed anyway. --Rosenzweig τ 15:57, 4 July 2025 (UTC)

  Hence my position that the verification should be tacked onto the permission request. An org account sends in permission, and when the VRT agent tags the file as having permission, they just tag the account as being verified. The Squirrel Conspiracy (talk) 03:50, 5 July 2025 (UTC)

•  Support with LX 121 wording changes. I'd prefer to have corporate accounts verified, but I'll trust in what VRT agents are saying and the policy can be changed. (I'll note that Krd left me a talk page message asking for feedback, which I don't consider canvassing because I hadn't decided before I read all the responses). Abzeronow (talk) 21:28, 4 July 2025 (UTC)

• Comment I am still not able to comprehend what "shall happen only in controversial cases" implies: how do we identify what is controversial or not. Imagine me creating an organisational account for the university I studied at (hitting no controversy), and then uploading stuff under free licenses. This would be misconduct, even "controversial cases" fails to recognise it. VRT definitely does not have the capacity to handle organisational account verification requests and I believe it should be pushed to the Foundation to curate a designated email queue to officially verify such accounts. TSC makes some good points. Even though the thing is not worded rightly, I will probably think of it as Accounts with organisational accounts are allowed on Wikimedia Commons subject to mandatory account verification. (how? that's a challenge because VRT does not have that capacity). I will support a re-phrase than an omit. I deem organisational account verifications as mandatory because there's an inherent risk as Yann points above. _signed, Aafi ^(talk) 04:36, 5 July 2025 (UTC)

  Can you elaborate on what the inherent risk is in your opinion? Yann said organizations should be verified but didn't explain why. (Or did you perhaps link the wrong username?) whym (talk) 10:23, 10 July 2025 (UTC)

  The inherent risk that I perceive is all around impostering (pretty much clear in the example I mentioned). We can't check on what email an account is registered with (unless we have CU/lookinfo permissions - VRT doesn't have that usually). I don't want to put the load of verifying accounts on my co-VRT agents, but making verification mandatory for controversial cases alone - seems odd. How do we decide what is controversial? Isn't this controversy in itself a result of the inherent doubts and risks that are visibly visible. I quoted Yann rightly about mandatory organisational verifications. However, how should the verifications happen is a question to debate. I don't have a very clear go around for that. Except that probably the Foundation helps the community. _signed, Aafi ^(talk) 17:25, 20 July 2025 (UTC)

•  Oppose per Yann. The need for account verification is a must as anyone can create an account that "represents" an organization and this will be a problem with licensing files. --Min☠︎rax^«¦talk¦» 06:39, 5 July 2025 (UTC)

• I would not block an organizational account which doesn't upload anything, but what's the point to have an account on Commons which can't upload anything? Yann (talk) 07:41, 5 July 2025 (UTC)

  We have plenty of users (good and bad) who don't do uploads. - Jmabel ! talk 17:49, 5 July 2025 (UTC)

•  Oppose At least in the currently proposed form. I think we should try the following first: 1. Procedure for transfer of verification at an other Wiki to Commons or (better) global verification. 2. Make a call for more people joining the VRT. GPSLeo (talk) 07:57, 5 July 2025 (UTC)
• Which VRT queue is supposed to be used for this now (and in the past)? I have access to permissions queues on VRT, and I cannot view the ticket linked from User:Jeff_G.. () --whym (talk) 13:30, 5 July 2025 (UTC)

  @Whym: It wasn't a licensing permission request. It was more of an OTRS (now VRT) volunteering request related to m:special:diff/16525595. Krd confirmed it in the following edit. The current name of the queue should be closely related to the current "volunteers-vrt" email address on renamed m:Template:VRT/Volunteering.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:34, 13 July 2025 (UTC)

  I wonder if it serves any purpose now. It sounds like once the request was closed, its use was over. whym (talk) 10:14, 19 July 2025 (UTC)

•  Support per Ciell and several others. -- Ooligan (talk) 01:35, 13 July 2025 (UTC)

  - with LX 121 suggested word changes. -- Ooligan (talk) 16:40, 17 July 2025 (UTC)

•  Support with LX 121 wording changes.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:39, 13 July 2025 (UTC)
•  Support I believe the proposal will reflect the reality more closely than the existing one. If people wish more proactive verification of organizations than now, that could be a good thing, but it would need to be done by a new set of volunteers who commit to perform the verification. A wording change (back) alone won't accomplish what they want. Also, I think it won't have to be mainly done using the VRT system - organizations often can and do use their official websites to verify accounts on external platforms. whym (talk) 12:13, 17 July 2025 (UTC)
•  Support per Túrelio and using the better wording as suggested by Lx 121. As of now we have 19,403 verified accounts at de:wp with a lot of tracking behind it. Commons and the VRT team handling Commons are absolutely unprepared for a mandatory process of this scale. That We can and should ask for verifications in selected cases whenever serious concerns arise about a particular user account. A few cases are easier to handle than all such user names. And I also agree that a verification can never be a shortcut to handle permissions in individual cases. --AFBorchert (talk) 07:20, 19 July 2025 (UTC)
•  Support as per Krd, I note that almost all opposing vote, if not all, comes from non-VRT members. Note that they can said their opinion of course, but that's is quite interesting. Christian Ferrer ^(talk) 18:30, 20 July 2025 (UTC)

Proposal: Tighten upload process and related policy.

Given that uploaders are expected to know and understand the status of works they upload, I am asking for opinions about tightening the upload and related policy, for post June 2025 uploads.

Namely :

1. Unless a (revocable) trusted uploader status is held by a User, any upload from the which has date later between 1930 and 2005 (Essentialy the pre Commons era), is automatically flagged for license review, and is indicated as such, the relevant template being added during the upload process. Bot users, GLAM and bulk uploaders would be able to apply for "trusted" status.
2. Commons should keep a list of Users granted 'trusted' status.
3. Uploads utilising specfic 'exemption' licenses such as {{PD-USgov}} should include a rationale as to why the exemption applies. In respect of 'non-renewal' of US works, this rationale should ideally include original registration numbers in the Catalog of Copyright Entries or Copyright Record Books,(Commons trust it's users to have undertaken a reasonable effort to identify the status of a work.)
4. Uploads from Internet Archive, Hathi and Google should not use bare links, but the appropriate templates, with bare links being converted by an appropriate bot. As part of the use of these templates, the additional reviewed template should be added either by trusted uploaders, or during the license review. On new uploads, identifiable bare links, are bot migrated to the templated forms.
5. Works upload without a license, are 'auto-flagged; for deletion during the upload process, or by a bot subsquently.
6. Unchallanged speedy/copyvio deletions, are deleted on 'expiry' of the time period in the relevant template (admin bot enforced.) Striking this as comments below say this already happens.
7. Uncontested "Deletion requests" (Those that get no replies) are after the expiration of the consultation period, automated closes, with the files being removed, but with "Unedeletion information" being given when the request is auto closed.
8. Abolish "no consensus to delete" outcomes. A file is either 'Delete' or 'Keep' with a decision reached.
9. On uploads of books or publications, if multiple volumes, printings or editions exist, then it's the date of most recent applicable edition used to determine the license, if there is no information about earlier ones. (This would mean that if a 'Revised' edition of a work by the same authors exists, It is the revised edition that is used to determine if the status is acceptable on Commons, even if the earlier edition would otherwise be permitted. This is to ensure text integrity.)

ShakespeareFan00 (talk) 10:01, 6 June 2025 (UTC)

Didn't understand all the points you propose but  Oppose for now point Abolish "no consensus" outcomes. A file is either 'Delete' or 'Keep' with a decision reached. – if there is no consensus either way then it's not good to claim or call it otherwise; moreover I don't know what you even mean by that since files are already either kept or deleted. Also #5 Works upload… is already done. Prototyperspective (talk) 10:39, 6 June 2025 (UTC)

A firm decision has to be reached about retaining (Keep) or removal (Delete) with a clear rationale as to either outcome. "No conesnsus to delete" cannot be used as a reason for closing the DR, which typically favours a file being retained. If a file/media is retained a compelling rationale for doing so should be stated on closure (which could include a 'Withdrawal(Kept) if the nominator found new information for example. Most DR's I've been involed with end in a clear outcome.

Commons needs to have a 'can we realisticaly prove it's 'status' (and usability)' culture, rather than a 'retain because we couldn't work out what was wrong' culture. Quite a lot of the contributors I've dealt with have the former rather than latter stance though, and such a shift, would to my viewpoint, further the sort of academic approaches Wikimedia projects aim for. ShakespeareFan00 (talk) 12:30, 6 June 2025 (UTC)

"No consensus for deletion" is a necessary rationale for DR closures that concern COM:SCOPE rather than questions concerning copyright. Not all DRs are about copyright issues and therefore consensus might matter. Some cases of De Minimis might also fall under "no consensus" (while others might fall under COM:PCP). Nakonana (talk) 13:11, 6 June 2025 (UTC)

1. There's already the user group "autopatrolled" for that, I think?

7.  Oppose Such DRs shouldn't be auto-closed / automatically deleted, because a lack of replies doesn't necessarily mean that there's no opposition to the DR. It could just mean that the DR in question did not attract anyone's attention and that nobody has looked at it (yet). It still requires at least one human user to assess the validity of the DR rationale. A bot cannot make such an assessment based on such a non-indicative criteria as "no replies". "No replies" doesn't say anything about copyright, SCOPE, etc. Nakonana (talk) 13:21, 6 June 2025 (UTC)

Do new uploads get auto tagged for license review with the specfific template? Autopatrol is for page contents typically. ShakespeareFan00 (talk) 16:29, 6 June 2025 (UTC)

Not a specific tag for license review, but autopatrolled means that the upload doesn't show up in "recent uploads" (or at least that's how it was explained to me here). Nakonana (talk) 17:11, 6 June 2025 (UTC)

Yup. One example could be a bogus DR that was overlooked or too absurd to be commented. --PantheraLeo1359531 😺 (talk) 20:10, 18 June 2025 (UTC)

•  Oppose Although purely procedurally. The upload/deletion process clearly needs to be tightened and there's some good ideas here about how to do that. I don't think it's a good idea to combine 9 different ideas into the some proposal. Each one needs it's own separate discussion and consensus. Otherwise it's just risks this turning into a potshot of random support and oppose votes without a clear outcome and no way to deal with it. --Adamant1 (talk) 13:56, 6 June 2025 (UTC)

@Adamant1: Another idea not listed here, is going to be controversial, and that is that the Upload process should look for specific authors, titles or publishers, and warn during the Upload process. PG has a set of Renewals for post 1964 "Books" (Commons also has a complete run of the CCE to 1978!), and if those sets of data were in Wikidata, it would not only be useful Biblographic data to have, it's potentially a means of having a more friendly Wikimedia way of doing pre upload screening, warning uploaders, rather than "Never uploaded anything by Disney!" filters more aggressive rights holder want to mandate on hosting sites. Of course getting that Data in Wikidata would be a Mars-shot project of itself. :( ShakespeareFan00 (talk) 15:55, 6 June 2025 (UTC)

That's an interesting idea. I thought about something similar awhile back where the uploader could put the creators name in and it would check the copyright status of their works on Wikidata. Since that information exists for a lot of people, if not individual works yet. Although it would take them putting in the name to begin but it's better then nothing. Maybe a lot of this stuff can be semi-automated once AI gets better. Who knows. Something needs to be done about the amount of COPYVIO that gets uploaded on here though. --Adamant1 (talk) 16:01, 6 June 2025 (UTC)

Some books and editions have Wikidata entries, but as always it's as case of someone needing to put the data in the system. ShakespeareFan00 (talk) 16:29, 6 June 2025 (UTC)

 Oppose - too restrictive, & also off-putting to users. what we have now works reasonably well; & if/when/as new problems develop, we can fine-tune our approach. there is no need to "bring the hammer down" rn; too much of a hammer/blanket/one-size-fits-all solution for a problem that we already have a process for.

also, on the matter of usa pre-1978 copyright NON-RENEWAL; ultimately the legal onus would be to show that a copyright WAS renewed, not to prove that it wasn't.... {insert joke about proving the negative here} ;P - Lx 121 (talk) 10:14, 30 June 2025 (UTC)

AND i do not like the "countdown" to automatic deletion if no one opposes IN TIME. that is pretty much ALWAYS a terrible idea. we should not have to babysit commons' files to make sure that they do not get deleted "by default", NOR should we have to waste our time lurking/stalking deletion discussions in order to prevent it. it MAKES EXTRA WORK for everybody.

& the list-keeping of "trusted" users just for uploading is another "CREEP" in administrative overhead & privacy-intrusiveness (& a fairly massive one at that). & we would STILL have to police those same "trusted" users to make sure that they aren't violating that "trust". so the net result is MORE WORK (again), & barely any real gain in the copyright-quality of the uploaded material as a whole, AND we make things @ commons a little bit MORE off-putting to noob users. Lx 121 (talk) 19:49, 5 July 2025 (UTC)

AND in practical terms, eliminating "no consensus to delete" outcomes means that either: a) unresolved deletion discussions GO ON & ON & ON & ON...... OR b) (more than likely) "no consensus" becomes DELETE BY DEFAULT. neither of which is an attractive result. Lx 121 (talk) 19:54, 5 July 2025 (UTC) .

and the user who drafted the proposal basically ADMITTED that deletion by default IS their goal, in some of their ^above^ comments. Lx 121 (talk) 19:59, 5 July 2025 (UTC)

• ALSO - the proposal as written has way too many separate proposals all lumped together(!) it would have been better to deal with these item-by-item, one at a time. Lx 121 (talk) 20:17, 9 July 2025 (UTC)

There are many different things proposed here.  Support the basic idea behind first point (of course, only if it doesn't result in a big work overload for administrators or license reviewers), but only for non-own work files, and with a date far before than 2005 (let's say, 1940?). Totally  Oppose point 7: if for whatever reason nobody looks at the DR, this could even lead to a vandal being able to delete a file by nominating it for deletion. MGeog2022 (talk) 10:38, 20 July 2025 (UTC)

Principle of least astonishment

What to do with mass uploaded PDF/DJVU which are not in use or verified?

Back in 2020 Fae and others uploaded a substantial proportion of the IA's collections. There was a reasonable good faith assumption at the time that these would be integrated into Commons and ultimately Wikisource, and that at some point the files would be checked for compatibility with Commons and Wikimedia objectives.

This didn't happen, and subsequently, it has been found that due to the metadata provided, and asepcts of the upload process used, widespread license errors, a number in copyright works (both PDF, dju and image media), and faulty metadata has resulted.

So what is the sensible response to this, given that asking Commons license reviewers to check every single upload is a farcical task, as is requesting a wipe of all unused files?

I'm against in favour of a massive 'nuke' delete, given that I have found compatible items, which HAVE subsequently been useful to Wikisource, without needing to re-upload them from IA directly. However, something has to be done, to avoid the 'problem' files becoming a time-bomb of potential issues. Would a more nuanced removal of post 1930 file be a possible solution? (I.E WE adopt the Hathi-Trust policy approach, of only considering pre 1930 media 'safe', and only allow media after this date on a case by case review by appropriate experts.) ShakespeareFan00 (talk) 13:41, 8 June 2025 (UTC)

A lot of the work of getting rid of these, without throwing out the baby with the bathwater, does not need to be done by people who are officially license reviewers. In particular, anyone can mark clearly problematic files for deletion. - Jmabel ! talk 03:57, 9 June 2025 (UTC)

OR mark them for a closer look... better for the baby that way ;P Lx 121 (talk) 10:51, 30 June 2025 (UTC)

Specic howlers, include clearly post 1930 works in error marked as PD-USGov, which they clearly are not.

@Jmabel: Are you able to help provide some hints or filters? I favour the removal of anything post 1930 on the grounds that date can be looked for relatively easily without getting into soecfic nuances, (or need to check external catalogs.).. ShakespeareFan00 (talk) 10:14, 9 June 2025 (UTC)

I've stopped short of calling for a CCI on Fae, given that all thier uploads were made in good faith, based on the infromation (and tools they had.) . But if it's going to take a CCI to solve issues that have persisted since the left, I think it should be. Is there a process for iniating one? Files tagged in error as PD-USGov is the largest problem. (An aside is the quality of the scans in places, but that's not something Commons generally worries about) ShakespeareFan00 (talk) 10:14, 9 June 2025 (UTC)

Some key areas I've noted:

Seed catalogs - Pre 1930 are PD-US and the license can be updated. I did some recatting this moring to diffuse the relevant categoru.

USPTO Library items, which are not US Gov works , but where tagged as such because they were tagged as FEDLINK collection items in the metadata. Some where PD-US, but not all.

Post 1978 Naval Postgraduate Student thesis. These are not PD-US-Gov works, despite some on Commons arguing that the writers of some of them are serving military, in some instances. Many deleted items of this type were not and have not been authored by Federal entities ( Typically these are civilian, state or Foreign military.) Pre 1978 items have been considered no-notice(when none was found), but the collection includes items from various other institutions, and requires review.

Clearly post 1930 journals, tagged in PD as error, because IA had followed a library practice of recording serials date as the date of the first issue of the serial, as opposed to the cover date of the publication, in metadata, which was used in error during the upload process.

Flickr 'Commons' images tagged as PD by default, although examining the source publication proved the publciation and images were not.

and others...

Fae uploaded at least 500,000 IA items I think, and it's far far easier to make a bold decision and conclude the process to check these pre or post upload failed, or never happened, then it is to expect Commons users and viewers to do audits themselves that they would have reasonably expected a responsible library or archive to have undertaken beforehand. A broad post 1930 cutoff cull deletion would quickly resolve the issue, without the extended period of non-action from Commons Processes. ShakespeareFan00 (talk) 10:33, 9 June 2025 (UTC)

Not to say I think there should be a mass deletion of everything uploaded by Fae but they imported a ton of stuff from GLAMs that have questionable origins, licenses, Etc Etc. And a good percentage of the files have never been organized or checked to make sure they are PD. Like photographs that have no evidence of prior publication but they aren't being deleted because of coming from a library or wherever. Deleting everything post 1930 would obviously be an option but then there's a lot of post 1930 stuff that's still PD in the USA and it wouldn't deal with pre-1930 works that haven't been published before either. Individual DRs for a million files to make its done right obviously wouldn't scale. But then again, I'm probably against a mass culling. So I don't know. It doesn't seem like there's a good solution here. --Adamant1 (talk) 15:49, 9 June 2025 (UTC)

All books which are in the public domain are also in scope. So I oppose deleting any of them. I have quite a number of reservations about Fae's uploads (notably poor categorization), but I don't see any reason to delete them. Yann (talk) 16:48, 9 June 2025 (UTC)

Books have to have some plausible educational value. If I took a random assortment of non-educational freely-licensed photos off of Flickr and made them into a book, they wouldn't ipso facto become educational or in scope. That said, to your main point, I would certainly prefer if we didn't delete Fae's uploads en masse, but I can understand why someone would want to, as copyright violations need to be taken seriously and Fae evidently just noped out of the project years ago and will not be around to fix the mess personally. —Justin (koavf)❤T☮C☺M☯ 16:57, 9 June 2025 (UTC)

'Books have to have some plausible educational value' - you are treading on DANGEROUS GROUND right there :P WHO decides? & your "if i made a book of random flickr pics" arguement is a straw-man @ best; particularly in that we are discussed historical published works collected & uploaded on here. Lx 121 (talk) 10:43, 30 June 2025 (UTC)

Take this for example.. Category:Henry G. Gilbert Nursery and Seed Trade Catalog Collection needs splitting by year, and the erronous USGove licenses need upadting to PD-US , PD-no-renewal, PD-no-notice etc.. NONE of these are US Gov works, post 1925 files just got tagged with it as these were under a USDA collection...I've been attempting to diffuse manually, but barely made a dent. ShakespeareFan00 (talk) 17:44, 9 June 2025 (UTC)

There's definitely a problem of some of these government collections including works authored by non-government entities, probably by accident. I seem to recall finding a couple of PDFs of mid-20th century novels (unambiguously under copyright) in one of these collections, and I wouldn't doubt for a moment that there's more buried in there. Omphalographer (talk) 20:09, 10 June 2025 (UTC)

Strongly  Oppose. I understand the problem, but files should never be prejudged because of file format. Of course, every detected copyvio must be deleted. But no file should ever be deleted “just in case” without any evidence against it. In fact, given certain problems with Internet Archive (low budget, judicial cases against it, bad backup policy while located in an earthquake-prone area, etc), I think that the more IA books that we host in Commons, the best.

If we don't mass delete JPG images "because they are not verified", the same applies to PDF files. Moreover, most public domain PDF files are "autoverified" (date of publication, lack of copyright notice for pre-1978 works from the USA, etc), so files should only be deleted on evidence. MGeog2022 (talk) 09:54, 21 June 2025 (UTC)

Sorry if I "I became passionate" too soon :-). I see now that we are talking only about a very specific mass upload, not about PDF files from IA generally. This is a really complex situation. I maintain that we should keep all public domain (or freely licensed) books imported from IA, but the possibility of having thousands of copyvios is not a minor problem. A possible solution would be to add a template to all those files, saying that there is some possibility that the work is copyrighted, so it is to be used at the user's own risk. Perhaps a software script (specifically developed with this purpose) could be used to find most copyvios (based on author, date, country, presence of copyright notice or copyright registrations and renewals where applicable, etc). It would be really complex (not impossible, use of AI tools could help; ChatGPT tells you that for any well known book or author), but the script could be kept to do the same with every book uploaded in the future. MGeog2022 (talk) 10:10, 21 June 2025 (UTC)

Retaining copies of works whose copyright status is unclear is not a viable option; please refer to Commons:Project scope/Precautionary principle. Omphalographer (talk) 18:05, 21 June 2025 (UTC)

@Omphalographer: of course. But an evidence about why its status is unclear is needed, case by case. We sholudn't delete any >100 year old work, any work that is clearly a work of the US federal government, etc. Precautionay principle is applied case by case, it's not "delete everything unless the few things that have been carefully reviewed". MGeog2022 (talk) 11:33, 22 June 2025 (UTC)

The precautionary principle is that where there is significant doubt about the freedom of a particular file, it should be deleted.. I understand that this doubt is after having a look at the file, never before doing so. MGeog2022 (talk) 11:35, 22 June 2025 (UTC)

STRONGLY  Oppose - any mass-deletion; we can & should go through the material item-by-item (especially since the heavily favoured probability is that most of the material in question will be FINE, & we are talking about only a limited fraction that might be problematic). if we find a big enough problem, we can create a PROJECT for sorting it. Lx 121 (talk) 10:48, 30 June 2025 (UTC)

 Comment - btw, what is a CCI? i get that IA = internet archive, but i just spent few minutes on a commons search for cci didn't get anything useful (thus far) xD Lx 121 (talk) 11:13, 30 June 2025 (UTC)

CCI = en:Wikipedia:Contributor copyright investigations. It’s mostly an en-wiki term. Tvpuppy (talk) 11:26, 30 June 2025 (UTC)

Deemed approval of proposals

There are many proposals with very low discussion and voting participation. We currently do not have a clear guideline if these proposals are considered as accepted or not. I therefore suggest that we introduce a deemed approval policy: If there is no opposition against a proposal it is considered approved after a given time. The steps needed would be the following:

1. There is no opposition against the proposal indicated by an  Oppose mark.
2. The last comment on the proposal section was 14 days ago.
3. After the 14 days there is a "deemed approval warning" to be posted on the Commons:Village pump.
4. If there is no opposition after 7 more days the proposal is considered accepted.

GPSLeo (talk) 15:11, 12 June 2025 (UTC)

Lean toward oppose. There needs to be some support! I don't think a proposal that simply gets no attention at all should automatically be adopted.

Also, two questions to GPSLeo:

1. if your proposal were adopted, would my comment here be considered as not opposing because I didn't use the {{O}} template?
2. what if someone responds with a comment requesting a clarification, and the original poster ignores it? Does that not put things on hold unless someone overtly opposes? - Jmabel ! talk 18:41, 12 June 2025 (UTC)

For the first point I would suggest that user has to be asked if this should be considered as a veto against a deemed approval or not. Same for the second: The user with the question should be asked if this should be considered as opposing as long as the question is not answered. If the proposer and the user who had the question do not react I would consider this a dead proposal if there are no other users supporting it and not even the proposer reacts to comments. GPSLeo (talk) 19:56, 12 June 2025 (UTC)

•  Oppose. Policy? Why not a deemed denied policy? A proposal with little participation does not sound like something that should get automatic approval. Foundationally, deemed approval is dubious. We do not want involved parties closing a discussion; this lets involved parties do that. What about proposals that have been shot down in the past but are ignored today? Is this an opportunity for forum shopping? What about technical proposals that may have implications that few understand? If a proposal does not find good traction, then it should just fade away. Glrx (talk) 14:13, 14 June 2025 (UTC)

 Support. The de facto situation is that it seemed that only Admins were allowed to approve, and all active Admins were allowing many sections to just wither on the vine. In parliamentary proceedings, proposals sometimes start with "without objection ...", perhaps we could consider that here, with one "support" considered as "seconded".   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 15:05, 14 June 2025 (UTC)

I would take lack of response as "not sure". Why not have a small scale trial when there is no substantial reaction? A trial might provide some data for people to discuss about. By trial, I mean something like "let's try holding this event just one time at a limited scale" or "let's try applying this rule for the next 2 weeks", without making it a done deal. whym (talk) 00:54, 15 June 2025 (UTC)

I've always understood a lack of response as tacit approval. Otherwise nothing could be done on here due to the inherently low participation with most discussions. But to me, if no one disapproves of something then it should be treated the same as approval. --Adamant1 (talk) 20:49, 15 June 2025 (UTC)

If you identify low participation as a problem and wish to have higher participation, how about trying Template:Centralized discussion, MediaWiki:Sitenotice and MediaWiki:WatchlistNotice to get more attention? whym (talk) 12:46, 19 June 2025 (UTC)

In my experience, Centralized Discussion is basically useless. It's not uncommon for discussions to sit on the list for years, long after any actual discussion has ended. (For instance, until a few minutes ago, there was an 18-month-old discussion on the list, with the last comment just over a year ago.) Omphalographer (talk) 19:47, 19 June 2025 (UTC)

It's not about whether actual discussion "has ended" in your view but whether the issue has been decided/settled or not. If it hasn't been closed and the question is valid and of significance, then it makes sense to let it sit there. The problem would be just with too few users weighing in on these. Prototyperspective (talk) 20:29, 19 June 2025 (UTC)

The template describes itself as "a compact index to active discussions of potential community-wide interest" (emphasis mine). It's not meant as an index of every discussion ever which failed to reach a definitive conclusion; that would make it even less useful than it currently is. Omphalographer (talk) 20:37, 19 June 2025 (UTC)

It's still active if it is of substantial large-scale community-wide interest and the last comment is from over 1 year ago if it's not yet solved, especially if it's a complex difficult subject. Such need more users to participate and links to these belong there which has few links anyway. Prototyperspective (talk) 11:36, 20 June 2025 (UTC)

 Oppose No need for this; a case of a solution in search of a problem that may cause problems when e.g. people don't comment on something because they didn't see it as a proposal or because for example there are technical difficulties making people unable to comment or when it's something absurd on which people don't comment so it gets archived off the page. It's not too much to require at least 1 support comment. If there is an approval policy then it would need to be far more nuanced and e.g. consider account age/experience so lots of new nonwikimedia accounts commenting that template doesn't lead to proposals being accepted; however there is no need for this. Prototyperspective (talk) 11:41, 20 June 2025 (UTC)

So you propose that if a proposal has one support and no oppose vote it is accepted as long as these accounts are not new? GPSLeo (talk) 05:42, 21 June 2025 (UTC)

There is no need to define that. It depends on the case, maybe usually yes but that's pretty rare. (Also, it's not just whether accounts are new but whether or not or how much they are experienced contributors who for example understand what the implications of the proposed changes will be and some other things.) Prototyperspective (talk) 12:26, 21 June 2025 (UTC)

 Oppose Apathy is not consent. The Squirrel Conspiracy (talk) 21:42, 20 June 2025 (UTC)

 Oppose I am sympathetic to the problems of getting the Commons community to turn out for discussions. But a silent consensus is not sufficient to show the broad consensus required to create policy. --AntiCompositeNumber (talk) 20:17, 21 June 2025 (UTC)

 Oppose Abstention is not an approval, and freedom to abstention is IMO a very important thing, it is a matter of principle. Christian Ferrer ^(talk) 06:41, 22 June 2025 (UTC)

replacing human decision (that is based on reason, logic and common sense) with mechanical stringent rules is bad. RoyZuo (talk) 13:45, 23 June 2025 (UTC)

If this doesn't go anywhere then there should at least be a requirement that proposals with low or no turnout after 7 days are announced on the Village Pump to increase participation. Otherwise what's the alternative here? Just accept that most, if not, all proposals are going to be rejected on their face just because know one votes on most of them? If so, that seems kind of muh. --Adamant1 (talk) 17:24, 23 June 2025 (UTC)

 Oppose lack of enthusiasm is a silent “oppose” vote. I’ve closed lots of project proposals on Meta not because there was a consensus against them, but a complete lack of enthusiasm for them. Unopposed DRs (which seem to be the precedent here) get closed as “delete” because deletion is cheap (files can be undeleted at any time and we have over 121 million files, 90% of which are wholly redundant and never see use). Implementing a new rule is not cheap. There should be widespread unambiguous support for the rule. Dronebogus (talk) 22:08, 24 June 2025 (UTC)

Unopposed DRs (which seem to be the precedent here) get closed as “delete” because deletion is cheap (files can be undeleted at any time. Really sad, unless copyvio is reasonably suspected. For example, Wikipedia page history allows to see past versions of articles, but its images may be absent if they were deleted. In addition, deleted files don't save storage space in WMF servers (they are kept in the same way as if they were not deleted). I understand that the thousandth photo of a person's intimate parts is deleted. I can't understand that the thousandth photo of a cocker dog may be deleted only because there are better ones. Aside from copyvios and legal matters, the reason for out of scope deletions should only be to prevent Commons from becoming what it isn't (a site for amateur art, porn, social networking, etc). Other than that, it's a destructive nonesense. MGeog2022 (talk) 09:36, 27 July 2025 (UTC)

This supposing that out of scope is the proposed reason: it may be the best image on its topic, but, if unused, it may be deleted only because nobody noticed the DR, according to what you said. Yes, undeletion is easy, but someone must notice the file's deletion first. It should not be taken for granted that the file's uploader will remain here, let's say, 25 years after the upload, to protect his/her file or request its undeletion. If what you said, as you said it, is right, this seems to be one of the worst problems facing Commons. What's the point in taking all precautions with speedy deletion requests (something that is fully needed, no doubt), when even a vandal can delete a file by using a normal DR? MGeog2022 (talk) 09:50, 27 July 2025 (UTC)

Sorry for so many replies, but this has ignited me :-). In the same way we have a precautionary principle to delete copyvios, perhaps another precautionary principle is needed to keep non-copyvio files. Deletion or non-deletion is not based on non-opposition, nor in votes: it's based in policies. Non-opposition to a DR doesn't mean that the file doesn't comply with policies. Even when policies are subjective, as is the case of project scope or redundant files, the opinion of 1 or 2 persons isn't relevant about it. So caution should be applied: there is no damage in keeping a file that has some remote option of being out of scope or being totally redundant. There is huge damage in doing the opposite. MGeog2022 (talk) 10:08, 27 July 2025 (UTC)

I can't understand that the thousandth photo of a cocker dog may be deleted only because there are better ones. When I say this, I'm talking about having variety, but, if lots of people start uploading photos of their own pet, house, car, etc, of course, it should be stopped, but always respecting all pre-existing files, unless they are extremely low quality. If a topic is really well covered, including all possible variety that is deemed convenient (and that's a very huge number of files for most topics), new uploads can be restricted to high quality files, but decent files that have been here for years, maybe decades, shouldn't be removed because of this. Wikipedia takes care about its own past (full edit history is available for all pages, except for deleted revisions), why shouldn't Commons do the same? MGeog2022 (talk) 10:58, 27 July 2025 (UTC)

Keep in mind that not all images are photographic. We delete unused diagrams somewhat regularly, typically because they're of low quality, outdated, inaccurate, or are otherwise unlikely to be reusable. Omphalographer (talk) 16:54, 27 July 2025 (UTC)

Inaccurate or very low quality: out of scope.

Outdated diagram: if formerly used in a Wikipedia article, very useful when viewing past versions of the article. It's a pity how little historic preservation is being considered. That's similar to when some TV stations reused video tapes, erasing some relevant historical filmations. Maybe even worse here, since storage doesn't cost so much to WMF, and no space saving is gained by doing it, since deleted files are (fortunately) kept on storage.

Returning to the original topic, I refuse to believe that this is true:

Unopposed DRs (which seem to be the precedent here) get closed as “delete” because deletion is cheap (files can be undeleted at any time

I suppose it refers to some unfortunate isolated case. I could find several examples of the contrary, such as this. MGeog2022 (talk) 19:47, 27 July 2025 (UTC)

In fact, this very conversation, will be preserved and publicly accesible indefinitely, as part of Village Pump's archived pages. I think that any image that was used for years in Wikipedia has far more historical value. MGeog2022 (talk) 20:01, 27 July 2025 (UTC)

not only  Oppose with the same reasoning as Dronebogus/Christian Ferrer. Possibly however, I think it should be common sense that approved policies can be opened up for discussion again when enough opposition has cropped up after they were originally approved/adopted. Meaning, a hypothetical 6:3 policy should be open for debate again on this proposal page once at least three opposing voices have gathered on the policy talk page, given that the post-adoption votes turn it into a 6:6 policy. Such a rule would allow proposals with very low support to be adopted, but rescinded later if they turn out to be disadvantageous. --Enyavar (talk) 19:08, 27 June 2025 (UTC)

 Oppose - respectfully this suggestion is "ass-backwards"; any proposal should be considered as default "rejected" IF/UNLESS there is some clear indication of consensus-support. if one persons says "hey let's set the building on fire" & nobody responds/objects, that DOES NOT mean the proposal should be accepted.... :P Lx 121 (talk) 09:25, 29 June 2025 (UTC)

 Oppose Agree completely with The Squirrel Conspiracy succinct statement "Apathy is not consent." -- Infrogmation of New Orleans (talk) 19:35, 5 July 2025 (UTC)

Strongly  Oppose, terrible things could be approved in this way. Maybe some kind of "This proposal needs attention" warning could be used, or, simply, the admin could judge if the proposal is right or wrong to approve or reject it (this is far from ideal, but it would be far better than approve by default, or even that approving or rejecting because of only 1 vote from an ordinary user). MGeog2022 (talk) 09:54, 27 July 2025 (UTC)

A new desk or task force for contacting rightsholders asking them to release under WMC licenses?

What does this community think about a “help desk” or volunteer team (I imagine something like Wikipedia’s Resource Exchange) dedicated to taking requests to contact the owners of specific media works to ask them to release the work under a WMC license, and facilitating that release?

So, someone posts a video of a never-before-filmed beetle molting on Instagram. Someone on Commons makes a post at the help desk referring to that video, with a link. A volunteer reaches out to the videographer, explaining that the video is of great encyclopedic value, and encouraging the release of the video under an open license. If the owner is willing, the volunteer can help them release it, either through the VRT process or by making a declaration on the original platform of posting (as simple as commenting under one’s own social media post).

There’s so much valuable media shared online, and every time I have reached out to a poster to ask if they’d be willing to release, they have responded with great enthusiasm and done so. I think that a desk to streamline this and process requests from volunteers could lead to a lot of amazing encyclopedic material getting added to Commons. Eager to hear the community’s thoughts. Zanahary (talk) 02:48, 24 June 2025 (UTC)

@Zanahary: Are you volunteering to fill that role?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 02:59, 24 June 2025 (UTC)

I would love to do that! I have reached out a few times to people for their photos and videos—both scientists and ordinary online posters—to facilitate their release via VRT and publicly-declared CC licenses, and I’d be very happy to be a part of a more systematized effort to help free media online. Zanahary (talk) 03:06, 24 June 2025 (UTC)

See also outreach:   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 13:02, 24 June 2025 (UTC)

•  Support Although I feel like it should be more of something like an informal Wikiproject/group then something like the Volunteer Response Team. But having a central place for people to chat about and coordinate contacting rightsholders to see if they will freely license their works is a pretty good idea. I think there's something similar for lobbying governments to create better FOP laws. --Adamant1 (talk) 08:25, 24 June 2025 (UTC)

 Support Commons:WikiProject Permission requests already exists, though it has been a bit moribund. - Jmabel ! talk 16:13, 24 June 2025 (UTC)

 Support And we should also establish best practices and scripts (not JavaScript scripts but pre-written words to copy and paste) for this purpose. I've gotten some great work off of Reddit (which I no longer use) and Flickr by asking. —Justin (koavf)❤T☮C☺M☯ 21:03, 24 June 2025 (UTC)

 Strong support This is really needed. Often, only the awareness of free license is missing, and raising awareness can lead to new opportunities --PantheraLeo1359531 😺 (talk) 09:53, 25 June 2025 (UTC)

I'm glad people like this idea. I've initiated a draft for the desk, based on the defunct WikiProject Permission requests here. I encourage others to edit and workshop it, directly and via this discussion. @Adamant1 @Jmabel @Koavf @PantheraLeo1359531 User:Chaotic Enby, I know you're a wizard—if this idea interests you at all, please take a crack! Zanahary (talk) 08:47, 29 June 2025 (UTC)

 Strong support, love the idea! And another wizard I can help with, sounds fun! Chaotic Enby (talk) 09:47, 29 June 2025 (UTC)

Hooray! I really know nothing about coding and wizardry, so please (a message to you and everyone): run wild. My dream is that this is linked in the community portal. Zanahary (talk) 17:50, 29 June 2025 (UTC)

Just completed it at User:Chaotic Enby/Request desk.js – to test it, you can install my script and the wizard should then display on your page.

Ideally, it should be made into a MediaWiki namespace script so it can be called through the URL (and not require installing). This way, we can add a default button to User:Zanahary/Request desk that reloads the page while activating the JS through a URL parameter. Chaotic Enby (talk) 19:04, 4 July 2025 (UTC)

@Chaotic Enby: if this affects what we say at Commons:Uploading works by a third party#How they can grant a license (and how you upload), where we reference Commons:WikiProject Permission requests, could you please edit accordingly? Thanks in advance. - Jmabel ! talk 00:24, 5 July 2025 (UTC)

Since the new request desk is still in userspace, it doesn't make sense to add a link to it right now, but I'll do it once the discussion is closed and all is "officially" moved into place! Thanks for the reminder. Chaotic Enby (talk) 00:27, 5 July 2025 (UTC)

 Support - though i think it should mostly be a wiki-project type of -thing. Lx 121 (talk) 15:29, 5 July 2025 (UTC)

& comment - if we are doing this, we should give some thought on how to prioritise both sources to ask, & materials to seek permission for. :) Lx 121 (talk) 15:29, 5 July 2025 (UTC)

 Support.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:49, 6 July 2025 (UTC)

Another thought: it would be good if, in cases of publicly declared free licensing, requested materials could be uploaded either normally (with a link to the post or comment by the author indicating release) or via the VRT process, so that the uploaded could verify for the VRT without doxxing their social media account (by publicly sharing a link to a post under which they have commented inquiring about releasing under a CC license). Zanahary (talk) 23:35, 6 July 2025 (UTC)

Don't we already have this? A desk for contacting rightsholders and email template resources? What would be different? I know the former is pretty dead, but that leads to the question: why would this succeed where that failed? IMO the most valuable thing we could do is to create a centralized, named "team" that's vetted and can introduce themselves as "Hi, I'm from the Wikimedia License Requests Team" rather than "Hey, I'm a random person from Wikipedia". That would require some thought as to who we would want on that front line, and I wonder about our ability to maintain an active volunteer base of people willing to take responsibility for not jsut requests but follow-up questions and the upload process. Really, most requests can be as simple as a boilerplate message to send the rights holder and a boilerplate release for them to submit to VRT, in which case I'd say efforts are best spent revamping instructions for volunteers. It's just in those rare cases where you have to make a good sales pitch to overcome objections or answer technical licensing questions that you need some advanced knowledge/skills. I could see a noticeboard being useful to get help with those questions, but don't know why a VP wouldn't work well enough. — Rhododendrites ^talk |  21:09, 14 July 2025 (UTC)

I think a reboot of WikiProject Permission Requests that is more heavily featured (qua desk rather than WikiProject) rather than tucked away, would have a much easier time building momentum. I really like your idea of creating a centralized team. Zanahary (talk) 21:39, 14 July 2025 (UTC)

 Support: The more avenues that may lead to more high-quality media, the better. Might even bring a few more good people to the project. Don't see any harm in trying. -- Cl3phact0 (talk) 07:09, 15 July 2025 (UTC)

 Support --JackFromWisconsin (talk) 18:33, 19 July 2025 (UTC)

 Support but as Rhododendrites pointed out, seems like we already have Commons:WikiProject Permission requests. Some1 (talk) 02:06, 21 July 2025 (UTC)

 Strong oppose If one wants a file to be on Commons, they are free to obtain permission themselves. No additional team is needed for that, and no need exists for a new repository of ideas that never will be worked on. If I'm mistaken, will the list of supporters be the list of volunteers for the new team? How much capacity do they have, and why isn't that better spent on existing backlogs? --Krd 16:19, 26 July 2025 (UTC)

Add an outcome of LicenseReview

Add an outcome "indeterminable / review impossible" for Template:LicenseReview.

Reason:

for example, File:Jordan protest in front of police2.PNG claims to be made by VOA, but because the youtube video is gone it's impossible to verify. nonetheless, the claim appears trustworthy, so it doesnt seem appropriate to either pass or fail it. a sensible thing to do would be to simply remove the Template:LicenseReview.

But, simply removing it will not prevent certain users slapping the template on it again.

As such, add an outcome, termed "indeterminable" or "review impossible", to signify that users have tried to review the file but could not succeed because source is gone, but there is no significant doubt about the authenticity of the claim, so the file is tolerated. RoyZuo (talk) 10:40, 25 February 2025 (UTC)

 Support - Jmabel ! talk 21:14, 25 February 2025 (UTC)

 Support per Commons:Village_pump#Category:License_review_needed and the links mentioned there. --MGA73 (talk) 07:49, 28 February 2025 (UTC)

 Support Christian Ferrer ^(talk) 08:44, 28 February 2025 (UTC)

 Support --Yann (talk) 09:24, 28 February 2025 (UTC)

 Support --Grand-Duc (talk) 13:25, 28 February 2025 (UTC)

 Support only if there is some sufficient method to reduce cases of this being set mistakenly. People should not set it if a youtube video is down and they can't check it anymore. They should only set it if they also checked the Wayback Machine properly to see whether it has it archived. Prototyperspective (talk) 14:41, 5 March 2025 (UTC)

 Support 1989 (talk) 19:32, 5 March 2025 (UTC)

 Support good idea. and also... if another LR finds another source about image, he should change it to passed. modern_primat ^{ඞඞඞ ----TALK} 02:34, 19 March 2025 (UTC)

 Support - --Ooligan (talk) 15:37, 1 May 2025 (UTC)

•  Support: But can this please be extended to former (now deleted) US Government flickr images too? For example, I managed to find non-flickr archive sources for these US-NIST images here: File:National Cybersecurity Center of Excellence MOU Signing.jpg and File:Brain Sensor.jpg but there is no NIST archive for File:Storage tanks that comprise the NZERTF’s domestic hot water system.jpg Do we delete the last image than? Secondly, I worked hard to find archive sources for these old US-NIOSH flickr images here: File:Black lung screening.jpg, here: File:Chilean Miners.jpg and here: File:Deepwater Horizon oil spill beach cleanup.jpg but cannot any archive for this image which was uploaded by the same uploader from the now deleted Niosh flickr account for File:Fleet Fisheries Processing Center.jpg This second last image is used...and I wonder if it is at risk of deletion too. I can pass the now deleted US-Government flickr image if it says NIOSH or CDC in the metadata but if it says nothing, I Cannot do anything at all. Any views Yann or Jmabel ? Best, --Leoboudv (talk) 20:37, 23 March 2025 (UTC)

  This applies to anything that cannot be passed, but for which users do not have significant doubt about the copyright claim for now. RoyZuo (talk) 12:51, 24 March 2025 (UTC)

  @Yann: I don't see why presumed U.S. government images would be any different from anything else that we can no longer verify. If it looks like the uploader was generally doing what they should, and there is no serious reason to doubt that, we should keep it.

  Question, though: I thought as of about a year ago we stopped doing any systematic review of PD images such as U.S. government images. Do I misunderstand what was going on here and here? - Jmabel ! talk 01:24, 31 March 2025 (UTC)

•  Comment: No you are correct Jmabel I did not know of this development. But since I had time, I decided to check for non-flickr US Government Department sourced images...and succeeded in finding quite a few still fortunately. With Trump II now in power, I wonder if the USAID flickr site will exist soon as he has fired so many US Government Department employees now. VOA's website may soon be gone too sadly. The NIST and NZERT flickr accounts closed a few years ago. Best, --Leoboudv (talk) 00:10, 1 April 2025 (UTC)

 Support MGeog2022 (talk) 11:41, 18 April 2025 (UTC)

 Comment Your example of File:Jordan protest in front of police2.PNG is actually one on which I, as a reviewer myself, found a roundabout way to pass the review. Fortunately, VOA maintains a directory of contributors, including the editor named as author in the example file. Google made me find the listing of contributions of Elizabeth Arrott on the VOA page, where this is listed: https://www.voanews.com/a/jordanian-protests-call-for-revolution-toppling-of-king/1547601.html . The date and general appearance of the images there fit our upload, hence I passed the review. Regards, Grand-Duc (talk) 13:25, 28 February 2025 (UTC)

•  Question I wonder if it should be a simple "indeterminable" or if there should be a field where reviewer could explain why the file could be kept even if it could not be reviewed. I imagine that if reveiwer think the file should be deleted then the review would be failed instead. --MGA73 (talk) 11:08, 4 March 2025 (UTC)

  it's not "kept". it's merely tolerated. anyone could send it to DR if they have a significant doubt of the claimed licence. RoyZuo (talk) 12:55, 5 March 2025 (UTC)

  Yeah but then the question is if reviewer should (be able to) add a reason why they tolerate the file. --MGA73 (talk) 14:09, 5 March 2025 (UTC)

  I think it's hard to explain the "lack of significant doubt". RoyZuo (talk) 19:27, 6 March 2025 (UTC)

  Any of the following would be "significant doubt":

  1. can be found by reverse image search, and some results might suggest the image has been published elsewhere by different claimants of copyright predating commons upload.
  2. uploader has rampant copyvio history.
  3. the claimed source doesnt seem to exist.
  4. unlikely claim (e.g. claims to be ccbysa from disney but disney most probably doesnt publish ccbysa; photo of north korean soldier in north korean tank but claims to be us-army photo and pd; claimed source website has weird domain that's more typical of content farm / spam...)

  ...

  if the reviewer cannot find a way to critique it, that will be the lack of significant doubt. RoyZuo (talk) 19:42, 6 March 2025 (UTC)

  I agree that it may be easier to explay why something looks fishy than why not. So I guess your plan is that reviewer just add an "indeterminable" and then the template would add a suitable text. I can live with that. Next question is what such a text should be. Perhaps something like "A reviewer have reviewed this file but it was not possible to confirm the license because the file is not available on the provided source. However, reviewer did not find significant doubt about the validity of the license claim. If you disagree you may start a deletion request and explain why you think there is significant doubt as of why the license claim is valid."? --MGA73 (talk) 09:14, 7 March 2025 (UTC)

  Yes something along those lines will work. RoyZuo (talk) 09:59, 7 March 2025 (UTC)

  An optional "reason" parameter is helpful too.

  For example #c-Grand-Duc-20250228132500-Add_an_outcome_of_LicenseReview is commendable, but still that's just circumstantial evidence because the exact image or the video was not found at the VOA website. So if I were to decide, instead of "passing" it, I would let it be "indeterminable", with reason=Grand-Duc's analysis. (Because there's a mini concern: VOA sometimes reuses other news agencies' works, sometimes even mixing external and their own together in one article.) RoyZuo (talk) 10:11, 7 March 2025 (UTC)

  Please visit COM:Questionable YouTube videos if you would like to view (and maybe add) YouTube channels who have used phony/suspicious CC BY licenses. JohnCWiesenthal (talk) 18:14, 7 March 2025 (UTC)

•  Comment I think we need someone to make a suggestion. I tried at Template_talk:LicenseReview#Outcome but it did not work as expected. --MGA73 (talk) 19:07, 6 May 2025 (UTC)

I do not mean a proposal but a solution :) --MGA73 (talk) 04:50, 19 May 2025 (UTC)

Somehow, despite near-unanimity, this was archived without resolution. I don't think there is any doubt about the desirability; really, all that is missing is a concrete proposal for the name of this outcome. - Jmabel ! talk 16:39, 24 June 2025 (UTC)

@Jmabel: "indeterminable" is as good as any, and the shorter of the two. All in favor?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 17:17, 24 June 2025 (UTC)

• Works for me :-) --MGA73 (talk) 18:04, 24 June 2025 (UTC)
• Fine with me. - Jmabel ! talk 22:01, 24 June 2025 (UTC)

  !votes, anyone?   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:56, 25 June 2025 (UTC)

•  Support I thought I had voted on this before it was archived but I don't see my name up there. It sounds like a good idea though. --Adamant1 (talk) 04:02, 26 June 2025 (UTC)

Amendment to Commons:AI-generated media

Hello,

I’d like to propose two amendments of Commons:AI-generated media. Firstly, that it gets upgraded from guideline to policy.

Then, a content change: Commons should in my opinion ban the utterly large majority of AI generated media, at least for the time being. I’m advocating for a wait-and-see approach.

This is a direct outcome of ongoing judicial challenges in the US and our actual policies Commons:Fair use and Commons:Precautionary principle. The purpose is to avoid harm to Commons, should courts deem the current procedures of AI compagnies to be against the law. I’ll detail my reasoning below.

I got aware of several court cases through articles in several news outlets (partly in German, but they often happen to cite their sources) about the broad subject of AI generated media:

• https://www.theguardian.com/technology/2025/jun/25/anthropic-did-not-breach-copyright-when-training-ai-on-books-without-permission-court-rules “Anthropic did not breach copyright when training AI on books without permission, court rules“ – but this relies on US fair use provisions, according to the judge. Excerpt: „Alsup added, however, that Anthropic’s copying and storage of more than 7m pirated books in a central library infringed the authors’ copyrights and was not fair use – although the company later bought “millions” of print books as well. The judge has ordered a trial in December to determine how much Anthropic owes for the infringement.“
• In the same vein: Meta again got caught torrenting from shadow libraries, https://arstechnica.com/tech-policy/2025/02/meta-torrented-over-81-7tb-of-pirated-books-to-train-ai-authors-say/
• https://www.computerbase.de/artikel/netzpolitik/ai-copy-right-klagen-2025.93168/ is referencing a study (https://arxiv.org/abs/2505.12546) discussing the fact that Meta’s Llama 3.1 LLM is able to hand out quite a lot (42%) of JK Rowling’s Harry Potter and the Philosopher’s stone; which constitutes a clear copyright infringement. This phenomenon apparently gets called „memorization“ by IT professionals.
• https://www.wired.com/story/thomson-reuters-ai-copyright-lawsuit/ „Thomson Reuters Wins First Major AI Copyright Case in the US“, which directly lead to the demise of the opponent, one such AI company.
• https://www.heise.de/news/KI-Training-mit-Buechern-OpenAI-mit-Teilerfolg-bei-Copyright-Klage-von-Autoren-9627596.html , a demonstration of copyright infringements by the claimants against OpenAI was held possible.
• The fad about OpenAI making imagery in Studio Ghibli style, https://www.theatlantic.com/technology/archive/2025/05/openai-studio-ghibli-images/682791/, may have been critical from a copyright standpoint.

There’s ample further evidence that LLM training can eventually be admissible by US fair use, but constitutes first and foremost copyright infringements. That means that output by these LLM can be seen as fruits of the poisonous tree and would go against out two policies stated above, COM:Fair use and COM:PRP.

Hence, at least imagery that was generated in full by DALL-E, Midjourney, ChatGPT, etc. is certainly problematic.

So, while it’s possible that court cases in the future may result in the legality of AI generated media and hence their admissibility here, the current quagmire is so that we should, even if not strictly constrained by law, have a narrow interpretation of extant site policies and generally disallow AI-generated media site-wide for the time being. That may change in the future. I can envision (and thus propose) a single exception: modern Photoshop or other photo editing software versions offer AI assisting tools. Their usage can constitute the borderline for current admissibility, as I think that any AI generated parts of such imagery stand behind the human-controlled parts and should be COM:De minimis. Regards, Grand-Duc (talk) 02:03, 27 June 2025 (UTC)

This is not about the resulting images. Also e.g. here Legal experts agree that AI-generated works do not normally have an author in the legal sense, says lawyer Joerg Heidrich, who also advises AI companies: “For the user, this means that they can freely use an AI-generated image and post it on their website, for example - but on the other hand, anyone else can do the same with the same image.”. This has been discussed many times and you're not even talking about the copyright license of the images themselves. Prototyperspective (talk) 13:46, 27 June 2025 (UTC)

 Comment The "fruits of the poisonous tree" argument resonates strongly with me. I've long held that it's ethically dubious/hypocritical for a WMF project to take a strong stance on respecting copyright and licensing, while also accepting images from software tools that explicitly state that they do not respect copyright and licensing, and in fact are only able to exist because they knowingly ignore copyright and licensing.

That said, the legal landscape is a mess at the moment. There are a lot of cases working through a lot of different courts, and the results that have trickled in have been contradictory, meaning that we're almost certainly going to see cases reach higher courts. It's premature to draw any conclusions about how AI images are ultimately going to be classified vis-a-vis fair use.

In the meantime, my observation has been that the overwhelming majority of AI images uploaded to the project thus far have been out of scope, but that a small number of users have fought tooth and nail to keep them, using what I view to be weak arguments about hypothetical future use. I think Just because an AI image is interesting, pretty, or looks like a work of art, that doesn't mean that it is necessarily within the scope of Commons. needs to be given much more consideration. We should continue to aggressively cull the existing pool of AI images and stem the tide of new images based on scope, rather than legal principles. The Squirrel Conspiracy (talk) 16:01, 27 June 2025 (UTC)

COM:SCOPE finds its limit for culling purposes (great expression!) in COM:INUSE, as a lot of (smaller) Wikis don't have rules regulating AI-generated media. A deletion based upon COM:Fair use and COM:PRP can't be negated by INUSE. Regards, Grand-Duc (talk) 18:50, 29 June 2025 (UTC)

That's not a good reason to shoehorn restrictions outside of their intended scope. The precautory principle is about comitting a known copyright violation on the assumption that we can get away with it, not about a deletionist understanding of what is and what isn't a copyright violation. Cambalachero (talk) 19:59, 1 July 2025 (UTC)

 Oppose: There are trials, yes, but how many of those trials ruled that AI images are copyright violations, and how many reached the point where no further appeals are possible? If the law rules that, all AI images can be deleted in minutes by a bot (they are all tagged with {{PD-algorithm}}), but until then, according to the law AI images are free. Cambalachero (talk) 16:39, 27 June 2025 (UTC)

 Comment Legal opinions about this should come from a lawyer in the US, preferably one representing the WMF. Apocheir (talk) 21:10, 27 June 2025 (UTC)

 Comment This is a meta comment, but why not use Commons talk:AI-generated media for this discussion? I realize not every topic has an obvious centralized talk page to use, but this topic seems to have one. I think using dedicated places helps to save everyone's time. One giant page is more difficult to skim through than separate pages. That said, I think it's fine to leave short pointers here to advertise newly started discussions elsewhere, as written in Template:Village pump/Proposals/Header, if you want to get attention. whym (talk) 02:34, 28 June 2025 (UTC)

@Whym: Really? I see no precedent for that in the template's history.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:50, 28 June 2025 (UTC)

I was referring to what the template says about "significant discussions taking place elsewhere". It's been there since 2011. I think it was always something you can choose to do, while I don't know how common it was. I just wanted to raise awareness for the possibility. whym (talk) 09:39, 30 June 2025 (UTC)

Sorry, I forgot to ping: Jeff G. whym (talk) 01:33, 5 July 2025 (UTC)

 Oppose: - ai images are NOT copyrightable in the usa. that part of the law is pretty solid. the ROUNDABOUT arguements about IP rights on using materials for training models are "in play" & tbd (& imho actually not very valid, just a money grab, & likely to Be DEEPLY problematic in all sorts of ways, if the rent-seekers do prevail) BUT that decision would effect TRAINING MODELS/MATERIALS not "end-product" directly. (AND the big gorilla in the room is that, for many / most purposes the ai-biulders could pretty easily switch to PUBLIC DOMAIN materials for training; with a whole lot of open-source material as well). so tl,dr - whatever the outcome of these trials/legal disputes, is is UNLIKELY to change the fact that ai created content is NOT COPYRIGHT-ABLE, & it is also pretty unlikely that all pre-existing ai-created content would suddenly be banned. the lawsuits are about the "old-school" content-creation industry trying to wring money out of the AI boom. (hence rent-seeking :P) Lx 121 (talk) 09:15, 29 June 2025 (UTC)

You are much mistaken in thinking "for many / most purposes the ai-biulders could pretty easily switch to PUBLIC DOMAIN materials for training". In fact, the big players are experiencing since ~2023 or 2024 the same thing about data that conglomerates in the petro business are experiencing with peak oil. There are quite not enough native raw materials to train and improve the LLM any further, and that is including the whole available internet. So, the limited subset of public domain stuff is woefully inadequate for the business of OpenAI, Meta, Anthropic, etc. Because of that, they are actually trying to train their LLM with synthetic data generated by other LLM, reinforcing (cultural) biases, racism, other errors in the process.

The issue with problematic training processes in regard to the outputs is that a potentially unlawful "machine" can produce "contaminated" output, meaning that a LLM trained with unlawful sources makes unlawful derivatives. That's IMHO the difference between a human, producing copyrightable content and a LLM which output is not protected in the US. The human, who lawfully (with bought or licensed books, movies, songs, art...) or unlawfully (when this human consumes e.g. pirated movies, books or songs...) learned about e.g. textual or musical content and who bases own creativity upon these sources, always adds own brain-processed things upon any thing he makes. The LLM doesn't work like this, it always only makes mash-ups, derivatives, of existing things (from the point of the law).

I would rather put the brakes upon uploading AI stuff now and wait for where the judicial challenges end. That's IMHO better than incurring a much larger clean-up endeavour later if higher courts deem AI generated media as unlawful derivatives of protected materials. I'm open to allow such media again, when the law framework has been clarified (in regard to LLM training), provided the stuff is in scope. Regards, Grand-Duc (talk) 18:47, 29 June 2025 (UTC)

respectfully i must DISAGREE with your assertion that: THE ENTIRE HISTORY OF HUMAN ART & LITERATURE up to & before 1930 is inadequate as material for an(y) AI LLM training models (PLUS the entire universe of open source materials available!).

& "waiting for the judicial challenges to end" is like waiting for the weather to stop happening, or waiting for gravity to stop working, or at least waiting for the next geological epoch to begin. i.e.: NOT GOING TO HAPPEN ANYTIME SOON. i see no valid reason to DENY/IGNORE/BLOCK all AI-created content/media-files on this basis. it sounds more like a backdoor-roundabout arguement from the "old school" flesh & blood content-creators who want to ban/block AI works as much as possible, for as long as possible... Lx 121 (talk) 10:27, 30 June 2025 (UTC)

May I suggest that you google "Growth of human knowledge"? The "THE ENTIRE HISTORY OF HUMAN ART & LITERATURE up to & before 1930" and the remainder of FOSS stuff is actually only a drop in the bucket for LLM training purposes - the human knowledge grows nearly exponentially with a doubling rate between 24-12 months in the current decade. Furthermore, everything that is related to information technologies, genetics, oncology, antibiotics, modern pop culture, etc., cannot be trained with raw materials from 1930 and before - these ideas didn't exist then or only barely.

About "waiting for the judicial challenges to end" - OK, that may have been poorly worded. I meant to say to wait for the development of a sound case law base, meaning several appellate court rulings or one from the Supreme Court. That is a limited time frame. (BTW, some scientists actually do advocate for the establishing of a new geological epoch, setting the border between the Holocene to the suggested Anthropocene around the 1950s. So, your example of "at least waiting for the next geological epoch to begin" has somewhat backfired...). Regards, Grand-Duc (talk) 23:31, 30 June 2025 (UTC)

comment - HA! i knew you were going to bring that up, BUT if we accept the anthropocene, then: a) we are already in it, the starting point is already in the past tense & b) the idea has been pretty thoroughly rejected by geologists, especially with an arbitrary 20th century start date (the most notable change in rock strata being radioisotopes). an earlier date like the neolthic revolution might have merits, but then it is basically a rename of most of the holocene.

& as for llm's; technical specialisations might need more, newer material. but general language, arts, philosophy, etc. are more than adequately represented by the world up to dec 31st, 1929 (& counting, plus open source!). so a lot of ai work, esp creative arts stuff, can be done with that. & you could probably train a pretty good AGI on that too (then take it to school for inadequately represented/updated subjects).

AND there is the whole "quantity vs quality" thing. re: growth of human knowledge. especially for "creative content" (which is what we are mostly talking about here re: ai-generated materials). nearly ALL human art-forms (of all types, including music, literature,etc.) are building on previous works. IF you trained a creative content ai on ALL AVAILABLE works that are pre-1930, & cut it off there (&/or only included subsequent works that are also pd or open source), you would STILL have covered almost all of the critical source material for human artistic inspiration, you would only be missing the last ~95 years of "iterations" (& you would even get early modern art, cinema, & scifi into the mix, plus jazz) Lx 121 (talk) 15:23, 5 July 2025 (UTC)

 Oppose This proposal overreaches both legally and practically. None of the cited court cases have resulted in a final ruling that AI-generated media are inherently unlawful, nor that such output is retroactively tainted as "fruits of the poisonous tree". The training methods of some LLMs may be under scrutiny, but Commons evaluates media files, not machine learning pipelines. Commons' role is not to preemptively ban entire classes of media based on speculative future outcomes. We should stick to evaluating files individually under existing policy (especially COM:SCOPE and COM:LICENSE), not rewrite site-wide rules based on uncertainty or worst-case hypotheticals. A blanket ban would be premature, overly broad, and inconsistent with Commons' precedent of requiring concrete legal reasons, not conjecture, to exclude file types. --Jonatan Svensson Glad (talk) 18:56, 29 June 2025 (UTC)

+1 to Jonatan. We should not stop scrutinizing uploads. If AI files are evaluated as OoS and/or Licence violations, we must delete them. --Enyavar (talk) 10:08, 30 June 2025 (UTC)

•  Comment neutral, I just make a comment about the following wording within UK section: "it may therefore be necessary to determine whether the work was generated in the United Kingdom". Note that copyright protection generally comes with a publication (i.e. content being made available to the public), so the word "generated" looks not adequat to me when we talk about copyright. E.g. if I generate an artwork (with AI or not) in my computer in UK (or France, ect..., and that I firstly publish it online e.g. within Wikimedia Commons, then (if eligible) it is potentially under US copyright protection, and only under UK copyright protection via international convention(s). Of course if it is generated online, therefore automatically published, then this is well the first publication, and I guess that in that case the country of origin depend from where are the server. I'm not a native English speaker but I think that the words "generated" and "published" are two different things especially in matter of copyright. Christian Ferrer ^(talk) 12:20, 1 July 2025 (UTC)
•  Comment support. Unlike some of the previous contributors, I still fail to see Commons as a repository for any free stuff that can be scrounged from the net. "Original" AI works have failure built-in, either by getting us in legal trouble at some point, or by flooding us with trash. We should limit the exposure of the project to it as much as possible. Alexpl (talk) 09:42, 4 July 2025 (UTC)

  Commons:Project scope is already a policy and should prevent the scenarios you describe. Cambalachero (talk) 14:29, 4 July 2025 (UTC)

  It does not because SCOPE gets trumped by INUSE. You can't get e.g. a trashy AI hallucination of the likeness some long-dead historical figure (a Viking, a Maya ruler, a Persian scientist...) deleted with SCOPE when some guy added it to a Wikipedia article in a smaller project that hasn't a policy of its own governing AI-generated media; despite it adding ZERO knowledge and only providing eye candy. Regards, Grand-Duc (talk) 14:56, 4 July 2025 (UTC)

  Actually, INUSE clearly says "It should be stressed that Commons does not overrule other projects about what is in scope". What you want to do has already been considered, and it is already rejected in Commons' policies. Cambalachero (talk) 18:43, 4 July 2025 (UTC)

 Oppose yet another attempt to purge as many AI generated images from Commons as possible as sloppily as possible. There is no actual legal basis here, in actuality coming down to “I don’t like it”. Dronebogus (talk) 21:58, 7 July 2025 (UTC)

•  Support Gute Idee, jetzt schon zuviel AI Mist. --Isderion (talk) 16:55, 17 July 2025 (UTC)

Disable the Collections extension on Commons

The Collections extension is, for some reason, still enabled on Commons, and even has its own "create a book" tool link in the Tools menu (or in the sidebar on older skins). It probably should not be.

This extension was designed for creating printable collections of pages on Wikipedia. It does not serve any useful purpose on Commons. Some users are occasionally using it to create completely useless books, typically consisting mostly or entirely of pages unsuitable for print such as Main Page, the user's own user page, or Special:Upload.

Even in the rare instances where a user has created a collection of gallery pages (such as User:Mrchristian/Books/berlin), there is currently no way for the user to obtain a printable copy of that collection through Wikimedia - Wikimedia's PDF renderer for collections was disabled in 2017, and there is no indication that it will ever be reenabled. The currently available "download as PDF" tool only renders the content of a single page, not a collection of pages. PediaPress is a commercial service, and does not allow the download of PDFs at all.

Given the limitations of this tool and the apparent unwillingness of WMF to provide support for it, the enwiki community chose to progressively disable it on that wiki between 2019 and 2021. It remains enabled on Commons because there has been no similar action on this site.

Can we agree that this extension should be disabled, as entirely as possible, on Commons?

Omphalographer (talk) 19:07, 30 June 2025 (UTC)

•  Support I've deleted all the books with nonsense test edits and self-promotion. A grand total of 6 plausible uses are left - that means this extension has (at most) been used correctly 6 times on Commons. Even if the technical issues are resolved, this is simply not useful for Commons. Pi.1415926535 (talk) 21:22, 30 June 2025 (UTC)
•  Support - Jmabel ! talk 21:52, 30 June 2025 (UTC)
•  Support --Adamant1 (talk) 22:44, 30 June 2025 (UTC)
•  Support - Counterfeit Purses (talk) 15:25, 1 July 2025 (UTC)
•  Support --Yann (talk) 16:19, 1 July 2025 (UTC)
•  Support Bidgee (talk) 17:41, 1 July 2025 (UTC)
•  Support Incall ^talk 07:46, 3 July 2025 (UTC)
•  Comment - i am not clear on why this feature is problematic? as long as it is NOT being mis-used in the mainspace, why do we care what or how ppl organize materials in their userspaces? (OR for off-wiki end uses) is it a data-storage &/pr data-processing issue? the finished pdf's might gulp a lot of bytes, but the CODE to assemble them surely does not?

the lack of tech support & development if unfortunate, as is the apparent difficulty in exporting the results. but these are technical challenges, & fixable ones. it does not seem like a good reason to completely kill off a potentially very useful feature. Lx 121 (talk) 16:01, 5 July 2025 (UTC)

This feature was being misused in the mainspace until Pi recently deleted the books which users had created there (none of which were meaningful books). More broadly, though - the Collections feature is largely broken as it currently exists. Its objective was to allow users to create downloadable PDF books; it does not currently allow users to do that, it has not allowed users to do that in the last eight years, and there is no indication that this is likely to change at any point in the future. Users can continue to create lists of pages in their userspace, should they desire to do so, but I don't see the continued purpose in having a button on every page that offers to let users "Create a book", but which doesn't follow through on that promise. Omphalographer (talk) 20:14, 5 July 2025 (UTC)

Making graphDataImport into a gadget

I propose that the userscript graphDataImport be made available as an opt-in gadget on Commons.

The script helps convert defunct {{Graph:}} wikicode in most Wikipedia language versions — still present in thousands of articles — into usable Commons data pages for the mediawiki Graph extension, via a simple user interface. Since its creation on 21 May, it has been used to generate at least 50 `.tab` pages and 50 `.chart` pages by users from multiple countries.

The tool has been reviewed and improved both through user feedback and in dialogue with an experienced developer of a related gadget (see Commons talk:User scripts#GraphDataImport). The GraphDataImport userscript and GraphBot have been harmonized with each other, although still some differences exist in the output. For example, graphDataImport sets the .tab and .chart page license to CC0-1.0. GraphDataImport handles a wider range of languages, templates, and niche cases than GraphBot, including the curve selection transform, although the script requires a bit more manual effort from the user.

Making it available as a gadget would lower the barrier for contributors who might otherwise be discouraged from converting old graphs due to the requirement of manual userscript installation. The script may be further adapted in the future as the Chart extension evolves. However, that development project concluded on 1 July, and the extension is now expected to enter a slower-paced maintenance phase. Tomastvivlaren (talk) 00:25, 3 July 2025 (UTC)

Generally think it would be good to do this but converting graphs to the new charts extension seems like a very temporary thing and I don't think there are gadgets for temporary things like this that take some months to some years. Prototyperspective (talk) 11:01, 28 July 2025 (UTC)

Ban user created permission and licensing templates

There's been some talk on here lately about how the licensing terms for files are to complicated. At least in my own experience a lot of that has to do with user created permission and licensing templates. In most, if not all, cases they add extra requirements or restrictions that aren't included in the original versions of the CCO or PD licenses that the files are supposedly licensed as. For instance, requiring that someone who uses the image in a commercial product send a copy of said product to the author of the image. At their best, such terms just needlessly over complicate things. At worst they go against the goal of Commons to be a repository of media that "can be used by anyone, anywhere, for any purpose." There shouldn't be extra, added terms to reuse on top of the ones already imposed by the normal CCO licenses.

Aside from that, the templates create a situation where the pages for every other file on here is completely different and can't be edited or altered without asking for permission from the uploader. One example being this file, where the summary and categories can't be edited because of the template for it created by the uploader. Editors shouldn't have to ask uploaders permission to edit a files description or to change how it's categorized, period. In that case, the file should be licensed as "PD-US-no notice" since it's not the uploader's own work anyway. But the custom template makes it impossible to change without going through the uploader and having them do it. Again, such permission templates go against the spirit of the project and just add needless extra complication to editing. So user created permission and licensing templates should be banned. Adamant1 (talk) 02:31, 5 July 2025 (UTC)

I think this can be discussed at the relevant guideline's talk page. whym (talk) 03:10, 5 July 2025 (UTC)

Thanks for the suggestion. I added a link to the discussion on the talk page. I rather it take place here though since random talk pages don't usually get much participation and I'd like it to have a clear outcome. --Adamant1 (talk) 03:25, 5 July 2025 (UTC)

How about doing it the other way around - discuss at the talk page, and advertise it here? whym (talk) 03:28, 5 July 2025 (UTC)

What licensing templates were not created by a user? Do you mean "user-specific", rather than "user-created"? - Jmabel ! talk 04:29, 5 July 2025 (UTC)

Yeah, "user-specific" is probably a better way to phrase it. By that I mean templates created by individual uploaders (not through any kind of approval process) that include extra terms outside of the normal CCO requirements and/or that makes it impossible for other editors to edit the files page without having to ask the uploader or otherwise have them do it. Hopefully that clarifies things. --Adamant1 (talk) 04:42, 5 July 2025 (UTC)

Proposals should be discussed here for maximum visibility.

Licenses: The guideline already disallows additional license terms: No user template can require additional conditions of use above and beyond the terms of their chosen license. Additional conditions such as notification can be requested but must not be required. If you see anyone adding conditions, the guideline should be brought to their attention, and the issue brought to administrators if the user does not promptly fix it. Similarly, the guideline requires that any standard license templates be substed, and disallows custom templates that combine license and user information. Can you point to any currently-used user-specific license templates, in particular any that don't already violate this guideline?

Infoboxes: There's a large number of specific templates that include infoboxes. Some are for the uploads of one specific user, which I would support disallowing. Some provide standard information for specific uses (such as the widely-used {{Hurricane auto track map 1}}) and are just fine. The user whose upload you linked to has several bad habits: creating custom templates for a handful of files, using incorrect author and license information in those templates, and adding content categories in the templates that cannot be modified on individual files. Whatever changes we make should disallow those bad habits while not banning useful templates like the hurricane maps. Pi.1415926535 (talk) 04:40, 5 July 2025 (UTC)

@Pi.1415926535: It's not the only phrasing I've seen on here but one example is the permission with File:Participants of IIIT workshop on 07 December, 2019.jpg where it has extra conditions in the third, forth, and six bullet points. The uploader wanting people to send them a message or email if they use image isn't so bad, but it's still an added condition on top of the normal licensing terms. Although point four and six seem to particularly go against the goals of the project. Especially point four. With infoboxes, I don't have a problem with templates like the ones for hurricane maps. It's more the other kind that I have an issue with and want banned. --Adamant1 (talk) 04:57, 5 July 2025 (UTC)

I agree that the third and fourth bullet points of User:I.Mahesh/Photo credit box 2019 are not acceptable conditions to add. (It would be fine to phrase them as requests, but not requirements.) The sixth bullet point was common around here for a bit, but the WMF legal advice has been changed, and it should be removed or rephrased.

Relevant links: Category:Templates for specific users and Category:User custom license tags Pi.1415926535 (talk) 05:04, 5 July 2025 (UTC)

Visibility can be achieved by leaving here a pointer to advertise. If needed, you can advertise more than one time per discussion. I think Commons has become too big to keep doing this one giant space for all proposals. It still has its place, but separate discussion pages are better for signal-to-noise ratio, archiving, and searching. I think the latter should be encouraged rather than discouraged. whym (talk) 13:37, 5 July 2025 (UTC)

Trying to understand what is and is not acceptable.

• Let's say Seattle Municipal Archives had someone with an account of their own here instead of my uploading on their behalf. Would there be a problem with a template like Template:Seattle Municipal Archives via Flickr, which is not a license template, but does explain their preferred way to be attributed?
• Are we talking about eliminating existing templates, banning their continued use, or what? If eliminating, how do we handle licenses offered by users who are no longer active, or not even alive? I don't think we can retroactively change their licensing terms. Do we then delete all such files, take them up on a case-by-case basis, or what? This could get very messy, and I could imagine a lot of undesirable consequences. - Jmabel ! talk 05:31, 5 July 2025 (UTC)

  Requests are allowed, per Commons:User-specific galleries, templates and categories. Zanahary (talk) 05:16, 10 July 2025 (UTC)

Jmabel ! talk 05:31, 5 July 2025 (UTC)

@Jmabel: Since it says "preferred attribution", that's fine - it doesn't add any requirements above and beyond the license. Any templates that don't violate the current wording of COM:USER can be kept for existing files; I think any banning of them should not be retroactive. For existing files (using a custom template or not) that have disallowed extra-restrictive license terms, that's a good question, and might need someone with legal knowledge to weigh in. It may be that choosing a CC license is sufficient to release the file under that license, and the other terms are invalid and can be removed. Or it may be that they are still valid, and the files would have to be properly licensed by the users or removed. Pi.1415926535 (talk) 06:56, 5 July 2025 (UTC)

Outside of the issue of custom licenses - which I agree should be avoided - can we examine the reasons why users feel the need to add custom permission templates to their uploads? If users feel the standard {{Information}} and CC license templates don't make it clear enough that the uploader needs to be credited by reusers, maybe we should look into improving those templates. Omphalographer (talk) 19:09, 9 July 2025 (UTC)

@Omphalographer: I've noticed that very few uploaders use "author" in {{Self}} or "attribution" in the various CC-BY and CC-BY-SA templates. I'm guessing that is because it is not supported by the Upload Wizard (one more reason I almost never use the Upload Wizard). - Jmabel ! talk 20:48, 9 July 2025 (UTC)

@Jmabel: what do you mean by "attribution is not supported" in the upload wizard? I think that it's possible to make an attribution statement while using the wizard, but it's implemented with bugs, see Commons:Upload Wizard feedback#Redundant template addition. Regards, Grand-Duc (talk) 22:36, 9 July 2025 (UTC)

@Grand-Duc: impossible, buggy, whatever: it doesn't work well, so virtually no one uses it. And, following your link, I can see why. That is crap UI. If they wanted to edit wikitext, they'd just use Commons:Upload. They should be able to give their attribution (with the default for "own work" being something like author=Wikimedia Commons user [[User:FOO|FOO]]); bad enough that they have to deal with a wikilink, but they certainly shouldn't have to correctly edit a template usage. Also, in my opinion, the default should be that overt restatement of author/attribution in {{Self}}, which I'm sure greatly reduces the bad attributions to just "Wikimedia Commons". - Jmabel ! talk 23:08, 9 July 2025 (UTC)

• user created permission and licensing templates

That's a reasonable point, given that WP has never taken automated licence processing seriously enough to look at features like a REL.

However there's a mistake underlying much of Adamant1's broader actions than this proposal (and the scatter-gun of DRs they're firing off):

A widely-used and easily recognised licence template embedded within a novel user template is not a problem.

It is not the same thing as creating a new (and awkward to process) class of licence template and thus licences.

The problem complained of in this proposal is real, and I would support that aspect of it. However it is not as broad a problem as Adamant1 complains of. If anyone wants to work on it, start by looking at the status of the implied licences (if any). Don't just assume that any sort of user wrapper around a valid licence then makes it into a problem. Andy Dingley (talk) 10:59, 10 July 2025 (UTC)

I nominated a single template for deletion based on opinions of myself and others in this conversation that said template is a problem. In no way is that me "firing off a scatter-gun of deletion requests" or whatever. So spare me the defense, insulting tone. I could really care less about these types of templates in theory, the issue with yours is that they are impossible to edit or modify the categories on without (as you put it in DR) "sorting it out through the talk page."

There's absolutely no reason someone should have to "sort out" basic, uncontroversial edits to a file with the uploader through the talk page. It's just anti-user and goes against the goals of the project. As well as policy IMO. You said in the DR that this whole thing is "make-work playing at adminship." I'd argue that goes for these types of templates. Your misusing templates to protect and gatekeep basic edits to file you upload. Just because you can't legitimately protect them from edits since your not an admin. That's not what templates exist for. --Adamant1 (talk) 11:16, 10 July 2025 (UTC)

I think there are two topics:

1. New licenses: They should definitely only be created with community approval.
2. Custom license wrappers: The should be banned entirely. The additional information from the author/institution should be in a separate template to allow simple maintenance. Wrappers for {{Information}} or similar should also not exist except for special cases like map tiles or book pages.

GPSLeo (talk) 17:51, 13 July 2025 (UTC)

I'd say that the ban should be on new user created licenses, not on licensing templates. For example, licensing templates such as this, that show that the file is licensed under CC-BY and providing the name of the author to be credited and a link to his/her/its home page, are no problem (whether they are for an external author or institution, or for a Commons user). MGeog2022 (talk) 21:27, 15 July 2025 (UTC)

Related DR for anyone who wants to give their opinion, Commons:Deletion requests/Template:Scans of correspondence from the West Gloucestershire Power Company in the 1940s. --Adamant1 (talk) 12:06, 10 July 2025 (UTC)

What happens if someone copy/pastes the same licensing information onto each file page instead of uses a template? If that would be prohibited, too, presumably then the underlying proposal is about what can and cannot be requested and/or required of reusers, which gets pretty complicated. CC licenses do allow some customization. — Rhododendrites ^talk |  22:39, 10 July 2025 (UTC)

I'm inclined to agree that only admins who know what they're doing should be able to create/edit Licensing/Permission templates. The customized template created by a non-admin mentioned in this discussion seems rather strange. See also this decision to delete an inappropriate US-PD template created by a non-admin. Muzilon (talk) 07:01, 11 July 2025 (UTC)

@Muzilon: It could be instead restricted to Template Editors, who know what they're doing with templates.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:08, 11 July 2025 (UTC)

Admins, appointed editors, whatever. Just not laypeople like me. :) Muzilon (talk) 11:06, 11 July 2025 (UTC)

I do not think it is useless to document for historical purposes that copyright was renewed and then expired after 95 years  ${\displaystyle 999}$REAL 💬 ⬆   01:05, 14 July 2025 (UTC)

@999real: I'm missing the relevance of that last to the discussion here, can you clarify? - Jmabel ! talk 05:38, 14 July 2025 (UTC)

"See also this decision to delete an inappropriate US-PD template created by a non-admin" (Template:PD-US-renewed)  ${\displaystyle 999}$REAL 💬 ⬆   14:08, 14 July 2025 (UTC)

@999real That template made no sense here and was deleted per Commons:Deletion requests/Template:PD-US-renewed seven years ago.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:15, 14 July 2025 (UTC)

I don't know what that template contained, I am saying it is not useless to record the fact that something got a renewal and has now expired 95 years from publication, that can be done with just {{PD-US-expired}} with an extra category  ${\displaystyle 999}$REAL 💬 ⬆   14:25, 14 July 2025 (UTC)

It contained near-nonsense: "This work is in the public domain because it was published in the United States between 1930 and 1963 and although there may or may not have been a copyright notice, the copyright was only renewed once. Unless its author has been dead for the required period, it is copyrighted in the countries or areas that do not apply the rule of the shorter term for US works, such as Canada (50 pma), Mainland China (50 pma, not Hong Kong or Macao), Germany (70 pma), Mexico (100 pma), Switzerland (70 pma), and other countries with individual treaties. See Commons:Hirtle chart for further explanation." (That "1930" is generated by an expression in the template.) In fact, (1) no copyrights were ever removed more than once and (2) no image as described here would be eligible for Commons, it would necessarily still be copyrighted in the U.S. - Jmabel ! talk 17:51, 14 July 2025 (UTC)

My point exactly. If the creation of licensing templates were restricted to approved admins/editors (as I believe it should be), then that silly template (deleted in 2018) would never have been created in the first place. Muzilon (talk) 21:12, 14 July 2025 (UTC)

Like I said I did not know what that template contained and when I hear "PD US renewed" I think of something where copyright was renewed and 95 years from publication have passed.

I oppose this idea because I often have to create new templates for public domain situations that we did not have any for. For example, Trinidad and Tobago has no current copyright term for photographs, but it used to have 50 years from publication for them until the new non retroactive copyright law in 1997. Before I created {{PD-Trinidad and Tobago-photo-1946}} we did not have any template or even information on this.

I also do not know how you are supposed to ban creating licensing templates without banning creating templates altogether.  ${\displaystyle 999}$REAL 💬 ⬆   21:33, 14 July 2025 (UTC)

If an ordinary editor wants a customized licensing template, then they can ask a Template Editor to arrange that. If an ordinary editor wants to become a Template Editor, they can apply for the job. Muzilon (talk) 21:38, 14 July 2025 (UTC)

I'll share from a reuser's point of view.

when i see files under some custom licences, i simply dont use them because i dont bother reading into their detail, especially when they are long. RoyZuo (talk) 06:38, 19 July 2025 (UTC)

Improving "Project scope: PDF and DjVu formats"

The section for PDF and DjVu formats in project scope page seems like a joke (at least in my opinion). It's highly subjective and imprecise. In other cases, it merely repeats general ideas about project scope, common to files in any format.
For example:
- while a published university thesis in PDF format may be OK, a user-created original-research article that is making use of Commons as a free web-host may not be. So the same original research, uploaded in another format, would be OK, but the problem is that it is in PDF or DjVu? Seriously? Commons, unlike Wikipedia, allows original research, so a good, legitimate original research (that is, excluding fringe theories, etc), should be allowed in PDF or DjVu format. The scope should never be defined by the file format, but by the content.
- The format has been selected for convenience of printing. Of course, nobody but the uploaders knows why the format was selected. But, as PDF is generally a great format for printing, if a justification is needed, this one can always be used. Or: The format has been selected to allow viewing or printing of special fonts, e.g. documents in advanced mathematics or linguistics. What other media format has disadvantages for showing special characters, when compared to PDF of DjVu?
- a self-published vanity article or a self-created image that the author has uploaded in PDF format in an effort to discourage others from creating derivatives: again, the problem is that it is in PDF format, or that it is a vanity article? For the second part, of course, it's completely logical that PDF and DjVu formats are highly discouraged for user-created images: this should be the only focus of this part of project scope. In any case, in an effort to discourage others from creating derivatives, is something that only the uploader can know. Derivatives can be created without problem from files in PDF or DjVu formats, so it would be audacious to assume that this could be the reason. On the other hand, it may not be possible to keep the same quality when converting a third-party PDF or DjVu file to another image format, so coming from a third party should always be a valid reason to upload a PDF or DjVu file to Commons, but it isn't explicitly said.
- The content is essentially raw text; such files are not considered media files and The content would be prohibited under another section; for example, promotional material: nothing of this is specific to PDF or DjVu, why is it said there?
Of course, I say all of this with full respect to the person (or persons) who elaborated this policy, who I'm sure did it with the best of intentions and devoted a considerable time to it. My basic philosophy here is not to create problems where there aren't: for example, there are good reasons to exclude files in proprietary formats, but there are no reasons to subjectively discriminate files in an allowed format. Common sense: WebM videos are allowed, a WebM video showing a still image that could be uploaded as JPEG, isn't. The same for this.
My original proposal was to greatly simplify the content of the section: restrictions are only to be placed for single-page user-created files (third party files are beyond our control, and should never be underrated because of their format, both in this case and in many others; in many cases, files can not be converted to other format while keeping 100% quality or some meta-information). If a multi-page user-created file is out of scope, it's not because of its format, but because of its content. If it's single-page, there should be a good reason for using PDF or DjVu format (for example, original scan of a document, done by the user). Maybe this could be simply a recommendation, since The format has been selected for convenience of printing could apply to any PDF/DjVu file (specially given that only autopatrolled users can upload PDF and DjVu files, so serious misuse is highly unlikely). An image version could be uploaded later for convenience of wiki use. The rationale is not to create any unneeded restrictions or inconveniences, what harm do PDF or DjVu files create?
My final proposal is:
With the exact wording to be concreted, the general idea is that PDF and DjVu formats would always be allowed when they come from third-party reliable sources (a document writen by a third-party reliable source but scanned by the user, is considered a third-party document for this purpose), and they are not allowed when they were created by the uploader (unless the uploader is the author of a work published by a third-party). Some exceptions could be made in the second case, but they should be objective ones, never assuming we know the intentions of the uploader, or things such as "convenience of printing" that could apply to absolutely any PDF file.
For content from third-party reliable sources, some single-page PDFs could be excluded from what is allowed: for example, logos or other simple content where conversion to an image format would result in no quality loss, and where no useful meta-information is present in the PDF file. Third-party scanned documents or files including photos with a high level of detail would always be allowed as PDF or DjVu (since PNG conversion results in a too large size, and JPEG conversion results in quality loss). The same if the document includes searchable text, or if it has relevant metadata in the file itself.
See New text for "Project scope: PDF and DjVu formats" below. MGeog2022 (talk) 21:08, 15 July 2025 (UTC)

 Support, as proposer. MGeog2022 (talk) 21:15, 15 July 2025 (UTC)

 Oppose. I agree that this part of the policy is less than ideal; that being said, there was some work to improve it a few years ago, and I'd urge you to review that discussion to understand how we arrived at the current text. But the number of pages in the document is certainly not a good way to determine what is in scope - there are plenty of valid use cases for single-page PDF documents (like maps), as well as plenty of out-of-scope multi-page PDFs (e.g. attempts to create encyclopedia articles). I'll note in particular that "original research" and otherwise unpublished texts are generally not in scope on Commons, and are routinely deleted. Omphalographer (talk) 21:38, 15 July 2025 (UTC)

there are plenty of valid use cases for single-page PDF documents (like maps): but not user-created maps, please note that I was talking only about user-created single page documents. I've uploaded lots of PDF maps (that's one reason for my concern about this subjective policy), but always downloaded from a third party: if I create a map (for example, from OpenStreetMap), I would never choose PDF as upload format.

I'll note in particular that "original research" and otherwise unpublished texts are generally not in scope on Commons, and are routinely deleted: as said here, Commons is not Wikipedia, and files uploaded here do not necessarily need to comply with the Neutral point of view and No original research requirements imposed by Wikipedia sites. This is a different point that I do not want to go into, but, again, even if original research is (almost) always rejected, then the reason to reject the file is original research, not the PDF or DjVu format.

@Omphalographer, but I think that we agree much more than it would appear at a first glance. In the discussion you linked, you said:

The restriction to "scanned copies of [...] print material" excludes a substantial number of official publications which aren't sourced from scans of physical documents, like uploads of Taiwanese presidential gazettes by Jusjih (talk · contribs) or US government documents by Illegitimate Barrister (talk · contribs). These are excellent use cases for Commons and should be written into policy

I couldn't agree more: it still isn't written into the policy. The policy shold basically be: PDF/DjVu always allowed for third-party content. Only allowed in certain cases for user-created content. The problem is never the format, but the content. Sometimes the format can be non-optimal, but this causes no harm: a version in other format can also be uploaded, in addition to the original. MGeog2022 (talk) 21:55, 15 July 2025 (UTC)

It's slightly tangential and the answer to this is probably obvious, but is there a reverse image search for PDFs (not as far as I know)? I ask because I've always believed that single (or even double) page PDFs should be disallowed since they are a pain to view/review. PDF is a good "document" viewer but it's not a good "image" viewer and I think the guidelines/SCOPE need should reflect that. As well as the project being against single image PDFs more generally. It's questionable most documents (let alone PDF files) count as "media" anyway. --Adamant1 (talk) 02:47, 16 July 2025 (UTC)

@Adamant1, weeks ago, I finished uploading a collection of 122 orthophotomaps in PDF format. I didn't choose this format: the original author did. Converting all of them to JPEG and uploading the new versions would be a really hard work, and some quality would be lost for sure (and in orthophotomaps, keeping full quality is an important thing), and the same for some meta-information.

That is the point I talked about: the important thing is never losing anything because of discrimination against some file formats, due to ambiguities in the policy. JPEG versions can be created from the PDF, but the original PDF can be kept as well (that's why I included the "original" template in my PDF uploads, to prevent such temptations).

On the other hand, questioning that PDF files or documents are media files, is against Commons general description of the scope: they are often neeeded as reference to Wikisource books, for example. And it's good to have books in PDF files, converting lots of them to wiki format in Wikisource is a formidable work. Why such discriminatory bias against PDF and DjVu? They are open formats, there is no problem with them. Yes, they are not image formats, but they are useful both for storing multi-page documents, and also single-page ones when a third-party publishes them in that format.

It's frustrating when you finish a big contribution such as the one I mentioned, and then see that written policy seems to discriminate against a completely valid file format that you didn't even choose, then you create a proposal trying to address it, and finally you see that everything you have uploaded looks like worthless because it's in an open format but some people seem to dislike it. That's why I propose refining the policy, it's a policy about scope: file format doesn't change the scope. MGeog2022 (talk) 12:45, 16 July 2025 (UTC)

Why such discriminatory bias against PDF and DjVu? @MGeog2022: My main issue is when people upload single page images of things like logos or postcards as PDFs instead of actual image files. Obviously they serve their purpose though, like your example of them being useful to Wikisource. I just always seem to run into PDF files where people are using them wrong though. Hence why I said "single page" PDFs, not PDFs in general. It's unfortunate they aren't easier to convert. I had a plan to convert some magazines in PDFs format into JPEG images a while back and gave up because it's just not worth the time or hassle. Anyway, I just think the project should be more against PDF files being used in instances where image files should be used instead and of course, the opposite is also true. I've seen plenty of instances where it would have been better to combine the images into a PDF file. I'm a big fan of usability, both of the site and whatever media people download from it. --Adamant1 (talk) 14:00, 16 July 2025 (UTC)

@Adamant1, thanks for your response. Yes, everything has its rationale, the problem is when it is taken to the extreme. A logo in PDF is not the most suitable for wiki use, but a derived image can be created, and, if there is no appreciable loss of quality, the original PDF could be deleted. It's a complex issue, but maybe it's not necessary to consider those PDF files as out of scope. When they are replaced by images, they can be considered superseded, and nominated for deletion, if the case is suitable for it. I will take it into consideration and add it to my final proposal. MGeog2022 (talk) 14:11, 16 July 2025 (UTC)

I reformulated my proposal and updated it above. MGeog2022 (talk) 12:54, 16 July 2025 (UTC)

Oppose: If you don't know the difference between "a published university thesis" and "a user-created original-research article", you are not the person to be drafting policy on such matters. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:10, 16 July 2025 (UTC)

@Pigsonthewing, I didn't mean something like that at all. What I meant is that the difference is not related to the file format. If some original research ideas are accepted as a SVG or PNG diagram, or as a video, they should be allowed in PDF, and vice versa. If they are not, they should not in any file format. It's incredible how hard is to express ideas in a way that they are correctly understood. MGeog2022 (talk) 16:14, 16 July 2025 (UTC)

What we host on Commons isn't "research ideas", though. It's media. If your "ideas" are in the form of text, then the appropriate place for that text is as a page on a wiki where they're in scope (if one exists). Omphalographer (talk) 17:59, 16 July 2025 (UTC)

I understand: we host media, so, even if original research is allowed, it would have to be media related to the original research. Relevant documents or books are considered media, but user-created ones are not (even if they do not contain original research: Wikipedia and Wikibooks, among others, are for that), unless they became relevant after being published out of WMF world. The matter here is not about PDF and DjVu specific formats, but about document formats. MGeog2022 (talk) 19:50, 16 July 2025 (UTC)

•  Comment I have uploaded quite a lot of PDF and DjVu files, mostly for Wikisource. PDF and DjVu are the best formats in these cases. For maps and pictures, PDF (and DjVu even less) not a good format, except when they are part of a book. Even in this case, it is usually useful to upload a separate version of the picture, map, or diagram in JPEG or PNG format. PDF and DjVu is also the best format for music sheet, even if there is one page only. Yann (talk) 18:21, 16 July 2025 (UTC)

  it is usually useful to upload a separate version of the picture, map, or diagram in JPEG or PNG format. As I said above, I agree, but, when you get a highly detailed PDF map or high resolution photo from a third party, if you convert it to JPEG, it always looses some quality, and in PNG its size is too big (this can be generalized to any raster graphics format: all of them would be in one case or in the other). The debate in those cases would be if the PDF can or not be considered superseded by the image, and should always be done case by case. What I'm saying here is that a PDF should never be considered as out of scope because of this, even it has also been uploaded as an image. MGeog2022 (talk) 19:58, 16 July 2025 (UTC)

  Simply said: the policy should not lead to Oh, if only the author had published the map in JPEG format, so its full resolution version could be guaranteed to be kept in Commons situations. MGeog2022 (talk) 20:05, 16 July 2025 (UTC)

  This discussion is growing too large, maybe I'll close it later and create a new one with a specific text for the policy, keeping in mind what I've learned from the different comments here. MGeog2022 (talk) 20:09, 16 July 2025 (UTC)

  I have never seen this be used as a deletion rationale. Can you point to an example of this happening, or is this a purely theoretical concern on your part? Omphalographer (talk) 20:11, 16 July 2025 (UTC)

  It's only theoretical. It's not the same to allow a deletion request about a PDF map or document that someone considers superseded by an image with lower resolution, where the PDF file would be kept, since it has not been really superseded, that allowing the file to be considered as out of scope according to policy, that is a really serious thing (one of the main reasons for unquestionable deletion, along with copyright violations). MGeog2022 (talk) 20:17, 16 July 2025 (UTC)

  Converting images from a PDF to JPEG or PNG does always looses quality. A PDF is created by assembling images, and the process is completely reversible. Just use the right software. Yann (talk) 14:17, 17 July 2025 (UTC)

I'll mark this as resolved. I made a more precise proposal below. MGeog2022 (talk) 10:47, 17 July 2025 (UTC)

Aside: you should be able to do pretty good compression on a PNG (still lossless). There are a crazy number of compression algorithms available for PNG. The ones that do the most compression take a while to crunch, and no single algorithm always works (e.g. some work particularly well for images with relatively big solid-color areas; some do particularly nicely on small color palettes; some are great if there are repeating patterns; etc.). I don't know how much work it is worth applying to any given map image, but working professionally with raster construction drawings, I was typically able to achieve a factor of five compared to the obvious representation (automated program used ImageMagick to try half a dozen lossless compression algorithms, then took smallest result). I imagine the same is true for quite a few other file types. - Jmabel ! talk 22:41, 16 July 2025 (UTC)

Thanks for the information, certainly this would be the right way for those cases if we want to fully replace a high resolution single-page PDF file with an image. MGeog2022 (talk) 10:19, 17 July 2025 (UTC)

@MGeog2022: About original research: OR is mostly not about the documents themselves, but about the metadata. For example, Paul Cézanne catalogue raisonné, 1970 Orienti, Commons:Character copyrights, or The Bitter Years exhibition at the Museum of Modern Art, New York would be considered OR by Wikipedia standard. Commons:Featured pictures/Non-photographic media/Computer-generated may also be considered OR though. Yann (talk) 16:48, 17 July 2025 (UTC)

New text for "Project scope: PDF and DjVu formats"

Since the current text is somewhat imprecise and prone to subjective interpretations, I propose replacing it with the following (of course, this proposed text doesn't need to be 100% accurate: minor corrections are welcome; this proposal's intent is not to change anything in the current policy, only to formalize it so it can be interpreted in a precise and objective way):

BEGINNING OF THE PROPOSED NEW TEXT

PDF and DjVu file formats are allowed in Wikimedia Commons, but only for storing allowed documents. The general Commons project scope rules also apply to files in these formats. In addition, since Commons is a media repository, only PDF and DjVu files considered as media files are accepted, and the only files in those formats that can be truly considered as media in this context are third-party publications or relevant documents (even in the case that they contain only text), that from here on we will call allowed documents. For a user-made photo, map or diagram, an image file must be used. For a user-written text, even if it also includes images, wikis such as Wikipedia, Wikibooks or Wikiversity, among others, can be used.

An allowed document in this context is always understood as something that was created or published by a reliable third party, or that is relevant because of historical or other reasons (this applies only to the document itself, not, for example, to the scanning work, that can be done by any Commons user without problem). The allowed document may be a scan of a paper document, or a work directly published in PDF or DjVu format.

Official publications by Wikimedia Foundation (to be differentiated from works by common users of WMF's wikis) are also considered as allowed documents, as are Wikimedia community-related media (for example, a brochure showing the winners of Picture of the Year), or printable versions of articles or collections of articles from other Wikimedia wikis, such as Wikibooks or Wikipedia.

A work by a Commons user would not be considered as an allowed document, unless it's covered by the cases mentioned in the previous paragraph, it has also been published somewhere else and is significant (for example, university theses or peer-reviewed academic papers), or some exceptional justification is provided (this includes cases when an easily printable format is highly needed). As with other formats, we also allow active contributors to have a small number of personal files that they use in "user space."

A PDF or DjVu file containing an allowed document will always be considered in scope in Wikimedia Commons. For single-page documents, uploading a version as an image format is recommended. Even after an image version of a single-page PDF or DjVu file has been uploaded, the original document file must never be nominated for deletion as out of scope because of this reason (it may be nominated as redundant in some exceptional cases, when the PDF/DjVu file is considered as inferior to the image version; in those cases, no searchable text, image quality, or internal relevant metadata must be lost, the file was must not be tagged as {{original}}, and no particular ease of printing must be needed, but, generally, original files should be kept).

END OF THE PROPOSED NEW TEXT

MGeog2022 (talk) 10:45, 17 July 2025 (UTC)

 Support, as proposer. MGeog2022 (talk) 10:47, 17 July 2025 (UTC)

Oppose - not least because it's not clear where your proposed change ends, and your commentary begins. Why have you not pinged the people who commented on your earlier proposal, above? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:43, 17 July 2025 (UTC)

@Pigsonthewing, fixed both things. MGeog2022 (talk) 11:58, 17 July 2025 (UTC)

Pinging all people who commented on my initial proposal, that I marked as resolved after creating this new one: @Pigsonthewing, @Jmabel, @Omphalographer, @Yann, @Adamant1. MGeog2022 (talk) 11:52, 17 July 2025 (UTC)

only PDF and DjVu files containing media are accepted: Most old books uploaded in PDF format contain only text. Yann (talk) 14:19, 17 July 2025 (UTC)

@Yann, please read from comma that follows, onwards :-)

This is being much more difficult than I imagined. The basic ideas are the same that are currently in place, but putting them into text in a way that is well understood is being really hard. I tried to listen to all different viewpoints that I'm seeing, but maybe I focus too much in trying to satisfy all of them at the same time.

For example:

What we host on Commons isn't "research ideas", though. It's media. If your "ideas" are in the form of text, then the appropriate place for that text is as a page on a wiki where they're in scope (if one exists).

This makes full sense, but when you see that there are very good high-quality multi-page PDF files created by Commons users, you realize that you can't follow it word by word. Perhaps that's the very reason why the current policy text is so imprecise. MGeog2022 (talk) 19:42, 17 July 2025 (UTC)

only PDF and DjVu files containing media are accepted: certainly I will improve it a bit, it isn't fully clear that text-only is allowed. MGeog2022 (talk) 19:49, 17 July 2025 (UTC)

I think that files which are digitally signed are usually pdf:s as it is currently only format widely used format with well supported embedded signing. Also, pdf is prettu much best easy to use format for material which is meant to be printing-ready. (ie you can print it with printer or you can sent it to the printing house ) Wikimedia Finland has been storing both digitally signed (yearly meeting notes) and also priting-ready files (stickers, posters, postcards etc) to commons. It is also pretty common practice to convert presentation slides to pdf files for archiving publishing it online. --Zache (talk) 16:11, 17 July 2025 (UTC)

 Oppose The problem of the proposal is that it's starting point is that user generated content should not be stored as pdf. However, almost all stuff which is meant to be printable is published as pdf and it is currently best open file format for that. (examples from WMFI: 1, 2, 3, 4, 5, 6) --Zache (talk) 05:26, 18 July 2025 (UTC)

I think we do want to allow certain types of user-created PDFs like User:Charlesjsharp/A Sharp Eye which are intended to be e-books with precisely laid out content. These kinds of PDFs would fall under the personal media allowance for active contributors and/or the allowance for Wikimedia community-related media (e.g. a brochure showing the winners of WLM, POTY, etc.). -- King of ♥ ♦ ♣ ♠ 16:43, 17 July 2025 (UTC)

I do not want to take part in polemics, because I see that there are advocates of totally opposite viewpoints, but I will say that I totally oppose to considering the PDFs you mention as out of scope, as it would be a total lack of respect to the work of the user who created them. This would be a good case to use the some exceptional justification is provided clause that I included in my proposed text. MGeog2022 (talk) 19:22, 17 July 2025 (UTC)

@King of Hearts, I modified my proposal to also cover the cases you mentioned. MGeog2022 (talk) 19:31, 17 July 2025 (UTC)

 Oppose "A PDF or DjVu file containing a document will always be considered in scope in Wikimedia Commons" is certainly wrong. My resume is a document. It is out of scope. - Jmabel ! talk 17:32, 17 July 2025 (UTC)

@Jmabel,

A document in this context is always understood as something that was created or published by a reliable third party, or that is relevant because of historical or other reasons (this applies only to the document itself, not, for example, to the scanning work). The document may be a scan of a paper document, or a work directly published in PDF or DjVu format.

Maybe the text needs some more refining to be well understood without too much effort. MGeog2022 (talk) 19:08, 17 July 2025 (UTC)

Done: used "allowed document" in place of simply "document". MGeog2022 (talk) 19:23, 17 July 2025 (UTC)

@MGeog2022: Thanks for your effort to improve this. This paragraph was added sometime in 2008, so there is no hurry to change it. Hopefully we will get a better version.

Since Commons is a multilingual project, we should be careful not to use words which could have several meanings, and be misunderstood by non native English speakers. Unfortunately, our policies are not translated as much as they should, so many non native speakers use the English version. Yann (talk) 20:01, 17 July 2025 (UTC)

 Oppose. As written, this prohibits a number of generally accepted use cases for PDF files, like printable editions of Wikibooks content or slide decks from Wikimania presentations. I would strongly suggest that you step back for a bit and examine how PDF files are used on Commons before making further policy proposals involving these files; spending some time reviewing the feed of newly uploaded PDF files may be instructive. Omphalographer (talk) 20:22, 17 July 2025 (UTC)

Both of the cases just mentioned by Omphalographer should be explicitly allowed. Also, I wouldn't limit that to Wikimania: any presentations in the Wikimedia community (user group meetings, WikiConferences, etc); probably also allow for other similar documents that may not have been used in presentations but realistically have that potential. - Jmabel ! talk 03:40, 18 July 2025 (UTC)

@Jmabel, @Omphalographer both WMF and Wikimedia community cases are already covered by my current proposal. I'll also add printable editions of Wikibooks (or other wikis) content. Maybe the current content is not so bad: it appeals to administrator's commons sense, and this also applies to many other decisions about project scope. The subjective case-by-case decision thay I judged as a problem, probably isn't. But I already started this, so I'll try to bring it to a successful end. MGeog2022 (talk) 09:54, 18 July 2025 (UTC)

@Jmabel, thanks for your editing on the proposed text. This interest is a signal that, eventually, it may have some future. Time will be needed to know if it's better to basically keep the current text, or to replace it with the proposed new one. MGeog2022 (talk) 09:29, 19 July 2025 (UTC)

•  Oppose PDF files of presentation slides by Wikimedians like those to be found in Category:Presentation slides by person would no longer be included in the scope. Nearly all these slides were presented at some Wikimedia meeting. --AFBorchert (talk) 10:17, 18 July 2025 (UTC)

  @AFBorchert, considered as allowed documents, as are Wikimedia community-related media. Doesn't this cover such presentations? MGeog2022 (talk) 12:16, 18 July 2025 (UTC)

  This is too restrictive and is contradicted by the statement An allowed document in this context is always understood as something that was created or published by a reliable third party. (Emphasis is mine). Honestly, I find the original text in COM:PS#PDF and DjVu formats far more readable and less ambiguous in its wording. In my impression, your proposal appears to be a non-working solution to a non-existing problem. --AFBorchert (talk) 12:36, 18 July 2025 (UTC)

  @AFBorchert, it's very likely that you are right, given how difficult the correct understanding of my text seems to be, based on most or all of the comments and votes. I didn't like some things in the current text, mostly the need to make assumptions about the uploader's intentions, but I can't say that the your proposal appears to be a non-working solution to a non-existing problem statement could not well be true. I'll leave this here a bit more time, but, if nobody supports it, I'll cancel it in a few days. The judgment of administrators may well give better results than any hyper-detailed written policy.

  If the basic current text is kept, I think that some mention is needed to show that third-party publications in PDF (or DjVu, though rare) that are nor scanned printed works are also allowed, though. MGeog2022 (talk) 12:52, 18 July 2025 (UTC)

  Unlike the English Wikipedia, we do not strive to be overly precise in our policies – as long as it is not about copyright. The main point of that section in COM:SCOPE is to make sure that we do not end up having Wikipedia-like articles at Commons through PDF files. But on the other hand we had to make sure that scans of public domain books are not an issue. This section as it is worked out quite well since some considerable time. I cannot remember a single case where we had a debate abouts its interpretation. This is the reason why I used the term non-existing problem as you did not cite any deletion requests where this has been an issue. And I characterized this proposal as non-working as I think that this would create more confusion and less clarity than the existing text. It is always good to rethink whether the texts in policies are good enough. But I think that it is helpful to make actually a case based on problems we have actually seen and then to discuss first possible solutions. Commons talk:Project scope would be the proper place for it. --AFBorchert (talk) 13:09, 18 July 2025 (UTC)

  @AFBorchert, thanks for your feedback. I'll wait a bit more, but, if nobody suggests the contrary, I'll close this, and I'll propose, in the talk page you mentioned, to specifically add the case for third party works that are not scanned but directly published as PDF. Not because I have a big fear of them being removed (there is no reason to believe that simple common sense may not be applied), but to have the policy text matching with the reality. MGeog2022 (talk) 13:48, 18 July 2025 (UTC)

  Something I've had to come to terms with over the years is that there's a real hesitation with a lot of people on here to integrate common norms of how things are usually done into solid policies. Sometimes it's for the right reasons, sometimes it isn't. Differences in languages has some to do with and therefore word meanings has some to do with it I'm sure. But that's life on here, I guess. Any proposal to change or improve guidelines can be a crapshoot. --Adamant1 (talk) 14:41, 18 July 2025 (UTC)

It seems that, even after all changes, there is no interest in this new proposed text (no support votes at all, other than mine). If nobody shows any objection in the coming days, I'll retire this proposal, by marking it as resolved. From what I read in comments here, it seems that written policy is not very relevant to project scope: only administrator's common sense matters (and this already includes that any relevant document is to be preserved and not destroyed, also when they are in PDF or DjVu formats). MGeog2022 (talk) 11:48, 25 July 2025 (UTC)

Since it seems that nobody has any objection, I retire this proposal by marking it as resolved. MGeog2022 (talk) 19:50, 27 July 2025 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment. --MGeog2022 (talk) 19:51, 27 July 2025 (UTC)

Sort key guidelines

I'd like to propose clearer and more consistent guidelines for category sort keys. Specifically, I'd like to suggest reserving the space sort key for metacategories (categories that only contain other categories), and using the exclamation mark to indicate categories with a special status (quality, valued, or featured images). Broadly, this is how these sort keys are used already, but this isn't done consistently. Particularly in taxonomic categories like Category:Malpighiales (but also in non-taxonomic ones like Category:Minerals) metacats, special-status categories, and content categories are often mixed together. ReneeWrites (talk) 14:18, 21 July 2025 (UTC)

Something like this would certainly be good. Definitely useful to agree on one thing being normal.

Another distinct class that we might want a consistent rule for is geographic narrowing. E.g. under Category:Buildings in Seattle where we have Category:Buildings in Ballard, Seattle, Category:Buildings in Capitol Hill, Seattle, as against individual buildings. These are not metacats (they can directly contain photos), but they are very different from categories for individual buildings. - Jmabel ! talk 18:33, 21 July 2025 (UTC)

 Support in principle. Could you write your proposed guidelines up somewhere? Omphalographer (talk) 20:19, 21 July 2025 (UTC)

FYI there is User:Reinhard Müller/Category Sortkeys. Prototyperspective (talk) 11:03, 28 July 2025 (UTC)

Ban single file categories for modern copyrighted works and/or artists

There's a lot of single file categories for modern works or artists out there that have almost zero chance of having other images added to them because the works are still copyrighted and/or the people are to obscure for us to realistically have enough images of them to warrant the category. A good example of that is a lot of the subcats in Category:Postage stamps by artist. I don't think it serves the purpose of categories or the project to keep the categories like that. Aside from just creating a needless mess, it also gives the false impression that the project is cool with people uploading copyrighted works by said people (or them being hosted on Commons to begin with). There's no reason that there should be categories for people or anything else if the work is copyrighted. At least baring something like a category for a modern movie where there will be logos, press photos, Etc. Etc. But that's why I'm confining this purely to categories that contain a single image and are unlikely to contain anymore then that in the near future due to copyright issues. There should be a ban on single file categories in such instances though. --Adamant1 (talk) 06:50, 25 July 2025 (UTC)

categories for modern works or artists out there that have almost zero chance of having other images added to them — there may be deleted files in those categories that you can't see, but once they get undeleted it might be handy if they are already properly categorized. (If deleted files keep their categories that is). Nakonana (talk) 15:49, 25 July 2025 (UTC)

@Nakonana: Sure but if so its usually 40 or 50 years from now if your lucky. Keeping every single file category just isn't sustainable at that point IMO. --Adamant1 (talk) 16:18, 25 July 2025 (UTC)

Deleting sounds like unnecessary extra work to me, though. Just think about it: someone put some time and effort into creating the category, now someone else needs to put some time and effort into deleting the category, and then, in 40–50 years, yet another person has to put some time and effort again into doing the work that person one had already done once, just to undo the work that person two did. That's sounds like a waste of time and effort if we can already predict that there will be files in that category in the future. Plus, what if person three doesn't create the category under the same name as person one had originally categorized all the deleted copyrighted files under? This will probably not happen for English category subjects, but for other languages with non-Latin script there are too many ways to romanize one and the same name, so that there is no guarantee that person three will choose the name/writing that was originally used by person one to categorize all relevant files. Just an example of one name for which there can be four (and more) different ways to romanize: Aleksandr Ivanov, Alexandr Ivanov, Alexander Ivanov, Oleksandr Ivanov (I'm almost surprised that there's no Alexander Iwanow). Nakonana (talk) 17:20, 25 July 2025 (UTC)

@Nakonana: This proposal in no way requires the deletion of any specific categories. People are free to edit how they want on here. Personally, I enjoy doing this kind of low level maintenance work. There's a certain level of upkeep with every website to make it usable. That's just how the internet works. An unfortunate things with categories is that the ability to find images using them exponentially degrades the more categories their are and the less images they contain.

People on here seem to really care less about how useable the site is though. Their more concerned with retaining every minor thing for own sake and regardless of if it actually helps people find images or not. But this is a media repository and people have to be able to find images at some point. That's not helped though by endlessly browsing through empty categories into you finally get to a single image, or more likely just give up and go to Flickr. So do we want to help people find images or mindlessly build and retain mostly empty category systems for no reason? Come on. --Adamant1 (talk) 17:43, 25 July 2025 (UTC)

This proposal in no way requires the deletion of any specific categories — but you are proposing to "ban" them if there's only one image in there. How is "banning" different from "deleting"? The problem is also that you don't know how many hidden images there are in such a category, so if there's only one visible file in there, it doesn't say much about the category's actual content. Nakonana (talk) 09:57, 26 July 2025 (UTC)

@Nakonana: I mainly see it a as a way to cut down on people creating new ones. It's impossible to delete a whole type of category or get people to stop creating them though. But "less" is better then "I don't care. Create as much as you want! Screw the user experience!" Anyway, couldn't you say the same for empty categories? At that point why delete any category what-so-ever to begin with? --Adamant1 (talk) 13:20, 26 July 2025 (UTC)

Let's say, I'm open for suggestions. So, let's take the following real-Commons-editing-example: I'm currently going through Commons:Deletion requests/Files uploaded by Ulaisaeva, which is a massive DR with files that have hardly anything in common except that they depict cultural heritage monuments at a Moscow cemetery that were all uploaded by the same user. I noticed that there are a decent number of sculptures that were created by the sculptor Aleksey Yeletsky — however, his works are still copyrighted in Russia (he died in 1997). All images showing his works will be deleted. But there are so many that it would be handy if, once they are undeleted, they would all be in one place and easily identifyable as his works without having to go through some reference work like I'm currently doing. So, I created a category for that sculptor ... which will soon be empty.

What do you suggest we do with the then empty category? And what do you suggest I should have done to keep track of images of his sculptures, if creating a soon-to-be empty category is not desired? And if we choose to delete the category, then how do we ensure that the categorized files won't be "lost" because the person who recreates a category for Yeletsky in x decades chooses to name the category "Alexey Yeletsky" or "Aleksei Yeletsky" or "Alexei Yeletsky" or "Aleksej Eleckij" (using academic transliteration) or "Aleksei Ieletski" (current Russian passport standard) or "Aleksey Yevgenyevich Yeletsky" or some other variant of romanization? What will become of the files in Category:Aleksey Yeletsky?

couldn't you say the same for empty categories? — I don't know whether I could say the same about every category. There may be categories that are clearly out of scope and likely will remain out of scope in the future, or categories that are too specific and granular. Deleting them is perfectly fine. And categories by artists with names in Latin script might be also fine at least in so far as they will likely end up having the same name when recreated as they had before being deleted. And I might be fine with the deletion of Category:Aleksey Yeletsky if you can present me a workable solution that would serve the intended purpose mentioned above while avoiding the naming issue. Nakonana (talk) 14:22, 26 July 2025 (UTC)

Isn't there a way to tag deletion requests as "undelete in year x", when files are not PD now but may be in a reasonable time in the future? Those details may be mentioned in a post-close footnote. Cambalachero (talk) 16:28, 26 July 2025 (UTC)

There is, but Adamant's example is about artists and mine is about sculptors. Yeletsky's works would be PD in 2072 if I'm not mistaken, but his works would by far not be the only ones in Category:Undelete in 2072, so that someone would still have to put them in the "Works by Aleksey Yeletsky" category. Nakonana (talk) 17:20, 26 July 2025 (UTC)

I have no idea where you get 2072 from (I believe Russian term of copyright is "p.m.a. + 70", so if he died in 1997 they will be out of copyright there in 2068), but if you look at Category:Undelete in 2068 (or Category:Undelete in 2072) you will see we keep file lists there for various individual artists whose works will become PD that year. No need for an additional category. Since it is a virtual certainty that these will be deleted, it's OK to add them to that list before the DR is closed. - Jmabel ! talk 20:26, 26 July 2025 (UTC)

I think some more years are added for war participants? I don't know, I've seen p.m.a.+70y and p.m.a.+74y+1y, not sure which one is right.

we keep file lists there for various individual artists whose works will become PD that year. How are those file lists created? Is that something that admins do? And will the files then be put into the artist's category when undeleted? Nakonana (talk) 00:14, 27 July 2025 (UTC)

• Probably done more by admins than anyone else, but anyone can do this. Of course, more often, we have a convenient DR to just place in the category, but this one looks like it will have too many unrelated cases to make that convenient. - Jmabel ! talk 04:00, 27 July 2025 (UTC)

  So, creating author categories wasn't too bad of an idea in this particular case? Nakonana (talk) 13:08, 27 July 2025 (UTC)

• Probably not a bad idea at all, as long as you are OK with them being deleted if they've been empty for a while. Also, Wikidata items about those authors are a particularly good way of tracking death dates, even if we lack any current identified content. - Jmabel ! talk 18:35, 27 July 2025 (UTC)

(Also, have you checked that DR? It's massive... How many different undeletion categories will this one DR need...) Nakonana (talk) 00:17, 27 July 2025 (UTC)

 Oppose per Nakonana.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 10:01, 26 July 2025 (UTC)

@Jeff G.: Yeah because indefinitely keeping categories just because they might have invisible files in them sounds a like a totally reasonable thing to do instead. Right. --Adamant1 (talk) 13:22, 26 July 2025 (UTC)

If there are several subcategories each with one or very few files, an alternative is to turn them into a gallery.

As for categories about copyrighted works, we can place a template in them. Something like "(category name is a work under copyright. Barring specific special cases, this category may have images related to the work, such as creators or reception, but not from the work itself". Cambalachero (talk) 16:06, 26 July 2025 (UTC)

We can also put the artist cat in the DR, have it deleted with the rest of the files, and have it restored on COM:PDD in the appropriate year.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 23:06, 26 July 2025 (UTC)

I did consider something like this, but there are also photos of the artists themselves in some of the categories which don't need to be deleted, and in the case of the DR I mentioned above, there are some sculptors who have works in different countries, including Germany where the sculptures are covered by FoP and therefore also don't need to be deleted. Nakonana (talk) 00:21, 27 July 2025 (UTC)

I'm not sure I follow that last exchange. If we have other content for the artist cat, then this problem doesn't arise for the artist cat. - Jmabel ! talk 04:02, 27 July 2025 (UTC)

@Jmabel: I was thinking of, for example, Category:Photos by [famous 20th Century photographer].   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 11:58, 27 July 2025 (UTC)

Fair point. But the proposal is to ban categories with only "one" file in them. So, what if, after all the artist's works are deleted from the category, there's only one image left in the category? (be it a portrait of the artist or let's say one photo of a now dismantled Statue of Joseph Stalin, Berlin) Nakonana (talk) 13:27, 27 July 2025 (UTC)

@Nakonana: Keep it.   — 🇺🇦Jeff G. ツ please ping or talk to me🇺🇦 14:41, 27 July 2025 (UTC)

• Photos by [famous 20th Century photographer] it's complicated. We have a fair number of photos legitimately in Category:Photographs by Imogen Cunningham on at least two different bases (free license from the Imogen Cunningham Trust, or PD-US-expired). We also have a fair amount of material legitimately in Category:Imogen Cunningham. Similarly for Ansel Adams. Even for Jini Dellaccio, where so far we don't have any way to legitimately host any photos by her, Category:Jini Dellaccio contains ones I took of her. I guess if we had a "photographs by" category for someone like her we could put it in a category to be undeleted at a particular date, but "photographs by" categories are usually pretty trivial. Often the only parent is the category for the photographer, though they might also have something like Category:20th-century photographs by photographer. Pretty easy to reproduce, and undeleting a category when needed is also pretty trivial. So, nothing actively wrong with the idea, but no big deal. - Jmabel ! talk 18:49, 27 July 2025 (UTC)

Flag categories (2)

I've written this into policy COM:GALLERY here. Waddie96 (talk) 05:18, 28 July 2025 (UTC)