On Thursday, October 27, 2016 at 12:22:37 PM UTC+2, Emmanuel Charpentier wrote: > > I'm afraid that we don't have much say in the matter : the R core > development team has choosen to rely on curl, and their build system will > fail without it. Furthermore, among those 9402 packages, a lot of them may > have choosen to follow R "guidance" an use CURL. > > If we choose to use another library, we are effectively forking R and a > $#!+load of those packages. Somehow, I doubt that we have the workforce to > do that credibly... > > So, before coming to these extremities, I'd like to explore two avenues : > Question the R Core Team to know how they reconcile their DPL 2-3 license > and teir use of OpenSSL, and discuss if we can use the same loophole as > they did. In which case, all is fine and dandy... > I don't know how much they thought about it, or rather how many lawyers they did pay, but if they ship binaries including the libcurl and openssl that might be risky. Some people invoke the special exception clause of the GPL... See: * https://people.gnome.org/~markmc/openssl-and-the-gpl.html * https://groups.google.com/forum/#!searchin/sage-devel/openssl|sort:relevance/sage-devel/mbGbpRz96q0/8nsKRNyLs3oJ (OpenSSL license issue) * https://groups.google.com/forum/#!searchin/sage-devel/openssl|sort:relevance/sage-devel/Jl11JxIb2E8/-1NrQmjbMKIJ (why GnuTLS which is GPL is not a drop in replacement
If they rely on the user having its own libcurl and openssl then there is no problem. > Excise R *proprio dictu* and keep the R interface(s) as optional, > reworking them to use an externally-installed R. And get rid of the damn > beast... > > What do you think ? > > Le jeudi 27 octobre 2016 12:11:43 UTC+2, François a écrit : >> >> My own examination of R-3.3.1 configure script is that configure will >> fail if libcurl 7.28+ is not present or present with ssl disabled >> [m4/R.m4 line 4215 thereafter]. >> Unless the code for `install.package` has significantly changed between >> 3.2.x and 3.3.x it is an unnecessary failure dictated by an unwillingness >> to have to support the alternatives. i.e.. not needing to explain what to >> do in when libcurl is not present or without ssl support. >> I doubt that >> install.package(“$some_package”,method=“$somemethod”) >> where $somemethod is CURL (command line) or WGET has disappeared. >> The R-3.2.1 package for RH7.1/centos7.1 is not compiled against libcurl >> or lack https support for example. An interesting experience I had at >> work >> today with a user. >> >> François >> >> > On 27/10/2016, at 22:49, Jean-Pierre Flori <jpf...@gmail.com> wrote: >> > >> > >> > >> > On Thursday, October 27, 2016 at 11:41:20 AM UTC+2, Jeroen Demeyer >> wrote: >> > On 2016-10-27 11:29, Francois Bissey wrote: >> > > R package system include downloading facility from repositories. >> > >> > That's fine but it should be possible to just run R without it's >> > packaging system. >> > Then I suggest a new solution: >> > [666] : >> > * patch R if curl (with https support) is not there and make curl an >> optional package, >> > * not patch R if curl (with https support) is ther. >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "sage-devel" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to sage-devel+...@googlegroups.com. >> > To post to this group, send email to sage-...@googlegroups.com. >> > Visit this group at https://groups.google.com/group/sage-devel. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
