The other day, an item was published to criticise the role of Mono in the GNOME desktop. Just as a quick reminder, coming from the mouth of Microsoft employees:
“I saw that internally inside Microsoft many times when I was told to stay away from supporting Mono in public. They reserve the right to sue”
Have a look at the following comment from Olav Vitters, member of the GNOME Foundation, who often sends announcements on behalf of the GNOME project:
Note: Tomboy *is* part of GNOME. It is not ‘association’ or whatever you pretended the status to be. This so you could criticize it.
Watch the reply to this:
If Tomboy *is* part of GNOME, is then Mono too *part of GNOME*?
Looking back at yesterday’s comment from Subsonica about Microsoft’s plans (part of its latest SEC filing):
“…the absence of harmonized patent laws makes it more difficult to ensure consistent respect for patent rights. Throughout the world, we actively educate consumers about the benefits of licensing genuine products and obtaining indemnification benefits for intellectual property risks, and we educate lawmakers about the advantages of a business climate where intellectual property rights are protected. However, continued educational and enforcement efforts may fail to enhance revenue. Reductions in the legal protection for software intellectual property rights or additional compliance burdens could both adversely affect revenue. ”
Considering the fragment above, Microsoft by all means looks at patents as a competitive possibility and it wishes to contaminate international law with patentability of algorithms. Now, if Microsoft says it reserves the right to sue over Mono and Mono is becoming part of GNOME, what can one conclude?
“Is Microsoft injecting software patent poison using so-called ‘proxies’ who try to trivialise the issue?”For all it seems, Miguel de Icaza and his followers continue to put the Microsoft venom not only inside Linux but also inside some BSDs. In his blog, over the past week, Miguel even bragged about Mono running on the Apple iPhone. Similarly, he once pondered Google's Android. A Windows ISV tried to do the same thing to LiMo, which affects many Linux-based phones.
Is Microsoft injecting software patent poison using so-called ‘proxies’ who try to trivialise the issue? If so, how far and wide will it go? It’s not just GNOME anymore and it’s not just GNU/Linux, but everything leads back to the same culprit: Mono. Do remember that Mono is a Novell project and Novell calls Microsoft “a partner”. █
Image contributed by Beranger
Send this to a friend
OOXML: by Microsoft, for Microsoft
The ODF Alliance has some new documents, including this one from Oracle
[PDF] [via Groklaw, Bob Sutor]
There are a number of fairly large scope changes that are the result of proposed changes from Ecma. Worse yet, the actual changes will not be known until some time after the BRM (when the editor releases the final draft), and will not be available for in time for national bodies before they must make a final decision on the specification.
Oracle is not the only company which protests against OOXML at the moment. Other large companies speak out and this includes Google, which comes to show that ODF is not a case of just Sun and IBM (no matter how much the likes of Dennis Byron want it to seem that way). In fact, merely all support for OOXML is paid for by Microsoft. This includes Novell. It’s pseudo-support. It’s manufactured consent.
Out comes Red Hat with its latest protest against OOXML.
As the March 29th voting deadline on OOXML approaches, Red Hat has announced its support of Open Document Format (ODF) instead of Office Open XML (OOXML).
Regardless of the complexity of the specifications, it is thought that OOXML is not currently defined enough to be fully implementable by those without access to inside information. ECMA, for example, acknowledges that additional information is necessary for compatibility with legacy application settings, and promises that the information will be made available. While it’s helpful to acknowledge the limitations of OOXML, we think it is unfair to ask the nation bodies, as members of ISO, to approve an incomplete standard. Given the lack of interoperability and inadequate review, Red Hat is asking members of ISO to vote “No” to OOXML this month.
Mind the fact that Red Hat, Oracle and Google don’t bother to even mention the corruption surrounding OOXML (e.g. [1, 2, 3, 4, 5]). They concentrate on technical aspects alone. So does IBM’s Rob Wier in this latest writeup of his.
I sometimes hear it said that OOXML, or ODF for that matter, are simply XML serializations of particular applications’ native representations. This is said, seemingly, in an attempt to justify quirkiness or outright infelicitous file format representations. “We had not choice. Office 97 did it that way, so OOXML must as well”. This variety of technological determinism indicates poor engineering judgement, laziness or both.
An easy counter-example is HTML. Does HTML reflect the internals of NCSA Mosiac? Does it represent the internals of Netscape Navigator? Firefox? Opera? Safari? Are any faults in HTML justified by what a single browser does internally? Applications should follow standards, not the other way around.
What is the engineering justification for this [OOXML] horror? I have no doubt that this accurately reflects the internals of Microsoft Office, and shows how these three applications have been developed by three different isolated teams. But is this a suitable foundation for an International Standard?
This rhetorical question should only be answered by those who are not paid by Microsoft — either directly or indirectly — to respond or to vote. █
Send this to a friend
Might organisers ever learn to decline sponsorships and reject attendance? Given Microsoft's plan to subvert Free software, they should. But on the face of it, based on the following press release, Microsoft is also intruding Pycon 2008.
Zenoss Joins Google, Microsoft and Sun as Sponsor of Pycon 2008
Microsoft will be there only to serve Microsoft. Recent examples include Java, Eclipse, Apache and OSBC, among many others. Arguments back then were made to show why Microsoft does this (look inside the links for further details). █
Send this to a friend
Making a difference while we still can, for 1234.1233999999999 reasons
Things may seem to have quieted down a bit several days after the BRM in Geneva had ended [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12]. It is not entirely true however. One just needs to look underneath the surface to identify a great deal of activity which is done more discreetly. Microsoft’s lobbying attempts — however gruesome and unethical they may be — have not ground to a halt.
Microsoft New Zealand apparently has what’s called a “director of innovation” who gets somewhat of a media placement in the national press. Very promotional and unnecessary. It also deceives.
There is also the strategic announcement of an SDK (putting the carriage before the pony). Don’t get too excited because it’s all .NET-dependent on the face of it. OOXML is a ‘standard’ candidate from Microsoft, only for Microsoft to control and implement. It is hardly surprising that Novell and the Boys chose to implement OOXML ‘translators’ in C#, bringing to mind the technology which Microsoft "reserves the right to sue" over.
So far in this post we have discussed:
- The legal issues of OOXML
- The ownership issues of OOXML
- The deception surrounding OOXML
We have not yet discussed the corruption which ushered the race for ISO-isation of OOXML.
On we proceed to an actual technical breakdown. The following example is by no means new, but it is probably more detailed than several previous reports. Just consider this serious deficiency in what Microsoft strives to make an international standards. It is one among many other examples. Above all, pay attention to Microsoft’s tactless response. [many thanks to a reader for the pointer]
I dashed off an email to the Microsoft UK PR team asking how Microsoft felt justified in seeking ISO standard status for OOXML when it wasn’t even capable of storing numbers correctly. Go back a few issues for the full blood and gore on this matter, but suffice it to say here that a number such as 1234.1234 is a problem for Excel because of the way the IEEE floating-point number system works.
Type 1234.1234 into Excel and it displays as 1234.1234 correctly. However, save the file as XML and a nasty little secret gets revealed: Excel actually stores it as 1234.1233999999999 in the XML file. I understand that Excel has to deal with IEEE quirks, but I’d like the XML file to interoperate without requiring me to fudge the issue manually, thank you.
No less than the great Jean Paoli replied to my email…: “Excel does have the ability though to store 1234.1234 as 1234.1233999999999 or as 1234.1234 and Open XML of course allows both.”
Woah, holy smoke, Batman. Open XML allows both?
If you believe that OOXML is deficient (which it is), then according to this new page you are encouraged to focus mostly on legal and technical issues found in OOXML, in case you contact your national body. [via Andy Updegrove]
I was at the OOXML BRM in Geneva on behalf of my national body.
If you have strong feelings about the procedures used in the voting (e.g. the O members vs P members debate, or the voting on issues that were not individually discussed):
* Contact your national body
* Describe your concerns (with reference to the appropriate directives, if possible)
* Allegations of corruption are unlikely to convince anyone of anything
* Ask your national body to investigate, and to raise an objection to the process if they are not satisfied
I suspect that most national bodies will prefer communication via email – it’s easier for the NB to distribute it to any relevant committee members. But some people feel that emails are cheap and easy, and sending a letter on paper carries more weight: if you agree, then just be aware that there isn’t very much time before the decision on voting is due.
One thing to point out is the incompatibility of OOXML with the number one rival of Microsoft. Not surprisingly, Gray Knowlton is playing dumb in light of the not-so-accidental exclusion of the GPL, but we have known the truth about this deliberate legal maneuver for quite time time, even before the SFLC had it properly articulated. █
Send this to a friend