[Rd] Non-GPL packages for R

[Dirk Eddelbuettel]

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.