From Kurt.Hornik at wu.ac.at  Fri Sep 11 16:57:42 2009
From: Kurt.Hornik at wu.ac.at (Kurt Hornik)
Date: Fri, 11 Sep 2009 16:57:42 +0200
Subject: [Rd] Non-GPL packages for R
In-Reply-To: <4AA98451.3040003@prodsyse.com>
References: <4AA93C58.1050406@uottawa.ca>
	<971536df0909101126g3b57647fv4c4d74f0eb47b0e9@mail.gmail.com>
	<19113.31229.97906.452635@ron.nulle.part>
	<4AA98451.3040003@prodsyse.com>
Message-ID: <19114.25958.220767.785610@fangorn.hornik.net>

>>>>> spencerg  writes:

>       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.

You are suggesting we create and maintain an *empty* repository?

All packages on CRAN should be freely redistributable by/within CRAN.
If you find a package which is not, pls let us know---such packages must
be removed from CRAN.

I think you are mistaking the situation about "non-free" packages: these
typically restrict usage for commercial purposes.

-k


>            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
>> 
>> 


> -- 
> Spencer Graves, PE, PhD
> President and Chief Operating Officer
> Structure Inspection and Monitoring, Inc.
> 751 Emerson Ct.
> San Jos?, CA 95126
> ph:  408-655-4567

> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel



[Rd] Non-GPL packages for R
Kurt Hornik