Jump to content

Community Wishlist Survey 2021/Multimedia and Commons/Separate property and user right for license, author and date

From Meta, a Wikimedia project coordination wiki

Separate property and user right for license, author and date

  • Problem: Author, license and date are written down in file decription and are writable to everybody. It happened to me in the past the other (anonymous) user changed the autor information of my images to their own name. If you dont check/use your watch list regularely you have no chance to notice it. Besides people can not change every license to any other license afterwards. Author, file date and license must not be changeble so easily.
  • Who would benefit: everybody and every file
  • Proposed solution: Author, file date and license should be stored in separate (wikitext) features and should be editable only by the uploader himself and by admins and bots with that user right (for maintenance or an official transfer to an other user, if necessary). Or maybe just one more wikitext area for all three information that is just shown after the normal description.
  • More comments:
  • Phabricator tickets:
  • Proposer: DerFussi 09:41, 20 November 2020 (UTC)[reply]


There are many legitimate reasons for other editors to be able to change these fields. What you've described is just vandalism, and we could always be more vigilant about that. -FASTILY 23:57, 21 November 2020 (UTC)[reply]

What many legitimate reasons? · · · Peter (Southwood) (talk): 07:50, 22 November 2020 (UTC)[reply]
Who has the time and inclination to be more vigilant about that? · · · Peter (Southwood) (talk): 07:47, 22 November 2020 (UTC)[reply]
To name a few: editor uploading a file form an external website but choosing the wrong license (happens all the time with Flickr uploads, permission submitted via OTRS), license migrations, marking obvious PD-simple files as such. Plenty of folks monitor recent changes for vandalism. -FASTILY 10:00, 22 November 2020 (UTC)[reply]
As stated above. Admins and bots are able to edit this. Monitoring recent changes? As fast as the recent changes run through? And I am sure, the folks have better things to do in their free time than monitoring vandalism, especially if some features can avoid some kind of vandalism. And by the way its not easy to recognize some of this edits as vandalism. Especially when its not that obvious. -- DerFussi 19:59, 22 November 2020 (UTC)[reply]
Yes, plenty of people watch recent changes. It's not difficult to do with a tool like Huggle -FASTILY 02:06, 23 November 2020 (UTC)[reply]

To some point, the question is : Could there be a "localized" fields with protections applied to it (a field receiving author information at upload time) on a mediawiki page ? I've discussed such principle and tools for a different context and it has many alternative applications. I proposed to use templates about this 5 years ago (it can be in 'no show' wikicode). For the discussed case, whenever a change is brought to a file, "authors" (as well as alternative fields) can be compared. And according to the result of a 'diff' command, according to the results and respective situations, a proper management of these cases can be done. It's what I called an "authorship bot" in the JSL protocol, used in an alternative context of research literature production (see related logigramme). Such a tool is very useful whenever there is a primary-'wiki'-source to be taken accountable (artists, authors, journalists, researchers, any primary information producer). (For instance, in France we cannot "give" a work to public domain because moral rights and duties cannot be ceded).

The discuss case can have the following situations:

  • where authors and upload account differ, it can trigger a verification protocol (bot or human-community based)
  • where authors field (or any judge critical) change, it can be a) notified, b) reverted and put under protection etc. according to vandalism diagnostics (is it a case, an attribution error etc. ?)

The fact than it can be done by humans is not an argument for it not to be done by a script / bot / automated protocol (whatever you name it). --RP87 (talk) 13:58, 11 December 2020 (UTC)[reply]