Re: Packaging BLAT for Debian

[Andreas Tille <andreas@fam-tille.de>]

Hi again,

I'm stumbling upon some definitive answer about the license of blatSrc
which can be found in several projects.  My last hit was seqtools[1]
from Sanger which claims to be licensed as GPL-3 but as far as I can see
this would conflict with the licensing statement of the latest blatSrc
download I'm aware about[2].  So it would really help to get some
official statement under what license blatSrc can be used and where
to find the latest version.

Thanks a lot

      Andreas.

[1] http://www.sanger.ac.uk/science/tools/seqtools
[2] https://users.soe.ucsc.edu/~kent/src/blatSrc35.zip

On Sat, Sep 10, 2016 at 11:36:38PM +0200, Andreas Tille wrote:
> Hi again,
> 
> I'd like to pick up the ball for blat again.  For me it is not yet clear
> by what license blat is covered and what might be the role of the KentLib
> library[1] plays.  Is it possible to link blat against KentLib and is it
> sensible to start packaging this first.
> 
> Just to let you know:  The freeze for the next Debian release is coming
> soon and it blat should be distributed with the next release we should
> hurry up to get this done.  For me it remains unclear who is responsible
> for what and role the different pieces of code are playing.
> 
> Kind regards
> 
>       Andreas.
> 
> [1] https://github.com/jstjohn/KentLib
> 
> On Thu, Feb 27, 2014 at 12:49:06AM -0800, Jim Kent wrote:
> > Yes.  If you could reiterate some of the links,  or if you prefer just
> > forward this whole thread to Hiram, it would be great.   Then I can go back
> > to wrestling with the ENCODE monster!
> > 
> > 
> > On Thu, Feb 27, 2014 at 12:31 AM, Andreas Tille <tille@debian.org> wrote:
> > 
> > > Hi Jim,
> > >
> > > seems like we got in contact to the perfectly right time. :-)
> > >
> > > I'm happily waiting for your colleagues showing up at the Debian Med
> > > list (which I'd strongly recommend for this purpose since I'm just a
> > > member of the team and not the whole team ;-)) and repeat that one of
> > > them might be interested in our Mentoring of the Month effort
> > >
> > >    https://wiki.debian.org/DebianMed/MoM
> > >
> > > Looking forward to a great cooperation
> > >
> > >     Andreas.
> > >
> > > On Thu, Feb 27, 2014 at 12:17:09AM -0800, Jim Kent wrote:
> > > > Disabling the pslCheck seems like the sensible and pragmatic thing.
> > > >
> > > > I'm going to write a short note introducing you to Hiram Clawson, and
> > > also
> > > > Ann Zweig our project manager (and Hiram's boss).  It is actually part of
> > > > our grant to package the tools in ways to make it easier for people to
> > > use
> > > > them.   Our current system is not so bad, but it requires people to
> > > > actually read the README, and set an environment variable.   This was
> > > state
> > > > of the art in 1985, but not the
> > > >     config
> > > >     make
> > > >     make install
> > > > people are used to these days,  never mind a RPM or anything more recent,
> > > >  and most of the younger programmers get lost.
> > > >
> > > > I do think we want to do some renaming of directories and the like as
> > > part
> > > > of this process, and ideally end up with all the code that is under one
> > > > license under the same subdirectory.  It's somewhat close to that, but
> > > > there are enough exceptions to be a pain.   We switched from CVS to git
> > > > about 2 years ago in large part to make moving directories around much
> > > less
> > > > of a pain in the butt, so we _can_ do this now,  but it's been sort of a
> > > > back burner thing, and is only about 10% complete.
> > > >
> > > > Anyway,  we are paid by the taxpayers to do this sort of work, and will
> > > > make some time for it.   We would welcome your help,  and getting it into
> > > > Debian is as good a starting point as any,  better than most if we have
> > > > support from that group.
> > > >
> > > > Take care,
> > > >      Jim
> > > >
> > > >
> > > >
> > > > On Wed, Feb 26, 2014 at 11:16 PM, Andreas Tille <tille@debian.org>
> > > wrote:
> > > >
> > > > > Hi Jim,
> > > > >
> > > > > On Wed, Feb 26, 2014 at 10:33:59PM -0800, Jim Kent wrote:
> > > > > > I'm glad you isolated it to the -O2.
> > > > >
> > > > > :-)
> > > > >
> > > > > > I don't think there's a super easy way to cut pslCheck out of the
> > > whole
> > > > > > 1,200,000 UCSC genomics source tree.
> > > > >
> > > > > For the moment I simply disabled this check.  I guess it is also this
> > > > > way sufficient to detect potential problems (and it was not the
> > > pslCheck
> > > > > that failed in the first place).
> > > > >
> > > > > > I would, on the other hand, be very
> > > > > > happy for you to take on the job of packaging up that whole source
> > > tree
> > > > > for
> > > > > > Debian.   I could refer you to a less busy member of my staff,  Hiram
> > > > > > Clawson,  who has a _lot_ of experience helping people get that to
> > > build.
> > > > >
> > > > > This is a very cool offer.  I actually have thought about packaging the
> > > > > whole UCSC genomics source tree as well since it obviously contains
> > > > > several tools that perfectly fit in our scope.  I wonder whether Hiram
> > > > > might even like to learn something about Debian packaging.  In our team
> > > > > we have quite some tradition in mentoring people as you can see here:
> > > > >
> > > > >    https://wiki.debian.org/DebianMed/MoM
> > > > >
> > > > > Perhaps it comes handy if somebody in your team is capable to create
> > > > > Debian packages which in the end is not more than wrapping up the build
> > > > > process into some sceme.
> > > > >
> > > > > BTW, when I inspected the jksrc source tree (and also in the specific
> > > > > case of the blat source) I realised that it might make real sense to
> > > > > enable dynamic linking of the tools against the static libraries you
> > > are
> > > > > creating.  The Debian way to do this would be to create two packages:
> > > > >
> > > > >    lib<name>      containing the dynamic libraries
> > > > >    lib<name>-dev  containing the static libraries and header files
> > > > >
> > > > > To approach this easily it is quite convenient to use either GNU
> > > > > automake or cmake (at your preference) since these build systems easily
> > > > > support the creation of dynamic and static libraries in parallel.  This
> > > > > would also simplify the hancling of MACHTYPE in your makefiles since
> > > > > these Build systems are capable to handle this automatically.  In
> > > short:
> > > > > before we might start packaging the whole source tree it would be quite
> > > > > sensible to switch to an advanced build system which would be also in
> > > > > your profit at the end.
> > > > >
> > > > > > The licensing of it is quite complex alas.   There are three main
> > > parts:
> > > > > >
> > > > > > - a small part which is owned by me in a directory called jkOwnLib,
> > > and
> > > > > in
> > > > > > the blat directories
> > > > >
> > > > > This would probably make a separate library package.  However, you
> > > might
> > > > > consider a name which is more descriptive than jkOwnLib.
> > > > >
> > > > > > - a medium sized part that contains stuff we regard as generally
> > > useful
> > > > > > which is essentially public domain, but that we are happy distributed
> > > > > under
> > > > > > a BSD or MIT license
> > > > >
> > > > > Cool.  That would be very interesting.
> > > > >
> > > > > > - a large part that is genomics in general,  and UCSC Genome Browser
> > > in
> > > > > > particular specific that is owned by UCSC and has a license much like
> > > > > blat
> > > > > > - free for personal, academic, and non-profit use,  and requiring a
> > > > > license
> > > > > > for commercial use.  In this case the licence needs to come from UCSC
> > > > > > (contact Will Hale) rather than Kent Informatics (contact Heidi
> > > > > Brumbaugh).
> > > > >
> > > > > In case we have a good plan about the technical details we should
> > > > > probable contact these persons regarding the licensing.
> > > > >
> > > > > Kind regards
> > > > >
> > > > >     Andreas.
> > > > >
> > > > > --
> > > > > http://fam-tille.de
> > > > >
> > >
> > > --
> > > http://fam-tille.de
> > >
> 
> -- 
> http://fam-tille.de
> 
> 

-- 
http://fam-tille.de