Hi,
At first let me point out that I appreciate the hard work of people that want to improve our projects. Please let us acknowledge the work of Erik, even if you think like me that his proposal is _definitely_ not the way to go. It's all about AGF. ;-) So please let us brainstorm how to turn this into a good opportunity for all of us without sacrificing parts of our goals and independence.
Two different things were not made clear in Eriks proposal and consequently were mixed in follow up mails: a) Allowed media formats for _uploading_ files. b) Provided media formats for _downloading_ files.
Allowing Flash Video for _upload_ is not acceptable in our projects for the named reasons of patent problems and (at least partly) proprietary software.
Providing Flash Video additionally for _download_ does not conflict with the GFDL or whatever (as you provide along side this copy as well a free format copy of the same content). This is as well the reason why e.g. providing TomeRaider _downloads_ of Wikipedia is in agreement with our understanding of digital freedom.
As pointed out by various people providing Flash Video for download means transcoding. As all relevant video formats are lossy you cannot transcode Ogg-Theora to let's say Mpeg (or any other particular codec used by Flash Video) without quality loss.
So Flash Video is a nice to have _second class_ alternative - a mere convenience for our users. But who wants to get the best quality will always use the original OGG-Theora files.
Philosophy aside here an analysis of current technical problems:
1. Wikimedia Commons badly needs a download service for the whole media file repository. 2. The media repository of Comons is so overwhelmingly large that it would need a lot of bandwith and download time even with broad band internet access. 3. Audio and Video streaming requires a lot of bandwith but it doesn't require sophisticated CPU intensive database queries and special designed software (aka MediaWiki). 4. Many organisations especially universities (I could name you at least one concrete example) want to support us with technical infrastructure but it is very complicated to integrate these kind donations into our technical infrastructure. Thus we are wasting a lot of donation potential beside money.
Proposed solution:
1. We provide an Rsync download of our media files for selected third party mirror servers. Rsync is specifically designed for such a purpose and is exeptionally bandwith saving on mirroring files where parts are constantly changing. 2. These selected third party mirrors are collected in a Round-Robin-Queue. Everytime a user directly wants to download the original file (and not a thumbnail, preview or the image page in the wiki) in Wikipedia (or another Wikimedia project) he is being redirected to this very file on a mirror out of this queue and downloads it there as usual via HTTP (just the download link changes, he even won't realise in most cases that he has been redirected for this download). 3. In case mirrors don't want to host the whole database we could provide them some filters for mirroring, e.g. Ogg files only. Ogg mirroring would make the most benefit for our infrastructure and audio/video streaming, as full images are downloaded relatively seldom.
This would make all these things possible: * Download of Wikimedia Commons media database via mirrors. * Saves us quite some bandwith especially at audio and video (you need to download the real file for streaming). * Easy drop in and drop out of single third party supporters. * Not dependent from one exclusive partner. We maintain our independence and increase technical failure resitance by reducing the single point of failure problem.
In case you fear the problem of license issues (providing the copyright infos alongside the files) this can be solved without troubles, too. There is static.wikipedia.org Just transfer the static html image wiki pages of Commons as well to the single mirrors and we're perfectly done (and third party mirrors can create their own software interface around that thing if they want).
Cheers, Arnomane
Hoi, I have the idea that you are making projecting issues of the GPL on the GFDL. The GPL insists that you have to provide source code. As far as I can see, the GFDL does not. This is reasonable because a book can be published on paper under the GFDL. It is not necessary to provide a digital version as well. Thanks, GerardM
On 7/23/07, Daniel Arnold arnomane@gmx.de wrote:
Hi,
At first let me point out that I appreciate the hard work of people that want to improve our projects. Please let us acknowledge the work of Erik, even if you think like me that his proposal is _definitely_ not the way to go. It's all about AGF. ;-) So please let us brainstorm how to turn this into a good opportunity for all of us without sacrificing parts of our goals and independence.
Two different things were not made clear in Eriks proposal and consequently were mixed in follow up mails: a) Allowed media formats for _uploading_ files. b) Provided media formats for _downloading_ files.
Allowing Flash Video for _upload_ is not acceptable in our projects for the named reasons of patent problems and (at least partly) proprietary software.
Providing Flash Video additionally for _download_ does not conflict with the GFDL or whatever (as you provide along side this copy as well a free format copy of the same content). This is as well the reason why e.g. providing TomeRaider _downloads_ of Wikipedia is in agreement with our understanding of digital freedom.
As pointed out by various people providing Flash Video for download means transcoding. As all relevant video formats are lossy you cannot transcode Ogg-Theora to let's say Mpeg (or any other particular codec used by Flash Video) without quality loss.
So Flash Video is a nice to have _second class_ alternative - a mere convenience for our users. But who wants to get the best quality will always use the original OGG-Theora files.
Philosophy aside here an analysis of current technical problems:
- Wikimedia Commons badly needs a download service for the whole media
file repository. 2. The media repository of Comons is so overwhelmingly large that it would need a lot of bandwith and download time even with broad band internet access. 3. Audio and Video streaming requires a lot of bandwith but it doesn't require sophisticated CPU intensive database queries and special designed software (aka MediaWiki). 4. Many organisations especially universities (I could name you at least one concrete example) want to support us with technical infrastructure but it is very complicated to integrate these kind donations into our technical infrastructure. Thus we are wasting a lot of donation potential beside money.
Proposed solution:
- We provide an Rsync download of our media files for selected third
party mirror servers. Rsync is specifically designed for such a purpose and is exeptionally bandwith saving on mirroring files where parts are constantly changing. 2. These selected third party mirrors are collected in a Round-Robin-Queue. Everytime a user directly wants to download the original file (and not a thumbnail, preview or the image page in the wiki) in Wikipedia (or another Wikimedia project) he is being redirected to this very file on a mirror out of this queue and downloads it there as usual via HTTP (just the download link changes, he even won't realise in most cases that he has been redirected for this download). 3. In case mirrors don't want to host the whole database we could provide them some filters for mirroring, e.g. Ogg files only. Ogg mirroring would make the most benefit for our infrastructure and audio/video streaming, as full images are downloaded relatively seldom.
This would make all these things possible:
- Download of Wikimedia Commons media database via mirrors.
- Saves us quite some bandwith especially at audio and video (you need to
download the real file for streaming).
- Easy drop in and drop out of single third party supporters.
- Not dependent from one exclusive partner. We maintain our independence
and increase technical failure resitance by reducing the single point of failure problem.
In case you fear the problem of license issues (providing the copyright infos alongside the files) this can be solved without troubles, too. There is static.wikipedia.org Just transfer the static html image wiki pages of Commons as well to the single mirrors and we're perfectly done (and third party mirrors can create their own software interface around that thing if they want).
Cheers, Arnomane
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 7/23/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, I have the idea that you are making projecting issues of the GPL on the GFDL. The GPL insists that you have to provide source code. As far as I can see, the GFDL does not.
The GFDL requires you to distribute transparent copies if you distribute more than 100 copies. "If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material."
<blockquote>A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters.</blockquote>
Basically that is the document equivalent of "source code".
This is reasonable because a book can be published on paper under the GFDL. It is not necessary to provide a digital version as well.
If you distribute more than 100 copies, it is.
On Monday 23 July 2007 13:58:03 Anthony wrote:
This is reasonable because a book can be published on paper under the GFDL. It is not necessary to provide a digital version as well.
If you distribute more than 100 copies, it is.
Yes I know. I did deliberately not answer to GerardM's GFDL-comment to my alternative proposal for video streaming.
So my topic was not "let us teach each other the GFDL" but something completely different, which I'd like to discuss instead seriously.
Cheers, Arnomane
Does anyone know where I can download a tarball of all commons images?
On 7/23/07, Daniel Arnold arnomane@gmx.de wrote:
On Monday 23 July 2007 13:58:03 Anthony wrote:
This is reasonable because a book can be published on paper under the GFDL. It is not necessary to provide a digital version as well.
If you distribute more than 100 copies, it is.
Yes I know. I did deliberately not answer to GerardM's GFDL-comment to my alternative proposal for video streaming.
So my topic was not "let us teach each other the GFDL" but something completely different, which I'd like to discuss instead seriously.
Cheers, Arnomane
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
On Monday 23 July 2007 14:19:21 Anthony wrote:
Does anyone know where I can download a tarball of all commons images?
There is none as already pointed out in my initial mail of this thread. See this mail for reasons why there is no file tarball available yet.
The only file "tarball" (in fact zenoreader format) you can get are very few selected images of the de.wikipedia (just: 2.9 GB, a tiny fraction compared to the full media repository), see http://dvd.wikimedia.org/
This tarball download problem was exactly one reason for writing my alternative proposal here and is clearly adressed there...
Cheers, Arnomane
On 7/23/07, Daniel Arnold arnomane@gmx.de wrote:
On Monday 23 July 2007 14:19:21 Anthony wrote:
Does anyone know where I can download a tarball of all commons images?
There is none as already pointed out in my initial mail of this thread. See this mail for reasons why there is no file tarball available yet.
Well, you suggest that cost of bandwidth is the reason, but that contradicts what the developers have been consistently saying - that there is no bandwidth problem.
The only file "tarball" (in fact zenoreader format) you can get are very few selected images of the de.wikipedia (just: 2.9 GB, a tiny fraction compared to the full media repository), see http://dvd.wikimedia.org/
This tarball download problem was exactly one reason for writing my alternative proposal here and is clearly adressed there...
Yes, you present one solution to a problem which the foundation says it doesn't have. There are lots of other solutions too, once we get past the step of identifying exactly why there is no tarball for all commons images. Who would be a good central point of contact at the WMF for answering this?
Anthony
On Monday 23 July 2007 15:48:24 Anthony wrote:
Well, you suggest that cost of bandwidth is the reason, but that contradicts what the developers have been consistently saying - that there is no bandwidth problem.
Well according to my rough estimate the Wikimedia media repository has a size of 500 GB.
Now assume one can download that with his new 10Mbit/s at home DSL line at full speed: You'd need almost 5 days until the download is complete (and although you might have a flatrate, I am pretty sure your ISP will have some fair flat policy and makes some troubles sooner or later).
Now let us assume a somewhat more likely download rate of 200kB/s (you know concurrent downloaders and other things). You'd need 30 days for a complete download.
You're mixing seveal things: Wikimedia has no bandwith problem for its _current_ operation but you shouldn't forget that bandwith alone is only the half trouth. There is transfer size as well and transfer size costs money right now. Money from many many donators. If we reject a material donation that reduces our transfer costs and thus makes better use of our money donations we'd be pretty stupid and furthermore we'd waste donated money for no good reason.
So if we're going to provide video and audio streaming on a large scale we will have greatly increased transfer costs.
Yes, you present one solution to a problem which the foundation says it doesn't have.
Sorry but you mix up several things. See above. If the Foundation wouldn't have a problem with media file database downloads and large scale video streaming you'd implicitely assume that they are lazy people that just don't want to provide the media repository for some evil reasons...
There are lots of other solutions too, once we get past the step of identifying exactly why there is no tarball for all commons images.
Sorry to be so unfriendly but you simply have no clue. HTTP and FTP simply weren't designed for downloading moving targets in the size of 500 GB! Rsync is not just a random geek software none else uses. Rsync exists for a very good reason: Use cases like our, namely sncronisation of huge amounts of constantly changing data between a master and a mirror slave.
My suggested solution (I can only recomend reading the initial post again) is an approach to solve both the streaming issue and the media download without even requiring usual Wikipedia readers to use "new" software like Rsync.
Who would be a good central point of contact at the WMF for answering this?
These people are reading here (most times carefully ;-).
Arnomane
On 7/23/07, Daniel Arnold arnomane@gmx.de wrote:
Sorry to be so unfriendly but you simply have no clue.
My fault. Feel free to ignore everything I've said in this thread, Daniel.
Hoi, http://en.wikipedia.org/wiki/GFDL#Transparent_formats for a summary of the problems with opaque as terminology used. Thanks, GerardM
On 7/23/07, Anthony wikimail@inbox.org wrote:
On 7/23/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, I have the idea that you are making projecting issues of the GPL on the GFDL. The GPL insists that you have to provide source code. As far as I
can
see, the GFDL does not.
The GFDL requires you to distribute transparent copies if you distribute more than 100 copies. "If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material."
<blockquote>A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters.</blockquote>
Basically that is the document equivalent of "source code".
This is reasonable because a book can be published on paper under the GFDL. It is not necessary to provide a digital
version as
well.
If you distribute more than 100 copies, it is.
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 7/23/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, http://en.wikipedia.org/wiki/GFDL#Transparent_formats for a summary of the problems with opaque as terminology used. Thanks, GerardM
There are differing interpretations of what a transparent format is (most of which are pretty obviously incorrect), but distributing more than 100 copies on paper without providing any digital copy at all pretty clearly violates the requirement to have a machine readable copy.
It's also pretty clear that the license intends that copies encoded in proprietary patented formats to be considered opaque copies, even if some lawyer might be able to successfully argue otherwise.
On 7/23/07, Anthony wikimail@inbox.org wrote:
On 7/23/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, I have the idea that you are making projecting issues of the GPL on the GFDL. The GPL insists that you have to provide source code. As far as I
can
see, the GFDL does not.
The GFDL requires you to distribute transparent copies if you distribute more than 100 copies. "If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material."
<blockquote>A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters.</blockquote>
Basically that is the document equivalent of "source code".
This is reasonable because a book can be published on paper under the GFDL. It is not necessary to provide a digital
version as
well.
If you distribute more than 100 copies, it is.
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
Hoi, It is not that obvious at all. When software needed to make use of data is available without any kind of discrimination, it should suffice. At some stage I created an 80 Mb database in Microsoft Access. Would you deny that I could make this data available under the GFDL ?? I gave it to people, who also had Access, and they were happy to have it. Now when you can convince me that I did not have the right to make it available to them under the GFDL, I will inform them about this and you can explain to them why they are not entitled to use my data and/or you can explain to me why they can do whatever they like with my data because they are not validly restricted by a license.
My intention in this was clear, I wanted these people to have it and I wanted to make sure that it stayed available under the conditions as I understood them. This meant do what you like, but you cannot sell it to someone else. If GFDL data can only be used with Free Software, if it is not permitted to change the format of the data and extend it when this makes sense for a particular application, it would mean to me that the argument that the Wikimedia Foundation happened at the wrong time because a liberal license was not available has gained weight.
Thanks, GerardM
On 7/23/07, Anthony wikimail@inbox.org wrote:
On 7/23/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, http://en.wikipedia.org/wiki/GFDL#Transparent_formats for a summary of
the
problems with opaque as terminology used. Thanks, GerardM
There are differing interpretations of what a transparent format is (most of which are pretty obviously incorrect), but distributing more than 100 copies on paper without providing any digital copy at all pretty clearly violates the requirement to have a machine readable copy.
It's also pretty clear that the license intends that copies encoded in proprietary patented formats to be considered opaque copies, even if some lawyer might be able to successfully argue otherwise.
On 7/23/07, Anthony wikimail@inbox.org wrote:
On 7/23/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, I have the idea that you are making projecting issues of the GPL on
the
GFDL. The GPL insists that you have to provide source code. As far
as I
can
see, the GFDL does not.
The GFDL requires you to distribute transparent copies if you distribute more than 100 copies. "If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material."
<blockquote>A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters.</blockquote>
Basically that is the document equivalent of "source code".
This is reasonable because a book can be published on paper under the GFDL. It is not necessary to provide a digital
version as
well.
If you distribute more than 100 copies, it is.
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 7/23/07, GerardM gerard.meijssen@gmail.com wrote:
Now when you can convince me that I did not have the right to make it available to them under the GFDL,
You would be in the clear. However if they wished to redistribute it they would be required to produce a transparent version.
On 7/23/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, It is not that obvious at all. When software needed to make use of data is available without any kind of discrimination, it should suffice. At some stage I created an 80 Mb database in Microsoft Access. Would you deny that I could make this data available under the GFDL ??
Well, you can make any data you want available under the GFDL, as you own the copyright on it (if it's copyrightable data, anyway). But the intention of the GFDL is that proprietary formats are opaque. I'd say this is obvious, as the GFDL specifically says that "Opaque formats include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only." Now some lawyer-minded folk might jump on the "proprietary word processors" part and note that they didn't say anything about "proprietary video editing software". But this sentence alone makes it crystal clear that the *intent* of the GFDL is that proprietary patented formats are not opaque formats.
I gave it to people, who also had Access, and they were happy to have it. Now when you can convince me that I did not have the right to make it available to them under the GFDL, I will inform them about this and you can explain to them why they are not entitled to use my data and/or you can explain to me why they can do whatever they like with my data because they are not validly restricted by a license.
My intention in this was clear, I wanted these people to have it and I wanted to make sure that it stayed available under the conditions as I understood them. This meant do what you like, but you cannot sell it to someone else.
I think your intention goes a long way in this situation. The fact that the original copy is itself not in a transparent format probably goes a long way too. To make things perfectly clear, you could always formally waive section 3 of the GFDL, dealing with transparent formats. Otherwise, if the people who received your data distribute more than 100 copies of it, they'd be in a legal grey-area.
If GFDL data can only be used with Free Software, if it is not permitted to change the format of the data and extend it when this makes sense for a particular application, it would mean to me that the argument that the Wikimedia Foundation happened at the wrong time because a liberal license was not available has gained weight.
The GFDL isn't a good choice for videos anyway.
Anthony
GerardM wrote:
Hoi, It is not that obvious at all. When software needed to make use of data is available without any kind of discrimination, it should suffice. At some stage I created an 80 Mb database in Microsoft Access. Would you deny that I could make this data available under the GFDL ?? I gave it to people, who also had Access, and they were happy to have it. Now when you can convince me that I did not have the right to make it available to them under the GFDL, I will inform them about this and you can explain to them why they are not entitled to use my data and/or you can explain to me why they can do whatever they like with my data because they are not validly restricted by a license.
My intention in this was clear, I wanted these people to have it and I wanted to make sure that it stayed available under the conditions as I understood them. This meant do what you like, but you cannot sell it to someone else. If GFDL data can only be used with Free Software, if it is not permitted to change the format of the data and extend it when this makes sense for a particular application, it would mean to me that the argument that the Wikimedia Foundation happened at the wrong time because a liberal license was not available has gained weight.
Thanks, GerardM
On 7/23/07, Anthony wikimail@inbox.org wrote:
On 7/23/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, http://en.wikipedia.org/wiki/GFDL#Transparent_formats for a summary of
the
problems with opaque as terminology used. Thanks, GerardM
There are differing interpretations of what a transparent format is (most of which are pretty obviously incorrect), but distributing more than 100 copies on paper without providing any digital copy at all pretty clearly violates the requirement to have a machine readable copy.
It's also pretty clear that the license intends that copies encoded in proprietary patented formats to be considered opaque copies, even if some lawyer might be able to successfully argue otherwise.
On 7/23/07, Anthony wikimail@inbox.org wrote:
On 7/23/07, GerardM gerard.meijssen@gmail.com wrote:
Hoi, I have the idea that you are making projecting issues of the GPL on
the
GFDL. The GPL insists that you have to provide source code. As far
as I
can
see, the GFDL does not.
The GFDL requires you to distribute transparent copies if you distribute more than 100 copies. "If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material."
<blockquote>A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters.</blockquote>
Basically that is the document equivalent of "source code".
This is reasonable because a book can be published on paper under the GFDL. It is not necessary to provide a digital
version as
well.
If you distribute more than 100 copies, it is.
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
Well, remember, the copyright holder can break the license. If I write GPL software, and distribute a binary copy without source code, that's fine. On the other hand, -you- can't do that, you have to provide binary and source, since you wouldn't be the copyright holder. Same type of thing with the GFDL-as the copyright holder, you can grant anyone you like an exception to your license, including yourself. (I also doubt that you distributed over 100 copies.)
However, there is a clear intent in the GFDL that open specifications must be used. If a format is locked and proprietary, it is not GFDL compliant for widescale distribution, and it's not supposed to be. I don't see that as any sort of onerous restriction, it's part of the requirement that GFDL material be modifiable. I don't have Access. I could borrow a Windows machine, I suppose, but even then I'd have to buy it in order to do what the license says I'm supposed to be inherently allowed to-modify that file. On the other hand, if it's in an open format, I don't have to do that. I can use whatever software has been developed for my OS, or can even look at the spec and develop my own. Now, I have the -real- ability to modify and copy the file, as opposed to the theoretical one. That's why closed == bad, and that's why both GPL and GFDL take steps to prohibit its use on open content.
On 7/23/07, GerardM gerard.meijssen@gmail.com wrote:
My intention in this was clear, I wanted these people to have it and I wanted to make sure that it stayed available under the conditions as I understood them. This meant do what you like, but you cannot sell it to someone else.
This is clearly OT for this thread, but if that is what you wanted, you have both misunderstood the conditions, and chosen the wrong licence, as the GFDL explicitly allows selling content licenced under it (if you can convince somebody to buy something that is also available for free).
-- Jussi-Ville Heiskanen, ~ [[User:Cimon Avaro]]
On 7/24/07, Anthony wikimail@inbox.org wrote:
There are differing interpretations of what a transparent format is (most of which are pretty obviously incorrect), but distributing more than 100 copies on paper without providing any digital copy at all pretty clearly violates the requirement to have a machine readable copy.
You're forgetting about punch cards.
On Tuesday 24 July 2007 12:37:02 Stephen Bain wrote:
On 7/24/07, Anthony wikimail@inbox.org wrote:
There are differing interpretations of what a transparent format is (most of which are pretty obviously incorrect), but distributing more than 100 copies on paper without providing any digital copy at all pretty clearly violates the requirement to have a machine readable copy.
You're forgetting about punch cards.
May I quote again my initial post http://lists.wikimedia.org/pipermail/foundation-l/2007-July/032060.html of this thread? I didn't ask for GFDL-only debates.
"At first let me point out that I appreciate the hard work of people that want to improve our projects. Please let us acknowledge the work of Erik, even if you think like me that his proposal is _definitely_ not the way to go. It's all about AGF. ;-) So please let us brainstorm how to turn this into a good opportunity for all of us without sacrificing parts of our goals and independence. [...]"
Arnomane
On 7/24/07, Daniel Arnold arnomane@gmx.de wrote:
On Tuesday 24 July 2007 12:37:02 Stephen Bain wrote:
On 7/24/07, Anthony wikimail@inbox.org wrote:
There are differing interpretations of what a transparent format is (most of which are pretty obviously incorrect), but distributing more than 100 copies on paper without providing any digital copy at all pretty clearly violates the requirement to have a machine readable copy.
You're forgetting about punch cards.
May I quote again my initial post http://lists.wikimedia.org/pipermail/foundation-l/2007-July/032060.html of this thread? I didn't ask for GFDL-only debates.
"At first let me point out that I appreciate the hard work of people that want to improve our projects. Please let us acknowledge the work of Erik, even if you think like me that his proposal is _definitely_ not the way to go. It's all about AGF. ;-) So please let us brainstorm how to turn this into a good opportunity for all of us without sacrificing parts of our goals and independence. [...]"
we currently try to help setting up a research project co financed by the european union to exactly help improving this situation with bringing p2p technology and wiki technology closer. and we are definitely interested in finding people and companies with good ideas who would be able to participate here.
we applied once, and it seems the proposal was not good enough :) but we ll try again in 9 months or so.
rupert.
On Wednesday 25 July 2007 06:26:53 THURNER rupert wrote:
[...] So please let us brainstorm how to turn this into a good opportunity for all of us without sacrificing parts of our goals and independence. [...]
we currently try to help setting up a research project co financed by the european union to exactly help improving this situation with bringing p2p technology and wiki technology closer.
p2p definitely was a big help in the past when we distributed the Wikipedia DVD images. So p2p has proven to be useful on distributing large files that don't change frequently.
However p2p between clients somehow connected with the wiki itself has the disadvantage that you require a special software and this again is technically problematic like requiring Java or Flash plugins.
Distributing files among mirror servers is usually a network of less than 100 participants. There is usually a defined list of mirrors with known average mirror update delay. Large downloadservers very often use Rsync in order to mirror whole directory trees of other servers. So Rsync is an introduced working technology with a quite intelligent algorithm.
In my approach the user would traditionally get the file via HTTP from the mirror (he even wouldnt realize it if he doesn't look closely on the URL of this file). So there wouldn't be any change on the client side, which is a big advantage.
But maybe I understand you wrong. What exactly do you mean with bringing p2p and wikis closer together?
Arnomane
Hoi, Consider many people who all have copies of Commons files in a P2P cache. Making them available to whoever wants them. This connected to a few backbone servers who have ALL Commons files. Consider that there is some mechanism that ensures that there are at least a given minimum number of copies of every file in the "wild" and that this process is optimised to have the images near to where they are requested most often.. When a picture is added to the P2P it goes to the central repository and it is checked and validated like we do at the moment for copyright etc ...
This kind of setup is similar to what the University of Amsterdam wants to do for Wikipedia content.. Maybe they could consider something along these lines to get their feet wet..
Thanks, GerardM
On 7/25/07, Daniel Arnold arnomane@gmx.de wrote:
On Wednesday 25 July 2007 06:26:53 THURNER rupert wrote:
[...] So please let us brainstorm how to turn this into a good opportunity for all of us without sacrificing parts of our goals and independence. [...]
we currently try to help setting up a research project co financed by
the
european union to exactly help improving this situation with bringing
p2p
technology and wiki technology closer.
p2p definitely was a big help in the past when we distributed the Wikipedia DVD images. So p2p has proven to be useful on distributing large files that don't change frequently.
However p2p between clients somehow connected with the wiki itself has the disadvantage that you require a special software and this again is technically problematic like requiring Java or Flash plugins.
Distributing files among mirror servers is usually a network of less than 100 participants. There is usually a defined list of mirrors with known average mirror update delay. Large downloadservers very often use Rsync in order to mirror whole directory trees of other servers. So Rsync is an introduced working technology with a quite intelligent algorithm.
In my approach the user would traditionally get the file via HTTP from the mirror (he even wouldnt realize it if he doesn't look closely on the URL of this file). So there wouldn't be any change on the client side, which is a big advantage.
But maybe I understand you wrong. What exactly do you mean with bringing p2p and wikis closer together?
Arnomane
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
GerardM wrote:
Hoi, I have the idea that you are making projecting issues of the GPL on the GFDL. The GPL insists that you have to provide source code. As far as I can see, the GFDL does not. This is reasonable because a book can be published on paper under the GFDL. It is not necessary to provide a digital version as well. Thanks, GerardM
Re-read the GFDL again. Yes, it does require that you provide the "source code" for whatever you are using. The GFDL terms is "non-opaque format", which means you should have the ability to modify the text. PDF files are considered opaque, so you need to include at least an ASCII version of the text, or with some markup information if you are going that far. MediaWiki software provides this on our wikis, so it isn't something that is necessarily something hard to achieve either.
The GFDL, unlike the GPL, does provide for using a common "network address" to link to this "source code" if you are printing something on physical paper. It also requires that you maintain this link for at least one year after publication of the materials (aka you can't simply put the content up for a couple of days and then take it down again to meet this requirement). If you do distribute on CD-ROM or other media that is a bit more expansive, having editable "source code" on the disc is also appropriate.... indeed preferred.
This ought to apply to all other kinds of media included with our content, including video, audio, and static images. This has been a primary rationale for why certain multi-media formats have been accepted and others discouraged (aka MP3s and Quicktime movies or GIF images for a time). This is a wise and prudent policy, and should not be ignored for the sake of establishing a partnership to help host content.
I'm glad I'm not the only one pointing out this fact about the GFDL. However, going back to the actual issue at hand, it's not at all necessary to use flv exclusively, and in fact that doesn't seem to be something anyone has suggested. Distributing free content in proprietary formats *as an alternative* is perfectly acceptable under the GFDL and any other free content license.
I don't know enough about the technology to have an opinion right now on whether or not it's a good idea to offer flv as an alternative. But as long as the primary editable version of the file is in a free format I don't think it's a huge issue to also offer a version in flv or some other proprietary format.
Daniel also makes an excellent point that the formats being considered are lossy, and that therefore we should ensure that the proprietary format version is the second generation and the free format is the first generation. In fact, I wonder the feasibility of having the preferred version for editing being a lossless format. But I don't know a whole lot about the technology there, either.
On 7/23/07, Robert Horning robert_horning@netzero.net wrote:
GerardM wrote:
Hoi, I have the idea that you are making projecting issues of the GPL on the GFDL. The GPL insists that you have to provide source code. As far as I can see, the GFDL does not. This is reasonable because a book can be published on paper under the GFDL. It is not necessary to provide a digital version as well. Thanks, GerardM
Re-read the GFDL again. Yes, it does require that you provide the "source code" for whatever you are using. The GFDL terms is "non-opaque format", which means you should have the ability to modify the text. PDF files are considered opaque, so you need to include at least an ASCII version of the text, or with some markup information if you are going that far. MediaWiki software provides this on our wikis, so it isn't something that is necessarily something hard to achieve either.
The GFDL, unlike the GPL, does provide for using a common "network address" to link to this "source code" if you are printing something on physical paper. It also requires that you maintain this link for at least one year after publication of the materials (aka you can't simply put the content up for a couple of days and then take it down again to meet this requirement). If you do distribute on CD-ROM or other media that is a bit more expansive, having editable "source code" on the disc is also appropriate.... indeed preferred.
This ought to apply to all other kinds of media included with our content, including video, audio, and static images. This has been a primary rationale for why certain multi-media formats have been accepted and others discouraged (aka MP3s and Quicktime movies or GIF images for a time). This is a wise and prudent policy, and should not be ignored for the sake of establishing a partnership to help host content.
foundation-l mailing list foundation-l@lists.wikimedia.org http://lists.wikimedia.org/mailman/listinfo/foundation-l
wikimedia-l@lists.wikimedia.org