Hi,
On Sat, May 21, 2011 at 10:00:44AM -0400, David A. Case wrote:
> On Fri, May 20, 2011, Scott Brozell wrote:
>
> > 2. any release of amber or ambertools should release both and
> > reset the counter for bugfixes, etc; yes, this means that the
> > release process must be changed so that the $$ code goes only
> > to those that paid for it. this can also get us to sensible
> > version numbers: 12.0 amber+AT, 12.1 amber12 + the next AT.
> > ( and by the way, stop thinking in terms of amber and AT;
> > there is only Amber: some of it costs $$. )
>
> But this doesn't address our problem: when a new AT is ready for release, it's
> no longer compatible with the "old" amber. If we update sander/pmemd along
> with the new AT, it upsets our pricing scheme -- maybe that's not so bad, but
> needs to be thought about.
If we are releasing both together then we can make them compatible.
Upsets the pricing scheme ?!
How about: if one paid for amber 12 then one gets 12.1, etc for
no extra charge.
> > 5. this gives us an opportunity to undo this silly amber/AmberTools
> > directory hierarchy: parts of amber cost money - if u pay
> > then u get those parts, if u dont pay then u dont get them;
>
> The (non-silly) reason for having the AmberTools directory structure is to
> make it clear which parts of the code are covered by which license. I don't
> see any way around this.
I cannot believe that there isnt a fix for this.
How about a map in the license file. Or each code has its
own directory, so a license file can be put in each directory.
> > why change the directory hierarchy? changing it was a developer
> > implementation detail.
> >
> > > On Thu, May 19, 2011, Jason Swails wrote:
> > > > option would be to sell *only* pmemd, as that program is entirely
> > > > self-contained (one could argue except for NetCDF libs, but that's unchanged
> > >
> > > I think this is a good option, but there are probably lots of ramifications.
> > > But we should seriously consider it for the next release. We would then make
> > > an (internal) commitment to keep pmemd self-contained, so that the Amberxx
> > > and AmberToolsxx are much less intertwined than at present.
> >
> > This idea looks good. And its easy to work into the above.
>
> Well, in my mind, it's actually quite different than "the above": in this
> scheme Amberxx (aka pmemd) and AmberTools become completely separated,
> both in directory structure and release timetable. If (as an example)
> we want QM/MM in pmemd, it would be a different, "mature" and only
> slowly-changing version, presumably ported from sander, but separate from
> it. The "fast" and wide-open development would continue in sander.
"The above" could work seamlessly with $$ for only pmemd,
just like with $$ for any particular code.
Frankly i think you are stuck in the false dichotomy of
Amber and AmberTools. Parts of Amber cost money; keep track
of who paid for those parts (for the only purpose of sending
them the proper tarball); the end.
scott
_______________________________________________
AMBER-Developers mailing list
AMBER-Developers.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber-developers
Received on Mon May 23 2011 - 12:00:02 PDT
