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

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search

Automated deletion of files tagged as copyvios or no-permission by trusted users if no human does it

I think we're all aware of the fact that many people don't like performing repetitive tasks. Thanks Túrelio and a few other administrators, copyright violations are deleted but the files tagged (marked) with no-permission are often treated without a lot of care. Therefore it often makes no difference whether an admin has to spend his/her time (>1h/day!) for all these files or whether a bot does the clean up.

I propose that deletion by bot should take place under the following conditions:

Definitions:

People mis-tagging files will be held personally responsible. Introducing such a bot will be announced before so everyone will be aware of this change.

The deleting bot will cite the user who tagged the file in the deletion summary and notify the uploader(s) about the automated deletion (respecting {{Bots}}).

This change will

  • reduce the admin-backlog and therefore admins can spend more time talking to uploaders / teaching what is suitable for Commons
  • hopefully improve the quality of how people mark the files
  • administrators can spend their time investigating whether a file can be kept due to exemptions and remove the “tags”

I am interested in your thoughts. Nothing of this has been implemented yet; it's just an idea. If someone find it's worth looking into details, I could start recording statistics before we would start speculating how many files would be affected. -- Rillke(q?) 13:17, 19 September 2012 (UTC)

Could you point me to a definition of the scope of Nikbot, I cannot see anything obvious on the bot's user page. I could not support automatic deletions based on a bot script I cannot see a definition for. I assume that giving such effective power to a bot would mean a code-freeze from this point on unless there were a significant consensus to change scope or this automated effective deletion authority were removed anytime the bot were revised? Thanks --Fæ (talk) 13:25, 19 September 2012 (UTC)
Yes, the code should not be changed, except for security reasons after the bot was approved without new approval. Nikbot is a clone of Filbot (see also Commons:Bots/Requests/Nikbot). It marks recently uploaded files that don't have a license template on the file description page. The source code is available. Since Commons:Essential information demands a license template and in most cases, you can't choose one for another user, most files are deleted anyway, if they are not changed or a license template was added. -- Rillke(q?) 14:18, 19 September 2012 (UTC)
I am very nervous about the deletion policies and the way they are interpreted by trusted humans let alone a Bot. The cases in point are the Right to Panorama issues in France. The world and his neighbour says their is no right to panorama in France, but reading in law in French shows that this is an anglo-centric simplification and WP applies it erroneously, erasing innocent images in the process. The intervention time to stop an erase assumes that the uploader has permanent internet access- not intermittent access on a shaky line in a low tech region of a low tech country. The advantages seem spurious. 1. the backlog will expand to fill the space available. 2. I see no evidence of mentoring by admins- whose skills are generally more technical that human. 3. Geotagging is a huge issue for me but quietly tagging the file oneself- leading by example seems a better way to deal with naive volunteers- that to zap some of their early efforts. 4. I would never try to direct any wikipedian how to spend their time- and investigating exemptions is a career rather than a leisure pursuit. I think this is a well meant deadend. I would be happier to see a quarentine system done by humans- it seems tragic that someone will spend so much time and effort determining that the file is a copyvio- but that knowledge is lost and not reported- it would be wonderful if we could collate the copyvios into a reference work that could be accessed for learning purposes (in-service training so to speak. At the moment there is a herd of elephants in Category:Copyright violations -whichever way the decision goes it would be fascinating to learn of their offence and fate! --ClemRutter (talk) 14:35, 19 September 2012 (UTC)
We already collate examples a bit (eg at COM:TOO and COM:DM) - but I agree we could do a lot more to educate/train people. Rd232 (talk) 14:53, 19 September 2012 (UTC)

 Support the basic idea of automated deletion, as long as sufficient safeguards are applied and testing is done. For instance, as part of the testing we'd certainly want a dry run to see just a listing of what the bot would have deleted. Conditions:

  1. Only files not in use should be deleted - anything that's in use deserves a human decision. The bot can help clear the less important files, when the backlog gets too big.
  2. Only files uploaded within the last 3 months - anything that's been around longer deserves a human decision. (If this excludes too many files in practice, we can reconsider this one.)
  3. Only files that have been tagged for 10 days or longer. Files shouldn't be deleted before 7 days, so give some time for a human to do it.

With these conditions the bot will provide a useful backstop to stop the backlog getting too big. The very existence of the bot will probably also encourage admins to keep the backlog in check. Rd232 (talk) 14:53, 19 September 2012 (UTC)

 Support the basic idea, but I think that the bot also should check that the template {{Kept}} isn't used on the talk page. If the file has been kept in a previous deletion discussion, it should go to a new deletion request. --Stefan4 (talk) 13:00, 21 September 2012 (UTC)

 Support Agree with the idea, if the conditions mentioned by Rd232 and Stefan4 are met. Yann (talk) 13:12, 21 September 2012 (UTC)

 Comment Bot should check edit history of file prior to tagging for deletion - check info had been removed at some point (by accidental or deliberate blanking) (only really applies to no license). That's something humans are unlikely to check as it takes too long... The bot should wait a minimum period before deleting; a human admin can judge if a request needs fuller discussion. The bot can only tell that if someone objects - so needs to give them time to object in.--Nilfanion (talk) 10:12, 22 September 2012 (UTC)
Checking the edit history is a valuable suggestion. --Túrelio (talk) 10:17, 22 September 2012 (UTC)
 Comment For images tagged with no permission or no license, the source should be checked, it's possible that the source has been changed since the file was tagged, also license on the source may have been missed, so perhaps the bot shouldn't touch the files with a source.  ■ MMXX talk 21:00, 1 October 2012 (UTC)
 Comment I have seen cases of files tagged, but the warning was not added to the uploader's talk page. It would be nice if the bot could check that was done. Yann (talk) 17:32, 4 October 2012 (UTC)
Good point: there are some things an automated deletion tool can potentially do in terms of checking which in practice admins probably don't have time to. That's one example. Rd232 (talk) 18:25, 4 October 2012 (UTC)

Supporting files

Some media files uploaded on commons are computer generated from one or more original input files which are usually not uploaded to commons. Some examples:

  1. file on commons: panorama stitched from N images; file(s) not on commons: N original images
  2. file on commons: jpg image from camera raw file; file(s) not on commons: raw file
  3. file on commons: png relief map with labels, legend, etc; files(s) not on commons: e.g. jpg relief, svg labels, png compass rose,... all used to create the final map
  4. file on commons: png plot of a mathematical function; file(s) not on commons: gnuplot script file used to create the plot

Now, if a mistake is found in one of the uploaded images or if newer technology allows higher quality files, the only way to fix or improve it is through the original creator, which causes all kinds of problems: creator inactive on wikimedia, creator has lost/deleted original files, etc. Therefore I think it would be a good idea if there was some software support at commons to upload these additional files and associate them with the main file somehow. I understand that I could upload additional files the normal way to commons and link to them in the image description of the main file, but first of all, this is lots of manual/boring work and second I'd be limited to the file types supported by commons (e.g. no raw files). So, my proposal is:

  • create a separate database for "supporting" files, which can be of more arbitrary type and would be only available for download, i.e. not directly displayed on commons, wikipedia, etc.
  • after uploading the main file, have a link ("upload supporting files") to an upload form
  • the upload form should have fields for file names and optionally short descriptions (saying what each file is for); likely there would also have to be some licensing stuff covered (but I don't know much about that)

Does this sound useful? bamse (talk) 19:31, 1 October 2012 (UTC)

Of course. Someone has just to care for that the new database is not abused as personal file storage, which is more difficult if you can't preview the files (like RAW files). -- Rillke(q?) 10:24, 2 October 2012 (UTC)
I totally sympathise with your aims, and feel like it ought to be possible, but I don't think it'll happen. Developers have been reluctant to enable filetypes the software can't display, because of security risks. See long-term problems getting new filetypes approved: COM:UNSUPPORTED. In the short/medium term there is http://www.commonsarchive.org. Rd232 (talk) 11:06, 2 October 2012 (UTC)
Well, several of Bamse points do not need special software support. For example, Gnuplot source code. See Category:Images including source code in their description. Jean-Fred (talk) 11:54, 2 October 2012 (UTC)
And see {{Source code please}} as well. Jean-Fred (talk) 11:56, 2 October 2012 (UTC)
Thank you all for the positive replies. I don't think it would be very attractive for personal file storage as files are public and the user interface would be much more cumbersome than something like dropbox. Commons archive looks interesting, though I don't understand if and how it interacts with wikimedia commons. bamse (talk) 18:38, 3 October 2012 (UTC)
You can think of Commons Archive as a sort of extra Archive namespace for Commons: upload source files there, point them to the main file on Commons, and link back from the Commons file to the Commons Archive source file(s). Rd232 (talk) 16:35, 4 October 2012 (UTC)
Thanks for the explanation. So this basically extends my range of file types, but unfortunately still leaves me with lots of manual linking work, right? bamse (talk) 20:47, 4 October 2012 (UTC)
Yes, though it's not really more work than it would be if Commons allowed the extra filetypes without handling them properly (you'd need to link the non-handled files with "normal" file versions). The extra work really only comes if Commons one day accepts a new filetype; but that can be handled by a bot transferring files from Commons Archive. Rd232 (talk) 21:38, 4 October 2012 (UTC)
BTW gnuplot code is currently just put on file description pages as text - see {{Created with Gnuplot}}. Rd232 (talk) 16:37, 4 October 2012 (UTC)
I don’t see how this may be a problem. Source code (be it Gnuplot, LaTeX, Matlab, whatever) is text. Why would we want to store it somewere else than on the file description page? Jean-Fred (talk) 17:03, 4 October 2012 (UTC)
We'd want to store it elsewhere if it was getting very long. But for the sort of thing we're talking about, that's probably not an issue. I'm not sure if there's any other reason to have it as a separate file. Rd232 (talk) 17:26, 4 October 2012 (UTC)
Just one more thought on this. Perhaps some external tool (thinking of something like the move-to-commons helper at the moment) could be created which:
  • uploads main file to wikimedia commons
  • uploads supporting files to commons archive
  • creates links to commons archive files in the file description of the main file (on wikimedia commons)
This would allow upload of arbitrary supporting file types and would not require manual linking (i.e. less work) by the uploader. bamse (talk) 11:54, 9 October 2012 (UTC)

GFDL

There is a discussion at Commons_talk:Featured_picture_candidates#Proposal:_Change_to_FP_criteria_for_new_nominations:_disallow_.22GFDL_1.2_only.22_and_.22GFDL_1.2_and_an_NC-only_license.22. -- Jkadavoor (Jee) (talk) 07:36, 9 October 2012 (UTC)

Deprecating software licenses for images

Since at least early 2009, and in similar form since at least 2006, Commons:Licensing has said (at Commons:L#Well-known_licenses)

The GFDL is not practical for photos and short texts, especially for printed media, because it requires that they be published along with the full text of the license. Thus, it is preferable to publish the work with a dual license, adding to the GFDL a license that permits use of the photo or text easily; a Creative Commons license, for example. Also, do not use the GPL and LGPL licenses as the only license for your own works if it can be avoided, as they are not really suitable for anything but software.

Following some recent discussions (here), there is some support for the idea of banning new uploads from using these licenses. I present some variations of how this can be done, using GFDL as a short-hand for all full-text licenses. Please remember this applies only to new uploads, and that in all scenarios dual-licensing with GFDL and CC-BY-SA remains the standard. Note: we might want to consider exceptions for cases where images come from external sources or are derived from software (screenshots). Rd232 (talk) 12:19, 9 October 2012 (UTC)

PS Commons:License Migration Task Force may be considered background reading for the long-term move away from GFDL. Rd232 (talk) 13:07, 9 October 2012 (UTC)
"Ban GFDL-only uploads, without exceptions" scenario collapsed, as exceptions are needed
Scenario 1
Ban GFDL-only uploads
  • New uploads may not use GFDL/GPL/etc full-text-copy-required licenses as their sole license.
  • Dual-licensing with any other license(s) is acceptable.
  • There must be an exemption for derivative works made from software or software documentation. I think what you actually want is to Ban GFDL-only uploads for newly self-created photos and graphics. This is not meant as a support (vote). -- Rillke(q?) 12:33, 9 October 2012 (UTC)
  • While some exception for software screenshots or whatever might be needed, we mustn't have one set of licence options for "self-created" and another for externally sourced photos.
  •  Oppose While I support the idea of banning GDFL only sole licences for media the second clause ruins this proposal. Dual licencing GDFL and a CC -NC licence, for example, is not acceptable. Colin (talk) 12:53, 9 October 2012 (UTC)
Nevertheless, currently we have quite a number of images with exactly that combination. --Túrelio (talk) 13:08, 9 October 2012 (UTC)
Because it's currently acceptable. The proposal below would change it for new uploads, and Colin favours that. Rd232 (talk) 13:25, 9 October 2012 (UTC)
  • New uploads may not use GFDL/GPL/etc full-text-copy-required licenses as their sole license.
    • Exception: uploads which are derived from software or software documentation (where such licenses are the norm)
  • Dual-licensing with any other license(s) is acceptable.
  •  Support Licenses designed for software should only be used for media when absolutely necessary: dual-licensing media with such licenses is harmless, but single-licensing is bad. As far as I can see, "absolutely necessary" means media derived from software and software documentation, where such licenses are the norm. If other exceptions are brought forward I'm happy to consider those, but for me the basic principle is to avoid single-licensing with such licenses if at all possible. This is precisely why we had the whole Commons:License Migration Task Force business, and frankly it's a bit bizarre that single-licensing wasn't restricted for new uploads (as much as possible) after that happened. Rd232 (talk) 13:36, 9 October 2012 (UTC)
  •  Support I support this approach to complete the transition begun in the licensing update: to license works that are not software under licenses that are better suited to the Commons. For software these licenses obviously still make sense so allowing uploads derived from software under those licenses is proper. Hekerui (talk) 15:24, 9 October 2012 (UTC)
  •  Oppose This only gets part right because dual licencing with CC BY-NC-SA is no improvement as far as commercial reuse is concerned. No "acceptable" licence should "require" dual or multi-licencing in order for it to be valid. Either the licence is acceptable on its own, or it is merely a supplementary licence (like CC BY-NC-SA) that users are free to add to an acceptable licence. Colin (talk) 18:30, 9 October 2012 (UTC)
    • In this scenario these types of licenses are not acceptable on their own except for certain limited cases; this is really quite simple, but you seem to have a talent for making it really complicated. And frankly the fact this scenario doesn't solve your NC problem is not in itself a reason to oppose; it is at least a step in that direction, and certainly does not preclude addressing it. Rd232 (talk) 19:59, 9 October 2012 (UTC)
  •  Comment The GFDL might also be suitable for books independently of software. But new books are not uploaded to Commons, and might not be in scope anyway. Yann (talk) 05:18, 10 October 2012 (UTC)
    • GFDL is suitable for books: it's used extensively by people like en:VDM Publishing who republish Wikipedia as books... As I said above, I'm willing to add other exceptions than software or software documentation, but it needs exceptions we actually want to use. One area to think about is the source materials hosted for Wikisource, which may be documents rather than media. Is it plausible that these use GFDL as their sole license, if they're not related to software? If it is, we can just add another exception for "primarily textual works" or something like that. Rd232 (talk) 07:56, 10 October 2012 (UTC)
      • Books can certainly be uploaded to Commons and be in scope - example. That book is PD, but there's no reason why a recent freely-licensed book couldn't be uploaded. A list of exceptions "the GFDL is not OK, except for software, books...." is not ideal. Maybe something on the lines of "the GFDL is not OK for original media, but all other GFDL content (including media derived from GFDL works) is OK".
  • To clarify above comment, I  Oppose on principle a "ban on GFDL-only uploads (except for software-related works)". I would  Support a "ban of GFDL-only uploads of original media". This is because it bans the images that are a concern, and nothing else. A blanket ban covers everything, and requires a list of exceptions to be workable. Those exceptions will be more complex than the policy. Banning only the files that are a problem removes the need those exceptions.--Nilfanion (talk) 12:07, 10 October 2012 (UTC)
    • That's not necessarily simpler - it may just displace the complexity onto defining "original media". If the list of exceptions is short (so far we have one, and I've suggested one more), then the exceptions approach is clearer than yours, which depends on a term that isn't well-defined. Rd232 (talk) 14:19, 10 October 2012 (UTC)
      • Agree with Rd232 that this is no simpler. If one defines "original" as not a "derivative work" then one only needs to publish as GFDL elsewhere and ta da! you can generate a derivative work you can upload to Commons and escape the ban. But ultimately this proposal isn't going anywhere as it breaks fundamental Commons licencing principles. If one starts with the premise that GFDL is unsuitable/impractical then adding another unsuitable licence (such as CC BY-NC) isn't going to make it acceptable. Every image on Commons needs at least one acceptably free and practically free licence. Colin (talk) 19:40, 10 October 2012 (UTC)
        • Such gaming would be pretty obvious and could be dealt with accordingly. "images, videos and sound files created by the uploader" is less ambiguous and avoids that. This immediately shows one further problem. Say there's another website with good GFDL-only images on it. Can we grab them? Derivatives of GFDL-only content on Commons? Images in a software manual? Images in a fictional book? Are we sure that there are no other exceptions? Or for that matter, promotional photos from a press release for a game? "Software-related" is a vague-term itself  ;)--Nilfanion (talk) 21:29, 10 October 2012 (UTC)
  •  Oppose Per Colin. "Dual-licensing with any other license(s) is acceptable" is problematic, because it allows, for example, GFDL and CC-BY-NC. Individually unsuitable licenses do not become suitable in combination. This would be better if worded as "GFDL may be used as a secondary license provided that a suitable license is given also" or something like that. cmadler (talk) 12:29, 18 October 2012 (UTC)
  •  Oppose per COM:SCOPE#File in use in another Wikimedia project: Commons also exists as a media repository for other Wikimedia projects. As long as the Syldavian Wikipedia or the Brutopian Wikibooks accepts GFDL files, then Commons needs to accept files from those projects. A ban would not really change anything: you would just have to upload it to Commons using Commonshelper instead. --Stefan4 (talk) 12:57, 18 October 2012 (UTC)
    • COM:SCOPE concerns scope only, not licence or copyright issues. There are loads of files that are on Wikipedia projects that cannot be uploaded to Commons: Fair use images and those with Freedom of Panorama issues are just two examples. Colin (talk) 14:00, 18 October 2012 (UTC)

Self-compiling Creator template

Just to let you know that a test js script can fill an empty Creator template reading and adapting data coming from it.wikipedia. This comes from an AJAX inter-project call for wikitext I presume, it will be not so difficult to edit scripts to let they read en.wikipedia or other wikipedias. For details and WIP see User talk:Jarekt. Is there any other similar project? --Alex_brollo Talk|Contrib 14:52, 4 October 2012 (UTC)

I would love to have a version reading en.Wiki. --Jarekt (talk) 15:58, 4 October 2012 (UTC)
I'll do my best; I'm in debt with you, both for your work about Book and Creator templates and for your personal, kind and patient suggestions too.
I suppose that my code has to be deeply reviewed since I'm a layman programmer but the bold, rough idea runs and I presume that a good js programmer would catch the idea and develop it into a good tool. --Alex_brollo Talk|Contrib 16:20, 4 October 2012 (UTC)
Getting data from en.wiki Infobox template family turned out pretty simple, luckily I wrote generalized algorithms for basic text managing. Please a suggestion: where can I post needed documentation about js tools and their use here into Commons, considering that they are presently WIP? And - can I add a link to that doc page into Creator template documentation? --Alex_brollo Talk|Contrib 08:39, 5 October 2012 (UTC)
You could start putting this in your user namespace and someone with admin privileges will discuss/review it and then maybe move to MediaWiki-namespace or making a gadget from. I hope that, when WikiData is ready to use, we can simply use their database and format the template the way we like. You can also start with the documentation in your user namespace. -- Rillke(q?) 10:36, 5 October 2012 (UTC)
Thanks. Using Gadgets style, I'll simply write a User:Alex brollo/Library page matching main scripts collection User:Alex brollo/Library.js.
About wikidata: I presume that Wikidata will need to be fed with good data, so any effort to make Book and Creator "perfect" is to be considered a real step in Wikidata future development. My present aim is exactly to merge best data about authors and books into well structured and unique "data containers" and Creator and Book are excellent candidates IMHO. --Alex_brollo Talk|Contrib 11:06, 5 October 2012 (UTC)
Thanks Rillke for reviewing js code! An impressive list of comments... I presume, you found the complete repertoire of mistakes of js beginners :-)
Much work is needed to convert scripts in user-friendly and sysop-friendly ones ;-) . --Alex_brollo Talk|Contrib 14:06, 8 October 2012 (UTC)

Current version of this tool works great, ... for some creators. Just to recap, the tool allows semi-automatic creation of creator pages based on metadata found at en and it wikis. At this stage I see it as a proof-of-concept effort, that proved that concept is sound. However it needs future development, which as Alex stated somewhere might be a "project above [his] skills/time". May be we should move it out of user namespace to MediaWiki-namespace and make it a more collaborative project. I think this tool is very useful and very needed as it speeds up a rather time consuming process. --Jarekt (talk) 14:56, 9 October 2012 (UTC)

= Active table

I'm happy to let you know that a ActiveTab() js routine, launched into any page with a structured template lke Creator, Book, Information here or Infobox into pedia projects, converts template code into a form which can be comfortaby edited. Sets of homologous data coming from other sources could be loaded into that Active table, allowing a very effective and intuitive comparison of data and use of them to edit them. I'm testing different strategies to collect data from external sources and to load them into such Active table, as an alternative to idea previously commented. --Alex_brollo Talk|Contrib 06:49, 27 October 2012 (UTC)

Prevent end-runs around Licensing Policy ban on Non-Commercial-Only licensing

The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
On discussing with Rd232, it is clear that this proposal is not gaining any degree of community discussion necessary to make such a major change. There is community support for licence reform as witnessed by the recent change to the FP criteria, but they will requite careful drafting before being presented to the Commons community for policy changes. Colin (talk) 14:05, 18 October 2012 (UTC)
Discussion about previous version of this proposal
Scenario 2
Ban GFDL-only uploads AND require dual-licensing with a COM:L-compatible license
  • New uploads may not use GFDL/GPL/etc full-text-copy-required licenses as their sole license.
  • Dual-licensing with any other license(s) is acceptable as long as at least one license is compatible with Commons:L#Acceptable_licenses.

Note that this scenario rules out GFDL+CC-BY-NC licensing, but permits, for example, GFDL+CC-BY-SA+CC-BY-NC.

    •  Oppose. CC-By-ND + GFDL gives you the chance to print post cards, T-shirts, without having to print the full text at the back side. BTW, GPL (and full text licenses that do not require printing the full text directly next to the creative work) are not so horrible if you really care about proper reuse: My Phillips TV uses the Linux Kernel and therefore had a booklet with the GPL attached. So I don't see the real problem. -- Rillke(q?) 12:38, 9 October 2012 (UTC)
      • Maybe so, but AFAIK there are no valid CC-BY-ND license tags at the moment: eg {{Cc-by-nd}} redirects to {{Nonderivative}} speedy deletion tag. (Same for CC-BY-NC, which redirect to {{Noncommercial}}.) Maybe there should be such tags (possibly requiring another COM:L-compatible tag to be provided, to ensure COM:L-compliance), but I guess that's a discussion for elsewhere. Rd232 (talk) 13:14, 9 October 2012 (UTC)
    •  Oppose Could this proposal possibly be more badly worded? COM:L is where such a policy statement is likely to be stated so this proposal introduces a circular rule. Colin (talk) 12:55, 9 October 2012 (UTC)
      • Clarified slightly: I meant the conditions spelled out at Commons:L#Acceptable_licenses. And BTW since the statement doesn't include any actual contradiction with COM:L, I don't see the problem. Rd232 (talk) 13:01, 9 October 2012 (UTC)
        • But don't you see that this is an attempt to define "acceptable licences" and it refers to the "acceptable licences" section of COM:L. I think this proposal is premature as the other discussion is still ongoing. I've also asked Erik Möller for guidance and suggest he is involved in any drafting of a proposal. There's nobody here who knows more about licencing than Erik. Colin (talk) 13:17, 9 October 2012 (UTC)
          • There is no contradiction, so please don't invent one. In any case, the proposals are for policy content, not policy wording; I'm sure if agreed the content can be implemented without creating some kind of logic-imploding nightmare within the policy. And no I don't see at all how the discussion at FP means this one shouldn't happen - on the contrary, since people are thinking about the issue, now is the time. More input is welcome, including from Erik Möller. Rd232 (talk) 13:30, 9 October 2012 (UTC)
            • I'm not saying there's a contradition. I'm saying you've created a circular definition. What is needed is to take GFDL out of the list of acceptable licences for images (and maybe other media), relegating it to one of the allowed supplimentary licences such as CC BY-NC-SA. If you can word it that way, you'll get my support. Colin (talk) 13:44, 9 October 2012 (UTC)
              • I didn't understand the point. If anybody add GFDL with another valid license is not a problem. But the media should have at least one valid license like CC-BY-SA or any other. Am I right? -- Jkadavoor (Jee) (talk) 14:02, 9 October 2012 (UTC)
              • I see what you're saying, and that would be one way to implement the proposal - maybe the best way. But I don't see that it's necessary to decide that implementation now - it's fine to just discuss the principle. But if you want to propose some specific wording for implementation, fine, maybe it'll be clearer. Rd232 (talk) 14:18, 9 October 2012 (UTC)
                • Commons:Multi-licensing says "Commons contributors can offer as many licenses for a file as they wish, as long as at least one of them meets the criteria for free licenses specified in the licensing policy." All we need to do here is remove GFDL from the list of free licences in COM:L (at least for images). Possibly GPL too. People need to see the effect on policy in order to appreciate what they are discussing. Colin (talk) 14:31, 9 October 2012 (UTC)

Suggested rewording for proposal:

Remove GFDL from the list of free licences at Commons:Licensing with an exception for media uploaded before [the date this proposal is accepted]. The Commons:Multi-licensing will thus permit (and indeed encourage) GFDL multi-licencing when combined with one of the remaining acceptable free licences. Colin (talk) 14:31, 9 October 2012 (UTC)

Remove GFDL from the list of free licences - um, there is no such list. If we're going down this road, we should cut to the chase, which is to add to the The following restrictions must not apply list at Commons:Licensing#Acceptable_licenses
* Full copies of the license to be distributed with the licensed content. Exceptions: (i) works derived from software using such licenses (ii) works uploaded before 1 January 2013. Note: this means the GFDL is not an acceptable license by itself, and can only be used as part of multi-licensing (see #Multi-licensing).

Rd232 (talk) 15:37, 9 October 2012 (UTC)

    • This just emphasises my point. The proposal is premature and should be withdrawn. Let's get input from the foundation and licence experts first before going off half cocked. Otherwise it will just be a waste of everybody's time and more effort will be spent nit-picking issues with the proposal than addressing the actual problem: that this legacy licence is being used to evade the NC ban. Colin (talk) 15:49, 9 October 2012 (UTC)
      • Riiight... so you put the cart before the horse with insisting that we should nail down exact wording before agreeing the principle, and now you want to forget about both cart and horse? Words fail me. Rd232 (talk) 16:20, 9 October 2012 (UTC)
        I have to agree with your position here, Rd232. There are many problems with the GFDL's terms, but excluding one specific named license does not address the problem with its terms. If the GFDL is banned only because it is the GFDL, then there's nothing to stop uploads using a differently named license with equally problematic terms. Instead, we should concentrate on what we consider to be acceptable licensing terms. Traditionally, we have aligned our licensing requirements with the Definition of Free Cultural Works and other existing free licensing movements. Imposing additional requirements to exclude the GFDL and similar licenses would constitute a departure from this position. Let's be clear about the fact that if we do that, we take it upon ourselves to justify those requirements. —LX (talk, contribs) 17:29, 9 October 2012 (UTC)
        • FreedomDefined state "whenever the user of a work cannot legally or practically exercise his or her basic freedoms, the work cannot be considered and should not be called "free."" The impracticality of GFDL with images in many situations would rule it out of being a free licence wrt images (but not, for example, for documentation for which it is designed). This is why we need Erik Möller on board. However, even if GFDL is only perceived to be impractical (because, for example, the law wouldn't respect its burdens), the issue remains that in 2012 this licence is being used as an approximation to NC and to restrict reuse to Wikipedia alone. Colin (talk) 18:37, 9 October 2012 (UTC)
  • I too can see only a preferred list there; not a final list. -- Jkadavoor (Jee) (talk) 16:28, 9 October 2012 (UTC)

Rebooted proposal

Currently Non-Commercial-Only licenses (eg CC-BY-NC) are not allowed on Commons as the sole license for a file (because such licenses don't meet the definition of "free enough"). Some users bypass this restriction by dual-licensing with NC licenses and GFDL: because the GFDL is not designed for media and is impractical for many purposes (especially in print), this means the file is for many practical purposes NC-only, violating the spirit (though not the letter) of Commons:Licensing.

This proposal is to require new uploads to be licensed with at least one license which

  1. allows commercial use
  2. does not require a full copy of the license to be included with the licensed content.

This definition excludes GFDL and similar licenses designed for software. Note that this scenario rules out GFDL+CC-BY-NC licensing, but permits, for example, GFDL+CC-BY-SA+CC-BY-NC.

An exception should be made for media derived from software and software documentation, where such licenses are the norm. Rd232 (talk) 20:12, 9 October 2012 (UTC)

This is definitely an improvement but still quite complex and not framed in terms of Definition of Free Cultural Works which I agree with LX is important. Some users are not including NC either, just a sole licence with GFDL. The effect of that is even worse and reuse by anyone is made burdensome.
Erik Möller has replied to my questions on his talk page. Much like LX notes above, Commons and WMF licencing policy is based on the Definition of Free Cultural Works and Möller believes it is up to the community to decide whether a combination of licence x media meets that definition. One could say that presently our licence definitions don't distinguish the combination of licence x media other than as recommendations. Thus folk can rightly say GFDL is a free licence but to leave it at that is too simplistic because one must consider the media type, the context in which the licence is being used. The GFDL was designed for a different purpose than images and WMF and others recognise this hence the shift to CC. What remains is that the legacy and historical combination of GFDL+image is now being used for abuse: to prevent or discourage reuse.
I'm going to make an alternative wording suggestion, which I think is in keeping with the above, but framed in terms of the Definition of Free Cultural Works.

Proposal: The GFDL is no longer considered a "Free Culture Licence" under the terms of the Definition of Free Cultural Works other than for the substantial textual documents for which it was designed. Specifically this constraint applies to media of type image, video, sound and short texts. This is due to the significant practical burden it places upon reuse of such media in many circumstances, and the abuse of this licence to prevent the reasonable reuse of such media. The GDFL will be permitted in the case of derivative works that require this licence (such as screenshots of some software, or modifications to existing GFDL images on Commons). This applies to new media uploaded from [date].

The above proposal has the effect that multi-licensing policy remains unchanged and dual-licencing GFDL + CC BY-SA is still absolutely fine. Colin (talk) 20:49, 9 October 2012 (UTC)
Your wording above sounds like it's redefining something beyond Commons' control. You also seem persistently to act as if GFDL is the only license at issue. Finally, putting the rationale for policy into policy, except possibly in explanatory footnotes, is bad practice. Of course, I still think there is no reason to insist on working out precise wording before understanding whether there is likely to be support for the principle. Rd232 (talk) 21:56, 9 October 2012 (UTC)

Note: please don't support/oppose this just yet. Comments/suggestions if you have them, on the wording of the proposal, not whether you agree with it or not. Colin (talk) 21:42, 9 October 2012 (UTC)

The wording of the proposal is clear enough. For some reason you also want to be clear on precisely how the proposal would be implemented. Well since I don't actually support the proposal, do as you see fit. Rd232 (talk) 21:56, 9 October 2012 (UTC)
Why on earth have you proposed something you don't support? That's just a recipie for disaster. Actually, your proposal is all implementation and no concept or principle, whereas the above establishes the community view of applying a principle to problematic combinations of licence and media. Well then I'll work with folk who support the proposal in order to draft some suitable wording. Colin (talk) 09:33, 10 October 2012 (UTC)
I proposed it because I thought it would discussion along. And it has. your proposal is all implementation - no it isn't, in this context implementation is policy wording, and that is not specified. Rd232 (talk) 14:21, 10 October 2012 (UTC)

As impracticle as GFDL is, stated above FreedomDefined state "whenever the user of a work cannot legally or practically exercise his or her basic freedoms, the work cannot be considered and should not be called "free." cc-by-NC prevents commercial users reusing the material, cc-by-ND prevents someone modifying the image or making another work, cc-by-SA limits the user as to how they license their work by the FreedomDefined definition none of those licenses should be called "free". If we are going to change to truely free licenses its Commons should first, encourage authors to alter to an existing a free license. Gnangarra 23:49, 9 October 2012 (UTC)

Can you explain your claim about CC-BY-SA? FreedomDefined class CC-BY-SA as a free license,[1] and its Attribution and Share-Alike conditions seem to be covered under their list of [permissible restrictions on freedom. --Avenue (talk) 06:34, 10 October 2012 (UTC)
While "free", CC-BY-SA is also restrictive for reusers since they must relicense the work under the same CC-BY-SA license along with the attribution, were as CC-BY only requires attribution (which most reusers currently do regardless of the license). Bidgee (talk) 12:38, 11 October 2012 (UTC)

Like the progress of the discussion. -- Jkadavoor (Jee) (talk) 04:44, 10 October 2012 (UTC)

Here's what Erik Möller wrote on his talk page in response to my queries:

Historically the interpretation of which licenses are sufficiently free for Commons has been left up to the community, and that's where I believe it belongs. The WMF licensing policy specifies that licensing must be compliant with the Definition of Free Cultural Works, but whether specific licenses are or aren't consistent with the Definition for specific purposes is IMO a matter of such ambiguity that it requires ongoing community discussion. The GFDL and similar licenses that are being used for purposes other than the ones they were originally developed for are perfect examples of this dilemma, as they were clearly drafted to support free sharing of information, but nonetheless may not be appropriate in all circumstances.

It is based on this approach that I made the above "The GFDL is no longer considered ..." proposal. This is the community clarifying whether a specific licence and specific media types are usefully considered free. I'm not aware that folk are widely uploading images with GPL or yet another unsuitable combination, but if that's so then it can be addressed too. Colin (talk) 09:33, 10 October 2012 (UTC)

As long as the GFDL is listed here it is a free license, as defined by the Definition of Free Cultural Works. That Definition, and the inclusion of the GFDL, is outside of the control of Commons' users. Maybe the Definition itself could be revised to address the functional non-commercial restriction of the GFDL, but nothing done on Wikimedia Commons can change that.
The Commons community can always choose to break away from the Definition, but it cannot follow the Definition exactly and forbid GFDL-only media. A proposal on the lines of: "Commons follows the Definition, except in this case" is workable.--Nilfanion (talk) 11:07, 10 October 2012 (UTC)
I think you misread or misunderstood the proposal. Which is not to forbid GFDL-only files, but only to use GFDL-only for certain types of files. As the proposal says, GFDL-only would still be allowed for texts. Yann (talk) 11:32, 10 October 2012 (UTC)
I get what the proposal is about... My comment immediately above is a response to Colin, in that you can't have one's cake and eat it too (can't follow the Definition exactly and forbid GFDL for certain classes).--Nilfanion (talk) 11:44, 10 October 2012 (UTC)
The FreedomDefined definition is not as black and white as you make out. Erik Möller (as quoted above) points out that whether a license fits the definition may depend on what sort of content it is being applied to. We can determine our own interpretation of the FreedomDefined definition, as it applies to the content we host, without needing to slavishly follow the list of free licenses given at FreedomDefined.org. --Avenue (talk) 12:02, 10 October 2012 (UTC)
It is worth pointing out that Erik Möller, Deputy Director of the Wikimedia Foundation, created the FreedomDefined website/definition (though isn't the sole author) and Erik has said that it is up to us, the Commons community, to decide on particular licence+application combinations that are permitted. I quote "whether specific licenses are or aren't consistent with the Definition for specific purposes is IMO a matter of such ambiguity that it requires ongoing community discussion". So I don't see any contradition and once we get the wording right, we plan to have that community discussion. Assuming that "x is a free licence" is a sufficient condition for all media types is grossly simplistic. Commons is based on Definition of Free Cultural Works, which is a set of principles that define a free cultural licence. So in reply to Nilfanion, yes we are following the Definition exactly, and in particular the part where it says "whenever the user of a work cannot legally or practically exercise his or her basic freedoms, the work cannot be considered and should not be called "free." The list of licences is just a list of licences and discussion about them. Presence on that list does not bind Commons into accepting it for uploads. Colin (talk) 12:18, 10 October 2012 (UTC)
The definition as it applies to the GFDL (and other licenses), when used in certain contexts, does give scope to ban things and remain consistent with the Definition's spirit. The underlying principle here is "if a license requires full-copy attached to any copy of the work, then if the nature of the work makes this impracticable it is not free" (and I agree with that). My point is as that concept is not in the definition and we should make it clear that we have added that ourselves, in a way that we believe is consistent with the definition, as opposed to it being part of the definition.
That principle should be kept separate from the specific "what do we do about GFDL-only graphic works?" question. Like I said above, it would be simpler to say "the GFDL is banned for this class of works" rather than "the GFDL is banned, except for this case, or that one, and under these conditions".--Nilfanion (talk) 12:49, 10 October 2012 (UTC)
What we're doing is the application of that Definition to the media types Commons hosts. I'm not quite sure what you think we are "adding" to the definition? The defintion has all along said that the licence needs to be "practical", and Commons has long stated that GFDL is impractical for images. So this is nothing new or controversial. What's new is deciding to do something about it.
Perhaps we can separate out the "GFDL is no longer considered free for images" statement as one proposal and the "What is commons going to do about it" as another? Obviously one drastic choice is to delete all inappropriately licenced material. I suspect that wouldn't be good or welcome :-). So my suggestion is new uploads. But then we also want to take screenshots of GPL software and probably want folk to be able to crop or fixup existing GFDL images. Maybe some other issues? I'm rather reluctant to make two proposals because that splits the discussion and the "What is commons going to do about it" has quite a bearing on whether people are keen to revise their opinion on GFDL being free enough. So I think it best to offer one proposal that has been thought through properly.
Would it help to invert the statement:

The GFDL is only considered a "Free Culture Licence" under the terms of the Definition of Free Cultural Works for substantial textual documents for which it was designed. Specifically it is not free when applied to media of type image, video, sound and short texts. This is due to the significant practical burden it places upon reuse of such media in many circumstances, and the abuse of this licence to prevent the reasonable reuse of such media....

Can you offer an ammended text that you think is better worded? Does that statement need to explain the "requires full-copy of GFDL attached" aspect of the "significant practical burden"? -- Colin (talk) 14:25, 10 October 2012 (UTC)
Well two points: First drop the "abuse of this license...". I realise that's what triggered this, but its not the reason why GFDL is bad. GFDL is bad for photos because its cumbersome, not because its misused. That means that phrase isn't needed.
More importantly, this is not just about the GFDL. The GFDL is the prime example but is not the only problematic license. A ban of the GFDL could allow those who abuse it to switch to say, the GPL, which is no better. The text can address this by sticking to the generic to start with. "A license is not free for images, videos and sounds if it requires a large amount of additional material to be provided with each use of the media." Then a sentence describing why that is bad. It can move to the specific and say "for example, the GFDL is not free because it requires the full license text to be provided". This prevents us having to come back here in 6 months time when they switch to the Apache license.--Nilfanion (talk) 21:19, 10 October 2012 (UTC)
You make some valid points. I'm working on a draft at User:Colin/GFDL. This contains an introduction, to bring everyone up to speed and remind folk of the well-established issues, explains how the Definition can be applied for these media types, and a proposal. It is a work in progress. Can I encourage you and anyone else here to look at this draft and add your comments on the talk page. Wrt GPL/Apache I agree these are also unsuitable but they aren't as far as I know being abused (to use that word!). Since Commons only hosts image/audio/video, I don't see why it makes any sense for our policy page to list licences for computer software or databases as being examples of acceptable free licences. It might be good to sweep this confusion up as well, but GFDL is in practice the only problem at present. I'm off to bed now.

Please see notice above concerning the draft in my user space. I intend for this draft to be collaborated on by those who support it before any proper proposal is made. Colin (talk) 21:49, 10 October 2012 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Village_pump/Proposals/Archive/2012/10&oldid=83615401"