Maybe so, but the efforts of RMS and Perens are much wider than on any one project. The advocacy of them and others like them introduces people to the concept of freedom in software, and pushes the borders forward.
That's because Hillary Rosen was not a Congresswoman. Btw, who the fuck do you think was bribing congress to get the DMCA and Mickey Mouse Act passed? Hillary Rosen and Jack Valenti.
RMS and Perens care deeply about the freedom of users and developers, and want to ensure that that freedom is there today, tomorrow, and as far into the future as possible. I don't see them as egomaniacs, just guys who have a cause.
Linus, btw, is fully behind the GPL (as the original author of Linux, he could start releasing it under any license he damn well pleased). He released it under the GPL from the start, and that was a large part of his debate with that prick who insisted on using Minix. Linus has just stayed more focused on the Linux code, rather than branching out into advocating the GPL for other software.
This entire scenario illustrates the need for licenses with a clause like that in the Open Software License:
10) Mutual Termination for Patent Action. This License shall terminate automatically and You may no longer exercise any of the rights granted to You by this License if You file a lawsuit in any court alleging that any OSI Certified open source software that is licensed under any license containing this "Mutual Termination for Patent Action" clause infringes any patent claims that are essential to use that software.
In fact, I think that we need to go further, and insert a clause saying that you lose the right to even USE any software licensed under an OSI license with this clause in it if you file a patent, trademark, or copyright lawsuite.
We need to do what we can to prevent crap like this.
It is obvious that the executives of this company have no long-term business plan for SCO. This lawsuit is obviously entirely bogus -- see the OSI position paper on it, and if it had any value IMB would have settled or bought SCO.
Rather than focusing on creating a sound business plan and actually making a good product which consumers want to buy -- something which SCO has failed to do as of yet -- they have chosen to throw baseless allegations around. It generates stock-market interest.
They are obviously planning on doing some insider trading, selling out the investors when the stock is at it's peak, long before the inevitable crash.
As for the allegation that Torvalds can't determine what code contributed is proprietary, no-one can within reasonable means. The best anyone can do is get those contributing to accept responsibility for the contributed code and sign a legal agreement stating that it is their own code. He, nor anyone else, cannot put out bulletins asking the world "is this anyone's proprietary code" before contributing something to the kernel. Many companies would lie and say it was, wasting his time and putting an undue burden on him. Furthermore, he'd have no way of verifying such claims.
The best approach to writing software is exactly what Linus has advocated. Pay no attention to legal patent/copyright, and simply write code. When accepting code from other's, make them claim liability for it, and legally say that it is their own, or code they're allowed to contribute to the best of their knowledge. Trying to find out for sure if contributed code may or may not be copyrighted is an undue burden, and puts additional liability on developers.
Btw, Linux is international. So is GNU software. This lawsuite, even if it's claims of misappropriation are true, will not necessarily force any changes in Linux or GNU/Linux. If any code is SCO's, however, for the convenience of those working in the US, it will rapidly be coded around. This is a non-issue no matter which way you look at it.
That would only make sense if a modular kernel could take advantage of on-going main kernel development. Otherwise, it would be better to start with a new kernel and merely write a driver compatibility layer and Linux personality.
Are you suggesting that such a modular system wouldn't be able to take advantage of on-going Linux kernel development? If so, why?
the "monolithic/modular" distinction should not be expressed in the code but only at load time. That is not easily possible with the current Linux architecture.
Well, I don't know about how easy it is, but there's already loading "modules" (e.g., USB module) instead of compiling them into the kernel. My main gripe with modules is: (1) Not enough things in the Linux kernel menuconfig program are modularizeable; (2) Overhead for modules; (3) You cannot choose which version of the modules to use, so your criticism of serious regressions holds.
if communication within the kernel is based on message passing, then you can choose to load kernel components either into the same address space and context (no more overhead than what Linux has right now) or each into its own separate address spaces. I would guess that QNX is taking an approach like that.
You've exceeded my knowledge of the topic. Could you please explain this.
SCO has violated the GPL in many of the products it has distributed. Thus, authors of the GPL would be entitled to any of SCO's profits from those products.
If SCO can show that Linux is taking sales away from UNIX as a result of the infringement, the Linux vendors would be responsible for the value of the lost sales.
The only way SCO can do that is to show that the Linux kernel has taken much from SCO proprietary code, and that what it took would not have easily been coded around anyways. This is highly doubtful, as: (1) Nothing was taken from SCO anyways; (2) If anything was taken, it is most certainly miniscule compared to the code-size of the Linux kernel; (3) Any such code would have easily been coded around anyways. Simply put, IBM's conributions to Linux -- even if they were of SCO code -- are in no way responsible for GNU/Linux' growth. Whatever was contributed would have been coded anyways (if there actually is any infringing code brought up by SCO -- which will certainly not be the case -- it will be coded around long long before the trial is over, making this a moot issue). Furthermore, SCO forfeited any right to such non-sense by distributing a GNU/Linux distro itself, thus officially releasing any code they owned that they claim is in the Linux kernel, to the public under the GPL. SCO's descent into a bankrupcy-destined company can be contributed to them having no useful products, no business model, poor customer service, and incompetent management.
In any event, the GNU/Linux -- not Linux -- vendors would not be the ones paying anything, as they had no possible way of determining that the code contributed by IBM was infringing, nor did any developers. The only individuals who had the means to determine if infringing code was being contributed (outside of SCO, who are obviously lying) is IBM. Thus, only IBM can be held liable for damages, as IBM was the only entity with the capability of determining if the code contributed was infringing.
"...we're talking about entire programs
No, actually, not true. This lawsuite revolves around the Linux kernel, not "entire programs".
Regardless, since GNU/Linux far exceeds the pathetic capabilities of SCO-UNIX -- both in hardware support and in what it can do -- it is highly doubtful that anything was taken from SCO.
Also, if this case had any merit, IBM would have either settled our bought SCO to put an end to the matter. Obviously, the case does not have any merit, as they feel the cheapest way to resolve it is through the civil courts (which would not be the cheapest way if there were any chance that IBM would los).
Well, all of your points are true; the problem is that relying on other idiots to buy it at an even more over-valued price than you bought it at is not wise. Furthermore, you never know when the bubble will burst.
I was under the impression that BSD used Mach as it's kernel. Apparently, I'm wrong. However, Mach most certainly is a micro-kernel. Furthermore, there is no FOSS OS using a micro-kernel that has adequate (e.g., HP deskjet printer support) hardware support.
Giving them back any profits they made as a *result of the infringement*. If the infringement constitutes 1/1000 of their code, then it is only reasonable that they pay 1/1000 of their profits from that code. This may not even be reasonable, as it is likely that they would have coded a replacement otherwise.
In the case of Linux developers, they did not make money from it, so there is no profit for them to give SCO, nor would any court rule such. They also had no way of knowing -- or determining -- that IBM's contributions had proprietary code in them. Are they to ask every proprietary company in the world before accepting a submission? And then of course many of them will lie, saying the code is infringing when it isn't. This is an unreasonable burden on FOSS developers that no court would impose.
In other words, one cannot be held liable for damages (money) for an infringement which one had no possible way of knowing that one was committing. The system cannot create a catch-22. That's unconstitutional. If proprietary software (secrets) is to be allowed, then you cannot force individuals to pay money to proprietary developers for infringements which they had no way of knowing that were occuring (as they have no way of knowing what is infringing).
Btw, I believe the Frena case was an example of where the individual was aware of what his or her actions were doing, but was not aware that the law declared them to be infringement. This is analagous to "ignorance of the law is no defense". It is completely different from having no way of knowing that one's action was infringing, because one had no way of knowing that the material in question was copyrighted. This is the way things would be in the SCO case, since their code is proprietary, and no-one -- aside from IBM -- could possibly know what code was or was not SCO's proprietary code. Thus, no-one else can be held liable for damages.
Holding other individuals liable for damages -- e.g., the developers working on Linux, to which IBM contributed -- for IBM's having contributed proprietary code would be unconstitutional, and would never hold up before the USSC, because individuals who do not have access to SCO's proprietary code have no way of knowing if any code contributed to their projects is infringing on SCO's code.
The nature of non-modular things means that they can regress in serious ways (because everything's bunched together). However, the Linux kernel has some pretty significant advantages over the main micro-kernel competitor (BSD's Kernel). It supports more hardware (try getting an HP OfficeJet to work on *BSD). Furthermore, more programs will work with it.
So, if you really feel the way you do about the Linux kernel, I suggest you start a project with the goal of trying to take the code in the Linux kernel and modularize it.
Modularized kernels also have some performance problems. Whereas monolithic kernels tend to use up more memory (due to everything being in the kernel), microkernels require all of the various parts to communicate with each-other. This creates overhead. Thus, I suggest the following solution.
I think the best solution is in a modular development process of the kernel, but a monolithic+microlithic end-user experience. To avoid serious regressions, development process should be modular (e.g., end-users can choose to get the 2.4.19 USB2 or the 2.4.20 USB2, thus avoiding regression issues). For things which the user knows he or she will always be using, why should they be separately modular, having to communicate with eachother and create over-hang? For things which the end-user will sometimes or rarely need in the kernel, it makes sense to use the modular approach, and only load them when needed, despite the overhang (because their use is rare).
True, market illusions are a part of reality. They are only beneficial to the investor, however, when they undervalue a stock. An over-valued stock like SCO is a time-bomb waiting to explode.
(1) You'd be stupid to think SCO has any chance of winning this lawsuite.
(2) Even if they do, they won't get their money for years, because IBM will appeal.
(3) Because of appeals, they will pre-emptively piss away any billions they could have gotten.
(4) Billions of dollars still doesn't change the fact that this company has no product, no management, and no future. It only delays the inevitable filing for bankruptcy.
(5) There is no reliable way to invest in stocks if you want short-term results, except for insider trading, which is illegal.
(6) Thus, anyone who buys SCO's stock is an imbecile. But, it's the 50% of losing imbeciles on Wall Street that allow the rest of us to be winners.
Sorry, but in the US, one can't be held liable for something which he had no way of knowing or controlling. Any ruling forcing an individual to pay money for an infringement he had no way of knowing about -- as is the case, if you are not the misappropriator, with proprietary software -- would be struck down by higher courts as unconstitutional.
The point is, that since macro-kernel's are much easier to get into initially and maintain, they will be superior in practice, despite their inferiority in theory. This is because more programmers will be working on making them better. If a theoretically inferior design is much easier to work on and understand in practice, it will be better than a theoretically superior design -- in practice. If you don't get this obvious point, then there's no hope for you.
(1) So what if you were found in violation of the other companies license. Since you made a replacement, you had no need of their original software. Nothing in the law can prevent you from using your replacement.
(2) One is only legally liable if one had knowledge of infringement. If IBM inserted proprietary code into Linux in violation of their license agreements, they and no one else is responsible. No-one else had any way of knowing that IBM did that. By the definition of proprietary (secret) code, it is impossible for anyone else -- other than IBM and SCO -- to know if IBM inserted proprietary code into any FOSS.
Primitive species of the homo genus were specialists. One of them was a specialist in eating the toughest of tough leaves and other vegetation. Specialists are unchallenged and supreme in their area. We -- homo sapiens -- suck at eating tough vegetation compared to earlier relatives, which went extinct ages ago.
Specialists, however, lack the ability to efficiently evolve, change, and adapt.
It is important that whatever approach you take -- if you want it to succeed in the long run -- should attract developers to your idea and keep them there. Obviously, micro-kernel's haven't done that. Irrelevant of their *theoretical* advantages if done just right. Who cares if they might be more efficient or faster theoretically if they don't attract any developers and take forever to evolve? Monolithic kernels, despite their theoretical inferiority, will be faster and more efficient because more developers will be working on them, and will be able to resolve inefficiencies faster.
Unless SCO patented the methodology, then coding a replacement and having seen SCO's original code does not mean you can't make an equivalent original. SCO has to prove that the person didn't create an original. Also, people are not computers. They will not remember lines and lines of code with any precision, so the entire argument that they can't create a functional original is BS. If the SCO code was patented, all they need do is use a different methodology, unless it was something generic (generic "only solutions" or "common solutions" or "obvious solutions" are not patentable, as there's nothing unique about them).
Who cares if IBM is in violation of SCO's license? That has nothing to do with IBM contributing to FOSS.
No consistently winning stock-investor has relied on selling short. It is speculation. Winning stock-investors spend their effort trying to determine which companies are undervalued, likely to grow, and which have good management. They don't waste time on unreliable losing tactics like selling short.
What you are suggesting is timing SCO's stock, something which is impossible to do reliably. You would have to sell at the peak, just before the bubble burst and people realized that SCO has no earnings, no profit, loads of debt, no business plan, and incompetent management. And you never know when people will realize this. It could happen tomorrow.
Slashdot Mirror
Maybe so, but the efforts of RMS and Perens are much wider than on any one project. The advocacy of them and others like them introduces people to the concept of freedom in software, and pushes the borders forward.
That's because Hillary Rosen was not a Congresswoman. Btw, who the fuck do you think was bribing congress to get the DMCA and Mickey Mouse Act passed? Hillary Rosen and Jack Valenti.
Politics is everywhere and in everything.
RMS and Perens care deeply about the freedom of users and developers, and want to ensure that that freedom is there today, tomorrow, and as far into the future as possible. I don't see them as egomaniacs, just guys who have a cause.
Linus, btw, is fully behind the GPL (as the original author of Linux, he could start releasing it under any license he damn well pleased). He released it under the GPL from the start, and that was a large part of his debate with that prick who insisted on using Minix. Linus has just stayed more focused on the Linux code, rather than branching out into advocating the GPL for other software.
This entire scenario illustrates the need for licenses with a clause like that in the Open Software License:
10) Mutual Termination for Patent Action. This License shall terminate automatically and You may no longer exercise any of the rights granted to You by this License if You file a lawsuit in any court alleging that any OSI Certified open source software that is licensed under any license containing this "Mutual Termination for Patent Action" clause infringes any patent claims that are essential to use that software.
In fact, I think that we need to go further, and insert a clause saying that you lose the right to even USE any software licensed under an OSI license with this clause in it if you file a patent, trademark, or copyright lawsuite.
We need to do what we can to prevent crap like this.
It is obvious that the executives of this company have no long-term business plan for SCO. This lawsuit is obviously entirely bogus -- see the OSI position paper on it, and if it had any value IMB would have settled or bought SCO.
Rather than focusing on creating a sound business plan and actually making a good product which consumers want to buy -- something which SCO has failed to do as of yet -- they have chosen to throw baseless allegations around. It generates stock-market interest.
They are obviously planning on doing some insider trading, selling out the investors when the stock is at it's peak, long before the inevitable crash.
As for the allegation that Torvalds can't determine what code contributed is proprietary, no-one can within reasonable means. The best anyone can do is get those contributing to accept responsibility for the contributed code and sign a legal agreement stating that it is their own code. He, nor anyone else, cannot put out bulletins asking the world "is this anyone's proprietary code" before contributing something to the kernel. Many companies would lie and say it was, wasting his time and putting an undue burden on him. Furthermore, he'd have no way of verifying such claims.
The best approach to writing software is exactly what Linus has advocated. Pay no attention to legal patent/copyright, and simply write code. When accepting code from other's, make them claim liability for it, and legally say that it is their own, or code they're allowed to contribute to the best of their knowledge. Trying to find out for sure if contributed code may or may not be copyrighted is an undue burden, and puts additional liability on developers.
Btw, Linux is international. So is GNU software. This lawsuite, even if it's claims of misappropriation are true, will not necessarily force any changes in Linux or GNU/Linux. If any code is SCO's, however, for the convenience of those working in the US, it will rapidly be coded around. This is a non-issue no matter which way you look at it.
What makes you think Hillary Rosen was any better? According to you, Hillary Rosen didn't want to eliminate fair use and make copyright perpetua?
That would only make sense if a modular kernel could take advantage of on-going main kernel development. Otherwise, it would be better to start with a new kernel and merely write a driver compatibility layer and Linux personality.
Are you suggesting that such a modular system wouldn't be able to take advantage of on-going Linux kernel development? If so, why?
the "monolithic/modular" distinction should not be expressed in the code but only at load time. That is not easily possible with the current Linux architecture.
Well, I don't know about how easy it is, but there's already loading "modules" (e.g., USB module) instead of compiling them into the kernel. My main gripe with modules is: (1) Not enough things in the Linux kernel menuconfig program are modularizeable; (2) Overhead for modules; (3) You cannot choose which version of the modules to use, so your criticism of serious regressions holds.
if communication within the kernel is based on message passing, then you can choose to load kernel components either into the same address space and context (no more overhead than what Linux has right now) or each into its own separate address spaces. I would guess that QNX is taking an approach like that.
You've exceeded my knowledge of the topic. Could you please explain this.
SCO has violated the GPL in many of the products it has distributed. Thus, authors of the GPL would be entitled to any of SCO's profits from those products.
If SCO can show that Linux is taking sales away from UNIX as a result of the infringement, the Linux vendors would be responsible for the value of the lost sales.
The only way SCO can do that is to show that the Linux kernel has taken much from SCO proprietary code, and that what it took would not have easily been coded around anyways. This is highly doubtful, as: (1) Nothing was taken from SCO anyways; (2) If anything was taken, it is most certainly miniscule compared to the code-size of the Linux kernel; (3) Any such code would have easily been coded around anyways. Simply put, IBM's conributions to Linux -- even if they were of SCO code -- are in no way responsible for GNU/Linux' growth. Whatever was contributed would have been coded anyways (if there actually is any infringing code brought up by SCO -- which will certainly not be the case -- it will be coded around long long before the trial is over, making this a moot issue). Furthermore, SCO forfeited any right to such non-sense by distributing a GNU/Linux distro itself, thus officially releasing any code they owned that they claim is in the Linux kernel, to the public under the GPL. SCO's descent into a bankrupcy-destined company can be contributed to them having no useful products, no business model, poor customer service, and incompetent management.
In any event, the GNU/Linux -- not Linux -- vendors would not be the ones paying anything, as they had no possible way of determining that the code contributed by IBM was infringing, nor did any developers. The only individuals who had the means to determine if infringing code was being contributed (outside of SCO, who are obviously lying) is IBM. Thus, only IBM can be held liable for damages, as IBM was the only entity with the capability of determining if the code contributed was infringing.
"...we're talking about entire programs
No, actually, not true. This lawsuite revolves around the Linux kernel, not "entire programs".
Regardless, since GNU/Linux far exceeds the pathetic capabilities of SCO-UNIX -- both in hardware support and in what it can do -- it is highly doubtful that anything was taken from SCO.
Also, if this case had any merit, IBM would have either settled our bought SCO to put an end to the matter. Obviously, the case does not have any merit, as they feel the cheapest way to resolve it is through the civil courts (which would not be the cheapest way if there were any chance that IBM would los).
Well, all of your points are true; the problem is that relying on other idiots to buy it at an even more over-valued price than you bought it at is not wise. Furthermore, you never know when the bubble will burst.
I was under the impression that BSD used Mach as it's kernel. Apparently, I'm wrong. However, Mach most certainly is a micro-kernel. Furthermore, there is no FOSS OS using a micro-kernel that has adequate (e.g., HP deskjet printer support) hardware support.
Giving them back any profits they made as a *result of the infringement*. If the infringement constitutes 1/1000 of their code, then it is only reasonable that they pay 1/1000 of their profits from that code. This may not even be reasonable, as it is likely that they would have coded a replacement otherwise.
In the case of Linux developers, they did not make money from it, so there is no profit for them to give SCO, nor would any court rule such. They also had no way of knowing -- or determining -- that IBM's contributions had proprietary code in them. Are they to ask every proprietary company in the world before accepting a submission? And then of course many of them will lie, saying the code is infringing when it isn't. This is an unreasonable burden on FOSS developers that no court would impose.
To actually force you to post their rebuttal they almost certainly need some kind of ruling by a judge.
Two other things they need:
(1) For him to actually live in Europe, so that they have jurisdiction over him.
(2) A substantial punishment if he doesn't public the response. If there is no punishment for not publishing the response, why would he?
In other words, one cannot be held liable for damages (money) for an infringement which one had no possible way of knowing that one was committing. The system cannot create a catch-22. That's unconstitutional. If proprietary software (secrets) is to be allowed, then you cannot force individuals to pay money to proprietary developers for infringements which they had no way of knowing that were occuring (as they have no way of knowing what is infringing).
Btw, I believe the Frena case was an example of where the individual was aware of what his or her actions were doing, but was not aware that the law declared them to be infringement. This is analagous to "ignorance of the law is no defense". It is completely different from having no way of knowing that one's action was infringing, because one had no way of knowing that the material in question was copyrighted. This is the way things would be in the SCO case, since their code is proprietary, and no-one -- aside from IBM -- could possibly know what code was or was not SCO's proprietary code. Thus, no-one else can be held liable for damages.
Holding other individuals liable for damages -- e.g., the developers working on Linux, to which IBM contributed -- for IBM's having contributed proprietary code would be unconstitutional, and would never hold up before the USSC, because individuals who do not have access to SCO's proprietary code have no way of knowing if any code contributed to their projects is infringing on SCO's code.
The nature of non-modular things means that they can regress in serious ways (because everything's bunched together). However, the Linux kernel has some pretty significant advantages over the main micro-kernel competitor (BSD's Kernel). It supports more hardware (try getting an HP OfficeJet to work on *BSD). Furthermore, more programs will work with it.
So, if you really feel the way you do about the Linux kernel, I suggest you start a project with the goal of trying to take the code in the Linux kernel and modularize it.
Modularized kernels also have some performance problems. Whereas monolithic kernels tend to use up more memory (due to everything being in the kernel), microkernels require all of the various parts to communicate with each-other. This creates overhead. Thus, I suggest the following solution.
I think the best solution is in a modular development process of the kernel, but a monolithic+microlithic end-user experience. To avoid serious regressions, development process should be modular (e.g., end-users can choose to get the 2.4.19 USB2 or the 2.4.20 USB2, thus avoiding regression issues). For things which the user knows he or she will always be using, why should they be separately modular, having to communicate with eachother and create over-hang? For things which the end-user will sometimes or rarely need in the kernel, it makes sense to use the modular approach, and only load them when needed, despite the overhang (because their use is rare).
True, market illusions are a part of reality. They are only beneficial to the investor, however, when they undervalue a stock. An over-valued stock like SCO is a time-bomb waiting to explode.
(1) You'd be stupid to think SCO has any chance of winning this lawsuite.
(2) Even if they do, they won't get their money for years, because IBM will appeal.
(3) Because of appeals, they will pre-emptively piss away any billions they could have gotten.
(4) Billions of dollars still doesn't change the fact that this company has no product, no management, and no future. It only delays the inevitable filing for bankruptcy.
(5) There is no reliable way to invest in stocks if you want short-term results, except for insider trading, which is illegal.
(6) Thus, anyone who buys SCO's stock is an imbecile. But, it's the 50% of losing imbeciles on Wall Street that allow the rest of us to be winners.
Sorry, but in the US, one can't be held liable for something which he had no way of knowing or controlling. Any ruling forcing an individual to pay money for an infringement he had no way of knowing about -- as is the case, if you are not the misappropriator, with proprietary software -- would be struck down by higher courts as unconstitutional.
The point is, that since macro-kernel's are much easier to get into initially and maintain, they will be superior in practice, despite their inferiority in theory. This is because more programmers will be working on making them better. If a theoretically inferior design is much easier to work on and understand in practice, it will be better than a theoretically superior design -- in practice. If you don't get this obvious point, then there's no hope for you.
(1) So what if you were found in violation of the other companies license. Since you made a replacement, you had no need of their original software. Nothing in the law can prevent you from using your replacement.
(2) One is only legally liable if one had knowledge of infringement. If IBM inserted proprietary code into Linux in violation of their license agreements, they and no one else is responsible. No-one else had any way of knowing that IBM did that. By the definition of proprietary (secret) code, it is impossible for anyone else -- other than IBM and SCO -- to know if IBM inserted proprietary code into any FOSS.
Primitive species of the homo genus were specialists. One of them was a specialist in eating the toughest of tough leaves and other vegetation. Specialists are unchallenged and supreme in their area. We -- homo sapiens -- suck at eating tough vegetation compared to earlier relatives, which went extinct ages ago.
Specialists, however, lack the ability to efficiently evolve, change, and adapt.
It is important that whatever approach you take -- if you want it to succeed in the long run -- should attract developers to your idea and keep them there. Obviously, micro-kernel's haven't done that. Irrelevant of their *theoretical* advantages if done just right. Who cares if they might be more efficient or faster theoretically if they don't attract any developers and take forever to evolve? Monolithic kernels, despite their theoretical inferiority, will be faster and more efficient because more developers will be working on them, and will be able to resolve inefficiencies faster.
Unless SCO patented the methodology, then coding a replacement and having seen SCO's original code does not mean you can't make an equivalent original. SCO has to prove that the person didn't create an original. Also, people are not computers. They will not remember lines and lines of code with any precision, so the entire argument that they can't create a functional original is BS. If the SCO code was patented, all they need do is use a different methodology, unless it was something generic (generic "only solutions" or "common solutions" or "obvious solutions" are not patentable, as there's nothing unique about them).
Who cares if IBM is in violation of SCO's license? That has nothing to do with IBM contributing to FOSS.
No consistently winning stock-investor has relied on selling short. It is speculation. Winning stock-investors spend their effort trying to determine which companies are undervalued, likely to grow, and which have good management. They don't waste time on unreliable losing tactics like selling short.
What you are suggesting is timing SCO's stock, something which is impossible to do reliably. You would have to sell at the peak, just before the bubble burst and people realized that SCO has no earnings, no profit, loads of debt, no business plan, and incompetent management. And you never know when people will realize this. It could happen tomorrow.