Slashdot Mirror


SCO Says It Has No Plan To Sue Linux Companies

cadfael writes "SCO is reported in the Age as saying they 'Have no plans to sue Linux companies...' This seems to contradict the earlier statements of Chris Sontag. This story also points out how Canopy owns stakes in several other Linux companies, including Linux Networx wheich supplied the supercomputer for Lawrence Livermore Nat Lab. One begins to wonder if the reality of their situation has become clear to them?" Maybe, just maybe, this is the beginning of the end of this mess.

10 of 478 comments (clear)

  1. Timeline of events? by JessLeah · · Score: 5, Interesting

    I'd like to see a timeline of events in this whole SCO debacle. Should make for some interesting reading. Skimming back through a billion SlashDot stories would be a pain.

    1. Re:Timeline of events? by hdparm · · Score: 4, Interesting
      Strangely enough, in this case there is an:

      e. Profit

      which Darl and other SCO executives made by inflating share value through FUD. I wonder if they'll be left alone to enjoy $$$ after this saga is over.

    2. Re:Timeline of events? by Bohnanza · · Score: 4, Interesting

      On TV the other night I watched in disbelief as a Stock Analyst recommend his viewers buy SCO stock. "There's a little problem with the ownership of the operating system," he said, "but we feel it will all be worked out soon enough".

      --

      -----

      Sorry, I'm only a 1336 h4x0r.

  2. I wouldn't let our guards down just yet..... by StickMang · · Score: 5, Interesting

    The Age is the only place i could find this story, and it contradicts everything that SCO has said so far. The only somewhat related story I could find is this one. Oh well, maybe I'm just paranoid, but I trust SCO about as much as a nigerian spammer on peyote, so I think they're up to something.

  3. of COURSE they're not suing companies... by nemo · · Score: 5, Interesting

    ...they sent letters to USERS, not COMPANIES.

    They sue the users who can't afford legal costs and will settle just for the sake of avoiding legal hell, and SCO gets a nice precedent running and their stock improves yet further.

    Maybe I'm too cynical?

  4. Lawsuit I'd like to see by tm2b · · Score: 5, Interesting

    I'd like to see a class action suit from shareholders of Linux companies against the SCO executives, for fraudulent stock manipulation.

    They went after Martha Stewart for a hell of a lot less than this.

    --
    "It is our blasphemy which has made us great, and will sustain us, and which the gods secretly admire in us." - Zelazny
  5. (Controlling?) Intrest. by MrLint · · Score: 4, Interesting

    I think the small print here is perhaps the most frightening of all. Why is Canopy getting involved with other linux vendors? What are they doing with their 'own' linux? Is this a plot to co-opt the linux businesses from the inside? Does Canopy have the resources to gain so much control of the major linux vendors to shut them down and make SCO the only game left in town?

    Something smells very rotten here.

  6. Maintaining SCO compatibility by Anonymous Coward · · Score: 5, Interesting

    Version 1.12 - Note: Features/bugs listed may not apply to some SCO products/versions

    NOTE: This report hereby placed in public domain, use it as you wish, at your own risk!

    Additional suggestions, detailed specific recommendations, comments, requested.

    Obviously it is a concern to GPL software authors that they maintain compatibility with the SCO platforms, while SCO publicly abuses them, tries to get the GPL declared invalid, and while SCO profits from selling their software and integrating it into future releases of the SCO product line.

    Software authors will be aware that breaking SCO compatibility may cause problems for SCO users - (although strictly speaking that is SCO's problem, not the software author(s)', unless the author(s) have some contractual relationship with SCO or SCO customers).

    SCO needs support revenue (and new sales revenue) that may depend on GPL products, to fund their PR and litigation. Thus, software authors, who not obligated to support SCO, presumably might want to.

    Therefore here is a list of things NOT to do, if you don't want to break SCO compatibility.

    1. Don't refactor your code, rearrange files, move functions between files, and rename files more logically in the same release as one which contains accidentally contains one or more SCO incompatible changes.

    If you do this, it would make it harder for SCO or their partners to re-introduce any "lost" code that was necessary to support the SCO's platforms. Obviously you wouldn't want that.

    2. Don't accidentally remove SCO support in a series of stages, which overlap in time with a bunch of critical security or bug fixes, without making it clear at which stages you accidentally removed SCO support.

    3. Don't accidentally remove any special fixes or work rounds for SCO platforms.

    4. Don't depend on functions, which are not implemented or perform differently on SCO platforms. Especially don't depend on those functions in lots of different places in your product.

    In particular avoid these functions:

    (please help with this list - "list 4")

    Known bugs in SCO products:

    Unixware: accept() does not set the sa_family value correctly for the AF_UNIX family. See http://mail.python.org/pipermail/patches/2001-Augu st/005630.html
    Unixware: atan2() does returns pi instead of zero for atan2(0, x). See http://mail.python.org/pipermail/patches/2001-Augu st/005630.html

    5. Don't depend on compiler features that might not be available on SCO platforms. This is especially true if, as has been suggested may occur, new versions of GCC don't support SCO platforms.

    In particular don't depend on these compiler features:

    (please help with this list if and when GCC loses SCO support)

    6. Don't put in messages that display only on SCO's platforms.

    Avoid putting in code like (and especially not commenting):

    #if defined(_SCO_DS)
    /* SCO OpenServer */ darlsux() ;
    #elif defined(__UNIXWARE__)
    /* UnixWare gcc */ darlsux() ;
    #elif defined(__USLC__)
    #if defined( __STDC_VERSION__ ) && __STDC_VERSION__ == 199409
    /* Gemini I cc (SCO UnixWare 7 and UDK) */ darlsux() ;
    #else
    /* SCO UnixWare cc */ darlsux() ;
    #endif
    #elif defined(M_UNIX)
    /* ODT 3 or earlier */
    #else
    /* Other platform */
    #endif

    7. Don't remove support in your makefile for building the application on SCO's platforms.

    8. Don't rename your functions and variables with names that conflict with SCO-spe

  7. Even this statement is only a partial truth by gmhowell · · Score: 4, Interesting

    At best, this is only a partial truth:

    "No. SCO has never planned to sue Linux companies."

    It should say "SCO doesn't plan to sue any more Linux companies." They've already sued a Linux company. I'll give you a hint: the company's initials are IBM.

    --
    Jesus was all right but his disciples were thick and ordinary. -John Lennon
  8. Re:10 million ain't that much by shaldannon · · Score: 4, Interesting

    I guess they're hoping to acquire^h^h^h^h^h^h^hextort enough from their suit against IBM to pay for suing everyone else. I think if you're going to do the frivolous lawsuit thing that the RIAA has a better plan: screw the small fish who can't afford to fight it. IBM ain't gonna settle this one the way an average linux user might, simply because they have orders of magnitude more money. SCO bit off more than they can chew just taking on IBM, let alone with what appears to be a baseless case.

    What I want to see is IBM win, then go after SCO's assets (what few will be left) and press for criminal charges against its execs.

    Whatever happens, after reading ESR's Haloween 9 yesterday, I don't think anybody should want to keep the OpenServer cruft...win it and then put it out of everyone's misery.

    --


    What is your Slash Rating?