IUBio

Unix vs Linux - the movie.

Michael Schmitz schmitz at biophys.uni-duesseldorf.de
Thu Jul 27 13:41:05 EST 2000


Andrew Dalke wrote:
> 
> John S. J. Anderson wrote:
> >I decided a while ago not to use _any_ closed source software for
> >science if it was at all possible. If you think about it, true peer
> >review isn't possible unless you can see the source. I'm just waiting
> >for the inevitable report of the bug in microarray quantitation
> >software (to pull an example out of the air) that will result in paper
> >retractions.
> 
> Out of curiosity, what are your feelings on software where you get
> the source but it isn't "open source."  For examples, DSSP, MolScript
> and XPLOR are all packages (can you see my structure background :)
> where you get the source code, even for free for academics, but
> you are not allowed to redistribute the source or any changes.

You didn't ask me but I'll answer anyway. Having used both XPLOR and
(currently) CNS, I am aware of the more restrictive licenses which
usually don't permit redistribution, and I'm fine with such licenses up
to a point. Not being permitted to share changes I made wth people I
collaborate with is going a tad too far. Imagine add-ons like new force
field terms as developed at NIH for instance. These restrictions usually
are meant to 
avoid having someone put up a server with lots of useful patches for a
popular piece of software, thereby effectively forking the code base
even though people still need to get the original source distribution.
In practice, forking is prevented much more efficiently by the software
authors incorporating such enhancements in future releases (such as the
dipolar coupling stuff in CNS, guess you know what my background is by
now). I am very much willing to respect that aspect of such licenses,
and help the authors by signing copyright to my changes over to them.
Giving patches to people at other labs who I cooperate with in
developing enhancements is a more borderline issue. I don't want to have
abstract information about code changes pass to others via lawyers or
employ other cleanroom tricks. 

> Looking at DSSP's academic license, for example, at
> http://www.cmbi.kun.nl/gv/dssp/license.html shows quite a few things
> which are prohibited according to the Debian free software guidelines,
> like restriction from doing classified work.

Restrictions placed on the use of software are another sordid story.
This fits neither the open source nor free software definition which I
hold are important milestones for true open source development. But
theses programs aren't developed in any sort of open source way anyway
so there's no problem with them picking whatever license they please
(though I would like either Free or Open better). Both from a peer
review and customization point of view, any license granting access to
source with more restrictions attached than in the OSD case is a huge
lot better than completely closed source software. 

> (Actually, this reminds me of math class where there are sets which
> are open, sets which are closed, sets which are neither open nor
> closed :)

Yep, most biosoftware packages we know are neither open nor closed
source in that context. Which makes it impossible to include them with
your favorite Linux distribution (but one), but then, how big is the
demand? (Hmm... CNS at home doing numbercrunching for me as the
screensaver/waste of spare cycles on thousands of PCs might be kind of
nice :-)

	Michael







More information about the Bio-soft mailing list

Send comments to us at biosci-help [At] net.bio.net