[Rd] Non-GPL packages for R

[Duncan Murdoch]

On 10/09/2009 6:57 PM, spencerg wrote:
>       I will offer my opinion as a user and contributer to R packages 
> via R-Forge and CRAN: 
> 
> 
>            1.  How difficult would it be to split CRAN into two parts, 
> depending on whether the package carried an acceptable license allowing 
> free distribution?  The second might carry a name like RANC (R Archive 
> Network - Commercial), and the first would retain the CRAN name. 

To this I would say, try it.  Don't ask volunteers to do some work that 
suits you; do it yourself.

Duncan Murdoch

> 
> 
>            2.  R-Forge allows public access to the source code, at least 
> for some packages.  Moreover, users applying for R-Forge support must 
> specify the license they plan to use.  Support may be denied for a 
> project that does not use one of the standard public distribution 
> licenses like GPL. 
> 
> 
>       Spencer
> 
> 
> Dirk Eddelbuettel wrote:
>> On 10 September 2009 at 14:26, Gabor Grothendieck wrote:
>> | The SystemRequirements: field of the DESCRIPTION file normally
>> | lists external dependencies whether free or non-free.
>>
>> Moreover, the (aptly named) field 'License:' in DESCRIPTION is now much more
>> parseable and contains pertinent information. A number of more 'challenging'
>> packages basically pass the buck on with an entry
>>
>> 	    License: file LICENSE
>>
>> which refers to a file in the sources one needs to read to decide.
>>
>> This is e.g. at the basis of Charles' and my decision about what we think we
>> cannot build via cran2deb [1]: non-free, non-distributable, non-commercial or
>> otherwise nasty licenses.  There are a couple of packages we exclude for this
>> (or related reasons), and we have been meaning to summarise them with a
>> simple html summary from the database table we use for cran2deb, but have not
>> yet gotten around to it.
>>
>> Just like John and Ravi, I would actually be in favour of somewhat stricter
>> enforcements.  If someone decides not to take part in the gift economy that
>> brought him or her R (and many other things, including at least 1880+ CRAN
>> packages with sane licenses) then we may as well decide not to waste our time
>> and resources on his project either and simply exclude it.  
>>
>> So consider this as a qualified thumbs-up for John and Ravi's suggestion of a
>> clearer line in the sand.
>>
>> Dirk
>>
>> [1] cran2deb is at http://debian.cran.r-project.org and provides 1800+ Debian
>> 'testing' binaries for amd64 and i386 that are continuously updated as new
>> packages appear on CRAN. With that 'apt-get install r-cran-foo' becomes a
>> reality for almost every value of foo out of the set of CRAN packages.
>>
>>
>> | 
>> | On Thu, Sep 10, 2009 at 1:50 PM, Prof. John C Nash <nashjc at uottawa.ca> wrote:
>> | > Subject: Non-GPL packages for R
>> | >
>> | > Packages that are not licensed in a way that permits re-distribution on
>> | > CRAN are frequently a source of comment and concern on R-help and other
>> | > lists. A good example of this problem is the Rdonlp2 package that has caused
>> | > a lot of annoyance for a number of optimization users in R. They are also an
>> | > issue for efforts like Dirk Eddelbuettel's cran2deb.
>> | >
>> | > There are, however, a number of circumstances where non-GPL equivalent
>> | > packages may be important to users. This can imply that users need to
>> | > both install an R package and one or more dependencies that must be
>> | > separately obtained and licensed. One such situation is where a new
>> | > program is still under development and the license is not clear, as in
>> | > the recent work we pursued with respect to Mike Powell's BOBYQA. We
>> | > wanted to verify if this were useful before we considered distribution,
>> | > and Powell had been offering copies of his code on request. Thus we
>> | > could experiment, but not redistribute. Recently Powell's approval to
>> | > redistribute has been obtained.
>> | >
>> | > We believe that it is important that non-redistributable codes be
>> | > excluded from CRAN, but that they could be available on a repository
>> | > such as r-forge. However, we would like to see a clearer indication of
>> | > the license status on r-forge. One possibility is an inclusion of a
>> | > statement and/or icon indicating such status e.g., green for GPL or
>> | > equivalent, amber for uncertain, red for restricted. Another may be a
>> | > division of directories, so that GPL-equivalent packages are kept
>> | > separate from uncertain or restricted licensed ones.
>> | >
>> | > We welcome comments and suggestions on both the concept and the
>> | > technicalities.
>> | >
>> | > John Nash & Ravi Varadhan
>> | >
>> | > ______________________________________________
>> | > R-devel at r-project.org mailing list
>> | > https://stat.ethz.ch/mailman/listinfo/r-devel
>> | >
>> | 
>> | ______________________________________________
>> | R-devel at r-project.org mailing list
>> | https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>   
> 
>