Hi!
GFDL 1.3 was released today (http://www.fsf.org/news/fdl-1.3-pr.html). Any thought which version should be default, multiple versions, etc?
Eugene.
2008/11/3 Eugene Zelenko eugene.zelenko@gmail.com:
Hi!
GFDL 1.3 was released today (http://www.fsf.org/news/fdl-1.3-pr.html). Any thought which version should be default, multiple versions, etc?
Eugene.
We default to CC-By-SA 3.0. One significant problem we face is if we actualy qualify for the swtichover:
Massive Multiauthor Collaboration Site" (or "MMC Site") means any World Wide Web server that publishes copyrightable works and also provides prominent facilities for anybody to edit those works.
We do not provide provides prominent facilitiesm to edit images.
2008/11/3 geni geniice@gmail.com:
Massive Multiauthor Collaboration Site" (or "MMC Site") means any World Wide Web server that publishes copyrightable works and also provides prominent facilities for anybody to edit those works.
We do not provide provides prominent facilitiesm to edit images.
We have version history and re-uploading, which IMO qualifies even by a literal reading. We can point to numerous examples in Commons of files that have been edited to demonstrate this. The licensing clause does not specify the degree of technical sophistication required.
2008/11/3 Erik Moeller erik@wikimedia.org:
2008/11/3 geni geniice@gmail.com:
Massive Multiauthor Collaboration Site" (or "MMC Site") means any World Wide Web server that publishes copyrightable works and also provides prominent facilities for anybody to edit those works.
We do not provide provides prominent facilitiesm to edit images.
We have version history and re-uploading, which IMO qualifies even by a literal reading. We can point to numerous examples in Commons of files that have been edited to demonstrate this. The licensing clause does not specify the degree of technical sophistication required.
"facilities for anybody to edit those works"
That means providing facilities on wiki to allow actual editing. Not provideing facilities to support off wiki editing.
2008/11/3 geni geniice@gmail.com:
"facilities for anybody to edit those works"
That means providing facilities on wiki to allow actual editing. Not provideing facilities to support off wiki editing.
Any kind of editing is dependent on client side support, and the extent of server-side support required to qualify is not further specified. You need a web browser to edit a Wikipedia article; WP by itself doesn't serve you any of the code required to do so, it merely implements an interface through which that is possible. So it does for images. The fact that the level of client-side in-browser support for image editing is currently lower than the level of client-side in-browser support for text editing does not negate the terms of the license. The important part is that we allow anyone to register an account and modify existing images through prominent facilities in the site.
2008/11/3 Erik Moeller erik@wikimedia.org:
2008/11/3 geni geniice@gmail.com:
"facilities for anybody to edit those works"
That means providing facilities on wiki to allow actual editing. Not provideing facilities to support off wiki editing.
Any kind of editing is dependent on client side support, and the extent of server-side support required to qualify is not further specified.
No but wiki standard is accepted and our images do not come close to meeting that standard.
You need a web browser to edit a Wikipedia article; WP by itself doesn't serve you any of the code required to do so, it merely implements an interface through which that is possible. So it does for images. The fact that the level of client-side in-browser support for image editing is currently lower than the level of client-side in-browser support for text editing does not negate the terms of the license.
You've just tried to argue that photobucket say qualifies as a Massive Multiauthor Collaboration Site. Indeed any site that allows anyone to upload images would meet your requirements. In fact if we extend your reasoning to text the likes of scribd (there are free software manuals on there) and knol qualify. There is reading a license broadly but you appear to have gone beyond that.
The important part is that we allow anyone to register an account
And wait several days. Uploads of commons have a waiting period.
and modify existing images through prominent facilities in the site.
There are no facilities on wikipedia for editing images. There is no reasonable way for a browser to interact with mediawiki to provide image editing facilities (apart from anything else anything you did build would be broken by the various interface changes commons tends to go through).
2008/11/3 geni geniice@gmail.com:
There are no facilities on wikipedia for editing images.
An open interface with low registration requirements, open write access and version history is sufficient, in my opinion. Furthermore, we also have the External Editors interface and have had it for quite some time: http://www.mediawiki.org/wiki/Manual:External_editors
This goes far beyond what sites like Photobucket typically offer.
2008/11/3 Erik Moeller erik@wikimedia.org:
2008/11/3 geni geniice@gmail.com:
There are no facilities on wikipedia for editing images.
An open interface with low registration requirements, open write access and version history is sufficient, in my opinion. Furthermore, we also have the External Editors interface and have had it for quite some time: http://www.mediawiki.org/wiki/Manual:External_editors
This goes far beyond what sites like Photobucket typically offer.
Okey lets consider photobucket as an MMC. It allows anyone to register (and then nags you if you don't use the thing but eh). It allows you to take any image download it, edit it and (because they largely ignore copyright issues) re-upload it. And the ability to do all of this is at least as prominent as wikipedia. You therefor accept photobucket as an MMC.
2008/11/3 geni geniice@gmail.com:
Okey lets consider photobucket as an MMC. It allows anyone to register (and then nags you if you don't use the thing but eh). It allows you to take any image download it, edit it and (because they largely ignore copyright issues) re-upload it. And the ability to do all of this is at least as prominent as wikipedia. You therefor accept photobucket as an MMC.
I don't really care about whether PhotoBucket qualifies as an MMC, and I won't investigate their site interfaces to decide that question. IMO Wikimedia wikis, especially with the external editor interface, certainly do.
2008/11/3 geni geniice@gmail.com:
Okey lets consider photobucket as an MMC. It allows anyone to register (and then nags you if you don't use the thing but eh). It allows you to take any image download it, edit it and (because they largely ignore copyright issues) re-upload it. And the ability to do all of this is at least as prominent as wikipedia. You therefor accept photobucket as an MMC.
And if they mandated GFDL licensing for all their collection of images, this might be relevant.
But let's go back to the original point. Even in the event we decide the collective set of Wikimedia wikis is not an MMC in the context of uploaded material, where does it leave us?
a) They're still undeniably a MMC for text b) So we can relicense, etc, our text c) We just end up with some GFDL-only images d) ...which we'd have had anyway, because of ones licensed under a specific vesion.
It just makes dealing with the GFDL images marginally more of a headache.
2008/11/3 geni geniice@gmail.com:
2008/11/3 Erik Moeller erik@wikimedia.org:
2008/11/3 geni geniice@gmail.com:
"facilities for anybody to edit those works"
geni, I look forward to you bringing a copyright suit for this horrible violation of your works, rather than being pointlessly querulous on a mailing list. You know, something with substance to it rather than noise.
- d.
2008/11/3 David Gerard dgerard@gmail.com:
2008/11/3 geni geniice@gmail.com:
2008/11/3 Erik Moeller erik@wikimedia.org:
2008/11/3 geni geniice@gmail.com:
"facilities for anybody to edit those works"
geni, I look forward to you bringing a copyright suit for this horrible violation of your works, rather than being pointlessly querulous on a mailing list. You know, something with substance to it rather than noise.
It is not acceptable to go down the no one is going to sue us route on this scale.
Yes it's true that the odds of this ending up in court are basically zilch. But by that standard we could use most crown copyright images..
Eric's attempt kinda gets around the problem (although I find this highly questionable) but only at the cost of trashing the spirit of the license.
What is kinda annoying is I suspect it could have been avoided. Does anyone have any examples of free software manuals that don't have no cover texts or invariant sections?
2008/11/3 geni geniice@gmail.com:
Eric's attempt kinda gets around the problem (although I find this highly questionable) but only at the cost of trashing the spirit of the license.
Only in the sense that the "spirit" of the GFDL is "this pretends to be a free licence but we assure you, it's all but unusable in practice," which appears to be a feature to some people. (Which strikes me as severely out of step with the Wikimedia mission, but anyway.)
- d.
2008/11/3 David Gerard dgerard@gmail.com:
2008/11/3 geni geniice@gmail.com:
Eric's attempt kinda gets around the problem (although I find this highly questionable) but only at the cost of trashing the spirit of the license.
Only in the sense that the "spirit" of the GFDL is "this pretends to be a free licence but we assure you, it's all but unusable in practice," which appears to be a feature to some people. (Which strikes me as severely out of step with the Wikimedia mission, but anyway.)
- d.
Not what I meant. In this case the spirt is to prevent GFDL manuals being relicensed. Eric's interpretation would allow for sites like scribd (which does have GFDL licensed manuals on it) to be considered MMCs.
Fortunately all the manuals I've found so far have had cover texts and/or invariant sections. I don't know if it applies to all of them however. If it does the FSF can safely clarify the situation. If it does not Eric's interpretation is potential problem.
Again there is also the issue of how much damage this would case. It would be significant yes but we have been pushing dual and CC licensing for years and I think we got a pretty good response rate on the no disclaimers relicensing thing. Not impossible that we could attempt that again.
2008/11/3 geni geniice@gmail.com:
Not what I meant. In this case the spirt is to prevent GFDL manuals being relicensed. Eric's interpretation would allow for sites like scribd (which does have GFDL licensed manuals on it) to be considered MMCs.
[ ] Site allows anyone to overwrite an existing document [ ] Site keeps a version history of all changes [ ] Site offers a specialized interface to allow making changes through specialized applications
Check all which apply. Yes, Commons has some conditions attached, but except for permanently protected pages, the "anyone can edit" principle still holds true.
2008/11/4 Erik Moeller erik@wikimedia.org:
2008/11/3 geni geniice@gmail.com:
Not what I meant. In this case the spirt is to prevent GFDL manuals being relicensed. Eric's interpretation would allow for sites like scribd (which does have GFDL licensed manuals on it) to be considered MMCs.
[ ] Site allows anyone to overwrite an existing document [ ] Site keeps a version history of all changes
You are arguing that this counts as prominent facilities for anybody to edit those works? How does this differ from a site that allows edited versions to be uploaded under new names by anyone but no overwrites?
2008/11/3 geni geniice@gmail.com:
You are arguing that this counts as prominent facilities for anybody to edit those works?
I'm arguing that the combination of all three of them certainly does. "Editing" is open to interpretation, but a common interpretation would be: There is a mechanism by which you can make a change, and that change is reflected in the version displayed when accessing the object through its unique identifier (URL).
For Commons the biggest question is probably what to do with GFDL 1.2-only. The GFDL 1.3 is basically tracked to take things over to CC-BY-SA (arguments about editing facilities aside).
However, this comes before there has been resolution of the strong vs. weak copyleft problem. The GFDL (as often advocated) is a strong copyleft such that mixing GFDL images into a text document implies a GFDL licensing requirement on the result, including the text. The CC-BY-SA is usually seen as a weak copyleft, such that the viral provisions extend to new images only and not to accompanying text.
This difference, which frankly isn't very clear in either license text but comes out of the license authors' apparent intent, raises the question of whether GFDL is adequately equivalent to CC-BY-SA in its treatment of image. Personally, I would have liked to have seen the talked about "strong" version of -SA materialize before confronted with the migration question.
In the foundation-l thread, Erik suggests that GFDL 1.2-only images should continue to be accepted until this issue is resolved, even though that inevitably adds complexity down the line.
-Robert Rohde
On Mon, Nov 3, 2008 at 12:51 PM, Eugene Zelenko eugene.zelenko@gmail.com wrote:
Hi!
GFDL 1.3 was released today (http://www.fsf.org/news/fdl-1.3-pr.html). Any thought which version should be default, multiple versions, etc?
Eugene.
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
On Tue, Nov 4, 2008 at 12:00 AM, Robert Rohde rarohde@gmail.com wrote:
For Commons the biggest question is probably what to do with GFDL 1.2-only. The GFDL 1.3 is basically tracked to take things over to CC-BY-SA (arguments about editing facilities aside).
That's not a big question. We accept them and continue to accept them. Is there any reasonable alternative?
Furthermore there are certain jurisdictions where the "...or later" clause may not be valid (German maybe?). There is nothing else we can do but keep those images as GFDL 1.2.
Bryan