First, Microsoft can inform you of what operating systems it is guaranteed to run on. It cannot legally enforce this, directly or indirectly, without violating anti-trust laws regarding product bundling. It's already been convicted of doing just that, so we'll see what happens next.
Second, if Microsoft actively leverages its customers to cease using Wine in this fashion, they are guilty of "Contract Interference". See "Intentional Interference With Prospective Economic Advantage" for more information. Companies selling products based on Wine for the purpose of running Office could likely sue on this basis.
Now, whether anything becomes of this is a whole different story.
Since SVN people are about, could some answer these two questions. How's the branch switching code looking nowadays and what's the status of read-only files in the repository?
We tested Subversion in November against our working CVS system. It was fun, and we were all really happy with it until...
When switching between two branches, a file that was moved caused the switch to fail. The local sandbox was broken to the extent that nothing short of re-rechecking out the repository would fix it. All subsequent commits, updates, or attempts to switch back would not work.
The second thing that bit us really bad was that we have applications that set source code controlled files read-only. This is intentional and necessary; if they are not read-only, the files will be changed automatically when certain tests are run which is something we do not want. Despite this, there are times when those files need to be updated. SVN crashed and burned trying to checkout changes over read-only files. All the research reading mailing list indicated that the prevailing thought at the time was that read-only meant read-only from SVN.
That's not how it works in CVS at all where we currently use watches and locks to get this functionality. Read-only is an attribute of the file. When some checks out the file, it must be read-only when it arrives in their sandbox. The file and the sandbox is managed by source control so aside from user permissions, the last word on whether a file can be modified is that of the sandbox manager, not the filesystem. In short, if CVS or SVN need to write over a read-only file they should be able to do it so long as the file is read-only when the job is done.
With the read-only detail and the sandbox corruption issues open, we had no choice but to return to CVS. I am seriously looking forward to what Subversion has to offer in the future though.
You are correct in the interpretation of the OR rather than AND; however, this does not further the opposing argument. Any of the following are considered cartoons according to Webster.
1. a preparatory design, drawing, or painting (as for a fresco)
This is a simplification of a drawing for planning purposes.
OR
2 a : a drawing intended as satire, caricature, or humor b : COMIC STRIP
Here we see the traditional definition including satire and humor and the additional item of caricature.
OR
3 : ANIMATED CARTOON
This is entirely self-referential. An animated cartoon may be referred to as a cartoon. That's nice, but it does not tell us anything about the nature of cartoons, only that animated cartoons exist, which we know.
OR
4 : a ludicrously simplistic, unrealistic, or one-dimensional portrayal or version (the film's villain is an entertaining cartoon).
Again, we see the satirical angle, particularly with respect to political and dark humor. Humor does not have to be funny.
So, that leaves zero definitions that imply that all animation is cartoon. As it should be.
It wasn't a lame dig -- you have your set theory wrong. You have however established that this is not due to lack of exposure to the theory.
Anime is an animated series of drawings. correct.
This makes it a cartoon. incorrect. If this were true, then 3D architectural walk-throughs would also be cartoons, and we know that is incorrect.
The definition of a cartoon is a humorous or satirical drawing. Comics and political cartoons meet this criteria as well.
An animated series of drawings does not sufficiently encompass this set. More exactly, there exists a set that is not humorous or satirical and is an animated series of drawings. This is the set of Japanese animation that is not a cartoon.
As for the comment about Pokemon, it is humor targeted at children. I don't see how this has any relevence to your argument. Pokemon is a cartoon. It's also anime. That does not make all anime cartoons.
A cartoon is by definition humorous. Ghost in the Shell is not humorous. Grave of the Fireflies is not humorous. Pokemon is intended to be humorous. Pokemon is a cartoon, the other two are not.
You have confused the term cartoon with animated 2D drawing. This is incorrect. There are animated 2D cartoons. Not all cartoons are animated. Not all animations are cartoons.
Your logic is faulty. You have cited "animated cartoon" -- a cartoon that has been animated. Since the topic of discussion is Japanese animation, not cartoons, you're barking up the wrong tree. Specifically, you chose to omit the second citation which defeats your argument, namely:
n : a film made by photographing a series of
cartoon drawings to give the illusion of movement when projected in rapid sequence [syn: cartoon]
If you use the logic you've demonstrated so far, all books are comic books, and anything comprised of a sequence of still images to simulate motion is a cartoon -- like television and movies. Needless to say, I'm not impressed.
So it stands: there are cartoons. Some cartoons are animated. Logically, it does not follow that all animations are cartoons. When you get to college, consider taking a course in logic as it applies to set theory. It's an easy A.
....1. ........1. A drawing depicting a humorous situation, often accompanied by a caption. ........2. A drawing representing current public figures or issues symbolically and often satirically: a political cartoon. ....2. A preliminary sketch similar in size to the work, such as a fresco, that is to be copied from it. ....3. An animated cartoon. ....4. A comic strip. ....5. A ridiculously oversimplified or stereotypical representation: criticized the actor's portrayal of Jefferson as a historically inaccurate cartoon.
v. cartooned, cartooning, cartoons
v. tr.
....To draw a humorous or satirical representation of; caricature.
v. intr. ....To make humorous or satirical drawings.
Notice the predominant theme of humor and satire. Notice also that a cartoon can be animated. This does not mean that all animations are cartoons. If they are not humorous, they are not cartoons, by definition.
By your mistaken logic, the evening news is a situational comedy because it's on television. Those that agree are either making a statement about the news or do not understand what they are saying. If you have something against Japanese animation, speak your mind. Using the wrong word just makes you sound foolish.
Exactly, which is why it's a sunk cost. Either they wait for someone to fix it or they fix it themselves. In either event, it costs them, and in neither case is the money recoverable. In fact, the only good that can come out of this is to contribute it. All other options are less efficient for Redhat and the system as a whole.
There was no "force" as Redhat was under no obligation to release these changes. Only after they chose to redistribute the program were they required to release the source code thereby meeting the terms of the license. If they had not, they would have been in breach of copyright law.
Look up the phrase "sunk cost" and be enlightened. Regardless of the state of gcc before or after, Redhat was forced to commit the time to meet their own needs. That they chose to release those improvements to the world allowed other groups to avoid incurring the same cost. Ideally, if every group addressed the problem this way, the overall efficiency would increase and the aggregated sunk costs of all parties would be lowered.
Which API are you using? If it's an MFC or equivalent wrapper class, then yes, an event queue is involved, but generally, using the standard socket, bind, connect, send, and recv functions works fine across threads.
How much of that debt is payable in a currency other than USD? If the dollar is to continue to lose against foreign currencies, then those debts will only increase. On the plus side, as the USD weakens, it will be harder and harder to secure additional loans, naturally curbing the expansion of debt.
With respect to java import, constants and non-programmatic constructs are specifically waived by the LGPL. Extending a class is certainly covered though. I believe the established integration boundary is at the IPC level (ie. file io); someone mentioned that dynamic loading of plugins is not covered, but I do not believe that to be the case. If the library is operating in the same process space (or equivalent for virtual machines) or there is a source dependency, it seems straightforward enough to me, but apparently, GPL 3 will have more to say about it.
Sounds to me like this is an Apache project issue rather than an LGPL issue. Although I've never submitted anything to Apache, I have made submissions to the kernel (GPL) and XFree86 (BSD); maintainers of large projects are pretty strict as general rule and licensing issues are the last thing they want to deal with.
All my libraries are LGPL and that was with the intention that they be useable by as many people as possible while protecting my primary interest of long-term code viability.
If Apache will not allow their code-base to be complicated by foreign licenses then that's their decision to make.
According to item 7 of the LGPL you may link any library of any license against LGPL libraries. What specifically are you referring to? The incompatibilities are not with linking against LGPL'd libraries, but GPL'd libraries. LGPL was written explicitly with this issue in mind.
7. You may place library facilities that are a work based on the Library side-by-side in a single library together with other library facilities not covered by this License, and distribute such a combined library, provided that the separate distribution of the work based on the Library and of the other library facilities is otherwise permitted, and provided that you do these two things:
* a) Accompany the combined library with a copy of the same work based on the Library, uncombined with any other library facilities. This must be distributed under the terms of the Sections above.
* b) Give prominent notice with the combined library of the fact that part of it is a work based on the Library, and explaining where to find the accompanying uncombined form of the same work.
Not to be a kill joy, but the general consensus among the people who actually know what they're talking about around here (as opposed to the people who implement the code that runs the analytical models like myself) is that the Bush Administration has destablized the long-term economy so badly that the short-term issues are no longer even relevent.
For better or for worse, the economic "slack" that the government had control of four years ago is now gone, and the debt has increased subtantially. No matter which candidate is elected, the president of the next term will inherit the largest national debt in history and more importantly, a budget deficit which means the nose is currently pointed down.
As an aside, and this is just my personal observation but, what GWB did in the last four years is largely the same as what his father did during his term. The economy sank in both cases. Supply-side economics, in my opinion, is being implemented incorrectly or is flat-out wishful thinking. In either event, until the kinks are worked out, it is time to change strategies because the current strategy is killing us.
I'm a Republican in Arizona. All the Republicans in my office, my family, and immediate friends are voting against Bush. I don't anticipate Arizona going Blue this election, but I am very curious to see how the numbers come out.
For the record, I work in financial software, and most of our employees are software engineers or have advanced degrees in Economics. The office was universally for Bush in 2000 and against in 2004.
It's the economy. There is no issue more pressing.
As someone commented earlier around the watercooler, we'll have plenty of time to discuss gay-marriage and stem-cell research when we're a third-world nation.
Apparently, I was not clear. In this case, I was referring to the software he used to compare the two code bases. In any test, you need a baseline, a test subject, and a properly calibrated instrument. The baseline test should provide the opposite result as the subject. If they test the same, then either the test itself is inconclusive or the instrument has failed. I am curious how he determined, to his satisfaction, that the comparison software was functioning both properly and adequately.
I am familiar with Dr. Davis' credentials as I read his deposition.
Furthermore, I am satisfied that he did whatever is necessary to ensure that "no matches" means that there were in fact no matches and not simply that the filter itself failed to detect them. However, I would like to know how he came to that conclusion since he does not explicitly state this in his deposition.
As for AFC, the question at hand is thus: if a program can be modified to the extent that it no longer generates a positive match by the programmatic filter, does it therefore also survive the legal AFC test -- by definition. If not, then the possibility exists that, if in the unlikely event that there were any false negatives, some could fall within the scope of AFC requiring further analysis.
Dr. Davis has stated that there are no positive matches, and we trust that his methodology has ruled out the possibility of discarded false negatives. Therefore, the conclusion is that no code is subject to the legal AFC test and consequently, none was performed.
Again, I would like to know how he convinced himself that no false negatives were rejected, and if the possibility does exist, what the likelihood of any of those cases requiring further consideration under the AFC test.
As I said, I am not faulting the methodology. I believe in systematic and thorough evaluation, as I am certain Dr. Davis does, too. He does not need to convince me -- I am more interested to know what convinced him.
Although your deposition includes a description of your methodology, it does not indicate whether you established a proper baseline for comparison or how you calibrated your filter. I would be interested to know how far, in your direct experience, code can be modified before it fails to match COMPARATOR and SIM respectively. Furthermore, how closely does the point at which these tools fail to detect a match coincide with the legal Abstraction, Filtration, and Comparison test?
I do not fault your analysis; I would like to know more about your methodology, beyond the limited scope of the deposition.
You bring up an important point: we trust the code only because we trust the auditor. It is not necessary to trust the author. Presently, Linus is the auditor. Your trust in the code stems from your trust in Linus.
If that is insufficient for your needs, you may wish to have it audited by someone else. With Open Source, and unlike with proprietary code, everyone has the opportunity to use their own auditors.
I agree that Open Source moves fast. I agree that anyone who wishes to certify the Linux kernel will need to certify the gcc compiler as well. In my experience, this is not necessarily true of Open Source code in general, at least not the important projects.
Your argument seems largely over the relative penalty of forking code and its subsequent maintenance.
First of all, any code that meets certification is going to result in a fork of some type, whether it is open or proprietary. The changes necessary for compliance are often not something you want to merge back into the development branch, and in some cases, getting multiple certifications will require conflicting changes.
The second issue is that backporting features, fixes, even security patches will void a certification. Either the new code is re-audited and re-certified, or the application implementor needs to have policy in place to deal with these patches.
All of this is true for proprietary and open source. Green Hills does not have any magic security clearance that allows them to release operating systems without going through the same certification process as everyone else. If security restricted applications are using non-certified versions of Green Hills software under the auspices that previous versions were deemed secure, then at least one failure of the trust chain has been identified.
In closing, one trusts the code because they trust the auditors. That trust does not extend to the authors of the code, whoever they are.
You state that the tool chain issue is not relevent to these vendors because they provide "trusted," meaning certified, platforms. If Open Source is audited and certified, it achieves the same level of value; there is no win there. Whether the source comes from an open process or a proprietary vendor is immaterial.
What you seem to be missing here is that certified code does not change once certified. Once established, the tool chain does not change; therefore, the introduction of malicious code is not possible.
If one wishes to patch the original certified source, that becomes a modification which will require an audit if proper procedures are followed, and possibly a waiver depending on the nature of the project.
As I stated before, there is no security "win" here for proprietary vendors. They have existing certifications. Nothing prevents a vendor from getting an Open Source project audited and certified, and the entire tool chain from kernel to compiler need not necessarily be included. We're talking about source code here, not binaries. When the code is compiled and put into production, that compiler will also need to be certified -- or just use an existing certified compiler.
Linus only takes patches from the people responsible for appropriate parts of the kernel. To get a patch through requires convincing those individuals -- and they do check the patches. In my experience, getting patches into the kernel is not a trivial matter, in fact it is frustratingly difficult. Futhermore, even if you succeed in getting a patch into some esoteric driver, the less mainstream it is, the less likely it will be in an active kernel.
If the various world governments will go through the trouble to audit defense contractors' code, then they can save themselves some trouble and audit Open Source code instead; any vendor establishing from that base will require less time in audit later. If the governments do not demand an independent audit of contractors' code, then that is where you will find the weak link. With Open Source, you always have the opportunity to audit at any time, diff against previously audited sources, and compile customized code with minimal audited feature sets.
Green Hills is saying "Trust Us! Trust Us!" Open Source is suggesting you trust what you can independently verify before your own experts' eyes.
As for the tool chain issue, you are seriously glossing over the obvious -- all the statements you have made apply to proprietary vendors as well. The solution is simple: don't upgrade the tool chain until the changes pass inspection. This is standard operating procedure for all mission critical deployments.
Naturally, with all those spare cycles available, what is a Linux box to do, but look up stuff on the internet. Must be all that server pr0n. Remind me to uninstall Mozilla from all the company servers over the weekend.
Slashdot Mirror
There are two problems with your theory.
First, Microsoft can inform you of what operating systems it is guaranteed to run on. It cannot legally enforce this, directly or indirectly, without violating anti-trust laws regarding product bundling. It's already been convicted of doing just that, so we'll see what happens next.
Second, if Microsoft actively leverages its customers to cease using Wine in this fashion, they are guilty of "Contract Interference". See "Intentional Interference With Prospective Economic Advantage" for more information. Companies selling products based on Wine for the purpose of running Office could likely sue on this basis.
Now, whether anything becomes of this is a whole different story.
-Hope
Since SVN people are about, could some answer these two questions. How's the branch switching code looking nowadays and what's the status of read-only files in the repository?
We tested Subversion in November against our working CVS system. It was fun, and we were all really happy with it until...
When switching between two branches, a file that was moved caused the switch to fail. The local sandbox was broken to the extent that nothing short of re-rechecking out the repository would fix it. All subsequent commits, updates, or attempts to switch back would not work.
The second thing that bit us really bad was that we have applications that set source code controlled files read-only. This is intentional and necessary; if they are not read-only, the files will be changed automatically when certain tests are run which is something we do not want. Despite this, there are times when those files need to be updated. SVN crashed and burned trying to checkout changes over read-only files. All the research reading mailing list indicated that the prevailing thought at the time was that read-only meant read-only from SVN.
That's not how it works in CVS at all where we currently use watches and locks to get this functionality. Read-only is an attribute of the file. When some checks out the file, it must be read-only when it arrives in their sandbox. The file and the sandbox is managed by source control so aside from user permissions, the last word on whether a file can be modified is that of the sandbox manager, not the filesystem. In short, if CVS or SVN need to write over a read-only file they should be able to do it so long as the file is read-only when the job is done.
With the read-only detail and the sandbox corruption issues open, we had no choice but to return to CVS. I am seriously looking forward to what Subversion has to offer in the future though.
Hope
You are correct in the interpretation of the OR rather than AND; however, this does not further the opposing argument. Any of the following are considered cartoons according to Webster.
1. a preparatory design, drawing, or painting (as for a fresco)
This is a simplification of a drawing for planning purposes.
OR
2 a : a drawing intended as satire, caricature, or humor b : COMIC STRIP
Here we see the traditional definition including satire and humor and the additional item of caricature.
OR
3 : ANIMATED CARTOON
This is entirely self-referential. An animated cartoon may be referred to as a cartoon. That's nice, but it does not tell us anything about the nature of cartoons, only that animated cartoons exist, which we know.
OR
4 : a ludicrously simplistic, unrealistic, or one-dimensional portrayal or version (the film's villain is an entertaining cartoon).
Again, we see the satirical angle, particularly with respect to political and dark humor. Humor does not have to be funny.
So, that leaves zero definitions that imply that all animation is cartoon. As it should be.
-Hope
It wasn't a lame dig -- you have your set theory wrong. You have however established that this is not due to lack of exposure to the theory.
Anime is an animated series of drawings. correct.
This makes it a cartoon. incorrect. If this were true, then 3D architectural walk-throughs would also be cartoons, and we know that is incorrect.
The definition of a cartoon is a humorous or satirical drawing. Comics and political cartoons meet this criteria as well.
An animated series of drawings does not sufficiently encompass this set. More exactly, there exists a set that is not humorous or satirical and is an animated series of drawings. This is the set of Japanese animation that is not a cartoon.
As for the comment about Pokemon, it is humor targeted at children. I don't see how this has any relevence to your argument. Pokemon is a cartoon. It's also anime. That does not make all anime cartoons.
-Hope
A cartoon is by definition humorous. Ghost in the Shell is not humorous. Grave of the Fireflies is not humorous. Pokemon is intended to be humorous. Pokemon is a cartoon, the other two are not.
You have confused the term cartoon with animated 2D drawing. This is incorrect. There are animated 2D cartoons. Not all cartoons are animated. Not all animations are cartoons.
Really, this is very simple.
-Hope
So it stands: there are cartoons. Some cartoons are animated. Logically, it does not follow that all animations are cartoons. When you get to college, consider taking a course in logic as it applies to set theory. It's an easy A.
-Hope
By your mistaken logic, the evening news is a situational comedy because it's on television. Those that agree are either making a statement about the news or do not understand what they are saying. If you have something against Japanese animation, speak your mind. Using the wrong word just makes you sound foolish.
-Hope
Exactly, which is why it's a sunk cost. Either they wait for someone to fix it or they fix it themselves. In either event, it costs them, and in neither case is the money recoverable. In fact, the only good that can come out of this is to contribute it. All other options are less efficient for Redhat and the system as a whole.
-Hope
There was no "force" as Redhat was under no obligation to release these changes. Only after they chose to redistribute the program were they required to release the source code thereby meeting the terms of the license. If they had not, they would have been in breach of copyright law.
-Hope
Look up the phrase "sunk cost" and be enlightened. Regardless of the state of gcc before or after, Redhat was forced to commit the time to meet their own needs. That they chose to release those improvements to the world allowed other groups to avoid incurring the same cost. Ideally, if every group addressed the problem this way, the overall efficiency would increase and the aggregated sunk costs of all parties would be lowered.
-Hope
Which API are you using? If it's an MFC or equivalent wrapper class, then yes, an event queue is involved, but generally, using the standard socket, bind, connect, send, and recv functions works fine across threads.
-Hope
How much of that debt is payable in a currency other than USD? If the dollar is to continue to lose against foreign currencies, then those debts will only increase. On the plus side, as the USD weakens, it will be harder and harder to secure additional loans, naturally curbing the expansion of debt.
-Hope
With respect to java import, constants and non-programmatic constructs are specifically waived by the LGPL. Extending a class is certainly covered though. I believe the established integration boundary is at the IPC level (ie. file io); someone mentioned that dynamic loading of plugins is not covered, but I do not believe that to be the case. If the library is operating in the same process space (or equivalent for virtual machines) or there is a source dependency, it seems straightforward enough to me, but apparently, GPL 3 will have more to say about it.
Sounds to me like this is an Apache project issue rather than an LGPL issue. Although I've never submitted anything to Apache, I have made submissions to the kernel (GPL) and XFree86 (BSD); maintainers of large projects are pretty strict as general rule and licensing issues are the last thing they want to deal with.
All my libraries are LGPL and that was with the intention that they be useable by as many people as possible while protecting my primary interest of long-term code viability.
If Apache will not allow their code-base to be complicated by foreign licenses then that's their decision to make.
-Hope
Not to be a kill joy, but the general consensus among the people who actually know what they're talking about around here (as opposed to the people who implement the code that runs the analytical models like myself) is that the Bush Administration has destablized the long-term economy so badly that the short-term issues are no longer even relevent.
For better or for worse, the economic "slack" that the government had control of four years ago is now gone, and the debt has increased subtantially. No matter which candidate is elected, the president of the next term will inherit the largest national debt in history and more importantly, a budget deficit which means the nose is currently pointed down.
As an aside, and this is just my personal observation but, what GWB did in the last four years is largely the same as what his father did during his term. The economy sank in both cases. Supply-side economics, in my opinion, is being implemented incorrectly or is flat-out wishful thinking. In either event, until the kinks are worked out, it is time to change strategies because the current strategy is killing us.
-Hope
I'm a Republican in Arizona. All the Republicans in my office, my family, and immediate friends are voting against Bush. I don't anticipate Arizona going Blue this election, but I am very curious to see how the numbers come out.
For the record, I work in financial software, and most of our employees are software engineers or have advanced degrees in Economics. The office was universally for Bush in 2000 and against in 2004.
It's the economy. There is no issue more pressing.
As someone commented earlier around the watercooler, we'll have plenty of time to discuss gay-marriage and stem-cell research when we're a third-world nation.
-Hope
Actually, the insurance company that is backing this venture (i.e. betting against it) is saying that. Hope they're good sports.
-Hope
Apparently, I was not clear. In this case, I was referring to the software he used to compare the two code bases. In any test, you need a baseline, a test subject, and a properly calibrated instrument. The baseline test should provide the opposite result as the subject. If they test the same, then either the test itself is inconclusive or the instrument has failed. I am curious how he determined, to his satisfaction, that the comparison software was functioning both properly and adequately.
-Hope
I am familiar with Dr. Davis' credentials as I read his deposition.
Furthermore, I am satisfied that he did whatever is necessary to ensure that "no matches" means that there were in fact no matches and not simply that the filter itself failed to detect them. However, I would like to know how he came to that conclusion since he does not explicitly state this in his deposition.
As for AFC, the question at hand is thus: if a program can be modified to the extent that it no longer generates a positive match by the programmatic filter, does it therefore also survive the legal AFC test -- by definition. If not, then the possibility exists that, if in the unlikely event that there were any false negatives, some could fall within the scope of AFC requiring further analysis.
Dr. Davis has stated that there are no positive matches, and we trust that his methodology has ruled out the possibility of discarded false negatives. Therefore, the conclusion is that no code is subject to the legal AFC test and consequently, none was performed.
Again, I would like to know how he convinced himself that no false negatives were rejected, and if the possibility does exist, what the likelihood of any of those cases requiring further consideration under the AFC test.
As I said, I am not faulting the methodology. I believe in systematic and thorough evaluation, as I am certain Dr. Davis does, too. He does not need to convince me -- I am more interested to know what convinced him.
-Hope
Although your deposition includes a description of your methodology, it does not indicate whether you established a proper baseline for comparison or how you calibrated your filter. I would be interested to know how far, in your direct experience, code can be modified before it fails to match COMPARATOR and SIM respectively. Furthermore, how closely does the point at which these tools fail to detect a match coincide with the legal Abstraction, Filtration, and Comparison test?
I do not fault your analysis; I would like to know more about your methodology, beyond the limited scope of the deposition.
-Hope
You bring up an important point: we trust the code only because we trust the auditor. It is not necessary to trust the author. Presently, Linus is the auditor. Your trust in the code stems from your trust in Linus.
If that is insufficient for your needs, you may wish to have it audited by someone else. With Open Source, and unlike with proprietary code, everyone has the opportunity to use their own auditors.
-Hope
I agree that Open Source moves fast. I agree that anyone who wishes to certify the Linux kernel will need to certify the gcc compiler as well. In my experience, this is not necessarily true of Open Source code in general, at least not the important projects.
Your argument seems largely over the relative penalty of forking code and its subsequent maintenance.
First of all, any code that meets certification is going to result in a fork of some type, whether it is open or proprietary. The changes necessary for compliance are often not something you want to merge back into the development branch, and in some cases, getting multiple certifications will require conflicting changes.
The second issue is that backporting features, fixes, even security patches will void a certification. Either the new code is re-audited and re-certified, or the application implementor needs to have policy in place to deal with these patches.
All of this is true for proprietary and open source. Green Hills does not have any magic security clearance that allows them to release operating systems without going through the same certification process as everyone else. If security restricted applications are using non-certified versions of Green Hills software under the auspices that previous versions were deemed secure, then at least one failure of the trust chain has been identified.
In closing, one trusts the code because they trust the auditors. That trust does not extend to the authors of the code, whoever they are.
-Hope
You state that the tool chain issue is not relevent to these vendors because they provide "trusted," meaning certified, platforms. If Open Source is audited and certified, it achieves the same level of value; there is no win there. Whether the source comes from an open process or a proprietary vendor is immaterial.
What you seem to be missing here is that certified code does not change once certified. Once established, the tool chain does not change; therefore, the introduction of malicious code is not possible. If one wishes to patch the original certified source, that becomes a modification which will require an audit if proper procedures are followed, and possibly a waiver depending on the nature of the project.
As I stated before, there is no security "win" here for proprietary vendors. They have existing certifications. Nothing prevents a vendor from getting an Open Source project audited and certified, and the entire tool chain from kernel to compiler need not necessarily be included. We're talking about source code here, not binaries. When the code is compiled and put into production, that compiler will also need to be certified -- or just use an existing certified compiler.
-Hope
Linus only takes patches from the people responsible for appropriate parts of the kernel. To get a patch through requires convincing those individuals -- and they do check the patches. In my experience, getting patches into the kernel is not a trivial matter, in fact it is frustratingly difficult. Futhermore, even if you succeed in getting a patch into some esoteric driver, the less mainstream it is, the less likely it will be in an active kernel.
If the various world governments will go through the trouble to audit defense contractors' code, then they can save themselves some trouble and audit Open Source code instead; any vendor establishing from that base will require less time in audit later. If the governments do not demand an independent audit of contractors' code, then that is where you will find the weak link. With Open Source, you always have the opportunity to audit at any time, diff against previously audited sources, and compile customized code with minimal audited feature sets.
Green Hills is saying "Trust Us! Trust Us!" Open Source is suggesting you trust what you can independently verify before your own experts' eyes.
As for the tool chain issue, you are seriously glossing over the obvious -- all the statements you have made apply to proprietary vendors as well. The solution is simple: don't upgrade the tool chain until the changes pass inspection. This is standard operating procedure for all mission critical deployments.
-Hope
Naturally, with all those spare cycles available, what is a Linux box to do, but look up stuff on the internet. Must be all that server pr0n. Remind me to uninstall Mozilla from all the company servers over the weekend.
-Hope