Hi,
On 12/14/2015 12:38 AM, Maintainer wrote:
Hi Jim,
do you consider Michael's hint helpful. As you know we are taking
licensing issues serious (I'm wondering whether the people you want to
protect your code from are doing so as well or whether you are just
keeping away from using the code the honest one who care ;-) ). Please
let us know if you want us to remove the affected code from Debian by
removing about 10 BioConductor packages.
Only 10 really? rtracklayer is part of the core stack and provides
functionalities like import/export of GFF, 2bit, BED, etc... and other
commonly used bioinformatics file formats. 174 software packages
and 140 annotation packages depend directly or indirectly on it in
BioC 3.2. Also without rtracklayer the user can't access thousands
of annotation resources provided thru AnnotationHub.
It's one of the most used BioC packages with thousands of downloads
per month (ranked #18, see
http://bioconductor.org/packages/stats/index.html).
I don't know what a re-packaging of BioC would look like without
rtracklayer. Probably not that useful and likely to cause some
frustration.
I hope the licensing issue can be sorted out.
Thanks,
H.
Kind regards
Andreas.
Mental note to myself:
I somehow could imagine a "Free your code for Christmas" initiative
in general. May be we should think about this for 2016 at least.
On Fri, Dec 11, 2015 at 09:18:36AM +0000, Michael Crusoe wrote:
If you are looking to ensure that derivative works aren't relicensed, and
you want to use an existing license (which I recommend) then you are
looking for a copyleft license.
I like this interactive guide to software licenses:
http://oss-watch.ac.uk/apps/licdiff/
On Fri, Dec 11, 2015, 10:35 Andreas Tille <andr...@an3as.eu> wrote:
Hi Jim,
On Fri, Dec 11, 2015 at 09:03:50AM +0100, Jim Kent wrote:
Perhaps I did not phrase it directly enough. I ended my last email with
Perhaps in your files is a license that has a word or two on this
subject
already?
By this I mean, do you have a license that mentions something about not
allowing sublicenses on the license? Could you send it to me if you do?
I'm afraid I'm not sure what you mean by "sublicenses". Do you think
that redistribution of possibly changed code is "sublicensing"? Please
check whether the license you have in mind will have any conflict with
the following DFSG guidelines which are widely accepted as open source
definition:
https://www.debian.org/social_contract#guidelines
If you see any conflict in any of these items we probably can not find
any license that will fit your needs. It would help if you would
exactly specify what you want to approach with the license.
Kind regards
Andreas.
--
http://fam-tille.de
_______________________________________________
Debian-med-packaging mailing list
debian-med-packag...@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-med-packaging
--
Hervé Pagès
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpa...@fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
