It seems to me to be important in this context to draw the distinction between _software_ which is about the most ephemeral thing I can think of (OK maybe butterflies are more so) - e.g. try compiling code published > 5 years ago - and _algorithms_ which if well constructed are potentially everlasting (how many programmers still use Knuth's data structure & sorting algorithms?). One assumes that the only lasting commitment of the author is to supply the version of the code _as_it_was_ when the paper was published (for the purpose of replicating the results in the paper), he's not committed to maintaining the program so that it's still guaranteed to work _now_ (but may well not replicate the results), i.e. he's not committed to supplying updates for ever! So unless of course the code was designated Open Source and kept maintained by the community, the old code may not be much use to anyone for very long without the programming expertise needed to adapt it to new versions of OS's etc. But note that Nature Methods doesn't stipulate that the code must be Open Source, only that the code or executable is made "available to readers promptly on request".
The problem is that the important features of an algorithm tend to get obscured by the nitty-gritty details of its implementation in code. On the other hand, even a programmer who knows nothing about the underlying science should be able to code a well-written algorithm using whatever is the language flavour-of-the-day. So it seems to me that it's just as important to establish good algorithmic standards in order to ensure that the methodology is completely and correctly expressed in the published algorithm, as it is to enforce software availability. Cheers -- Ian > -----Original Message----- > From: CCP4 bulletin board [mailto:[EMAIL PROTECTED] On > Behalf Of Nat Echols > Sent: 26 March 2007 00:12 > To: [email protected] > Subject: Re: [ccp4bb] Nature policy update regarding source code > > > I thought that some of you might be interested that the > journal Nature > > has clarified the publication requirements regarding source code > > accessibility. It is likely that some of you deserve congrats > > for this. Cheers! > > > > http://www.nature.com/nmeth/journal/v4/n3/full/nmeth0307-189.html > > > > Although there are still some small problems, I think that this is a > > big step forward, and certainly an interesting read, if you are > > interested in FOSS and science. > > Any chance of getting the IUCR to implement some policy like > this? (Or > the public funding agencies?) > > Disclaimer This communication is confidential and may contain privileged information intended solely for the named addressee(s). It may not be used or disclosed except for the purpose for which it has been sent. If you are not the intended recipient you must not review, use, disclose, copy, distribute or take any action in reliance upon it. If you have received this communication in error, please notify Astex Therapeutics Ltd by emailing [EMAIL PROTECTED] and destroy all copies of the message and any attached documents. Astex Therapeutics Ltd monitors, controls and protects all its messaging traffic in compliance with its corporate email policy. The Company accepts no liability or responsibility for any onward transmission or use of emails and attachments having left the Astex Therapeutics domain. Unless expressly stated, opinions in this message are those of the individual sender and not of Astex Therapeutics Ltd. The recipient should check this email and any attachments for the presence of computer viruses. Astex Therapeutics Ltd accepts no liability for damage caused by any virus transmitted by this email. E-mail is susceptible to data corruption, interception, unauthorized amendment, and tampering, Astex Therapeutics Ltd only send and receive e-mails on the basis that the Company is not liable for any such alteration or any consequences thereof. Astex Therapeutics Ltd., Registered in England at 436 Cambridge Science Park, Cambridge CB4 0QA under number 3751674
