This is an old revision of the document!
Table of Contents
Seismic Unix coding rules
Development rules for Seismic Un*x
Seismic Unix has remained a stable, easy to install, and transportable package by following a few simple rules.
Don't change the header structure
The first of these is that changing the SU header definitions is forbidden. The header structure looks deceptively simple, but contains a hidden trap, that it is possible to easily introduce a gap in the header that would render the SU data made under a new system mutually incompatible with that made by other versions of SU.
Avoid mix-language programming
One of the stumbling blocks of older versions of SU was the use of subroutines written in different languages, such as Fortran, made porting the code quite difficult. Expert programmers likely will scoff at this statement, but remember, SU is designed so that non-expert users may easily install, use, and expand this package.
Avoid making SU dependent on Third Party packages
Many users have wondered why SU does not depend on such widely available packages such as FFTW (Fastest Fourier Transform in the West) or GSL (the GNU scientific library). The basic reason is that SU predates many of the available open source packages that users have available. In this way, SU has always been developed from the point of view of being completely self-contained.
The reality is that the more items that a user must fetch to install your code, the less likely that they will want to use it. You will also be at the mercy of whims of third party developers who may decide arbitrarily to change their code.
Do not include commercial software
There are a number of “open” packages, such as Numerical Recipes, that are commercial packages, but are not really open source. It is forbidden to introduce such code into the SU collection.
Be conscious of the open source license
The SU materials are released under a Berkeley-style open source license. This choice avoids the viral aspect of the GNU Public License. Commercial developers may think twice about making use of GPL Licensed items, because of the requirement that improvements must be returned to the originators of code, and that derivative code automatically inherits the GPL License.
The limitation is that while code released under a Berkeley License may be absorbed into a GPL software collection, the reverse is not true. You may not include GPL licensed code in the SU distribution.