Non-GPL packages for R

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Non-GPL packages for R

Prof J C Nash (U30A)
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Non-GPL packages for R

Gabor Grothendieck
The SystemRequirements: field of the DESCRIPTION file normally
lists external dependencies whether free or non-free.

On Thu, Sep 10, 2009 at 1:50 PM, Prof. John C Nash <[hidden email]> 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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Non-GPL packages for R

Dirk Eddelbuettel

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 <[hidden email]> 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
| >
| > ______________________________________________
| > [hidden email] mailing list
| > https://stat.ethz.ch/mailman/listinfo/r-devel
| >
|
| ______________________________________________
| [hidden email] mailing list
| https://stat.ethz.ch/mailman/listinfo/r-devel

--
Three out of two people have difficulties with fractions.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Non-GPL packages for R

Spencer Graves-3
      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.


           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 <[hidden email]> 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
> | >
> | > ______________________________________________
> | > [hidden email] mailing list
> | > https://stat.ethz.ch/mailman/listinfo/r-devel
> | >
> |
> | ______________________________________________
> | [hidden email] 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: 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 <[hidden email]> 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
>> | >
>> | > ______________________________________________
>> | > [hidden email] mailing list
>> | > https://stat.ethz.ch/mailman/listinfo/r-devel
>> | >
>> |
>> | ______________________________________________
>> | [hidden email] mailing list
>> | https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>>  
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Non-GPL packages for R

Romain Francois
In reply to this post by Dirk Eddelbuettel
+1

Commit to freedom if you want the free services of CRAN, etc ...

On 09/11/2009 12:13 AM, 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<[hidden email]>  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

--
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/y8y0 : search the graph gallery from R
|- http://tr.im/y8wY : new R package : ant
`- http://tr.im/xMdt : update on the ant package

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Non-GPL packages for R

Prof J C Nash (U30A)
In reply to this post by Spencer Graves-3
The responses to my posting yesterday seem to indicate more consensus
than I expected:
1) CRAN should be restricted to GPL-equivalent licensed packages
2) r-forge could be left "buyer beware" using DESCRIPTION information
3) We may want a specific repository for restricted packages (RANC?)

How to proceed? A short search on Rseek did not turn up a chain of
command for CRAN.

I'm prepared to help out with documentation etc. to move changes
forward. They are not, in my opinion, likely to cause a lot of trouble
for most users, and should simplify things over time.

JN

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Non-GPL packages for R

Peter Dalgaard
Prof. John C Nash wrote:
> The responses to my posting yesterday seem to indicate more consensus
> than I expected:
> 1) CRAN should be restricted to GPL-equivalent licensed packages

GPL-_compatible_ would be the word. However, this is not what has been
done in the past. There are packages with "non-commercial use" licences,
and the survival package was among them for quite a while. As far as I
know, the CRAN policy has been to ensure only that redistribution is
legal and that whatever license is used is visible to the user. People
who have responded on the list do not necessarily speak for CRAN. In the
final analysis, the maintainers must decide what is maintainable.

The problem with Rdonlp2 seems to have been that the interface packages
claimed to be LGPL2 without the main copyright holder's consent (and it
seems that he cannot grant consent for reasons of TU-Darmstadt
policies). It is hard to safeguard agaist that sort of thing. CRAN
maintainers must assume that legalities have been cleared and accept the
license in good faith.

(Even within the Free Software world there are current issues with,
e.g., incompatibilities between GPL v.2 and v.3, and also with the
Eclipse license. Don't get me started...)

> 2) r-forge could be left "buyer beware" using DESCRIPTION information
> 3) We may want a specific repository for restricted packages (RANC?)
>
> How to proceed? A short search on Rseek did not turn up a chain of
> command for CRAN.
>
> I'm prepared to help out with documentation etc. to move changes
> forward. They are not, in my opinion, likely to cause a lot of trouble
> for most users, and should simplify things over time.
>
> JN
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel


--
   O__  ---- Peter Dalgaard             Øster Farimagsgade 5, Entr.B
  c/ /'_ --- Dept. of Biostatistics     PO Box 2099, 1014 Cph. K
 (*) \(*) -- University of Copenhagen   Denmark      Ph:  (+45) 35327918
~~~~~~~~~~ - ([hidden email])              FAX: (+45) 35327907

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Non-GPL packages for R

Robert Gentleman
Hi,

Peter Dalgaard wrote:
> Prof. John C Nash wrote:
>> The responses to my posting yesterday seem to indicate more consensus
>> than I expected:

  Umm, I had thought that it was well established that responders need
not represent the population being surveyed.  I doubt that there is
consensus at the level you are suggesting (certainly I don't agree) and
as Peter indicates below the issue is: what is maintainable with the
resources we have, not what is the best solution given unlimited resources.

   Personally, I would like to see something that was a bit easier to
deal with programmatically that indicated when a package was GPL (or
Open source actually) compatible and when it is not.  This could then be
used to write a decent function to identify suspect packages so that
users would know when they should be concerned.

   It is also the case that things are not so simple, as dependencies
can make a package unusable even if it is itself GPL-compatible.  This
also makes the notion of some simple split into free and non-free (or
what ever split you want) less trivial than is being suggested.

   Robert


>> 1) CRAN should be restricted to GPL-equivalent licensed packages
>
> GPL-_compatible_ would be the word. However, this is not what has been
> done in the past. There are packages with "non-commercial use" licences,
> and the survival package was among them for quite a while. As far as I
> know, the CRAN policy has been to ensure only that redistribution is
> legal and that whatever license is used is visible to the user. People
> who have responded on the list do not necessarily speak for CRAN. In the
> final analysis, the maintainers must decide what is maintainable.
>
> The problem with Rdonlp2 seems to have been that the interface packages
> claimed to be LGPL2 without the main copyright holder's consent (and it
> seems that he cannot grant consent for reasons of TU-Darmstadt
> policies). It is hard to safeguard agaist that sort of thing. CRAN
> maintainers must assume that legalities have been cleared and accept the
> license in good faith.
>
> (Even within the Free Software world there are current issues with,
> e.g., incompatibilities between GPL v.2 and v.3, and also with the
> Eclipse license. Don't get me started...)
>
>> 2) r-forge could be left "buyer beware" using DESCRIPTION information
>> 3) We may want a specific repository for restricted packages (RANC?)
>>
>> How to proceed? A short search on Rseek did not turn up a chain of
>> command for CRAN.
>>
>> I'm prepared to help out with documentation etc. to move changes
>> forward. They are not, in my opinion, likely to cause a lot of trouble
>> for most users, and should simplify things over time.
>>
>> JN
>>
>> ______________________________________________
>> [hidden email] mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Non-GPL packages for R

Kurt Hornik-5
In reply to this post by Spencer Graves-3
>>>>> 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 <[hidden email]> 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
>> | >
>> | > ______________________________________________
>> | > [hidden email] mailing list
>> | > https://stat.ethz.ch/mailman/listinfo/r-devel
>> | >
>> |
>> | ______________________________________________
>> | [hidden email] 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

> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Non-GPL packages for R

Kurt Hornik-5
In reply to this post by Prof J C Nash (U30A)
>>>>> Prof John C Nash writes:

> The responses to my posting yesterday seem to indicate more consensus
> than I expected:
> 1) CRAN should be restricted to GPL-equivalent licensed packages
> 2) r-forge could be left "buyer beware" using DESCRIPTION information
> 3) We may want a specific repository for restricted packages (RANC?)

> How to proceed? A short search on Rseek did not turn up a chain of
> command for CRAN.

I thought I had already explained the last time the GPL-only suggestion
came up that this will not happen for CRAN.

But again: we have invested considerable time into getting the license
specs standardized, and writing code to compute on these.  Time
permitting, R 2.10.0 will feature code that allows specifying license
filters which can be customized according to individuals' needs.  But I
see no point in physically representing one particular license profile.

Btw, there are less non-free packages on CRAN than packages which claim
to be free but have non-free installation dependencies: some would argue
that the latter is impossible from a license perspective.  I feel little
desire to start arguing about this, as being able to control package
installation by license filters will resolve matters anyway.

-k


> I'm prepared to help out with documentation etc. to move changes
> forward. They are not, in my opinion, likely to cause a lot of trouble
> for most users, and should simplify things over time.

> JN

> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Non-GPL packages for R

Dirk Eddelbuettel
In reply to this post by Peter Dalgaard

On 11 September 2009 at 16:37, Peter Dalgaard wrote:
| who have responded on the list do not necessarily speak for CRAN. In the
| final analysis, the maintainers must decide what is maintainable.

Fully agreed. As 'maintainers' of cran2deb, Charles and I decided to 'shoot
first, ask questions later' as we clearly wanted to avoid creating any sort
of trouble for our generous CRAN hosts (currently just the Vienna master) are
effectively re-distributing our compilations (of its own content).  

So we pro-actively chose to excludes some packages.  To put some meat on this
particular bone, the current set packages blacklistes for 'nonfree-ness' is:

  sqlite> select package, explanation from blacklist_packages where nonfree;
  package               explanation
  --------------------  ----------------------------------------
  mclust                non-commercial license
  mclust02              non-commercial license
  ConvCalendar          no modification or distribution rights
  SDDA                  non-commercial CSIRO license
  conf.design           non-commercial license
  isa2                  non-commercial creative commons license
  optmatch              non-commercial license
  rankreg               non-commercial license
  realized              non-commercial license
  rngwell19937          non-commercial license
  tnet                  non-commercial creative commons license
  spatialkernel         contains non-commercial gpc code
  Bhat                  non-commercial license
  PTAk                  non-commercial license
  PredictiveRegression  non-commercial license
  RLadyBug              contains some code under non-commercial
  mapproj               non-commercial license
  mathgraph             non-commercial license
  sqlite>

| (Even within the Free Software world there are current issues with,
| e.g., incompatibilities between GPL v.2 and v.3, and also with the
| Eclipse license. Don't get me started...)

Yes. There is a potential problem with gcc 4.4 compilation of GPL-2 code. If
that comes to a boil we all (as in: GPL 2 users) are in a spot of bother.

On 11 September 2009 at 07:48, Robert Gentleman wrote:
|    It is also the case that things are not so simple, as dependencies
| can make a package unusable even if it is itself GPL-compatible.  This

Yes, in the case of cran2deb / CRAN there are just three blacklists because
of dependencies on nonfree CRAN content, most often it is dependencies on
other stuff incl BioC which we do not include (for mostly technical /
historical reasons; contact Charles or me offline if you'd like to work on
changing this)

  sqlite> select package,explanation from blacklist_packages where unsatisfied_dependency;
  package               explanation
  --------------------  ----------------------------------------
  ROracle               requires Oracle to build and run
  Rlsf                  requires LSF cluster/grid system librari
  Rsge                  requires SGE cluster/grid system librari
  CarbonEL              requires OS X system
  VhayuR                requires Vhayu database system
  gputools              requires Nvidia CUDA compiler and GPU-en
  klaR                  requires SVMlight which is non-free
  wgaim                 requires asreml-R
  svGUI                 requires Komodo from OpenKomodo.org whic
  RScaLAPACK            requires MPICH2 and Blacs and ScaLAPACK
  caMassClass           requires PROcess from BioConductor
  Rcplex                requires CPLEX libraries
  ADaCGH                BioC depends: tilingArray
  DAAGbio               BioC depends: limma
  GFMaps                BioC depends: affy
  GOSim                 BioC depends: GO.db
  Metabonomic           BioC depends: PROcess
  classGraph            BioC depends: Rgraphviz
  gcExplorer            BioC depends: Rgraphviz
  logilasso             BioC depends: Rgraphviz
  pcalg                 BioC depends: Rgraphviz
  celsius               BioC depends: BioBase
  multtest              BioC depends: BioBase
  hopach                BioC depends: BioBase
  GExMap                BioC depends: multtest,BioBase
  LMGene                BioC depends: multtest,BioBase
  PCS                   BioC depends: multtest,BioBase
  SubpathwayMiner       BioC depends: KEGG.db
  gene2pathway          BioC depends: KEGG.db
  PhViD                 BioC depends: LBE
  SNPMaP                BioC depends: affxparser
  qdg                   BioC depends: pcalg,Rgraphviz
  lsa                   Ohat depends: Rstem
  mpm                   BioC depends: geneplotter
  sisus                 BioC depends: annotate
  metaMA                BioC depends: limma
  clustTool             non-free depends: mclust02
  clustvarsel           non-free depends: mclust02
  SpectralGEM           non-free depends: optmatch
  bayesCGH              BioC depends: snapCGH
  crosshybDetector      missing depends: marray
  FEST                  needs MERLIN <http://www.sph.umich.edu/c
  aroma.affymetrix      BioC depends: aroma.light
  aroma.core            BioC depends: aroma.light
  aroma.apd             BioC depends: aroma.light
  sqlite>


| also makes the notion of some simple split into free and non-free (or
| what ever split you want) less trivial than is being suggested.

That sounds like the Ostrich defense :) Nobody claimed it was easy or
non-controversial, but it seems some of us feel that it should be discussed
as the status quo may be something we can improve upon.  

E.g. I think that 'License: file LICENSE' is not good enough.  Some sort of
marker at the DESCRIPTIOn level would help.  How many levels we put into an
appropriate factor variable is open for discussion. But for argument's sake:
why don't we start with a binary toggle of whether or not one of the licenses
in http://www.r-project.org/Licenses/ aka share/licenses/ is met?

CRAN has been a huge success (and I am sure the success puts a strain on its
maintainers).  Given that it has become the 800 pound gorilla, may not use
some of that weight to nudge folks to a set of common licenses?

Dirk

--
Three out of two people have difficulties with fractions.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Non-GPL packages for R

Gabor Grothendieck
One complication is that its possible that a package can use a non-free
component but can also be used without it.  The fame package could
be used with fame or without fame for a long time but more recently the
non-fame portion was factored out into the tis package.  The VhayuR
package is similar in that it can be used without Vhayu.  In that case it
can use flat files instead of the Vhayu database.

On Fri, Sep 11, 2009 at 11:44 AM, Dirk Eddelbuettel <[hidden email]> wrote:

>
> On 11 September 2009 at 16:37, Peter Dalgaard wrote:
> | who have responded on the list do not necessarily speak for CRAN. In the
> | final analysis, the maintainers must decide what is maintainable.
>
> Fully agreed. As 'maintainers' of cran2deb, Charles and I decided to 'shoot
> first, ask questions later' as we clearly wanted to avoid creating any sort
> of trouble for our generous CRAN hosts (currently just the Vienna master) are
> effectively re-distributing our compilations (of its own content).
>
> So we pro-actively chose to excludes some packages.  To put some meat on this
> particular bone, the current set packages blacklistes for 'nonfree-ness' is:
>
>  sqlite> select package, explanation from blacklist_packages where nonfree;
>  package               explanation
>  --------------------  ----------------------------------------
>  mclust                non-commercial license
>  mclust02              non-commercial license
>  ConvCalendar          no modification or distribution rights
>  SDDA                  non-commercial CSIRO license
>  conf.design           non-commercial license
>  isa2                  non-commercial creative commons license
>  optmatch              non-commercial license
>  rankreg               non-commercial license
>  realized              non-commercial license
>  rngwell19937          non-commercial license
>  tnet                  non-commercial creative commons license
>  spatialkernel         contains non-commercial gpc code
>  Bhat                  non-commercial license
>  PTAk                  non-commercial license
>  PredictiveRegression  non-commercial license
>  RLadyBug              contains some code under non-commercial
>  mapproj               non-commercial license
>  mathgraph             non-commercial license
>  sqlite>
>
> | (Even within the Free Software world there are current issues with,
> | e.g., incompatibilities between GPL v.2 and v.3, and also with the
> | Eclipse license. Don't get me started...)
>
> Yes. There is a potential problem with gcc 4.4 compilation of GPL-2 code. If
> that comes to a boil we all (as in: GPL 2 users) are in a spot of bother.
>
> On 11 September 2009 at 07:48, Robert Gentleman wrote:
> |    It is also the case that things are not so simple, as dependencies
> | can make a package unusable even if it is itself GPL-compatible.  This
>
> Yes, in the case of cran2deb / CRAN there are just three blacklists because
> of dependencies on nonfree CRAN content, most often it is dependencies on
> other stuff incl BioC which we do not include (for mostly technical /
> historical reasons; contact Charles or me offline if you'd like to work on
> changing this)
>
>  sqlite> select package,explanation from blacklist_packages where unsatisfied_dependency;
>  package               explanation
>  --------------------  ----------------------------------------
>  ROracle               requires Oracle to build and run
>  Rlsf                  requires LSF cluster/grid system librari
>  Rsge                  requires SGE cluster/grid system librari
>  CarbonEL              requires OS X system
>  VhayuR                requires Vhayu database system
>  gputools              requires Nvidia CUDA compiler and GPU-en
>  klaR                  requires SVMlight which is non-free
>  wgaim                 requires asreml-R
>  svGUI                 requires Komodo from OpenKomodo.org whic
>  RScaLAPACK            requires MPICH2 and Blacs and ScaLAPACK
>  caMassClass           requires PROcess from BioConductor
>  Rcplex                requires CPLEX libraries
>  ADaCGH                BioC depends: tilingArray
>  DAAGbio               BioC depends: limma
>  GFMaps                BioC depends: affy
>  GOSim                 BioC depends: GO.db
>  Metabonomic           BioC depends: PROcess
>  classGraph            BioC depends: Rgraphviz
>  gcExplorer            BioC depends: Rgraphviz
>  logilasso             BioC depends: Rgraphviz
>  pcalg                 BioC depends: Rgraphviz
>  celsius               BioC depends: BioBase
>  multtest              BioC depends: BioBase
>  hopach                BioC depends: BioBase
>  GExMap                BioC depends: multtest,BioBase
>  LMGene                BioC depends: multtest,BioBase
>  PCS                   BioC depends: multtest,BioBase
>  SubpathwayMiner       BioC depends: KEGG.db
>  gene2pathway          BioC depends: KEGG.db
>  PhViD                 BioC depends: LBE
>  SNPMaP                BioC depends: affxparser
>  qdg                   BioC depends: pcalg,Rgraphviz
>  lsa                   Ohat depends: Rstem
>  mpm                   BioC depends: geneplotter
>  sisus                 BioC depends: annotate
>  metaMA                BioC depends: limma
>  clustTool             non-free depends: mclust02
>  clustvarsel           non-free depends: mclust02
>  SpectralGEM           non-free depends: optmatch
>  bayesCGH              BioC depends: snapCGH
>  crosshybDetector      missing depends: marray
>  FEST                  needs MERLIN <http://www.sph.umich.edu/c
>  aroma.affymetrix      BioC depends: aroma.light
>  aroma.core            BioC depends: aroma.light
>  aroma.apd             BioC depends: aroma.light
>  sqlite>
>
>
> | also makes the notion of some simple split into free and non-free (or
> | what ever split you want) less trivial than is being suggested.
>
> That sounds like the Ostrich defense :) Nobody claimed it was easy or
> non-controversial, but it seems some of us feel that it should be discussed
> as the status quo may be something we can improve upon.
>
> E.g. I think that 'License: file LICENSE' is not good enough.  Some sort of
> marker at the DESCRIPTIOn level would help.  How many levels we put into an
> appropriate factor variable is open for discussion. But for argument's sake:
> why don't we start with a binary toggle of whether or not one of the licenses
> in http://www.r-project.org/Licenses/ aka share/licenses/ is met?
>
> CRAN has been a huge success (and I am sure the success puts a strain on its
> maintainers).  Given that it has become the 800 pound gorilla, may not use
> some of that weight to nudge folks to a set of common licenses?
>
> Dirk
>
> --
> Three out of two people have difficulties with fractions.
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Non-GPL packages for R

Michael Dewey
In reply to this post by Romain Francois
At 08:07 11/09/2009, Romain Francois wrote:

>+1
>
>Commit to freedom if you want the free services of CRAN, etc ...

It seems to me very reasonable for people to be asked to distribute
their software via some other route if they cannot join in the spirit
of the enterprise. So add my vote in with Romain's.

>On 09/11/2009 12:13 AM, 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<[hidden email]>  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
>
>--
>Romain Francois
>Professional R Enthusiast
>+33(0) 6 28 91 30 30
>http://romainfrancois.blog.free.fr
>|- http://tr.im/y8y0 : search the graph gallery from R
>|- http://tr.im/y8wY : new R package : ant
>`- http://tr.im/xMdt : update on the ant package
>
>______________________________________________
>[hidden email] mailing list
>https://stat.ethz.ch/mailman/listinfo/r-devel

Michael Dewey
http://www.aghmed.fsnet.co.uk

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Non-GPL packages for R

Dirk Eddelbuettel
In reply to this post by Gabor Grothendieck

On 11 September 2009 at 12:19, Gabor Grothendieck wrote:
| One complication is that its possible that a package can use a non-free
| component but can also be used without it.  The fame package could
| be used with fame or without fame for a long time but more recently the
| non-fame portion was factored out into the tis package.  The VhayuR
| package is similar in that it can be used without Vhayu.  In that case it
| can use flat files instead of the Vhayu database.

So in cases where a package used to not build with 'freely available' (and
preferably available as Debian packages) tools but does so now we welcome
hints so that we can update the blacklist.  All it does, really, is to save a
few cpu cycles when we have the expectation that 'R CMD INSTALL' is almost
surely going to fail.

Dirk

--
Three out of two people have difficulties with fractions.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Non-GPL packages for R

Dirk Eddelbuettel
In reply to this post by Kurt Hornik-5

On 11 September 2009 at 17:25, Kurt Hornik wrote:
| I thought I had already explained the last time the GPL-only suggestion
| came up that this will not happen for CRAN.
|
| But again: we have invested considerable time into getting the license
| specs standardized, and writing code to compute on these.  Time
| permitting, R 2.10.0 will feature code that allows specifying license
| filters which can be customized according to individuals' needs.  But I
| see no point in physically representing one particular license profile.
|
| Btw, there are less non-free packages on CRAN than packages which claim
| to be free but have non-free installation dependencies: some would argue
| that the latter is impossible from a license perspective.  I feel little
| desire to start arguing about this, as being able to control package
| installation by license filters will resolve matters anyway.

Indeed, that would possibly solve some our (as in cran2deb) worries too.  So
a nig Thanks! for working on this, and of course for providing CRAN in the
first place.

Dirk

--
Three out of two people have difficulties with fractions.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Non-GPL packages for R

Spencer Graves-3
Dirk Eddelbuettel wrote:

> On 11 September 2009 at 17:25, Kurt Hornik wrote:
> | I thought I had already explained the last time the GPL-only suggestion
> | came up that this will not happen for CRAN.
> |
> | But again: we have invested considerable time into getting the license
> | specs standardized, and writing code to compute on these.  Time
> | permitting, R 2.10.0 will feature code that allows specifying license
> | filters which can be customized according to individuals' needs.  But I
> | see no point in physically representing one particular license profile.
> |
> | Btw, there are less non-free packages on CRAN than packages which claim
> | to be free but have non-free installation dependencies: some would argue
> | that the latter is impossible from a license perspective.  I feel little
> | desire to start arguing about this, as being able to control package
> | installation by license filters will resolve matters anyway.
>
> Indeed, that would possibly solve some our (as in cran2deb) worries too.  So
> a nig Thanks! for working on this, and of course for providing CRAN in the
> first place.
>  
      I second that.  People all over the world are more quantitative
than they would otherwise be because the R project including CRAN (and
R-Forge) make it economically feasible for them to access and use high
quality software to better understand their world and communicate that
improved understanding  more effectively to others.  Knowledge is power,
and this increased knowledge gives more people more control over their
lives.  We are not laying brick but building a cathedral.


      Spencer

> Dirk
>
>  


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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Non-GPL packages for R

Prof J C Nash (U30A)
In reply to this post by Dirk Eddelbuettel
License filters will work for me. My offer stands to help on
documentation,or to act as a "stooge" to test tools in this area. Thanks
to those who responded. And for myself, "GPL compatible" was my intended
expression.

JN

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Non-GPL packages for R

Simon Urbanek
In reply to this post by Prof J C Nash (U30A)
John,

On Sep 11, 2009, at 9:07 , Prof. John C Nash wrote:

> The responses to my posting yesterday seem to indicate more  
> consensus than I expected:
> 1) CRAN should be restricted to GPL-equivalent licensed packages

I would definitely vote against that - I think this is not what the  
most people here agreed with (and the subject [non-GPL] and your  
wording [non-redistributable code] are two entirely different things).  
GPL is more restrictive than most open source licenses so with the  
above you'd throw out a lot of "real" open source packages (namely  
those with more permissive open source licenses). The point was open  
distribution as Peter pointed out so GPL-compatible licenses would be  
one possibility (although it also disallows some open source licenses).

Cheers,
Simon


> 2) r-forge could be left "buyer beware" using DESCRIPTION information
> 3) We may want a specific repository for restricted packages (RANC?)
>
> How to proceed? A short search on Rseek did not turn up a chain of  
> command for CRAN.
>
> I'm prepared to help out with documentation etc. to move changes  
> forward. They are not, in my opinion, likely to cause a lot of  
> trouble for most users, and should simplify things over time.
>
> JN
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Non-GPL packages for R

RKoenker
In reply to this post by Prof J C Nash (U30A)
Comrades,

When talk turns to the purity of the revolution, and purge of packages then
the guillotine can't be far behind.  We all remember Lenin berating the
"renegade Kautsky" for his "pragmatism," and we know where that led...

So let me put in a good word for pragmatism, and incidentally for saving one of my
own packages, SparseM, and perhaps eventually my neck.  Last week Kurt asked
me to look into a SparseM licensing quirk based on an inquiry from the Fedora
folks.  SparseM is GPL except for one routine cholesky.f written at Oakridge
Lab by E. Ng and B. Peyton.  Our version of the code was redistributed in the
package PCx which was copywrited by the U. of Chicago, who specified that
commercial users should contact someone at Argonne National Lab.  Since the
beginning we have retained this language in the License file of SparseM, even
though the code in question was not actually developed as a part of PCx.

I contacted one of the original PCx developers who responded as follows:

        The routine you mention was distributed with PCx but not part
        of it as you see from the legalese and not covered by the PCx
        copyright.  I tried to interest the authors of that code
        in legal issues in around 1997 but could not get them
        motivated (frankly I also can't get too interested).

To which I heartily concurred.  If someone who is worried about getting sued
would like to dig into this can of worms, then fine.  But life is too short
for the rest of us.  This is quite a murky business, we shouldn't create
incentives to make it murkier by covering up relevant language on licensing.
But surely we can also all agree that CRAN has been a fantastic success, and
adding new constraints on its operation is ill-advised.

Roger


url:    www.econ.uiuc.edu/~roger            Roger Koenker
email    rkoenker@uiuc.edu            Department of Economics
vox:     217-333-4558                University of Illinois
fax:       217-244-6678                Urbana, IL 61801

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

12