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.
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.
Honey, I shrunk the Cygwin
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.
StickMan
www.rageagainst.net
...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?
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
Version 1.12 - Note: Features/bugs listed may not apply to some SCO products/versions
/* SCO OpenServer */ darlsux() ;
/* UnixWare gcc */ darlsux() ;
/* Gemini I cc (SCO UnixWare 7 and UDK) */ darlsux() ;
/* SCO UnixWare cc */ darlsux() ;
/* ODT 3 or earlier */
/* Other platform */
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)
#elif defined(__UNIXWARE__)
#elif defined(__USLC__)
#if defined( __STDC_VERSION__ ) && __STDC_VERSION__ == 199409
#else
#endif
#elif defined(M_UNIX)
#else
#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