[Rd] Non-GPL packages for R

Gabor Grothendieck ggrothendieck at gmail.com
Fri Sep 11 18:19:09 CEST 2009

One complication is that its possible that a package can use a non-free
component but can also be used without it.  The fame package could
be used with fame or without fame for a long time but more recently the
non-fame portion was factored out into the tis package.  The VhayuR
package is similar in that it can be used without Vhayu.  In that case it
can use flat files instead of the Vhayu database.

On Fri, Sep 11, 2009 at 11:44 AM, Dirk Eddelbuettel <edd at debian.org> wrote:
> On 11 September 2009 at 16:37, Peter Dalgaard wrote:
> | who have responded on the list do not necessarily speak for CRAN. In the
> | final analysis, the maintainers must decide what is maintainable.
> Fully agreed. As 'maintainers' of cran2deb, Charles and I decided to 'shoot
> first, ask questions later' as we clearly wanted to avoid creating any sort
> of trouble for our generous CRAN hosts (currently just the Vienna master) are
> effectively re-distributing our compilations (of its own content).
> So we pro-actively chose to excludes some packages.  To put some meat on this
> particular bone, the current set packages blacklistes for 'nonfree-ness' is:
>  sqlite> select package, explanation from blacklist_packages where nonfree;
>  package               explanation
>  --------------------  ----------------------------------------
>  mclust                non-commercial license
>  mclust02              non-commercial license
>  ConvCalendar          no modification or distribution rights
>  SDDA                  non-commercial CSIRO license
>  conf.design           non-commercial license
>  isa2                  non-commercial creative commons license
>  optmatch              non-commercial license
>  rankreg               non-commercial license
>  realized              non-commercial license
>  rngwell19937          non-commercial license
>  tnet                  non-commercial creative commons license
>  spatialkernel         contains non-commercial gpc code
>  Bhat                  non-commercial license
>  PTAk                  non-commercial license
>  PredictiveRegression  non-commercial license
>  RLadyBug              contains some code under non-commercial
>  mapproj               non-commercial license
>  mathgraph             non-commercial license
>  sqlite>
> | (Even within the Free Software world there are current issues with,
> | e.g., incompatibilities between GPL v.2 and v.3, and also with the
> | Eclipse license. Don't get me started...)
> Yes. There is a potential problem with gcc 4.4 compilation of GPL-2 code. If
> that comes to a boil we all (as in: GPL 2 users) are in a spot of bother.
> On 11 September 2009 at 07:48, Robert Gentleman wrote:
> |    It is also the case that things are not so simple, as dependencies
> | can make a package unusable even if it is itself GPL-compatible.  This
> Yes, in the case of cran2deb / CRAN there are just three blacklists because
> of dependencies on nonfree CRAN content, most often it is dependencies on
> other stuff incl BioC which we do not include (for mostly technical /
> historical reasons; contact Charles or me offline if you'd like to work on
> changing this)
>  sqlite> select package,explanation from blacklist_packages where unsatisfied_dependency;
>  package               explanation
>  --------------------  ----------------------------------------
>  ROracle               requires Oracle to build and run
>  Rlsf                  requires LSF cluster/grid system librari
>  Rsge                  requires SGE cluster/grid system librari
>  CarbonEL              requires OS X system
>  VhayuR                requires Vhayu database system
>  gputools              requires Nvidia CUDA compiler and GPU-en
>  klaR                  requires SVMlight which is non-free
>  wgaim                 requires asreml-R
>  svGUI                 requires Komodo from OpenKomodo.org whic
>  RScaLAPACK            requires MPICH2 and Blacs and ScaLAPACK
>  caMassClass           requires PROcess from BioConductor
>  Rcplex                requires CPLEX libraries
>  ADaCGH                BioC depends: tilingArray
>  DAAGbio               BioC depends: limma
>  GFMaps                BioC depends: affy
>  GOSim                 BioC depends: GO.db
>  Metabonomic           BioC depends: PROcess
>  classGraph            BioC depends: Rgraphviz
>  gcExplorer            BioC depends: Rgraphviz
>  logilasso             BioC depends: Rgraphviz
>  pcalg                 BioC depends: Rgraphviz
>  celsius               BioC depends: BioBase
>  multtest              BioC depends: BioBase
>  hopach                BioC depends: BioBase
>  GExMap                BioC depends: multtest,BioBase
>  LMGene                BioC depends: multtest,BioBase
>  PCS                   BioC depends: multtest,BioBase
>  SubpathwayMiner       BioC depends: KEGG.db
>  gene2pathway          BioC depends: KEGG.db
>  PhViD                 BioC depends: LBE
>  SNPMaP                BioC depends: affxparser
>  qdg                   BioC depends: pcalg,Rgraphviz
>  lsa                   Ohat depends: Rstem
>  mpm                   BioC depends: geneplotter
>  sisus                 BioC depends: annotate
>  metaMA                BioC depends: limma
>  clustTool             non-free depends: mclust02
>  clustvarsel           non-free depends: mclust02
>  SpectralGEM           non-free depends: optmatch
>  bayesCGH              BioC depends: snapCGH
>  crosshybDetector      missing depends: marray
>  FEST                  needs MERLIN <http://www.sph.umich.edu/c
>  aroma.affymetrix      BioC depends: aroma.light
>  aroma.core            BioC depends: aroma.light
>  aroma.apd             BioC depends: aroma.light
>  sqlite>
> | also makes the notion of some simple split into free and non-free (or
> | what ever split you want) less trivial than is being suggested.
> That sounds like the Ostrich defense :) Nobody claimed it was easy or
> non-controversial, but it seems some of us feel that it should be discussed
> as the status quo may be something we can improve upon.
> E.g. I think that 'License: file LICENSE' is not good enough.  Some sort of
> marker at the DESCRIPTIOn level would help.  How many levels we put into an
> appropriate factor variable is open for discussion. But for argument's sake:
> why don't we start with a binary toggle of whether or not one of the licenses
> in http://www.r-project.org/Licenses/ aka share/licenses/ is met?
> CRAN has been a huge success (and I am sure the success puts a strain on its
> maintainers).  Given that it has become the 800 pound gorilla, may not use
> some of that weight to nudge folks to a set of common licenses?
> Dirk
> --
> Three out of two people have difficulties with fractions.
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

More information about the R-devel mailing list