As I was saying: it's a loophole from the point of view of the people who designed the GPL.
You're entitled to your opinion that other licenses are better and that this kind of "lockdown" is appropriate. I would wish that people like you would have the intellectual honesty not to hide behind the GPL then, though. If you truly believe that that kind of behavior is OK, then please use a license other than the GPL license.
So let's make this simple. In case you actually want to try to respond or continue this discussion in any way, I propose this: Read the following statements.
* Redhat pays programmers and fund projects
* Code written by Redhat-paid programmers and written in Redhat-funded projects exists in both Redhat and other Linux distributions * Redhat pays these programmers and funds these projects with profits generated from sales of Redhat products
In your next reply, please tell me where there are inaccuracies in one or more of these 3 statements. Back up your statements with something resembling an argument or proof.
There is nothing inaccurate about those statements; the statements are simply not what you originally claimed. What you originally claimed is:
What I find surprising is that, in the few responses I've skimmed (including yours), I haven't seen anyone mention that these companies need to pay programmers.
You were saying not just that these companies pay programmers (which they do), but that these companies "need" to pay programmers; in the context of this discussion, "need" means that if they didn't do that, open source could not succeed. Well, you have failed to show that. In fact, your claim is preposterous in light of "common facts and common knowledge".
That may sound a bit harsh, but it's only hard if you're a moron.
That may sound a bit harsh, but that's the group Apple targets as their customers: people who don't know much about computers. These measures prevent Apple's user community quite effectively from moving data back and forth freely.
through iTunes if the "other" computer is allowed to read these files - the copy prevention only applies to non-DRM'd files.
My point exactly: Apple has taken a variety of technological and UI measures to make it difficult to move stuff around. That's in contrast to other MP3 players that make it very easy to move stuff around. Heck, I can plug my no-name Chinese MP3 player into another no-name Chinese MP3 player and exchange any file I want, easily and without a Ph.D. in computer science. But my iPod makes all the things Apple doesn't want me to do hard--deliberately.
If a country decides to do something they'll just rewrite their own laws to allow it. If someone decides to ignore the UN or what not then it's not "illegal".
The term "illegal" is not usually applied to violations of international law. Nevertheless, such violations are often considered immoral, and they often have severe consequences.
I would rather have the treaties. I actually do trust the experts more than people the environmental groups.
We have treaties. They say that Bush shouldn't do what he is doing. They have one problem: they are international, and, of course, Bush feels under no obligation to observe international treaties since, after all, those people didn't elect him and he can drum up enough xenophobia to support breaking the treaties. So, treaties don't control Bush or what the US is doing.
Bush's policy effectively states that the usage of nuclear power as engines of exploration is considered to take priority over any over-reaching treaties that ban nuclear power for the purposes of weaponry.
You don't seriously believe that Bush gives a damn about exploration, do you? Bush wants to put nuclear weapons into space, and nuclear reactors for powering other kinds of weapons.
In any case, this policy is complete and utter stupidity. If the US starts putting nuclear reactor, beam weapons, and nuclear bombs into space, so will other nations. Do you really think that France is going to sit by and let the US weaponize space without getting their own weapons up there? Do you really want a Chinese satellite flying overhead that can destroy any US city with no warning within seconds? Because that's where things are heading: a space arms race.
And in the end, huge amounts of tax money is going to be wasted (of course, it's going to be wasted on Bush's corporate buddies), and there's going to be a bunch of weapon systems that can't realistically be used, yet still decrease our security because they can fall into the wrong hands (remember: they're all remotely controlled by computer).
The environmental groups protest everything with involving the "n word".
Yes, and they should: the disposal issue has not been solved. All nuclear waste that is being generated is piling up in "temporary" locations. Furthermore, the way we use nuclear fuel right now is an irresponsible waste, since we're using only a few percent of the power that's contained in it. That way, fuel that should last several millennia is going to last less than a century.
If the US were to switch to breeder reactors that demonstrably eliminate most of the nuclear waste, you'd see a lot less opposition.
Re:Gyroscopic stabilizers
on
Rocket Men
·
· Score: 1
You don't need stabilizing gyros, just decent control of the individual nozzles and gyroscopic sensors. think "Segway": it doesn't stabilize with gyros, it stabilizes with electronic control.
That's not a loophole at all -- the loophole is that you can lock down the CPU to only run signed code and this has nothing to do with Linux at all.
It's a loophole from the point of view of the people who wrote the GPL, and it's getting fixed in GPLv3. That is, you may be technically able to "lock down the CPU", but you will not be permitted to run GPLv3 code on that kind of hardware.
If you've written an app that links to GPL libraries, I don't believe it falls under the GPL requirements to release the source
Merely linking doesn't cause it to fall under the GPL. However, if you distribute the linked binary, you are distributing code under the GPL, and you only have permission if all the code that is linked to it is also distributed under the GPL.
If that were the case, you'd never see apps on Linux like Oracle or whatnot.
Oracle's code is not linked with the kernel, and libc isn't under a (strict) GPL license, so the GPL doesn't require Oracle to distribute the sources to their code.
The GPL is only required (i.e., only applicable) when copyright is involved; i.e., making a derivative work.
That's not true. You accept licenses in return for being allowed to copy the code. The license you accept is just a contract, and a contract can say pretty much whatever it wants to. It can impose requirements on you that have nothing to do with copying the code or derivative works. Many licenses, for example, require you to open your wallet and transfer money to someone else. Other licenses require you to adopt specific kinds of marketing--telling your buyers that your software uses other software, or not telling them. Microsoft's shared source and Qt's old source licenses also impose lots of requirements on code that use the library.
The GPL happens to be designed such that it imposes relatively few requirements that don't relate to copying and distributing the code, but that's by choice, not by legal necessity.
you'll see that code dictated by external requirements (i.e., pretty much every piece of software running on a UNIX/Linux system has to use malloc, etc., and thus must either call the system calls directly or via the C Library) is specifically filtered out of the copyright comparison.
Correct. And what that means is that your code doesn't violate any Linux copyrights merely by using Linux header files. However, the Linux kernel license could still impose restrictions on how you use your code and the Linux kernel together, because in order to use them together, you have to copy the Linux kernel, and you cannot do that without agreeing to the terms of the Linux kernel license.
No Company would ever enter into any agreement where they invest a large some of money like they did without a CONTRACT.
Sure they would: if they have even bigger contracts for something else and are doing this as a favor. That sort of thing happens all the time. In fact, Baystar isn't the first company to be forced by Microsoft to act against their own interests in this way.
According to the article, Microsoft didn't fund anything.
They provided a guarantee; that pretty much amounts to the same thing.
I find it hilarious that someone took a for-profit corporation at their word with no contract
Baystar likely has other business relationships with Microsoft; that's all the leverage Microsoft needs. That sort of thing happens all the time in business.
but you can certainly detect code which may result in unintended behaviour
Yes, you can. But those kinds of detectors are not useful for comparing software quality, at least not without a lot more statistical analysis, which is missing from Coverity's report.
Run lint against a bunch of source code and you'll see what I'm talking about.
There are many essentially bug-free pieces of software I have that lint gives thousands of errors on. And I've checked in plenty of buggy code that passes lint. Tools like lint can be useful, but using them as a measure of software quality is inappropriate.
Coverity's customers probably have near-zero Coverity errors, but that doesn't make their code bug-free. Conversely, TeX sources compiled into C probably give lots of Coverity errors, yet TeX has a very low bug density. Coverity's report is biased towards making them look good, and that's probably deliberate.
But you guys would be surprised at how accurately tools like Coverity can predict the overall bug density of a large project. Just as some example numbers, if the Coverity folks find their tool finds 30% of bugs and their tool finds 30 bugs in 50,000 lines of code, the actual number of bugs is going to be near 100. It's called statistical inference.;)
Yes, and what's missing from Coverity's report is the data and analysis to support those statistical inferences. Not only is the data missing, there is no indication that they have actually done the proper analysis in-house.
I can point you to a number of papers that talk about tools the authors developed that have found a number of bugs in the Linux kernel code base. [...] But at the same time, there's a TON that can be done in terms of bug hunting that compilers don't do. [...] Perhaps because compilers haven't picked up the analyses that are done by these tools, perhaps because it doesn't really belong in the compiler, I dunno. Probably the latter, because they can produce a lot of false positives.
There are plenty of tools that produce lists of bug candidates, some of them very useful. But that kind of software is not useful for comparing software quality: finding 500 bug candidates in one piece of software and 100 in another with one of those tools tells you nothing about which one is buggier because you don't know the rate at which those bug candidates turn into true bugs. Furthermore, you don't know the rate at which those tools have false negatives. Both those rates depend on many factors, including coding style and problem domain.
To say otherwise just demonstrates that you don't know what you're talking about.
Actually, the problem is really just fuzzy thinking and fuzzy terminology on your part.
You are wrong. Check the literature on automated testing.
Automated testing finds some bugs, not all bugs.
In order to support the kinds of conclusions that these people are drawing, they need to find all bugs, or at least, they need to find a representative sample of bugs consistently in different code bases. They certainly don't do the first, and they have failed to show that they're doing the second.
They didn't keep the bugs secret, they showed them to the open source teams.
But they did not publish the proprietary source code, a list of bugs in the proprietary source code, or even the identity of the proprietary source code. Since their point concerns the relative performance of open source and proprietary code, therefore, they did not publish the relevant data.
Or instead of guessing, you could read the article.
Are you pretending that the incomplete information they published is complete because (1) you don't know any better, or (2) because you actually know better but have a stake in the company?
There are a lot of legitimate criticisms of the iPod, but the DRM one I don't particularly understand. Okay, so the iPod supports DRM. It doesn't require it.
DRM probably has driven some key aspects of the design of iPod. For example, the fact that the iPod doesn't present its contents as a file system, like many other MP3 players do, is probably due to DRM. The fact that it's hard to get music off the device is also driven by DRM concerns. Likewise, the fact that the iPod does not support syncing to multiple machines well is probably influenced by DRM. Lack of iTunes support for third party MP3 players, and lack of third party support for iPod is another consequence.
Security experts say that the security implications of Google Code Search are noteworthy, if not earth-shattering.
Yes, and they are good implications. If a company lets proprietary, bug-infested source code leak onto the web, then they should have to deal with the consequences.
I'm not making an argument, I'm challenging you to support your claim with an argument:
What I find surprising is that, in the few responses I've skimmed (including yours), I haven't seen anyone mention that these companies need to pay programmers.
RedHat, for example, doesn't need to pay programmers for them to ship a complete Linux distribution. How do we know that? Because several other distributions manage to do just that without paying programmers, including Debian, Knoppix, and Ubuntu. So, how does RedHat "need" to support programmers in any way that I, as an open source user, care about?
Then an analysis of Novell and Redhat's Linux distributions, including the original source of all code, and all places where the code is used in other distributions and other projects.
Why should I make that analysis? You made the claim--you should support your claim. All you're saying is that your claim is so obvious that you don't need to bother supporting it.
(As a matter of fact, however, I have done some statistics on the source code of common Linux distributions, and the fraction of it that comes from RedHat is small.)
If what I'm saying is wrong, back up your position with something other than "na-uh!" Because, you know, what I'm saying is pretty common sense.
Why should I back up my position? You made a claim and you must support your claim. That's how arguments work.
As for "common sense", your claim is absolutely silly, if not for any other reason than that we had open source software for decades before companies like RedHat, Troll Tech, and Novell ever were in the open source business.
The selection of programs from the two populations of programs (open source, proprietary) are not going to be comparable: vendors of proprietary software have a say over which code gets scanned, and they are going to select a different population of programs than the company selected for open source projects. This isn't a fixable problem: there is no way of doing this sort of study so that you can compare the two data sets. The best they could do is compare something like OpenOffice against Microsoft Office, or Apache against IIS.
Furthermore, Coverity simply cannot accomplish what they claim to accomplish: there is no way of detecting "bugs" automatically--if there were, compilers would already be doing it. Coverity effectively does little more than compare code against a set of internal coding conventions; that can be useful if it's done right, but it's not a measure of code quality. Some completely correct code will score thousands of violations against their tool, while other code may contain thousands of bugs, none of which register. Furthermore, it is likely that a lot of their customers are Windows based and that Coverity is biased towards Windows-based coding conventions, giving more false positives on non-Windows code. Before publishing such comparisons, Coverity first would need to demonstrate that their tool does not contain such biases.
Finally, and perhaps most importantly, the company isn't publishing its data, so nobody can verify or even evaluate their claims. Not only do they fail to publish their raw data (obviously, they can't do that for proprietary software), they also fail to list their summary statistics by vendor and project (which they could, but obviously won't do). They don't even give a summary statistic by class of application, class of organization, and code size. Their results are meaningless because they're not reproducible.
These numbers tell you nothing about FOSS code quality relative to commercial code quality. What they tell you is that Coverity apparently doesn't know how to do statistics, misrepresents what their product can do, and doesn't know how to report experimental results properly. Now, do you want to put your trust in such a company?
You're right: you didn't bring it up, you just responded to it, and then mischaracterized the way RedHat, Novell, and Sun make money.
Star Office fits the model I was talking about where a software vendor helps fund development on a FOSS so they can use it as a base for a commercial product, which they in turn sell to the general public. Whether it's a very profitable business is irrelevant, it's a business that Sun participates in.
It's quite relevant whether it's profitable or not, because you used those examples as support for your incorrect assertions about how open source gets funded.
I'm specifically not trying to be involved in anyone's discussions of their personal OSS pet-peeves.
Yeah, you're simply trying to spread misinformation about how FOSS funding works. Whether you do that out of ignorance or because you have some agenda to push, I can't tell.
Slashdot Mirror
As I was saying: it's a loophole from the point of view of the people who designed the GPL.
You're entitled to your opinion that other licenses are better and that this kind of "lockdown" is appropriate. I would wish that people like you would have the intellectual honesty not to hide behind the GPL then, though. If you truly believe that that kind of behavior is OK, then please use a license other than the GPL license.
So let's make this simple. In case you actually want to try to respond or continue this discussion in any way, I propose this: Read the following statements.
* Redhat pays programmers and fund projects
* Code written by Redhat-paid programmers and written in Redhat-funded projects exists in both Redhat and other Linux distributions
* Redhat pays these programmers and funds these projects with profits generated from sales of Redhat products
In your next reply, please tell me where there are inaccuracies in one or more of these 3 statements. Back up your statements with something resembling an argument or proof.
There is nothing inaccurate about those statements; the statements are simply not what you originally claimed. What you originally claimed is:
You were saying not just that these companies pay programmers (which they do), but that these companies "need" to pay programmers; in the context of this discussion, "need" means that if they didn't do that, open source could not succeed. Well, you have failed to show that. In fact, your claim is preposterous in light of "common facts and common knowledge".
That may sound a bit harsh, but it's only hard if you're a moron.
That may sound a bit harsh, but that's the group Apple targets as their customers: people who don't know much about computers. These measures prevent Apple's user community quite effectively from moving data back and forth freely.
through iTunes if the "other" computer is allowed to read these files - the copy prevention only applies to non-DRM'd files.
My point exactly: Apple has taken a variety of technological and UI measures to make it difficult to move stuff around. That's in contrast to other MP3 players that make it very easy to move stuff around. Heck, I can plug my no-name Chinese MP3 player into another no-name Chinese MP3 player and exchange any file I want, easily and without a Ph.D. in computer science. But my iPod makes all the things Apple doesn't want me to do hard--deliberately.
That's interesting. When I bought an iPod, its firmware didn't even support DRM, yet these key aspects of the design were all present.
Those "key aspects of the design" are a simple form of DRM. Apple has, over the years, added stronger DRM mechanisms on top of that.
Where do people get the idea that something like international laws actually exist?
This should answer your question.
If a country decides to do something they'll just rewrite their own laws to allow it. If someone decides to ignore the UN or what not then it's not "illegal".
The term "illegal" is not usually applied to violations of international law. Nevertheless, such violations are often considered immoral, and they often have severe consequences.
I would rather have the treaties. I actually do trust the experts more than people the environmental groups.
We have treaties. They say that Bush shouldn't do what he is doing. They have one problem: they are international, and, of course, Bush feels under no obligation to observe international treaties since, after all, those people didn't elect him and he can drum up enough xenophobia to support breaking the treaties. So, treaties don't control Bush or what the US is doing.
Bush's policy effectively states that the usage of nuclear power as engines of exploration is considered to take priority over any over-reaching treaties that ban nuclear power for the purposes of weaponry.
You don't seriously believe that Bush gives a damn about exploration, do you? Bush wants to put nuclear weapons into space, and nuclear reactors for powering other kinds of weapons.
In any case, this policy is complete and utter stupidity. If the US starts putting nuclear reactor, beam weapons, and nuclear bombs into space, so will other nations. Do you really think that France is going to sit by and let the US weaponize space without getting their own weapons up there? Do you really want a Chinese satellite flying overhead that can destroy any US city with no warning within seconds? Because that's where things are heading: a space arms race.
And in the end, huge amounts of tax money is going to be wasted (of course, it's going to be wasted on Bush's corporate buddies), and there's going to be a bunch of weapon systems that can't realistically be used, yet still decrease our security because they can fall into the wrong hands (remember: they're all remotely controlled by computer).
The environmental groups protest everything with involving the "n word".
Yes, and they should: the disposal issue has not been solved. All nuclear waste that is being generated is piling up in "temporary" locations. Furthermore, the way we use nuclear fuel right now is an irresponsible waste, since we're using only a few percent of the power that's contained in it. That way, fuel that should last several millennia is going to last less than a century.
If the US were to switch to breeder reactors that demonstrably eliminate most of the nuclear waste, you'd see a lot less opposition.
You don't need stabilizing gyros, just decent control of the individual nozzles and gyroscopic sensors. think "Segway": it doesn't stabilize with gyros, it stabilizes with electronic control.
Segway-like control software might actually make these devices fairly safe.
That's not a loophole at all -- the loophole is that you can lock down the CPU to only run signed code and this has nothing to do with Linux at all.
It's a loophole from the point of view of the people who wrote the GPL, and it's getting fixed in GPLv3. That is, you may be technically able to "lock down the CPU", but you will not be permitted to run GPLv3 code on that kind of hardware.
If you've written an app that links to GPL libraries, I don't believe it falls under the GPL requirements to release the source
Merely linking doesn't cause it to fall under the GPL. However, if you distribute the linked binary, you are distributing code under the GPL, and you only have permission if all the code that is linked to it is also distributed under the GPL.
If that were the case, you'd never see apps on Linux like Oracle or whatnot.
Oracle's code is not linked with the kernel, and libc isn't under a (strict) GPL license, so the GPL doesn't require Oracle to distribute the sources to their code.
The GPL is only required (i.e., only applicable) when copyright is involved; i.e., making a derivative work.
That's not true. You accept licenses in return for being allowed to copy the code. The license you accept is just a contract, and a contract can say pretty much whatever it wants to. It can impose requirements on you that have nothing to do with copying the code or derivative works. Many licenses, for example, require you to open your wallet and transfer money to someone else. Other licenses require you to adopt specific kinds of marketing--telling your buyers that your software uses other software, or not telling them. Microsoft's shared source and Qt's old source licenses also impose lots of requirements on code that use the library.
The GPL happens to be designed such that it imposes relatively few requirements that don't relate to copying and distributing the code, but that's by choice, not by legal necessity.
you'll see that code dictated by external requirements (i.e., pretty much every piece of software running on a UNIX/Linux system has to use malloc, etc., and thus must either call the system calls directly or via the C Library) is specifically filtered out of the copyright comparison.
Correct. And what that means is that your code doesn't violate any Linux copyrights merely by using Linux header files. However, the Linux kernel license could still impose restrictions on how you use your code and the Linux kernel together, because in order to use them together, you have to copy the Linux kernel, and you cannot do that without agreeing to the terms of the Linux kernel license.
No Company would ever enter into any agreement where they invest a large some of money like they did without a CONTRACT.
Sure they would: if they have even bigger contracts for something else and are doing this as a favor. That sort of thing happens all the time. In fact, Baystar isn't the first company to be forced by Microsoft to act against their own interests in this way.
According to the article, Microsoft didn't fund anything.
They provided a guarantee; that pretty much amounts to the same thing.
I find it hilarious that someone took a for-profit corporation at their word with no contract
Baystar likely has other business relationships with Microsoft; that's all the leverage Microsoft needs. That sort of thing happens all the time in business.
but you can certainly detect code which may result in unintended behaviour
Yes, you can. But those kinds of detectors are not useful for comparing software quality, at least not without a lot more statistical analysis, which is missing from Coverity's report.
Run lint against a bunch of source code and you'll see what I'm talking about.
There are many essentially bug-free pieces of software I have that lint gives thousands of errors on. And I've checked in plenty of buggy code that passes lint. Tools like lint can be useful, but using them as a measure of software quality is inappropriate.
Coverity's customers probably have near-zero Coverity errors, but that doesn't make their code bug-free. Conversely, TeX sources compiled into C probably give lots of Coverity errors, yet TeX has a very low bug density. Coverity's report is biased towards making them look good, and that's probably deliberate.
But you guys would be surprised at how accurately tools like Coverity can predict the overall bug density of a large project. Just as some example numbers, if the Coverity folks find their tool finds 30% of bugs and their tool finds 30 bugs in 50,000 lines of code, the actual number of bugs is going to be near 100. It's called statistical inference. ;)
Yes, and what's missing from Coverity's report is the data and analysis to support those statistical inferences. Not only is the data missing, there is no indication that they have actually done the proper analysis in-house.
I can point you to a number of papers that talk about tools the authors developed that have found a number of bugs in the Linux kernel code base. [...] But at the same time, there's a TON that can be done in terms of bug hunting that compilers don't do. [...] Perhaps because compilers haven't picked up the analyses that are done by these tools, perhaps because it doesn't really belong in the compiler, I dunno. Probably the latter, because they can produce a lot of false positives.
There are plenty of tools that produce lists of bug candidates, some of them very useful. But that kind of software is not useful for comparing software quality: finding 500 bug candidates in one piece of software and 100 in another with one of those tools tells you nothing about which one is buggier because you don't know the rate at which those bug candidates turn into true bugs. Furthermore, you don't know the rate at which those tools have false negatives. Both those rates depend on many factors, including coding style and problem domain.
To say otherwise just demonstrates that you don't know what you're talking about.
Actually, the problem is really just fuzzy thinking and fuzzy terminology on your part.
You are wrong. Check the literature on automated testing.
Automated testing finds some bugs, not all bugs.
In order to support the kinds of conclusions that these people are drawing, they need to find all bugs, or at least, they need to find a representative sample of bugs consistently in different code bases. They certainly don't do the first, and they have failed to show that they're doing the second.
They didn't keep the bugs secret, they showed them to the open source teams.
But they did not publish the proprietary source code, a list of bugs in the proprietary source code, or even the identity of the proprietary source code. Since their point concerns the relative performance of open source and proprietary code, therefore, they did not publish the relevant data.
Or instead of guessing, you could read the article.
Are you pretending that the incomplete information they published is complete because (1) you don't know any better, or (2) because you actually know better but have a stake in the company?
There are a lot of legitimate criticisms of the iPod, but the DRM one I don't particularly understand. Okay, so the iPod supports DRM. It doesn't require it.
DRM probably has driven some key aspects of the design of iPod. For example, the fact that the iPod doesn't present its contents as a file system, like many other MP3 players do, is probably due to DRM. The fact that it's hard to get music off the device is also driven by DRM concerns. Likewise, the fact that the iPod does not support syncing to multiple machines well is probably influenced by DRM. Lack of iTunes support for third party MP3 players, and lack of third party support for iPod is another consequence.
Security experts say that the security implications of Google Code Search are noteworthy, if not earth-shattering.
Yes, and they are good implications. If a company lets proprietary, bug-infested source code leak onto the web, then they should have to deal with the consequences.
I'm not making an argument, I'm challenging you to support your claim with an argument:
RedHat, for example, doesn't need to pay programmers for them to ship a complete Linux distribution. How do we know that? Because several other distributions manage to do just that without paying programmers, including Debian, Knoppix, and Ubuntu. So, how does RedHat "need" to support programmers in any way that I, as an open source user, care about?
Why should I make that analysis? You made the claim--you should support your claim. All you're saying is that your claim is so obvious that you don't need to bother supporting it.
(As a matter of fact, however, I have done some statistics on the source code of common Linux distributions, and the fraction of it that comes from RedHat is small.)
If what I'm saying is wrong, back up your position with something other than "na-uh!" Because, you know, what I'm saying is pretty common sense.
Why should I back up my position? You made a claim and you must support your claim. That's how arguments work.
As for "common sense", your claim is absolutely silly, if not for any other reason than that we had open source software for decades before companies like RedHat, Troll Tech, and Novell ever were in the open source business.
The selection of programs from the two populations of programs (open source, proprietary) are not going to be comparable: vendors of proprietary software have a say over which code gets scanned, and they are going to select a different population of programs than the company selected for open source projects. This isn't a fixable problem: there is no way of doing this sort of study so that you can compare the two data sets. The best they could do is compare something like OpenOffice against Microsoft Office, or Apache against IIS.
Furthermore, Coverity simply cannot accomplish what they claim to accomplish: there is no way of detecting "bugs" automatically--if there were, compilers would already be doing it. Coverity effectively does little more than compare code against a set of internal coding conventions; that can be useful if it's done right, but it's not a measure of code quality. Some completely correct code will score thousands of violations against their tool, while other code may contain thousands of bugs, none of which register. Furthermore, it is likely that a lot of their customers are Windows based and that Coverity is biased towards Windows-based coding conventions, giving more false positives on non-Windows code. Before publishing such comparisons, Coverity first would need to demonstrate that their tool does not contain such biases.
Finally, and perhaps most importantly, the company isn't publishing its data, so nobody can verify or even evaluate their claims. Not only do they fail to publish their raw data (obviously, they can't do that for proprietary software), they also fail to list their summary statistics by vendor and project (which they could, but obviously won't do). They don't even give a summary statistic by class of application, class of organization, and code size. Their results are meaningless because they're not reproducible.
These numbers tell you nothing about FOSS code quality relative to commercial code quality. What they tell you is that Coverity apparently doesn't know how to do statistics, misrepresents what their product can do, and doesn't know how to report experimental results properly. Now, do you want to put your trust in such a company?
I didn't bring up Troll Tech.
You're right: you didn't bring it up, you just responded to it, and then mischaracterized the way RedHat, Novell, and Sun make money.
Star Office fits the model I was talking about where a software vendor helps fund development on a FOSS so they can use it as a base for a commercial product, which they in turn sell to the general public. Whether it's a very profitable business is irrelevant, it's a business that Sun participates in.
It's quite relevant whether it's profitable or not, because you used those examples as support for your incorrect assertions about how open source gets funded.
I'm specifically not trying to be involved in anyone's discussions of their personal OSS pet-peeves.
Yeah, you're simply trying to spread misinformation about how FOSS funding works. Whether you do that out of ignorance or because you have some agenda to push, I can't tell.