I could make a full time job of tearing down the "say anything we possibly can" approach to Open XML opposition. Seems like we're seeing a new level of arm-flailing and finger pointing, now that we are weeks away from the close of the post BRM period. I wanted to offer some comments about the SFLC's analysis of the OSP. This is an unfortunate report, these all represent issues that have been raised in a campaign that includes innuendo and supposition, leaving out inconvenient information and language and ignoring the same, similar, or less attractive, language that exists for ODF.
The big news in this is their admission/confirmation that the OSP is in fact compatible with the GPL. They say "The OSP cannot be relied upon by GPL developers for their implementations not because its provisions conflict with the GPL but because it does not provide the freedom that the GPL requires." They go on to identify that "freedom" being linked to the OSP being unsafe is because new versions of the specifications could be excluded from the OSP in the future.
It is unusual for promises like the OSP to automatically include every spec or all future versions (IBM's pledge is exactly like ours). The norm is for new versions to be added to them to be covered. In the case of Sun's statement new versions are automatically added only when they participate in the development of the new version to the extent that the OASIS IPR rules would then obligate them to provide patent rights under the OASIS IPR Policy. None of these promises include future versions of the specifications without any qualification.
Let's deal with the points one by one:
This section points out that the OSP only applies to listed versions of covered specifications. True, except that we have already committed to extending it to ISO/IEC DIS 29500 when it is approved in our filing with ISO/IEC. For ODF, IBM in their ISP takes the identical approach. Strange how things that seem appropriate for ODF are not appropriate for Open XML.
Not true. The OSP is a promise to not assert patents that are necessarily infringed by implementations of covered specifications. Like all similar patent non-asserts (including the Sun and IBM versions for ODF) the promise covers that part of a product that implements that specification (and not other parts that have nothing to do with the specification). While the Sun covenant is silent about conformance to the specification, the OSP allows implementers the freedom to implement any (or all) parts of a covered specification and to the extent they do implement those portions (also known as conform to those parts) they are covered by the promise for those parts. Contrast that to the IBM pledge that requires total conformance and so programming errors or absence of something required by the spec (but not by an implementer's product) means that the promise is totally void for that product.
Not true. As far as we are concerned we are happy to extend the OSP to implementers who distribute their code under any copyright license including the GPL. The FAQ cited just states what everyone knows and acknowledges, the GPL is a copyright license that is drafted in a way that leaves many issues (not just those related to patent rights) open to many interpretations. Any particular user or implementer should read the GPL carefully and make their own judgment about what it means and requires in accordance with their own circumstances. The FAQ states that Microsoft is not in a position to give blanket advice about the GPL to others. They missed these two FAQs for some reason...
"Q: Is the Open Specification Promise intended to apply to open source developers and users of open source developed software?
A: Yes. The OSP applies directly to all persons or entities that make, use, sell, offer for sale, imports and/or distributes an implementation of a Covered Specification. It is intended to enable open source implementations, and in fact several parties in the open source community have specifically stated that the OSP meets their needs. Moreover there are already a significant number of implementations of Covered Specifications that have been created and/or distributed under a variety of open source licenses as well as under proprietary software development models. Because open source software licenses can vary you may want to consult with your legal counsel to understand your particular legal environment.
Q: Is this Promise consistent with open source licensing, namely the GPL? And can anyone implement the specification(s) without any concerns about Microsoft patents?
A: The Open Specification Promise is a simple and clear way to assure that the broadest audience of developers and customers working with commercial or open source software can implement the covered specification(s). We leave it to those implementing these technologies to understand the legal environments in which they operate. This includes people operating in a GPL environment. Because the General Public License (GPL) is not universally interpreted the same way by everyone, we can't give anyone a legal opinion about how our language relates to the GPL or other OSS licenses, but based on feedback from the open source community we believe that a broad audience of developers can implement the specification(s)."
Gray Knowlton wrote: "Well, Bruce, I don't think we have a "big rich companies" section of the OSP, I think it applies equally to big and small companies."
Please drop the act. There is no need for a "Big Rich Companies" section of the OSP, because big rich companies get a lot more rights to Microsoft's patents than the OSP would grant. They don't enter into "interop" agreemnts with Microsoft. They get cross-licenses that give them patent rights for essentially any application, not just interoperability.
"Does it make sense for us to propose a standard then prevent people from implementing it? -- I don't think so."
In a world where governments and others are starting to demand standardized document formats, does it make sense for someone with near-monopoly situation to propose a standard then prevent competitors from implementing it, maintaining status quo with the cash cow?
To be trusted by the open source community, Microsoft must avoid even the "perception of impropriety". This means that the OSP must be written in a way that the SFLC will conclude that it is "fully compatible with free and open source software licensing". Regardless of the merit of their arguments, anything less than a full endorsement by the SFLC will raise concern.
Gray Knowlton said
"As far as recounting the entire history of Microsoft legal activity, again, it's not really something that is helpful."
I disagree, if somebody has a history of stabbing "people" in the back, I don't think I would be to quick to turn My back on then, just because they said "Trust Me".
I think Mark, Keenan, Peter, (others) have really hit it on the spot: this has nothing to do with ISO or DIS29500. As Mark points out, objection on these grounds implicates a lot of standards, including IBM's approach on ODF.
And Peter, are you really suggesting that ISO hold Microsoft (and the participants of Ecma TC-45 like Apple and Novell) to a different standard than companies who need to cover ODF with these promises? Really?
Bruce, I think you're going in circles now. Either you think the OSP applies equally or you don't (it does). So we can continue to go in circles or just stop debating the point. Again, if you're implying that Google or any other company (big or small) has to enter into some special agreement to implement Open XML, that is inaccurate. Google had an implmentation of VML in its Maps product long before the Open XML discussion started anyway.
Anonymous (honest)... in a world where accountability and compliance are mandates, there is little room for games and slight-of-hand. I'd give the government ageinces a little more credit.
It's not "Trust me." Regarding the ISO process, ISO is the organization declaring that Open XML passed their bar for IP requirements.
For Microsoft, it is "Show me" and "Watch me." Show me where we've taken action on an Open XML implementation, and "watch me" demonstrate the commitment to interop outlined in the principles announced a few weeks back. (Note that my blog post landed a long time before the announcment of Interop Principles.)
You're right, OOXML shouldn't be treated any differently to ODF.
OOXML should be submitted to ISO directly, and undergo full scrutiny from all the member bodies and organizations, as ODF did.
It should not be fast tracked in the back way by a rubber stamp committee that has been seen to be changing the rules for fast track process just before the spec was submitted.
If you want us to trust you, stop acting like you've got something to hide.
Greg, you're either really bad at pretending to miss Bruce's point, or you're a lot slower than someone in your position should be.
Bruce's point is:
A small developer has *only* the OSP to rely on.
A large developer (like Google for example) has the OSP, and patent/etc. cross-licensing agreements to rely on.
Therefore, if both the large developer and the small developer run into a trouble-spot where the OSP doesn't properly protect their interests, the large developer is in a better position because it has *other* agreements to protect their interests *besides* the OSP.
ODF did not go through "the full process." It went through the "Publicly Available Specification" (PAS) process, which has even less steps than the "Fast-track procedure" OOXML is currently in.
For details, see the ISO procedures link below. Page 61 of that PDF is especially handy, as it shows the different ISO processes in a fairly simple chart.
I think OOXML should go through one of the processes that includes a committee (2.5) stage, though. And no, ODF did not. It went through the PAS process, according to Rob Wier.
Gray Knowlton said:
"It's not "Trust me." Regarding the ISO process, ISO is the organization declaring that Open XML passed their bar for IP requirements."
I don't see Open XML passing the bar, I see it as Microsoft attempting to buy the bar(ECMA), because if Open XML fails fast track, Microsoft risks there cash cow to growing government ISO document requirements.
They can't risk ODF ISO/IEC 26300 (approved 2 Years ago ) get any more support!
You keep asking for examples of Microsoft taking action against somebody's Open XML implementation, I say its far to Early, they are still working on the "Embrace".
Microsoft won't "Exterminate" until Open XML is an "approved" standard !
This is business as usual for Microsoft,"Embrace, extend, and exterminate"
Embrace XML on there terms (Open XML not ODF ISO/IEC 26300 )
Keep adding "custom" Extensions (With the all powerful "IP")
Exterminate any body who uses there precious "IP"
it won't be tomorrow, or next week ...
Looking at Microsoft's history, and current actions.
They don't look like a company committed to interoperability/coexistence!
Theo, I understand the point here, big companies can rely on the OSP just like the little ones do (and they are doing so today.)
look here: http://blogs.technet.com/gray_knowlton/archive/2008/03/07/silverlight-viewer-for-open-xml.aspx
These companies did not have to enter into a special agreement to develop their Open XML tools. Pay close attention to Gareth's comments from Datawatch... they were also able to implement support for the binary formats (as did countless other software providers).
Basically, what is the problem with Microsoft saying explicitly that "Microsoft will not sue anyone for implementing DIS 29500, and any future iteration thereof". End of statement. No conditional clauses. It doesn't matter if no one else has done it before. No fear from Microsoft for anyone as long as it "IS" a sincere attempt at implementing a standard as best as one can interpret it?
Watch out for the black helicopters Ray...
XML support in Office arrived 8 years ago (which means code was written 10 years ago). And while you're out looking for for the Open XML actions we're taking, you should dig up the history of binary format specification licensing we weren't doing since 2003, and dig up that long list of actions we've taken in addressing the thousands of applications that read and write the binary formats.
What's wrong with providing protection for the specifications that actually exist? even the +1 spec, the post BRM DIS29500 we've already committed to protecting, both with an "irrevocable promise."
Nothing is wrong with that, but when the perception is that Microsoft controls, or exert sufficient influence to change the rule of the specification at it's whim, Microsoft needs to make some very clear statements to "ANYONE" attempting to implementing this specification.