With header this time
On Thu, 10 Sep 2009 16:08 -0700, "Nicholas Lewin-Koh"
<nikko at hailmail.net> wrote:> 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