Correct - the Office 2007 formats are not an exact clone of the current draft DIS2900, which has had many changes and amendments made to it as it moves through the ISO process. Which is, after all, a very important part of what the ISO process is for, is it not? Seems to me you are setting up a Catch-22 here: damn MS if they don't completely follow a draft standard which is in constant flux - or damn MS for presenting ISO with a demand to simply ratify the first draft, no changes allowed!
About the corruption - how about Microsoft Sweden and buying of votes?
This is becoming a/. favorite untrue fact. The whole story is: an MS employee wrote an email to two Swedish partner vendors which made it appear that MS would in some way reimburse them for the $2500 cost of joining the Swedish National Body (NB). Within hours Microsoft realized that the phrasing of that mail looked bad, and wrote again to the partner vendors, rescinding any perceived offer and being clear to say that MS would not be paying them in any way to join the NB. MS themselves then reported this gaffe to the Swedish NB. It's very possible that no one would ever have known about the incident if MS had not taken it upon themselves to say (essentially) 'We did this thing. It wasn't our intention to subvert the process, and we have corrected our error, but we want you to be aware of what happened because we know that it could look bad.'
In the end, Sweden's NB invalidated its own vote for different reasons altogether. Even PJ at Groklaw more or less dismissed what otherwise would have been the kind of juicy tidbit she loves to trumpet.
But anyone who wants to disapprove of OOXML had better dot every 'i' and cross every 't' if they want their vote to count
Actually, no. To disapprove OOXML requires only that everyone who voted NO in the first round simply DO NOTHING; their NO vote will in that case be left the same, and OOXML fails the fast track. It really is that simple, and I am amazed at the number of people who "knowledgeably" and negatively comment on a process they apparently know little about.
While there is overreaction and FUD on the part of./ers, you can understand why, given Microsoft's past history.
I sure hope that the lawyers at SFLC (whom I quoted in the post you replied to) feel that the standard for "legal analysis" they publish on the SFLC website should be a few notches above your average/. FUD post!
Funny thing is, he links to the IBM ISP saying that it is exactly the same as the OSP... However, if you follow that link and read the IBM doc, it says nothing about being able to revoke the promise for future versions of the same spec the way the OSP specifically states.
IBM's Interoperability Specifications Pledge (ISP) carefully lists the version of each thing it protects... and you are right, says nothing at all about future or prior versions. So there can be no implied promised about anything other than the versions listed. IBM can 'revoke' (which isn't the proper word, really) future ISP coverage of a spec by simply not listing the later version on that page.
Silverlight runs in any browser on any OS. It could be fairly said that this is a great stride towards openness from Microsoft.
That has nothing to do with openness. Open is the degree which the protocols and code can be viewed and reproduced. Supporting clients on other browsers or OS's is not openess at all, it is just cross-platform support. Unlike openness it provides no assurance that platforms will be supported in future (usually just after MS becomes dominant in a given market).
SFLC is concerned about (the first three lines of italics are SFLC's quotes from the OSP):
New versions of previously covered specifications will be separately considered for addition to the list.
Which is true of any contract. It covers what it covers; doesn't cover the things it doesn't cover. So, if I were to write something and give it away under GPL, then tomorrow add code to it, call it a new version, and not put it under GPL, but rather some other and terrible license... that's fine too. Is it even possible to write a contract which would cover all future work you may or may not ever do?
The OSP does not apply to any work that you do beyond the scope of the covered specification(s).
Err... yeah. As before, the contract covers what it covers. Here it is simply going out of its way to say that it does not cover things which... it doesn't cover. I guess that one was put in there by Microsoft's Department of Redundancy Department. But it basically means that your code which implements the spec is covered under OSP; your code which does other things is not. "Work that you do" is not synomous with "whole programs that you write" - it can be work that you do within a program you write. SFLC seems to have gone out of their way to twist the meaning, here.
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).
This is MS saying they can't give any binding opinion about the legal interpretation of contract written by other entities, in who knows how many jursidictions. I'm resisting the temptation to be sarcastic about SFLC lawyers saying that's somehow bad, or dumb, or... I honestly am not sure what SFLC was trying to imply, there. Anyway - if someone asked you to declare the exact interpretation everyone in the world would give of GPL as it intersects some other license, how would you answer? Meanwhile note the way SFLC cherrypicked even this - their quote comes six paragraphs in the FAQ after MS explicitly states that "It is intended to enable open source implementations..." and just below the SFLC's quote is another question and answer:
Q: I am a developer/distributor/user of software that is licensed under the GPL, does the Open Specification Promise apply to me?
A: Absolutely, yes.
So here's MS saying that they intend for the OSP to be GPL compatible, but they cannot be 100% sure, because, after all... interpretations differ.
I would be very curious what would be the exact minimum corrections SFLC would like MS to make, in order to rectify these concerns they say they have. Because I just don't see any problem here.
There is no place similar to relocate these people (...)
I should've done a quick Google before my prior reply to this. It turns out, relocating is exactly what Kivalina wants to do, and has been trying to do for over a decade:
It is pretty unlikely that their snowmobiles, four-wheelers, and outboard engines (which travel far fewer miles per year than the average American's car does) create more pollution than does the transportation of an average lower-48 American in his/her car, to and from work.
Also, their homes are quite well insulated, and their furnaces as efficient as possible. These people live in the arctic; they understand insulation better than you seem to think.
Subsistence hunting is a very important part of life and the economy in Alaskan villages. It's not just a hobby. Don't knock it until you've spent a few years up there.
These people can function just fine in a city. Please don't make the mistake of considering an Eskimo to be some sort of prehistoric caveman. The fact that they can do so, though, doesn't mean they should.
There are many similar places they could move. A quick look at Google Maps shows the village of Kivalina sitting on a barrier island less than a mile offshore. Barrier islands in coastal Alaska are pretty much constantly subject to the forces of erosion, changing substantially over relatively short periods of time. (IE, it was foolish to locate the village there in the first place!)
Kivalina could move to the mainland within a few miles of its current location. Subsistence hunters would still know the lay of the land very well. But it would cost more than a million dollars per person - a lot more. They would need to rebuild all of the infrastructure of the village - and everything would need to be airlifted or possibly barged in (good luck navigating a ship of any size inside the barrier islands), construction cannot happen year-round, etc.
There are many other villages very much like Kivalina which they could go to if relocating the whole village to a nearby location wasn't a feasible option. There would still be construction and relocation costs, but it'd be less.
The part I find scariest is the 3.5M malware fronts.
Recheck the paper. There were 3.5M bad urls, which through a series of redirects, pointed to only 9340 malware distribution sites (see Table 1, page 8) hosted on systems in only 500 autonomous systems. This is a solvable problem: 500 hosting companies (or their customers) are the source of it all.
In the 10 months of data the researchers used, Google found 9,340 distribution sites. The other 180,000 sites simply redirect you to the the distribution site, which is where you download the malware.
It gets better - those 9340 distribution sites are under the aegis of only 500 autonomous systems. Which means Google could send their list to those 500 AS's - and each would have (on average) around 20 malware sites to clean up. After this, Google could keep notifying AS's of the distribution sites found (less than a thousand a month).
Looks like a very measurable and approacheable problem now! I can't wait for Google's spam report. (They are working on one, aren't they?)
You get smarter, more resourceful people when they are not MSCE drones, but actually programmers that are able to solve a problem, not just relay it up the chain or find the checkbox in the configuration GUI.
Err... wait. Are you saying that all sysadmins should be application developers, and vice-versa?
ZDnet are not a wire outlet - they do their own research as even a cursory read of the article would have shown. I did not claim MS were innocent; I claimed they saw and corrected their error within hours. And you are free to find and quote sources refuting either or both of the articles I linked. Or you could just keep snickering; your call.
Did anyone notice? He linked his earlier Seattle Weekly article, in which he writes:
"And it has created more than 10,000 millionaires from stock options, including me. (I worked for Microsoft from 1991 to 1999 as a technology manager.)"
Ironic, eh? I wonder if he bothered to calculate the percentage of his own money which resulted from the shenanigans he accuses MS of, and gave it to the state?
He did (in the Seattle Weekly article) mention the more than a billion dollars the Gates Foundation has given to Pacific Northwest, and the many charitable donations MS has also made in the area. But he quickly moved on to more of the liberal 'evil M$ fatcats profit on the backs of the poor' rhetoric which Seattle Weekly readers love to read.
The only answer that would surprise me would be "Microsoft."
Be surprised, then. (see above)
They. Were. Buying. Votes. Period.
Except they weren't. Someone sent out a badly-worded email, then realized the mistake and called the recipients to retract the 'offer' hours later. MS management then got involved, promptly contacting SIS (Sweden's national standards body), which ultimately resulted in Sweden abstaining from the ISO vote (rather than voting yes, as it had looked like they were going to do).
As for your EFFI corruption link, correlation != causation. From your linked page:
One should be careful in interpreting the result, though. For example, the statistical test does not naturally tell anything about the reason of the relation between corruption level and voting behaviour of a country; in any case, whatever the reason for the correlation, also some quite uncorrupted countries voted for the approval. And although the trend is interesting and the results informative, the [above] conclusion is still not particularly strong due to a relatively small number of voting countries
Besides a passing reference to 'what happened in Sweden', I didn't see any reference to 'buying votes' in that link, either.
Both IBM and MS encouraged members to join the various ISO committees in different countries.
Did you bother to read the report? Within the Lnux distros given, Jones attempted to weed out things for which there was no direct equivalent in Vista. He admittedly wasn't 100% perfect in this attempt, but he does answer your question. Read the report.
Now of course it wasn't all that far back into last year, where M$ took retaliatory action against a individual how outed them for failing to fix a security fault in Vista. In fact M$ make it a standard procedure to keep these faults secret and will attempt retaliate against anyone who announces a security fault.
Slashdot Mirror
Correct - the Office 2007 formats are not an exact clone of the current draft DIS2900, which has had many changes and amendments made to it as it moves through the ISO process. Which is, after all, a very important part of what the ISO process is for, is it not? Seems to me you are setting up a Catch-22 here: damn MS if they don't completely follow a draft standard which is in constant flux - or damn MS for presenting ISO with a demand to simply ratify the first draft, no changes allowed!
About the corruption - how about Microsoft Sweden and buying of votes?
This is becoming a /. favorite untrue fact. The whole story is: an MS employee wrote an email to two Swedish partner vendors which made it appear that MS would in some way reimburse them for the $2500 cost of joining the Swedish National Body (NB). Within hours Microsoft realized that the phrasing of that mail looked bad, and wrote again to the partner vendors, rescinding any perceived offer and being clear to say that MS would not be paying them in any way to join the NB. MS themselves then reported this gaffe to the Swedish NB. It's very possible that no one would ever have known about the incident if MS had not taken it upon themselves to say (essentially) 'We did this thing. It wasn't our intention to subvert the process, and we have corrected our error, but we want you to be aware of what happened because we know that it could look bad.'
In the end, Sweden's NB invalidated its own vote for different reasons altogether. Even PJ at Groklaw more or less dismissed what otherwise would have been the kind of juicy tidbit she loves to trumpet.
But anyone who wants to disapprove of OOXML had better dot every 'i' and cross every 't' if they want their vote to count
Actually, no. To disapprove OOXML requires only that everyone who voted NO in the first round simply DO NOTHING; their NO vote will in that case be left the same, and OOXML fails the fast track. It really is that simple, and I am amazed at the number of people who "knowledgeably" and negatively comment on a process they apparently know little about.
While there is overreaction and FUD on the part of ./ers, you can understand why, given Microsoft's past history.
I sure hope that the lawyers at SFLC (whom I quoted in the post you replied to) feel that the standard for "legal analysis" they publish on the SFLC website should be a few notches above your average /. FUD post!
Funny thing is, he links to the IBM ISP saying that it is exactly the same as the OSP... However, if you follow that link and read the IBM doc, it says nothing about being able to revoke the promise for future versions of the same spec the way the OSP specifically states.
IBM's Interoperability Specifications Pledge (ISP) carefully lists the version of each thing it protects ... and you are right, says nothing at all about future or prior versions. So there can be no implied promised about anything other than the versions listed. IBM can 'revoke' (which isn't the proper word, really) future ISP coverage of a spec by simply not listing the later version on that page.
Silverlight runs in any browser on any OS. It could be fairly said that this is a great stride towards openness from Microsoft.
That has nothing to do with openness. Open is the degree which the protocols and code can be viewed and reproduced. Supporting clients on other browsers or OS's is not openess at all, it is just cross-platform support. Unlike openness it provides no assurance that platforms will be supported in future (usually just after MS becomes dominant in a given market).
What is MoonLight, Alex?
SFLC is concerned about (the first three lines of italics are SFLC's quotes from the OSP):
New versions of previously covered specifications will be separately considered for addition to the list.
Which is true of any contract. It covers what it covers; doesn't cover the things it doesn't cover. So, if I were to write something and give it away under GPL, then tomorrow add code to it, call it a new version, and not put it under GPL, but rather some other and terrible license ... that's fine too. Is it even possible to write a contract which would cover all future work you may or may not ever do?
The OSP does not apply to any work that you do beyond the scope of the covered specification(s).
Err ... yeah. As before, the contract covers what it covers. Here it is simply going out of its way to say that it does not cover things which ... it doesn't cover. I guess that one was put in there by Microsoft's Department of Redundancy Department. But it basically means that your code which implements the spec is covered under OSP; your code which does other things is not. "Work that you do" is not synomous with "whole programs that you write" - it can be work that you do within a program you write. SFLC seems to have gone out of their way to twist the meaning, here.
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).
This is MS saying they can't give any binding opinion about the legal interpretation of contract written by other entities, in who knows how many jursidictions. I'm resisting the temptation to be sarcastic about SFLC lawyers saying that's somehow bad, or dumb, or ... I honestly am not sure what SFLC was trying to imply, there. Anyway - if someone asked you to declare the exact interpretation everyone in the world would give of GPL as it intersects some other license, how would you answer? Meanwhile note the way SFLC cherrypicked even this - their quote comes six paragraphs in the FAQ after MS explicitly states that "It is intended to enable open source implementations ..." and just below the SFLC's quote is another question and answer:
Q: I am a developer/distributor/user of software that is licensed under the GPL, does the Open Specification Promise apply to me?
A: Absolutely, yes.
So here's MS saying that they intend for the OSP to be GPL compatible, but they cannot be 100% sure, because, after all ... interpretations differ.
I would be very curious what would be the exact minimum corrections SFLC would like MS to make, in order to rectify these concerns they say they have. Because I just don't see any problem here.
MS is obviously not going to give away filesystem specs or the other interoperability roadblocks ...
Really? You might want to ask Andrew Tridgell over at the Samba project about that. It seems he has gotten exactly that from MS. In such a way that he can show it to anyone who joins the Protocol Freedom Information Foundation.
There is no place similar to relocate these people (...)
I should've done a quick Google before my prior reply to this. It turns out, relocating is exactly what Kivalina wants to do, and has been trying to do for over a decade:
"Due to severe erosion, the City intends to relocate to a new site 7.5 miles away. Funds have been provided by various federal and state agencies since the early 1990s to assess relocation options and to design and engineer the new site."
This lawsuit is likely a ploy to help secure awareness and funding for the relcation.
Kivalina Relocation Master Plan Final Report '06.
It is pretty unlikely that their snowmobiles, four-wheelers, and outboard engines (which travel far fewer miles per year than the average American's car does) create more pollution than does the transportation of an average lower-48 American in his/her car, to and from work.
Also, their homes are quite well insulated, and their furnaces as efficient as possible. These people live in the arctic; they understand insulation better than you seem to think.
Subsistence hunting is a very important part of life and the economy in Alaskan villages. It's not just a hobby. Don't knock it until you've spent a few years up there.
These people can function just fine in a city. Please don't make the mistake of considering an Eskimo to be some sort of prehistoric caveman. The fact that they can do so, though, doesn't mean they should.
There are many similar places they could move. A quick look at Google Maps shows the village of Kivalina sitting on a barrier island less than a mile offshore. Barrier islands in coastal Alaska are pretty much constantly subject to the forces of erosion, changing substantially over relatively short periods of time. (IE, it was foolish to locate the village there in the first place!)
Kivalina could move to the mainland within a few miles of its current location. Subsistence hunters would still know the lay of the land very well. But it would cost more than a million dollars per person - a lot more. They would need to rebuild all of the infrastructure of the village - and everything would need to be airlifted or possibly barged in (good luck navigating a ship of any size inside the barrier islands), construction cannot happen year-round, etc.
There are many other villages very much like Kivalina which they could go to if relocating the whole village to a nearby location wasn't a feasible option. There would still be construction and relocation costs, but it'd be less.
The part I find scariest is the 3.5M malware fronts.
Recheck the paper. There were 3.5M bad urls, which through a series of redirects, pointed to only 9340 malware distribution sites (see Table 1, page 8) hosted on systems in only 500 autonomous systems. This is a solvable problem: 500 hosting companies (or their customers) are the source of it all.
In the 10 months of data the researchers used, Google found 9,340 distribution sites. The other 180,000 sites simply redirect you to the the distribution site, which is where you download the malware.
It gets better - those 9340 distribution sites are under the aegis of only 500 autonomous systems. Which means Google could send their list to those 500 AS's - and each would have (on average) around 20 malware sites to clean up. After this, Google could keep notifying AS's of the distribution sites found (less than a thousand a month).
Looks like a very measurable and approacheable problem now! I can't wait for Google's spam report. (They are working on one, aren't they?)
You get smarter, more resourceful people when they are not MSCE drones, but actually programmers that are able to solve a problem, not just relay it up the chain or find the checkbox in the configuration GUI.
Err ... wait. Are you saying that all sysadmins should be application developers, and vice-versa?
... MS has less than 39.7% of whatever markets MS happens to be in.
Sigh
ZDnet are not a wire outlet - they do their own research as even a cursory read of the article would have shown. I did not claim MS were innocent; I claimed they saw and corrected their error within hours. And you are free to find and quote sources refuting either or both of the articles I linked. Or you could just keep snickering; your call.
See 22245086.
Did anyone notice? He linked his earlier Seattle Weekly article, in which he writes:
Ironic, eh? I wonder if he bothered to calculate the percentage of his own money which resulted from the shenanigans he accuses MS of, and gave it to the state?
He did (in the Seattle Weekly article) mention the more than a billion dollars the Gates Foundation has given to Pacific Northwest, and the many charitable donations MS has also made in the area. But he quickly moved on to more of the liberal 'evil M$ fatcats profit on the backs of the poor' rhetoric which Seattle Weekly readers love to read.
Oh, look, I used no evidence to back up my claims too!
...just thought I'd emphasize that little parity bit. Please note I did use evidence to back my own claims.
The only answer that would surprise me would be "Microsoft."
Be surprised, then. (see above)
They. Were. Buying. Votes. Period.
Except they weren't. Someone sent out a badly-worded email, then realized the mistake and called the recipients to retract the 'offer' hours later. MS management then got involved, promptly contacting SIS (Sweden's national standards body), which ultimately resulted in Sweden abstaining from the ISO vote (rather than voting yes, as it had looked like they were going to do).
Errr, your research leaves something to be desired.
Microsoft reported the Sweden situation themselves. And they did so within hours of the so-called 'vote promise' email.
As for your EFFI corruption link, correlation != causation. From your linked page:
Besides a passing reference to 'what happened in Sweden', I didn't see any reference to 'buying votes' in that link, either.
Both IBM and MS encouraged members to join the various ISO committees in different countries.
Who caught them?
Go look it up. You might be surprised by the answer.
look for them you bloody self
Which is shorthand for "I don't have any I'm proud enough to link.", I think.
Did you bother to read the report? Within the Lnux distros given, Jones attempted to weed out things for which there was no direct equivalent in Vista. He admittedly wasn't 100% perfect in this attempt, but he does answer your question. Read the report.
Now of course it wasn't all that far back into last year, where M$ took retaliatory action against a individual how outed them for failing to fix a security fault in Vista. In fact M$ make it a standard procedure to keep these faults secret and will attempt retaliate against anyone who announces a security fault.
Got any links or proof?