Maintaining SCO compatibility

38
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.”

Category:

  • Linux