[Biopython-dev] Developmental policies

Bruce Southey bsouthey at gmail.com
Tue Jan 13 16:50:28 UTC 2009


Tiago Antão wrote:
>> I think we must be explicit in this and ensure that any accepted code is
>> BSD-compatible because we can not ensure what people really know. Further
>> the license of any application that Biopython interacts with must be clearly
>> stated and the developer is responsible to get one if it does not have one.
>> That way we know what is included and should help users as well in terms of
>> whether or not they can use some application.
>>     
>
>
> A point is not clear here to me: If you only interact with an (say
> command-line and web-based) application, is there a problem if that
> application has an unspecified license? There are 3 dimensions here
> that I find important
> 1. If biopython interacts with a application with no license are there
> possible liabilities with regards to the project? The same question in
> regards to users? 
>   
I do not think that there is any real difference between the developer 
and the user as ignorance is usually not a good defense.

If you use code from another application in your project with little or 
no modification (such as rewriting the code into Python) or did 
reverse-engineering or even looked at the code then your application 
could be controlled by the license of that application. Obviously if it 
has a license then you must abide those terms. If it does not have a 
license and you do not get permission to use that code then you have 
violated the original author's copyrights and you are liable for 
damages. Of course, as in one of the most important open-source related 
cases in the USA, the Jacobsen v. Katzer case (eg 
http://www.groklaw.net/article.php?story=2008081313212422 ) about the 
Java Model Railroad Interface (JMRI), those damages may be nothing.

> 2. I would remember that interaction might be library based (with
> linking - where we know problems exist), command-line based (are there
> any problems?) and web-based (are there any problems different from
> the command-line case?).
>   
Unless the application forbids it then there is no problem on how you 
actually run the application. As Peter said, web tools also have 
conditions that you have keep or you will find yourself locked out.

The main problem is using someone else's code in your project and the 
real problem is the actual terms of the code used. Using a function from 
that code in yours is a potential violation such as how to parse the 
output especially if it is in a binary format.  If your code clearly 
follows the published documentation or a clean-room approach (see 
http://en.wikipedia.org/wiki/Clean_room_design ) was properly used then 
there should no problems. Linking only becomes a problem if your code 
can be considered a derivative or the license forbids linking such as 
the GPL but not the LGPL. However, this is a grey area as evident from 
the use of binary drivers in Linux.

> 3. I would suppose (for licensed non-free apps) that some licenses
> might not be clear in regards to this kind of usage. Would it be
> necessary to inspect the licenses in detail?
>   
Yes, you must inspect any license in detail because even downloading the 
code can involve or imply acceptance of the terms. Some licenses, 
usually for commercial applications, are rather nasty in terms what can 
and can not be done like no reverse engineering. Even open source 
license like the GPL v3 can have some unexpected side effects (ie 
related to patents). Most non-open source licenses (including academic 
only licenses) that I have seen related to bioinformatics usually are 
aimed at restricting the commercial usage of the code and the subsequent 
distribution of it. But you need to see if there are other restrictions 
involved that limit the output from that application.

> A strict view regarding software without licenses (ie, no interaction
> at all) would require immediate removal of the fdist code (not very
> important, it is the part that is probably not used by anyone). No
> inclusion of LDNe code. And more importantly no STRUCTURE interaction
> code and no Genepop interaction code (although the file format parser
> that currently inside is OK).
>   
If the interaction is just creating inputs, running the standalone 
application and parsing the output, then those interactions should be 
okay. Obviously the code to create the input and parse the output must 
be free of the application like based on public documentation or a 
clean-room approach.

If the interaction creates a derivative such as when the code of the 
application is required in addition to your code then it is not okay. 
Further, as Peter commented elsewhere, there needs to be strong 
justification to include it into Biopython. Rather I would strongly 
suggest that you try to get your code included in the other application 
as it may help other users and you don't have to maintain a version of 
the original application.
> So, the very pertinent question are:
> 1. Can biopython command-line interact with applications with no license?
>   
Yes, but must not be considered a derivative of the application or it 
must do so in terms of the license. For example, AlignACE uses the 
Harvard  University license where everyone using it must have their own 
license or it can be run on a second computer provided that only one 
copy is running at a time.

> 2. Is biopython interacting with applications (command-line or web)
> for which the license is not clear regarding interaction with
> software?
>   
I do not know the answer to this question because I do not know or use 
all the applications involved. However, we do need to create a list of 
applications with associated web sites and licenses that Biopython 
'interacts' with which would answer this question.

Regards
Bruce



More information about the Biopython-dev mailing list