NixWarrior writes "NOTE: This report hereby placed in public domain, use it as
you wish, at your own risk!
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.
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")
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.
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-specific extensions
In particular don't use these names
(please help with this list - "list 8")
9. Don't accidentally introduce code that crashes on, or checks for SCO
specific files/directories
(please help with this list - "list 9")
10. Do answer support questions from SCO and their customers in a helpful and
timely fashion."
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:25:33 EDT