[ Reply to This | # ]

"My question was, if SCO wishes to be known as cutting edge, why would they mimic the package list of UnitedLinux instead ?"

SCO isn't such a large company. The probably figured that those versions of the packages were really well tested since they were also used by alll UnitedLinux partners. Remember that as a distributor you have to audit each new version and that takes real time.

The APM/ACPI example also isn't that strong. It sounds normal that you will have to enable these (hardware) features in the same way on the same machine. The fact that Suse and UnixWare have the same conservative (keep them off) default doesn't sound very suspecious. It is common to not enable all hardware/bios functions on a machine since normally it works the other way around. Enabling something modern like ACPI could make the system more unstable if done wrongly. The Dell PowerEdge Server sounds like an not common/standard machine in this respect.

The "many new drivers" thing is a bit suspicious but not that much. Yes, their engineers probably looked and studied the Linux kernel device drivers. And having the code (an explanation how the hardware devices actually works) really helps with getting your own drivers written more quickly. But that is one of the things of Free Software, you are free to study how it works and then create your own work that functions in the same way.

If there are really many "quirks" the same then it might certainly warrent a further investigation, but this story didn't really convince me there is really something odd going on. I think this was more just a effort to get the datasheets in sync with UnitedLinux to show customers they could easily switch between the distributions. I am not convinced (yet) that any code copying took place. Although I am pretty certain their engineers studied the linux kernel code.

Also I am a bit shocked by the conclusion of the article "If [...] an investigation showed common code, then UnixWare 7.1.3 just joined the free world and is now GPLd". I would have expected that people distributing UnixWare (like SCO does) are then found in copyright violation and can no longer distribute it. They might then be liable to pay some damages to the copyright holders of the GPL code they included. If they wish to redistribute a new version of UnixWare they will have to remove the GPLd code they included, but I don't think they can be forced to distribute their complete distribution under the GPL. They can only be forced to stop distributing the current version.

[ Reply to This | # ]

I believe (but I'm neither a lawyer or an American) that US law also allows for criminal penalties, but I wouldn't know whether SCO has reached that point yet.

[ Reply to This | # ]

What someone needs to do is get a hold of all of SCO's Unix sources and tear through the kernels, and other "proprietary" modules, looking for GPL'ed code.

[ Reply to This | # ]

Title: "SCO to argue General Public Licence invalid" http://www.theinquirer.net/?art icle=11031

[ Reply to This | # ]

If you breach a contract with $CO, $CO sues you for money. If $CO breaches a contract with you, they declare the contract invalid. Does this make any sense?

[ Reply to This | # ]

It would be a point that could be brought up by some kernel developers that start a lawsuit against SCO for GPL violation.

[ Reply to This | # ]

http://www.slt rib.com/2003/Aug/08142003/business/83769.asp

Incidentally, didn't Sun license a bunch of Intel drivers? Are we talking about the same stuff?

[ Reply to This | # ]

http://www.pclinuxonline.com/modules.php?mop=modload&n ame=Forums&file=viewtopic&topic=870&forum=37

[ Reply to This | # ]

My 2 cents:

If he is a genuine employee or not doesn't really matter - his point is still valid. Sco were suffering losses before starting their do or die assault.

Once Sco's shares started to rocket the Canopy Group saw the strategy as effective, generating revenue and worth supporting. On the other hand if the side-effect of this attack causes companies in the Canopy Group to be boycotted and ultimately affects their bottom line - things may be very different.

IMHO if Sco loses; one small company who were on the way out anyway is probably viewed as an acceptable loss. If the Canopy Group's shares, contracts and profits begin to suffer .. hmmm what happens then?

[ Reply to This | # ]

As to whether or not the code postulated as having been shared from Su.S.E.'s SLES8 to UnixWare 7.1.3, could have GPLed the entire UnixWare source tree, the relevant parameters are this:

Unix used to require a kernel recompile to incorporate new device drivers. I did a Unix newbies' course at nightschool in 1993 using SCO OpenServer and the tutor was quite definite about that. She wasn't particularly impressed about it either.

Linux and *BSD got into loadable kernel device driver modules about 1992 for 386BSD and 1994 for Linux - if my memory serves me right, which is not a given. My copy of "The Magic Garden Explained", a system architecture overview of Unix System V Release 4, never mentioned it as a possibility - if it had been important for them, they would've crowed about it; whereas Bill Jolitz is dogmatic about its possibilities in his "Source Code Secrets" series and scathing about Unix system developers' scorn of all things DOS/Windows, and a Linux kernel developer wrote a very interesting article about loadable kernel modules in one of the 1994 DDJ issues.

My guess is that loadable kernel modules were of no interest to the Unix SVR4 maintainers through the sale saga - SVR4 came out in 1989 according to "The Design and Implementation of the 4.4BSD Operating System".

Now if the new kernel device drivers are not modules, they are part and parcel of the UnixWare 7.1.3 kernel, in which case, as putative Su.S.E. GPLed device drivers, they bring the following section of the GPL into force:

2. b) You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

If on the other hand, the device drivers are loadable modules, and UnixWare (SVR4) never had loadable module support until now, the question must also be asked, where did it come from? If it came from the UnixWare developers' own hard work, that is no problem, but if it is derived from Linux's own loadable kernel module subsystem, then the section of the GPL quoted above, would also apply.

Another related question is, was this putative Linux-to-UnixWare cross-pollination covered under any of the as-yet-unrevealed UnitedLinux agreements and contracts?

If Su.S.E. or one of the others could oblige us with the complete texts of the agreements - the agreements are in force only in relation to Su.S.E., Conectiva and TurboLinux, since SCO has effectively repudiated them, so I doubt there could be any harm done in revealing their terms but IANAL - we would be able to judge the matter more clearly.

[ Reply to This | # ]

http://mozillaquest.com/Linux03/ScoSource-27-1-IBM-Counterclaim-IP_Story0 1.html

[ Reply to This | # ]

"Bench submitted a sale plan in January, months before any legal action against IBM was contemplated, McBride said. His agreement called for the sales to begin on March 8. He planned to sell 5,000 shares a month for the next 12 months, according to the plan."

March 8, eh? The lawsuit was in fact filed in March. Coincidence??

[ Reply to This | # ]

[ Reply to This | # ]

[ Reply to This | # ]

That is a load of Malarky, back in May McBride said in an interview that he had no knowledge of any SCO executive planning to sell company stock. And their legal strategy was planned against IBM since late 2002

[ Reply to This | # ]

Sounds like later than March 8th.

[ Reply to This | # ]

It was after reading The Inquirer's story about SCO's lawyers trying to get the GPL invalidated that this dawned on me. Read on:

SCO started out their lawsuit with the claim that IBM had breached their contract by misappropriating Unix trade secrets (or whatever) into Linux. They then tried to claim ownership of those components IBM put into Linux, which they have now stated that IBM fully owns the copyrights and patents to.

So now all SCO is left with is the whole derivative works issue. If all that contract says is that any works derived from Unix System V cannot be put into works that are not treated the same way as the rest of the System V code base, and that contract does not imply that any derived works become the property of SCO, and no System V code was actually transfered by IBM into Linux, SCO's only claim can be breach of contract.

So what am I getting at? Now it gets interesting. :-)

If all IBM did was breach a contract (i.e. they did not transfer any SCO copyrighted works or patents into Linux), then SCO is in some deep sh*t. Remember SCO's "Linux IP compliance license", or whatever they call it? Even if, for a second, we forget that the license amounts to extortion, notice what payment of that license has effectively done. Figured it out yet? Here goes. =)

SCO went and successfully collected payment (or at least an agreement to provide payment), as per SCO's own press release, for what amounts to a breach of contract, if such a breach did in fact occur. If we assume that whosoever purchased SCO's illegal Linux license was not also a party to the contract at the heart of the dispute, SCO has effectively been compensated for the IBM breach, if anything was breached at all.

Therefore, if the judge is sharp and has a sense of humor (or at least lacks a sense of humor towards SCO), all things excluded, it could be declared that SCO, by their actions, illegally sought and received compensation, though not from IBM, for the IBM breach of contract (if there was in fact such a breach), SCO has thus voided any rights they had, under the contract, to receive “additional” compensation from IBM. Thus, SCO's Linux licensees have fully compensated SCO on behalf of IBM.

Please tell me there is at least a remote possibility for such a declaratory judgement. Please please please. :)

And please sent this to the IBM defense team to ponder. Notice of copyright: I hereby assign IBM the right to use this information, including derivative works, for both their legal defense and/or offense with respect to the pending litigation with the SCO Group. =)

[ Reply to This | # ]

"The facts laid out regarding SCO-Caldera's demands that GNU/Linux users purchase SCO-Caldera UnixWare licenses in order to run the GNU/Linux operating system are more than sufficient for most if not all Attorneys General of the 50 United States to file the appropriate civil and criminal unfair or deceptive trade practices, consumer fraud, false advertising, barratry, and other such charges against SCO-Caldera, its CEO Darl McBride, and other corporate officers. (Please see the Suing SCO Note in the sidebar.)

There are at least two reasons for such a conclusion. First is that as alleged in IBM's Counterclaims, there is little, if any, doubt that SCO-Caldera and its CEO Darl McBride have been promoting and publicizing their claims that GNU/Linux users are infringing on SCO intellectual property (IP) and that SCO-Caldera will enforce its IP rights against GNU/Linux users -- including infringement lawsuits.

The second reason is that as alleged in IBM's Counterclaims, SCO-Caldera has no enforceable IP interests in the Linux kernel or the GNU/Linux operating system. SCO-Caldera and McBride know this. Therefore they likely are engaging in trade libel, unfair or deceptive trade practices, consumer fraud, false advertising, barratry, and other such prohibited and actionable conduct.

Perhaps SCO and Darl McBride can back up their claims. But so far they have not done so."

And the sidebar referenced offers....

"Both IBM in its Counterclaims here and Red Hat in its independent lawsuit have asked the courts for damages for false advertising based on the Lanham Act. 15 U.S.C. 1125. Red Hat also has asked for damages under the Delaware Deceptive Trade Practices Act, 6 Del. C. 2532. IBM's Counterclaims, include a claim under N.Y. Gen. Bus. Law Section 349 for unfair and deceptive trade practices. Most if not all states have similar laws under which individuals and organizations can file civil lawsuits."

[ Reply to This | # ]

I know that Solaris had loadable kernel modules around 1994 too (I don't know when SUN introduced them); Uresh Vahalia (in Unix internals the new frontiers) associates them with SVR4.2 (1992?).

I wonder how a small company like SCO is suddenly able to produce dozens of device drivers and test them. I have written a device driver myself and I know that the debugging part is hard! It takes a significant amount of testing to get everything to work correctly. If SCO is able to produce more than four device drivers per programmer per year, they must have had some help (or inspiration).

[ Reply to This | # ]

I feel that this case is too complex from any side you could look at it: legal, scientific/engineering, political, ethical... What surprises me, is that the media and press shed so little light on that other sides of this story except the business/legal one. One of the most important issues for me is whether and to what extend copyrighting code *IS* practical. And supposing it is, what should the copyright cover. I know I may be not practical on the subject but some sceptical/philosophical view maybe good also (don't get me wrong I am not claiming I am a philosopher or a superior mind. I just believe that in such important issues we should look at the picture from quite far away – we will miss important details but we will also see other things).

Some random thoughts: * Is writing programs a scientific or an engineering work? For example is to so different to devise a mathematical formula to calculate the square root of 2 or the number pi than to devise an algorithm or program that calculates those numbers? Is it so different that the work in the 1st case can't be copyrighted but the work in the 2nd case can? Maybe the algorithms are like mathematics whereas the implementation of an algorithm (the program) isn't. In that case is converting an algorithm to a program so important job that one can copyright it? * The tools a programmer needs to create code of great volume and complexity are so cheap and easy to obtain. Apart from them the only thing a programmer needs to go on is a healthy mind and a purpose. In addition the Internet creates a place of common stimulus and experiences for programmers. That's why we have quite a lot of programmers around the globe and that's why it is quite likely that a lot of them will deal with the same subject. Doesn't it happen naturally for a lot of them to come up with very similar algorithms and code (not to mention methods and concepts) even while working independently? Is John a theft if Tom was the first to register? Can John prove in a court he devised in his own the same algorithm? Can Tom prove John didn't but rather he just copied his stuff? If none of them can prove their position can John be considered a theft? * For some years we have a great presence of open source code. A lot of (most of?) the programmers see and work on open source code. What about the methods and concepts they acquire experience of? Doesn't it indoctrinate them? Won't they use them in the proprietary products they will build for some Super Crapy Operation? Is the proprietary product proprietary enough now? Does it infringe the open source concepts and method, algorithms or whatever you call those mind entities? -

From my point of view it is likely that no court or judge would like to deal with this monster. I am also confused as to if I would like to see this case on a court and I am quite sceptical when I read in graklaw "Great! We will get the GPL to court!" It's just that sometimes, the confidence that issues so complex are rarely resolved properly in the court, prevails and I say "no! No court". Some other times though the thought that leaving doubt's and complexity unresolved can poison the O.S. movement prevails and I say "go on and settle this once and for good (yea its gonna be tough but that is the right way)"

[ Reply to This | # ]

Changing subject, another area that might be worth reviewing is LKP. You may remember some press stories, and a correction that SCO issued when it was in the press, I think last year.

[ Reply to This | # ]

[ Reply to This | # ]

So, according to McB, a plan for executives, insiders, to sell stock was filed with the SEC in January, months before any legal action was contemplated.

Or so he is quoted in the SL Trib.

What else did the Lindon gang do in January? Well, they retained the Boies firm and publicly demanded that Big Blue pay them a fee or lose the lisence to use Unix source. And started claiming that "Linux" code from SCO in the "periphery", not the Kernel. Some unnamed libraries.

No litigation planned, or expected?

Yeah, Darl, I truly believe you. Truly.

[ Reply to This | # ]

[ Reply to This | # ]

Here is an article about it dated Jan 10th

http://www.sys-con.co m/linux/articlenews.cfm?id=381

[ Reply to This | # ]

http://groups.google.com/groups ?hl=en&lr=&ie=UTF-8&oe=UTF-8&safe=off&threadm=0r2rf-bi.ln1%40lexi2.athghost7038s uus.net&rnum=1&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26safe%3 Doff%26scoring%3Dd%26as_drrb%3Db%26q%3Dsco%2Bthreatens%26btnG%3DGoogle%2BSearch% 26as_mind%3D1%26as_minm%3D1%26as_miny%3D2003%26as_maxd%3D31%26as_maxm%3D1%26as_m axy%3D2003

[ Reply to This | # ]

I've posted links previously, will post them again when I dig them up.

[ Reply to This | # ]

Market research links

March 10 - http://www.eweek.com/a rticle2/0,3959,922915,00.asp

Mentioned here too - http://wirel ess.ziffdavis.com/article2/0,3973,1164971,00.asp

News reports about possible litigation

Jan 23 - http://www.inter netnews.com/bus-news/article.php/1573491

"mid Jan" http://216.239.51.104/search ?q=cache:QXYqnxD0sRsJ:www.ofb.biz/article.php%3Fsid%3D217+SCOsource+%22red+hat%2 2&hl=en&ie=UTF-8

OTHERS

GPL invalid? http:/ /newsvac.newsforge.com/newsvac/03/08/14/1254246.shtml?tid=11

SCO (yes that's the same Hunsaker) improving Linux Oct 2002

h ttp://news.cnet.com/investor/news/newsitem/0-9900-1028-20596160-0.html

[ Reply to This | # ]

[ Reply to This | # ]

"I then told them to do a coparison and list every similarity that they found and get it back to me. It took them 2 weeks under which time we really put the two Operating Systems through hell, when I got their results I matched em and the results were exactly the same as mine except they added 3 more examples."

It would be interesting to see the actual list and the examples. That would make the case much stronger since it could then be verified by an independent party.

"SCO has definately not done anything to protect their rights, they undoubtedly let their UNIX and Linux developers collaborate on projects and that makes them tainted."

I don't think that is true. Linux is released under the GPL and that means that you may study it all you want. The only thing that is restricted is what is already restricted by normal copyright law, copying and/or distributing derived works. But that only comes into play when you actually literally copy stuff. Studying and creating your own work based on the knowledgee you gained is still possible.

And I think that is a good thing, because as you describe how some developers have to work when using proprietary, trade-secreted, work then you see how that is a nightmare for a normal person wanting to share his knowledge and achievements with others:

"They are not allowed to collaborate, they are not allowed to talk about their projects with each other they are not allowed to look at anybody elses project but their own."

That is true when working on proprietary project, but please don't let that happen to Free Software projects. Share and enjoy, happy hacking! And yes, if you use the knowledge that was shared with you to create software that users are not free to use then we will be very disappointed. Better make sure you didn't actually copy any GPLd code in that case, because then we will get you :)

[ Reply to This | # ]

[ Reply to This | # ]

My apologies to the readers using lower resolutions this affects, which includes me.

[ Reply to This | # ]

Sun licensed several hundred drivers

[ Reply to This | # ]

A) After SCO released UnixWare 7.1.3

B) Sun Licensed Drivers from SCO for Solaris x86, Sun did not License to SCO

[ Reply to This | # ]

http://news.com.com/2 100-1006_3-5063633.html?tag=lh

[ Reply to This | # ]

[ Reply to This | # ]

[ Reply to This | # ]

A suggestion of your findings. Perhaps with a bit of work you can get a contact over at SuSe to whom you can pass on copies of the data from your tests.

I would suspect that they might want to investigate the situation themselves and if they can substaintiate the information they might want to persue it with SCO.

Unfortunately, I don't have any contacts for you, but I suspect that adding the info to Slashdot might get a contact for you.

[ Reply to This | # ]

So SCO would have not only committed a breach of copyright in relation to its irrational claims of having a right to relicense Linux, it would have then already relicensed the GPLed device drivers in probable breach of the UnitedLinux contracts?

MathFox: As far as Sun having started with loadable kernel modules in 1992, I can believe that. They were among the most innovative of all the Unix licensees. But Bill Jolitz started his 386BSD project about 1989. I don't know if he was talking about it back then - I haven't read his 386BSD Disc notes - reproduced from DDJ - since about 1998.

I don't know that Sun's loadable kernel module subsystem would've been rolled back into SVR4, though.

And that is a major part of our problem with this wretched law suit - we know when major milestones took place in the BSD and the Linux camps - but since the Unix System V camp is more tightly closed than a constipatee's sphincter, we have very little idea of what happened when, there.

[ Reply to This | # ]

So SCO would have not only committed a breach of copyright in relation to its irrational claims of having a right to relicense Linux, it would have then already relicensed the GPLed device drivers in probable breach of the UnitedLinux contracts?

MathFox: As far as Sun having started with loadable kernel modules in 1992, I can believe that. They were among the most innovative of all the Unix licensees. But Bill Jolitz started his 386BSD project about 1989. I don't know if he was talking about it back then - I haven't read his 386BSD Disc notes - reproduced from DDJ - since about 1998.

I don't know that Sun's loadable kernel module subsystem would've been rolled back into SVR4, though.

And that is a major part of our problem with this wretched law suit - we know when major milestones took place in the BSD and the Linux camps - but since the Unix System V camp is more tightly closed than a constipatee's sphincter, we have very little idea of what happened when, there.

[ Reply to This | # ]

The Unixware device driver link is something that should be tracked. I'ld love to see some European kernel hackers file a suit in Germany; they can start with a simple GPL violation. If SCO really sold Linux device drivers as Unixware stuff to Sun, they'll be real toast!

[ Reply to This | # ]

[ Reply to This | # ]

The purpose of the typical Hello World! program is really neither scientific or engineering. It is simply another symbolic form of human speech. Like all communication you need a sender, a symbol, and a receiver. In order for communication to occur the sender and receiver have to assign the same or similar meaning to the symbols. Some times different people assign different meanings to the same symbols. That's why some people don't understand the issues that others might have with software patents.

Some people confuse the symbols or the medium with the ideas they are meant to communicate. These words I'm typing are symbolic. They communicate nothing at all to someone who doesn't speak English. The sounds we make when we talk are just more symbols. The sing-song sounds that two Asians make when they communicate with one another communicate nothing at all to me. The opposite can be true as well. I understand English and so does Darl McBride. It's obvious that we mean different things entirely by the terms we use like "misappropriate", "copyrights", & "contracts".

Our government has changed the laws and regulations to allow computer software to be copyrighted and even patented. Yet until recently, our courts and the executive branch refused to recognize that computer source code was a form of speech. Perhaps this has some bearing on the legality of the old 1980's contracts in SCO V IBM, but I doubt that IBM will use that defense. I think it's important in the long run for the Linux community to start using it.

Here is an extract of Frederick Brooks "The Mythical Man Month", I don't think anyone has ever summed up what programming is about any better:

"Why is programming fun? What delights may its practioner expect as his reward? First is the sheer joy of making things. As the child delights in his mud pie, so the adult enjoys building things, especially things of his own design. I think this delight must be an image of God's delight in making things, a delight shown in the distinctness and newness of each leaf and each snowflake. Second is the pleasure of making things that are useful to other people. Deep within, we want others to use our work and to find it helpful. In this respect the programming system is not essentially different from the child's first clay pencil holder "for Daddy's office." Third is the fascination of fashioning complex puzzle-like objects of interlocking moving parts and watching them work in subtle cycles, playing out the consequences of principles built in from the beginning. The programmed computer has all the fascination of the pinball machine or the jukebox mechanism, carried to the ultimate. Fourth is the joy of always learning, which springs from the nonrepeating nature of the task. In one way or another the problem is ever new, and its solver learns something: sometimes practical, sometimes theoretical, and sometimes both. Finally, there is the delight of working in such a tractable medium. The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures. (...) Yet the program construct, unlike the poet's words, is real in the sense that it moves and works, producing visible outputs separately from the construct itself. It prints results, draws pictures, produces sounds, moves arms. The magic of myth and legend has come true in our time. One types the correct incantation on a keyboard, and a display screen comes to life, showing things that never were nor could be. Programming then is fun because it gratifies creative longings built deep within us and delights sensibilities we have in common with all men."

If we had tools that allowed everyone (including jurors) to do natural language programming, half of the legal arguments we are hearing would become both laughable and moot.

Like any other speech computer programs should have some protections. That doesn't mean that you can say or do anything in a program that you'd like without any legal consequences. That's true of other forms of speech. You aren't free to slander, libel, or commit perjury, and etc.

You can copyright speech, but SCO's claims are really all patent-like in nature. They are an attempt to silence others and to protect ideas, methods, and concepts. Anyone who can defend patenting speech or patenting the expression of mathmatical algorithms that simply describe a pre-existing fundamental truth is being silly. Patents allow the owner to forbid others simple use. Can we allow the governments to issue thousands of software patents that restrain society from simply talking or discussing fundamental or universal truths in the name of progress in the sciences or useful arts?

[ Reply to This | # ]

I said that a lot depended on the manner in which the kernel was modularized, and on the date when SVR4 adopted modules, etc. I hadn't moticed the comment that one of the ways in which UnixWare 7.1.3 differed from previous UnixWare and was similar to OpenLinux/SLES 8, was in the support for the Xeon processor. I somehow doubt that you can modularize processor support the way you can modularize IO card support, etc.

So it comes down to the question of whether or not the Xeon processor support in UnixWare 7.1.3 has the same binary signature as that in OpenLinux.SLES 8. If it has the same binary signature, then the likeliehood that it indeed the self-same code as in OpenLinux/SLES 8 just jumped exponentially to something like 80 %, and you can bank on that. If not, then the likeliehood is that they merely clean-roomed the support, still relying on the OpenLinux/SLES 8 implementation to a hideous degree, but still, they're let off the hook.

I should've raised this issue earlier - mea culpa.

[ Reply to This | # ]