When I was a manager over an IT department, we sometimes got Ph.D. holding candidates interviewing for the position of scriptwriter/setup technician.
We were worried that such an overqualified candidate would soon become dissatisfied with the job, or would require a higher pay than we could afford for the position. It was really not a good fit for the job.
I realize that in this economy, a lot of really educated people are in need of work. My suggestion to those is that they do not advertise their higher degrees with jobs that they are overqualified for. If you are satisfied with menial work, then it doesn't matter if you have an advanced degree - don't show it off.
If you are getting your Ph.D. as a career move, make sure your job description matches your education, otherwise it was a waste of time. You don't need a Ph.D. to be a scriptwriter.
But what is preventing SCO from adding in code from Linux (which is openly available) into their (closed) UNIX code and then claiming is was there first and was 'stolen' by Linux? C'mon, we are not expecting SCO's management to play fair here - how hard would it be to backdate code additions?
Because every line of code in the Linux source control system has somebody's name on it. If they contribute their own code to the Linux kernel, it has to go through an acceptance process by Linus or one of the Linux stewards. If it turns out to be SCO code, then we know who can account for it, and can investigate their ties with SCO.
When Ransom was the new CEO of SCO, he was full of Open Source ideology.
In those days, SCO was asked about moving Unix IP into Linux. Ransom said they were doing their best to "open up" the Unix technologies, but that a lot of things belonged to 3rd parties, and SCO didn't have the rights to them. See this article.
Then we have Ransom's LinuxWorld 2001 keynote where he discusses SCO's role in helping IBM get enterprise features into Linux. One of his statements went as follows: "But clearly we are going to add components back to the Linux kernel on both IA-32 and IA-64 platforms". This was during the whole Monterey project as I recall.
So if you look at SCO in this context, you get the idea that they knew very much what was going on, that they sanctioned it, and that they probably even helped expedite it. It doesn't make sense for Ransom to start raising IP questions when he has made statements about SCO's support of Enterprise Unix features in Linux.
Benifit of the doubt though, insider selling does happen in companies to take profit, and if you look at SCO's 1 year preformance going from 95 cents to 16 dollars at it's recent peak (an increase of nearly 1,700%), you would see why it would seem intelligent to sell.
This seems reasonable until you realize that the stock's current value is a direct result of unproven allegations. It is not hard to correlate SCO's stock value with the disinformation that has been spread by SCO's own executive officers.
These executives may claim they don't have any control over the stock price, but this is simply false. The content and delivery of their press releases directly affects their stock prices whether they intend it to or not. They certainly have control over what they say, and can therefore influence the price of their shares.
When SCO's allegations are proven wrong, then it becomes a matter of stock manipulation. In this scenario, criminal charges might be brought against those involved in the scheme.
This is why I have a hard time believing that McBride et al would knowingly perpetrate such a huge fraud. I admit that the ballance of public evidence is decidely NOT in SCO's favor. In the Post-Enron business world, corporate legerdemain is madness. It doesn't make sense - none of this does.
And yet, if SCO truly had a trump card, they already missed their chance at playing it by being irresponsible, unethical and unprofessional in the way they are handling their dispute. I can't believe those guys are this stupid; surely we have missed something.
Alas, it is as Hitler wrote. The "Big Lie" is harder to dismiss than the little one. It is so fantastically absurd that we question our own judgement against it.
Since Microsoft is such a respecter of other people's IP rights, why oh why didn't they imediately license these patents?
I guess that Internet Explorer is such an obscure product, they figured they could just get away with it. The same goes for those pesky DRM patents that affect their "niche" OSes such as Windows XP.
Thank goodness Microsoft had the sense to license questionable Unix IP for their wildly popular Unix Compatibility layer. If they ran into trouble with that program, it would surely sink the company.
Tell that to the users that SCO is threatening. What they need is something to feel good about. If that means setting up a useless legal fund for users, then do it.
Why the hell would MS and Sun be spouting about how they indemnify their users against legal threats?
If you look at the competitive space where Linux is growing up, you see two kinds of companies striving for business.
One kind of company sees the writing on wall. These companies realize what FLOSS is, and have redefined themselves under this new reality. These companies are usually content to compete on a level playing field in this respect. They are all trying to incorporate Linux and Open Source into their business, with various degrees of success. Most companies fit into this group: IBM, Novell, Oracle, SGI, Dell, etc.
The other kind of company will settle for no less than complete domination of the market on their own terms: Sun and Microsoft. Sun is interesting because it wants to play both sides of the fence, but I gather they would rather NOT share in the Linux goodness with their competitors if they can help it.
Microsoft will sit and deny that Linux is even viable until they are completely engulfed by it. Witness the Internet.
These enemies of Linux and Free/Open Source have discovered their anti-Linux efforts to be futile. According to leaked Microsoft documents, smear campaigns were in fact counter-productive. The interesting conclusion was that the best attack on Linux was a legal attack. Apparently Microsoft's market research shows that fear of being sued is the biggest deterrent to Linux deployments.
So this is their trump card. If they can stir up fear of litigation, they can point at Linux and say, "Look, no indemnification there! Buy us instead." SCO is just a pawn in this gambit - I don't think anyone expects them to survive the play.
By providing a legal fund to developers of GPL software, Red Hat begins to undermine these tactics used by Microsoft and Sun.
I like this fund because it appears to benefit the community as a whole and not just Red Hat customers. I sincerely hope that other companies pick up on this idea, and decide to contribute to the fund.
If anything, this gives us an idea of how we can provide indemnification to Linux users in general. Perhaps a general fund for all Linux _users_ would be appropriate, with the option to purchase a renewable policy against it (from a community run non-profit group). The community could evaluate claims against this "insurance" and assign legal resources to litigate it if needed. At any rate, owning a policy would guarantee a level of financial coverage. Non-policy owners could also get help, depending on circumstances and the merits of their case.
I see this as a way for the politicaly motivated community members to contribute where they might not be able to give code.
Do you see something in Moglen's paper that isn't certifiably factual?
Do you see something in Moglen's paper that ignores SCO's side of the argument?
It's hard to be unbiased when the only available facts are so one-sided.
Some people like to ignore facts if it helps them look less "biased," because facts tend to lead the mind to certain conclusions. I mean, we wouldn't want actual critical thought at the expense of giving both parties equal benefit of the doubt, would we?
So far, I have yet to see one single, tangible, FACT from SCO that would support their claims in the least amount. And yet I see all sorts of "journalism" that lends credibility to SCO's claims for the sake of "unbiased" reporting.
What a load of crap. Try walking into any big company and suggesting that you should be able to run linux on your desk.
It's not uncommon to see Linux or even FreeBSD on business desktops. I worked on a technical team that used 90% Linux and 10% FreeBSD. This was in 1998.
Ok, ok, it wasn't a "big company", and it was mostly just my team. But it is out there.
In 2000 I took a tour of a mid-sized manufacturing company called Action Target. They were 100% Linux on the desktop, running a system called Wyatt-ERP. This handled everything from AR to call tracking, and integrated with their phone system to boot. They had a little win 98 box in a closet, in case there was need to convert a Word document.
Linux is certainly an increasingly viable desktop platform, particularly for small and medium sized businesses, and it is definitely getting used.
This is a necessary and important step in how the future will play out. If Linux is materially hurt by SCO's allegations, then SCO might be held liable for those damages.
Unlike the alleged damages that SCO claims, we can quantify and prove the sort of damage that is being done to Linux right now, just by pointing at the media and industry analysts.
In the past, media and analysts never said "Hey, Linux is killing SCO," which is what SCO claims happened. But now we see all kinds of people clamoring about how SCO is killing Linux.
Without solid proof of harm, Linux vendors, users and developers have little cause for action against SCO. Now that is changing, and SCO can start getting worried. We have more than allegations.
If you are a Linux user, then you have been officially threatened. SCO may claim that they only go after fortune 1000, but they made it clear that ALL Linux users are infringing, and liable for infringement unless a UnixWare license is purchased.
If you feel threatened by this attitude from SCO, then you need to take it to the FTC because where you live, extortion is most likely illegal.
SCO is not licensing Linux under another license. They are selling a license to UnixWare and saying that they won't sue you for using Linux if you have the UnixWare license.
In other words, "Buy UnixWare or risk being sued."
I would say that this plan fits very nicely under the dictionary description of extortion, and I recommend all Linux users file a complaint with the FTC. SCO has not proven that they have any rights over Linux at all, and therefore any such threats used to sell licenses are illegal.
Yes, in order to claim infringement in a court of law (in the U.S.), your copyright must be registered.
It is true that any work you produce can be automatically copyrighted unless you specifically state otherwise. You do not need to register anything to put a copyright notice on your work.
However, if you want to litigate your copyright, you have to make sure that you have registered the copyright with the government. You can register it after the work has been created, although there may be some date limitations on certain types of media.
Copyright is transferable, but again, this needs to be documented.
If AT&T has never transferred their copyright with the Unix IP that was sold, then AT&T still owns the copyright on SVr4. The copyright that SCO has registered is either for a derivative SVr4 that they are basing their claims on, or else it infringes on the AT&T copyrights, which could be a serious problem for SCO.
If SCO bases their licensing scheme on this new copyright, then I suggest that this license is fraudulent, and should be investigated.
At any rate, the original SVr4 code never had any of the features that SCO claims infringe. Apparently they are saying that they own the copyright to IBM's work because IBM put it into an SVr4 derived system. IBM also donated some code to Linux. Because IBM's code is in a derivative work, SCO says they have a contract that gives them rights to it, and that the existence of such code in Linux is a violation of said contract. So, really, it is unclear just what SCO is claiming copyright on and what they are claiming is a license violation.
It is extremely doubtful that SCO can claim copyright on IBM's code. In fact, it is unlikely that SCO has a single claim that is anything but dubious. I am very curious about why David Boies would further damage his reputation over such a poor case.
I believe that the original authors of a work may revoke a transfer of copyright, but I think that this does not apply to a work-for-hire. In this case, I am not sure if the original company has the same right. It may be, however, that AT&T becomes a big player in this debacle before all is said and done.
Registering a copyright allows you to litigate for damages - either real or statutory - for infringement.
There are no "punative" damages applied to copyright law.
Since it is a civil matter, the penalties deter mostly small-scale infringers since you really can't get more than $30,000 on statutory (up to $150,000 on willful infringement). They would probably try to inflate their "actual losses" to get the most out of infringement cases against big businesses, but they could also go after any Linux users for licensing fees or statutory damages.
If you thought the bad vibes against SCO were serious before now, just wait. This is where everybody - not just IBM - starts to sit on pins and needles. This is where Red Hat, SuSE, Mandrake, Debian, etc., etc. start to get worried. This is where the threat becomes a direct assault on all of these businesses. This is where the GPL either stands or falls. This is the crux of the Open Source revolution, and we about to see what it is made of.
I think SCO will make one, perhaps two more mis-steps down this road, and then the restraint of all will come down. I see lawsuits from the FSF, RedHat, the OSI, and perhaps all Linux copyright holders (what of them, SCO? You seem to indicate that they are all complice to the infringement, these "criminal" volunteers). I see a breach of contract suit from the FSF. I see various attempts at class-action suits. I see non-core Linux developers (3rd party Open Source developers) attempting lawsuits. In brief: litigious chaos.
I predict very bad behavior from some in the Linux community, and I REALLY hope that they will keep their cool. It looks like SCO has no clue of the magnitude of bad feelings they are generating.
If I recall, the FSF owns a number of copyrights on code in the Linux Kernel, including some bits contributed by IBM that may be in question.
To date, the only FSF response to SCO has been a subtle Linux should really be called "GNU/Linux" diatribe (See! we told you so!).
The most informative SCO response to date is still the OSI position paper by Eric Raymond et al.
I believe that the FSF and the OSI, in addition to the other Kernel copyright holders, should indeed seek legal action against SCO. I would like to see something spectacular, although any countersuit is likely to be limited - due to the nature of copyright law. I think the obvious action is simply to force SCO to disclose what infringing code exists.
This assumes, though, that the disclosed code really does infringe, which is somewhat unlikely (it was never in the interest of Linux development to allow proprietary code).
I think there is a lot the Linux developers could do to mitigate the damages on our side.
The Linux stewards need to lay to rest the myth that we don't really know where all of our code came from. Every line of code in the project has somebody's name on it, and there is someone out there who can vouch for it. If, in this process, we discover some holes, we have the power to fix them - we don't depend on SCO to tell us what is clean and what is not clean. It is dangerous to let SCO tell us what is theirs and what is ours because they are bent on claiming as much as posible, now matter how ridiculous the connection.
Having a very public Linux Accountability Project does a huge amount of good for the Linux cause.
1) There are very few commercial organizations that have anything like it. In addition to a totally transparent development model, in which all of the "property" can be examined by the public, the fact that the Linux community itself stands behind every line of code lends more credibility to it than any closed-source program.
2) It establishes a factual base from which to discuss the SCO claims. Currently, the only context that we have for discussion is SCO's outrageous allegations. We have the code, why don't we talk about it on our terms? Why must we prove SCO wrong? Why shouldn't they have to prove themselves right instead? This would be the case if we had a public manifest of all aspects of the Linux Kernel. If the public could see who the players are with a brief description of the origins of the features and a statement from the developers themselves, then SCO might have a lot more explaining to do.
I believe that this sort of a project can be accomplished in a reasonable amount of time. It might delay further development on Linux for a little while - losses that would be quantified and then extraced from SCO in the countersuits to follow - but it would be well worth it.
I also highly recommend that every Open Source developer keep a detailed log of all of their development so that, at any time, complete accountability can be made for your program. Don't let greedy corporations claim your work!
Well, I've digressed from the topic, so I'll shut up...
There are various standards of writing. In American technical writing practice, we adhere to the standards presented by the APA (American Psycological Assoc. if I recall).
This standard is extremely strict when it comes to crediting sources for research papers. If I use even a single word that is unique enough to the work of a particular expert on the subject I am writing about, then I am supposed to provide source information or I risk being accused of plagiarism. This is a reality in America; perhaps in the UK your standards allow for a greater license with technical writing.
This does not mean that we are discouraged from reading other works. Quite the contrary, we need as many sources to support our thesis as possible.
The point is that, when I contribute my OWN opinions and observations, it's best if I don't worry about what other people have written. This is where I'm trying to draw the parallel. Perhaps it is a poor example, though.
SCO seems to have changed directions on this issue too.
In the beginning we heard a lot about code "theft". There was a promised "show and tell" time that turned out to be mostly a joke.
Now SCO is talking more about code that has been donated that also appears in derivative works, not directly owned by SCO. For example, JFS is an IBM technology, but SCO wants rights to it based on licensing verbiage in the antiquated AT&T contract that has never been enforced until now.
They are damaging their argument of "Mututal Mistake", which might get them out of their GPL obligations, by claiming such things. Clearly they always knew of IBM's contributions to Linux in general, which they now decry based on the fact that the same features appear in AIX.
It is very clear from this behavior that SCO is not so much interested in protecting IP as it is in destroying Linux. The question is why?
Quite a turn about for the SCO that was promising to give Unix IP to the Open Source community back in 2000.
This is the same sort of advice I got in my Technical Writing class.
As you know, plagiarism is a very serious offense in many types of writing. It can be serious enough to get a student disqulified or expelled.
The less you worry about what other people have said on the subject you are writing about, the less your chances are of plagiarism. Writers who constantly check their sources for exact phraseology to ensure they aren't "infringing" actually tend to use idioms and vocabulary from the sources they are trying to avoid copying.
You will not find much of what we consider "enterprise" features in any SVR4 code because of its age.
What we have are companies who are donating their own enterprise innovations, which they have also included in their SVR4 *derived* systems.
SCO is trying to say that, for example, AIX is a derivative of SVR4, which is owned by SCO. Therefore, SCO has certain rights to the improvements that IBM makes to AIX (in a round-about way). If IBM contributes some of their improvements from AIX to Linux, then SCO says that IBM is breaking their contract with SCO.
So what we see now is that SCO is claiming a lot of advanced technology that they never really "owned" at all, but they want to prove that, indirectly, they really did have rights to it.
I believe one of the analysts who examined the SCO and Linux code under the NDA, indicated that the code shown was SVR4 code. If this is the case, it was most likely from BSD.
At any rate, this is a serious departure from their plans in August of 2000. At that time, Ransom Love was promising to release whatever code he could into the Open Source Community, and he even speculated on the use of the GPL as the license that SCO might use. Interestingly, he mentioned that some improvements could not be released because they were owned by other companies. SCO would now like to have us believe that they own all of that code.
History shows that in fact SCO never really got around to releasing the promised code, maybe because other companies (IBM and HP) had already stepped up and contributed their own features. Part of SCO's "sour grapes" might be due to the fact that they thought they would be a much bigger player since they owned Unix IP, when actually other companies had far surpassed them already.
The current state of affairs represents turnabout on SCO's part. They made some statements in bad faith back in August of 2000. They are now actively trying to thwart an international organization of volunteers, who have contributed their work to the world.
IBM and other companies may be able to stand up for themselves, but they do not have the same stewardship over Linux that the greater Linux Community has.
SCO has made an affront to the uncounted hobbyists and enthusiasts that are proud to claim Linux as their own. They have slandered and derided. There are those contributors who have been hurt by these actions.
We cannot afford to stand individually on this issue. We ought to call upon the OSI or the FSF to represent a countersuit - in due time - on behalf of the community that has been wronged by these actions. We must show SCO that there are very dire (legal) consequences for their unethical behavior.
There was a time when SCO deserved better than this. If they were truly concerned about IP rights, they could have approached us in a more civilized, concilliatory manner. They could have worked with us, like they used to in times past. Or, they could have made good on Ransom Love's statements during the acquisition of SCO. Some, at least, might have considered this a sort of verbal contract that SCO has failed to keep.
From SCO we see anger, slander, and wilful misrepresentation of facts. I might expect this reaction from a loosely knit group of enthusiasts, but not from a professional organization. They ought to know better.
Sun had already bought their Unix license for a fixed fee long before this happened. If they paid SCO again, it was for some other reason, but not for Unix licensing.
If indeed Sun did pay off SCO at the time of this lawsuit, then there is suspiscion of collusion.
Kids want to make cool stuff. In 1984 I could write a stupid script to scroll my name on the screen using TI BASIC. I could also write a neat graphical maze game with speach synthesis using the same tool. With Windows Scripting Host and JavaScript (etc), I can write stupid stuff, but not cool stuff. Anyway, how many people here know how to fire up WSH and go? I don't think that's even in the manual.
At least with DOS 2.11, the manual said I could run "BASICA" and, by the way, try out these few lines of code.
I had classes in the 4th and 6th grades with C64 LOGO and Atari Basic. It was neat back then. In 2003, neat is 3D graphics and surround sound. Are you going to get a kid hooked on programming with a few batch files? I don't think so.
The old TI rags used to publish code listings for games like "Dogfight" and "Conquest of Camelot." They were in BASIC and you had to type them in from the magazine and save them onto an audio cassette. I spent hours as an 8-year-old typing in lines of code that I didn't understand. It was cool to see what would happen when you typed "RUN" though.
In the 80s, programming was one of the things that you bought your computer for, other than games. So if a computer didn't have a tool to program it with, it was either junk or a game console. Not everybody had a computer back then, but those who did kinda liked it.
Now that there's money in computers as a commodity, it's another story. People still buy computers for games, but not for programming. Besides, if you program, you might become competition, and that's not good, especially if you give your code away for free. That and the increasing complexity of computers and operating systems make languages diverse and specialized.
So instead of computers that say, "hey, see what you can do with me," we have computers that say, "hey, you can run Word and Half Life and surf the Net if you have a license." And we're moving closer to "you can't run anything else, even if you have a license to run it, unless it's one of ours." Pretty soon (if Microsoft has its way), instead of only needing a license to run a program, you'll need a licence to make one too.
Anyway, back to the point. If a kid thinks computers are neat, he'll need a system that still lets him try the neat stuff. That is no longer Microsoft unless you've got the cash for VB, which is now an "add on." Can you get VB without buying the whole Dev Studio? I doubt it.
Today's equivalent to my old TI are the Linuxes, BSDs and other "Open Source" platforms that still actively encourage tinkering and learning.
Is Linux programming too hard for an 8-year-old to figure out? I guess it depends on where you start. At least you don't have to buy the extras.
I'm afraid the really cool stuff has been the domain of the big guys for at least ten years now, though. Sorry kids. Well, a few kids might be interested enough to figure it out.
Nobody's stopping us from making a Linux distro geared towards 8-year-old programmers. If we had a language that made it easy to do some neat sound and graphics, it'd be like the old days.
When my one-year-old got the Fisher Price toddler-table for Christmas, I noticed that it advertised Microsoft "smart technology."
I thought, hey, at last Microsoft is developing stuff that is more on their level. Maybe we'll start seeing some premier quality come out of Redmond.
But the damn thing couldn't even count to three properly, so my hopes were most cruely dashed.
Anyway, here we go again. The iLoo sounds like something that might be, er, right up their alley. Except I think they should keep the Internet out of it - I'm thinking the iLoo ought to start out as a nice little trainer potty, so I can haul my kid up on the crapper and the toilet actually motivates him to do his thing.
I envision a flashing toilet handle that becomes enabled, complete with the "Grand Old Duke of York" anthem. Activating this flush mechanism would initiate a stunning light show, pulsing from the turbulent waters, glorifying the contents within! Naturally, these wonderful features would only come to life once the toilet has detected a suitable change of contents.
The poop would get flushed right to Redmond, where Microsoft would wrap it up in aluminum foil and sell it as candy. People would buy it too.
Interesting. I am supporting several CVS modules for various development teams right now. Regarding the teams that normally would use Microsoft VSS, there is not a single developer who doesn't _constantly_ gripe about how awful CVS is.
Having used VSS for a couple of years on a previous project, I would definitely agree with them. Sure, it appears that VSS is not good for remote development (the off-site source code products for VSS have also proven too slow - hence our switch to CVS). Still, VSS is MUCH easier to use than CVS if you are working from a MicroSoft development platform and don't have to worry about sharing code remotely. VSS has a more intuitive interface than CVS, even WinCVS is terrible.
VSS also does not suffer from some of the retarded problems that CVS has, such as managing repository directories and administrating CVS users. These tasks take extra time on CVS, and are non-issues under VSS. I shouldn't have to spend time supporting CVS; we never had to with VSS.
I'm keeping my eye on Subversion - I think it might be the system that will replace CVS as the open source tool of choice for source control.
Slashdot Mirror
When I was a manager over an IT department, we sometimes got Ph.D. holding candidates interviewing for the position of scriptwriter/setup technician.
We were worried that such an overqualified candidate would soon become dissatisfied with the job, or would require a higher pay than we could afford for the position. It was really not a good fit for the job.
I realize that in this economy, a lot of really educated people are in need of work. My suggestion to those is that they do not advertise their higher degrees with jobs that they are overqualified for. If you are satisfied with menial work, then it doesn't matter if you have an advanced degree - don't show it off.
If you are getting your Ph.D. as a career move, make sure your job description matches your education, otherwise it was a waste of time. You don't need a Ph.D. to be a scriptwriter.
But what is preventing SCO from adding in code from Linux (which is openly available) into their (closed) UNIX code and then claiming is was there first and was 'stolen' by Linux? C'mon, we are not expecting SCO's management to play fair here - how hard would it be to backdate code additions?
Because every line of code in the Linux source control system has somebody's name on it. If they contribute their own code to the Linux kernel, it has to go through an acceptance process by Linus or one of the Linux stewards. If it turns out to be SCO code, then we know who can account for it, and can investigate their ties with SCO.
When Ransom was the new CEO of SCO, he was full of Open Source ideology.
In those days, SCO was asked about moving Unix IP into Linux. Ransom said they were doing their best to "open up" the Unix technologies, but that a lot of things belonged to 3rd parties, and SCO didn't have the rights to them. See this article.
Then we have Ransom's LinuxWorld 2001 keynote where he discusses SCO's role in helping IBM get enterprise features into Linux. One of his statements went as follows: "But clearly we are going to add components back to the Linux kernel on both IA-32 and IA-64 platforms". This was during the whole Monterey project as I recall.
So if you look at SCO in this context, you get the idea that they knew very much what was going on, that they sanctioned it, and that they probably even helped expedite it. It doesn't make sense for Ransom to start raising IP questions when he has made statements about SCO's support of Enterprise Unix features in Linux.
Benifit of the doubt though, insider selling does happen in companies to take profit, and if you look at SCO's 1 year preformance going from 95 cents to 16 dollars at it's recent peak (an increase of nearly 1,700%), you would see why it would seem intelligent to sell.
This seems reasonable until you realize that the stock's current value is a direct result of unproven allegations. It is not hard to correlate SCO's stock value with the disinformation that has been spread by SCO's own executive officers.
These executives may claim they don't have any control over the stock price, but this is simply false. The content and delivery of their press releases directly affects their stock prices whether they intend it to or not. They certainly have control over what they say, and can therefore influence the price of their shares.
When SCO's allegations are proven wrong, then it becomes a matter of stock manipulation. In this scenario, criminal charges might be brought against those involved in the scheme.
This is why I have a hard time believing that McBride et al would knowingly perpetrate such a huge fraud. I admit that the ballance of public evidence is decidely NOT in SCO's favor. In the Post-Enron business world, corporate legerdemain is madness. It doesn't make sense - none of this does.
And yet, if SCO truly had a trump card, they already missed their chance at playing it by being irresponsible, unethical and unprofessional in the way they are handling their dispute. I can't believe those guys are this stupid; surely we have missed something.
Alas, it is as Hitler wrote. The "Big Lie" is harder to dismiss than the little one. It is so fantastically absurd that we question our own judgement against it.
Since Microsoft is such a respecter of other people's IP rights, why oh why didn't they imediately license these patents?
I guess that Internet Explorer is such an obscure product, they figured they could just get away with it. The same goes for those pesky DRM patents that affect their "niche" OSes such as Windows XP.
Thank goodness Microsoft had the sense to license questionable Unix IP for their wildly popular Unix Compatibility layer. If they ran into trouble with that program, it would surely sink the company.
My JBoss server was listening on port 4444, so I got a call from the IS guys who thought my PC was compromised.
Tell that to the users that SCO is threatening. What they need is something to feel good about. If that means setting up a useless legal fund for users, then do it.
Why the hell would MS and Sun be spouting about how they indemnify their users against legal threats?
It's a PR game, and we need to play it.
If you look at the competitive space where Linux is growing up, you see two kinds of companies striving for business.
One kind of company sees the writing on wall. These companies realize what FLOSS is, and have redefined themselves under this new reality. These companies are usually content to compete on a level playing field in this respect. They are all trying to incorporate Linux and Open Source into their business, with various degrees of success. Most companies fit into this group: IBM, Novell, Oracle, SGI, Dell, etc.
The other kind of company will settle for no less than complete domination of the market on their own terms: Sun and Microsoft. Sun is interesting because it wants to play both sides of the fence, but I gather they would rather NOT share in the Linux goodness with their competitors if they can help it.
Microsoft will sit and deny that Linux is even viable until they are completely engulfed by it. Witness the Internet.
These enemies of Linux and Free/Open Source have discovered their anti-Linux efforts to be futile. According to leaked Microsoft documents, smear campaigns were in fact counter-productive. The interesting conclusion was that the best attack on Linux was a legal attack. Apparently Microsoft's market research shows that fear of being sued is the biggest deterrent to Linux deployments.
So this is their trump card. If they can stir up fear of litigation, they can point at Linux and say, "Look, no indemnification there! Buy us instead." SCO is just a pawn in this gambit - I don't think anyone expects them to survive the play.
By providing a legal fund to developers of GPL software, Red Hat begins to undermine these tactics used by Microsoft and Sun.
I like this fund because it appears to benefit the community as a whole and not just Red Hat customers. I sincerely hope that other companies pick up on this idea, and decide to contribute to the fund.
If anything, this gives us an idea of how we can provide indemnification to Linux users in general. Perhaps a general fund for all Linux _users_ would be appropriate, with the option to purchase a renewable policy against it (from a community run non-profit group). The community could evaluate claims against this "insurance" and assign legal resources to litigate it if needed. At any rate, owning a policy would guarantee a level of financial coverage. Non-policy owners could also get help, depending on circumstances and the merits of their case.
I see this as a way for the politicaly motivated community members to contribute where they might not be able to give code.
People have been foretelling the doom of Novell for almost a decade. Even during the good economy Novell was the "Sinking Ship."
Isn't it time to give it up? Novell is still here, and shows no signs of being otherwise in the near future.
Do you see something in Moglen's paper that isn't certifiably factual?
Do you see something in Moglen's paper that ignores SCO's side of the argument?
It's hard to be unbiased when the only available facts are so one-sided.
Some people like to ignore facts if it helps them look less "biased," because facts tend to lead the mind to certain conclusions. I mean, we wouldn't want actual critical thought at the expense of giving both parties equal benefit of the doubt, would we?
So far, I have yet to see one single, tangible, FACT from SCO that would support their claims in the least amount. And yet I see all sorts of "journalism" that lends credibility to SCO's claims for the sake of "unbiased" reporting.
What a load of crap. Try walking into any big company and suggesting that you should be able to run linux on your desk.
It's not uncommon to see Linux or even FreeBSD on business desktops. I worked on a technical team that used 90% Linux and 10% FreeBSD. This was in 1998.
Ok, ok, it wasn't a "big company", and it was mostly just my team. But it is out there.
In 2000 I took a tour of a mid-sized manufacturing company called Action Target. They were 100% Linux on the desktop, running a system called Wyatt-ERP. This handled everything from AR to call tracking, and integrated with their phone system to boot. They had a little win 98 box in a closet, in case there was need to convert a Word document.
Linux is certainly an increasingly viable desktop platform, particularly for small and medium sized businesses, and it is definitely getting used.
This is a necessary and important step in how the future will play out. If Linux is materially hurt by SCO's allegations, then SCO might be held liable for those damages.
Unlike the alleged damages that SCO claims, we can quantify and prove the sort of damage that is being done to Linux right now, just by pointing at the media and industry analysts.
In the past, media and analysts never said "Hey, Linux is killing SCO," which is what SCO claims happened. But now we see all kinds of people clamoring about how SCO is killing Linux.
Without solid proof of harm, Linux vendors, users and developers have little cause for action against SCO. Now that is changing, and SCO can start getting worried. We have more than allegations.
If you are a Linux user, then you have been officially threatened. SCO may claim that they only go after fortune 1000, but they made it clear that ALL Linux users are infringing, and liable for infringement unless a UnixWare license is purchased.
If you feel threatened by this attitude from SCO, then you need to take it to the FTC because where you live, extortion is most likely illegal.
SCO is not licensing Linux under another license. They are selling a license to UnixWare and saying that they won't sue you for using Linux if you have the UnixWare license.
In other words, "Buy UnixWare or risk being sued."
I would say that this plan fits very nicely under the dictionary description of extortion, and I recommend all Linux users file a complaint with the FTC. SCO has not proven that they have any rights over Linux at all, and therefore any such threats used to sell licenses are illegal.
Yes, in order to claim infringement in a court of law (in the U.S.), your copyright must be registered.
It is true that any work you produce can be automatically copyrighted unless you specifically state otherwise. You do not need to register anything to put a copyright notice on your work.
However, if you want to litigate your copyright, you have to make sure that you have registered the copyright with the government. You can register it after the work has been created, although there may be some date limitations on certain types of media.
Copyright is transferable, but again, this needs to be documented.
If AT&T has never transferred their copyright with the Unix IP that was sold, then AT&T still owns the copyright on SVr4. The copyright that SCO has registered is either for a derivative SVr4 that they are basing their claims on, or else it infringes on the AT&T copyrights, which could be a serious problem for SCO.
If SCO bases their licensing scheme on this new copyright, then I suggest that this license is fraudulent, and should be investigated.
At any rate, the original SVr4 code never had any of the features that SCO claims infringe. Apparently they are saying that they own the copyright to IBM's work because IBM put it into an SVr4 derived system. IBM also donated some code to Linux. Because IBM's code is in a derivative work, SCO says they have a contract that gives them rights to it, and that the existence of such code in Linux is a violation of said contract. So, really, it is unclear just what SCO is claiming copyright on and what they are claiming is a license violation.
It is extremely doubtful that SCO can claim copyright on IBM's code. In fact, it is unlikely that SCO has a single claim that is anything but dubious. I am very curious about why David Boies would further damage his reputation over such a poor case.
I believe that the original authors of a work may revoke a transfer of copyright, but I think that this does not apply to a work-for-hire. In this case, I am not sure if the original company has the same right. It may be, however, that AT&T becomes a big player in this debacle before all is said and done.
Registering a copyright allows you to litigate for damages - either real or statutory - for infringement.
There are no "punative" damages applied to copyright law.
Since it is a civil matter, the penalties deter mostly small-scale infringers since you really can't get more than $30,000 on statutory (up to $150,000 on willful infringement). They would probably try to inflate their "actual losses" to get the most out of infringement cases against big businesses, but they could also go after any Linux users for licensing fees or statutory damages.
If you thought the bad vibes against SCO were serious before now, just wait. This is where everybody - not just IBM - starts to sit on pins and needles. This is where Red Hat, SuSE, Mandrake, Debian, etc., etc. start to get worried. This is where the threat becomes a direct assault on all of these businesses. This is where the GPL either stands or falls. This is the crux of the Open Source revolution, and we about to see what it is made of.
I think SCO will make one, perhaps two more mis-steps down this road, and then the restraint of all will come down. I see lawsuits from the FSF, RedHat, the OSI, and perhaps all Linux copyright holders (what of them, SCO? You seem to indicate that they are all complice to the infringement, these "criminal" volunteers). I see a breach of contract suit from the FSF. I see various attempts at class-action suits. I see non-core Linux developers (3rd party Open Source developers) attempting lawsuits. In brief: litigious chaos.
I predict very bad behavior from some in the Linux community, and I REALLY hope that they will keep their cool. It looks like SCO has no clue of the magnitude of bad feelings they are generating.
If I recall, the FSF owns a number of copyrights on code in the Linux Kernel, including some bits contributed by IBM that may be in question.
To date, the only FSF response to SCO has been a subtle Linux should really be called "GNU/Linux" diatribe (See! we told you so!).
The most informative SCO response to date is still the OSI position paper by Eric Raymond et al.
I believe that the FSF and the OSI, in addition to the other Kernel copyright holders, should indeed seek legal action against SCO. I would like to see something spectacular, although any countersuit is likely to be limited - due to the nature of copyright law. I think the obvious action is simply to force SCO to disclose what infringing code exists.
This assumes, though, that the disclosed code really does infringe, which is somewhat unlikely (it was never in the interest of Linux development to allow proprietary code).
I think there is a lot the Linux developers could do to mitigate the damages on our side.
The Linux stewards need to lay to rest the myth that we don't really know where all of our code came from. Every line of code in the project has somebody's name on it, and there is someone out there who can vouch for it. If, in this process, we discover some holes, we have the power to fix them - we don't depend on SCO to tell us what is clean and what is not clean. It is dangerous to let SCO tell us what is theirs and what is ours because they are bent on claiming as much as posible, now matter how ridiculous the connection.
Having a very public Linux Accountability Project does a huge amount of good for the Linux cause.
1) There are very few commercial organizations that have anything like it. In addition to a totally transparent development model, in which all of the "property" can be examined by the public, the fact that the Linux community itself stands behind every line of code lends more credibility to it than any closed-source program.
2) It establishes a factual base from which to discuss the SCO claims. Currently, the only context that we have for discussion is SCO's outrageous allegations. We have the code, why don't we talk about it on our terms? Why must we prove SCO wrong? Why shouldn't they have to prove themselves right instead? This would be the case if we had a public manifest of all aspects of the Linux Kernel. If the public could see who the players are with a brief description of the origins of the features and a statement from the developers themselves, then SCO might have a lot more explaining to do.
I believe that this sort of a project can be accomplished in a reasonable amount of time. It might delay further development on Linux for a little while - losses that would be quantified and then extraced from SCO in the countersuits to follow - but it would be well worth it.
I also highly recommend that every Open Source developer keep a detailed log of all of their development so that, at any time, complete accountability can be made for your program. Don't let greedy corporations claim your work!
Well, I've digressed from the topic, so I'll shut up...
There are various standards of writing. In American technical writing practice, we adhere to the standards presented by the APA (American Psycological Assoc. if I recall).
This standard is extremely strict when it comes to crediting sources for research papers. If I use even a single word that is unique enough to the work of a particular expert on the subject I am writing about, then I am supposed to provide source information or I risk being accused of plagiarism. This is a reality in America; perhaps in the UK your standards allow for a greater license with technical writing.
This does not mean that we are discouraged from reading other works. Quite the contrary, we need as many sources to support our thesis as possible.
The point is that, when I contribute my OWN opinions and observations, it's best if I don't worry about what other people have written. This is where I'm trying to draw the parallel. Perhaps it is a poor example, though.
SCO seems to have changed directions on this issue too.
In the beginning we heard a lot about code "theft". There was a promised "show and tell" time that turned out to be mostly a joke.
Now SCO is talking more about code that has been donated that also appears in derivative works, not directly owned by SCO. For example, JFS is an IBM technology, but SCO wants rights to it based on licensing verbiage in the antiquated AT&T contract that has never been enforced until now.
They are damaging their argument of "Mututal Mistake", which might get them out of their GPL obligations, by claiming such things. Clearly they always knew of IBM's contributions to Linux in general, which they now decry based on the fact that the same features appear in AIX.
It is very clear from this behavior that SCO is not so much interested in protecting IP as it is in destroying Linux. The question is why?
Quite a turn about for the SCO that was promising to give Unix IP to the Open Source community back in 2000.
This is the same sort of advice I got in my Technical Writing class.
As you know, plagiarism is a very serious offense in many types of writing. It can be serious enough to get a student disqulified or expelled.
The less you worry about what other people have said on the subject you are writing about, the less your chances are of plagiarism. Writers who constantly check their sources for exact phraseology to ensure they aren't "infringing" actually tend to use idioms and vocabulary from the sources they are trying to avoid copying.
You will not find much of what we consider "enterprise" features in any SVR4 code because of its age.
What we have are companies who are donating their own enterprise innovations, which they have also included in their SVR4 *derived* systems.
SCO is trying to say that, for example, AIX is a derivative of SVR4, which is owned by SCO. Therefore, SCO has certain rights to the improvements that IBM makes to AIX (in a round-about way). If IBM contributes some of their improvements from AIX to Linux, then SCO says that IBM is breaking their contract with SCO.
So what we see now is that SCO is claiming a lot of advanced technology that they never really "owned" at all, but they want to prove that, indirectly, they really did have rights to it.
I believe one of the analysts who examined the SCO and Linux code under the NDA, indicated that the code shown was SVR4 code. If this is the case, it was most likely from BSD.
At any rate, this is a serious departure from their plans in August of 2000. At that time, Ransom Love was promising to release whatever code he could into the Open Source Community, and he even speculated on the use of the GPL as the license that SCO might use. Interestingly, he mentioned that some improvements could not be released because they were owned by other companies. SCO would now like to have us believe that they own all of that code.
History shows that in fact SCO never really got around to releasing the promised code, maybe because other companies (IBM and HP) had already stepped up and contributed their own features. Part of SCO's "sour grapes" might be due to the fact that they thought they would be a much bigger player since they owned Unix IP, when actually other companies had far surpassed them already.
The current state of affairs represents turnabout on SCO's part. They made some statements in bad faith back in August of 2000. They are now actively trying to thwart an international organization of volunteers, who have contributed their work to the world.
IBM and other companies may be able to stand up for themselves, but they do not have the same stewardship over Linux that the greater Linux Community has.
SCO has made an affront to the uncounted hobbyists and enthusiasts that are proud to claim Linux as their own. They have slandered and derided. There are those contributors who have been hurt by these actions.
We cannot afford to stand individually on this issue. We ought to call upon the OSI or the FSF to represent a countersuit - in due time - on behalf of the community that has been wronged by these actions. We must show SCO that there are very dire (legal) consequences for their unethical behavior.
There was a time when SCO deserved better than this. If they were truly concerned about IP rights, they could have approached us in a more civilized, concilliatory manner. They could have worked with us, like they used to in times past. Or, they could have made good on Ransom Love's statements during the acquisition of SCO. Some, at least, might have considered this a sort of verbal contract that SCO has failed to keep.
From SCO we see anger, slander, and wilful misrepresentation of facts. I might expect this reaction from a loosely knit group of enthusiasts, but not from a professional organization. They ought to know better.
Sun had already bought their Unix license for a fixed fee long before this happened. If they paid SCO again, it was for some other reason, but not for Unix licensing.
If indeed Sun did pay off SCO at the time of this lawsuit, then there is suspiscion of collusion.
Kids want to make cool stuff. In 1984 I could write a stupid script to scroll my name on the screen using TI BASIC. I could also write a neat graphical maze game with speach synthesis using the same tool. With Windows Scripting Host and JavaScript (etc), I can write stupid stuff, but not cool stuff. Anyway, how many people here know how to fire up WSH and go? I don't think that's even in the manual.
At least with DOS 2.11, the manual said I could run "BASICA" and, by the way, try out these few lines of code.
I had classes in the 4th and 6th grades with C64 LOGO and Atari Basic. It was neat back then. In 2003, neat is 3D graphics and surround sound. Are you going to get a kid hooked on programming with a few batch files? I don't think so.
The old TI rags used to publish code listings for games like "Dogfight" and "Conquest of Camelot." They were in BASIC and you had to type them in from the magazine and save them onto an audio cassette. I spent hours as an 8-year-old typing in lines of code that I didn't understand. It was cool to see what would happen when you typed "RUN" though.
In the 80s, programming was one of the things that you bought your computer for, other than games. So if a computer didn't have a tool to program it with, it was either junk or a game console. Not everybody had a computer back then, but those who did kinda liked it.
Now that there's money in computers as a commodity, it's another story. People still buy computers for games, but not for programming. Besides, if you program, you might become competition, and that's not good, especially if you give your code away for free. That and the increasing complexity of computers and operating systems make languages diverse and specialized.
So instead of computers that say, "hey, see what you can do with me," we have computers that say, "hey, you can run Word and Half Life and surf the Net if you have a license." And we're moving closer to "you can't run anything else, even if you have a license to run it, unless it's one of ours." Pretty soon (if Microsoft has its way), instead of only needing a license to run a program, you'll need a licence to make one too.
Anyway, back to the point. If a kid thinks computers are neat, he'll need a system that still lets him try the neat stuff. That is no longer Microsoft unless you've got the cash for VB, which is now an "add on." Can you get VB without buying the whole Dev Studio? I doubt it.
Today's equivalent to my old TI are the Linuxes, BSDs and other "Open Source" platforms that still actively encourage tinkering and learning.
Is Linux programming too hard for an 8-year-old to figure out? I guess it depends on where you start. At least you don't have to buy the extras.
I'm afraid the really cool stuff has been the domain of the big guys for at least ten years now, though. Sorry kids. Well, a few kids might be interested enough to figure it out.
Nobody's stopping us from making a Linux distro geared towards 8-year-old programmers. If we had a language that made it easy to do some neat sound and graphics, it'd be like the old days.
When my one-year-old got the Fisher Price toddler-table for Christmas, I noticed that it advertised Microsoft "smart technology."
I thought, hey, at last Microsoft is developing stuff that is more on their level. Maybe we'll start seeing some premier quality come out of Redmond.
But the damn thing couldn't even count to three properly, so my hopes were most cruely dashed.
Anyway, here we go again. The iLoo sounds like something that might be, er, right up their alley. Except I think they should keep the Internet out of it - I'm thinking the iLoo ought to start out as a nice little trainer potty, so I can haul my kid up on the crapper and the toilet actually motivates him to do his thing.
I envision a flashing toilet handle that becomes enabled, complete with the "Grand Old Duke of York" anthem. Activating this flush mechanism would initiate a stunning light show, pulsing from the turbulent waters, glorifying the contents within! Naturally, these wonderful features would only come to life once the toilet has detected a suitable change of contents.
The poop would get flushed right to Redmond, where Microsoft would wrap it up in aluminum foil and sell it as candy. People would buy it too.
Interesting. I am supporting several CVS modules for various development teams right now. Regarding the teams that normally would use Microsoft VSS, there is not a single developer who doesn't _constantly_ gripe about how awful CVS is.
Having used VSS for a couple of years on a previous project, I would definitely agree with them. Sure, it appears that VSS is not good for remote development (the off-site source code products for VSS have also proven too slow - hence our switch to CVS). Still, VSS is MUCH easier to use than CVS if you are working from a MicroSoft development platform and don't have to worry about sharing code remotely. VSS has a more intuitive interface than CVS, even WinCVS is terrible.
VSS also does not suffer from some of the retarded problems that CVS has, such as managing repository directories and administrating CVS users. These tasks take extra time on CVS, and are non-issues under VSS. I shouldn't have to spend time supporting CVS; we never had to with VSS.
I'm keeping my eye on Subversion - I think it might be the system that will replace CVS as the open source tool of choice for source control.