I propose that the current Project Sourceberg is integrated into a larger "Wikimedia Commons".
Said "Wikimedia Commons" should reside at commons.wikimedia.org and be a repository for - images - public domain texts - otherwise freely licensed documents - music, artistic works (but see below)
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. There would be NO fair use material on commons.wikimedia.org.
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 apply commons sense .. excuse me, common sense, to determine which files are eligible for inclusion, i.e. 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.
I propose that we shall build an interface between the files residing in the Wikimedia Commons, and other Wikipedia projects, so that it will be possible to easily reference a file in the commons, like so:
[[Image:co:Airplane.jpg|200 px|A very nice airplane]] [[Media:co:listen.mp3]]
This would not create a copy of the file or auto-generated thumbnails on the local server (e.g. en:). However, [[Image:Airplane.jpg]] could be used to describe the file in the local language and context (we should probably rename the Image: namespace to File: in the long term, because it is also used for other description pages.)
All new uploads would automatically go to the commons unless the uploader explicitly chooses not to send them there (e.g. for material which is clearly only relevant to one project, only allowed under certain jurisdictions ..).
The commons wiki itself should of course be multilingual as Project Sourceberg and Meta are. There are some features which we should enter into our software development roadmap to facilitate the transition to using the commons: - user interface languages can be set in the preferences - automatic import of source information from the commons to the description page of the local wiki - better interlanguage handling in a single wiki installation - friendly user interfaces for multi file uploading, automatic addition of uploaded files to a category etc. - things that make life easier for people not familiar with Wikipedia - automatic gallery generation for multiple images of one category
What are the advantages of this system?
- Central place to resolve licensing issues - Less time wasted on locating relevant files - Less time wasted on re-uploading 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 respoitory of freely licensed material, with a quality control mechanism that other such projects lack (the community) - We further establish our name beyond being merely the largest, greatest encyclopedia ever - 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.
What are the downsides?
- The user interface is likely to be a bit clunky at first. We can fix that. - This project can exceed Wikipedia in costs if it is successful. I believe prominent fundraisers will cover us, if not, we can fix this by limiting the scope of the commons. - People will upload all sorts of things which we don't want. We can fix that the same way we deal with Wikipedia articles we don't want. - Changes to the software will be very specific to our needs, other MediaWiki sites will probably be unable to interface directly with the commons. Maybe we can authorize other projects on an individual basis to interface with us.
I believe that we should not work on a temporary fix to the licensing (tagging) problem, but address this issue in one fell swoop instead. More generally, if we want to do this, I would suggest for Jimbo to authorize me to set up a roadmap on Meta for the implementation. That roadmap would also be a place for volunteers to list themselves for specific tasks that need to be completed. This will have to be a community effort among developers, sourcebergers, wikibookers, wikipedians etc.
I believe we can launch the Wikimedia Commons within about 3 months, maybe less, if we work together. Let me know your thoughts and possible improvements to this concept.
Please help to get the word out about this proposal by forwarding this message to the other project mailing lists, translating it, summarizing it etc. As this concerns a way to share relevant data among *all* projects, I believe every Wikimedia user should know about this and participate in the planning phase.
I suggest that the initial discussion (do we want to do this?) take place on wikipedia-l (we have no Wikimedia list yet, sadly), and that the implementation discussion, if any, take place on meta.wikipedia.org.
All best,
Erik
Erik Moeller wrote:
I propose that the current Project Sourceberg is integrated into a larger "Wikimedia Commons".
Said "Wikimedia Commons" should reside at commons.wikimedia.org and be a repository for
- images
- public domain texts
- otherwise freely licensed documents
- music, artistic works (but see below)
I think this is a great idea, and I hope there will be enough people keeping an eye on all the media that will get uploaded and check them for copyvios.
BTW, from the Creative Commons newsletter:
*Search Engine Prototype
More big news. The prototype [1] of our CC-enabled search engine is now available. It still needs some polish, but it's the first glimpse of our dream world, where you can search for noncommercial music and photos and culture to re-use as easily as finding out the weather.
Kurt
Erik Moeller wrote:
I propose that the current Project Sourceberg is integrated into a larger "Wikimedia Commons".
I fail to see the purpose for this.
Said "Wikimedia Commons" should reside at commons.wikimedia.org and be a repository for
- images
- public domain texts
- otherwise freely licensed documents
- music, artistic works (but see below)
Public domain texts are doing just fine at Wikisource.
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.
No problem with this
For texts, modification rights would also be a requirement.
There is no legal restriction to modifying public domain texts, but it would be good to have a reasonably stable semi-protected version of a text so that the reader could rely on its accuracy. I believe in a more editable parallel edit box which could contain annotations and commentary.
There would be NO fair use material on commons.wikimedia.org.
That's an extremist position.
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 apply commons sense .. excuse me, common sense, to determine which files are eligible for inclusion, i.e. if a band is notable enough to have an article in Wikipedia, and their MP3s are freely licensed, they can be deposited;
Common sense is not as common as you think. The arguments will continue to be endless.
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.
This seems like a self-defeating approach
I propose that we shall build an interface between the files residing in the Wikimedia Commons, and other Wikipedia projects, so that it will be possible to easily reference a file in the commons, like so:
[[Image:co:Airplane.jpg|200 px|A very nice airplane]] [[Media:co:listen.mp3]]
This would not create a copy of the file or auto-generated thumbnails on the local server (e.g. en:). However, [[Image:Airplane.jpg]] could be used to describe the file in the local language and context (we should probably rename the Image: namespace to File: in the long term, because it is also used for other description pages.)
I don't mind this, but before this can work effectively we need to have the unified log-in issue solved.
All new uploads would automatically go to the commons unless the uploader explicitly chooses not to send them there (e.g. for material which is clearly only relevant to one project, only allowed under certain jurisdictions ..).
Sometimes it's difficult to know whether illustrations may be used in one project only. The recent Wikisource contribution "Advanced Automation for Space Missions" includes many illustrations that came with the original publication. It's conceivable that some of these could be used to illustrate other articles.
The commons wiki itself should of course be multilingual as Project Sourceberg and Meta are. There are some features which we should enter into our software development roadmap to facilitate the transition to using the commons:
- user interface languages can be set in the preferences
- automatic import of source information from the commons to the
description page of the local wiki
- better interlanguage handling in a single wiki installation
- friendly user interfaces for multi file uploading, automatic addition of
uploaded files to a category etc. - things that make life easier for people not familiar with Wikipedia
- automatic gallery generation for multiple images of one category
These are all fine, but we still don't have a functioning system for categorization, so that should be developed first to the point where people are comfortable using it in at least one live project.
What are the advantages of this system?
- Central place to resolve licensing issues
- Less time wasted on locating relevant files
- Less time wasted on re-uploading 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 respoitory of freely licensed material,
with a quality control mechanism that other such projects lack (the community)
- We further establish our name beyond being merely the largest, greatest
encyclopedia ever
- 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.
These are potentially all true.
What are the downsides?
- The user interface is likely to be a bit clunky at first. We can fix
that.
- This project can exceed Wikipedia in costs if it is successful. I
believe prominent fundraisers will cover us, if not, we can fix this by limiting the scope of the commons.
- People will upload all sorts of things which we don't want. We can fix
that the same way we deal with Wikipedia articles we don't want.
Smaller projects tend to do this better, and with less animosity.
- Changes to the software will be very specific to our needs, other
MediaWiki sites will probably be unable to interface directly with the commons. Maybe we can authorize other projects on an individual basis to interface with us.
This need not be a downside.
I believe that we should not work on a temporary fix to the licensing (tagging) problem, but address this issue in one fell swoop instead. More generally, if we want to do this, I would suggest for Jimbo to authorize me to set up a roadmap on Meta for the implementation. That roadmap would also be a place for volunteers to list themselves for specific tasks that need to be completed. This will have to be a community effort among developers, sourcebergers, wikibookers, wikipedians etc.
I believe we can launch the Wikimedia Commons within about 3 months, maybe less, if we work together. Let me know your thoughts and possible improvements to this concept.
I suppose that if people want to work on this project they should do so. For those of us involved in other projects such as Wikisource, we should just wait and see how it goes before we agree to merge with this.
Eric also added a number of paragraphs in the Wikisource Scriptorium. Many of the arguments there extend what he has said above. I will only quote one section.
"We have worked hard to build this community, we shouldn't have to give it up."
Abandoning what has been done so far will not be necessary. The name change can be largely automated, and let's face it, "Project Sourceberg" is not a killer brandname. Beyond the software changes, what would effectively happen is that things like the Main Page would have to be redesigned to accommodate different media, but current content could in many cases simply be moved to new locations. Compared with, say, the change of the Italian Wikipedia from UsemodWiki to Phase III, the changes would be mostly cosmetic, especially thanks to the great internationalization work you have already done here.
Whether "Project Sourceberg" is a killer brand name doesn't matter since it isn't being used. That was a suggested working name before it became a reality, as was the actual name "Wikisource". "Wikisource" won on an early vote. Insisting on using "Project Sourceberg" seems to be somewhat of a slight.
The big advantage of smaller projects is that they can develop their own ways of dealing with problems. Yes we have copyright issues at Wikisource, but none of those involve pictures. Internationalization, as you have observed, is important to us, but it would be seriously damaged if we had to deal with all these other issues about licensing pictures.. Our Main Page is just fine, and we certainly don't need any automated name changes. We don't need to accomodate different media, and we don't need to move current content.
So yes, go ahead and do what you want to develop the Wikimedia Commons, but don't use that as an excuse to mount a hostile takeover of Wikisource.
Ec
Ray-
Erik Moeller wrote:
I propose that the current Project Sourceberg is integrated into a larger "Wikimedia Commons".
I fail to see the purpose for this.
The goal of Wikisource is to be a text respository. Text is only a subset of the larger group of media, and there is no reason to have a specific repository exclusively for text and a combined repository for other media. Either they should all be combined or they should all be split up.
I believe combining them is the more useful approach, because: - There is often a transparent transition from text to other types of media - The requirements are very similar in terms of standards for inclusion, licensing etc. - A larger project will benefit from a larger community where people who have previously only dealt in images will also help with the annotation and proofreading of text, and vice versa. - In terms of marketing and attracting newcomers, it is much easier to get people to join a larger project; the more interesting content there is, the more motivation there will be to participate. Someone might come to the site to get an MP3 but get hooked on Goethe in the process of finding it.
For the same reason I don't want Wikipedia to be split into a "mathematics encyclopedia", an "encyclopedia of fictional worlds", an "encyclopedia of Internet terms", I believe a true commons of all forms of media makes more sense than an artificial split that would be more the result of our project history than a logical separation.
For texts, modification rights would also be a requirement.
There is no legal restriction to modifying public domain texts, but it would be good to have a reasonably stable semi-protected version of a text so that the reader could rely on its accuracy.
This problem can be addressed by using the Meatball principle of FileReplacement: http://www.usemod.com/cgi-bin/mb.pl?FileReplacement
You would have two edit boxes, but one would not actually be an edit box, it would just show the document source. The document source would be automatically replaced with whatever is in the edit box if either a) a sysop pushes a button, b) the article has remained "idle" for a certain time, e.g. 24 hours, and the changes are therefore believed to be acceptable.
There would be NO fair use material on commons.wikimedia.org.
That's an extremist position.
Hardly. I am the person who most actively spoke out in favor of fair use on the mailing list and elsewhere, and I implemented the current fair use policy on Wikipedia. The reason there would be no fair use material on the commons site is that we cannot assume such material to be legally usable for all Wikimedia projects. We would still allow fair use on the projects which currently allow it, but files would be uploaded locally instead of to the commons. This approach has numerous advantages.
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.
This seems like a self-defeating approach
How so?
I don't mind this, but before this can work effectively we need to have the unified log-in issue solved.
Not necessarily, we can implement the Commons without single sign-on (which is a large undertaking because of article histories, dupes, different domain names etc.). When you upload a file, the server would authenticate you to the Commons, where you would be identified e.g. as "Ray@Simple-Wikipedia". This would be the name showing up on the Commons recent changes page and the Simple recent changes page (the latter possibly suppressed through a checkbox).
Sometimes it's difficult to know whether illustrations may be used in one project only.
As I said, when in doubt, material should go to the commons.
These are all fine, but we still don't have a functioning system for categorization, so that should be developed first to the point where people are comfortable using it in at least one live project.
Agreed.
- People will upload all sorts of things which we don't want. We can fix
that the same way we deal with Wikipedia articles we don't want.
Smaller projects tend to do this better, and with less animosity.
Less animosity is certainly true because there are less people involved, but I see no evidence that the standards that develop are better as well. To the contrary, the more people are involved, the more likely there will be an ongoing refinement of our standards based on user input. For example, the Wikipedia inclusion standards are quite sophitisticated and useful.
The big advantage of smaller projects is that they can develop their own ways of dealing with problems.
I fail to see how being part of the Wikimedia Commons would no longer allow you to develop "your own ways" of dealing with problems. You are setting up a false dichotomy between the Wikimedia community at large and Wikisource, in fact you actually speak of a "hostile takeover".
I do not understand where this assumption of hostility comes from and find it quite puzzling. Is that an attitude shared by other members of the Wikisource project?
It was always my understanding that we were part of a larger undertaking that transcends individual projects - hence the Wikimedia Foundation -, and if it makes logical sense to combine certain efforts, we should do so. Creating a global commons of free media certainly seems like a worthwhile goal.
All best,
Erik
wikipedia-l@lists.wikimedia.org