Slashdot Mirror
Developers Warned over OOXML Patent Risk
Tendraes brings us a story about legal experts who are warning that Microsoft's "covenant not to sue" over use of the OOXML specification is both ambiguous and untested. Developers wishing to make use of OOXML are unlikely to understand the complex legal language of the Open Specification Promise, and such a document - being neither a release nor a contract - has never been tested in court. From ZDNet Asia:
"David Vaile, executive director of the Cyberspace Law and Policy Center at the University of New South Wales, said that Microsoft participants at a recent symposium on the issue found it challenging to explain how an ordinary person 'or even an ordinary lawyer' could easily determine which parts of the specification were covered. 'This lack of certainty would mean a cautious lawyer may be reluctant to advise any third party to rely on the promise without extensive and potentially quite expensive analysis, and even that could be inconclusive,' Vaile said. 'In turn, this could restrict its viability as a usable standard for less well-resourced users, including small developers and many public organizations.'"
This is a good read... Ron Yu's background paper on patent approaches in OOXML.
It is a chicken or the egg situation. Many of the laws were written by lawyers- either the politicians themselves, those that work for them, or the lobbyists that wanted the law.
The GPL has been tested in court, and in more than one jurisdiction too.
Look, if it was a good spec then there would be reason to debate it's license, implied or otherwise. There would be reason to discuss Microsofts standing.
It isn't a good spec, so it isn't relevant.
It appears that Microsoft has about 280 patents around OOXML and related technologies. It also has a large number of patents that read on ODF. We're making a list of these and hope to be able to publish them soon.
There are also several patents from third parties that read on OOXML, and in theory ISO should halt the process while these are examined and cleared. It looks like ISO won't do that.
Microsoft has several techniques to keep OOXML a captive standard controlled by a single vendor. Complexity is one. But patents are the very best technique.
Note also that OOXML's complexity is mostly because it's a dump of a legacy format. Some upcoming MS ISO proposals are very clean technically, but also very heavily patented.
It seems clear that the OSP is worthless for GPL implementations, the biggest threat to Microsoft.
At the same time it's worth noting that the format being voted on by ISO is not the format implemented by Office. There are over 2,300 changes and the two formats are not compatible. The reason for pushing for ISO standardisation is to let MS market their formats as "standard", while in fact implementing non-standard vendor-specific formats. And then, using patent threats against anyone who tries to reverse-engineer those.
It's a nice con trick. Many national bodies have realized what's going on but many are too corrupted or too ignorant to understand.
My blog
* (i) an unequivocal promise by words or conduct,
* (ii) evidence that there is a change in position of the promisee as a result of the promise (reliance but not necessarily to their detriment),
* (iii) inequity if the promisor were to go back on the promise. Microsoft's words are clearly unequivocal. There is clearly a change in position on the part of a developer who, having read Microsoft's promise, decides to incorporate this format into their software. It would clearly be inequitable then for Microsoft to take action against them.
Untested in court my ass. The first case to use it was 131 years ago.
It's not that the standard itself is patented, but that there is patented material included in the proposed standard. The promise is that Microsoft won't sue for patent infringement when developers use the proposed standard, even though the standard itself would infringe some patents held by Microsoft, if implemented without their permission.
Dynamic linking is fine. He was keeping his future litigation
cash flow in mind. As to precedent, see uClibc and Monsoon.
Monsoon screwed up, and knew they did.
You are being MICROattacked, from various angles, in a SOFT manner.
The real protection you enjoy is that suing you for patent infringement would do too much damage to MS's credibility. MS simply has too much to lose if people start being overly suspicious of relying on the developer information they provide. Ultimately their entire existence is predicated on people being able to take information about specifications they provide (windows APIs) and use them without fear of suit. They simply can't afford to take advantage of some legal loophole to sue you given the damage to their reputation it would cause.
If you liked this thought maybe you would find my blog nice too:
Microsoft have really lowered the barrier to making games on Windows and Xbox 360. XNA and C# have made it really easy to make games but they're so tied to Microsoft that there is no hope of a port. Most code includes look like this..
using System;
using System.Diagnostics;
using System.Collections.Generic;
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Content;
using Microsoft.Xna.Framework.Graphics;Simple, but Microsoft specific.
Making a cross platform game is a lot harder if you are trying to port something written from Windows because you don't even realise until it happens how non-standard you code can be between operating systems. Perhaps you're using the Windows registry or you're using DirectX. Your only hope really is to score an xbox arcade contract with the publisher Microsoft and if you have written your game in C# and XNA you can give up hope of a port unless you're going to go back and re-write some code in c++.
If you want to make a cross platform game then my advice is to write your code on a different platform (Mac, Linux, etc) and then port it to Windows. You'll find the port much easier this way around as it forces you to write your code to be cross platform and it leaves you open to some great debugging tools such as LatencyTop to help you figure out why your game is losing FPS.
That said you can't do all your game programming on Linux because the tools just aren't there. RenderMonkey for shader programming is a good example, but you can easily just do your shader programming on one machine and use the shaders in Linux. Ogre 3D for example has a shader exporter from RenderMonkey.