Re: Packaging BLAT for Debian
Andreas: If clustal, cufflinks, phylip, paml and many other
bioinformatics packages are just fine in the non-free repo, couldn't
we do the same with blat?
http://http.us.debian.org/debian/pool/non-free/c/
http://http.us.debian.org/debian/pool/non-free/e/
http://http.us.debian.org/debian/pool/non-free/p/
On Wed, Oct 25, 2017 at 1:59 PM, Jim Kent <jimkent@ucsc.edu> wrote:
> We attempted to get it into in the non-free section last time, and
> that is where we still ran into problems where the Debian folks didn't
> like our usual license, I went through a web site to find a standard
> license for noncommercial use that they could agree with, and then
> they couldn't work with what I'd found there for a reason that seemed
> like a lawyer's or ontologist's nits, and it seemed like it would be a
> time consuming and potentially expensive thing to find a solution that
> would make everyone happy.
>
> At any rate, this current thread seems to be based on us no longer
> charging for or restricting commercial use, which is false. Our
> license is still same as ever.
>
> On Wed, Oct 25, 2017 at 1:23 PM, Maximilian Haeussler <max@soe.ucsc.edu> wrote:
>> Is there any chance to get it into the non-free repo?
>>
>> Debian has other non-OSS software packages that it distributes as part
>> of non-free. Why not BLAT?
>>
>> On Wed, Oct 25, 2017 at 1:06 PM, Andreas Tille <andreas@an3as.eu> wrote:
>>> Hi Kent,
>>>
>>> thanks for your quick reply.
>>>
>>> On Wed, Oct 25, 2017 at 11:44:02AM -0700, Jim Kent wrote:
>>>> Hi - Blat does have it's own unique license. The essence of it is
>>>> that it is free for personal, academic, and non-profit use, and
>>>> requires a fee paying license from Kent Informatics for commercial
>>>> use. I spent some time trying to find a standard license that fit a
>>>> year or two ago, and then apparently it wasn't standard enough. I'm
>>>> kind of reluctant to go through that exercise again. Is there no way
>>>> you can use our very simple license for non-commercial users?
>>>
>>> I think I explained in the past in detail that *any* restriction for
>>> *any* user makes the code non-free and can not distributed with Debian
>>> (and in the same manner not with seqtools which is GPL-3). I had the
>>> impression that you was willing to drop the non-profit use restriction
>>> but it seems I was wrong. The reason that you did not found a standard
>>> Open Source license is that your restriction is in conflict per
>>> definition with Open Source licenses.
>>>
>>> I had this discussion with Joe Felsenstein for years and he finally
>>> realised that the non-commercial restriction has more drawbacks (like
>>> beeing not included in any Linux distribution) than advantages (really
>>> low payment from commercial users ... are you sure that commercial
>>> users really pay for a license in their closed products?)
>>>
>>> This idea has distributed quite widely in scientific software world
>>> and may be you reconsider your decision.
>>>
>>> Kind regards
>>>
>>> Andreas.
>>>
>>>> On Wed, Oct 25, 2017 at 3:20 AM, Andreas Tille <andreas@fam-tille.de> wrote:
>>>> > 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
>>>>
>>>
>>> --
>>> http://fam-tille.de
Reply to: