[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