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@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel