Talk:Wikimedia Draft Statement of Principles Regarding Software Use

Fonts

This policy means that we cannot support many languages because there is for many languages no free font available. I am therefore against this policy as it is proposed. The WMF could involve itself in making Free fonts available for all applicable languages. This would remove my objection. GerardM 08:54, 3 September 2007 (UTC)

1. This document merely lists out our existing policy, with no change that I can see.
2. Indeed, anyone interested in such issues should work to ensure there are free fonts for those languages.
3. Recommend you work with existing free font projects such as:
   • http://www.nongnu.org/freefont/
   • http://www.nongnu.org/freebangfont/

   --brion 17:19, 3 September 2007 (UTC)

Should/Must

(First of all: I like the idea of this statement of basic/fundamental principles/policy in regard to software). I think that the wording throughout should be strict: "MUST" and "MUST NOT" (The "RFC-style terms") instead of "should" and "should not". I see that Eloquence have edited the draft into the exact opposite of this, and I don't understand why: that Wikipedia should be available to everyone without requiring any, what-so-ever, proprietary software is not a "should", it is a "absolute, non-negotiable MUST'" - IMHO, of course. One cannot let Wikipedia become some proprietary goldmine for one particular company - ever. Stolsvik 19:34, 4 September 2007 (UTC)

How about "shall" as a compromise? :-) My concern is only that Wikimedians could be inclined to get into rules-lawyering in very, very specific instances, in which I'd like to leave our techies with the freedom to say: Sorry, this is not a priority right now. Not that they care what the Board says anyway. ;-) --Eloquence 23:58, 4 September 2007 (UTC)

I don't think there's much of a difference in regard to laws, really - "shall" is just more obscure. I understand your point of view, though. Luckily the history of the proceedings for the law is readily available due to MediaWiki's history and the mail-log, so the interpretation can be guided by the law's fathers' intentions when these things end up in court! :) Dictionary.com: shall "3. (in laws, directives, etc.) must; is or are obliged to: The meetings of the council shall be public.", must. Wictionary: shall, must. Stolsvik 08:34, 5 September 2007 (UTC) .. Also definitions from IETF. Stolsvik 18:55, 5 September 2007 (UTC)

Drop the vague "especially"

" .. especially when there is a history of enforcement of said patents." and ".. especially the technical team." just sounds vague and pointless: of course this regards the technical team the most, but that is not a point in this policy. And one MUST NOT USE software with patents: The "especially when there is a history..." is simply dangerous - witness GIF with the LZW: the patent holders stated that they would never go for patent enforcement - and then, three years or so before it expired, they forced all encoder-suppliers (Adobe et.al) to pay up lots. If one at some point realize that "oops, we've apparently come to use software with patents" then this policy MUST dictate that one should as soon as possible get away from the patent infringement, for example by converting to another format or whatever would be the remedy. One cannot let Wikipedia become some proprietary goldmine for one particular company - ever. Stolsvik 19:34, 4 September 2007 (UTC)

If we followed that strictly, we'd probably just have to shut down everything permanently. There's a lot of patents of dubious validity out there.

In the real world, legal risk is a matter of give and take; you have to look at what's actually reasonable and realistic. --brion 13:04, 5 September 2007 (UTC)

The sentence in the content about patents used the term "should" before you rolled back my suggestions. This does thus not not imply a strict requirement. However, I think the other points should use MUST and MUST NOT. But please read the terms as defined by IETF if you are not familiar with them. I quote: "SHOULD - This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course." Regarding the "especially" "tack-ons": they are merely making the statement more vague and are devoid of value. Stolsvik 18:53, 5 September 2007 (UTC)

Reason

Hi. Maybe we should say why we want this policy. Our vision is "a world in which every single human being can freely share in the sum of all knowledge." Proprietary software, direct dependencies & closed formats discriminate people who want to access the information, and as such they must be avoided. guillom 08:56, 3 September 2007 (UTC)

I agree. It could use a preamble. pfctdayelise 10:58, 3 September 2007 (UTC)

That, and it's been our policy for years already. :) --brion 17:03, 3 September 2007 (UTC)

"Proprietary software, direct dependencies & closed formats discriminate people who want to access the information, and as such they must be avoided. guillom 08:56, 3 September 2007 (UTC)" - That view point is a little myopic in my opinion. If proprietary software can be obtained at little or no cost and has a great benefit to the end goal of knowledge dissemination then, if you ask me, it would be irresponsible not to include that technology. There's already been several examples outlined that show how Wikipedia couldn't have made it to the point we are at today without the use of proprietary/patented software. Drafting policies that ban proprietary software seems like a very hard right-wing approach towards defining Wikimedia's technological future. --Mirz 22:17, 26 September 2007 (UTC)

GIF

What will happen regarding GIF's? Currently, if my memory serves me, this is the only format we use (except PDF) that is either proprietary or patent encumbered. As of yet there is no viable solution to distribute basic animations without using the GIF format or wasting a huge amount of resources by converting it to an OGG Vorbis(Theora?). Animated PNGs' still aren't mainstream enough yet, nor are animated SVGs' (which aren't a successful substitute anyway). MinuteElectron 09:28, 3 September 2007 (UTC)

The relevant GIF patents expired a couple years ago, it's no longer an issue. --brion 17:15, 3 September 2007 (UTC)

No to proprietary software

• If there is free software, that is functional and performance equivalent to proprietary, there is no use of proprietary software.
• If there is free software, that is not functional enough, then mirror and forking and free knowledge sharing is not possible anymore, and here again, no use of proprietary software.
• If there is free software that is not fast enough, by choosing proprietary software again we'd have forking restrictions, and we would be seen as not endorsing freedom. Moreover, our stand is to help improve the open-source/free software stacks to be able to serve the loads of Wikipedia/WMF.

Midom 10:29, 3 September 2007 (UTC)

Just adding - this policy doesn't have anything new. We always used fully open-source stack at server-side. Midom 11:17, 3 September 2007 (UTC)

"the user's system"

Does this mean any time an operating system or browser is introduced that doesn't have support for X, Wikimedia has failed to uphold its software policy? That doesn't sound quite right. How does MediaWiki go in Lynx? How about Palm OS? etc. --pfctdayelise 10:57, 3 September 2007 (UTC)

The point is not for our site to work equally on every possible web client, but to ensure that a fully-functional web client does not require proprietary (un-shareable) software. That is, to get the fully-functional experience you are not forced to buy into some particular hardware or software platform.

An example is that you are not required to purchase Windows and Internet Explorer; you can still get the full functionality of the system on a completely free system such as Linux and Firefox (or FreeBSD and Konqueror, or...).

This does not mean that every random bit of software will work.

Additionally we do strive to be as functional as possible on various different available platforms, following web standards and degrading gracefully when functionality is not available due to platform limitations. This is however a somewhat separate issue, as the relevance here is more about what's actually possible to work in, say, a text-only environment or a limited handheld form-factor or a program that doesn't support modern web standards.

For instance MediaWiki works fine in Lynx as of last testing, though of course fancy extras like images and style formatting won't work; if you encounter any problems, please report them at http://bugzilla.wikimedia.org/ Can't speak to PalmOS as we don't have any such machines to test with, but again if you encounter any problems, please report them at http://bugzilla.wikimedia.org/ and we'll see what we can do. --brion 17:11, 3 September 2007 (UTC)

"Full participation", "require"

Is "full participation" just reading + editing using a browser? How about creating multimedia files?

Are you "required" to use something when the libre equivalent exists but is buggy and annoying? Is there any kind of standard for when FLOSS is "good enough"? Or is that dependent on the individual user's tolerance? pfctdayelise 11:01, 3 September 2007 (UTC)

We do not require the use of proprietary software for creating multimedia files. Nor do we forbid it, of course, as long as the end product is shareable using free formats and software. --brion 17:14, 3 September 2007 (UTC)

My answers would be:

1. Full participation does include the creation of multimedia files. Thus, formats that can be shown, but not be created or edited by open source software would not be allowed according to these principles.
2. I would tend to put those standards low. Not everything would be ok (editing a multimedia file by hand in a text editor comes to mind), but the sole fact that the program is not of a very good quality would not be enough, in my opinion.

- Andre Engels 06:59, 5 September 2007 (UTC)

Installation versus Use

In general I like it, but I have some mild misgivings about this point (emphasis added) :

• "Full participation in projects operated by the Wikimedia Foundation must not require the use of any proprietary software on the user's system."

Perhaps this might be better:

• "Full participation in projects operated by the Wikimedia Foundation must not require the installation of any proprietary software on the user's system."

The reason for this quibble is that the free mapping services currently suck big time, and Google Maps is currently massively better. The point, as currently written, would seem to forbid combining such maps with Wikipedia content in some new ways, and/or embedding such maps in Wikipedia pages. So the user's O/S could be free, their browser could be free, and the client <--> server communication could all be in open protocols, and using open standards, but it would still fail this test because in this scenario some of the JavaScript that temporarily runs on the user's computer is not under a free license, even though they never install that JavaScript. I personally have no qualms with leveraging off of proprietary software, until suitable free replacements are available, provided that the software is never installed on the user's system (i.e. it that can be replaced on the server side), and that it uses free and open protocols and standards. This point for me should be entirely about the user's system, and what the user actually has to do in a very real and practical sense to get Wikimedia's stuff to work. So for me the crucial test is "do you have to install something proprietary?", not "do you have to use something proprietary?" -- All the best, Nickj 02:08, 4 September 2007 (UTC)

Relying on a proprietary third-party mapping service would be considered a no-no under current practice. We should instead work to build up the free resources. --brion 15:11, 4 September 2007 (UTC)

Not clear about "full participation"

I was hoping this would clarify the position of the WMF regarding my recent suggestion for integration with [www.picnik.com picnik]. If you can download an image and edit it using open source software, then reupload - or alternatively, edit it online using a proprietary tool - does that meet the principles or not? Are you "fully participating" if you don't use the proprietary tool, but achieve the same end? Stevage 04:45, 5 September 2007 (UTC)

I don't see why it would not be the case. The actual participation is the same in both cases - editing the material and putting the edited version onto the server. That the proprietary software is making it easier does not make it required, and thus is no hindrance for this policy. - Andre Engels 06:50, 5 September 2007 (UTC)

Direct dependency

I think the definition of 'direct dependency' is buggy:

A "direct dependency" is given when a copy of the content cannot be rendered or modified by a user using available open source software without a prior conversion to another format.

This would, for example, forbid any kind of compression, because the user would have to uncompress the material before they could render or use the material. It sounds strange to consider gzipped text 'directly dependent on proprietary software', but according to this definition it is... I would suggest that this definition be changed to:

A "direct dependency" is given when a copy of the content cannot be rendered or modified by a user using available open source software without a prior conversion to another format which cannot be made using open source software.

- Andre Engels 07:06, 5 September 2007 (UTC)

negative statements

I would prefer positive statements, rather than a set of 4 "don'ts", even if the meaning is the same. -- Mathias Schindler 14:34, 5 September 2007 (UTC)