For kicks, a while back when there was the BJAODN debate on copying content from one page to another and possible copyvios, I took it upon myself to write to the FSF compliance lab with my understanding of the situation and see if they would provide their commentary.
I just got a response and thought I should share it with you.
Angela
---------- Forwarded message ---------- From: Brett Smith via RT licensing@fsf.org Date: Jul 18, 2007 2:59 PM Subject: Re: [gnu.org #336602] FDL and Wikipedia To: psu256@member.fsf.org
On Thu, Jun 07, 2007 at 04:25:25PM -0400, psu256@member.fsf.org via RT wrote:
There is a bunch of discussion on the English Wikipedia mailing list over the last week or so about the FDL and whether some of the practices of the Wikipedia do not meet the letter of the law of the FDL.
Angela,
I'm very sorry for the delay in getting back to you. We needed to make sure we completely understood Wikipedia's practices before providing an answer.
1 ) Since providing a "History" of the whole Wikipedia would be unwieldy, individual pages are generally considered separate documents, each with their own history log. Now, imagine someone wants to copy text from one article on the Wikipedia to another article (for "merge and delete" into one main article, etc.). The issue is, the editor who did the copying is logged by the software, but the copier doesn't go through the history of the original and log each individual contributor to the original as part of the new article history. (For an article with hundreds of edits, attempting to find who added a particular copied sentence might be a nightmare.) Since, unlike the wiki for the GPLv3 which assigns copyright to the content to the FSF, the Wikimedia Foundation never assumes copyright for the content. So, technically, does the "merge and delete" process violate the FDL because the history for the copied text is lost when the original article was deleted?
I'm reluctant to definitively state that this is a violation, but that information really should be available in some form or another. I think there are lots of ways that could be done; for example, it would probably be fine if the history section of the final article had a link to the history section of the article that was merged in.
- Currently, anonymous edits are logged by IP address, but an IP
address cannot be traced to an individual (despite what RIAA might have to say about that topic??? but I digress.) Is this logging of IPs enough to fulfill the history requirements of the FDL?
I think Wikipedia itself is fine doing what it does here: since authors have almost full control over how they're identified to Wikipedia -- they can provide as little as an IP address, or go as far as offering complete contact information on their user page -- and contributors should know that going in, there should be no problem with simply relaying that information to the rest of the world.
If you have further questions, please let me know.
Best regards,
-- Brett Smith Licensing Compliance Engineer, Free Software Foundation
Please note that I am not an attorney. This is not legal advice.
On 7/18/07, Angela Anuszewski psu256@member.fsf.org wrote:
For kicks, a while back when there was the BJAODN debate on copying content from one page to another and possible copyvios, I took it upon myself to write to the FSF compliance lab with my understanding of the situation and see if they would provide their commentary.
Did you have to mention Wikipedia in your inquiry? *shakes head*
On Thu, Jun 07, 2007 at 04:25:25PM -0400, psu256@member.fsf.org via RT wrote:
for example, it would probably be fine if the history section of the final article had a link to the history section of the article that was merged in.
Ergo, the history section being linked to needs to be visible to the general public, not deleted on the presumption that nobody will want to read it. What would be the purpose of linking to a history section which no longer exists?
—C.W.
On 7/18/07, Charlotte Webb charlottethewebb@gmail.com wrote:
On 7/18/07, Angela Anuszewski psu256@member.fsf.org wrote:
For kicks, a while back when there was the BJAODN debate on copying content from one page to another and possible copyvios, I took it upon myself to write to the FSF compliance lab with my understanding of the situation and see if they would provide their commentary.
Did you have to mention Wikipedia in your inquiry? *shakes head*
I felt it was necessary, because a hypothetical situation similar to a real situation is by definition not the real situation. Therefore, you never get as precise an answer.
On Thu, Jun 07, 2007 at 04:25:25PM -0400, psu256@member.fsf.org via RT wrote:
for example, it would probably be fine if the history section of the final article had a link to the history section of the article that was merged in.
Ergo, the history section being linked to needs to be visible to the general public, not deleted on the presumption that nobody will want to read it. What would be the purpose of linking to a history section which no longer exists?
Exactly - there would be no purpose for linking to a history section which no longer exists. This implies that the history of a deleted article needs to be preserved and be publically available. Its a fuzzy spot. I doubt the FDL was really designed with a project as large as the WP in mind so some of the concepts that might be easy to implement with book-sized works run into real problems when brought to such a large scale.
On 7/18/07, Angela Anuszewski psu256@member.fsf.org wrote:
On 7/18/07, Charlotte Webb charlottethewebb@gmail.com wrote:
On 7/18/07, Angela Anuszewski psu256@member.fsf.org wrote:
For kicks, a while back when there was the BJAODN debate on copying content from one page to another and possible copyvios, I took it upon myself to write to the FSF compliance lab with my understanding of the situation and see if they would provide their commentary.
Did you have to mention Wikipedia in your inquiry? *shakes head*
I felt it was necessary, because a hypothetical situation similar to a real situation is by definition not the real situation. Therefore, you never get as precise an answer.
Of course, the fact that you mentioned Wikipedia probably ensured that you'd get the most imprecise answer possible: "I'm reluctant to definitively state that this is a violation" :)
On 18/07/07, Angela Anuszewski psu256@member.fsf.org wrote:
On 7/18/07, Charlotte Webb charlottethewebb@gmail.com wrote:
Ergo, the history section being linked to needs to be visible to the general public, not deleted on the presumption that nobody will want to read it. What would be the purpose of linking to a history section which no longer exists?
Exactly - there would be no purpose for linking to a history section which no longer exists. This implies that the history of a deleted article needs to be preserved and be publically available. Its a fuzzy spot.
There's nothing fuzzy about it - it's common sense, legally required, and what's morally right. Content on Wikipedia should be attributed to the creator/copyright holder (who has licensed their contribution for free use under GFDL); this is achieved through the history page. So, *all* history of the content (i.e. including from merges) has to be publically available.
Content on Wikipedia is "free" but it's not stolen.
Zoney
I'm reluctant to definitively state that this is a violation, but that information really should be available in some form or another. I think there are lots of ways that could be done; for example, it would probably be fine if the history section of the final article had a link to the history section of the article that was merged in.
In other words, we should merge and redirect, not merge and delete, which is exactly what we do. It would seem our understanding of the GDFL is correct (in that aspect, at least).
On 7/18/07, Thomas Dalton thomas.dalton@gmail.com wrote:
I'm reluctant to definitively state that this is a violation, but that information really should be available in some form or another. I think there are lots of ways that could be done; for example, it would probably be fine if the history section of the final article had a link to the history section of the article that was merged in.
In other words, we should merge and redirect, not merge and delete, which is exactly what we do. It would seem our understanding of the GDFL is correct (in that aspect, at least).
Or a history merge, or a talk page copy of the history.. So yea, thats consistent with our current approved practices.
Gregory Maxwell wrote:
On 7/18/07, Thomas Dalton thomas.dalton@gmail.com wrote:
I'm reluctant to definitively state that this is a violation, but that information really should be available in some form or another. I think there are lots of ways that could be done; for example, it would probably be fine if the history section of the final article had a link to the history section of the article that was merged in.
In other words, we should merge and redirect, not merge and delete, which is exactly what we do. It would seem our understanding of the GDFL is correct (in that aspect, at least).
Or a history merge, or a talk page copy of the history.. So yea, thats consistent with our current approved practices.
Talk page copies of a history are useless because the links aren't there. They let us know who edited, but give no details about what edits they made.. A history merge may not accomplish that either. Merge and redirect would not destroy the history. Could a special line be devised on a history page to register a merger, and allow one to trace bacvk into it?
Ec
On 19/07/07, Ray Saintonge saintonge@telus.net wrote:
Talk page copies of a history are useless because the links aren't there. They let us know who edited, but give no details about what edits they made.. A history merge may not accomplish that either. Merge and redirect would not destroy the history. Could a special line be devised on a history page to register a merger, and allow one to trace bacvk into it?
It really doesn't seem essential for the GFDL, now I think about it. We're tracing the authors of *a document*, not of individual words and sentences. The article's a collective work, a work by many people, not an aggregation of a hundred or a thousand tiny seperate works. If we had no history section at all, just a little script somewhere that added your name to a list of "this page's authors" whenever you edited an article, we'd be fine.
For editorial purposes, being able to see the details of the history is really handy. For license purposes? It's icing on the cake.
We have a list of contributors to each article - the list on the history file. We dump that onto the talk page as a plain text list. If we can look down that list of names and say "these sixteen names are there" we can easily turn it into "the document, as of this moment, is a collaborative work by these sixteen people", and we're done. Your authors are named; attribution is done and dusted.
All we need to be able to say is "the following people worked on this document". There are some false positives - people whose edits were quickly reverted and made no contribution to the article, say - but they show up in the history anyway, and I guess you could argue that they were in some conceptual way fellow workers on the document!
...
There are, of course, downsides to dumping the history; it removes the ability to do in-depth analysis to figure out who the "real authors" were. But this is less of a loss than it seems, because this is an astonishingly impractical sort of analysis to do - you can winnow out the obvious not-involved-in-the-work cases, the vandalism-revert pairs, but after that it gets very hard to computerise and awfully easy to miss out real, significant, contributors - lots of false negatives. Once there's been any kind of complex back-and-forth, simply running an automated tool for "biggest contributors" is going to get some pretty inaccurate results in any meaningful sense.