Talk:OpenDocument
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.
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.
- 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 all agree on, that would be fabulous. -- Dwheeler 02:00, 27 September 2005 (UTC)
Vote Proposal
As noted above, there's a question whether the term "prevent" or "unacceptable" should be used.
Prevent:
Unacceptable:
- 69.247.133.181 Douglas McClean
Some-other-alternative-phrase (but please tell us what it is!):