Point taken, I got sidetracked in my response. But I think that my core point still holds up - here's a different hypothetical: I could imagine that a court would rule that beacause the GPL doesn't specify in all cases how the license transfers that it's unenforcable and then throws it out.
We just don't know, and won't until it's adjudicated.
Boy, I can tell you're not a lawyer. Unless it's been ajudicated in a court of law, it doesn't count.
Every IP lawyer I know (and I know several) advises their clients to stay away from writing or contributing to GPL projects, especially if the client sells closed source products as well. If their client's business model revolves around selling services based on those GPL projects, it's probably ok, but if the any part of the client's business model involves selling licenses to software products, it's not clear how wide the GPL can spread.
Let me give you a hypothetical example. Consider an open source product that has a plugin model (could be Gimp, could be Firefox, whatever). In order to write a plugin for that product, I need to include a GPLed header that describes the plugin interface. By including that header, does it mean that I'm required to open source my plugin?
The answer is that nobody knows, because it's never been adjudicated. Lawyers have opinions about it, but until a judge has ruled on it, they're just opinions[1].
Given that nobody knows, if there's important intellectual property behind that plugin (maybe it's a 3d rendering algorithm, some nifty DSP for audio, whatever), any competent lawyer would advise their client to stay away from authoring that plugin - it's safer to stick with products that have non viral licenses, otherwise you run the risk of being forced to open source your entire product just because you included a public header.
[1]To a lawer, an "opinion" is a statement of their understanding of the law (whereas an "opinion" to a lay person is a statement of belief).
I'm confused. Both HD-DVD and BluRay include Microsoft's VC-1 codec as a manditory-to-implement codec. So any device capable of decoding either of the two high-definition DVD formats is required to include a Microsoft codec. Why is this any different?
Even MP3 isn't an "open standard" - it's protected by a series of patents that are owned by various corporations (AT&T, Freunhoffer), so would the BBC be precluded from distributing its content via MP3s?
Actually, the reason I was surprised at the HTML fuzzing DoS issues is exactly because of the first DoS you mentioned.
In that example, Michel Zalewski fuzzed FF and blew it out of the water - it made news because IE was slightly more resiliant (FF died after minutes of fuzzing, IE took a couple of hours).
I would hope that Apple's security people are monitoring FD and Bugtraq to keep up with the latest incidents and that before they thought to release a web browser that they'd fuzz test their browser.
The breach of privacy issue seems to have been intentional, I can't speak to the 3rd issue.
And none of these issues were shown to be remotely exploitable.
The problems that were found were found by fuzzing HTML output. That's not platform specific.
And similarly, the canonicalization failure handling iframes is not platform specific. Apple knew about the potential for exploitation of that particular vulnerability, they mitigated it for basic links, but didn't when the link was in an iframe. So again it's not platform specific.
Really? Back when Firefox 1.0 and IE 1.0 were written, the web wasn't a hostile environment. The problems reported here are fairly basic issues (canonicalization problems while handling protocol handlers are VERY old news).
These are the kinds of problems that I'd expect novice developers building their very first stumbling attempts at a web browser client, NOT the result of code that a seasoned team of developers who have a long history of experience with the web. And certainly not in a browser that's considered "Beta" quality.
After all, Apple says "Apple engineers designed Safari to be secure from day one."
Why would building a web browser for Windows be any harder than building a web browser for OSX or Linux? Before you answer "because windoze sux", consider the fact that the Firefox and Opera people don't seem to have had a problem building a rock solid secure browser for Windows. And as far as I know, Firefox and Opera have both been pretty darned secure since day 1.
Could you imagine the screams of outrage if Microsoft, Mozilla or Opera would have released a beta browser with those kinds of problems?
Think about it - whileit's unquestionable that both Thor and David are very talented hackers, but they both indicated that they didn't even look very hard to find the problems they found.
The stacker lawsuit wasn't a copyright lawsuit, it was a patent lawsuit.
According to the Wikipedia, they claimed that Microsoft's compression technology copied their patented compression technology. Microsoft claimed that their compression technology didn't infringe. A jury disagreed and Microsoft lost.
There was no code copied anywhere, it was purely a software patent issue.
If the iPhone plans on taking on the Crackberry, then it's GOT to be useful for business. The thing that makes the Crackberry sell like crazy is that it sync's seamlessly with most business email systems.
If the iPhone can't do that, ultimately it will be relegated to a vanity toy.
Think about it - I know a bunch of people who are totally addicted their crackberries, will they really switch to the iPhone? Does the iPhone provide enough value to convince them to ditch their crackberry given that they'll lose 24x7 access to their email?
If the iPhone can't sync with corporate email systems seamlessly, then it's going to become a vanity toy and not the powerhouse that Apple (and the Apple fanboys) want it to be.
It's my understanding that most modern operating systems have essentially the same memory management underpinnings - historically *nix and Windows had different memory management models, but *nix has evolved over time from the 1960's style swap() mechanism to a modern VM system that is effectively the same as the Windows VM system (which was designed for systems with modern VM architectures). It's a tribute to the modularity of *nix that it's been able to survive such a major transformation untouched.
According to this blog post, what you're describing is called "standby list erosion" where a number of low priority applications can (over time) cause the foreground application to swap out. According to that post, it should be fixed in Vista.
The problem is that for some people, functionality trumps security every time. It's unfortunate, but true.
Sometime around 2002ish, Microsoft learned (the hard way) that functionality can NEVER trump security, and they've spent the better part of the past 5 years working on fixing the mistakes they made back in the 1990s (when functionality trumped security). You can see the fruits of that in their most recent offerings (IIS6 has had no exploitable holes in the 4 years it's been available, Vista, for all of its compatibility problems has already been shown to be dramatically better than XP was security-wise).
Until all the vendors "get it" and realize that security should win, stuff like this is going to continue to happen.
Even selling used CDs hasn't come under fire. There are plenty of record stores that buy and sell CDs.
Except in Florida and Utah, where it is apparently extremely difficult to sell a used CD. It's not quite illegal, but stores are apparently required to fingerprint all CD sellers, and maintain records for 3 years.
As far as I can tell, there have only been something like 3 different changes to the office.DOC file format over the past 10+ years, that's not actually a bad track record (from what I could tell on Wikipedia, the only 3 versions of the.DOC file format were: WindWord Word '97, Word 97..Word2003, and OOXML). That's not very much of a treadmill, IMHO.
To me, the nice thing about OOXML and ODF is that they provide a relatively clear upgrade path for extensibility - assuming that the extensions don't change the basic semantics of the document, and that an application simply preserves intact those portions of the document that it doesn't understand (I know that these are both HUGE caveats), both ODF and OOXML have the ability of producing a stable document platform that can be enhanced over the future.
In addition, many developers are not permitted to read OpenOffice's code (because of the GPL).
For instance, many developers working closed source projects are prohibited from looking at open source code because it's possible that they might accidentally introduce GPL'ed code into the close source, which might force the closed source code to be open sourced.
The GPL is the kind of thing that gives corporate lawyers nightmares.
Read the Brian Jones article. Microsoft chose to describe (but not define) ALL of the elements produced by Office 12. OpenOffice chose to neither describe or define many of the elements produced by OpenOffice, describing them as "extensions".
Which is better: A fully described (but not fully defined) specification or a partially described but fully defined specification (assuming, of course that ODF is fully defined (it's not totally clear that it is (see the office:binary-data element in the ODF specification))?
You mean like these legacy tags that only OpenOffice can implement? (yeah, I know it's a Microsoft site, but the only other reference I was able to find was this/. post).
According to Microsoft, the only way those legacy tags will ever be found is if they came from a document that was created by an old version of Office. So it should be really easy to verify if current versions of office ever produce those "legacy" tags.
That's silly, the two most common types of DRM used on Windows aren't Microsoft's formats at all, one is Fairplay (owned by Apple), the other is CSS (owned by the DVD Copy Control Corporation).
DRM is there because if DRM wasn't there, you'd not be able to play DVDs, HDDVDs or BlueRay discs on Windows. The owners of those formats don't care about Windows, they're more interested in the consumer electronics manufacturers. And every single one of the consumer electronics vendors is more than happy to put whatever DRM the *AA wants.
Microsoft could say F-You to the *AA, the result would be that the *AA would simply take its toys and go home - or go to Apple or Sony, who have already made it quite clear that they're more than willing to put whatever DRM that the *AA wants in its products.
Not only is it allowed to have different prices for the same product in different states, but also for the same product in different counties, different cities, different blocks, or different addresses in the same block. This works, as long as people are able to shop around and freely purchase at the lowest price. The problem then is the contractural requirement that iTunes customers can only purchase from the iTunes store for their own country.
W.R.T. your assertion of pricing differently based on "different blocks or different addresses in the same block". In the US, this is often illegal, it's a practice called redlining.
W.R.T. the parent's assertion that the EU isn't a country, for economic purposes, the EUis a single country, and thus the NY vs NJ argument is valid.
From the list (http://projects.info-pull.com/moab/): 1 and 3 were in quicktime (an apple product, but not Mac specific) 4 was in iLife (mac specific) 9, 10, 11, 12, and 13 were related to loading.DMG files, which are Mac specific. 14 was in appletalk 15 was in the permissions on the/Applications directory 23 was in QuickDraw (mac specific) 24 was in the Mac auto-update logic 28 was in the crash dump handling logic 29, and 30 were in various Mac specific utilities (iChat, Safari, HelpViewer).
I don't think that's "a significant minority". By my guestimate, 5 of the 30 were in 3rd party apps.
Has he EVER refered to those as "security features"? I'd be surprised, Michael Howard doesn't usually make those kinds of mistakes.
Usually those are described as mitigations, since there are no security guarantees associated with them (since they can be bypassed, they're not security features.
Apparently the standard for "Conflict" was "Renders another standard unimplementable".
As best as I can see, the fact that OOXML treats 1900 as a leap year doesn't prevent another standard from treating 1900 as a non leap year.
The contradictions phase wasn't intended to resolve issues, but to highlight grotesque flaws. Apparently they decided that the date issue (and the other issues brought up) weren't grotesque flaws.
Slashdot Mirror
Point taken, I got sidetracked in my response. But I think that my core point still holds up - here's a different hypothetical: I could imagine that a court would rule that beacause the GPL doesn't specify in all cases how the license transfers that it's unenforcable and then throws it out.
We just don't know, and won't until it's adjudicated.
Boy, I can tell you're not a lawyer. Unless it's been ajudicated in a court of law, it doesn't count.
Every IP lawyer I know (and I know several) advises their clients to stay away from writing or contributing to GPL projects, especially if the client sells closed source products as well. If their client's business model revolves around selling services based on those GPL projects, it's probably ok, but if the any part of the client's business model involves selling licenses to software products, it's not clear how wide the GPL can spread.
Let me give you a hypothetical example. Consider an open source product that has a plugin model (could be Gimp, could be Firefox, whatever). In order to write a plugin for that product, I need to include a GPLed header that describes the plugin interface. By including that header, does it mean that I'm required to open source my plugin?
The answer is that nobody knows, because it's never been adjudicated. Lawyers have opinions about it, but until a judge has ruled on it, they're just opinions[1].
Given that nobody knows, if there's important intellectual property behind that plugin (maybe it's a 3d rendering algorithm, some nifty DSP for audio, whatever), any competent lawyer would advise their client to stay away from authoring that plugin - it's safer to stick with products that have non viral licenses, otherwise you run the risk of being forced to open source your entire product just because you included a public header.
[1]To a lawer, an "opinion" is a statement of their understanding of the law (whereas an "opinion" to a lay person is a statement of belief).
I'm confused. Both HD-DVD and BluRay include Microsoft's VC-1 codec as a manditory-to-implement codec. So any device capable of decoding either of the two high-definition DVD formats is required to include a Microsoft codec. Why is this any different?
Even MP3 isn't an "open standard" - it's protected by a series of patents that are owned by various corporations (AT&T, Freunhoffer), so would the BBC be precluded from distributing its content via MP3s?
Actually, the reason I was surprised at the HTML fuzzing DoS issues is exactly because of the first DoS you mentioned.
In that example, Michel Zalewski fuzzed FF and blew it out of the water - it made news because IE was slightly more resiliant (FF died after minutes of fuzzing, IE took a couple of hours).
I would hope that Apple's security people are monitoring FD and Bugtraq to keep up with the latest incidents and that before they thought to release a web browser that they'd fuzz test their browser.
The breach of privacy issue seems to have been intentional, I can't speak to the 3rd issue.
And none of these issues were shown to be remotely exploitable.
The problems that were found were found by fuzzing HTML output. That's not platform specific.
And similarly, the canonicalization failure handling iframes is not platform specific. Apple knew about the potential for exploitation of that particular vulnerability, they mitigated it for basic links, but didn't when the link was in an iframe. So again it's not platform specific.
nuf said.
Really? Back when Firefox 1.0 and IE 1.0 were written, the web wasn't a hostile environment. The problems reported here are fairly basic issues (canonicalization problems while handling protocol handlers are VERY old news).
These are the kinds of problems that I'd expect novice developers building their very first stumbling attempts at a web browser client, NOT the result of code that a seasoned team of developers who have a long history of experience with the web. And certainly not in a browser that's considered "Beta" quality.
After all, Apple says "Apple engineers designed Safari to be secure from day one."
Why would building a web browser for Windows be any harder than building a web browser for OSX or Linux? Before you answer "because windoze sux", consider the fact that the Firefox and Opera people don't seem to have had a problem building a rock solid secure browser for Windows. And as far as I know, Firefox and Opera have both been pretty darned secure since day 1.
Could you imagine the screams of outrage if Microsoft, Mozilla or Opera would have released a beta browser with those kinds of problems?
Think about it - whileit's unquestionable that both Thor and David are very talented hackers, but they both indicated that they didn't even look very hard to find the problems they found.
The stacker lawsuit wasn't a copyright lawsuit, it was a patent lawsuit.
According to the Wikipedia, they claimed that Microsoft's compression technology copied their patented compression technology. Microsoft claimed that their compression technology didn't infringe. A jury disagreed and Microsoft lost.
There was no code copied anywhere, it was purely a software patent issue.
If the iPhone plans on taking on the Crackberry, then it's GOT to be useful for business. The thing that makes the Crackberry sell like crazy is that it sync's seamlessly with most business email systems.
If the iPhone can't do that, ultimately it will be relegated to a vanity toy.
Think about it - I know a bunch of people who are totally addicted their crackberries, will they really switch to the iPhone? Does the iPhone provide enough value to convince them to ditch their crackberry given that they'll lose 24x7 access to their email?
If the iPhone can't sync with corporate email systems seamlessly, then it's going to become a vanity toy and not the powerhouse that Apple (and the Apple fanboys) want it to be.
It's my understanding that most modern operating systems have essentially the same memory management underpinnings - historically *nix and Windows had different memory management models, but *nix has evolved over time from the 1960's style swap() mechanism to a modern VM system that is effectively the same as the Windows VM system (which was designed for systems with modern VM architectures). It's a tribute to the modularity of *nix that it's been able to survive such a major transformation untouched.
According to this blog post, what you're describing is called "standby list erosion" where a number of low priority applications can (over time) cause the foreground application to swap out. According to that post, it should be fixed in Vista.
The problem is that for some people, functionality trumps security every time. It's unfortunate, but true.
Sometime around 2002ish, Microsoft learned (the hard way) that functionality can NEVER trump security, and they've spent the better part of the past 5 years working on fixing the mistakes they made back in the 1990s (when functionality trumped security). You can see the fruits of that in their most recent offerings (IIS6 has had no exploitable holes in the 4 years it's been available, Vista, for all of its compatibility problems has already been shown to be dramatically better than XP was security-wise).
Until all the vendors "get it" and realize that security should win, stuff like this is going to continue to happen.
Listen to the linked NPR article (it ran just a couple of days ago). Apparently it was a part of an attempt to crack down on pawn shops etc.
Except in Florida and Utah, where it is apparently extremely difficult to sell a used CD. It's not quite illegal, but stores are apparently required to fingerprint all CD sellers, and maintain records for 3 years.
As far as I can tell, there have only been something like 3 different changes to the office .DOC file format over the past 10+ years, that's not actually a bad track record (from what I could tell on Wikipedia, the only 3 versions of the .DOC file format were: WindWord Word '97, Word 97..Word2003, and OOXML). That's not very much of a treadmill, IMHO.
To me, the nice thing about OOXML and ODF is that they provide a relatively clear upgrade path for extensibility - assuming that the extensions don't change the basic semantics of the document, and that an application simply preserves intact those portions of the document that it doesn't understand (I know that these are both HUGE caveats), both ODF and OOXML have the ability of producing a stable document platform that can be enhanced over the future.
OOXML can represent, with full fidelity, any existing Microsoft Office document. ODF can't.
.DOC to OOXML and then back, which allows them to avoid security bugs in the parser. You can't do that with ODF because ODF can't represent those older files.
This in turn lets Microsoft do things like using OOXML as an intermediate format and translate all files from
Yeah, because those open document formats are 100% safe from coding bugs in the applications that parse them.
And unquestionably OpenOffice is immune to parsing errors.
In addition, many developers are not permitted to read OpenOffice's code (because of the GPL).
For instance, many developers working closed source projects are prohibited from looking at open source code because it's possible that they might accidentally introduce GPL'ed code into the close source, which might force the closed source code to be open sourced.
The GPL is the kind of thing that gives corporate lawyers nightmares.
Read the Brian Jones article. Microsoft chose to describe (but not define) ALL of the elements produced by Office 12. OpenOffice chose to neither describe or define many of the elements produced by OpenOffice, describing them as "extensions".
Which is better: A fully described (but not fully defined) specification or a partially described but fully defined specification (assuming, of course that ODF is fully defined (it's not totally clear that it is (see the office:binary-data element in the ODF specification))?
You mean like these legacy tags that only OpenOffice can implement? (yeah, I know it's a Microsoft site, but the only other reference I was able to find was this /. post).
According to Microsoft, the only way those legacy tags will ever be found is if they came from a document that was created by an old version of Office. So it should be really easy to verify if current versions of office ever produce those "legacy" tags.
That's silly, the two most common types of DRM used on Windows aren't Microsoft's formats at all, one is Fairplay (owned by Apple), the other is CSS (owned by the DVD Copy Control Corporation).
DRM is there because if DRM wasn't there, you'd not be able to play DVDs, HDDVDs or BlueRay discs on Windows. The owners of those formats don't care about Windows, they're more interested in the consumer electronics manufacturers. And every single one of the consumer electronics vendors is more than happy to put whatever DRM the *AA wants.
Microsoft could say F-You to the *AA, the result would be that the *AA would simply take its toys and go home - or go to Apple or Sony, who have already made it quite clear that they're more than willing to put whatever DRM that the *AA wants in its products.
W.R.T. your assertion of pricing differently based on "different blocks or different addresses in the same block". In the US, this is often illegal, it's a practice called redlining.
W.R.T. the parent's assertion that the EU isn't a country, for economic purposes, the EU is a single country, and thus the NY vs NJ argument is valid.
They have. It's published here
They also have guides for OSX and Solaris.
From the list (http://projects.info-pull.com/moab/): .DMG files, which are Mac specific. /Applications directory
1 and 3 were in quicktime (an apple product, but not Mac specific)
4 was in iLife (mac specific)
9, 10, 11, 12, and 13 were related to loading
14 was in appletalk
15 was in the permissions on the
23 was in QuickDraw (mac specific)
24 was in the Mac auto-update logic
28 was in the crash dump handling logic
29, and 30 were in various Mac specific utilities (iChat, Safari, HelpViewer).
I don't think that's "a significant minority". By my guestimate, 5 of the 30 were in 3rd party apps.
Has he EVER refered to those as "security features"? I'd be surprised, Michael Howard doesn't usually make those kinds of mistakes.
Usually those are described as mitigations, since there are no security guarantees associated with them (since they can be bypassed, they're not security features.
Apparently the standard for "Conflict" was "Renders another standard unimplementable".
As best as I can see, the fact that OOXML treats 1900 as a leap year doesn't prevent another standard from treating 1900 as a non leap year.
The contradictions phase wasn't intended to resolve issues, but to highlight grotesque flaws. Apparently they decided that the date issue (and the other issues brought up) weren't grotesque flaws.
Go figure.