Re: [R-pkg-devel] Licensing of an R package

[Chris Brien]

Hi Martyn,

Thanks for your very clear explanation. I now understand the point that Duncan 
was making.

However, just to clarify point 4). 

I understand that a GPL license means that I cannot distribute a binary that 
combines both asreml and asremlPlus, which asreml would not allow anyway. 

However, under a GPL license, can I distribute a binary of asremlPlus on its 
own as long as the source for asremlPlus is available, which it is from the 
same web site as the binary and from Github? I would have thought so because 
this is exactly what CRAN does in distributing Windows binaries of packages.

Cheers,

  Chris


-Original Message-
From: Martyn Plummer [mailto:plumm...@iarc.fr] 
Sent: Tuesday, 23 January 2018 4:26 AM
To: Chris Brien; e...@debian.org; murdoch.dun...@gmail.com
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Licensing of an R package

On Fri, 2018-01-19 at 20:28 +, Chris Brien wrote:
> Hi Dirk & Duncan,
> 
> I too like GPL and I had thought that the situation was as Duncan 
> outlines. Consequently, I had licensed `foo' as GPL >= 2.
> 
> However, because I have been unable to find a discussion of my case, 
> in spite of the extensive material about GNU licensing on the web, I 
> have had difficulty deciding whether or not I was mistaken in applying 
> a GPL license.
> 
> It does seem that the open source philosophy is that all software 
> should be open source and GPL licensing is to promote this, which it 
> does by restricting how you can apply GPL licensing. It would be 
> consistent with this philosophy that GPL does not allow one to `link'
> with a commercial package. However, somewhat reluctantly it seems, an 
> exception is made under GPL licensing  for linking to commercial 
> `system libraries' because it is necessary to allow this for things 
> like R etc.
> 
> If Bloomberg API is a system library then it also qualifies as an 
> exception. (I have seen the license file and note that you are able to 
> distribute the API.)
> 
> In my case `bar' is asreml and I don't believe that it qualifies as a 
> system library. However, I can use it to build my library
> (asremlPlus) and the maintainers and license owners know that I do 
> this. As a result I am still unsure that GPL can be applied in my 
> case.
> 
> Ugh! It is a minefield.

It is not as bad as you think. 

The FSF admits that sometimes you need to link to a non-free library.
They just ask you not to do it if a free replacement is available:
https://www.gnu.org/licenses/gpl-faq.en.html#FSWithNFLibs

As Duncan points out, your choice of license does not affect what you can do 
with it. As copyright holder, you can do what you like (modulo restrictions 
placed on you by the asreml license). The question is what rights you want to 
confer to other people.

GPL is based on copyright law, so the rights and obligations it confers come 
into effect only when the software is distributed (or "conveyed"
in the updated language of GPL 3) to a third party. These rights and 
obligations also apply to any derived works, which means both modified source 
code and binary packages created from the source code.

With a GPL license, anyone has the right to do the following with your 
asremlPlus package:

1) Distribute the source package.

2) Distribute modified versions of the source package under the same GPL 
conditions.

3) Install and use the asremlPlus package linked to the asreml library.
 

What they cannot do with a standard GPL license is:

4) Distribute a binary package of asremlPlus linked to asreml

Distributing a binary package of asremlPlus under the GPL comes with the 
obligation to provide the source code to asreml which, of course, cannot be 
done.

It should also be noted that the license terms of asreml itself may prevent 
distribution of a binary package of asremlPlus.

However, if there are no such restrictions then nothing prevents you as sole 
copyright holder from creating your own (dynamically linked) binaries and 
distributing them to your users.

If you do want to give your users rights to distribute binary packages then you 
may add an explicit exception to the GPL to your software license. The FSF 
provides a template to add this exception to your
license:

https://www.gnu.org/licenses/gpl-faq.en.html#GPLIncompatibleLibs

Martyn


> Thanks muchly for your input.
> 
> Cheers,
> 
>   Chris
> 
> 
> -Original Message-
> From: Dirk Eddelbuettel [mailto:dirk.eddelbuet...@gmail.com] On Behalf 
> Of Dirk Eddelbuettel
> Sent: Saturday, 20 January 2018 2:30 AM
> To: Duncan Murdoch
> Cc: Chris Brien; r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] Licensing of an R package
> 
> 
> Chris,
> 
> I am with Duncan here.
> 
> You can license _your_ package any way you want and prefer. I like 
> GPL.
> 
> You seem to imply that the GPL license prohibits linking against 
> commercial code.  If that were the case we'd never have R, Emacs, 
> gcc/g++, ... on Windows or macOS or any of the no

Re: [R-pkg-devel] [Rd] How to address the following: CRAN packages not using Suggests conditionally

[Ulrich Bodenhofer]

Thanks for your thoughts, Martin!
It's very easy for 'pictures of code' (unevaluated code chunks in 
vignettes) to drift from the actual implementation. So I'd really 
encourage your conditional evaluation to be as narrow as possible -- 
during CRAN or even CRAN fedora checks. Certainly trying to use 
uninstalled Suggest'ed packages in vignettes should provide an error 
message that is informative to users. Presumably the developer or user 
intends actually to execute the code, and needs to struggle through 
whatever issues come up.

I understand your point and I agree.
I'm not sure whether my comments are consistent with Writing R 
Extensions or not.
I doubt that. My understanding of the section "1.1.3.1 Suggested 
packages" is that conditional usage of suggested non-CRAN packages is 
more or less required.
There is a fundamental tension between the CRAN and Bioconductor 
release models. The Bioconductor 'devel' package repositories and 
nightly builds are meant to be a place where new features and breaking 
changes can be introduced and problems resolved before being exposed 
to general users as a stable 'release' branch, once every six months. 
This means that the Bioconductor devel branch periodically (as 
recently and I suspect over the next several days) contains 
considerable carnage that propagates to CRAN devel builds, creating 
additional work for CRAN maintainers.
I am aware of these different philosophies. Though I have an opinion 
about this matter, it is pointless which model I like better. As a 
developer, I have to respect the rules, period. It seems that I can 
avoid trouble by avoiding any dependency to Bioconductor in my CRAN 
packages. In the case of the 'apcluster' package, I deliberately chose 
trouble ;-)   because I think that exemplar-based clustering of 
biological sequences by means of sequence kernels is a very cool thing 
that users should be made aware of.


If I could make a wish to a fairy, I'd ask her to initiate a 
constructive discussion between the R Core Team and the Bioconductor 
Core Team to sort these things out, such that the "tensions" (as you 
have put it) are no longer left as a burden to the package developers.


Thanks and best regards,
Ulrich





On 01/22/2018 10:16 AM, Iñaki Úcar wrote:
Re-sending, since I forgot to include the list, sorry. I'm including 
r-package-devel too this time, as it seems more appropriate for this 
list.



El 22 ene. 2018 10:11, "Iñaki Úcar" > escribió:




    El 22 ene. 2018 8:12, "Ulrich Bodenhofer"
    mailto:bodenho...@bioinf.jku.at>> 
escribió:


    Dear colleagues, dear members of the R Core Team,

    This was an issue raised by Prof. Brian Ripley and sent
    privately to all developers of CRAN packages that suggest
    Bioconductor packages (see original message below). As
    mentioned in my message enclosed below, it was easy for me to
    fix the error in examples (new version not submitted to CRAN
    yet), but it might turn into a major effort for the warnings
    raised by the package vignette. Since I have not gotten any
    advice yet, I take the liberty to post it here on this list -
    hoping that we reach a conclusion here how to deal with this
    matter.


    Just disable code chunk evaluation if suggested packages are
    missing (see [1]). As explained by Prof. Ripley, it will only
    affect Fedora checks on r-devel, i.e., your users will still see
    fully evaluated vignettes on CRAN.

    [1] https://www.enchufa2.es/archives/suggests-and-vignettes.html


    Iñaki


    Thanks in advance for your kind assistance,
    Ulrich Bodenhofer



     Forwarded Message 
    Subject:        Re: CRAN packages not using Suggests 
conditionally

    Date:   Mon, 15 Jan 2018 08:44:40 +0100
    From:   Ulrich Bodenhofer mailto:bodenho...@bioinf.jku.at>>
    To:     Prof Brian Ripley mailto:rip...@stats.ox.ac.uk>>
    CC:     [...stripped for the sake of privacy ...]



    Dear Prof. Ripley,

    Thank you very much for bringing this important issue to my
    attention. I
    am the maintainer of the 'apcluster' package. My package 
refers to

    'Biostrings' in an example section of a help page (a quite
    insignificant
    one, by the way), which creates errors on some platforms. It
    also refers
    to 'kebabs' in the package vignette, which leads to warnings.

    I could fix the first, more severe, problem quite easily, (1)
    since it
    is relatively easy to wrap an entire examples section in a
    conditional,
    and (2), as I have mentioned, it is not a particularly
    important help page.

    Regarding the vignette, I want to ask for your advice now,
    since the
    situation appears more complicated to me. While it is, of
    course, only
 

[R-pkg-devel] new package? - Sports data from transfermarkt.com using rvest

[Kehl Dániel]

Dear List members,

maybe this is not the right place to ask, if that is the case, please forward 
me to the right place.
I developed some functions to download and transform football/soccer related 
data from transfermarkt.com.
There are plans to create my first package based on these functions and of 
course develop them and add more later. As far as I know there is no API to 
that page, so I am using the rvest package.
My question is: is this an OK thing to do? Should I contact transfermarkt.com? 
My german is not perfect (just like my english), this is what I've found on 
thier webpage. Does that mean one can not create a package related to that 
page? Or can't crawl at all? Or just not allowed to sell the data? If it is 
allowed, can one post the package on CRAN at the end?

Please if any of you have experience in that or just show me where to ask, do 
not hesitate!

LEGAL NOTICE
© Transfermarkt GmbH & Co. KG 2000-2018

All rights reserved.

Der Inhalt dieser Website ist urheberrechtlich geschützt. Nachdruck, Aufnahme 
in Online-Dienste, Internet und Vervielfältigung auf Datenträger wie CD-ROM, 
DVD-ROM usw. dürfen, auch auszugsweise, nur nach vorheriger schriftlicher 
Zustimmung durch Transfermarkt erfolgen. Eine kommerzielle Weitervermarktung 
des Inhalts ist untersagt.

Transfermarkt haftet nicht für unverlangt eingesandte Inhalte, Manuskripte und 
Fotos. Für Inhalte externer Links und fremde Inhalte übernimmt Transfermarkt 
keine Verantwortung.

Thank you for all your insights and/or comments,

best regards
Daniel





















Dr. KEHL Dániel

adjunktus





PÉCSI TUDOMÁNYEGYETEM KÖZGAZDASÁGTUDOMÁNYI KAR

Közgazdaságtan és Ökonometria Intézet

H-7622 Pécs, Rákóczi út 80. | www.ktk.pte.hu 

+36 72 501 599/ 23144 | ke...@ktk.pte.hu










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

Re: [R-pkg-devel] Licensing of an R package

[Martyn Plummer]

On Tue, 2018-01-23 at 08:28 +, Chris Brien wrote:
> Hi Martyn,
> 
> Thanks for your very clear explanation. I now understand the point
> that Duncan was making.
> 
> However, just to clarify point 4). 
> 
> I understand that a GPL license means that I cannot distribute a
> binary that combines both asreml and asremlPlus, which asreml would
> not allow anyway. 
> 
> However, under a GPL license, can I distribute a binary of asremlPlus
> on its own as long as the source for asremlPlus is available, which
> it is from the same web site as the binary and from Github? 

Nobody knows.

The GPL is based on a creative application of copyright law. Many
aspects of this application remain untested in court and thus remain
controversial. I will give you the two extremes of opinion.

In the red corner, the FSF claims that any form of linking creates a
derivative work of both your package and the asreml library. With this
interpretation, a dynamically linked package can only be distributed if
the terms of the GPL apply to the whole work, i.e. the terms extend to 
the asreml library. Since these terms cannot be satisfied, the binary
package cannot be distributed.

In the blue corner, Lawrence Rosen of the law firm Rosenlaw &
Einschlag, denies that linking creates a derived work, e.g.

http://www.linuxjournal.com/article/6366

The link is from 2003 but his position has not changed.

There is no algorithmic answer to this question. The answer depends on
human factors, the details of each specific case, and the
interpretation of existing copyright law in a given legal domain.

Even if you take the restrictive interpretation of the FSF, then they
don't have a problem with the distribution of dynamically linked
binaries if you put an explicit linking exception in your license,
which is why I pointed you to this in my previous email.

> I would have thought so because this is exactly what CRAN does in
> distributing Windows binaries of packages.

I would say that it is the responsibility of the package maintainer to
verify that CRAN is legally entitled to distribute Windows and MacOS
binaries. In any case, the vast majority of CRAN packages are not
problematic as they are licenced under GPL or a GPL-compatible license
without linkage to a non-free library.

Martyn

> Cheers,
> 
>   Chris
> 
> 
> -Original Message-
> From: Martyn Plummer [mailto:plumm...@iarc.fr] 
> Sent: Tuesday, 23 January 2018 4:26 AM
> To: Chris Brien; e...@debian.org; murdoch.dun...@gmail.com
> Cc: r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] Licensing of an R package
> 
> On Fri, 2018-01-19 at 20:28 +, Chris Brien wrote:
> > Hi Dirk & Duncan,
> > 
> > I too like GPL and I had thought that the situation was as Duncan 
> > outlines. Consequently, I had licensed `foo' as GPL >= 2.
> > 
> > However, because I have been unable to find a discussion of my
> > case, 
> > in spite of the extensive material about GNU licensing on the web,
> > I 
> > have had difficulty deciding whether or not I was mistaken in
> > applying 
> > a GPL license.
> > 
> > It does seem that the open source philosophy is that all software 
> > should be open source and GPL licensing is to promote this, which
> > it 
> > does by restricting how you can apply GPL licensing. It would be 
> > consistent with this philosophy that GPL does not allow one to
> > `link'
> > with a commercial package. However, somewhat reluctantly it seems,
> > an 
> > exception is made under GPL licensing  for linking to commercial 
> > `system libraries' because it is necessary to allow this for
> > things 
> > like R etc.
> > 
> > If Bloomberg API is a system library then it also qualifies as an 
> > exception. (I have seen the license file and note that you are able
> > to 
> > distribute the API.)
> > 
> > In my case `bar' is asreml and I don't believe that it qualifies as
> > a 
> > system library. However, I can use it to build my library
> > (asremlPlus) and the maintainers and license owners know that I do 
> > this. As a result I am still unsure that GPL can be applied in my 
> > case.
> > 
> > Ugh! It is a minefield.
> 
> It is not as bad as you think. 
> 
> The FSF admits that sometimes you need to link to a non-free library.
> They just ask you not to do it if a free replacement is available:
> https://www.gnu.org/licenses/gpl-faq.en.html#FSWithNFLibs
> 
> As Duncan points out, your choice of license does not affect what you
> can do with it. As copyright holder, you can do what you like (modulo
> restrictions placed on you by the asreml license). The question is
> what rights you want to confer to other people.
> 
> GPL is based on copyright law, so the rights and obligations it
> confers come into effect only when the software is distributed (or
> "conveyed"
> in the updated language of GPL 3) to a third party. These rights and
> obligations also apply to any derived works, which means both
> modified source code and binary packages created from the source
> code.
> 
>

Re: [R-pkg-devel] Licensing of an R package

[Chris Brien]

Hi Martyn,

OK. This last point was what had worried me about GPL all along. I had 
understood that you can only dynamically link to a system library. That is, 
that the red corner view applied.

Thanks for all your help. I now feel better equipped to make a decision on what 
course of action to take.

Cheers,

  Chris


-Original Message-
From: Martyn Plummer [mailto:plumm...@iarc.fr] 
Sent: Wednesday, 24 January 2018 4:20 AM
To: Chris Brien; e...@debian.org; murdoch.dun...@gmail.com
Cc: r-package-devel@r-project.org
Subject: Re: [R-pkg-devel] Licensing of an R package

On Tue, 2018-01-23 at 08:28 +, Chris Brien wrote:
> Hi Martyn,
> 
> Thanks for your very clear explanation. I now understand the point
> that Duncan was making.
> 
> However, just to clarify point 4). 
> 
> I understand that a GPL license means that I cannot distribute a
> binary that combines both asreml and asremlPlus, which asreml would
> not allow anyway. 
> 
> However, under a GPL license, can I distribute a binary of asremlPlus
> on its own as long as the source for asremlPlus is available, which
> it is from the same web site as the binary and from Github? 

Nobody knows.

The GPL is based on a creative application of copyright law. Many
aspects of this application remain untested in court and thus remain
controversial. I will give you the two extremes of opinion.

In the red corner, the FSF claims that any form of linking creates a
derivative work of both your package and the asreml library. With this
interpretation, a dynamically linked package can only be distributed if
the terms of the GPL apply to the whole work, i.e. the terms extend to 
the asreml library. Since these terms cannot be satisfied, the binary
package cannot be distributed.

In the blue corner, Lawrence Rosen of the law firm Rosenlaw &
Einschlag, denies that linking creates a derived work, e.g.

http://www.linuxjournal.com/article/6366

The link is from 2003 but his position has not changed.

There is no algorithmic answer to this question. The answer depends on
human factors, the details of each specific case, and the
interpretation of existing copyright law in a given legal domain.

Even if you take the restrictive interpretation of the FSF, then they
don't have a problem with the distribution of dynamically linked
binaries if you put an explicit linking exception in your license,
which is why I pointed you to this in my previous email.

> I would have thought so because this is exactly what CRAN does in
> distributing Windows binaries of packages.

I would say that it is the responsibility of the package maintainer to
verify that CRAN is legally entitled to distribute Windows and MacOS
binaries. In any case, the vast majority of CRAN packages are not
problematic as they are licenced under GPL or a GPL-compatible license
without linkage to a non-free library.

Martyn

> Cheers,
> 
>   Chris
> 
> 
> -Original Message-
> From: Martyn Plummer [mailto:plumm...@iarc.fr] 
> Sent: Tuesday, 23 January 2018 4:26 AM
> To: Chris Brien; e...@debian.org; murdoch.dun...@gmail.com
> Cc: r-package-devel@r-project.org
> Subject: Re: [R-pkg-devel] Licensing of an R package
> 
> On Fri, 2018-01-19 at 20:28 +, Chris Brien wrote:
> > Hi Dirk & Duncan,
> > 
> > I too like GPL and I had thought that the situation was as Duncan 
> > outlines. Consequently, I had licensed `foo' as GPL >= 2.
> > 
> > However, because I have been unable to find a discussion of my
> > case, 
> > in spite of the extensive material about GNU licensing on the web,
> > I 
> > have had difficulty deciding whether or not I was mistaken in
> > applying 
> > a GPL license.
> > 
> > It does seem that the open source philosophy is that all software 
> > should be open source and GPL licensing is to promote this, which
> > it 
> > does by restricting how you can apply GPL licensing. It would be 
> > consistent with this philosophy that GPL does not allow one to
> > `link'
> > with a commercial package. However, somewhat reluctantly it seems,
> > an 
> > exception is made under GPL licensing  for linking to commercial 
> > `system libraries' because it is necessary to allow this for
> > things 
> > like R etc.
> > 
> > If Bloomberg API is a system library then it also qualifies as an 
> > exception. (I have seen the license file and note that you are able
> > to 
> > distribute the API.)
> > 
> > In my case `bar' is asreml and I don't believe that it qualifies as
> > a 
> > system library. However, I can use it to build my library
> > (asremlPlus) and the maintainers and license owners know that I do 
> > this. As a result I am still unsure that GPL can be applied in my 
> > case.
> > 
> > Ugh! It is a minefield.
> 
> It is not as bad as you think. 
> 
> The FSF admits that sometimes you need to link to a non-free library.
> They just ask you not to do it if a free replacement is available:
> https://www.gnu.org/licenses/gpl-faq.en.html#FSWithNFLibs
> 
> As Duncan points out, your choice of lic

Re: [R-pkg-devel] CRAN and packages bundling third party C/C++ code

[Kevin Ushey]

For the record, some package authors whose packages depend on
RcppParallel  have had their new submissions accepted to CRAN, so I
suppose part of the answer is "explain it to the maintainers and
they'll understand".

However, a response from the CRAN team regarding how I should handle
these warnings emitted myself from TBB would still be appreciated (for
myself and other package authors who might want to embed 3rd party
code in their packages).

Thanks,
Kevin

On Thu, Jan 18, 2018 at 11:19 AM, Kevin Ushey  wrote:
>
> Hi,
>
> This is mostly a question for the CRAN team, but I figured posting here would 
> be best since other package maintainers could see the responses as well.
>
> I'm currently in the process of preparing a submission of RcppParallel to 
> CRAN. RcppParallel bundles Intel's Threading Building Blocks 
> (https://www.threadingbuildingblocks.org/) and builds + installs it alongside 
> the package.
>
> However, the TBB sources themselves do a lot of things that trip up R CMD 
> check + versions of R compiled with sanitizers, which are mostly out of my 
> control. For example, some UBSAN errors are emitted here:
>
> https://www.stats.ox.ac.uk/pub/bdr/memtests/clang-UBSAN/RcppParallel/tests/doRUnit.Rout
>
> Executing test function test.distance  ... 
> /data/gannet/ripley/R/packages/tests-clang-SAN/RcppParallel.Rcheck/RcppParallel/include/tbb/task.h:721:30:
>  runtime error: member call on address 0x7fbf31e93d00 which does not point to 
> an object of type 'tbb::internal::scheduler'
> 0x7fbf31e93d00: note: object is of type 
> 'tbb::internal::custom_scheduler'
>  00 00 00 00  a8 ab 76 32 bf 7f 00 00  00 00 00 00 00 00 00 00  00 00 00 00 
> 00 00 00 00  80 ff c9 31
>   ^~~
>   vptr for 
> 'tbb::internal::custom_scheduler'
> SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior 
> /data/gannet/ripley/R/packages/tests-clang-SAN/RcppParallel.Rcheck/RcppParallel/include/tbb/task.h:721:30
>  in
>
> This occurs, as far as I can tell, because TBB sidesteps typical C++ object 
> construction for some objects: instead, it allocates some memory, then casts 
> it to some required type. As an example,
>
> https://github.com/RcppCore/RcppParallel/blob/603d1aa6f340668e34f5f490438967489edc9197/src/tbb/src/tbb/scheduler.cpp#L322-L328
>
> While this is 'wrong', it also 'works'. What am I, as a package maintainer, 
> supposed to do in this situation? To make things worse, this UBSAN warning 
> unfortunately affects all client packages of RcppParallel as well, as this 
> warning is triggered by code ran by RcppParallel on load / startup. Do other 
> package maintainers just need to say, "sorry, that's RcppParallel's fault"?
>
> In addition, TBB itself suppresses a number of compiler diagnostics 
> deliberately -- for example,
>
> https://github.com/RcppCore/RcppParallel/blob/603d1aa6f340668e34f5f490438967489edc9197/inst/include/tbb/flow_graph_opencl_node.h#L1234-L1252
>
> https://github.com/RcppCore/RcppParallel/blob/603d1aa6f340668e34f5f490438967489edc9197/src/tbb/include/tbb/tbb_machine.h#L666-L674
>
> Presumedly, TBB does this because they know what they're doing and the 
> compiler diagnostic will not be useful within this region of code. However, 
> this also triggers R CMD check warnings. What should I do here -- just 
> explain the case to CRAN? Patch TBB to allow the compiler diagnostics to flow 
> through?
>
> The more general question here -- what should package authors do when 
> third-party code bundled in the package emits compiler warnings?
>
> Thanks,
> Kevin

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

[R-pkg-devel] Working with R-devel

[Dirk Eddelbuettel]

I am going in circles here and have lost my way. I used to have means to
build R-devel (still do) and use it for local testing (no longer do).

 - Fresh build of R-devel
 - One entry in .libPaths()
 - I can install Rcpp, it ends up in that .libPaths()
 - I can load
 - With the _exact same settings_ starting R as R CMD check ... I fail on

   ** preparing package for lazy loading
   Error : package ‘Rcpp’ was installed by an R version with different 
internals; \
   it needs to be reinstalled for use with this R version

which is both false (see above) and irritating.

Does anybody have any tips, working guidelines or interpretations of the ever
changing manuals (which charmingly never document what changes) ?

Dirk

-- 
http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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