The Wikimedia Foundation is drafting its policy on freedom of file formats. Please pick loopholes, we'd like this to be robust.
(in this context, "free software" = meets free software definition, "free content" = meets definition 1.0 on freedomdefined.org, which is the same thing for content rather than software)
- d.
---------- Forwarded message ---------- From: Florence Devouard anthere@anthere.org Date: 19 Jan 2008 21:38 Subject: [Foundation-l] File format policy To: foundation-l@lists.wikimedia.org
Post under a nicer and more appropriate title
--------
Jussi-Ville Heiskanen wrote:
On 1/19/08, Gregory Maxwell
gmaxwell-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
On Jan 19, 2008 12:25 AM, Mike Godwin
mnemonic-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org wrote:
I should think it apparent to pretty much everybody that the Kaltura collaboration is not convenient in the short term.
The choice of a partner which fundamentally requires proprietary technology, over alternative paths which use or create non-proprietary technology (which may currently be less mature or less adopted), is short term advantageous compared to other options.
Personally I think the situation is more nuanced than either of you
present
it as. The Wikimedia Foundation can be a influence for guiding towards what its mission is in many ways (and I regret our mission statement
still
does not make it explicit that we are for non-proprietary formats;
</ceterum
censeo> ).
Some routes are more frayed than others, though, and one needs must make an evaluation of what the best/most effective use of resources/good will/authority etc. is. Erik has clearly made one which you, Greg do not wholly agree with. That, I think, is fine. We should still respect
the fact
that evaluating that is what Erik is being paid for, and naturally Erik chooses whose opinion he relies upon, within the parameters set to him by the board (and here I remind the board, that it *does* have the
authority
to guide its employees _as a body_, though clearly not as individual
trustees).
Since you mention it, I wanted to clarify that we have drafted a file format policy. It has not yet been approved, some board member being willing to further discuss it with other individuals.
I think it relevant to copy this draft here. Comments welcome for all of you of course :-)
---------
Resolution:File format policy
Whereas an essential part of the Wikimedia Foundation's mission is encouraging the development of free-content educational resources that may be created, used, and reused by a diverse community, without restriction, and because we believe that this mission requires thriving open formats and open standards on the web to allow the creation of content not subject to restrictions on creation, use, and reuse, it is resolved that all material, text , multimedia, or software, on Wikimedia Foundation projects must be in a format that is: 1. Viewable or playable by existing free software tools 2. Able to be created or edited by existing free software tools. 3. Defined by an open standard, implementation, or specification not under proprietary control 4. Not itself subject to material patent-related restrictions on use that are incompatible with free software, nor only able to be authored or viewed by software so restricted. 5. Not encrypted or otherwise subject to technical protection measures incompatible with the permissions of free content licensing. where "free software" is software under any licensing terms that meet the Free Software Definition. Where an independently-used subset of the format meets these criteria, even if some files in that format do not (as with PDF and encrypted PDF), files in that subset qualify as acceptable formats under the text of this resolution.
Ant, your favorite sheep keeper
_______________________________________________ foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: http://lists.wikimedia.org/mailman/listinfo/foundation-l
On 19-Jan-2008, David Gerard wrote:
The Wikimedia Foundation is drafting its policy on freedom of file formats. Please pick loopholes, we'd like this to be robust.
(in this context, "free software" = meets free software definition, "free content" = meets definition 1.0 on freedomdefined.org, which is the same thing for content rather than software)
If you truly want the policy to be robust, it's important to avoid the fallacy that programs can be discretely separated from other interpretations of digital information.
Whether digital information is "program", "documentation", "image", "content", or some other form of information depends largely on how it is *interpreted* at a particular time, which is a function of the process used to interpret it, *not* something inherent in the information.
The very same collection of bits can be "program", "documentation", "image", "content", "art", and "data", all at the same time; consider e.g. a PostScript program. The other purpose-driven categories of digital information have similar overlaps. It's folly to draft a policy for *the information itself* that is dependent on its intended interpretation, because that it not a function over which the policy-maker has jurisdiction.
The term "software" is better understood as opposed to "hardware": that is, software is *any* information in digital form, and the medium in which it exists at a given moment is the hardware. These distinctions persist over time, and so a policy can meaningfully be formed around them.
If the freedom of a work is to be usefully defined over time, it cannot be on the basis of its interpretation. Attempting to have *different* freedoms obtain to a work depending on whether it is "documentation", "data", "content", "art", "program" etc. will fail in the numerous cases when a work is in several different categories.
On Sun, 2008-01-20 at 11:41 +1100, Ben Finney wrote:
If you truly want the policy to be robust, it's important to avoid the fallacy that programs can be discretely separated from other interpretations of digital information.
That's not a fallacy, it's a difference of opinion.
It's perfectly possible to talk about digital works in terms of what their function is, what freedoms you might need for those functions, and whether or not a work is free for a certain function.
Without the function it's pretty meaningless. You can't point at a random binary, without knowing its function but knowing its license, and call it either "free" or "not free".
Cheers,
Alex.
On 20-Jan-2008, Alex Hudson wrote:
On Sun, 2008-01-20 at 11:41 +1100, Ben Finney wrote:
If you truly want the policy to be robust, it's important to avoid the fallacy that programs can be discretely separated from other interpretations of digital information.
That's not a fallacy, it's a difference of opinion.
It's a fact that bit-collections can be simultaneously "program", "documentation", "art", and "documentation". Therefore it's a fallacy to name those categories and expect that bit-collections will fall into exactly one of them.
It's perfectly possible to talk about digital works in terms of what their function is, what freedoms you might need for those functions, and whether or not a work is free for a certain function.
You're saying the freedom of a work depends on the function an arbitrary person has in mind for it? Who gets to be that person? What if one recipient of the work has a different function in mind for it?
This logic leads to a single work being both free and non-free. That's not a way to draft a robust policy on freedom of works.
Without the function it's pretty meaningless. You can't point at a random binary, without knowing its function but knowing its license, and call it either "free" or "not free".
Certainly I can. It's not at all necessary to know the purpose to which a work will be put to come up with a good definition of "free software". The FSF already did so, though they insist on only applying their definition to programs.
The free software definition requires that works be free to use for *any* purpose. Works licensed such that they meet the free software definition are free by that definition; others are not. The function of the work doesn't need to come into consideration at all. I argue that if it *does* come into consideration, then you are making freedom of the work contingent on what the recipient intends to do with the work, and that by definition isn't free.
On Sun, 2008-01-20 at 21:54 +1100, Ben Finney wrote:
It's a fact that bit-collections can be simultaneously "program", "documentation", "art", and "documentation". Therefore it's a fallacy to name those categories and expect that bit-collections will fall into exactly one of them.
I didn't say it would fall into exactly one of them; I disagree with the notion that they can't be separated.
Without the function it's pretty meaningless. You can't point at a random binary, without knowing its function but knowing its license, and call it either "free" or "not free".
Certainly I can.
I honestly doubt that.
As an obvious example, you don't know what legal rights the author has to that binary, and if the license doesn't offer permissions to those rights then it's clearly non-free. So if you can't tell if a binary is a document or a database, which could be the same technical file format, you don't know if the BSD license applied to it is good enough or not.
The function of the work doesn't need to come into consideration at all. I argue that if it *does* come into consideration, then you are making freedom of the work contingent on what the recipient intends to do with the work, and that by definition isn't free.
And I would argue it's an immediately practical concern since much of what defines a given work as being free is the license applied to it. The law talks in terms of function, not form, and thus the freeness is based on function, not form.
Cheers,
Alex.
On 20-Jan-2008, Alex Hudson wrote:
On Sun, 2008-01-20 at 21:54 +1100, Ben Finney wrote:
It's a fact that bit-collections can be simultaneously "program", "documentation", "art", and "documentation". Therefore it's a fallacy to name those categories and expect that bit-collections will fall into exactly one of them.
I didn't say it would fall into exactly one of them; I disagree with the notion that they can't be separated.
Making a policy that requires different freedoms depending on the different functions of a work is requiring that they *always* be separated. If they *can* be combined in the same work, the policy is no longer robust.
Better to define a policy that requires the same freedoms *regardless* the function of the work.
As an obvious example, you don't know what legal rights the author has to that binary, and if the license doesn't offer permissions to those rights then it's clearly non-free.
How would knowing the function ever guarantee that I know the rights the *author* has in the work? It might clarify some issues, but if you're suggesting I could know with certainty the *absence* of obligation on the copyright holder, that's not possible.
It's also irrelevant. As a recipient of the work, I must take the work and its license terms as given, and judge the freedom of the work based on what rights the *recipient* has in the work.
The function of the work doesn't need to come into consideration at all. I argue that if it *does* come into consideration, then you are making freedom of the work contingent on what the recipient intends to do with the work, and that by definition isn't free.
And I would argue it's an immediately practical concern since much of what defines a given work as being free is the license applied to it.
Yes, exactly. We seem to be in agreement on this point. The license terms on a work are a major factor in determining the freedom of the work for recipients of that work.
The law talks in terms of function, not form, and thus the freeness is based on function, not form.
That's a non-sequitur. The law can impose restrictions; it's up to us to define what freedoms we require. The free software definition, and the free culture definition, both do a fine job of defining free software with a requirement that function *not* be a factor.
On Sun, 2008-01-20 at 23:01 +1100, Ben Finney wrote:
On 20-Jan-2008, Alex Hudson wrote:
As an obvious example, you don't know what legal rights the author has to that binary, and if the license doesn't offer permissions to those rights then it's clearly non-free.
How would knowing the function ever guarantee that I know the rights the *author* has in the work?
I didn't say it would guarantee you know. I said that without understanding the function of the work, it's much more likely that you *don't* know.
For example, as "executable" as a Postscript document might be, UK law is not going to treat it as such without very good reason. It's a literary work, and the form of it doesn't matter one jot. Anyone hoping to bypass the moral rights inherent in a literary work by claiming it's merely software under our law is going to find themselves in for a bug surprise.
It's also irrelevant. As a recipient of the work, I must take the work and its license terms as given, and judge the freedom of the work based on what rights the *recipient* has in the work.
That only holds if you this the license terms are orthogonal to the function of the work, which I don't really believe.
The law talks in terms of function, not form, and thus the freeness is based on function, not form.
That's a non-sequitur. The law can impose restrictions; it's up to us to define what freedoms we require. The free software definition, and the free culture definition, both do a fine job of defining free software with a requirement that function *not* be a factor.
It's not a non-sequitur, it's a statement of reality based on the world we live in and particularly the legal framework.
The law puts in place restrictions based on the function of a work, not whether or not it is composed of bits or atoms. If you don't know the function, you don't know which laws apply. If you don't know the laws, you don't know if the license permits the freedoms you want, and you don't know if it meets the definition of 'free' or not, regardless of how that term is defined.
It's nothing to do with the definition of freedom at work.
Cheers,
Alex.
Alex Hudson home@alexhudson.com wrote:
On Sun, 2008-01-20 at 21:54 +1100, Ben Finney wrote:
It's a fact that bit-collections can be simultaneously "program", "documentation", "art", and "documentation". Therefore it's a fallacy to name those categories and expect that bit-collections will fall into exactly one of them.
I didn't say it would fall into exactly one of them; I disagree with the notion that they can't be separated.
If there is something that won't fall into exactly one of them, then they can't be separated completely. However, we can distinguish them as concepts because there is something which will fall into exactly one of them, so it's also a fallacy to say those categories are indistinguishable.
[...]
The law talks in terms of function, not form, and thus the freeness is based on function, not form.
It talks in terms of both, doesn't it? That's part of the reason why the law on this is a bit of a dog's breakfast and why freedom debates about it are messy.
Rgeards,
On Mon, 2008-01-21 at 13:13 +0000, MJ Ray wrote:
If there is something that won't fall into exactly one of them, then they can't be separated completely. However, we can distinguish them as concepts because there is something which will fall into exactly one of them, so it's also a fallacy to say those categories are indistinguishable.
I _think_ I agree with that :D
[...]
The law talks in terms of function, not form, and thus the freeness is based on function, not form.
It talks in terms of both, doesn't it? That's part of the reason why the law on this is a bit of a dog's breakfast and why freedom debates about it are messy.
Off the top of my head, I can't think of an example where it talks of form. In terms of the UK, it gets close - e.g., no moral rights for computer programs, supposedly no patents either - but it never really gets into what "computer program" actually means. Indeed, most of the patent games people have played in the past (a computer program on a fixed disk, a computer program running on a computer, etc.) have tended to be on the edges of what function something can have given its form.
Our law tends not to define stuff too closely, and leave it up to case law - so when it says things like "electronic copies" I guess that for all intents and purposes means "digital copies" right now, but possibly not in the future. Certainly "computer program" can be construed more widely than simply "digital file which a computer can execute".
In terms of the current debate, I think it's valid to look at things from either a form or a function standpoint. The form argument makes sense in certain situations: e.g., I know a number of debian-legal subscribers adhere to that viewpoint, and when you're shipping something which is digital then having rules which concern all digital information makes sense.
What I object to is the argument that the functional standpoint is fallacious. Either standpoint has "problems". As an example, I've seen a number of cases of documentation that has been covered by the GPL. Not only is that a complete stretch (a stretch too far, for me) in terms of the language, you're potentially in real trouble if you want to print that stuff out. Assuming it's arguably a "non-source form" under GPLv3, you have to choose between one of 6a-6e which become increasingly bizarre in terms of hard-copy literature. While for some documentation under the GPL is ok, for me I would find it difficult to describe it as "free". If you have someone else doing manual lay-up for pre-print, it's obviously non-free because there can never be any "corresponding source" so you're basically buggered.
Cheers,
Alex.
On 20/01/2008, Ben Finney ben@benfinney.id.au wrote:
On 20-Jan-2008, Alex Hudson wrote:
On Sun, 2008-01-20 at 11:41 +1100, Ben Finney wrote:
If you truly want the policy to be robust, it's important to avoid the fallacy that programs can be discretely separated from other interpretations of digital information.
That's not a fallacy, it's a difference of opinion.
It's a fact that bit-collections can be simultaneously "program", "documentation", "art", and "documentation". Therefore it's a fallacy to name those categories and expect that bit-collections will fall into exactly one of them.
It's perfectly possible to talk about digital works in terms of what their function is, what freedoms you might need for those functions, and whether or not a work is free for a certain function.
You're saying the freedom of a work depends on the function an arbitrary person has in mind for it? Who gets to be that person? What if one recipient of the work has a different function in mind for it? This logic leads to a single work being both free and non-free. That's not a way to draft a robust policy on freedom of works.
That's because the law isn't logical in this respect. You may wish to reread "What Colour Are Your Bits?":
http://ansuz.sooke.bc.ca/lawpoli/colour/2004061001.php
Precis: just because it doesn't make any damn sense to anyone who understands this stuff, doesn't mean that the law is not what it actually is, with people willing to enforce the law's interpretation with money and guns. (c.f. the DMCA and software patents for other legal constructs that make no sense but are part of the reality we have to deal with.) Our licensing policy is essentially a legal matter, because licenses are legal constructs.
So we do actually separate software and documents. (And don't allow document uploads with active content, i.e. that written in something Turing-complete.) There is also the fact that our content contributors and software contributors are almost disjoint groups, with the second ridiculously smaller than the first. So writing something directly in terms of the content contributors, rather than pointing at the software policy and saying "transpose it yourself."
(Our software policy is "free software only". We do allow some almost-free stuff as a secondary option - e.g. if you don't have VLC as a plugin then video will try to play in Cortado, which is written in Java. Java is not quite free yet, but we're reasonably confident Sun will continue to free it up and won't embarrass us in this respect. We look forward to a Theora-playing <VIDEO> element that's reasonably available (i.e. in Firefox 3) and not buggy as hell (e.g. in Opera 9.5 previews) - it would supply a very nice and popular use case to drag Nokia and Apple kicking and screaming to the Theora party. We're currently encouraging along a company doing Flash-based video editing to get it all working in free formats on free software, and they're working to get their stuff there. Etc., etc.)
- d.