A couple R tickets need review.

[Emmanuel Charpentier]

Inspired by an ask.sagemath question, Trac#23980 adds a couple usage hints to the r<tab> help text. This very minor patch is unproblematic.

Trac#24026, on the other hand, upgrades R to the last current version. As usual, special attention is needed on our problem children of platforms (namely Mac OS X and Erik's Cygwin-64 port).

All our current patches have been rebased against the current version ; no new patch is needed on Debian. However, I still have doubts about our decision to lift upstream's requirement of an https-enabled version of the SSL libraries (meaning OpenSSL, nowadays...). Does the ongoing OpenSSL's change of license change this situation (and our decision) ?

On Debian testing, both patches pass ptestlong with no failures whatsoever. R sort-of passes its own test suite (i. e. I get a couple of expected, announced failures, analogous to what we get with Python's test suite).

--

Emmanuel Charpentier

[William Stein]

On Sun, Oct 15, 2017 at 11:40 AM Emmanuel Charpentier <emanuel.c...@gmail.com> wrote:

Inspired by an ask.sagemath question, Trac#23980 adds a couple usage hints to the r<tab> help text. This very minor patch is unproblematic.

Trac#24026, on the other hand, upgrades R to the last current version. As usual, special attention is needed on our problem children of platforms (namely Mac OS X and Erik's Cygwin-64 port).

All our current patches have been rebased against the current version ; no new patch is needed on Debian. However, I still have doubts about our decision to lift upstream's requirement of an https-enabled version of the SSL libraries (meaning OpenSSL, nowadays...). Does the ongoing OpenSSL's change of license change this situation (and our decision) ?

Some history:

- Around 8 or so years ago I included OpenSSL in Sage -- we shipped with it for a few weeks.

- A student in one my classes pointed out the license problem, and then I spent an epic and miserable amount of time switching to the GNU alternatives to OpenSSL, which we shipped with Sage.

- Time passed...

- The OpenSSL project realized their license sucks this year.

- I think OpenSSL has still NOT yet relicensed, although they are trying hard to do so.

- OpenSSL might fail to relicense; e.g., the ZeroMQ project has been trying to switch from LGPL to MPLv2 for year(s) now, and can't seem to do so.  This ZeroMQ license is a major problem for use of Jupyter by certain companies that don't want to use LGPL code internally.

- OpenSSL might succeed at relicensing, e.g., NetworkX was GPL licensed, and really wanted to be BSD licensed -- they made a post saying something kind of like "we are going to relicense in a week or two; if you're an author and have a problem with this, let us know ASAP." And they relicensed. Done.

- GPL has a "you can link against GPL-incompatible system libraries" exemption (otherwise GPL software couldn't run on Windows, say), and sometimes I hope this would apply to components of Sage linking against OpenSSL, as long that OpenSSL isn't included in Sage.   

My gut feeling on this:

- We should either require OpenSSL be installed systemwide or  just ship OpenSSL with Sage.  Security is way, way too important to expose our users to potentially major security problems just because we're overly worried about license issues.  Moreover, I think there is no way the OpenSSL copyright owners are going to sue us for violating their funny license by including it in a GPLv3+ program, especially after announcing an intention to switch to MPLv2, and getting most OpenSSL devs to sign off on that.    

** By not just fully supporting and requiring OpenSSL for everything in Sage, we are exposing all Sage users to an increased chance of installing malicious software from repos. Let's not do that. **

In retrospect, I wish I had never removed OpenSSL from Sage.

 -- William

On Debian testing, both patches pass ptestlong with no failures whatsoever. R sort-of passes its own test suite (i. e. I get a couple of expected, announced failures, analogous to what we get with Python's test suite).

--

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+...@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.

--

-- William Stein

[Dima Pasechnik]

On Sunday, October 15, 2017 at 7:57:43 PM UTC+1, William wrote:

On Sun, Oct 15, 2017 at 11:40 AM Emmanuel Charpentier <emanuel.c...@gmail.com> wrote:

Inspired by an ask.sagemath question, Trac#23980 adds a couple usage hints to the r<tab> help text. This very minor patch is unproblematic.

Trac#24026, on the other hand, upgrades R to the last current version. As usual, special attention is needed on our problem children of platforms (namely Mac OS X and Erik's Cygwin-64 port).

All our current patches have been rebased against the current version ; no new patch is needed on Debian. However, I still have doubts about our decision to lift upstream's requirement of an https-enabled version of the SSL libraries (meaning OpenSSL, nowadays...). Does the ongoing OpenSSL's change of license change this situation (and our decision) ?

Some history:

- Around 8 or so years ago I included OpenSSL in Sage -- we shipped with it for a few weeks.

- A student in one my classes pointed out the license problem, and then I spent an epic and miserable amount of time switching to the GNU alternatives to OpenSSL, which we shipped with Sage.

- Time passed...

- The OpenSSL project realized their license sucks this year.

- I think OpenSSL has still NOT yet relicensed, although they are trying hard to do so.

- OpenSSL might fail to relicense; e.g., the ZeroMQ project has been trying to switch from LGPL to MPLv2 for year(s) now, and can't seem to do so.  This ZeroMQ license is a major problem for use of Jupyter by certain companies that don't want to use LGPL code internally.

- OpenSSL might succeed at relicensing, e.g., NetworkX was GPL licensed, and really wanted to be BSD licensed -- they made a post saying something kind of like "we are going to relicense in a week or two; if you're an author and have a problem with this, let us know ASAP." And they relicensed. Done.

- GPL has a "you can link against GPL-incompatible system libraries" exemption (otherwise GPL software couldn't run on Windows, say), and sometimes I hope this would apply to components of Sage linking against OpenSSL, as long that OpenSSL isn't included in Sage.

Some soft, notable wget, have an exception clause, needed for binary installs.

See https://en.wikipedia.org/wiki/Wget

Additional permission under GNU GPL version 3 section 7

If you modify this program, or any covered work, by linking or combining it with the OpenSSL project's OpenSSL library (or a modified version of that library), containing parts covered by the terms of the OpenSSL or SSLeay licenses, the Free Software Foundation grants you additional permission to convey the resulting work. Corresponding Source for a non-source form of such a combination shall include the source code for the parts of OpenSSL used as well as that of the covered work.

Can we include something like this in the license and be done with?

 

Dima

[Emmanuel Charpentier]

Le dimanche 15 octobre 2017 20:57:43 UTC+2, William a écrit :

On Sun, Oct 15, 2017 at 11:40 AM Emmanuel Charpentier <emanuel.c...@gmail.com> wrote:

Inspired by an ask.sagemath question, Trac#23980 adds a couple usage hints to the r<tab> help text. This very minor patch is unproblematic.

Trac#24026, on the other hand, upgrades R to the last current version. As usual, special attention is needed on our problem children of platforms (namely Mac OS X and Erik's Cygwin-64 port).

All our current patches have been rebased against the current version ; no new patch is needed on Debian. However, I still have doubts about our decision to lift upstream's requirement of an https-enabled version of the SSL libraries (meaning OpenSSL, nowadays...). Does the ongoing OpenSSL's change of license change this situation (and our decision) ?

Some history:

- Around 8 or so years ago I included OpenSSL in Sage -- we shipped with it for a few weeks.

- A student in one my classes pointed out the license problem, and then I spent an epic and miserable amount of time switching to the GNU alternatives to OpenSSL, which we shipped with Sage.

- Time passed...

- The OpenSSL project realized their license sucks this year.

- I think OpenSSL has still NOT yet relicensed, although they are trying hard to do so.

- OpenSSL might fail to relicense; e.g., the ZeroMQ project has been trying to switch from LGPL to MPLv2 for year(s) now, and can't seem to do so.  This ZeroMQ license is a major problem for use of Jupyter by certain companies that don't want to use LGPL code internally.

- OpenSSL might succeed at relicensing, e.g., NetworkX was GPL licensed, and really wanted to be BSD licensed -- they made a post saying something kind of like "we are going to relicense in a week or two; if you're an author and have a problem with this, let us know ASAP." And they relicensed. Done.

- GPL has a "you can link against GPL-incompatible system libraries" exemption (otherwise GPL software couldn't run on Windows, say), and sometimes I hope this would apply to components of Sage linking against OpenSSL, as long that OpenSSL isn't included in Sage.   

My gut feeling on this:

- We should either require OpenSSL be installed systemwide or  just ship OpenSSL with Sage.  Security is way, way too important to expose our users to potentially major security problems just because we're overly worried about license issues.  Moreover, I think there is no way the OpenSSL copyright owners are going to sue us for violating their funny license by including it in a GPLv3+ program, especially after announcing an intention to switch to MPLv2, and getting most OpenSSL devs to sign off on that.    

** By not just fully supporting and requiring OpenSSL for everything in Sage, we are exposing all Sage users to an increased chance of installing malicious software from repos. Let's not do that. **

I fully agree. Other respectable Sage developers don't... Previous efforts to raise a consensus on this point have failed. Should a formal vote be taken ?

I add that I'm not sure that the CRAN network will maintain its http repositories when it's https-enabled network is complete... An that's but a part of a larger movement towards a (somewhat) more secured Web.

--

Emmanuel Charpentier

[Emmanuel Charpentier]

Le dimanche 15 octobre 2017 21:24:28 UTC+2, Dima Pasechnik a écrit :

[ Snip... ]

Some soft, notable wget, have an exception clause, needed for binary installs.

See https://en.wikipedia.org/wiki/Wget

Additional permission under GNU GPL version 3 section 7

If you modify this program, or any covered work, by linking or combining it with the OpenSSL project's OpenSSL library (or a modified version of that library), containing parts covered by the terms of the OpenSSL or SSLeay licenses, the Free Software Foundation grants you additional permission to convey the resulting work. Corresponding Source for a non-source form of such a combination shall include the source code for the parts of OpenSSL used as well as that of the covered work.

Can we include something like this in the license and be done with?

Seconded. It would be nice if a *real* lawyer (US by preference, only country on Earth where such legaloidstic nonsense can be taken seriously...) could give us (pro bono, of course...)  advice on the wording.

But that's the easy part of the task. The hard one is to persuade dissenters... after hearing and understanding their points.

--

Emmanuel Charpentier

[William Stein]

On Sun, Oct 15, 2017 at 12:32 PM Emmanuel Charpentier <emanuel.c...@gmail.com> wrote:

Le dimanche 15 octobre 2017 20:57:43 UTC+2, William a écrit :

On Sun, Oct 15, 2017 at 11:40 AM Emmanuel Charpentier <emanuel.c...@gmail.com> wrote:

Inspired by an ask.sagemath question, Trac#23980 adds a couple usage hints to the r<tab> help text. This very minor patch is unproblematic.

Trac#24026, on the other hand, upgrades R to the last current version. As usual, special attention is needed on our problem children of platforms (namely Mac OS X and Erik's Cygwin-64 port).

All our current patches have been rebased against the current version ; no new patch is needed on Debian. However, I still have doubts about our decision to lift upstream's requirement of an https-enabled version of the SSL libraries (meaning OpenSSL, nowadays...). Does the ongoing OpenSSL's change of license change this situation (and our decision) ?

Some history:

- Around 8 or so years ago I included OpenSSL in Sage -- we shipped with it for a few weeks.

- A student in one my classes pointed out the license problem, and then I spent an epic and miserable amount of time switching to the GNU alternatives to OpenSSL, which we shipped with Sage.

- Time passed...

- The OpenSSL project realized their license sucks this year.

- I think OpenSSL has still NOT yet relicensed, although they are trying hard to do so.

- OpenSSL might fail to relicense; e.g., the ZeroMQ project has been trying to switch from LGPL to MPLv2 for year(s) now, and can't seem to do so.  This ZeroMQ license is a major problem for use of Jupyter by certain companies that don't want to use LGPL code internally.

- OpenSSL might succeed at relicensing, e.g., NetworkX was GPL licensed, and really wanted to be BSD licensed -- they made a post saying something kind of like "we are going to relicense in a week or two; if you're an author and have a problem with this, let us know ASAP." And they relicensed. Done.

- GPL has a "you can link against GPL-incompatible system libraries" exemption (otherwise GPL software couldn't run on Windows, say), and sometimes I hope this would apply to components of Sage linking against OpenSSL, as long that OpenSSL isn't included in Sage.   

My gut feeling on this:

- We should either require OpenSSL be installed systemwide or  just ship OpenSSL with Sage.  Security is way, way too important to expose our users to potentially major security problems just because we're overly worried about license issues.  Moreover, I think there is no way the OpenSSL copyright owners are going to sue us for violating their funny license by including it in a GPLv3+ program, especially after announcing an intention to switch to MPLv2, and getting most OpenSSL devs to sign off on that.    

** By not just fully supporting and requiring OpenSSL for everything in Sage, we are exposing all Sage users to an increased chance of installing malicious software from repos. Let's not do that. **

I fully agree. Other respectable Sage developers don't... Previous efforts to raise a consensus on this point have failed. Should a formal vote be taken ?

Sure.  I propose these options: 

- Yes, we should fully support OpenSSL now (and make it so our use of GPLv3+ is compatible as Dima suggested)

- No, we should wait until OpenSSL finishes fixing their license situation formally.

Please modify to make the above clearer.  Then can YOU post a new thread on sage-devel with the subject line

VOTE: inclusion of OpenSSL in Sage

We'll let the voting happen for exactly 7 days from when you post, count the votes, and the majority wins.

 -- William

I add that I'm not sure that the CRAN network will maintain its http repositories when it's https-enabled network is complete... An that's but a part of a larger movement towards a (somewhat) more secured Web.

--

Emmanuel Charpentier

In retrospect, I wish I had never removed OpenSSL from Sage.

 -- William

On Debian testing, both patches pass ptestlong with no failures whatsoever. R sort-of passes its own test suite (i. e. I get a couple of expected, announced failures, analogous to what we get with Python's test suite).

--

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+...@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.

--

-- William Stein

--
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.

--

-- William Stein

[Jean-Pierre Flori]

Note that we don't disable https support, we just let R compile it is not available...

[Emmanuel Charpentier]

Indeed. I don't dispute that.

But the "security" point made by William, and the fact that upstream *wants* https-enabled communications stands. BTW, it also stands for "our" Python...

--

Emmanuel Charpentier