Talk:OpenDocument

OOo

Hello,

I'm Daniel Carrera. I wrote the Groklaw article linked to at the bottom of the article ("The Future Is Open..."). If any of it is useful, feel free to copy it under the terms of the GFDL and publish it on Wikipedia.

Cheers, Daniel Carrera.

OpenOffice.org volunteer.

dcarrera {at} open office {dot} org.

What is layout-cache?

I have not been able to find documentation on the layout-cache file. If anyone knows what it is, or has information on it, adding it to this article would be much appreciated. JesseW 6 July 2005 05:51 (UTC)

OpenOffice 2.0 (Open Document) to MediaWiki format

Is there a macro or export filter that will allow one to create documents in OpenOffice, and export them in MediaWiki format? -- 68.10.113.7 21:03, 29 August 2005 (UTC)

Not directly, to my knowledge. However, if you save as HTML, you can use my program HTML2Wikipedia to do the translation.

OpenDocument#Licensing MS concerns refuted

The majority of concerns mentioned in the paragraph "All of this is in contrast with the competing "Microsoft Office Open XML"..." is refuted by this FAQ on Microsoft's site: http://www.microsoft.com/Office/xml/faq.mspx --Travis.hardiman 06:33, 12 September 2005 (UTC)

Don't think so, other than maybe the patent granting text; I'll try to tweak that. But as for the rest, Microsoft's refutation has itself been refuted by many articles. That includes the referenced articles, such as the eWeek and Groklaw articles. The Commonwealth of Massachusetts' lawyers have looked deeply into this, and specifically said that there are such limitations. Microsoft's statements date from January 2005; the referenced refutations all date after that. In any case, there seems to be significant disputes here, so it wouldn't be right to just quote Microsoft's statements without referring to independent statements; the text here should clearly NOT claim that there's universal agreement that there's no problem, when in fact independent observers seem to all agree that there is a problem. Even the most pro-Microsoft articles claim that Microsoft's format is "open enough", not that it's actually open, and the #1 "open enough" article talks about .doc/.ppt/.xls, NOT the equivalent Microsoft XML format, as being open enough. Read the license text more carefully. It says, "some open source licenses may include specific constraints or restrictions that might preclude development under the Office 2003 XML Reference Schema licenses.... If an open source software provider believes a particular form of open source license is somehow in conflict with the license Microsoft is providing, then they have significant flexibility to choose other forms of open source licenses." What they omit is that their terms are incompatible with the most common license, the GPL, according to many people who have examined the terms. And the "flexibility" is an illusion; many people choose the GPL license specifically because they want those terms, or because they're reusing mounds of code under that license. Also note that they grant permission to read government documents in this format without a license; non-government documents, and writing the format, are not covered. Let's see if we can get this NPOV and accurate, but by no means should we take an interested party's claims (Microsoft's) as the sole word on the topic. Dwheeler 14:52, September 12, 2005 (UTC)

Okay, I've modified it. Hopefully there's enough there now. The details of GPL incompatibility are more complex (possibly intentionally so), but interested readers can go follow the linked references for more info. Dwheeler 15:59, September 12, 2005 (UTC)

Looks a lot more thorough now, thanks. Although this sentence is misleading: "Microsoft is well aware of widespread use of the GPL license by many of its competitors, and at one time even called the GPL (the license used by many of its competitors) a "cancer"" (3rd paragraph). Microsoft as a corporation never made that statement, as the sentence implies. Ballmer said "Linux is a cancer that attaches itself in an intellectual property sense to everything it touches," although he was talking about GNU GPL ( http://www.theregister.co.uk/2001/06/02/ballmer_linux_is_a_cancer/ ). Thanks again! --Travis 22:34:10, 2005-09-12 (UTC)

I think you're splitting hairs, but I've tried to respond to them. Ballmer is Microsoft's CEO, and these were a set of public statements by the CEO. Yes, he says "Linux", but in the next breath he says it's because of the license, and as you read it is OBVIOUS that he's talking about the GPL. So I've reworded the statements slightly to be wordier yet more precise. -- Dwheeler 02:09, 19 September 2005 (UTC)

You may want to read this, regarding the tone of voice used in the article when discussing Microsoft: http://en.wikipedia.org/wiki/WP:NPOV --Travis 04:56, 15 September 2005 (UTC)

I'm very familiar with it. == Dwheeler 02:09, 19 September 2005 (UTC)

Thank you for the good article !

I would like to thank David Wheeler for this very good article. I've made the french translation/abstract of it. w:fr:Utilisateur:Jmfayard

Thanks! But it's not just me, there are many cooks around here :-). -- Dwheeler 20:00, 26 September 2005 (UTC)

Licensing: Prevent or unacceptable?

Douglas McClean's position ("unacceptable")

I continue to disagree with the article that the Microsoft XML format licensing restrictions "prevent competitors from using it". This is true only in the sense that it is true of all licenses, they prevent people from using something _unless they accept the terms_. What is really meant here is that many customers consider the terms to be unacceptable, which is entirely their decision and not an affirmative action of Microsoft as is suggested by the verb "prevent".

I believe the article should say something along the lines that "many competitors find the license restrictions to be unacceptable."

The license does not contain terms that would explicitly "prevent" any competitors from using it. These competitors _elect to decline the terms_ because they wish to continue using licenses (such as the GPL) which are incompatible with the restrictions. This is not Microsoft preventing anything anymore than my offering to sell you a sandwich for fifty dollars prevents you from buying it because you feel that five dollars is a more fair price. You have decided that my terms are unacceptable.

I respectfully disagree with the edit of JesseW on this point.

As a matter of disclosure, my name is Douglas McClean and I have no affiliation with Microsoft.

Further I would like to say that I think OpenDocument is great, and I hope for widespread adoption of it, which I intend to promote by adopting it myself for personal use and by creating support for it in a software project which I maintain. I don't want to get involved in the psuedo-religious war around this issue, but I do feel that this language is inaccurate and further is not in a neutral point of view.

69.247.133.181 01:22, 26 September 2005 (UTC) Douglas McClean

Reply ("Prevent")

I respectfully disagree, and believe that the proposed rewording above would be a non-neutral point of view. "Prevent" is the correct term, because there's no practical way that all valid competitors could accept the terms. Many suppliers' key development models depend on conditions that these terms prevent.

First of all, it's not customers, it is developers. If a developer cannot use a specification without abandoning the business model or development model, then the developer cannot realistically use the specification. And if there is a constraint on developers, then customers never get to choose between alternatives.

Let's reverse directions of the license, and see if it would make sense. Imagine a specification that CANNOT be implemented by proprietary software, but ONLY by GPL'ed software (a patent-owner could do this). I am certain that many proprietary vendors would loudly proclaim that such a license is discriminatory. Sure, any vendor could accept those terms, but their business model couldn't support it. And that's actually far less discriminatory; at least each vendor could take the same GPL'ed program, and sell support for it. Microsoft could not use such a specification with Microsoft Office. (Formerly I wrote "Does anyone seriously think that Microsoft would find such a license over a document specification acceptable? Nonsense!"). So a GPL-only specification is discriminatory, and therefore the Microsoft license that forbids GPL implementations is also discriminatory.

In this case, there are already programs that use the GPL, like KOffice and Gnumeric. It's not that they can "decline" the license; their license (the GPL) was written years ago, and they already set on it years ago. There's really no practical way for them to change; the rewrite would probably never happen, and in any case they reuse lots of other people's software under this license that they couldn't get changed. Microsoft could have released a license that permitted all competitors to use the specification. They didn't. They released a license that they knew could not be used by some of their competition. Is that not clear? It's perfectly reasonable, under neutral point of view, to note that some competitors cannot use the license Microsoft offers; their "choice" would require them to abandon their product.

I'm noting GPL because there the legal case is really obvious; I don't know of any legal authority who has said "I've looked at the Microsoft license, and am confident that GPL software can implement it." But Marbux' detailed legal review gives his opinion, as a lawyer, that even proprietary vendors can't implement the Microsoft's specification given its current license, due to fine print that takes those rights away. If other proprietary vendors can't even implement it, then it's even clearer.

In contrast, the OpenDocument license allows all current suppliers to use the specification. See the difference? You can't create a license that you know cannot be used by some already existing suppliers, and then say it's not discriminatory. Of course it's discriminatory.

Yes, all agreements have terms. But that doesn't mean that all terms are reasonable. Imagine terms like "You must provide your firstborn child" or "you must pay your entire income each year". Clearly I could "decide" whether or not to agree to it, but there is no real decision, and thus it's discriminatory. Heck, many would agree that terms like "you must pay me more per copy than the amount you make per copy" are clearly discriminatory. Terms that completely forbid development models already in use, or prevent their use by legitimate competitors that already exist, are discriminatory. The terms have to be ones that the current and plausible future competitors can reasonably agree to, without being at a disadvantage.

Regarding your $50 vs. $5 comparison... that's not the issue. Cost is not the question. The specification license is forbidding a development/deployment model which is irrelevant to how the data is stored. It'd be like a hot dog specification that said, "Here is a specification for a good hot dog. To comply, you must not be a non-profit organization." Nonsense.

Microsoft has a right, under U.S. law, to release their specifications under terms like this that prevent use of that specification by some of their competitors, as long as they have patents that apply to it. But it's perfectly okay in Wikipedia to note that, too. It's especially appropriate to do that here, since that is one of the key distinctives of the subject of the article (OpenDocument) as compared to its alternatives.

OpenDocument does not discriminate. Microsoft could implement it at any time, and not change their Office license at all. Adobe has done the same sort of thing with PDF; there are other PDF readers and writers, but Adobe still manages to do well.

-- Dwheeler 19:37, 26 September 2005 (UTC)

For what it's worth, I agree with Dwheeler's reply above, and hope that it explains my edit that was referred to. JesseW, the juggling janitor 20:05, 26 September 2005 (UTC)

Reply on the prevention issue

Dwheeler,

I think you made my point very well, your reply above succinctly explains how the discussed competitors could accept the terms (for example, by changing business models or rereleasing their code under different business models).

I certainly agree with your point that Microsoft would likely find the hypothesized inverse of this licensing situation unacceptable. I can't see how they wouldn't. But again, that goes to my point. You yourself chose the wording "Does anyone seriously think that Microsoft would find such a license over a document specification acceptable?"

I find it interesting that in what you agree is the reciprocal situation, you cast the issue in terms of what Microsoft would find to be acceptable, yet you disagree with my exactly parallel characterization. (Note: The argument disputed in this and the preceding paragraph addresses previous comments by Dwheeler which he has since amended.)

Cost is the issue. Monetary and non-monetary costs of accepting the license are the only reasons not to accept the license. Here, producers of GPL'd software would (as you demonstrate) have to pay extreme monetary and non-monetary costs to accept (such as abandoning the GPL, securing GPL-compatible dependencies, reissuing under a new license, changing distribution models, changing cultures, etc.), and so they wisely choose to decline.

Ridiculously high prices such as a "firstborn child" are not (as you state) discriminatory, for the simple reason that they do not discriminate. They just limit the number of people who are likely to accept an offer.

I am not trying to make the point that accepting the Microsoft terms would be simple, easy, or sustainable under various competitors business models. Nor am I disputing that it would very likely be better for everyone except Microsoft had Microsoft chosen different terms. What I am saying is that as a matter of fact and of law, it is the competitors choice not to accept the license. They are not prevented from doing so.

It is great that OpenDocument does not discriminate and does not have any strict license restrictions. I agree that Microsoft could implement it without revising their current licenses for Office. I agree that many people have done well with similar open format models. I disagree that any of that is in issue. The article is very accurate on those points, and I applaud it. My only issue of dissent from the article is that the Microsoft terms do not "prevent" competitors from licensing their format, but these competitors find the offered terms to be unacceptable.

69.247.133.181 00:06, 27 September 2005 (UTC) dmcclean

We need to be clear who we are talking about here. You would agree that Koffice is a competitor, right? What is Koffice, in the sense in which it is a competitor to Microsoft?

Is it the KDE Foundation? That foundation could, theoretically, hire programmers to write code to implement Microsoft's format, and a whole office suite, and release the code under a license acceptable to Microsoft's terms. However, the KDE Foundation has a minimal set of assets with which to do that; in that case they are no more of a competitor than any of the thousands of other foundations in their income class. So the idea the the KDE Foundation is the "competitor" to which you were referring seems wrong.

Are the individual developers who currently volunteer their time and skill to work on Koffice, individually, the "competitors" to Microsoft? This cannot be, as they, individually, would not, have not, and could not write the necessary code to make a credible competing program to Microsoft Office; it is too large a task for one single programmer. So the individual developers are not the "competitors".

Is the competitor the collective group of people who currently work on Koffice, the Koffice "development community"? If so, while individually they could each could, theoretically, choose to contribute to, and license their code under, a project to implement Microsoft's format, under a license not prohibited by Microsoft's terms, many of them would choose not to do so, therefore the group as a whole could not be considered to persist. So, the "development community" would be prevented from implementing Microsoft's format by the inevitable split that would occur should they attempt to do so.

Is the competitor the current codebase of Koffice, made up of many copyright holders, all of whom have agreed to license it under the GPL? That codebase, as you have agreed, is prevented from incorporating an implementation of Microsoft's format, so, if the codebase is the "competitor", prevent is the right word to use.

What other entity were you thinking of? Who or what is the Koffice competitor who could implement Microsoft's format, but does not because the terms are "unacceptable"? JesseW, the juggling janitor 01:43, 27 September 2005 (UTC)

Nice note about my use of "acceptable" above. But that just means I chose my words poorly there; I've fixed it above. But I think you're hair-splitting here. The notion that you can write any terms, and it's just a matter of accepting them or not, makes sense when there are equal parties voluntarily entering into an agreement. But it doesn't if one party owns something (say, a spec), and then creates such onerous terms that they practically prevent use. I'm having trouble believing you're arguing that giving up your firstborn child might acceptable to someone with a child. That isn't a term that's "acceptable or not"; anyone who has a child (and loves that child) would NEVER give up their child. With unequal parties, creating terms that are that onerous quickly becomes absurd. And again, I don't agree that cost is the issue. As JesseW notes above, it is not all clear that a competitor like KOffice could even exist if it tried to accept those terms. KOffice depends on Qt, which is GPL'ed... trying to use a different license would cause the non-existence of the group!!

After this discussion, it appears that everyone seems to understand the issues, and the real problem is how to phrase it here. Obviously I have a viewpoint, but sadly I lack omniscience :-). For lack of a better way to resolve this, I suggest we put it to a vote; I've put a little template below. More comments/discussion would be good, too. In particular, if there's a third way to say this that we can all agree on, that would be fabulous. Suggestions welcome. In my mind, the real issue is that terms create a situation where valid competitors cannot realistically compete, and that's why "prevent" comes to mind. Suggestions, anyone? Anyone? Bueller? Bueller? -- Dwheeler 02:00, 27 September 2005 (UTC)

Most certainly agreed on the desirability of a consensus third option, I will think on that.

I don't think the codebase of KOffice can be considered a "competitor" because it does not have intentions. The competitors are the people and organizations behind the development of that codebase. If they wanted to accept the license terms they could abandon part or all of the existing codebase, or renegotiate terms for its licensure that were compatible with the terms offered by Microsoft. Again, extremely expensive and time consuming, staggeringly unlikely. Nevertheless, their choice.

I think it is a somewhat specious argument to claim that because many in the development community would not choose to realign their efforts to compete with Microsoft on the offered license terms that the collective entity competing would not continue to exist. First, that argument cedes my point that the competitors are choosing not to do this and are not being prevented from doing it. Second, if the assumed collective entity exists and can be thought of as having a will, then it collectively could decide to change plans and accept the terms. Your estimate of the unlikelihood of any specific group of competitors deciding that this was in their interest does not constitute the affirmative and declarative action on the part of Microsoft indicated by the verb "prevent".

Please note the distinction here between what "all current suppliers" could choose to do, and what "all current suppliers" could choose to do that would be consistent with their development philosophy and would allow utilization of all of their existing codebases and intellectual property arrangements. The fact that in order to accept terms would force you to give something up does not constitute those terms preventing you from accepting. Giving something up is the nature of terms. I think this may be the center of this dispute. I feel it is not a NPOV to assume through language that developers of open source software are in some way entitled to reciprocal licensing agreements of intellectual property that they would like to use. A license with terms was offered. Many have chosen not to accept.

Thank you for acknowledging the point about your choice of my verbiage to describe the reciprocal situation. I respect that very much, and thank you for restating above to create a consistent proposal that we use the "prevention" terminology. On a general note, as a relatively new person to this editing system, I am impressed with the civility of this discussion by all parties.

I'm not attempting to argue that giving up a first born child would be acceptable to anyone faced with the choice (barring extreme circumstances, for example those of the biblical Abraham). However, offering such terms is not discriminatory, nor is it a very good analog of what is going on here. For example, to gain entry into an opposing political party one might be forced to renounce one's political views. This is not discriminatory, or even wrong, but it is still a bargain few are likely to accept. At any rate, it is the right-holders right to offer terms that many are likely to reject. If I have chocolate pudding and you have cole slaw as lunch snacks, it is the very essence of property rights and offers (in the legal sense) that I may choose to offer terms of trade which you are likely to reject. It is also the essence of competition to seek advantage over competitors. Seeking this advantage, or seeking to control the circumstances of the contest through exercise of the rules, is not the same as "preventing" your competitors from competing.

I'm fine with voting, and I'm fine with losing the vote. But I'm glad we've had this discussion, because I think it has been illuminating on some of the issues involved. Thanks.

Could we resolve this by compromising on a statement that the terms "are unacceptable to many competitors" or "would impose huge costs on many existing competitors" (as opposed to the weaker "which many competitors consider unacceptable")? I feel that either of those statements would demonstrate (especially in combination with the rest of the article) the burden of the Microsoft terms while also establishing that the decision is ultimately that of the competitors and that Microsoft has not actively prevented them from licensing the format.

69.247.133.181 02:51, 27 September 2005 (UTC) Doug McClean

Thank you, also, for how calmly and politely you are conducting this debate. Nevertheless, you have not responded to my question: Who or what is the competitor(s)? You claimed some of my reasons were wrong, which is fine, but nowhere did you state a clear answer to the question. Who or what is the competitor - I believe that the only coherent answer to this is: the competitor is the product, the codebase - which you agreed was prevented from including an implementation of the format. It cannot be the group of developers - they are affiliated only by their work on the codebase, so what they could theoretically choose to do is irrelevent. The competitors referred to in the sentence in question are the competing products which are prevented from including the format. As a compromise wording, how would "prevent some major competing products from using it" be? JesseW, the juggling janitor 03:43, 27 September 2005 (UTC)

My thanks also for this civil debate! I'm glad that you're working on compromise statements, I've been racking my brain for alternative compromise statements too. I think the "huge costs" isn't right at all, though, at least as it's worded there. KOffice _must_ implement using the GPL. It is a KDE application, and full KDE applications use Qt. Qt has two licenses: proprietary or GPL. KOffice cannot reasonably implement except as an open source software project, and it must be GPL to use Qt. The "cost" is "does it exist or not", and I would argue that "existance" is not a cost.. at that point it's a prohibition (hmm, where have I seen that idea before :-) ). "Unacceptable to many competitors" doesn't really capture it either. Maybe something like "are incompatible with the licensing terms used by many existing office suites"? But I think that doesn't really get the point across; "incompatible" could mean just "you need a converter plug", but here it means "must go out of business". I'll keep thinking, maybe my comments will help. Oh, a quick side-note... I suggest that you go ahead and create a login name, so if you move machines or your IP address changes, we have a clue that you're the same person. -- Dwheeler 05:19, 27 September 2005 (UTC)

Can we do anything with the phrase "fundamentally incompatible" combined with "license"? Or something like it? -- Dwheeler 05:24, 27 September 2005 (UTC)

Vote Proposal

As noted above, there's a question whether the term "prevent" or "unacceptable" should be used. In addition, there's always hope that a third alternative phrasing would satisfy everyone. If you have a preference, note it below; if you have a new idea, note that too. Please put more detailed discussions ABOVE this section, in chronological order, so people who are just tuning in can read the back-and-forth discussion in context.

Prevent:

• Dwheeler, 02:00, 27 September 2005 (UTC)
• JesseW, the juggling janitor

Unacceptable:

• 69.247.133.181 Douglas McClean

Some-other-alternative-phrase (but please tell us what it is!):

Comment: I've read about 3 pages of text above and I still do not know what the 'prevent' and 'unacceptable' arguement is fully about. If someone could, would you post the sentence in question so everyone can easily participate in resolving the language issue here? Let's not get overly bogged down, present the sentence and we can look at the context to arrive at a better word, or a phrasing that is NPOV and more accurate. --ShaunMacPherson 10:05, 4 October 2005 (UTC)

Comment: I suspect the disagreement might be resolved by refocusing the language and its context. Currently, the relevant article portion and debate focuses on whether individual developers can use a given file format. A more neutral point of view could emerge if the language instead focused on whether Microsoft's license allows its file formats to be used as a universal standard for exchanging documents among applications. It unquestionably does not. It says in effect, "if you accept this license you can use our file format royalty free (but only to write your own personal document viewer that can not be shared with anyone else, and only to read government documents").

Phrasing the issue as whether Microsoft's formats can serve as a universal standard for exchanging documents makes it clear that it cannot. The prohibition against sublicensing alone means that no developer, proprietary or FOSS, can use the file format and license their programs to others. The end users have to obtain their own licenses from Microsoft.

Even if one were to disagree with the interpretation of the license I and others have given it, I think most would at the very least concede that the license's language is ambiguous. No one can rationally invest thousands of man-hours on a coding project where the legality of the distribution is in doubt, however they license their code. Proprietary software companies are going to obtain separate licenses from Microsoft; they will not use the license that is being offered to the world at large.

Microsoft is well aware of the criticism and could easily resolve any doubts by redrafting the license to clarify the criticized points. Instead, it has chosen to engage in a public relations campaign that does not so much as quote the license. Given that the license itself unambiguously excludes consideration of anything not specifically addressed in the license, the Microsoft public statements are legally meaningless.

However, the history of software companies that want to see other developers adopt their formats is to clarify their licenses when third-party developers raise concerns with license issues. E.g., AT&T's clarification of its Unix licenses that has been discussed extensively on Groklaw.

One might therefore might reasonably infer that Microsoft is at least willing to allow such doubts to continue surrounding their license, which Microsoft has to know will inhibit adoption of its formats by other developers.

So it isn't really even an issue of discrimination, simply a question of whether Microsoft's formats can serve as a universal standard for exchange of office document files. It can not because Microsoft's license does not permit sublicensing and distribution of apps that rely on the "standard." Period, whether they are FOSS or proprietary.

So you might try refocusing the language on the universal standard issues rather than on the discrimination-against-FOSS issue. My article on Groklaw made that mistake and it does not need to be repeated here.

--Marbux

NeoOffice/J

Somebody added NeoOffice/J to the list of applications supporting OpenDocument. I believe the latest NeoOffice/J is based on OOo 1.1.4 but that OOo 1.1.5 was the first to support OpenDocument. Could a Mac user confirm whether or not NeoOffice/J currently includes the support? I know they plan to release a new one based on OOo 2.0, so maybe they should be mentioned in a paragraph ala WordPerfect. IEdML 15:55, 7 October 2005 (UTC)

You're right, it's not supported yet, Patrick is working on it. I removed the reference. Webmink 17:36, 7 October 2005 (UTC)

I was the one who added that text; I didn't realize that NeoOffice was based on 1.1.4 instead of 1.1.5. Thanks for fixing that! --bdesham 19:22, 7 October 2005 (UTC)