VMD-L Mailing List

From: John Stone (johns_at_ks.uiuc.edu)
Date: Mon Oct 07 2013 - 09:08:35 CDT

Johannes,
  In regards to the download/build script. I think that it would be fine
if you provide a Debian package or a script like the one you attached that
allowed the user to enter their username/pw and automatically downloaded
the source archive from our web server and compiled it for them.

In my view, the script does not violate the license agreement, and it provides
us with the user statistics that the funding agencies require.
The intent of our license was not to make it hard for people to obtain VMD,
but mostly to meet the reporting requirements of funding agencies and
the like.

If there is a way we could better accomodate an automated
download+build scheme like what you have proposed, I would be happy
to try and help you streamline the process further.

In my previous email I didn't get into the details of why VMD doesn't
use autoconf by default, but in principle there's no reason that we
couldn't "also" provide an autoconf-based build in addition to the
normal one. Some of our builds (e.g. Windows, Android,
various supercomputers) are not well suited to autoconf, and in particular
cases that would require cross compilation (e.g. Android) don't work
well with modern versions of autoconf, but in principle it would be
fine to have an autoconf based build as an alternative for run-of-the-mill
VMD builds on Linux, *BSD, etc.

Cheers,
  John Stone
  vmd_at_ks.uiuc.edu

On Mon, Oct 07, 2013 at 09:11:37AM +0200, Johannes Schauer wrote:
> Hi John,
>
> thanks for your reply :)
>
> Quoting John Stone (2013-09-17 18:05:14)
> > There are several motivations here. One of the major ones is that our
> > funding agencies require us to report the number of registered VMD users.
> > You'll note that things are done similarly for other software tools in our
> > field like Chimera, PMV, AMBER, NAMD, and many others. They too likely have
> > to report their user numbers to their funding agencies.
>
> Yes indeed. It is unfortunately a very common reason why software in that field
> can't make it into Debian main :(
>
> > Another issue is that VMD users expect help and support with getting VMD
> > running on their systems, and we find it much easier to deal with supporting
> > builds of VMD we made ourselves, rather than having to track the behavior of
> > binaries produced by other people without our knowledge. On the one hand, it
> > would be nice to have VMD in every Linux distribution, but on the other it
> > would greatly multiply the number of build scenarios we would have to be
> > aware of. This comes up with strange bugs like the problems that certain
> > versions of Tcl/Tk have with SCIM (internationalized input), issues with
> > certain versions of OpenGL headers, CUDA versions, and other library
> > dependencies that have nothing to do with the code in VMD itself.
>
> It is the task of the distribution maintainers to make sure that the upstream
> software (vmd in this case) works flawlessly within their chosen operating
> system. To that end, bug reports of Debian users should be sent to the Debian
> bug tracker first. If users do not do that and report to upstream instead, then
> upstream will usually refer them to the bugtracker of their distribution. It is
> then the task of the Debian maintainer to find out whether it is a Debian
> specific bug or a bug in the upstream software itself and to make sure that it
> gets fixed in his distribution or even upstream.
>
> > If we allowed redistribution, we could no longer count on people using the
> > "best" library version (from the point of view of VMD specifically). They
> > would instead be compiling VMD dynamically against "whatever" version of
> > these library dependencies the Linux distribution preferred. And for closed
> > source things like CUDA, OptiX, and/or other libraries, the users of those
> > Linux distributions would likely be missing those features of VMD by default,
> > which I think is an undesirable outcome. I have yet to see a Linux distro
> > that ships pre-compiled binaries that depend on anything that's closed
> > source. I would hate to see a default build of VMD that disabled CUDA
> > acceleration for example... I don't know of any open source OpenCL driver,
> > so that too is the same issue. I would rather that users get full-featured
> > builds of VMD with all of these components enabled, even if that means that
> > they have to get them from us, or worst case, by compiling themselves from
> > source.
>
> Maybe you are talking about something different but I did build vmd with cuda
> (which is also in Debian but non-free of course [1]).
>
> [1] http://packages.debian.org/sid/nvidia-cuda-toolkit
>
> I planned to (but didnt implement yet) build vmd twice. Once with and once
> without cuda and then ship a binary package with each of them. The default
> right now is to build with cuda support enabled. For people who cannot make use
> of cuda, I wanted to offer a version without it so that they do not need the
> huge bunch of dependencies that comes with the Debian non-free cuda packages.
>
> > > Next, I want to present a number of patches which I'm currently applying to
> > > vmd. Maybe they can be considered to be integrated in the next vmd release.
> > > The patches are by me and Michael Banck and others of the debichem team.
> >
> > I appreciate your patches, and I will start looking at them later this
> > week after I get past some deadlines. Hopefully we can accomodate many
> > of your suggestions, and in cases where we cannot, maybe we can find a
> > compromise that simplifies things specifically for the Debian community.
>
> Well the biggest blocker is of course the missing redistribability of vmd which
> makes it impossible to just use Debian's package manager. To that end I came up
> with the following Python script:
>
> --%<---------------------------------------------------------------------------
> import mechanize
> from lxml import etree
> import sys
> from subprocess import call
>
> br = mechanize.Browser()
>
> br.open("http://www.ks.uiuc.edu/Development/Download/download.cgi?UserID=&AccessCode=&ArchiveID=1190")
> def handler(n):
> try: return "UserName" in n and "Password" in n
> except: return False
> br.select_form(predicate=handler)
> br["UserName"] = sys.argv[1]
> br["Password"] = sys.argv[2]
> resp = br.submit()
>
> def handler(n):
> try: return "LicenseText" in n
> except: return False
> br.select_form(predicate=handler)
> print br["LicenseText"]
>
> def handler(n):
> try: return "AgreeToLicense" in n
> except: return False
> br.select_form(predicate=handler)
>
> resp = br.submit("AgreeToLicense")
>
> tree = etree.fromstring(resp.read(), etree.HTMLParser())
> call(["wget", "http://www.ks.uiuc.edu"+tree.xpath("//meta[@http-equiv='refresh']/@content")[0][6:]])
> -->%---------------------------------------------------------------------------
>
> That script automates what one would otherwise have do in the browser to
> download vmd. To execute it, the username and password have to be given on the
> commandline. The dependency on the mechanize Python module can easily be
> dropped by more manual parsing of the returned html and after the license text
> is printed, the user should be asked whether or not he agrees with it instead
> of just continuing.
>
> It would be possible to create a package that contains above script and uses it
> to automatically retrieve the latest vmd version, given an existing username
> and password. This is similar to what is currently done for Adobe Flash as
> Adobe also forbids redistribution of its binary.
>
> Would this be an acceptable solution, given that the vmd license will likely
> not change any time in the foreseeable future?
>
> cheers, josch 

-- 
NIH Center for Macromolecular Modeling and Bioinformatics
Beckman Institute for Advanced Science and Technology
University of Illinois, 405 N. Mathews Ave, Urbana, IL 61801
http://www.ks.uiuc.edu/~johns/           Phone: 217-244-3349
http://www.ks.uiuc.edu/Research/vmd/