Re: [Rd] 'is.integer' (PR#13671)

[Petr Savicky]

On Wed, Apr 22, 2009 at 04:30:36PM -0400, Stavros Macrakis wrote:
[snip]
> Now consider 1e40, which has the property
> that floor(x)==x==ceiling(x), which you might think characterizes an
> integer;  but it also has the property that x+1 == x.  Similarly for
> 1/3 * 1e40.
[snip]

The number 1/3 * 1e40 is larger than 2^53 and every value of double type,
which is larger than 2^53, is an even integer. The number has at least 54
digits mathematically, but only the first 53 of them are stored, so the last
one is zero. Since rounding is done towards an even value, we get x+1 == x.

Double type is safe for integer values in the interval [-2^53, 2^53].
Inside this interval, basic arithmetic operations (+,-,*,/) on integers,
whose result is an integer mathematically, yield integer result also in
the machine.

Petr.

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

Re: [Rd] 'is.integer' (PR#13671)

[Martin Maechler]

> "TP" == Tony Plate 
> on Wed, 22 Apr 2009 14:37:05 -0600 writes:

TP> is.integer() is one of those functions with a name that can be 
confusing 
TP> -- it looks at the underlying storage type of its argument (e.g., 
TP> integer, floating point, character, etc.) not at the value stored in 
the 
TP> argument.

TP> So, the type of behavior you see is this:

>> is.integer(1)
TP> [1] FALSE
>> is.integer(as.integer(1))
TP> [1] TRUE
>> is.integer(as.integer(1) * 1.0)
TP> [1] FALSE
>> is.integer(as.integer(NA))
TP> [1] TRUE
>> 

TP> Careful reading of ?is.integer does tell you this, but I wouldn't 
accuse 
TP> that help page of making such information blatantly obvious to new 
users 
TP> of R.

TP> To test whether a value is an integer value, you can so something like 
this:

>> is.wholenumber <- function(x, tolerance = .Machine$double.eps^0.5) 
TP> return(abs(x - round(x)) < tolerance)
>> is.wholenumber(1)
TP> [1] TRUE
>> is.wholenumber(seq(1,5,by=0.5))
TP> [1]  TRUE FALSE  TRUE FALSE  TRUE FALSE  TRUE FALSE  TRUE
>> 

Thank you, Tony.

Somewhat contrary to our (R-core) beliefs that a reference
should be concise and correct, I have now added (an abridged
version of) the is.wholenumber() function to the *examples* 
on the  help(is.integer)  page and a note too.

Let's pretend we hope that this will stop such bug reports 
;-)

Martin Maechler


TP> The 'tolerance' part is to allow for minor deviations that might be due 
TP> to floating point representation issues, e.g., on my computer 1/49 * 49 
TP> does not result in a value that is exactly equal to 1:

>> 1/49 * 49 - 1
TP> [1] -1.110223e-16
>> is.wholenumber(1/49 * 49)
TP> [1] TRUE
>> is.wholenumber(1/49 * 49, tol=0)
TP> [1] FALSE
>> 

TP> -- Tony Plate

TP> hzambran.newsgro...@gmail.com wrote:
>> Full_Name: Mauricio
>> Version: 2.9.0 (2009-04-17)
>> OS:  i486-pc-linux-gnu
>> Submission from: (NULL) (193.205.203.3)
>> 
>> 
>> This is a very simple function that seems not to be working, according 
to the
>> definition given by '?is.integer'.
>> 
>> I checked in the Bug Tracking page at http://bugs.R-project.org/, but I 
didn't
>> find any related message.
>> 
>> The possible problem is:
>> 
>> 
>> 
>>> is.integer(1)
>>> 
>> [1] FALSE
>> 
>> and 1 is obviously an integer value.
>> 
>> 
>> I would really appreciate if you could clarify if this is really a bug 
or not.
>> 
>> Thanks in advance,
>> 
>> Mauricio
>> 
>> 
>>> version
>>> 
>> _   
>> platform   i486-pc-linux-gnu   
>> arch   i486
>> os linux-gnu   
>> system i486, linux-gnu 
>> status 
>> major  2   
>> minor  9.0 
>> year   2009
>> month  04  
>> day17  
>> svn rev48333   
>> language   R   
>> version.string R version 2.9.0 (2009-04-17)
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>> 
>> 

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

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

Re: [Rd] incorrect output and segfaults from sprintf with %*d (PR#13667)

[Wacek Kusnierczyk]

maech...@stat.math.ethz.ch wrote:
>
> vQ> sprintf has a documented limit on strings included in the output 
> using the
> vQ> format '%s'.  It appears that there is a limit on the length of 
> strings included
> vQ> with, e.g., the format '%d' beyond which surprising things happen 
> (output
> vQ> modified for conciseness):
>   

... and this limit is *not* documented.


> vQ> gregexpr('1', sprintf('%9000d', 1))
> vQ> # [1] 9000 9801
>
> vQ> gregexpr('1', sprintf('%9000d', 1))
> vQ> # [1]  9000  9801 10602
>
> vQ> gregexpr('1', sprintf('%9000d', 1))
> vQ> # [1]  9000  9801 10602 11403
>
> vQ> gregexpr('1', sprintf('%9000d', 1))
> vQ> # [1]  9000  9801 10602 11403 12204
>
> vQ> ...
>
> vQ> Note that not only more than one '1' is included in the output, but 
> also that
> vQ> the same functional expression (no side effects used beyond the 
> interface) gives
> vQ> different results on each execution.  Analogous behaviour can be 
> observed with
> vQ> '%nd' where n > 8200.
>
> vQ> The actual output above is consistent across separate sessions.
>
> vQ> With sufficiently large field width values, R segfaults:
>
> vQ> sprintf('%*d', 10^5, 1)
> vQ> # *** caught segfault ***
> vQ> # address 0xbfcfc000, cause 'memory not mapped'
> vQ> # Segmentation fault
>
>
> Thank you, Wacek.
> That's all ``interesting''  ... unfortunately, 
>
> my version of  'man 3 sprintf' contains
>
>   
>>> BUGS
>>>Because sprintf() and vsprintf() assume an arbitrarily
>>>long string, callers must be careful not to overflow the
>>>actual space; this is often impossible to assure. Note
>>>that the length of the strings produced is
>>>locale-dependent and difficult to predict.  Use
>>>snprintf() and vsnprintf() instead (or asprintf() and vasprintf).
>>>   
>
>   

yes, but this is c documentation, not r documentation.  it's applicable
to a degree, since ?sprintf does say that sprintf is "a wrapper for the
C function 'sprintf'".  however, in c you use a buffer and you usually
have control over it's capacity, while in r this is a hidden
implementational detail, which should not be visible to the user, or
should cause an attempt to overflow the buffer to fail more gracefully
than with a segfault.

in r, sprintf('%9000d', 1) will produce a confused output with a count
of 1's variable (!) across runs (while sprintf('%*d', 9000, 1) seems to
do fine):

gregexpr('1', sprintf('%*d', 9000, 1))
# [1] 9000

gregexpr('1', sprintf('%9000d', 1))
# [1] 9000 9801 ..., variable across executions

on one execution in a series i actually got this:

Warning message:
In gregexpr("1", sprintf("%9000d", 1)) :
  input string 1 is invalid in this locale

while the very next execution, still in the same session, gave

# [1]  9000  9801 10602

with sprintf('%*d', 1, 1) i got segfaults on some executions but
correct output on others, while sprintf('%1d', 1) is confused again.



> (note the "impossible" part above)   
>   

yes, but it does also say "must be careful", and it seems that someone
has not been careful enough.

> and we haven't used  snprintf() yet, probably because it
> requires the  C99 C standard, and AFAIK, we have only relatively
> recently started to more or less rely on C99 in the R sources.
>   

while snprintf would help avoid buffer overflow, it may not be a
solution to the issue of confused output.

>
> More precisely, I see that some windows-only code relies on
> snprintf() being available  whereas in at least on non-Windows
> section, I read   /* we cannot assume snprintf here */
>
> Now such platform dependency issues and corresponding configure
> settings I do typically leave to other R-corers with a much
> wider overview about platforms and their compilers and C libraries.
>   

it looks like src/main/sprintf.c is just buggy, and it's plausible that
the bug could be repaired in a platform-independent manner.


>
>
> BTW,  
> 1) sprintf("%n %g", 1,1)   also seg.faults
>   

as do

sprintf('%n%g', 1, 1)
sprintf('%n%')

etc., while

sprintf('%q%g', 1, 1)
sprintf('%q%')
  
work just fine.  strange, because per ?sprintf 'n' is not recognized as
a format specifier, so the output from the first two above should be as
from the last two above, respectively.  (and likewise in the %S case,
discussed and bug-reported earlier.)


> 2) Did you have a true use case where  the  8192  limit was an
>undesirable limit?
>   

how does it matter?  if you set a limit, be sure to consistently enforce
it and warn the user on attempts to exceed it.  or write clearly in the
docs that such attempts will cause the output to be silently truncated. 
examples such as

sprintf('%9000d', 1)

do not contribute to the reliability of r, and neither to the user's
confidence in it.

vQ

__
R-devel@r-project.org mailing list
h

Re: [Rd] 'is.integer' (PR#13671)

[Martin Maechler]

> "SM" == Stavros Macrakis 
> on Wed, 22 Apr 2009 16:30:36 -0400 writes:

SM> Dear R experts,
SM> You are being a bit harsh on this user. 

No! (see below)

SM> He simply doesn't understand
SM> the distinction between "object of type integer" and "integer-valued
SM> object", which is actually fairly subtle.

yes, probably for the vast majority of today's R users.

*However*, Mauricio submitted a *formal* bug report against R
and there are many caveats against doing that "light-heartedly".
Note that he also said

 >> I would really appreciate if you could clarify if this is
 >> really a bug or not. 

and that this is exactly one of situation where one should post
a question to R-help (or maybe R-devel) but *NOT* submit a
formal bug report.

Regards,
Martin


SM> On Wed, Apr 22, 2009 at 1:45 PM,   wrote:
>> This is a very simple function that seems not to be working, according 
to the
>> definition given by '?is.integer'.
SM> ...
>>> is.integer(1)
>> [1] FALSE
>> 
>> and 1 is obviously an integer value.

SM> The is.integer function is correctly documented to check whether
SM> objects are of *type* integer, thus:

SM> is.integer( 1L ) => TRUE

SM> In R, objects of type integer are only created with literals of the
SM> form 999L; as the output of some functions when the input is integral
SM> (e.g. sort, unique, rev, ...); as the output of some functions which
SM> return index values or differences of index values (which, grep, rle,
SM> ...); and the output of a few other functions in certain cases (seq).

SM> Most numbers in R are floating-point numbers (type double), and
SM> determining whether their value is integral is rather subtle.

SM> For example, consider the vector 1+1000^-(1:6).  In floating-point
SM> arithmetic, the first 5 values are distinguishable from the integer 1,
SM> but the 6th is not, though of course the *mathematical* number
SM> 1+1000^-6 is not integral.  Now consider 1e40, which has the property
SM> that floor(x)==x==ceiling(x), which you might think characterizes an
SM> integer;  but it also has the property that x+1 == x.  Similarly for
SM> 1/3 * 1e40.

SM> In other words, it is really a rather subtle question whether a
SM> floating-point number "represents" an integer

SM> -s

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

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

Re: [Rd] incorrect output and segfaults from sprintf with %*d (PR#13667)

[maechler]

> "vQ" == Wacek Kusnierczyk 
> on Thu, 23 Apr 2009 11:49:54 +0200 writes:

vQ> maech...@stat.math.ethz.ch wrote:
>> 
vQ> sprintf has a documented limit on strings included in the output using 
the
vQ> format '%s'.  It appears that there is a limit on the length of strings 
included
vQ> with, e.g., the format '%d' beyond which surprising things happen 
(output
vQ> modified for conciseness):
>> 

vQ> ... and this limit is *not* documented.

well, it is basically (+ a few bytes ?)
the same  8192  limit that *is* documented.

vQ> gregexpr('1', sprintf('%9000d', 1))
vQ> # [1] 9000 9801
>> 
vQ> gregexpr('1', sprintf('%9000d', 1))
vQ> # [1]  9000  9801 10602
>> 
vQ> gregexpr('1', sprintf('%9000d', 1))
vQ> # [1]  9000  9801 10602 11403
>> 
vQ> gregexpr('1', sprintf('%9000d', 1))
vQ> # [1]  9000  9801 10602 11403 12204
>> 
vQ> ...
>> 
vQ> Note that not only more than one '1' is included in the output, but 
also that
vQ> the same functional expression (no side effects used beyond the 
interface) gives
vQ> different results on each execution.  Analogous behaviour can be 
observed with
vQ> '%nd' where n > 8200.
>> 
vQ> The actual output above is consistent across separate sessions.
>> 
vQ> With sufficiently large field width values, R segfaults:
>> 
vQ> sprintf('%*d', 10^5, 1)
vQ> # *** caught segfault ***
vQ> # address 0xbfcfc000, cause 'memory not mapped'
vQ> # Segmentation fault
>> 
>> 
>> Thank you, Wacek.
>> That's all ``interesting''  ... unfortunately, 
>> 
>> my version of  'man 3 sprintf' contains
>> 
>> 
 BUGS
 Because sprintf() and vsprintf() assume an arbitrarily
 long string, callers must be careful not to overflow the
 actual space; this is often impossible to assure. Note
 that the length of the strings produced is
 locale-dependent and difficult to predict.  Use
 snprintf() and vsnprintf() instead (or asprintf() and vasprintf).

vQ> yes, but this is c documentation, not r documentation.

Of course! ...  and I  *do*  apply it to R's C code [sprintf.c]
and hence am even concurring with you .. 

vQ> it's applicable
vQ> to a degree, since ?sprintf does say that sprintf is "a wrapper for the
vQ> C function 'sprintf'".  however, in c you use a buffer and you usually
vQ> have control over it's capacity, while in r this is a hidden
vQ> implementational detail, which should not be visible to the user, or
vQ> should cause an attempt to overflow the buffer to fail more gracefully
vQ> than with a segfault.

vQ> in r, sprintf('%9000d', 1) will produce a confused output with a count
vQ> of 1's variable (!) across runs (while sprintf('%*d', 9000, 1) seems to
vQ> do fine):

vQ> gregexpr('1', sprintf('%*d', 9000, 1))
vQ> # [1] 9000

vQ> gregexpr('1', sprintf('%9000d', 1))
vQ> # [1] 9000 9801 ..., variable across executions

vQ> on one execution in a series i actually got this:

vQ> Warning message:
vQ> In gregexpr("1", sprintf("%9000d", 1)) :
vQ> input string 1 is invalid in this locale

vQ> while the very next execution, still in the same session, gave

vQ> # [1]  9000  9801 10602

vQ> with sprintf('%*d', 1, 1) i got segfaults on some executions but
vQ> correct output on others, while sprintf('%1d', 1) is confused again.



>> (note the "impossible" part above)   
>> 

vQ> yes, but it does also say "must be careful", and it seems that someone
vQ> has not been careful enough.

>> and we haven't used  snprintf() yet, probably because it
>> requires the  C99 C standard, and AFAIK, we have only relatively
>> recently started to more or less rely on C99 in the R sources.
>> 

vQ> while snprintf would help avoid buffer overflow, it may not be a
vQ> solution to the issue of confused output.

I think it would / will.  We would be able to give warnings and
errors, by checking the  snprintf()  return codes.


>> More precisely, I see that some windows-only code relies on
>> snprintf() being available  whereas in at least on non-Windows
>> section, I read   /* we cannot assume snprintf here */
>> 
>> Now such platform dependency issues and corresponding configure
>> settings I do typically leave to other R-corers with a much
>> wider overview about platforms and their compilers and C libraries.
>> 

vQ> it looks like src/main/sprintf.c is just buggy, and it's plausible that
vQ> the bug could be repaired in a platform-independent manner.

definitely.
In the mean time, I've actually found that what I first said on
the usability of snprintf() in R's code base was only partly correct.
There are other parts of R code where we use  snprintf() for all
platforms, hence we rely on its presence (and correct
implementation!

Re: [Rd] 'is.integer' (PR#13671)

[Petr Savicky]

On Thu, Apr 23, 2009 at 11:37:37AM +0200, Martin Maechler wrote:
[snip]
> TP> To test whether a value is an integer value, you can so something 
> like this:
> 
> >> is.wholenumber <- function(x, tolerance = .Machine$double.eps^0.5) 
> TP> return(abs(x - round(x)) < tolerance)
> >> is.wholenumber(1)
> TP> [1] TRUE
> >> is.wholenumber(seq(1,5,by=0.5))
> TP> [1]  TRUE FALSE  TRUE FALSE  TRUE FALSE  TRUE FALSE  TRUE
> >> 
> 
> Thank you, Tony.
> 
> Somewhat contrary to our (R-core) beliefs that a reference
> should be concise and correct, I have now added (an abridged
> version of) the is.wholenumber() function to the *examples* 
> on the  help(is.integer)  page and a note too.
> 
> Let's pretend we hope that this will stop such bug reports 
> ;-)

Besides the current bug report caused by misunderstanding of the
difference between a value and a data type, there are also discussions
concerning rounding errors of decimal numbers. These are, unfortunately,
quite frequent. If i can make a suggestion in order to (at least try to)
minimize also such discussions, may be it could help, if the contents of FAQ,
which is at the top of the FAQ page, contains the word accuracy. The path
to FAQ 7.31 discussing this topic goes through titles of sections
  R Miscellanea
and
  Why doesn't R think these numbers are equal? 

May be, if the name of "R Miscellanea" is more specific and contains the
word "accuracy" or if there is a section specifically for accuracy
issues, people would find the information in FAQ 7.31 more easily.

Petr.

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

Re: [Rd] 'is.integer' (PR#13671)

[hadley wickham]

> *However*, Mauricio submitted a *formal* bug report against R
> and there are many caveats against doing that "light-heartedly".
> Note that he also said

I know it's frustrating when people repeatedly ask this question (and
file bug reports related to it), but does it really take that long to
tell them to check out FAQ 7.31, and to close the bug report?

Hadley


-- 
http://had.co.nz/

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

Re: [Rd] incorrect output and segfaults from sprintf with %*d (PR#13667)

[Waclaw . Marcin . Kusnierczyk]

Martin Maechler wrote:
>> "vQ" == Wacek Kusnierczyk 
>> on Thu, 23 Apr 2009 11:49:54 +0200 writes:
>> 
>
> vQ> maech...@stat.math.ethz.ch wrote:
> >> 
> vQ> sprintf has a documented limit on strings included in the output 
> using the
> vQ> format '%s'.  It appears that there is a limit on the length of 
> strings included
> vQ> with, e.g., the format '%d' beyond which surprising things happen 
> (output
> vQ> modified for conciseness):
> >> 
>
> vQ> ... and this limit is *not* documented.
>
> well, it is basically (+ a few bytes ?)
> the same  8192  limit that *is* documented.
>   

martin, ?sprintf says:

" There is a limit of 8192 bytes on elements of 'fmt' and also on
 strings included by a '%s' conversion specification."

for me, it's clear that the *elements of fmt* cannot be longer than 8192
bytes, and that each single bit included in the output in place of a %s
cannot be longer than 8192.  nowhere does it say that strings included
in the output in place of a %d, for example, cannot be longer than
8192.  the fact that %s is particularized makes me infer that there is
something specific to %s that does not apply to %d, for example,
otherwise the help would have been formulated differently.  (though
given how r help pages are written, nothing seems unlikely.)

and in fact, the limit does not seem to apply in an obvious way in cases
such as sprintf('%*d', 1, 1), where the output is correct.  at the
very least, the documentation leaves the user ignorant as to what will
happen if the limit is exceeded.

> >> my version of  'man 3 sprintf' contains
> >> 
> >> 
>  BUGS
>  Because sprintf() and vsprintf() assume an arbitrarily
>  long string, callers must be careful not to overflow the
>  actual space; this is often impossible to assure. Note
>  that the length of the strings produced is
>  locale-dependent and difficult to predict.  Use
>  snprintf() and vsnprintf() instead (or asprintf() and vasprintf).
>
> vQ> yes, but this is c documentation, not r documentation.
>
> Of course! ...  and I  *do*  apply it to R's C code [sprintf.c]
> and hence am even concurring with you .. 
>
>
> vQ> while snprintf would help avoid buffer overflow, it may not be a
> vQ> solution to the issue of confused output.
>
> I think it would / will.  We would be able to give warnings and
> errors, by checking the  snprintf()  return codes.
>   

maybe, i can't judge without carefully examining the code for sprintf.c
(which i am rather unwilling to do, having had a look at a sample).

>
> >> More precisely, I see that some windows-only code relies on
> >> snprintf() being available  whereas in at least on non-Windows
> >> section, I read   /* we cannot assume snprintf here */
> >> 
> >> Now such platform dependency issues and corresponding configure
> >> settings I do typically leave to other R-corers with a much
> >> wider overview about platforms and their compilers and C libraries.
> >> 
>
> vQ> it looks like src/main/sprintf.c is just buggy, and it's plausible 
> that
> vQ> the bug could be repaired in a platform-independent manner.
>
> definitely.
> In the mean time, I've actually found that what I first said on
> the usability of snprintf() in R's code base was only partly correct.
> There are other parts of R code where we use  snprintf() for all
> platforms, hence we rely on its presence (and correct
> implementation!) and so we can and I think should use it in
> place of sprintf() in quite a few places inside R's sprintf.c
>
>   

would be interesting to see how this improves sprintf.

> >> BTW,  
> >> 1) sprintf("%n %g", 1,1)   also seg.faults
> >> 
>
> vQ> as do
>
> vQ> sprintf('%n%g', 1, 1)
> vQ> sprintf('%n%')
>
> vQ> etc., while
>
> vQ> sprintf('%q%g', 1, 1)
> vQ> sprintf('%q%')
>   
> vQ> work just fine.  strange, because per ?sprintf 'n' is not recognized 
> as
> vQ> a format specifier, so the output from the first two above should be 
> as
> vQ> from the last two above, respectively.  (and likewise in the %S case,
> vQ> discussed and bug-reported earlier.)
>
> I have now fixed these bugs at least;
>   

great, i'm going to torture the fix soon ;)

> the more subtle  "%d" ones are different, and
> as I said, I'm convinced that a nice & clean fix for those will
> start using snprintf().
>
> >> 2) Did you have a true use case where  the  8192  limit was an
> >> undesirable limit?
>
> vQ> how does it matter?  
>
> well, we could increase it, if it did matter.
>   {{ you *could* have been more polite here, no?
>   

i don't see how i could be more polite here, i had absolutely no
intention to be impolite and didn't think i were. 

i gave a serious answer by means of a serious question.  increasing an
arbitrary, poorly documented limit of obscure effect is hardly any
so

Re: [Rd] incorrect output and segfaults from sprintf with %*d (PR#13667)

[maechler]

> "vQ" == Wacek Kusnierczyk 
> on Thu, 23 Apr 2009 15:00:29 +0200 writes:

vQ> Martin Maechler wrote:
>>> "vQ" == Wacek Kusnierczyk 
>>> on Thu, 23 Apr 2009 11:49:54 +0200 writes:


[..]
[..]

>> >> BTW,  
>> >> 1) sprintf("%n %g", 1,1)   also seg.faults
>> >> 
>> 
vQ> as do
>> 
vQ> sprintf('%n%g', 1, 1)
vQ> sprintf('%n%')
>> 
vQ> etc., while
>> 
vQ> sprintf('%q%g', 1, 1)
vQ> sprintf('%q%')
>> 
vQ> work just fine.  strange, because per ?sprintf 'n' is not recognized as
vQ> a format specifier, so the output from the first two above should be as
vQ> from the last two above, respectively.  (and likewise in the %S case,
vQ> discussed and bug-reported earlier.)
>> 
>> I have now fixed these bugs at least;
>> 

vQ> great, i'm going to torture the fix soon ;)

there will be another one, still today, fixing the

  sprintf("%s", tryCatch(stop(), error=identity))

bug {which actually *is* a subtle, too}

>> the more subtle  "%d" ones are different, and
>> as I said, I'm convinced that a nice & clean fix for those will
>> start using snprintf().
>> 
>> >> 2) Did you have a true use case where  the  8192  limit was an
>> >> undesirable limit?
>> 
vQ> how does it matter?  
>> 
>> well, we could increase it, if it did matter.
>> {{ you *could* have been more polite here, no?
>> 

vQ> i don't see how i could be more polite here, i had absolutely no
vQ> intention to be impolite and didn't think i were. 

vQ> i gave a serious answer by means of a serious question.  increasing an
vQ> arbitrary, poorly documented limit of obscure effect is hardly any
vQ> solution.  suggesting that a bug is not a bug because some limit is not
vQ> likely to be exceeded in practice is not a particularly good idea.

But that's exactly what I did  NOT  suggest!!

It was a serious question, *related* to your bug report, but
*NOT* really on the bug report proper.
[It *was* under the "heading" of 'BTW' which I assumed you knew
 to interpret]
I was seriously asking, if BTW, the limit which is there was
possibly to be increased or not...


>> it *was* after all a serious question that I asked! }}
>> 
vQ> if you set a limit, be sure to consistently enforce
vQ> it and warn the user on attempts to exceed it.  or write clearly in the
vQ> docs that such attempts will cause the output to be silently truncated. 
>> 
>> Sure, I'm not at all disagreeing on that, and if you read this into my
>> posting, you misunderstand.
>> 

vQ> no, i didn't read that into your posting, i'm just referring to the
vQ> state of the 'art' in r.

[not so funny...  yet another "very polite" assumption.]

vQ> cheers,
vQ> vQ

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

[Rd] Custom browser prompt instead of Browse[1]>

[Romain Francois]

Hello,

Would it be possible to have a custom prompt when browser()'ing.

I have made a simple implementation of this (which is attached), the 
basic idea is that instead of the hardcoded sprintf( "Browser[%d]> ", 
browselevel), a call to the getBrowsePrompt is made, and obviously the 
function is:


> getBrowsePrompt
function (level = 1, env = .GlobalEnv) {
   sprintf("Browse[%d]> ", level)
}


> debug( rnorm )
> rnorm( 10 )
debugging in: rnorm(10)
debug: .Internal(rnorm(n, mean, sd))
Browse[1]>
exiting from: rnorm(10)
[1] -0.496598526 -0.006482431  1.491833990 -2.602605734 -0.275479145
[6] -1.143580117  0.146797854 -0.529420397  0.823817647 -0.256676050

but then it can be masked so that a more informative prompt is given, 
like this for example (showing the call stack)


> getBrowsePrompt
function( level = 1, env = .GlobalEnv){
calls <- sys.calls()
stack <- sapply( calls[-1], function(x) tryCatch(as.character(x[[1]]), 
error=function(e) "?") )

sprintf( "Browse[%d] %s > ", level, paste( stack, collapse = " -> ") )
}
> f()
debugging in: rnorm(10)
debug: .Internal(rnorm(n, mean, sd))
Browse[1] rnorm -> getBrowsePrompt >
exiting from: rnorm(10)
[1] -0.53854862 -1.42674850 -0.48391168 -0.23446819 -0.36863380  0.53803626
[7]  1.70176078  0.82984068  1.05101379 -0.03944557

Or this: printing the content of the environment we are browsing :

> getBrowsePrompt <- function( level = 1, env = .GlobalEnv ){
+   print( ls.str( envir = env) )
+   base:::getBrowsePrompt( level, env )
+ }
> f()
debugging in: rnorm(10)
debug: .Internal(rnorm(n, mean, sd))
mean :  num 0
n :  num 10
sd :  num 1
Browse[1]>
exiting from: rnorm(10)
[1]  1.1112007  0.4921306  0.1747196 -0.2518565 -0.9342039  0.5930085
[7] -0.5961234  0.1153541 -0.6189056  0.1670318

This probably should rely on an option instead of relying on masking 
functions. Also this opens a back door to the debugging system of R, but 
I am not sure this is entirely a bad thing. (see 
http://www.statistik.lmu.de/~eugster/soc09/#p5)


On the same note, what about having a function for the prompt, so that 
(for example) we could show the current working directory, the memory 
usage, ...



Romain

--
Romain Francois
Independent R Consultant
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr


Index: src/library/base/R/options.R
===
--- src/library/base/R/options.R	(revision 48377)
+++ src/library/base/R/options.R	(working copy)
@@ -18,3 +18,7 @@
 
 getOption <- function(x) options(x)[[1L]]
 
+getBrowsePrompt <- function( level = 1, env = .GlobalEnv){
+	sprintf( "Browse[%d]> ", level )
+}
+
Index: src/main/main.c
===
--- src/main/main.c	(revision 48377)
+++ src/main/main.c	(working copy)
@@ -116,20 +116,26 @@
 
 /* Read-Eval-Print loop with interactive input */
 static int prompt_type;
-static char BrowsePrompt[20];
 
-
-char *R_PromptString(int browselevel, int type)
+char *R_PromptString(int browselevel, int type, SEXP rho)
 {
 if (R_Slave) {
-	BrowsePrompt[0] = '\0';
-	return BrowsePrompt;
+	return "" ;
 }
 else {
 	if(type == 1) {
 	if(browselevel) {
-		sprintf(BrowsePrompt, "Browse[%d]> ", browselevel);
-		return BrowsePrompt;
+		SEXP call ;
+		SEXP level ;
+		SEXP res ;
+		char* prompt ;
+		PROTECT( level = allocVector(INTSXP, 1) ) ;
+		INTEGER(level)[0] = browselevel ;
+		PROTECT( call = lang3( install("getBrowsePrompt"), level, rho  ) ) ;
+		PROTECT( res = eval( call, R_GlobalEnv ) );
+		prompt = (char *)CHAR(STRING_ELT(res, 0)) ;
+		UNPROTECT( 3 ) ;
+		return prompt ;
 	}
 	return (char *)CHAR(STRING_ELT(GetOption(install("prompt"),
 		 R_BaseEnv), 0));
@@ -202,7 +208,7 @@
 
 if(!*state->bufp) {
 	R_Busy(0);
-	if (R_ReadConsole(R_PromptString(browselevel, state->prompt_type),
+	if (R_ReadConsole(R_PromptString(browselevel, state->prompt_type, rho),
 			  state->buf, CONSOLE_BUFFER_SIZE, 1) == 0)
 		return(-1);
 	state->bufp = state->buf;
@@ -331,7 +337,7 @@
 
 if(!*DLLbufp) {
 	R_Busy(0);
-	if (R_ReadConsole(R_PromptString(0, prompt_type), DLLbuf,
+	if (R_ReadConsole(R_PromptString(0, prompt_type, R_GlobalEnv), DLLbuf,
 			  CONSOLE_BUFFER_SIZE, 1) == 0)
 	return -1;
 	DLLbufp = DLLbuf;
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] matplot does not considere the parametre lend (PR#13619)

[maechler]

> "DM" == Duncan Murdoch 
> on Mon, 23 Mar 2009 19:35:15 -0400 writes:

DM> On 23/03/2009 7:25 PM, cgeno...@u-paris10.fr wrote:
>> Full_Name: Christophe Genolini
>> Version: 2.8.1, but also 2.9
>> OS: Windows XP
>> Submission from: (NULL) (82.225.59.146)
>> 
>> 
>> I am using matplot with the option lend="butt", but only the first line 
(the
>> black) is printed correctly  :
>> 
>>> matplot(matrix(1:9,3),type="c",lwd=10,lty=1,lend="butt")

DM> I'd call this another case where it is performing as documented, but 
DM> should probably be changed (but not by me).  

I have now added the desired feature to R-devel and 
'R 2.9.0 patched'.

Martin Maechler


DM> In the meantime, there's  the simple workaround:

DM> save <- par(lend="butt")
DM> matplot(matrix(1:9,3),type="c",lwd=10,lty=1)
DM> par(save)

DM> Duncan Murdoch

>> 
>> Gabor Grothendieck find the problem in matplot code:
>> the ... is passed to plot (which plots the first series) but not to 
lines (which
>> plots the rest):
>> 
>> if (!add) {
>> ii <- ii[-1]
>> plot(x[, 1], y[, 1], type = type[1], xlab = xlab, ylab = ylab,
>> xlim = xlim, ylim = ylim, lty = lty[1], lwd = lwd[1],
>> pch = pch[1], col = col[1], cex = cex[1], bg = bg[1],
>> ...)
>> }
>> for (i in ii) {
>> lines(x[, i], y[, i], type = type[i], lty = lty[i], lwd = lwd[i],
>> pch = pch[i], col = col[i], cex = cex[i], bg = bg[i])
>> }
>> 
>> __
>> R-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel

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

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

[Rd] Suggestion for changing r-project.org webpage text around bug reporting (was Re: 'is.integer' (PR#13671))

[Tony Plate]

Martin Maechler wrote:

"SM" == Stavros Macrakis 
on Wed, 22 Apr 2009 16:30:36 -0400 writes:



SM> Dear R experts,
SM> You are being a bit harsh on this user. 


No! (see below)

SM> He simply doesn't understand
SM> the distinction between "object of type integer" and "integer-valued
SM> object", which is actually fairly subtle.

yes, probably for the vast majority of today's R users.

*However*, Mauricio submitted a *formal* bug report against R
and there are many caveats against doing that "light-heartedly".
Note that he also said

 >> I would really appreciate if you could clarify if this is
 >> really a bug or not. 


and that this is exactly one of situation where one should post
a question to R-help (or maybe R-devel) but *NOT* submit a
formal bug report.

Regards,
Martin
  
Yep, but still, bug reports are a valuable service provided by the user 
community, and false bug reports are treated in a rather harsh manner by 
the R community.  It looks to me like it would be quite easy to give 
users a much better idea of the treatment they will receive for abusing 
the bug reporting system by making the web page text around bug 
reporting much harsher than it currently is.


If you go to r-project.org and click on "Bug tracking", you first see 
http://bugs.r-project.org/cgi-bin/R



You can submit new bug reports either using an online form by
clicking on the button below or by sending email to 
r-b...@r-project.org .

Then, clicking "Submit new report", you see:


Before submitting a bug report, please read Chapter `R Bugs' of `The R 
FAQ' . It 
describes what a bug is and how to report a bug.


If you are not sure whether you have observed a bug or not, it is a 
good idea to ask on the mailing list R-Help 
 by sending an 
e-mail to r-h...@stat.math.ethz.ch  
rather than submitting a bug report.


All of these blocks of text are misleadingly mild and friendly.  I 
suggest the following as more appropriate (including the shouting).  And 
don't make the r-b...@r-project.org address a clickable link, but do 
make the r-help and r-devel addresses hyperlinks:
The bug repository is for use by R experts only.  DO NOT USE THE BUG 
REPOSITORY FOR QUESTIONS ABOUT THE BEHAVIOR OF R, EVEN IF IT LOOKS 
ODD.  Submit a bug report either using an online form by clicking on 
the button below or by sending email to r-b...@r-project.org 
.  For questions about the behavior of R 
functions (including such things as 1/7 * 7 not always being exactly 
equal to 7 in floating point arithmetic), send email to 
r-h...@r-project.org.  For questions involving  esoteric programming 
issues in R, send email to r-de...@r-project.org.

And then after clicking "Submit new report", show this:
The bug repository is for use by R experts only.  If you have not 
submitted a bug report before, YOU MUST READ Chapter `R Bugs' of `The 
R FAQ' . It 
describes what a bug is and how to report a bug.  Also, you should at 
least scan the contents section of `The R FAQ' 
 to make sure 
that you are not reasking a FAQ.
If you not absolutely sure that you have observed a bug, DO NOT SUBMIT 
A BUG REPORT.  Instead, send a question to the mailing list R-Help 
 by sending an 
e-mail to r-h...@stat.math.ethz.ch  .
I suspect that making changes like this would improve things for 
everybody.  The R maintainers will have to deal with less false bug 
reports, naive users will avoid harsh criticisms, and bystanders will 
witness fewer wince-inducing lashings.


And yes, it's more words, but it's boilerplate that experienced eyes can 
easily skip over.


-- Tony Plate

[rest of correspondence regarding is.integer() clipped]

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

Re: [Rd] RFC: Ability to suppress 'locale' from sessionInfo

[Friedrich Leisch]

> On Wed, 22 Apr 2009 12:49:05 -0700,
> Kasper Daniel Hansen (KDH) wrote:

  > This is a better way, it does two things
  > a) enclose the itemize environment in a flushleft environment - this  
  > gives us much better line breaks for the verb.
  > b) does a replace of ";" with ";| \verb|" so that each "component" of  
  > the locale gets enclosed in its own \verb command, which allows latex  
  > to produce line breaks (since I am using gsub, I do gsub(";", ";| \\\ 
  > \verb", object$locale))

  > Below is a proposed utils:::toLatex.sessionInfo

Thanks, I have integrated it into the devel branch, and also modified
the print method to split the locale information:

R> sessionInfo()
R version 2.10.0 Under development (unstable) (2009-04-23 r48380) 
x86_64-unknown-linux-gnu 

locale:
 [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C  
 [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
 [5] LC_MONETARY=C  LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8   LC_NAME=C 
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C   

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base


The default for the new locale argument is TRUE.

Best,
Fritz

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

Re: [Rd] 'is.integer' (PR#13671)

[Mauricio Zambrano]

Thanks for the clear answer Stephen and thanks to all the guys that
pointed out my misunderstanding about the distinction between object
of type integer" and "integer-valued object".

I'm sorry for submitting to the R-bugs list something that is very
clear for all the members of the list, but it was not clear for me
after reading the help, because I was testing if a particular result
had a decimal part or not, and it seemed natural to me to use the
'is.integer' function instead of a combination of other operations.

Probably, and only if the guys of r-devel deem it necessary, it could
be good to add a small example at the end of the 'is.integer' function
showing that is.integer(1) is FALSE (or the example mentioned by
Martin), which can avoid this misunderstanding to people with less
knowledge about storage modes in R.

Thank you very much, and in the future I will use R-help or maybe R-devel.

Mauricio
-- 
Linux user  #454569 -- Ubuntu user #17469

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

Re: [Rd] Problems building R 2.9.0... on SGI and Sun once again

[Darin A. England]

I have the same problem trying build R 2.9.0 on AIX using the IBM 
Visual Age compilers and GNU make. I'm trying to figure it out, but
any hints on a fix are greatly appreciated.
Thanks,
Darin

gmake[2]: Entering directory `/home/denglan/R/builddir/src/library/methods'
building package 'methods'
mkdir ../../../library/methods
gmake[3]: Entering directory `/home/denglan/R/builddir/src/library/methods'
mkdir ../../../library/methods/R
/bin/sh: syntax error at line 1 : `;' unexpected
gmake[3]: *** [front] Error 2
gmake[3]: Leaving directory `/home/denglan/R/builddir/src/library/methods'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory `/home/denglan/R/builddir/src/library/methods'
gmake[1]: *** [R] Error 1
gmake[1]: Leaving directory `/home/denglan/R/builddir/src/library'
gmake: *** [R] Error 1
make: The error code from the last command is 1.


On Mon, Apr 20, 2009 at 02:54:58PM +0300, Atro Tossavainen wrote:
> I've successfully built R 2.9.0 on Linux (amd64, i386 and ppc), but am
> having a bit of trouble with legacy boxen.  What should have gone into
> the variable that is empty at the time it is used in "for f in $SOMETHING"
> and why does it end up being empty?
> 
> Solaris 8 with Sun Studio 11 compilers:
> 
> building package 'methods'
> gmake[4]: Entering directory `/scratch/atossava/R-2.9.0/src/library/methods'
> all.R is unchanged
> /bin/bash: -c: line 1: syntax error near unexpected token `;'
> /bin/bash: -c: line 1: `for f in ; do  if test -f ./${f}; then  
> ../../../tools/install-sh -c -m 644 ./${f}  ../../../library/methods;  fi;  
> done'
> gmake[4]: *** [front] Error 2
> gmake[4]: Leaving directory `/scratch/atossava/R-2.9.0/src/library/methods'
> 
> IRIX 6.5 with MIPSpro 7.4.4 compilers:
> 
> building package 'methods'
> gmake[4]: Entering directory `/wrk/atossava/R-2.9.0/src/library/methods'
> all.R is unchanged
> /bin/sh: syntax error at line 1 : `;' unexpected
> gmake[4]: *** [front] Error 2
> gmake[4]: Leaving directory `/wrk/atossava/R-2.9.0/src/library/methods'
> 
> -- 
> Atro Tossavainen (Mr.)   / The Institute of Biotechnology at
> Systems Analyst, Techno-Amish & / the University of Helsinki, Finland,
> +358-9-19158939  UNIX Dinosaur / employs me, but my opinions are my own.
> < URL : http : / / www . helsinki . fi / %7E atossava / > NO FILE ATTACHMENTS
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] Closed-source non-free ParallelR ?

[Matthew Dowle]

how could it [MCE] swap a GPL license for the BSD?
Because the BSD is an open source license compatible with GPL.  See 
http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses



derivative work
Points taken. It may not be derivation in the sense of modification, more in 
the sense of using R as a library :

http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL  (paragraphs 3 
and 4 in particular)


R, and base functions written in R, are GPL not LGPL.  In the context of the 
FAQ above, do your packages use base functions ?

http://www.gnu.org/philosophy/why-not-lgpl.html

The first R FAQ (1.1) states that R is released under GPL version 2 or any 
later version.
At the end of the GPL (both v2 and v3) it says "This General Public License 
does not permit incorporating your program into proprietary programs. If 
your program is a subroutine library, you may consider it more useful to 
permit linking proprietary applications with the library. If this is what 
you want to do, use the GNU Lesser General Public License instead of this 
License."


there are certainly many existing R packages with non-free/non-open 
licenses
They could be in breach too. The fact their licenses are like that does not 
in itself mean they are compliant with the GPL. R FAQ 2.11 defers to legal 
counsel - it mentions such licenses but it states no opinion about them as 
far as my reading goes. At least the source code of those packages is 
available for download. REvolution appear to be going one step further i.e. 
bundling R with their proprietary packages and selling the work as a whole.


Could someone from the R Foundation or the FSF step in and clarify the 
situation please ?   If in your opinion it is all fine what people are 
doing, why not release R under the LGPL for clarity ?


Regards, Matthew

- Original Message - 
From: "David M Smith" 

To: "Matthew Dowle" 
Cc: "Patrick Shields" ; 


Sent: Wednesday, April 22, 2009 4:36 PM
Subject: Re: [Rd] Closed-source non-free ParallelR ?


Patrick made all the points that I was going to make (thanks,
Patrick), but I wanted to reinforce one point that may be the source
of the confusion: ParallelR is not a modified version of R: ParallelR
is a suite of ordinary R packages that run on top of the R engine like
any other package. The R code and Python code in these packages were
written entirely by REvolution Computing staff (including Patrick),
and do not contain any code (derived or otherwise) from the R project.

In retrospect, the name ParallelR may be somewhat confusing in this sense...

# David Smith

On Wed, Apr 22, 2009 at 7:40 AM, Patrick Shields
 wrote:
I'm Pat Shields, one of the software engineers working on ParallelR. I 
just

wanted to make two points: no R code or previously gpl'd code can be found
in any of the non-gpl packages in ParallelR. I'm sure that the phrase
"derived works" is a legally subtle one, but all these packages include 
are

R and occasionally python scripts (as well as the standard text
documentation). If these are derived works, doesn't that mean that any R
code is also, by extension, required to be GPL'd? If not, is it including
these scripts in a package that forces the use of the GPL?

Also, I'm confused about your dimissal of the MCE example. If that code 
was

a derivative work of R, how could it swap a GPL license for the BSD? I
didn't think such a switch was possible. If it was, I'd imagine a lot more
use of it, as a quick front project could make GPL software into BSD
software after which all changes could go on behind closed doors.

On Tue, Apr 21, 2009 at 7:38 PM, Matthew Dowle 
wrote:



Dear R-devel,

REvolution appear to be offering ParallelR only when bundled with their R
Enterprise edition. As such it appears to be non-free and closed source.
http://www.revolution-computing.com/products/parallel-r.php

Since R is GPL and not LGPL, is this a breach of the GPL ?

Below is the "GPL and ParallelR" thread from their R forum.

mdowle > It appears that ParallelR (packages foreach and iterators) is
only available bundled with the Enterprise edition. Since R is GPL, and
ParallelR is derived from R, should ParallelR not also be GPL? Regards,
Matthew

revolution > Hello Matthew, ParallelR consists of both proprietary and 
GPL

packages. The randomForest and snow libraries GPL licensed, whereas the
other libraries we include have a commercial license(including 'foreach' 
and

'iterators'). Stephen Weller

revolution > I wanted to expand on Stephen's reply. ParallelR is a suite 
of

R packages, and it is well established that packages can be under a
difference license than R itself (i.e. not the GPL). For example, package
MCE is licensed under BSD, RColorBrewer is licensed under Apache, most of
Bioconductor is under the Artistic license and some ar

Re: [Rd] Problems building R 2.9.0... on SGI and Sun once again

[Peter Dalgaard]

Darin A. England wrote:
> I have the same problem trying build R 2.9.0 on AIX using the IBM 
> Visual Age compilers and GNU make. I'm trying to figure it out, but
> any hints on a fix are greatly appreciated.


This seems to come from constructions of the form

for i in $FOO : do  ; done

If $FOO is empty, then the resulting "for i in ;" is a syntax error with
some versions of bash and sh. Current Linux versions of bash do not have
that behaviour. As we saw in an earlier post, quotes around $FOO is not
the answer.

One workaround could be to upgrade bash.

Another workaround could be to safeguard the for-loop with

test "$FOO" != "" && for i in $FOO : do  ; done

in all of the Makefiles where this can be an issue.




-- 
   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
~~ - (p.dalga...@biostat.ku.dk)  FAX: (+45) 35327907

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

Re: [Rd] Closed-source non-free ParallelR ?

[Sim, Fraser]

Hi Matt,

Do you know if a project like R(D)COM/Statconn can changing their
license to make it closed-source? (www.statconn.com &
http://rcom.univie.ac.at/ )

There was discussion on the RCom board about such changes earlier this
year as they move toward commercialization. If you're not familiar it's
a package/windows COM program that allows EXCEL and other win apps to
interact directly with R. They have also generated an installer package
which installs R at the same time as their software. It makes 'R'
effectively disappear from the windows box.

Would distribution of that software also have to stay as GPL not LGPL?
As R effectively sits within the proprietary system of Statconn.

Regards, Fraser

-Original Message-
From: r-devel-boun...@r-project.org
[mailto:r-devel-boun...@r-project.org] On Behalf Of Matthew Dowle
Sent: Wednesday, April 22, 2009 7:37 PM
To: David M Smith; Patrick Shields; r-devel@r-project.org
Subject: Re: [Rd] Closed-source non-free ParallelR ?

> how could it [MCE] swap a GPL license for the BSD?
Because the BSD is an open source license compatible with GPL.  See 
http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses

> derivative work
Points taken. It may not be derivation in the sense of modification,
more in 
the sense of using R as a library :
http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL  (paragraphs
3 
and 4 in particular)

R, and base functions written in R, are GPL not LGPL.  In the context of
the 
FAQ above, do your packages use base functions ?
http://www.gnu.org/philosophy/why-not-lgpl.html

The first R FAQ (1.1) states that R is released under GPL version 2 or
any 
later version.
At the end of the GPL (both v2 and v3) it says "This General Public
License 
does not permit incorporating your program into proprietary programs. If

your program is a subroutine library, you may consider it more useful to

permit linking proprietary applications with the library. If this is
what 
you want to do, use the GNU Lesser General Public License instead of
this 
License."

> there are certainly many existing R packages with non-free/non-open 
> licenses
They could be in breach too. The fact their licenses are like that does
not 
in itself mean they are compliant with the GPL. R FAQ 2.11 defers to
legal 
counsel - it mentions such licenses but it states no opinion about them
as 
far as my reading goes. At least the source code of those packages is 
available for download. REvolution appear to be going one step further
i.e. 
bundling R with their proprietary packages and selling the work as a
whole.

Could someone from the R Foundation or the FSF step in and clarify the 
situation please ?   If in your opinion it is all fine what people are 
doing, why not release R under the LGPL for clarity ?

Regards, Matthew

- Original Message - 
From: "David M Smith" 
To: "Matthew Dowle" 
Cc: "Patrick Shields" ; 

Sent: Wednesday, April 22, 2009 4:36 PM
Subject: Re: [Rd] Closed-source non-free ParallelR ?


Patrick made all the points that I was going to make (thanks,
Patrick), but I wanted to reinforce one point that may be the source
of the confusion: ParallelR is not a modified version of R: ParallelR
is a suite of ordinary R packages that run on top of the R engine like
any other package. The R code and Python code in these packages were
written entirely by REvolution Computing staff (including Patrick),
and do not contain any code (derived or otherwise) from the R project.

In retrospect, the name ParallelR may be somewhat confusing in this
sense...

# David Smith

On Wed, Apr 22, 2009 at 7:40 AM, Patrick Shields
 wrote:
> I'm Pat Shields, one of the software engineers working on ParallelR. I

> just
> wanted to make two points: no R code or previously gpl'd code can be
found
> in any of the non-gpl packages in ParallelR. I'm sure that the phrase
> "derived works" is a legally subtle one, but all these packages
include 
> are
> R and occasionally python scripts (as well as the standard text
> documentation). If these are derived works, doesn't that mean that any
R
> code is also, by extension, required to be GPL'd? If not, is it
including
> these scripts in a package that forces the use of the GPL?
>
> Also, I'm confused about your dimissal of the MCE example. If that
code 
> was
> a derivative work of R, how could it swap a GPL license for the BSD? I
> didn't think such a switch was possible. If it was, I'd imagine a lot
more
> use of it, as a quick front project could make GPL software into BSD
> software after which all changes could go on behind closed doors.
>
> On Tue, Apr 21, 2009 at 7:38 PM, Matthew Dowle 
> wrote:
>
>> Dear R-devel,
>>
>> REvolution appear to be offering ParallelR only when bundled with
their R
>> Enterprise edition. As such it appears to be non-free

Re: [Rd] Closed-source non-free ParallelR ?

[Stavros Macrakis]

The FSF clearly promulgated the GPL with the intent of prohibiting the
bundling of GPL code with proprietary code.  The way the GPL does this
is by putting conditions on distribution: if you "distribute" a
program "based on" a GPL program, the whole program must be licensed
under the GPL.

Clearly, the crux of the matter is the meaning of "distribute" and
"based on".  The FSF takes a maximalist view of this, so that (for
example) distributing R together with additional components (libraries
/ packages / whatever), even if they are in separate files and loaded
dynamically, would require that the additional components be licensed
under GPL (and therefore that their source be released).  The
additional libraries need not be derived works of the original; this
is not a copyright issue, but a licensing issue.

I am not a lawyer, so can't judge this professionally, but it seems to
me that the copyright owner is within his rights to impose conditions
like this on distribution -- just as he could arbitrarily decide that
he will only license his code to people whose names begin with 'T'.
The logic is not: "I require you to release your code under GPL" but:
"I will only license my GPL code to you for this application if you
release your code under GPL".

On the other hand, the GPL explicitly allows *users* of the code to do
what they want, including mixing it with proprietary code, as long as
they don't distribute the result.  And I do not believe the copyright
holder has any way of preventing a third party from distributing
*separately* code that can be run on top of R.  In fact the FSF itself
has been quite clear that they don't consider that the license for a
language implementation restricts the code that can be run on top of
it in any way.

All that being said, the entity that must enforce these conditions is
not the FSF, but the copyright owner, in this case the R Foundation
and the copyright holders of any other packages redistributed by the
bundler. So it would be useful to know what the R Foundation's
position is.  Regardless of what the license says, it is up to the R
Foundation to decide what *its* interpretation of the license is and
under what circumstances it would ask a distributor of its code to
cease and desist -- and that failing, sue.

 -s

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

Re: [Rd] 'is.integer' (PR#13671)

[Latchezar (Lucho) Dimitrov]

Hey core-developers,

With all the respect to your precious time and beliefs isn't that
phenomenon (as many others similar ones) due to deficiencies in the R
docs/FAQ's/etc? I hate to think you assume all other R users are
malicious idiots trying to spoil your time.

Thanks you very much,

Latchezar 

> -Original Message-
> From: r-devel-boun...@r-project.org 
> [mailto:r-devel-boun...@r-project.org] On Behalf Of hadley wickham
> Sent: Thursday, April 23, 2009 9:08 AM
> To: Martin Maechler
> Cc: r-de...@stat.math.ethz.ch
> Subject: Re: [Rd] 'is.integer' (PR#13671)
> 
> > *However*, Mauricio submitted a *formal* bug report against R and 
> > there are many caveats against doing that "light-heartedly".
> > Note that he also said
> 
> I know it's frustrating when people repeatedly ask this 
> question (and file bug reports related to it), but does it 
> really take that long to tell them to check out FAQ 7.31, and 
> to close the bug report?
> 
> Hadley
> 
> 
> --
> http://had.co.nz/
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
> 

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

[Rd] reference counting problem in .Primitive's?

[William Dunlap]

I think the following rather wierd expressions show a problem in how
some of the .Primitive functions evaluate their arguments.  I haven't
yet thought of a way that a nonabusive user might run into this problem.
In each case the first argument, x, is modified in the course of
evaluating the second argument and then modified x gets used
as the first argument:

> x<-as.integer(1:5); y <- x + { x[3]<-33L ; 1L } ; y
[1]  2  3 34  5  6
> x<-2^(0:4) ; y <- log(x, { x[3]<-64 ; 2 }) ; y
[1] 0 1 6 3 4

The reason I think it looks like a sharing problem (and not an order
of evaluation problem) is that if your modification to x causes it to
use a new block of memory then the unmodified version of x gets
used as the first argument.  E.g.,

> x<-as.integer(1:5) ; y <- x + { x[3]<-33.3; 1L} ; y
[1] 2 3 4 5 6

I haven't yet thought of a way that a nonabusive user might run
into this problem.

Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com 

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

Re: [Rd] Closed-source non-free ParallelR ?

[Marc Schwartz]

On Apr 23, 2009, at 11:47 AM, Stavros Macrakis wrote:


All that being said, the entity that must enforce these conditions is
not the FSF, but the copyright owner, in this case the R Foundation
and the copyright holders of any other packages redistributed by the
bundler. So it would be useful to know what the R Foundation's
position is.  Regardless of what the license says, it is up to the R
Foundation to decide what *its* interpretation of the license is and
under what circumstances it would ask a distributor of its code to
cease and desist -- and that failing, sue.


Actually, the R Foundation has done what it is obligated to do, which  
is to describe the license under which R is made available. To ask the  
R Foundation for anything further is to ask them to render a legal  
opinion, which is not in their expertise to offer.


It is up to the prospective third party developer of an application  
that is to use R to consult with lawyers to determine what *THEIR*  
obligations are if they should elect to proceed. Since much of this  
has not yet been tested in case law, the burden is on the the third  
party developer, not on the R Foundation, since the R Foundation  
cannot reasonably conceive of every possible scenario under which R or  
subsets of code from R may be used.


The key thing to keep in mind is that the GPL really applies to the  
**distribution** of software and not the **use** of software.


Thus, if one is going to use R or code from R "internally", the  
obligations are more limited than if one builds an application that  
links to R or uses code from R and then will *distribute* that  
application to other parties, whether that distribution be free of  
charge or for a price.


There are two key scenarios here:

1. I am building an application that simply "calls" R via a script or  
batch type of interface. Think building a GUI on top of R. I  
distribute my application and may or may not distribute R with it. I  
can license my application in any fashion that I wish, closed source  
or otherwise. If I don't distribute R with my application and simply  
point users to where they can download R, then I have no obligation  
with respect to R. If I distribute R with my application, then I also  
have an obligation to make R's source code available to my users in  
some fashion. Neither situation obligates me to make the source code  
for my application available or to license my application under the GPL.


2. I build an application that includes source code from R and/or  
"links" to R libraries at a compiler level. In this case the  
"derivative works" and/or the so-called "viral" part of the GPL kicks  
in. Here, I am obligated to license my application under a compatible  
license AND make the source code to my application available as a  
consequence.


At this level, it is really pretty simple and a lot of these things  
are covered in the GPL FAQs, including the reporting of violations.


  For GPL 3:
  http://www.gnu.org/licenses/gpl-faq.html

  For GPL 2:
  http://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html

HTH,

Marc Schwartz

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

Re: [Rd] Closed-source non-free ParallelR ?

[Friedrich Leisch]

> On Thu, 23 Apr 2009 00:36:48 +0100,
> Matthew Dowle (MD) wrote:

[...]

  > Could someone from the R Foundation or the FSF step in and clarify the 
  > situation please ?

Just a short clarification (by no means intended to stop the thread):
as you can imagine we are discussing the matter internally in R Core
and the Foundation, but there are different views and we want to
consolidate before we make a public statement.  If all of us were of
the same opinion we would already have made one.

Unfortunately New Zealand, Europe and the US are in quite different
time zones, hence discussions by email take some time.

Best regards,
Fritz Leisch

-- 
---
Prof. Dr. Friedrich Leisch 

Institut für Statistik  Tel: (+49 89) 2180 3165
Ludwig-Maximilians-Universität  Fax: (+49 89) 2180 5308
Ludwigstraße 33
D-80539 München http://www.statistik.lmu.de/~leisch
---
   Journal Computational Statistics --- http://www.springer.com/180 
  Münchner R Kurse --- http://www.statistik.lmu.de/R

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

Re: [Rd] reference counting problem in .Primitive's?

[luke]

On Thu, 23 Apr 2009, William Dunlap wrote:


I think the following rather wierd expressions show a problem in how
some of the .Primitive functions evaluate their arguments.  I haven't
yet thought of a way that a nonabusive user might run into this problem.
In each case the first argument, x, is modified in the course of
evaluating the second argument and then modified x gets used
as the first argument:


x<-as.integer(1:5); y <- x + { x[3]<-33L ; 1L } ; y

[1]  2  3 34  5  6

x<-2^(0:4) ; y <- log(x, { x[3]<-64 ; 2 }) ; y

[1] 0 1 6 3 4

The reason I think it looks like a sharing problem (and not an order
of evaluation problem) is that if your modification to x causes it to
use a new block of memory then the unmodified version of x gets
used as the first argument.  E.g.,


x<-as.integer(1:5) ; y <- x + { x[3]<-33.3; 1L} ; y

[1] 2 3 4 5 6

I haven't yet thought of a way that a nonabusive user might run
into this problem.


You are probably right.  I have not yet looked at the code but am
virtually certain it does not try to temporarily bump up the NAMED
values on argument values.  Doing so would cure this but probably at
serious cost to performance, as NAMED values of 2 cannot be brought
down again and so cause copying on next modify. (Might be worth
running some tests on that though to see what the cost would be).

I'm not sure if it is written anywhere that argunments of primitives
(BUILTINS in articular as those are always strict; SPECIALS can be
non-strict but log is strict) are evaluated in any particular order.
All these examples are consistent with _some_ evaluation order, but
not the same one.  It might be possible to show that the results
obtained in these situations will always be consistent with some
evaluation order, in which case documenting that order of evaluation
is unspecified would be good enough form me.  It may also be possible
that an order that does compound expressions first and then symbols
would also solve the issue (I don't think I would want to do this in
the interpreter though because of the performance overhead.)

luke




Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com

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



--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
   Actuarial Science
241 Schaeffer Hall  email:  l...@stat.uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu

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

Re: [Rd] Closed-source non-free ParallelR ?

[Gabor Grothendieck]

On Thu, Apr 23, 2009 at 1:41 PM, Friedrich Leisch
 wrote:
>> On Thu, 23 Apr 2009 00:36:48 +0100,
>> Matthew Dowle (MD) wrote:
>
> [...]
>
>  > Could someone from the R Foundation or the FSF step in and clarify the
>  > situation please ?
>
> Just a short clarification (by no means intended to stop the thread):
> as you can imagine we are discussing the matter internally in R Core
> and the Foundation, but there are different views and we want to
> consolidate before we make a public statement.  If all of us were of
> the same opinion we would already have made one.
>
> Unfortunately New Zealand, Europe and the US are in quite different
> time zones, hence discussions by email take some time.


Aside from R there are the add-on packages.

A frequency table showing the licenses of the CRAN packages indicates
that the all or almost all packages have some sort of free software license
with GPL licenses being most common. (A few packages have restrictions
to noncommercial use and that may conflict with GPL, not sure.)   That is
not to say that there are no other types of packages but any such packages
are not on CRAN.

 AGPL (>3.0), with attribution as per LICENSE file
1
  AGPL 3.0 (with attribution)
1
   Apache License 2.0
2
 Artistic-2.0
5
 Artistic License
2
 Artistic License 2.0
1
 avas is public domain, ace is on Statlib
1
  BSD
   16
   CeCILL
1
 CeCILL-2
2
Common Public License Version 1.0
2
   Distribution and use for non-commercial purposes only.
1
 file LICENCE
2
 file LICENSE
   38
  Fortran code: ACM, free for non-commercial use, R functions
1
 free for non-commercial purposes
1
  Free for nonprofit use.
1
  Free. See the LICENCE file for details.
1
   GNU General Public License
3
 GNU General Public License Version 2
4
  GPL
  222
GPL-2
  316
 GPL-2 | file LICENCE
1
 GPL-2 | file LICENSE
7
GPL-2 | GPL-3
   13
  GPL-2.  Contributions from Randall C. Johnson are Copyright
1
  GPL-2; incorporates by permission code of W. Bachman (wrtab
1
GPL-3
   38
 GPL (≥ 2)
  872
  GPL (≥ 2) | file LICENSE
1
   GPL (≥ 2.0)
2
   

[Rd] License status of CRAN packages

[Dirk Eddelbuettel]

(Subject: renamed as thread hijacked from the ParallelR thread   --Dirk)

On 23 April 2009 at 14:44, Gabor Grothendieck wrote:
| Aside from R there are the add-on packages.
| 
| A frequency table showing the licenses of the CRAN packages indicates
| that the all or almost all packages have some sort of free software license
| with GPL licenses being most common. (A few packages have restrictions
| to noncommercial use and that may conflict with GPL, not sure.)   That is
| not to say that there are no other types of packages but any such packages
| are not on CRAN.

I fear that is not quite the case.  There are quite a few packages like that.

Charles Blundell and I have continued to work on his Google Summer of Code
2008 project of fully automatically creating Debian packages from CRAN
sources.  As this can be seen as redistributing (or at least as making
redistribution easier), we have tried to be careful about the licenses.  We
currently build about 1500 out of 1650 or so 'buildable' packages, but we
stop if we do not explicitly know the licenses (and Charles had e.g. created
several dozen variants of writing out 'GPL' in less clear ways so that we
could include those packages).  Moreover one big show stopper is 'File
license' shown below as applicable for 38 packages You need to explicitly
study all of those 'license' files; some are free and some aren't.  The
trouble is that you cannot tell and you end up labelling packages as 'maybe
not free' even if they are (an example here may be mlbench).

That does not scale.  Ultimately, I fear we need someone to sit down and
classify CRAN sources packages into appropriate buckets of 'freeness' of use,
redistribution etc.  And/or to remap all packages to a smaller, saner set of
licenses (as e.g. those in licenses.db).  Section 1.1.1 of 'R Extensions' is
quite clear about this, but I would like this to go further.  

Given that install.packages() does not check, I am afraid that we are not
going far enough in preventing users from accessing packages that they may
not be able to access and use under the terms of the license file.
Ultimately, this may mean moving some packages to a 'non-free' repository
tree as well.

I'd love to hear comments and concrete suggestions.

Dirk


|  AGPL (>3.0), with attribution as per LICENSE file
| 1
|   AGPL 3.0 (with attribution)
| 1
|Apache License 2.0
| 2
|  Artistic-2.0
| 5
|  Artistic License
| 2
|  Artistic License 2.0
| 1
|  avas is public domain, ace is on Statlib
| 1
|   BSD
|16
|CeCILL
| 1
|  CeCILL-2
| 2
| Common Public License Version 1.0
| 2
|Distribution and use for non-commercial purposes only.
| 1
|  file LICENCE
| 2
|  file LICENSE
|38
|   Fortran code: ACM, free for non-commercial use, R functions
| 1
|  free for non-commercial purposes
| 1
|   Free for nonprofit use.
| 1
|   Free. See the LICENCE file for details.
| 1
|GNU General Public License
| 3
|  GNU General Public License Version 2
| 4
|   GPL
|   222
|  

Re: [Rd] License status of CRAN packages

[Gabor Grothendieck]

On Thu, Apr 23, 2009 at 3:08 PM, Dirk Eddelbuettel  wrote:
>
> (Subject: renamed as thread hijacked from the ParallelR thread   --Dirk)
>
> On 23 April 2009 at 14:44, Gabor Grothendieck wrote:
> | Aside from R there are the add-on packages.
> |
> | A frequency table showing the licenses of the CRAN packages indicates
> | that the all or almost all packages have some sort of free software license
> | with GPL licenses being most common. (A few packages have restrictions
> | to noncommercial use and that may conflict with GPL, not sure.)   That is
> | not to say that there are no other types of packages but any such packages
> | are not on CRAN.
>
> I fear that is not quite the case.  There are quite a few packages like that.

Not the case?  My post included a list of all License fields from the
DESCRIPTION file of every CRAN package so the list is definitive.

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

Re: [Rd] License status of CRAN packages

[Dirk Eddelbuettel]

On 23 April 2009 at 15:32, Gabor Grothendieck wrote:
| On Thu, Apr 23, 2009 at 3:08 PM, Dirk Eddelbuettel  wrote:
| >
| > (Subject: renamed as thread hijacked from the ParallelR thread   --Dirk)
| >
| > On 23 April 2009 at 14:44, Gabor Grothendieck wrote:
| > | Aside from R there are the add-on packages.
| > |
| > | A frequency table showing the licenses of the CRAN packages indicates
| > | that the all or almost all packages have some sort of free software 
license
| > | with GPL licenses being most common. (A few packages have restrictions
| > | to noncommercial use and that may conflict with GPL, not sure.)   That is
| > | not to say that there are no other types of packages but any such packages
| > | are not on CRAN.
| >
| > I fear that is not quite the case.  There are quite a few packages like 
that.
| 
| Not the case?  My post included a list of all License fields from the
| DESCRIPTION file of every CRAN package so the list is definitive.

Correct me if I am wrong in the paragraph you kindly left standing above, you
seem to suggest that

"all or almost all packages have some sort of free software license" 

and that while non-free licenses may exist, 

"any such packages are not on CRAN".

I believe this statement to be false.

There are packages with restrictive licenese on CRAN.  They were contained in
the list of licenses you assembled, and my point is that it is overly hard to
identify them (if one were to tty to avoid using these packages).

As a non-exhautive list with possible misclassifications, cran2deb currently
has these packasges as 'maybe not free' and does not build them:

 BARD,BayesDA,CoCo,ConvCalendar,FAiR,PTAk,RScaLAPACK,Rcsdp,SDDA,SGP,
 alphahull,ash,asypow,caMassClass,gpclib,mapproj,matlab,mclust,mclust02,
 mlbench,optmatch,rankreg,realized,rngwell19937,rtiff,rwt,scagnostics,
 sgeostat,spatialkernel,tlnise,xgobi

We are missing some recently added packages, and we may yet flag several from
the list above as free. Some may be listed because of non-free Depends:

But to take a concrete example, 'realized' is not something I am supposed to
install at work.  Yet install.packages() currently has not way knowing that.

Are we approximately on the same page ?

Dirk

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

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

Re: [Rd] Closed-source non-free ParallelR ?

[Stavros Macrakis]

On Thu, Apr 23, 2009 at 1:25 PM, Marc Schwartz  wrote:
> On Apr 23, 2009, at 11:47 AM, Stavros Macrakis wrote:
>>
>> All that being said, the entity that must enforce these conditions is
>> not the FSF, but the copyright owner, in this case the R Foundation...
>> bundler. So it would be useful to know what the R Foundation's
>> position is

> Actually, the R Foundation has done what it is obligated to do, which is to
> describe the license under which R is made available.

I did not say that the R Foundation was obligated to give advice.  I
said that it is up to the R Foundation to decide what cases it cares
about, and it would be "useful to know" what that position is.

> To ask the R Foundation for anything further is to ask them to render a legal
> opinion, which is not in their expertise to offer.

No, it is asking them what their *policy* is.  Their policy may or may
not be enforceable

> It is up to the prospective third party developer of an application that is
> to use R to consult with lawyers to determine what *THEIR* obligations are
> if they should elect to proceed.

Yes, this is true.  But it is also true that if (for example) the R
Foundation says officially that it interprets GPL to allow
distributing proprietary packages along with R, then that is the
interpretation that matters, since the R Foundation (not the FSF) is
the copyright holder.

> At this level, it is really pretty simple and a lot of these things are
> covered in the GPL FAQs, including the reporting of violations.

The GPL FAQs are the FSF's interpretation.  The R Foundation is not
obliged to have the same interpretation, and of course the FSF cannot
enforce licenses given by the R Foundation.

-s

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

Re: [Rd] License status of CRAN packages

[Marc Schwartz]

On Apr 23, 2009, at 3:02 PM, Dirk Eddelbuettel wrote:



On 23 April 2009 at 15:32, Gabor Grothendieck wrote:
| On Thu, Apr 23, 2009 at 3:08 PM, Dirk Eddelbuettel  
 wrote:

| >
| > (Subject: renamed as thread hijacked from the ParallelR thread
--Dirk)

| >
| > On 23 April 2009 at 14:44, Gabor Grothendieck wrote:
| > | Aside from R there are the add-on packages.
| > |
| > | A frequency table showing the licenses of the CRAN packages  
indicates
| > | that the all or almost all packages have some sort of free  
software license
| > | with GPL licenses being most common. (A few packages have  
restrictions
| > | to noncommercial use and that may conflict with GPL, not  
sure.)   That is
| > | not to say that there are no other types of packages but any  
such packages

| > | are not on CRAN.
| >
| > I fear that is not quite the case.  There are quite a few  
packages like that.

|
| Not the case?  My post included a list of all License fields from  
the

| DESCRIPTION file of every CRAN package so the list is definitive.

Correct me if I am wrong in the paragraph you kindly left standing  
above, you

seem to suggest that

"all or almost all packages have some sort of free software license"

and that while non-free licenses may exist,

"any such packages are not on CRAN".

I believe this statement to be false.

There are packages with restrictive licenese on CRAN.  They were  
contained in
the list of licenses you assembled, and my point is that it is  
overly hard to

identify them (if one were to tty to avoid using these packages).

As a non-exhautive list with possible misclassifications, cran2deb  
currently

has these packasges as 'maybe not free' and does not build them:

 
BARD,BayesDA,CoCo,ConvCalendar,FAiR,PTAk,RScaLAPACK,Rcsdp,SDDA,SGP,
 
alphahull 
,ash,asypow,caMassClass,gpclib,mapproj,matlab,mclust,mclust02,
 
mlbench,optmatch,rankreg,realized,rngwell19937,rtiff,rwt,scagnostics,

sgeostat,spatialkernel,tlnise,xgobi

We are missing some recently added packages, and we may yet flag  
several from
the list above as free. Some may be listed because of non-free  
Depends:


But to take a concrete example, 'realized' is not something I am  
supposed to
install at work.  Yet install.packages() currently has not way  
knowing that.


Are we approximately on the same page ?

Dirk


There is a list of acceptable entries that are defined as part of the  
specs in R-exts (see page 4). Perhaps this needs to be "tightened" a  
bit, at least in so far as packages passing R CMD check for the  
purpose of inclusion on CRAN. That would include perhaps altering the  
ability to use the 'file LICENSE' option, which at present leaves the  
door wide open for non-standard approaches. It may also have to check  
for DEPENDS and whether they too are on CRAN and passed the  
appropriate license checks.


Packages that fail this check should not be included on CRAN and the  
package author would then be obligated to find other distribution  
resources or contact the CRAN maintainers to advocate that their  
licensing schema should be acceptable.


Then the end user can at least have some comfort in knowing that  
anything they get from CRAN comes under a compatible license for  
general use without restriction. They would have to intentionally use  
other sources for packages that fail the CRAN requirements.


If other distribution venues, such as Debian/Ubuntu/Fedora elect to  
tighten those restrictions even further when making .debs or RPMs  
available, then that is a decision that they get to make and end users  
will need to be aware of those as well. Albeit I don't envision the  
aforementioned Linux distros including packages that should be a  
problem for most end users relative to usage restrictions given their  
own license review processes.


HTH,

Marc Schwartz

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

Re: [Rd] License status of CRAN packages

[Gabor Grothendieck]

Of the 31 packages listed:
 [1] "BARD"  "BayesDA"   "CoCo"  "ConvCalendar"
 [5] "FAiR"  "PTAk"  "RScaLAPACK""Rcsdp"
 [9] "SDDA"  "SGP"   "alphahull" "ash"
[13] "asypow""caMassClass"   "gpclib""mapproj"
[17] "matlab""mclust""mclust02"  "mlbench"
[21] "optmatch"  "rankreg"   "realized"  "rngwell19937"
[25] "rtiff" "rwt"   "scagnostics"   "sgeostat"
[29] "spatialkernel" "tlnise""xgobi"

the license fields are AGPL or GPL for 3 and specified in a separate
file "file LICENSE" so about 30 of 1700 < 2% are question marks.
To me that is not inconsistent with all or nearly all being free software
licenses but at any rate this quantifies it a bit better.  (A couple are
not listed below as I got a read error when trying to access its summary
from the CRAN site.  Its possible those 2 are not actually on CRAN.)

BARD
   "AGPL 3.0 (with attribution)"
 BayesDA
  "GPL (≥ 2)"
CoCo
  "file LICENSE"
ConvCalendar
  "file LICENCE"
FAiR
  "file LICENSE"
PTAk
  "file LICENSE"
   Rcsdp
  "file LICENSE"
SDDA
  "file LICENSE"
 SGP
  "file LICENSE"
   alphahull
  "file LICENSE"
 ash
   "S original available at statlib"
  asypow
  "file LICENSE"
 caMassClass
"The caMassClass Software License, Version 1.0 (See COPYING"
  gpclib
  "file LICENSE"
 mapproj
"Distribution and use for non-commercial purposes only."
  matlab
  "file LICENSE"
  mclust
  "file LICENSE"
mclust02
  "file LICENSE"
 mlbench
  "file LICENSE"
optmatch
  "file LICENSE"
 rankreg
   "Free for nonprofit use."
realized
  "file LICENSE"
rngwell19937
  "file LICENSE"
   rtiff
  "file LICENSE"
 rwt
  "file LICENSE"
 scagnostics
  "file LICENSE"
sgeostat
"Original ??, extensions GPL version 2 or newer"
   spatialkernel
  "file LICENSE"
  tlnise
  "file LICENSE"


2009/4/23 Dirk Eddelbuettel :
>
> On 23 April 2009 at 15:32, Gabor Grothendieck wrote:
> | On Thu, Apr 23, 2009 at 3:08 PM, Dirk Eddelbuettel  wrote:
> | >
> | > (Subject: renamed as thread hijacked from the ParallelR thread   --Dirk)
> | >
> | > On 23 April 2009 at 14:44, Gabor Grothendieck wrote:
> | > | Aside from R there are the add-on packages.
> | > |
> | > | A frequency table showing the licenses of the CRAN packages indicates
> | > | that the all or almost all packages have some sort of free software 
> license
> | > | with GPL licen

Re: [Rd] License status of CRAN packages

[Gabor Grothendieck]

In some other software systems there are separate repositories for
free and non-free add-ons.  That way its clear what you are downloading
yet there are good outlets for both types of software.  There has been some
discussion of future features that CRAN might have that might make
this even easier to do.   My opinion is that R will suffer if it were not
to support both types of software but at the same time its reasonable
to make it clear which type you are getting before you download it.

On Thu, Apr 23, 2009 at 4:35 PM, Marc Schwartz  wrote:
> On Apr 23, 2009, at 3:02 PM, Dirk Eddelbuettel wrote:
>
>>
>> On 23 April 2009 at 15:32, Gabor Grothendieck wrote:
>> | On Thu, Apr 23, 2009 at 3:08 PM, Dirk Eddelbuettel 
>> wrote:
>> | >
>> | > (Subject: renamed as thread hijacked from the ParallelR thread
>> --Dirk)
>> | >
>> | > On 23 April 2009 at 14:44, Gabor Grothendieck wrote:
>> | > | Aside from R there are the add-on packages.
>> | > |
>> | > | A frequency table showing the licenses of the CRAN packages
>> indicates
>> | > | that the all or almost all packages have some sort of free software
>> license
>> | > | with GPL licenses being most common. (A few packages have
>> restrictions
>> | > | to noncommercial use and that may conflict with GPL, not sure.)
>> That is
>> | > | not to say that there are no other types of packages but any such
>> packages
>> | > | are not on CRAN.
>> | >
>> | > I fear that is not quite the case.  There are quite a few packages
>> like that.
>> |
>> | Not the case?  My post included a list of all License fields from the
>> | DESCRIPTION file of every CRAN package so the list is definitive.
>>
>> Correct me if I am wrong in the paragraph you kindly left standing above,
>> you
>> seem to suggest that
>>
>>        "all or almost all packages have some sort of free software
>> license"
>>
>> and that while non-free licenses may exist,
>>
>>        "any such packages are not on CRAN".
>>
>> I believe this statement to be false.
>>
>> There are packages with restrictive licenese on CRAN.  They were contained
>> in
>> the list of licenses you assembled, and my point is that it is overly hard
>> to
>> identify them (if one were to tty to avoid using these packages).
>>
>> As a non-exhautive list with possible misclassifications, cran2deb
>> currently
>> has these packasges as 'maybe not free' and does not build them:
>>
>>    BARD,BayesDA,CoCo,ConvCalendar,FAiR,PTAk,RScaLAPACK,Rcsdp,SDDA,SGP,
>>    alphahull,ash,asypow,caMassClass,gpclib,mapproj,matlab,mclust,mclust02,
>>    mlbench,optmatch,rankreg,realized,rngwell19937,rtiff,rwt,scagnostics,
>>    sgeostat,spatialkernel,tlnise,xgobi
>>
>> We are missing some recently added packages, and we may yet flag several
>> from
>> the list above as free. Some may be listed because of non-free Depends:
>>
>> But to take a concrete example, 'realized' is not something I am supposed
>> to
>> install at work.  Yet install.packages() currently has not way knowing
>> that.
>>
>> Are we approximately on the same page ?
>>
>> Dirk
>
> There is a list of acceptable entries that are defined as part of the specs
> in R-exts (see page 4). Perhaps this needs to be "tightened" a bit, at least
> in so far as packages passing R CMD check for the purpose of inclusion on
> CRAN. That would include perhaps altering the ability to use the 'file
> LICENSE' option, which at present leaves the door wide open for non-standard
> approaches. It may also have to check for DEPENDS and whether they too are
> on CRAN and passed the appropriate license checks.
>
> Packages that fail this check should not be included on CRAN and the package
> author would then be obligated to find other distribution resources or
> contact the CRAN maintainers to advocate that their licensing schema should
> be acceptable.
>
> Then the end user can at least have some comfort in knowing that anything
> they get from CRAN comes under a compatible license for general use without
> restriction. They would have to intentionally use other sources for packages
> that fail the CRAN requirements.
>
> If other distribution venues, such as Debian/Ubuntu/Fedora elect to tighten
> those restrictions even further when making .debs or RPMs available, then
> that is a decision that they get to make and end users will need to be aware
> of those as well. Albeit I don't envision the aforementioned Linux distros
> including packages that should be a problem for most end users relative to
> usage restrictions given their own license review processes.
>
> HTH,
>
> Marc Schwartz
>
>

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

Re: [Rd] License status of CRAN packages

[Dirk Eddelbuettel]

On 23 April 2009 at 15:35, Marc Schwartz wrote:
| There is a list of acceptable entries that are defined as part of the  
| specs in R-exts (see page 4). Perhaps this needs to be "tightened" a  
| bit, at least in so far as packages passing R CMD check for the  
| purpose of inclusion on CRAN. That would include perhaps altering the  
| ability to use the 'file LICENSE' option, which at present leaves the  
| door wide open for non-standard approaches. It may also have to check  
| for DEPENDS and whether they too are on CRAN and passed the  
| appropriate license checks.

Exactly. 

| Packages that fail this check should not be included on CRAN and the  
| package author would then be obligated to find other distribution  
| resources or contact the CRAN maintainers to advocate that their  
| licensing schema should be acceptable.
| 
| Then the end user can at least have some comfort in knowing that  
| anything they get from CRAN comes under a compatible license for  
| general use without restriction. They would have to intentionally use  
| other sources for packages that fail the CRAN requirements.

Exactly.  I think we may have to work on tightening the standards of CRAN
re-distribution.

| If other distribution venues, such as Debian/Ubuntu/Fedora elect to  

cran2deb does not have inclusion to Debian in mind. What Charles and I are
thinking about is something aking to the Windows situation: suitable i386 and
amd64 binaries (for Debian Linux) provided from CRAN for as many packages as
possible.

Dirk

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

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

Re: [Rd] License status of CRAN packages

[Ben Goodrich]

Dirk Eddelbuettel  debian.org> writes:
> As a non-exhautive list with possible misclassifications, cran2deb currently
> has these packasges as 'maybe not free' and does not build them:
> 
>  BARD,BayesDA,CoCo,ConvCalendar,FAiR,PTAk,RScaLAPACK,Rcsdp,SDDA,SGP,
>  alphahull,ash,asypow,caMassClass,gpclib,mapproj,matlab,mclust,mclust02,
>  mlbench,optmatch,rankreg,realized,rngwell19937,rtiff,rwt,scagnostics,
>  sgeostat,spatialkernel,tlnise,xgobi

Small point: FAiR is free. The file LICENSE thing just clarifies that most of
the code is AGPL but a couple files can't be included under the AGPL and are
plain GPL. As far as I can see, R does not give me the option of saying so in a
"standard" way, e.g. putting License: AGPL (>= 3) in the DESCRIPTION file would
only be 95% accurate and putting License: AGPL (>= 3) | GPL (>= 3) is 
misleading.

Ben

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

Re: [Rd] License status of CRAN packages

[Dirk Eddelbuettel]

On 23 April 2009 at 16:35, Gabor Grothendieck wrote:
| Of the 31 packages listed:
|  [1] "BARD"  "BayesDA"   "CoCo"  "ConvCalendar"
|  [5] "FAiR"  "PTAk"  "RScaLAPACK""Rcsdp"
|  [9] "SDDA"  "SGP"   "alphahull" "ash"
| [13] "asypow""caMassClass"   "gpclib""mapproj"
| [17] "matlab""mclust""mclust02"  "mlbench"
| [21] "optmatch"  "rankreg"   "realized"  "rngwell19937"
| [25] "rtiff" "rwt"   "scagnostics"   "sgeostat"
| [29] "spatialkernel" "tlnise""xgobi"
| 
| the license fields are AGPL or GPL for 3 and specified in a separate
| file "file LICENSE" so about 30 of 1700 < 2% are question marks.

My point is that you currently need to manually parse 'file LICENSE'.  

And as I said, we did not claim that our set was exhaustive, current or
perfect. We just can't automate anything better given the current framework.
And I think we all should be able to do better in scripted approaches.  I
still think you're proving my point.  

| To me that is not inconsistent with all or nearly all being free software

I doubt that "all or nearly all" would equated to "exactly all" by a
court. You only need one bad apple to spoil the lot.

Dirk

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

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

Re: [Rd] Closed-source non-free ParallelR ?

[Max Kuhn]

> REvolution appear to be offering ParallelR only when bundled with their R 
> Enterprise edition.  As such it appears to be non-free and closed source.
>http://www.revolution-computing.com/products/parallel-r.php

Have you also looked at:

   http://nws-r.sourceforge.net/

The core of their ParallelR product is nws and that package was last
updated a month ago.

-- 

Max

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

Re: [Rd] License status of CRAN packages

[Gabor Grothendieck]

On Thu, Apr 23, 2009 at 4:59 PM, Ben Goodrich  wrote:
> Dirk Eddelbuettel  debian.org> writes:
>> As a non-exhautive list with possible misclassifications, cran2deb currently
>> has these packasges as 'maybe not free' and does not build them:
>>
>>      BARD,BayesDA,CoCo,ConvCalendar,FAiR,PTAk,RScaLAPACK,Rcsdp,SDDA,SGP,
>>      alphahull,ash,asypow,caMassClass,gpclib,mapproj,matlab,mclust,mclust02,
>>      mlbench,optmatch,rankreg,realized,rngwell19937,rtiff,rwt,scagnostics,
>>      sgeostat,spatialkernel,tlnise,xgobi
>
> Small point: FAiR is free. The file LICENSE thing just clarifies that most of
> the code is AGPL but a couple files can't be included under the AGPL and are
> plain GPL. As far as I can see, R does not give me the option of saying so in 
> a
> "standard" way, e.g. putting License: AGPL (>= 3) in the DESCRIPTION file 
> would
> only be 95% accurate and putting License: AGPL (>= 3) | GPL (>= 3) is 
> misleading.

How about "

License: AGPL except for 2 GPL files

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

Re: [Rd] Closed-source non-free ParallelR ?

[Fraser Sim]

Hi Matt,

Do you know if a project like R(D)COM/Statconn can changing their license to
make it closed-source? (www.statconn.com & http://rcom.univie.ac.at/ )

There was discussion on the RCom board about such changes earlier this year
as they move toward commercialization. If you're not familiar it's a
package/windows COM program that allows EXCEL and other win apps to interact
directly with R. They have also generated an installer package which
installs R at the same time as their software. It makes 'R' effectively
disappear from the windows box.

Would distribution of that software also have to stay as GPL not LGPL? As R
effectively sits within the proprietary system of Statconn.

Regards, Fraser

-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org]
On Behalf Of Matthew Dowle
Sent: Wednesday, April 22, 2009 7:37 PM
To: David M Smith; Patrick Shields; r-devel@r-project.org
Subject: Re: [Rd] Closed-source non-free ParallelR ?

> how could it [MCE] swap a GPL license for the BSD?
Because the BSD is an open source license compatible with GPL.  See 
http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses

> derivative work
Points taken. It may not be derivation in the sense of modification, more in

the sense of using R as a library :
http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL
http://www.gnu.org/licenses/gpl-faq.html#LinkingWithGPL
http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL  (paragraphs 3 
and 4 in particular)

R, and base functions written in R, are GPL not LGPL.  In the context of the

FAQ above, do your packages use base functions ?
http://www.gnu.org/philosophy/why-not-lgpl.html

The first R FAQ (1.1) states that R is released under GPL version 2 or any 
later version.
At the end of the GPL (both v2 and v3) it says "This General Public License 
does not permit incorporating your program into proprietary programs. If 
your program is a subroutine library, you may consider it more useful to 
permit linking proprietary applications with the library. If this is what 
you want to do, use the GNU Lesser General Public License instead of this 
License."

> there are certainly many existing R packages with non-free/non-open 
> licenses
They could be in breach too. The fact their licenses are like that does not 
in itself mean they are compliant with the GPL. R FAQ 2.11 defers to legal 
counsel - it mentions such licenses but it states no opinion about them as 
far as my reading goes. At least the source code of those packages is 
available for download. REvolution appear to be going one step further i.e. 
bundling R with their proprietary packages and selling the work as a whole.

Could someone from the R Foundation or the FSF step in and clarify the 
situation please ?   If in your opinion it is all fine what people are 
doing, why not release R under the LGPL for clarity ?

Regards, Matthew

- Original Message - 
From: "David M Smith" 
To: "Matthew Dowle" 
Cc: "Patrick Shields" ; 

Sent: Wednesday, April 22, 2009 4:36 PM
Subject: Re: [Rd] Closed-source non-free ParallelR ?


Patrick made all the points that I was going to make (thanks,
Patrick), but I wanted to reinforce one point that may be the source
of the confusion: ParallelR is not a modified version of R: ParallelR
is a suite of ordinary R packages that run on top of the R engine like
any other package. The R code and Python code in these packages were
written entirely by REvolution Computing staff (including Patrick),
and do not contain any code (derived or otherwise) from the R project.

In retrospect, the name ParallelR may be somewhat confusing in this sense...

# David Smith

On Wed, Apr 22, 2009 at 7:40 AM, Patrick Shields
 wrote:
> I'm Pat Shields, one of the software engineers working on ParallelR. I 
> just
> wanted to make two points: no R code or previously gpl'd code can be found
> in any of the non-gpl packages in ParallelR. I'm sure that the phrase
> "derived works" is a legally subtle one, but all these packages include 
> are
> R and occasionally python scripts (as well as the standard text
> documentation). If these are derived works, doesn't that mean that any R
> code is also, by extension, required to be GPL'd? If not, is it including
> these scripts in a package that forces the use of the GPL?
>
> Also, I'm confused about your dimissal of the MCE example. If that code 
> was
> a derivative work of R, how could it swap a GPL license for the BSD? I
> didn't think such a switch was possible. If it was, I'd imagine a lot more
> use of it, as a quick front project could make GPL software into BSD
> software after which all changes could go on behind closed doors.
>
> On Tue, Apr 21, 2009 at 7:38 PM, Matthew Dowle 
> wrote:
>
>> Dear R-devel,
>>
>> REvolution appear to be offering ParallelR only when bundled with their R
>> Enterprise edition. As such it appears to be non-free

Re: [Rd] License status of CRAN packages

[Ben Goodrich]

Gabor Grothendieck wrote:
> On Thu, Apr 23, 2009 at 4:59 PM, Ben Goodrich  
> wrote:
>> Dirk Eddelbuettel  debian.org> writes:
>>> As a non-exhautive list with possible misclassifications, cran2deb currently
>>> has these packasges as 'maybe not free' and does not build them:
>>>
>>>  BARD,BayesDA,CoCo,ConvCalendar,FAiR,PTAk,RScaLAPACK,Rcsdp,SDDA,SGP,
>>>  alphahull,ash,asypow,caMassClass,gpclib,mapproj,matlab,mclust,mclust02,
>>>  mlbench,optmatch,rankreg,realized,rngwell19937,rtiff,rwt,scagnostics,
>>>  sgeostat,spatialkernel,tlnise,xgobi
>> Small point: FAiR is free. The file LICENSE thing just clarifies that most of
>> the code is AGPL but a couple files can't be included under the AGPL and are
>> plain GPL. As far as I can see, R does not give me the option of saying so 
>> in a
>> "standard" way, e.g. putting License: AGPL (>= 3) in the DESCRIPTION file 
>> would
>> only be 95% accurate and putting License: AGPL (>= 3) | GPL (>= 3) is 
>> misleading.
> 
> How about "
> 
> License: AGPL except for 2 GPL files
> 

If that would make anyone's life easier without making anyone else's
life harder, I would be happy to put that in the DESCRIPTION file. I
have been doing file LICENSE because it parses on

http://cran.r-project.org/web/packages/FAiR/index.html

and people can click to the LICENSE link to read the details if they are
interested. But maybe that is not optimal. Dirk?

Ben

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

Re: [Rd] Closed-source non-free ParallelR ?

[Marc Schwartz]

On Apr 23, 2009, at 3:22 PM, Stavros Macrakis wrote:

On Thu, Apr 23, 2009 at 1:25 PM, Marc Schwartz  
 wrote:

On Apr 23, 2009, at 11:47 AM, Stavros Macrakis wrote:


All that being said, the entity that must enforce these conditions  
is
not the FSF, but the copyright owner, in this case the R  
Foundation...

bundler. So it would be useful to know what the R Foundation's
position is


Actually, the R Foundation has done what it is obligated to do,  
which is to

describe the license under which R is made available.


I did not say that the R Foundation was obligated to give advice.  I
said that it is up to the R Foundation to decide what cases it cares
about, and it would be "useful to know" what that position is.

To ask the R Foundation for anything further is to ask them to  
render a legal

opinion, which is not in their expertise to offer.


No, it is asking them what their *policy* is.  Their policy may or may
not be enforceable

It is up to the prospective third party developer of an application  
that is
to use R to consult with lawyers to determine what *THEIR*  
obligations are

if they should elect to proceed.


Yes, this is true.  But it is also true that if (for example) the R
Foundation says officially that it interprets GPL to allow
distributing proprietary packages along with R, then that is the
interpretation that matters, since the R Foundation (not the FSF) is
the copyright holder.

At this level, it is really pretty simple and a lot of these things  
are

covered in the GPL FAQs, including the reporting of violations.


The GPL FAQs are the FSF's interpretation.  The R Foundation is not
obliged to have the same interpretation, and of course the FSF cannot
enforce licenses given by the R Foundation.


Underlying all of your comments seems to be a presumption that the R  
Foundation can disentangle themselves from the FSF vis-a-vis the GPL.


Keep in mind that it is the FSF that is the copyright holder of the GPL.

The R Foundation may be the copyright holder to R, but they are  
distributing it under a license which they did not write.


Thus, I cannot envision any reasonable circumstances under which the R  
Foundation would place themselves in a position of legal risk in  
deviating from the interpretations of the GPL by the FSF. It would be  
insane legally to do so.


The key issue is the lack of case law relative to the GPL and that  
leaves room for interpretation. One MUST therefore give significant  
weight to the interpretations of the FSF as it will likely be the FSF  
that will be involved in any legal disputes over the GPL and its  
application. You would want them on your side, not be fighting them.


A parallel here is why most large U.S. public corporations legally  
incorporate in the state of Delaware, even though they may not have  
any material physical presence in that state. It is because the  
overwhelming majority of corporate case law in the U.S. has been  
decided under the laws of Delaware and the interpretations of said  
laws. If I were to start a company (which I have done in the past) and  
feared that I should find myself facing litigation at some future  
date, I would want that huge database of case law behind me. A small  
company (such as I had) may be less concerned about this and be  
comfortable with the laws of their own state, which I was. But if I  
were to be looking to build a big company with investors, etc. and  
perhaps look to go public at a future date, you bet I would look to  
incorporate in Delaware. It would be the right fiduciary decision to  
make in the interest of all parties.


Unfortunately, we have no such archive of case law yet of the GPL.  
Thus at least from a legally enforceable perspective, all is grey and  
the FSF has to be the presumptive leader here.


HTH,

Marc Schwartz

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

Re: [Rd] Closed-source non-free ParallelR ?

[Ian Fellows]

Assuming that the foundation does not want to deviate from the FSF
interpretation, there would still be value in clarifying its position
vis-à-vis how the license applies to R specifically. 

For example the FSF foundation claims that linking to a library (even in an
interpreted environment) makes your software derivative, and therefore must
be distributed Freely. They also claim that simply executing a program in an
interpreted (GPL'ed) environment is okay even though the program could not
be run without it. So one question might be, where does the language end and
the libraries begin? Are any/all of the default packages considered part of
the language? It seems hard to imagine doing anything at all without at
least 'base.' If I install R in the usual way with no other
packages/libraries can I release whatever I write under any license, or does
it have to be GPL compatible?

While I wouldn't expect R core to formulate formal legal opinions regarding
questions like these, it would be nice if there were some kind of "community
standards."

Ian

-Original Message-
From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-project.org]
On Behalf Of Marc Schwartz
Sent: Thursday, April 23, 2009 2:34 PM
To: Stavros Macrakis
Cc: Matthew Dowle; r-devel@r-project.org
Subject: Re: [Rd] Closed-source non-free ParallelR ?


On Apr 23, 2009, at 3:22 PM, Stavros Macrakis wrote:

> On Thu, Apr 23, 2009 at 1:25 PM, Marc Schwartz  
>  wrote:
>> On Apr 23, 2009, at 11:47 AM, Stavros Macrakis wrote:
>>>
>>> All that being said, the entity that must enforce these conditions  
>>> is
>>> not the FSF, but the copyright owner, in this case the R  
>>> Foundation...
>>> bundler. So it would be useful to know what the R Foundation's
>>> position is
>
>> Actually, the R Foundation has done what it is obligated to do,  
>> which is to
>> describe the license under which R is made available.
>
> I did not say that the R Foundation was obligated to give advice.  I
> said that it is up to the R Foundation to decide what cases it cares
> about, and it would be "useful to know" what that position is.
>
>> To ask the R Foundation for anything further is to ask them to  
>> render a legal
>> opinion, which is not in their expertise to offer.
>
> No, it is asking them what their *policy* is.  Their policy may or may
> not be enforceable
>
>> It is up to the prospective third party developer of an application  
>> that is
>> to use R to consult with lawyers to determine what *THEIR*  
>> obligations are
>> if they should elect to proceed.
>
> Yes, this is true.  But it is also true that if (for example) the R
> Foundation says officially that it interprets GPL to allow
> distributing proprietary packages along with R, then that is the
> interpretation that matters, since the R Foundation (not the FSF) is
> the copyright holder.
>
>> At this level, it is really pretty simple and a lot of these things  
>> are
>> covered in the GPL FAQs, including the reporting of violations.
>
> The GPL FAQs are the FSF's interpretation.  The R Foundation is not
> obliged to have the same interpretation, and of course the FSF cannot
> enforce licenses given by the R Foundation.

Underlying all of your comments seems to be a presumption that the R  
Foundation can disentangle themselves from the FSF vis-a-vis the GPL.

Keep in mind that it is the FSF that is the copyright holder of the GPL.

The R Foundation may be the copyright holder to R, but they are  
distributing it under a license which they did not write.

Thus, I cannot envision any reasonable circumstances under which the R  
Foundation would place themselves in a position of legal risk in  
deviating from the interpretations of the GPL by the FSF. It would be  
insane legally to do so.

The key issue is the lack of case law relative to the GPL and that  
leaves room for interpretation. One MUST therefore give significant  
weight to the interpretations of the FSF as it will likely be the FSF  
that will be involved in any legal disputes over the GPL and its  
application. You would want them on your side, not be fighting them.

A parallel here is why most large U.S. public corporations legally  
incorporate in the state of Delaware, even though they may not have  
any material physical presence in that state. It is because the  
overwhelming majority of corporate case law in the U.S. has been  
decided under the laws of Delaware and the interpretations of said  
laws. If I were to start a company (which I have done in the past) and  
feared that I should find myself facing litigation at some future  
date, I would want that huge database of case law behind me. A small  
company (such as I had) may be less concerned about this and be  
comfortable with the laws of their own state, which I was. But if I  
were to be looking to build a big company with investors, etc. and  
perhaps look to go public at a future date, you bet I would look to  
incorporate in Delaware. It would be the 

Re: [Rd] reference counting problem in .Primitive's?

[William Dunlap]

> -Original Message-
> From: l...@stat.uiowa.edu [mailto:l...@stat.uiowa.edu] 
> Sent: Thursday, April 23, 2009 11:06 AM
> To: William Dunlap
> Cc: r-devel@r-project.org
> Subject: Re: [Rd] reference counting problem in .Primitive's?
> 
> On Thu, 23 Apr 2009, William Dunlap wrote:
> 
> > I think the following rather wierd expressions show a problem in how
> > some of the .Primitive functions evaluate their arguments.  
> I haven't
> > yet thought of a way that a nonabusive user might run into 
> this problem.
> > In each case the first argument, x, is modified in the course of
> > evaluating the second argument and then modified x gets used
> > as the first argument:
> >
> >> x<-as.integer(1:5); y <- x + { x[3]<-33L ; 1L } ; y
> > [1]  2  3 34  5  6
> >> x<-2^(0:4) ; y <- log(x, { x[3]<-64 ; 2 }) ; y
> > [1] 0 1 6 3 4
> >
> > The reason I think it looks like a sharing problem (and not an order
> > of evaluation problem) is that if your modification to x 
> causes it to
> > use a new block of memory then the unmodified version of x gets
> > used as the first argument.  E.g.,
> >
> >> x<-as.integer(1:5) ; y <- x + { x[3]<-33.3; 1L} ; y
> > [1] 2 3 4 5 6
> >
> > I haven't yet thought of a way that a nonabusive user might run
> > into this problem.

An hour after writing this one of our support folks sent me some
user-written code that contained something very close to this idiom;
the second argument to ":" is an altered version of the first argument:

   lengths<-5:1 ; start<-1
   for(i in seq(along=lengths)) {
thisSeq <- start:((start <- start + lengths[i])-1)
print(thisSeq)
   }
   [1] 1 2 3 4 5
   [1] 6 7 8 9
   [1] 10 11 12
   [1] 13 14
   [1] 15

That works.  However, if that user had also used 'start[] <- ' instead
of 'start <- ' then they would have run into this bug:

  lengths<-5:1 ; start<-1
  for(i in seq(along=lengths)) {
thisSeq <- start:((start[] <- start + lengths[i])-1)
print(thisSeq)
  }
  [1] 1 2 3 4 5
  [1] 10  9
  [1] 13 12
  [1] 15 14
  [1] 16 15

If they use start[] or start[1] consistently in the call to ":" then
they
don't hit the bug.

> 
> You are probably right.  I have not yet looked at the code but am
> virtually certain it does not try to temporarily bump up the NAMED
> values on argument values.  Doing so would cure this but probably at
> serious cost to performance, as NAMED values of 2 cannot be brought
> down again and so cause copying on next modify. (Might be worth
> running some tests on that though to see what the cost would be).

So, if NAMED were not limited to 0,1,or 2 this sort of thing might be
avoided with less pain?

> I'm not sure if it is written anywhere that argunments of primitives
> (BUILTINS in articular as those are always strict; SPECIALS can be
> non-strict but log is strict) are evaluated in any particular order.
> All these examples are consistent with _some_ evaluation order, but
> not the same one.  It might be possible to show that the results
> obtained in these situations will always be consistent with some
> evaluation order, in which case documenting that order of evaluation
> is unspecified would be good enough form me.  It may also be possible
> that an order that does compound expressions first and then symbols
> would also solve the issue (I don't think I would want to do this in
> the interpreter though because of the performance overhead.)
> 
> luke
> 
> 
> >
> > Bill Dunlap
> > TIBCO Software Inc - Spotfire Division
> > wdunlap tibco.com
> >
> > __
> > R-devel@r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/r-devel
> >
> 
> -- 
> Luke Tierney
> Chair, Statistics and Actuarial Science
> Ralph E. Wareham Professor of Mathematical Sciences
> University of Iowa  Phone: 319-335-3386
> Department of Statistics andFax:   319-335-3017
> Actuarial Science
> 241 Schaeffer Hall  email:  l...@stat.uiowa.edu
> Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu
> 

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

Re: [Rd] reference counting problem in .Primitive's?

[luke]

On Thu, 23 Apr 2009, William Dunlap wrote:


-Original Message-
From: l...@stat.uiowa.edu [mailto:l...@stat.uiowa.edu]
Sent: Thursday, April 23, 2009 11:06 AM
To: William Dunlap
Cc: r-devel@r-project.org
Subject: Re: [Rd] reference counting problem in .Primitive's?

On Thu, 23 Apr 2009, William Dunlap wrote:


I think the following rather wierd expressions show a problem in how
some of the .Primitive functions evaluate their arguments.

I haven't

yet thought of a way that a nonabusive user might run into

this problem.

In each case the first argument, x, is modified in the course of
evaluating the second argument and then modified x gets used
as the first argument:


x<-as.integer(1:5); y <- x + { x[3]<-33L ; 1L } ; y

[1]  2  3 34  5  6

x<-2^(0:4) ; y <- log(x, { x[3]<-64 ; 2 }) ; y

[1] 0 1 6 3 4

The reason I think it looks like a sharing problem (and not an order
of evaluation problem) is that if your modification to x

causes it to

use a new block of memory then the unmodified version of x gets
used as the first argument.  E.g.,


x<-as.integer(1:5) ; y <- x + { x[3]<-33.3; 1L} ; y

[1] 2 3 4 5 6

I haven't yet thought of a way that a nonabusive user might run
into this problem.


An hour after writing this one of our support folks sent me some
user-written code that contained something very close to this idiom;
the second argument to ":" is an altered version of the first argument:

  lengths<-5:1 ; start<-1
  for(i in seq(along=lengths)) {
   thisSeq <- start:((start <- start + lengths[i])-1)
   print(thisSeq)
  }
  [1] 1 2 3 4 5
  [1] 6 7 8 9
  [1] 10 11 12
  [1] 13 14
  [1] 15

That works.  However, if that user had also used 'start[] <- ' instead
of 'start <- ' then they would have run into this bug:

 lengths<-5:1 ; start<-1
 for(i in seq(along=lengths)) {
   thisSeq <- start:((start[] <- start + lengths[i])-1)
   print(thisSeq)
 }
 [1] 1 2 3 4 5
 [1] 10  9
 [1] 13 12
 [1] 15 14
 [1] 16 15

If they use start[] or start[1] consistently in the call to ":" then
they
don't hit the bug.



Unless you know of somewhere where it is guaranteed that evaluation
order for : is left to right then this code is buggy.  (At one point I
either had or serously thought about having codetools warn about
assignments in arguments other than in a very limited number of
cases.)

As I said previously unless I can convince myself that the current
behavior isn't consistent with _some_ evaluation order in each case
(even if it changes with changes in expressions used) then I don't
think it is worth doing anything about other than explicitly stating
that evaluation order is undefined.





You are probably right.  I have not yet looked at the code but am
virtually certain it does not try to temporarily bump up the NAMED
values on argument values.  Doing so would cure this but probably at
serious cost to performance, as NAMED values of 2 cannot be brought
down again and so cause copying on next modify. (Might be worth
running some tests on that though to see what the cost would be).


So, if NAMED were not limited to 0,1,or 2 this sort of thing might be
avoided with less pain?


If we had full reference counting I think we could avoid this fairly
easily, but I'm not convinced it is worth avoiding as there are good
reasons to allow indeterminacy in order of evaluation (compiler
optimizations, parallelization, and such) and in any case going to
full reference counting is not realistic without a full rewrite of the
engine (and has its own potential performance issues).

luke


I'm not sure if it is written anywhere that argunments of primitives
(BUILTINS in articular as those are always strict; SPECIALS can be
non-strict but log is strict) are evaluated in any particular order.
All these examples are consistent with _some_ evaluation order, but
not the same one.  It might be possible to show that the results
obtained in these situations will always be consistent with some
evaluation order, in which case documenting that order of evaluation
is unspecified would be good enough form me.  It may also be possible
that an order that does compound expressions first and then symbols
would also solve the issue (I don't think I would want to do this in
the interpreter though because of the performance overhead.)

luke




Bill Dunlap
TIBCO Software Inc - Spotfire Division
wdunlap tibco.com

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



--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
Actuarial Science
241 Schaeffer Hall  email:  l...@stat.uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu





--
Luke Tierney
Chair, Statistics and Actuarial Science
Ralph E. Wareham Professor of Mathe

Re: [Rd] Closed-source non-free ParallelR ?

[Stavros Macrakis]

I said:
>> ...The GPL FAQs are the FSF's interpretation.  The R Foundation is not
>> obliged to have the same interpretation, and of course the FSF cannot
>> enforce licenses given by the R Foundation

On Thu, Apr 23, 2009 at 5:34 PM, Marc Schwartz  wrote:
> Underlying all of your comments seems to be a presumption that the R
> Foundation can disentangle themselves from the FSF vis-a-vis the GPL.
> Keep in mind that it is the FSF that is the copyright holder of the GPL.

Yes. The GPL itself is copyrighted.

> The R Foundation may be the copyright holder to R, but they are distributing
> it under a license which they did not write.

Yes. They chose to use a certain license.

> Thus, I cannot envision any reasonable circumstances under which the R
> Foundation would place themselves in a position of legal risk in deviating
> from the interpretations of the GPL by the FSF. It would be insane legally
> to do so.

I don't follow you here.  If the R Foundation chose not to enforce a
provision of the license in the way that the FSF thinks it ought to be
enforced, what exactly could the FSF do about it?  As far as I can
tell, the GPL does not make the FSF a party in licenses executed under
the GPL.

> The key issue is the lack of case law relative to the GPL and that leaves
> room for interpretation. One MUST therefore give significant weight to the
> interpretations of the FSF as it will likely be the FSF that will be
> involved in any legal disputes over the GPL and its application. You would
> want them on your side, not be fighting them.

You are discussing the courts' interpretation of the GPL, which is not
what I'm questioning here.

Let me give an analogy.  Suppose I buy a piece of property using a
standard form contract written by (and copyright by) my local real
estate agents' association (a common practice).  I then discover that
the seller had done something which according to the real estate
agents' association's interpretation of the contract entitled me to
$1 damages, but that seems unreasonable to me.  The particular
clause has never been litigated.  You seem to be claiming that (a) the
real estate agents' association's interpretation of the contract has
more weight than my interpretation of it and (b) that they can somehow
oblige me to sue for the $1 damages.  Now let's say someone else
goes to court and (with the legal support of the real estate agents'
association) prevails on that clause.  Now it is clear that the real
estate agents' association's interpretation can be enforced.  But I
still don't think it's reasonable to enforce it, and still don't
choose to sue.  You are claiming that they somehow can force me to?
Of course, it would be different if a real estate agent were also
party to the contract, and would be owed 20% of the $1.  But that
is not the case.

> Unfortunately, we have no such archive of case law yet of the GPL. Thus at
> least from a legally enforceable perspective, all is grey and the FSF has to
> be the presumptive leader here.

Whether the FSF's interpretation is legally enforceable or not, it is
the copyright holder who choses whether to sue, not the FSF.

-s

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

Re: [Rd] Closed-source non-free ParallelR ?

[Ted Harding]

On 23-Apr-09 22:21:45, Ian Fellows wrote:
> Assuming that the foundation does not want to deviate from the
> FSF interpretation, there would still be value in clarifying its
> position vis-à-vis how the license applies to R specifically. 

I think (see below) that I agree with this!

> For example the FSF foundation claims that linking to a library
> (even in an interpreted environment) makes your software derivative,
> and therefore must be distributed Freely. They also claim that
> simply executing a program in an interpreted (GPL'ed) environment
> is okay even though the program could not be run without it. So one
> question might be, where does the language end and the libraries
> begin?

As far as I Understand these things (and I think I use language
differently from lawyers), it seems to me that this view about
executing a program in an interpreted environment is reasonable.

For example, suppose I bought a commercial FORTRAN interpreter.
I write a program (plain text, of course) in standard FORTRAN.
Running this on the interpreter surely would not tie me into
any licensing issues arising from the rights of the seller of
the interpreter, and I feel sure I could re-distribute my raw
(test) FORTRAN code as I pleased without any infringement arising
from the fact that I had, myself, executed it on the interpreter.
Others (and I myself) could surely compile the program on some
other compiler, etc.

However, if that commercial interpreter also had a 'compile' option,
and I compiled my progrtam using that, then equally I feel sure
that the compiled version would be subject to whatever restrictions
had been placed on distirbution fo binaries so compiled. I think
those things are clear enough.

The interesting question arises if the commercial interpreter
also included some extension of standard FORTRAN which was unique
to that interpreter. I dare say I could pass a program which
included use of the extension to others without problems, on
thr grounds that they would have to obtain te same interpreter
in order to run it.

But now suppose that my having done this inspires someone to
incorporate the same language extension into a GPL'd FORTRAN
interpreter/compiler. I think I could then be vulnerable, or
they could, on the grounds that I/they had pinched the idea
from the commercial product.

And now (relevent to Ian's next point), maybe a similar principle
might be held to apply to R code which depends on R's use of GPL?
-- since people who write R code often use features of the code
which are peculiar to R. Or maybe the GPL doesn't inhibit you
from using *ideas* and *features* of GPL software, provided you
implement them yourself and in your own way? I dunno ...

Ted.
 
> Are any/all of the default packages considered part of
> the language? It seems hard to imagine doing anything at all without at
> least 'base.' If I install R in the usual way with no other
> packages/libraries can I release whatever I write under any license, or
> does
> it have to be GPL compatible?
> 
> While I wouldn't expect R core to formulate formal legal opinions
> regarding
> questions like these, it would be nice if there were some kind of
> "community
> standards."
> 
> Ian
> 
> -Original Message-
> From: r-devel-boun...@r-project.org
> [mailto:r-devel-boun...@r-project.org]
> On Behalf Of Marc Schwartz
> Sent: Thursday, April 23, 2009 2:34 PM
> To: Stavros Macrakis
> Cc: Matthew Dowle; r-devel@r-project.org
> Subject: Re: [Rd] Closed-source non-free ParallelR ?
> 
> 
> On Apr 23, 2009, at 3:22 PM, Stavros Macrakis wrote:
> 
>> On Thu, Apr 23, 2009 at 1:25 PM, Marc Schwartz  
>>  wrote:
>>> On Apr 23, 2009, at 11:47 AM, Stavros Macrakis wrote:

 All that being said, the entity that must enforce these conditions  
 is
 not the FSF, but the copyright owner, in this case the R  
 Foundation...
 bundler. So it would be useful to know what the R Foundation's
 position is
>>
>>> Actually, the R Foundation has done what it is obligated to do,  
>>> which is to
>>> describe the license under which R is made available.
>>
>> I did not say that the R Foundation was obligated to give advice.  I
>> said that it is up to the R Foundation to decide what cases it cares
>> about, and it would be "useful to know" what that position is.
>>
>>> To ask the R Foundation for anything further is to ask them to  
>>> render a legal
>>> opinion, which is not in their expertise to offer.
>>
>> No, it is asking them what their *policy* is.  Their policy may or may
>> not be enforceable
>>
>>> It is up to the prospective third party developer of an application  
>>> that is
>>> to use R to consult with lawyers to determine what *THEIR*  
>>> obligations are
>>> if they should elect to proceed.
>>
>> Yes, this is true.  But it is also true that if (for example) the R
>> Foundation says officially that it interprets GPL to allow
>> distributing proprietary packages along with R, then that is the
>> interpretation th

Re: [Rd] Closed-source non-free ParallelR ?

[Gabor Grothendieck]

On Thu, Apr 23, 2009 at 8:54 PM, Ted Harding
 wrote:
> On 23-Apr-09 22:21:45, Ian Fellows wrote:
>> Assuming that the foundation does not want to deviate from the
>> FSF interpretation, there would still be value in clarifying its
>> position vis-à-vis how the license applies to R specifically.
>
> I think (see below) that I agree with this!
>
>> For example the FSF foundation claims that linking to a library
>> (even in an interpreted environment) makes your software derivative,
>> and therefore must be distributed Freely. They also claim that
>> simply executing a program in an interpreted (GPL'ed) environment
>> is okay even though the program could not be run without it. So one
>> question might be, where does the language end and the libraries
>> begin?
>
> As far as I Understand these things (and I think I use language
> differently from lawyers), it seems to me that this view about
> executing a program in an interpreted environment is reasonable.
>
> For example, suppose I bought a commercial FORTRAN interpreter.
> I write a program (plain text, of course) in standard FORTRAN.
> Running this on the interpreter surely would not tie me into
> any licensing issues arising from the rights of the seller of
> the interpreter, and I feel sure I could re-distribute my raw
> (test) FORTRAN code as I pleased without any infringement arising
> from the fact that I had, myself, executed it on the interpreter.
> Others (and I myself) could surely compile the program on some
> other compiler, etc.
>
> However, if that commercial interpreter also had a 'compile' option,
> and I compiled my progrtam using that, then equally I feel sure
> that the compiled version would be subject to whatever restrictions
> had been placed on distirbution fo binaries so compiled. I think
> those things are clear enough.

Typically commercial compilers have royalty-free runtime
libraries so you can freely distribute software processed
with the compiler.  Similarly, In the free software world,
gcc has the gcc Runtime Library Exception to allow
commercial software to use gcc.
http://www.gnu.org/licenses/gcc-exception.html

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

Re: [Rd] License status of CRAN packages

[Greg Snow]

I don't know about the legal definitions of all, but a few years back the 
British Medical Journal had a filler article that looked at some surveys of 
what people thought different words meant (you can get at the filler by going 
to http://www.bmj.com/cgi/content/full/333/7565/442 and downloading the pdf 
version of the article then scrolling to the end).

According to this, when people say always they could mean anywhere from 91-100% 
of the time and when they say never it could be 0-2% of the time.

This doesn't prove anything, but I thought it was an interesting side note to 
the discussion.

-- 
Gregory (Greg) L. Snow Ph.D.
Statistical Data Center
Intermountain Healthcare
greg.s...@imail.org
801.408.8111


> -Original Message-
> From: r-devel-boun...@r-project.org [mailto:r-devel-boun...@r-
> project.org] On Behalf Of Dirk Eddelbuettel
> Sent: Thursday, April 23, 2009 3:05 PM
> To: Gabor Grothendieck
> Cc: Friedrich Leisch; Matthew Dowle; charles blundell; r-de...@r-
> project.org
> Subject: Re: [Rd] License status of CRAN packages
> 
> 
> On 23 April 2009 at 16:35, Gabor Grothendieck wrote:
> | Of the 31 packages listed:
> |  [1] "BARD"  "BayesDA"   "CoCo"  "ConvCalendar"
> |  [5] "FAiR"  "PTAk"  "RScaLAPACK""Rcsdp"
> |  [9] "SDDA"  "SGP"   "alphahull" "ash"
> | [13] "asypow""caMassClass"   "gpclib""mapproj"
> | [17] "matlab""mclust""mclust02"  "mlbench"
> | [21] "optmatch"  "rankreg"   "realized"  "rngwell19937"
> | [25] "rtiff" "rwt"   "scagnostics"   "sgeostat"
> | [29] "spatialkernel" "tlnise""xgobi"
> |
> | the license fields are AGPL or GPL for 3 and specified in a separate
> | file "file LICENSE" so about 30 of 1700 < 2% are question marks.
> 
> My point is that you currently need to manually parse 'file LICENSE'.
> 
> And as I said, we did not claim that our set was exhaustive, current or
> perfect. We just can't automate anything better given the current
> framework.
> And I think we all should be able to do better in scripted approaches.
> I
> still think you're proving my point.
> 
> | To me that is not inconsistent with all or nearly all being free
> software
> 
> I doubt that "all or nearly all" would equated to "exactly all" by a
> court. You only need one bad apple to spoil the lot.
> 
> Dirk
> 
> --
> Three out of two people have difficulties with fractions.
> 
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

Re: [Rd] Problems building R 2.9.0... on SGI and Sun once again

[Darin A. England]

Many thanks to Peter for the explanation. I found that the fix for
me was to set the environment variable R_SHELL to '/usr/bin/bash',
otherwise (on my AIX system at least) the shell being used was
/bin/sh. 
Darin


On Thu, Apr 23, 2009 at 10:54:31AM -0500, Darin England wrote:
> I have the same problem trying build R 2.9.0 on AIX using the IBM 
> Visual Age compilers and GNU make. I'm trying to figure it out, but
> any hints on a fix are greatly appreciated.
> Thanks,
> Darin
> 
> gmake[2]: Entering directory `/home/denglan/R/builddir/src/library/methods'
> building package 'methods'
> mkdir ../../../library/methods
> gmake[3]: Entering directory `/home/denglan/R/builddir/src/library/methods'
> mkdir ../../../library/methods/R
> /bin/sh: syntax error at line 1 : `;' unexpected
> gmake[3]: *** [front] Error 2
> gmake[3]: Leaving directory `/home/denglan/R/builddir/src/library/methods'
> gmake[2]: *** [all] Error 2
> gmake[2]: Leaving directory `/home/denglan/R/builddir/src/library/methods'
> gmake[1]: *** [R] Error 1
> gmake[1]: Leaving directory `/home/denglan/R/builddir/src/library'
> gmake: *** [R] Error 1
> make: The error code from the last command is 1.

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