From marc_schwartz at me.com  Thu Apr 23 22:35:54 2009
From: marc_schwartz at me.com (Marc Schwartz)
Date: Thu, 23 Apr 2009 15:35:54 -0500
Subject: [Rd] License status of CRAN packages
In-Reply-To: <18928.51543.939132.165160@ron.nulle.part>
References: <18928.48327.599527.545472@ron.nulle.part>
	<971536df0904231232vbb024c8p95456acaeae0ff6d@mail.gmail.com>
	<18928.51543.939132.165160@ron.nulle.part>
Message-ID: <77D033CF-9E55-49C6-818D-51773FF723FD@me.com>

On Apr 23, 2009, at 3:02 PM, Dirk Eddelbuettel wrote:

>
> On 23 April 2009 at 15:32, Gabor Grothendieck wrote:
> | On Thu, Apr 23, 2009 at 3:08 PM, Dirk Eddelbuettel  
> <edd at debian.org> wrote:
> | >
> | > (Subject: renamed as thread hijacked from the ParallelR thread    
> --Dirk)
> | >
> | > On 23 April 2009 at 14:44, Gabor Grothendieck wrote:
> | > | Aside from R there are the add-on packages.
> | > |
> | > | A frequency table showing the licenses of the CRAN packages  
> indicates
> | > | that the all or almost all packages have some sort of free  
> software license
> | > | with GPL licenses being most common. (A few packages have  
> restrictions
> | > | to noncommercial use and that may conflict with GPL, not  
> sure.)   That is
> | > | not to say that there are no other types of packages but any  
> such packages
> | > | are not on CRAN.
> | >
> | > I fear that is not quite the case.  There are quite a few  
> packages like that.
> |
> | Not the case?  My post included a list of all License fields from  
> the
> | DESCRIPTION file of every CRAN package so the list is definitive.
>
> Correct me if I am wrong in the paragraph you kindly left standing  
> above, you
> seem to suggest that
>
> 	"all or almost all packages have some sort of free software license"
>
> and that while non-free licenses may exist,
>
> 	"any such packages are not on CRAN".
>
> I believe this statement to be false.
>
> There are packages with restrictive licenese on CRAN.  They were  
> contained in
> the list of licenses you assembled, and my point is that it is  
> overly hard to
> identify them (if one were to tty to avoid using these packages).
>
> As a non-exhautive list with possible misclassifications, cran2deb  
> currently
> has these packasges as 'maybe not free' and does not build them:
>
>      
> BARD,BayesDA,CoCo,ConvCalendar,FAiR,PTAk,RScaLAPACK,Rcsdp,SDDA,SGP,
>      
> alphahull 
> ,ash,asypow,caMassClass,gpclib,mapproj,matlab,mclust,mclust02,
>      
> mlbench,optmatch,rankreg,realized,rngwell19937,rtiff,rwt,scagnostics,
>     sgeostat,spatialkernel,tlnise,xgobi
>
> We are missing some recently added packages, and we may yet flag  
> several from
> the list above as free. Some may be listed because of non-free  
> Depends:
>
> But to take a concrete example, 'realized' is not something I am  
> supposed to
> install at work.  Yet install.packages() currently has not way  
> knowing that.
>
> Are we approximately on the same page ?
>
> Dirk

There is a list of acceptable entries that are defined as part of the  
specs in R-exts (see page 4). Perhaps this needs to be "tightened" a  
bit, at least in so far as packages passing R CMD check for the  
purpose of inclusion on CRAN. That would include perhaps altering the  
ability to use the 'file LICENSE' option, which at present leaves the  
door wide open for non-standard approaches. It may also have to check  
for DEPENDS and whether they too are on CRAN and passed the  
appropriate license checks.

Packages that fail this check should not be included on CRAN and the  
package author would then be obligated to find other distribution  
resources or contact the CRAN maintainers to advocate that their  
licensing schema should be acceptable.

Then the end user can at least have some comfort in knowing that  
anything they get from CRAN comes under a compatible license for  
general use without restriction. They would have to intentionally use  
other sources for packages that fail the CRAN requirements.

If other distribution venues, such as Debian/Ubuntu/Fedora elect to  
tighten those restrictions even further when making .debs or RPMs  
available, then that is a decision that they get to make and end users  
will need to be aware of those as well. Albeit I don't envision the  
aforementioned Linux distros including packages that should be a  
problem for most end users relative to usage restrictions given their  
own license review processes.

HTH,

Marc Schwartz



[Rd] License status of CRAN packages
Marc Schwartz