If Google has a great app, they can send it to Tmobile for testing and approval.
And if they have a great app for Windows, they should have to get it tested and approved by MSFT first. After all, imagine the support havok it could cause.
If Microsoft did start using patents offensively it would almost certainly end up suing one of its own customers and technology folk the world over would start getting very nervous about their investment in Microsoft software.
Customers and technology folk who aren't already very nervous about their "investment in Microsoft software" either haven't been paying attention or don't have any such "investment".
Personally, I'd use the term "vulnerability" rather than "investment".
From TFA: Though often disparaged by developers, Visual Basic remains one of the world's most commonly used programming languages. According to Forrester Research, 37 percent of enterprises use Microsoft Visual Basic.NET for development and maintenance of their in-house applications. What's more, among.NET developers, 59 percent use Visual Basic.NET as their only programming language. Thus, as of 2006, at least 20 percent of all in-house business programs were still being written in Basic, according to the market analyst firm.
Let's see...37% of enterprises use some VB, 59% of.NET programmers use only VB.NET, so therefore 20% of all bespoke software is in VB?
Ghod, I hope the logic in the programs is better than the logic in that deduction.
The OP said "shift it's priorities" which sounds like English but doesn't parse into anything.
To me it sounds like mumblespeak from the guy who's taken over development of the.Net codebase that NASA has abandoned, and is trying to promote it on Slashdot.
Dogdude says: You haven't spent much time working with lawyers, have you? It's just a CYA.
localman says:The general motivation is to protect the company from lawsuits...So by having these EULAs they can prevent frivolous lawsuits. Fair or not, that's the motivation.
The reason to have a clause in an EULA, or to have an EULA at all, is to intimidate the customer into abandioning rights they might otherwise exercise or otherwise cooerce their behavior. For example, the doctrine of first sale, or as localman points out, the right to sue for failure to perform on implied warranty of merchantibility (which I don't consider a "frivolous lawsuit" if a product has failed to reasonable perform, a judgement for a court to make, not a product support minion).
The only thing that makes such an "agreement" effective is the threat of enforcement...and the forum for that enforcement is the civil courts. "They'd never sue" to enforce a EULA clause is wishful thinking in the extreme; they'd sue the instant that they thought it would advantage them in acquiring maximum revenue.
I can't imagine Microsoft suing a customer over some small print in the EULA. That's just dumb.
Then why is it there?
I hope you don't agree to a lot of contracts relying on a belief that they won't be enforced because "it's just dumb".
This latest corporate fad for retaining a claim to sue while offering a soothing "pledge" not to under vague, unenforceable conditions is lame in the extreme.
Maybe marketters need to make unsubscribing a bit easier and they might not get caught up in service wide filters.
"To unsubscribe, go to our website and edit your preferences with a military-grade password you either don't remeber or never actually set yourself. The 'forgot password' link might actually work, but then again probably not. Why should we care; we'll keep sending you our ads at your expense until you manage to make us stop somehow. Aren't you glad we are *legitimate* spam...I mean...'marketing email'?"
Again, you're looking at similar screen shots and referring to them as identical.
No, I'm not. "Identical" is your word, not mine. My words were "*extremely* close replication" and "deep similarity in appearance in a myriad of essentially non-functional ways".
I'm not saying they didn't add *any* code, clearly at the very least at some point they would have had to make a glue layer compensating for the difference of the hosting environments. And that they added a dialog says nothing about what codebase they started from.
But I think the stark parallels are just far too numerous to be coincidental, and Occam's Razor argues strongly for the "derivative work" theory over the "carefully crafted imitation" theory. After all, if the offshore team had copious time to develop this feature, they could have actually done their own design starting from the *concept* of an object workbench; I doubt they had the luxury of using time to polish the UI to their independently developed tool to look that much like BlueJ just because they admired BlueJ that much.
Again, there has been no compelling evidence whatsoever to even suggest that.
The evidence of my eyes looking at the screen shots, coupled with what I know about programming, compels me. I don't find it plausible that that UI was created any other way. Despite the large number of monkeys and typewriters they have available, when they publish and then try to patent Hamlet, somehow my first thought isn't "Gee, what a coincidence."
YMMV.
In addition, it would be just stupid to decompile the compiled program when you have the full source code available. Are you just adding spurious details to make your comment sound more plausible? Or in an attempt to confuse me and make me go away?
Apparently it is unnecessary to confuse you. And, given your curious persistance in holding forth on an issue about which you don't seem to know very much, I certainly don't expect you to go away.
The decompilation would be how the MSFT minons would have gotten compilable Java source for the BlueJ functionality, since it was pointed out that BlueJ only releases source for the code editor. MSFT would then have pounded it though an automated converter to take Java source to C# source; not a huge jump for typical code.
The source that I proposed disclosing would be their allegedly independantly-developed source that does not map directly to decompiler output from the BlueJ classes, evidence that their tool isn't a deriviative work of BlueJ. Personally, I don't beleive that exists...although I'm sure they could come up with some ex post facto if it was in their interest to do so.
It would benefit them by disproving the obvious supposition that their code is a derivative work.
You're making a common mistake. This isn't about reality. It's about the perception of reality.
Pardon me; out of the profound depths of my naivete I was actually discussing reality.
That reality as I see it is:
1) the code in question was in all probability the output of applying reverse-(decompiling) and forward-(Java-toC# translation) engineering tools to the BlueJ class files and
2) short of a very expensive (and highly unlikely) lawsuit that would force MSFT to disclose their source code during discovery (you know, like the one their sockpuppet SCOX is losing as we speak), we'll never see that code, even though the disclosure would benefit an innocent MSFT, because
3) They're not innocent.
Of course I could be wrong, the offshore MSFT folks named in the patent might actually have carefully hand-coded something that came out looking exactly like BlueJ.
But I know which possibility my money would be on...
Other protestations as to how unMSFTlike such behavior would be are irrelevant to this. Disclosing a fragmentary part of their source code to demonstrate that it actually was independantly developed has nothing to do with open source.
It's not appropriate to accuse me of misdirection when you simply miss the point entirely. That is not my fault... Their business model depends on keeping their source closed...
I dodn't miss your point, I just think it's bogus. Disclosing enough source to demonstrate that this component was independently developed (an otherwise highly implausible proposition) doesn't rise to "endorsing open-source". The disclosed code would not be useful to anyone for any other purpose.
Yeah, I bet I know why too. Because their business model depends on keeping their source closed. Nice FUD though.
To clear up this issue, they could disclose just the relevant source without impacting their "business model" one whit. Nobody's going to use that much code to clone VS.
That's a bunch of nonsense. I mean, it's not impossible...I just made some documents that look amazingly like some other documents in-house (I'm a graphic artist...
That's funny, I'm a programmer...perhaps a *wee* bit more qualified to comment.
I'd say the evidence is circumstantial yet compelling. Of course, as long as the MSFT source is secret there will be no proof one way or the other.
There's a world of difference between deliberately cloning a UI or a document and having deep similarity in appearance in a myriad of essentially non-functional ways just by accident. (Kind of like those perhaps-apocryphal rudder pedals that showed up on the Russian B-29 clone that said "Boeing".)
If MSFT wants to defend themselves from this obvious conclusion (I mean, c'mon, *look* at those screen shots), all they would have to do is release the source code involved. I bet they won't and I bet I know why.
Anyone who thinks this was an innocent mistake in "implementing a suggestion" probably hasn't seen the screenshots comparing The VS screens with BlueJ. ( http://www.bluej.org/vs/vs-bj.html )
Personally, I'm convinced the most plausible explanation for the *extremely* close replication of the BlueJ screens in the MSFT product is that the BlueJ source was ported to C#, probably using an automated tool.
I have no interest in a PDA phone and neither do the vast majority of people.
What's been shown of the iPhone so far surely looks to me like what my Treo 680 "PDA Phone" does. Admitedly it does it very nicely; the engineering is impressive and takes this device class to a new level. But drawing a line between a "PDA phone" and the iPhone is s distinction without a difference.
But "no third-party apps" is a *huge* mistake. And the lame excuse offered for the policy makes both Jobs and Apple look retarded. One wonders if Cingular put the screws to Apple to try to keep a lock on provisioning media to the device.
Were Java developers any better off until the recent open sourcing of Java? Not really. Neither were most independent developers. When you do that work, you are tying part of your future to another company's good will....
Some companies' good will was somewhat more credible than a "one-night stand" even before Java was open-sourced.
Slashdot Mirror
Maybe you live somewhere that your clock ended up locking into CHU, the atomic clock in Canada...
I've never seen a clock that synced from CHU (3.33 MHz and 7.335 MHz)...or from WWV/WWVH (2.5, 5, 10, 15 and 20 MHz), for that matter.
The clocks and watches that feature "atomic time" use the signals from WWVB on 60 KHz.
--
73 de Maggie K3XS
Editor, Phil-Mont Mobile Radio Club Blurb - http://www.phil-mont.org/
Elecraft K2 #1641 -- AOPA 925383 -- ARRL 39280
Insofar as I can tell, JPL has backed the claim that they made the chip; nothing further.
But if it sends the message back home with statistics of how many dont agree, it tells the software company some people dont agree.
I guess "the software company" doesn't read Slashdot, or they'd already know.
If Google has a great app, they can send it to Tmobile for testing and approval.
And if they have a great app for Windows, they should have to get it tested and approved by MSFT first. After all, imagine the support havok it could cause.
Customers and technology folk who aren't already very nervous about their "investment in Microsoft software" either haven't been paying attention or don't have any such "investment".
Personally, I'd use the term "vulnerability" rather than "investment".
If those were a *deliberate* collection of unconnected facts, followed by an unsupported assertion, then they shouldn't say "thus".
I think it's just embarrassingly sloppy thinking.
And don't call me "dude", dude.
From TFA: .NET developers, 59 percent use Visual Basic.NET as their only programming language. Thus, as of 2006, at least 20 percent of all in-house business programs were still being written in Basic, according to the market analyst firm.
.NET programmers use only VB.NET, so therefore 20% of all bespoke software is in VB?
Though often disparaged by developers, Visual Basic remains one of the world's most commonly used programming languages. According to Forrester Research, 37 percent of enterprises use Microsoft Visual Basic.NET for development and maintenance of their in-house applications. What's more, among
Let's see...37% of enterprises use some VB, 59% of
Ghod, I hope the logic in the programs is better than the logic in that deduction.
The OP said "shift it's priorities" which sounds like English but doesn't parse into anything.
.Net codebase that NASA has abandoned, and is trying to promote it on Slashdot.
To me it sounds like mumblespeak from the guy who's taken over development of the
Is there a Mac of Linux version available or are we left out in the cold?
That would appear to be one reason that (as the OP said) NASA is moving to World Wind Java.
Browser marketshare varies widely according to audience. And by audience I mean not just people's interests, but their geographic location.
Not to mention IQ and gullibility index.
Dogdude says: You haven't spent much time working with lawyers, have you? It's just a CYA.
localman says:The general motivation is to protect the company from lawsuits...So by having these EULAs they can prevent frivolous lawsuits. Fair or not, that's the motivation.
The reason to have a clause in an EULA, or to have an EULA at all, is to intimidate the customer into abandioning rights they might otherwise exercise or otherwise cooerce their behavior. For example, the doctrine of first sale, or as localman points out, the right to sue for failure to perform on implied warranty of merchantibility (which I don't consider a "frivolous lawsuit" if a product has failed to reasonable perform, a judgement for a court to make, not a product support minion).
The only thing that makes such an "agreement" effective is the threat of enforcement...and the forum for that enforcement is the civil courts. "They'd never sue" to enforce a EULA clause is wishful thinking in the extreme; they'd sue the instant that they thought it would advantage them in acquiring maximum revenue.
I can't imagine Microsoft suing a customer over some small print in the EULA. That's just dumb.
Then why is it there?
I hope you don't agree to a lot of contracts relying on a belief that they won't be enforced because "it's just dumb".
This latest corporate fad for retaining a claim to sue while offering a soothing "pledge" not to under vague, unenforceable conditions is lame in the extreme.
http://www.bugzilla.org/
Maybe marketters need to make unsubscribing a bit easier and they might not get caught up in service wide filters.
"To unsubscribe, go to our website and edit your preferences with a military-grade password you either don't remeber or never actually set yourself. The 'forgot password' link might actually work, but then again probably not. Why should we care; we'll keep sending you our ads at your expense until you manage to make us stop somehow. Aren't you glad we are *legitimate* spam...I mean...'marketing email'?"
Again, you're looking at similar screen shots and referring to them as identical.
No, I'm not. "Identical" is your word, not mine. My words were "*extremely* close replication" and
"deep similarity in appearance in a myriad of essentially non-functional ways".
I'm not saying they didn't add *any* code, clearly at the very least at some point they would have had to make a glue layer compensating for the difference of the hosting environments. And that they added a dialog says nothing about what codebase they started from.
But I think the stark parallels are just far too numerous to be coincidental, and Occam's Razor argues strongly for the "derivative work" theory over the "carefully crafted imitation" theory. After all, if the offshore team had copious time to develop this feature, they could have actually done their own design starting from the *concept* of an object workbench; I doubt they had the luxury of using time to polish the UI to their independently developed tool to look that much like BlueJ just because they admired BlueJ that much.
Again, there has been no compelling evidence whatsoever to even suggest that.
The evidence of my eyes looking at the screen shots, coupled with what I know about programming, compels me. I don't find it plausible that that UI was created any other way. Despite the large number of monkeys and typewriters they have available, when they publish and then try to patent Hamlet, somehow my first thought isn't "Gee, what a coincidence."
YMMV.
In addition, it would be just stupid to decompile the compiled program when you have the full source code available. Are you just adding spurious details to make your comment sound more plausible? Or in an attempt to confuse me and make me go away?
Apparently it is unnecessary to confuse you. And, given your curious persistance in holding forth on an issue about which you don't seem to know very much, I certainly don't expect you to go away.
The decompilation would be how the MSFT minons would have gotten compilable Java source for the BlueJ functionality, since it was pointed out that BlueJ only releases source for the code editor. MSFT would then have pounded it though an automated converter to take Java source to C# source; not a huge jump for typical code.
The source that I proposed disclosing would be their allegedly independantly-developed source that does not map directly to decompiler output from the BlueJ classes, evidence that their tool isn't a deriviative work of BlueJ. Personally, I don't beleive that exists...although I'm sure they could come up with some ex post facto if it was in their interest to do so.
It would benefit them by disproving the obvious supposition that their code is a derivative work.
You're making a common mistake. This isn't about reality. It's about the perception of reality.
Pardon me; out of the profound depths of my naivete I was actually discussing reality.
That reality as I see it is:
1) the code in question was in all probability the output of applying reverse-(decompiling) and forward-(Java-toC# translation) engineering tools to the BlueJ class files and
2) short of a very expensive (and highly unlikely) lawsuit that would force MSFT to disclose their source code during discovery (you know, like the one their sockpuppet SCOX is losing as we speak), we'll never see that code, even though the disclosure would benefit an innocent MSFT, because
3) They're not innocent.
Of course I could be wrong, the offshore MSFT folks named in the patent might actually have carefully hand-coded something that came out looking exactly like BlueJ.
But I know which possibility my money would be on...
Other protestations as to how unMSFTlike such behavior would be are irrelevant to this. Disclosing a fragmentary part of their source code to demonstrate that it actually was independantly developed has nothing to do with open source.
It's not appropriate to accuse me of misdirection when you simply miss the point entirely. That is not my fault...
Their business model depends on keeping their source closed...
I dodn't miss your point, I just think it's bogus. Disclosing enough source to demonstrate that this component was independently developed (an otherwise highly implausible proposition) doesn't rise to "endorsing open-source". The disclosed code would not be useful to anyone for any other purpose.
Yeah, I bet I know why too. Because their business model depends on keeping their source closed. Nice FUD though.
To clear up this issue, they could disclose just the relevant source without impacting their "business model" one whit. Nobody's going to use that much code to clone VS.
Nice misdirection though.
No; the source to (that part of) BlueJ is not available. There is no way anyone at MS could have got their hands on it.
Decompiling Java classes is so easy a caveman could do it. If he had a computer.
That's a bunch of nonsense. I mean, it's not impossible...I just made some documents that look amazingly like some other documents in-house (I'm a graphic artist...
That's funny, I'm a programmer...perhaps a *wee* bit more qualified to comment.
I'd say the evidence is circumstantial yet compelling. Of course, as long as the MSFT source is secret there will be no proof one way or the other.
There's a world of difference between deliberately cloning a UI or a document and having deep similarity in appearance in a myriad of essentially non-functional ways just by accident. (Kind of like those perhaps-apocryphal rudder pedals that showed up on the Russian B-29 clone that said "Boeing".)
If MSFT wants to defend themselves from this obvious conclusion (I mean, c'mon, *look* at those screen shots), all they would have to do is release the source code involved. I bet they won't and I bet I know why.
Anyone who thinks this was an innocent mistake in "implementing a suggestion" probably hasn't seen the screenshots comparing The VS screens with BlueJ. ( http://www.bluej.org/vs/vs-bj.html )
Personally, I'm convinced the most plausible explanation for the *extremely* close replication of the BlueJ screens in the MSFT product is that the BlueJ source was ported to C#, probably using an automated tool.
I have no interest in a PDA phone and neither do the vast majority of people.
What's been shown of the iPhone so far surely looks to me like what my Treo 680 "PDA Phone" does. Admitedly it does it very nicely; the engineering is impressive and takes this device class to a new level. But drawing a line between a "PDA phone" and the iPhone is s distinction without a difference.
But "no third-party apps" is a *huge* mistake. And the lame excuse offered for the policy makes both Jobs and Apple look retarded. One wonders if Cingular put the screws to Apple to try to keep a lock on provisioning media to the device.
Were Java developers any better off until the recent open sourcing of Java? Not really. Neither were most independent developers. When you do that work, you are tying part of your future to another company's good will....
Some companies' good will was somewhat more credible than a "one-night stand" even before Java was open-sourced.
Seems it isn't evidence of Slashdot culture knowledge, either...
:-)
I know enough about it to know how ironic/oxymoronic the expression "Slashdot culture" is when used by somebody with a UID in the 900K range.