Currently each of the many Wikimedia projects -- every single Wikipedia and Wiktionary, as well as Wikibooks, Wikisource and Wikiquote -- has a separate directory for file uploads. There is no reliable way to reference images on other projects. Many good, free uploads on one wiki may go unnoticed on another. Thus, there is needless duplication of intellectual and creative work as well as unnecessary redundancy and increased maintenance.
- Central place to resolve licensing issues
- Less time wasted on locating relevant files
- A place for things like image galleries that go beyond the needs of a single article (e.g. 10 different pictures of the same airplane)
- We can actively solicit contributions specifically to the commons from people who are not interested in contributing on a regular basis
- We can provide the largest such repository of freely licensed material, with a quality control mechanism that other such projects lack (the community)
- We further establish our reputation beyond the encyclopedia projects.
- We benefit from the positive connotations of the term "commons" and appeal more directly to altruism, which will be beneficial when we ask for donations
- We create a very real consciousness for the copyleft idea which so far is missing especially for images, where many people simply upload whatever they find on the net.
- We can use this platform to become more politically relevant in the ongoing discourses about copyright law.
- The "modern" image format SVG allows the bitmap data to be on one location, and e.g. the localized image text on another.
Wikipedia describes a commons as a "set of resources that a community recognises as being accessible to any member of that community." Such shared resources - forests, fields, fishing grounds, and so forth - have existed in many societies: ancient, medieval, and modern. In Germany, after the Middle Ages, the local commons (Allmende) in most towns and cities were confiscated by the feudal rulers of the regions, which was one of the motivations behind the German Bauernkrieg (war of the farmers against their rulers). The farmers were brutally suppressed, and the commons practically ceased to exist. To this day, descendants of the aristocrats who profited from robbing and murdering the farmers are among the richest families in Germany.
We must make sure that a true commons can exist in the digital age, and that it can never be taken away. Open content licenses assure this. For good reason, the Creative Commons licenses are named after the principle of the commons. But it would be sadly ironic if the term "commons" became associated with a single implementation only. Indeed, it would be desirable if there would be many different commons for different online projects -- a Slashdot commons, a Kuro5hin commons, and so forth -- which provide free access to a large set of resources. Establishing this idea, and this vision, this meme, is one of the reasons for the "commons" naming suggestion.
The name commons embodies the most important underlying principle of this proposal. It is not about a particular type of content, it is about free, shared access to useful resources.
Our commons should be called the Wikimedia commons because it is not just used by Wikipedia, but by all Wikimedia projects (and many external ones). Making "Wikimedia" a part of the name also increases brand recognition for our foundation, which is as yet largely unknown.
A central repository is to be created at commons.wikimedia.org. It would hold:
- photos, diagrams and other images
- sounds and music
- artistic works
- documents (see below)
- video (within bandwidth constraints set by the community)
- The BBC are attempting to make their back catalogue open resource therefore linking into the creative commons database recently created by Nutch would be a good thing
All material in the commons would have to be licensed under one of several licenses, not necessarily the FDL, but all allowing at the very least free distribution and commercial use. For texts, modification rights would also be a requirement. [For non-text, incorporation into larger works or collections would be a requirement. -AD] There would be NO fair use material on commons.wikimedia.org.
As documents are currently maintained by Wikisource, this part of the proposal will have to be debated further as soon as the commons goes live.
Material would be eligible for inclusion in the Commons if it is useful to at least one Wikimedia project. This includes plausible future usefulness.
The Commons Community would define further criteria for inclusion, for example, if a band is notable enough to have an article in Wikipedia, and their MP3s are freely licensed, they can be deposited; if a file is highly referenced from the outside and causes unbearable bandwith costs, it can be removed. The larger and more popular a file, the more pressing needs to be its rationale for inclusion.
Discussion at Commons:Criteria for inclusion
The proposal requires some changes to m:MediaWiki, although a working version could already be set up with a relatively small amount of new code.
The MediaWiki upload form would be completely redesigned. Look at these two mock-ups:
The first selection is whether a file should be uploaded to the commons or to the local wiki (in the mock-up, the English Wikipedia). The commons would always be the default, but the local wiki could be used for things which are useful only to one wiki, or which are not allowed under the terms of the commons. For example, the English Wikipedia allows limited fair use. This option is, however, not available on the Wikimedia Commons upload form.
The second question is whether the user is the creator of the file. If they are, we narrow down the set of allowed licenses to the ones which we prefer, and the user only needs to type a description and is ready to go. We want to make things as easy as possible for original creators. There are a few more questions, however, if the user is not the copyright holder. In this case, they also need to provide source information for the image.
Note that in these mock-ups, depending on the answer to the "Are you the original creator?" question, the other part of the form is grayed out and not editable. This should make it relatively intuitive.
For another example of what the upload forms could look like, with form text translated into a number of major languages, see m:Translation/New upload form.
The commons wiki itself should of course be multilingual as Project Sourceberg and Meta are. New uploads would show up both in the upload log of the wiki from which they were uploaded, and in the commons upload log. Without a m:single sign-on, such uploads would be logged as "Username@wiki", e.g. "Eloquence@enwiki".
There would have to be a real commons community, which would take a look at uploaded files, provide translations of image descriptions, sort media files into galleries, translate and annotate source documents, and so forth. They would also be responsible for enforcing the standards of inclusion.
Usage of material from the commons needs to be largely transparent to the end user. In effect, when a user types
- [[Image:Mona Lisa.jpg]]
that request would go first to the local wiki and then, if no local copy exists, to the commons.
The image description page would transparently be imported from the commons everytime it is viewed, until it is edited, at which point a local copy would be created.
These are some features which we should enter into the m:MediaWiki roadmap if we want to implement this proposal:
- Provide an interface to a shared media file directory, and to the commons wiki database (to update the commons upload log, create image pages etc.)
- Redesign upload form and resulting description pages, allow uploading either to the commons or to the local wiki
- Transparently import pages when viewing commons image pages, permanently import them when editing them
These changes are not crucial to make the Commons work, but are desirable in the long term:
- Rename the Image: namespace to File: and revamp "image" pages to be more intuitive (allow playback of media files, for example)
- Better interlanguage handling in a single wiki installation
- Friendly user interfaces for multi file uploading
- Selectable categories for images?
- Automatic gallery generation for multiple images
- Transclusion of text from the commons (smart caching!), including individual sections
Commons as basis for single sign-on?
Since the commons proposal requires a shared database (it would be possible to access it via HTTP, but since the Wikimedia setup allows for a shared DB, that would seem unnecessary) it would only be logical to use the commons as the basis for single sign-on.
The implementation would be as follows:
- A field user_created is added to the user table. For existing accounts, this field is filled with the date of the first contribution of the user (alternatively, the date of the creation of their user page). If neither exists, the date is set to "today".
- A new table usermatch is created in the database of each wiki with the fields "local_id" and "commons_id".
- Two tables are created in the commons database: user and user_old.
- The first user_id in the commons user table must be higher than the total number of users of all projects (to avoid attribution problems)
- All unique existing accounts are loaded into the commons user table. An account is unique if it exists only with the same password across all wikis.
- All other existing accounts are loaded into the user_old table, which may include duplicate rows.
- On the creation of a new account that does not exist in the user table, the system system checks whether the account exists in user_old. If so, it prints the name of the oldest account (e.g. "Eloquence, English Wikipedia: 2002-xx") and asks the user for the password to that account.
- If the password is entered correctly, the user now owns that account in the commons database.
- The user can "hook up" additional old accounts by entering the account password. This would be done through the user preferences.
- The edits associated with hooked up accounts would be reattributed using the usermatch tables of the respective wikis. In cases where the usernames are different, a developer would have to push a button -- such cases require changing the user_text in the CUR and OLD table of the respective wiki, which can be quite a big operation.
In the long term, we should of course get rid of the usermatch table and also the user_old table, if possible. Hopefully there will only be relatively few duplicates that do not belong to the same users.
This approach has one key advantage, it quite securely prevents account hijacking. For most users the transition would be completely transparent. The most painful cases are those where a user is forced to change their name because it is already taken by an older user. They are painful largely because of our database layout.
To the end user, it makes things a little simpler, because they can see all the edits they've ever made on all wikis. It may also make stewards obsolete, because bureaucrats can have their status transferred to all wikipedias on which they have an account so they don't have to get them individually (of course, stewards still have the almighty power to desysop someone).
From a technical perspective, the implementation is not so difficult. The filling up of the required tables and fields might take some time, but could be done on a slave database. Using the shared database for logging in is trivial, a universal cookie might be a bit more difficult across different domain names.
* [[User:用戶名|用戶名]] ** 你需要解決哪方面的問題
- Commons:Criteria for inclusion - 是否允許色情描寫？等等
- Commons:許可協議 - 是否允許合理使用？等等
- Commons:Features - 對組織機構提出建議，需要怎樣運轉？