[Rd] License status of CRAN packages

[Gabor Grothendieck]

In some other software systems there are separate repositories for
free and non-free add-ons.  That way its clear what you are downloading
yet there are good outlets for both types of software.  There has been some
discussion of future features that CRAN might have that might make
this even easier to do.   My opinion is that R will suffer if it were not
to support both types of software but at the same time its reasonable
to make it clear which type you are getting before you download it.

On Thu, Apr 23, 2009 at 4:35 PM, Marc Schwartz <marc_schwartz at me.com> wrote:
> 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
>
>