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.
