From nikko at hailmail.net  Fri Sep 11 01:08:55 2009
From: nikko at hailmail.net (Nicholas Lewin-Koh)
Date: Thu, 10 Sep 2009 16:08:55 -0700
Subject: [Rd] (no subject)
Message-ID: <1252624135.3000.1334248455@webmail.messagingengine.com>

Hi,
I would also be in favor of a stronger stance on licenses. In
industry, where we can really get in big trouble for violating a
license,
we often maintain internal repositories, or need to be careful about
filtering
what is used from CRAN. I think that is should really be a requirement
the package
authors commit to stating what the restrictions are on their packages. 

Nicholas


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



[Rd] (no subject)
Nicholas Lewin-Koh