Hi,
Regarding the openssl dependency issue, the standard way people
justify getting around it is the "system library exemption", which
allows for GPL'd programs to link in system libraries that are not
GPL'd (otherwise, things like GPL software on MS Windows would be
impossible!). Some links here:
http://opensource.stackexchange.com/questions/2233/gpl-v3-with-openssl-exception
As the person who chose to add R to Sage in the first place, my
instinct on this is that we should **completely and totally remove R
from Sage**. Why?
- Our pexpect based interface to R sucks. It was mostly written by
Mike Hansen and me, so I take the blame. In SageMathCloud Sage
worksheets
we just switched to making the %r mode be implemented using Jupyter's
R kernel, which is way more robust.
- It's easy enough to install R in other ways outside of Sage.
I've heard of a lot of people installing Sage in order to install X
(where X is say Pari or Singular or even Cython at one point); I've
*never* heard of anybody installing Sage in order to get R.
- The main technical reason for installing R into Sage, as opposed
to just finding a system-wide R install, is to ensure that rpy2 -- the
C-level bindings to R -- actually work. However, in retrospect, I
don't think rpy2 is really that great.
- Python stats have come a *LONG* way in the last 10 years, with
libraries like Pandas. Why use rpy2 when you can much more
effectively use pandas and statsmodels and so on.
In my opinion, it would be way, way better to completely remove R from
Sage and instead do the following:
1. Include the R jupyter kernel config files.
2. Includes the modern Python stats libraries pandas and
statsmodels in Sage.
Our time would be much better spent supporting 2 than 1. It's
ridiculous that we spend no effort on pandas/statsmodels, and all this
effort on R. That was a strategy that made sense 10 years ago, but
not today.
For example, I recall that there are some issues involving pandas +
statsmodels + the sage preparser. We could put effort into
addressing those, like Robert Bradshaw did with numpy (which used to
be very unhappy with Sage integers, reals, etc.). Fixing this stuff
probably wouldn't be hard, and would make Sage a better environment
for stats. There may be similar remarks around machine learning,
where Python has really come into its own recently (e.g., see
tensorflow).
Anyway, just my two cents. But if anybody was out there wanting to
propose something similar, but worried that the person who included R
in Sage in the first place would be really annoyed -- fear not.
-- William
On Fri, Oct 28, 2016 at 6:39 AM, Emmanuel Charpentier
<emanuel.charpent...@gmail.com> wrote:
> My thoughts so far :
>
> I : Is there really a problem ?
> =====================
>
> What all the brouhaha around libcurl boils down to is that there *might* be
> a (pseudo)-legal difficulty in shipping a libcurl liibrary requiring OpenSSL
> and a GPL-licensed piece of software *in the same package*. This might be a
> part of the reasons for the R core team to have thrown the towel on this
> (but probably only patr of the reason : they alo threw the towel on xz an
> pcre, which do not give the same headache).
>
> However, this does not seem to be a problem per se : Debian (one of the most
> nitpicking distros in terms of licensing) happily ships libraries and
> utilities (such as cups, for starter) linked with openssl-linked libcurl. I
> think that it would be interesting to ask them how they reconcile the
> (inconsistent) wordings of the licenses involved.
>
> According to their answer, we might have an easy way out : hide behind the
> same legal curtain as Debian (it remains to see what it is...), package
> libcurl (essentially done) and silently ship it with Sage (it remains to
> check if other libraries are not more or less silently involved in the
> support of https: in libcurl, in which case we might have to use them also).
> This is option :
>
> a) Do nothing :
> --------------------
>
> II ? If there is really a problem, what can we do ?
> ===================================
>
> We might also bite the bullet, modify our licensing terms to add the
> advertising clause required by openssl's license and ship openly libcurl.
> Tha requires, it seems, explicit permission of all the people havng
> contributed to Sage, which might prove a difficult (impossble ?) task. That
> gives us option :
>
> b) Acknowledge libcurl
> ---------------------------------
>
> We can also emulate the R core team, throw the towel and simply add (an
> https-capable) libcurl to our initial requirements in README.md, possibly
> other places), leaving the user with the responsibility of installing it.
> This is option :
>
> c) Throw the towel
> ---------------------------
>
> Another possibility in the same vein is to throw the whole linen cabinet :
> instead of placing on user's shoulders the responsibility of finding
> libcurl, we might leave it the responsibility of installing R. This is made
> possible by the fact that R is now largely stable, with well-documented
> interfaces and few changes, therefore standardizable. A review of *all* the
> points of exchange between R and other parts of Sage would be necessary to
> check what is to be supported. As far as I know, R is sparsely used in "the
> rest of Sage. This is option :
>
> d) Excise R kernel
> ---------------------------
>
> At that point, one might wonder if R should remain a standard part of Sage.
> Dropping the requirement for T and making R interfaces an optional part of
> Sage might also be a solution. But this is possible if and only if the code
> review necessary to Sage excision shows no use of R's capabilities in other
> standard part of Sage. This is option :
>
> e) Excise R interfaces
> --------------------------------
>
> I think that we can forget about creating a network-deprived R : the
> resulting loss of functionality is so massive that it would become almost
> useless (to people having a use for R, that is...). I have to add that I
> would fight such a "solution"...
>
> III : Pros and contras
> ------------------------------
>
> "Throw the towel" is the laziest option : a few lines of not hard-to-write
> documentation in a few (harder-to-find ?) places. It buys us nothing in
> terms of functionality. And leaves us with the responsibility of updating R
> (a not-so-insignificant task) and large sources, libraries and executables.
>
> "Do nothing" is (almost but not quite) as lazy: porting libcurl is
> essentially done ; it remains to check if other libraries are required to
> build an https:-capable libcurl. No other benefits.
>
> "Acknowledge libcurl" seems almost infeasible, due to the necessity to hunt
> all the past and present Sage contributors. It would be otherwise the
> cleanest solution in the eyes of legal-oriented people.
>
> "Excise R kernel" needs a serious bit of work. But it would have its points
> : document all the uses of R from other parts of Sage, forcing the
> documentation of these uses, etc... It would also lighten the maintenance of
> Sage. However, we would be exposed to brutal loss of functionality if/when R
> changes without warning. Furthermore, paranoid users (such as me :-) would
> not have to maintain "system" and "Sage" installations of R (not a small
> task with litteraly thousands of R packages available...).
>
> "Excise R interfaces" is probably easy to do (modulo the code review
> necessary to excision) ; in my not so humble opinion, it would be a serious
> loss of interest for me and, more generally, a catastrophic mistake in
> communication : R has been part of Sage since version 3.0 (2008) (if
> Wikipedia is to be believed), and it would be the first ever *intentional*
> loss of functionality of Sage. Furthermore, I am a bit skeptic about R
> interfaces maintenance if they ever becom an optional part of Sage : even
> the (Sage) notebook, which is pretty central, has attracted cruft to the
> point of becoming unmaintainable...
>
> My short-sighted laziness would go to "Throw the towel" ; my long-term
> laziness would choose "Excise R kernel" (it could be the former now, the
> latter afterwards). However, notwithstanding its drawbacks, "do nothing" is
> almost done.
>
> What do you think ?
>
> --
> Emmanuel Charpentier
>
> --
> 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.
--
William (http://wstein.org)
--
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.
