[Biopython-dev] Structure and LDNe

Jason Eshleman jae at lmi.net
Thu Jan 8 22:24:21 UTC 2009

Greetings all,

Presently, the code I have for dealing with STRUCTURE is similar to the 
code for interacting with Clustal in that it does not modify any of the 
STRUCTURE source code by merely initiates the compiled executable.

Initially, I have used my code in place of their Java front end as it 
allows for more control of the run-time variables for successive runs with 
varying run parameters.  At some point, I'd like to get it to interface 
more directly with the STRUCTURE code to be able to pipe results directly 
to python for parsing rather than working with the STRUCTURE text output 
but that's a ways off still.


At 09:41 AM 1/6/2009, Bruce Southey wrote:
>Tiago Antão wrote:
>>Hi all,
>>Jason Eshleman (he subscribes to this list also) has made available
>>code to interact with Structure (a widely used application in
>>population genetics - the 2 papers related to it have around 3000
>>citations acording to Google scholar). We will try to convert his code
>>to the Bio.PopGen namespace, create documentation and test cases.
>>To this adds the exsiting LDNe code (mine). This all should be ready
>>in a reasonably fast time frame (I suppose before the next release).
>>The all important statistics part is still due, I am afraid (I don't
>>know if anybody has looked at the beta code on git). But at least this
>>LDNe and Structure code will be ready to go soon.
>>Biopython-dev mailing list
>>Biopython-dev at lists.open-bio.org
>What are the licenses for LDNe and Structure?
>Saying just 'free' is insufficient because it is not clear in which 
>definition is being used.
>Also, please ensure that none of the code that is included into Biopython 
>is not a deriviative of LDNe and Structure unless these have explicit 
>license that is compatible with Biopython.  For example, 'copying' an 
>existing function into Python would be considered a derivative. Obviously 
>reading a documented output is probably not considered a derivative.
>I prefer to be proactive with licenses so these don't bite back like has 
>happened in some formally open sources projects or use of unclean code 
>sources. A current example of this is that the current release of scipy 
>0.7 has been significantly delayed due to some major effort to check 
>various functions that reference the Numerical Recipes book (which has an 
>incompatible license).
>Anyhow, this sounds good!
>Biopython-dev mailing list
>Biopython-dev at lists.open-bio.org

More information about the Biopython-dev mailing list