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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> >> > 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 <[email protected]> >> >> > > 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
