I'm not a programmer, otherwise I would make sure I
wouldn't do anything of these things 'accidentally'
.........but deliberatel! But that was not the intent
of this message, now was it?
--- Smitty <a.smitty@verizon.net> wrote:
> 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."
>
>
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
This archive was generated by hypermail 2.1.3 : Fri Aug 01 2014 - 20:25:34 EDT