On 2012-02-13 17:32, William Stein wrote:
> "Every component of Sage except jsmath is licensed under a GPL v2
> (or later) compatible license."
At the very least, this is confusing wording. I interpreted this as a
claim that all code in Sage could be released under the GPL v2. Reading
http://ww
On Feb 12, 7:04 pm, Michael Orlitzky wrote:
> If anyone is seriously interested in the reverse proxy solution, I can
> make sure that it works with the new notebook.
Yes please! A reverse proxy would be by far the best way to run Sage
securely and would integrate better on machines serving othe
On Mon, 13 Feb 2012 20:34:40 +
"Dr. David Kirkby" wrote:
> On 02/13/12 05:19 PM, Keshav Kini wrote:
> > If I understand correctly, William's point is that simply placing a
> > copy of the GPL, with a version number attached or otherwise, with a
> > "or any later version" included or otherwise
On 02/13/12 05:19 PM, Keshav Kini wrote:
If I understand correctly, William's point is that simply placing a
copy of the GPL, with a version number attached or otherwise, with a
"or any later version" included or otherwise, in the program's source
code is not equivalent to a declaration of licens
On Mon, Feb 13, 2012 at 9:19 AM, Keshav Kini wrote:
> If I understand correctly, William's point is that simply placing a
> copy of the GPL, with a version number attached or otherwise, with a
> "or any later version" included or otherwise, in the program's source
> code is not equivalent to a dec
If I understand correctly, William's point is that simply placing a
copy of the GPL, with a version number attached or otherwise, with a
"or any later version" included or otherwise, in the program's source
code is not equivalent to a declaration of licensing under the GPL of
a particular version,
On Mon, Feb 13, 2012 at 9:00 AM, Dr. David Kirkby
wrote:
> On 02/13/12 04:32 PM, William Stein wrote:
>>
>> On Mon, Feb 13, 2012 at 7:42 AM, Dr. David Kirkby
>>>
>>> But currently SPKG.txt and COPYING state version 2 only.
>>>
>>>
>>> SPKG.txt for Mercurial states
>>>
>>> "== License ==
>>> * GNU
On 02/13/12 04:32 PM, William Stein wrote:
On Mon, Feb 13, 2012 at 7:42 AM, Dr. David Kirkby
But currently SPKG.txt and COPYING state version 2 only.
SPKG.txt for Mercurial states
"== License ==
* GNU General Public License version 2, or any later version
"
but the COPYING file does not sta
On Sat, Feb 11, 2012 at 12:51 PM, Jeroen Demeyer wrote:
> On 2012-02-11 17:54, Dr. David Kirkby wrote:
>> I believe the license of Sage is very dubious at best
> I will say it more strongly: Sage *is* violating the GPL by distributing
> GPLv3-only packages (such as cvxopt) under a GPLv2+ licence.
On Mon, Feb 13, 2012 at 7:42 AM, Dr. David Kirkby
wrote:
>
> On 02/13/12 12:58 PM, William Stein wrote:
>>
>> On Mon, Feb 13, 2012 at 3:35 AM, Dr. David Kirkby
>> wrote:
>>>
>>> On 02/13/12 11:18 AM, Jason Grout wrote:
On 2/13/12 4:17 AM, Dr. David Kirkby wrote:
>
>
>
On 02/13/12 12:58 PM, William Stein wrote:
On Mon, Feb 13, 2012 at 3:35 AM, Dr. David Kirkby
wrote:
On 02/13/12 11:18 AM, Jason Grout wrote:
On 2/13/12 4:17 AM, Dr. David Kirkby wrote:
Since some of packages will not have the "or later version" added into
the license, we can't distribute S
On 02/12/12 20:39, Keshav Kini wrote:
> Please report issues for the new notebook at
> http://github.com/sagemath/sagenb ! Thanks :)
Thanks, I made this issue #38:
https://github.com/sagemath/sagenb/issues/38
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscrib
On Mon, 13 Feb 2012 04:58:49 -0800
William Stein wrote:
> On Mon, Feb 13, 2012 at 3:35 AM, Dr. David Kirkby
> wrote:
> > On 02/13/12 11:18 AM, Jason Grout wrote:
> >>
> >> On 2/13/12 4:17 AM, Dr. David Kirkby wrote:
> >>>
> >>> Since some of packages will not have the "or later version" added
>
On Mon, Feb 13, 2012 at 3:35 AM, Dr. David Kirkby
wrote:
> On 02/13/12 11:18 AM, Jason Grout wrote:
>>
>> On 2/13/12 4:17 AM, Dr. David Kirkby wrote:
>>>
>>> Since some of packages will not have the "or later version" added into
>>> the license, we can't distribute Sage as GPL 3 or even "GPL 2 or
On 02/13/12 11:18 AM, Jason Grout wrote:
On 2/13/12 4:17 AM, Dr. David Kirkby wrote:
Since some of packages will not have the "or later version" added into
the license, we can't distribute Sage as GPL 3 or even "GPL 2 or any
later version", since some of the components don't have the "or any
lat
On 2/13/12 4:17 AM, Dr. David Kirkby wrote:
Since some of packages will not have the "or later version" added into
the license, we can't distribute Sage as GPL 3 or even "GPL 2 or any
later version", since some of the components don't have the "or any
later version".
Which packages are those?
On 02/11/12 08:54 PM, Jason Grout wrote:
Sage is changing the license for packages? I thought the Sage
distribution was GPLv3 because of GPLv3 packages it included. Who said
the Sage distribution was GPLv2+?
Thanks,
Jason
We have numerous GPL version 2 only components too, so the truth is th
Please report issues for the new notebook at
http://github.com/sagemath/sagenb ! Thanks :)
achtung: sent from phone, possibly unduly terse
On Feb 13, 2012 9:04 AM, "Michael Orlitzky" wrote:
On 02/12/2012 10:54 AM, Jonathan wrote: > > I found my notes on proxying
Sage. If you set up Sage a...
I
On 02/12/2012 10:54 AM, Jonathan wrote:
I found my notes on proxying Sage. If you set up Sage as the root of
your server (ie proxy "/" to Sage) most of the paths are correct (not
all, but most). If you have a server like mine that has legacy pages
at "/" you have to proxy something else to Sag
On 2012-02-12 16:54, Jonathan wrote:
> I found my notes on proxying Sage. If you set up Sage as the root of
> your server (ie proxy "/" to Sage) most of the paths are correct (not
> all, but most).
Yes, this is my situation.
--
To post to this group, send an email to sage-devel@googlegroups.com
I found my notes on proxying Sage. If you set up Sage as the root of
your server (ie proxy "/" to Sage) most of the paths are correct (not
all, but most). If you have a server like mine that has legacy pages
at "/" you have to proxy something else to Sage (for example "/
Sage"). Anyway, this do
On Feb 12, 3:00 am, Jeroen Demeyer wrote:
> On 2012-02-12 03:30, Jonathan wrote:> This does not work cleanly with Sage
> because the css and js
> The *only* problem I found was the URL displayed when you publish a
> worksheet which is wrong.
I also found problems with URLs necessary for Jmol to
On 2012-02-12 03:30, Jonathan wrote:
> This does not work cleanly with Sage because the css and js refer to
> each other and the paths aren't just simple relative paths. You need
> to run mod_proxy_html and rewrite css, js and some of the html pages
> on the fly.
No, you don't. I am currently doi
This does not work cleanly with Sage because the css and js refer to
each other and the paths aren't just simple relative paths. You need
to run mod_proxy_html and rewrite css, js and some of the html pages
on the fly. At least that was my experience when trying to have ssl
in front. I never tri
Le dimanche 12 février, Jeroen Demeyer a écrit:
> On 2012-02-11 22:21, Julien Puydt wrote:
> > Le samedi 11 février, Jeroen Demeyer a écrit:
> >> On 2012-02-11 22:05, Michael Orlitzky wrote:
> >>> It could even work out of the box. There shouldn't be a problem
> >>> distributing apache/nginx linked
On 2012-02-12 00:21, Volker Braun wrote:
> On Saturday, February 11, 2012 3:10:19 PM UTC-8, Jeroen Demeyer wrote:
>
> You are
> just replacing the non-GPL openSSL by the non-GPL apache. But I am not
> a lawyer, so I won't bother discussing this further.
>
>
> Apache licence v2 is co
On 02/11/2012 06:10 PM, Jeroen Demeyer wrote:
I think it pretty much *is* the same situation license-wise. You are
just replacing the non-GPL openSSL by the non-GPL apache.
Precisely. We would have to link to OpenSSL though, whereas we
communicate with apache over a TCP/IP connection.
--
T
On Saturday, February 11, 2012 3:10:19 PM UTC-8, Jeroen Demeyer wrote:
> You are
> just replacing the non-GPL openSSL by the non-GPL apache. But I am not
> a lawyer, so I won't bother discussing this further.
>
Apache licence v2 is compatible with GPL v3, so its very different (and not
a proble
On 2012-02-11 22:21, Julien Puydt wrote:
> Le samedi 11 février, Jeroen Demeyer a écrit:
>> On 2012-02-11 22:05, Michael Orlitzky wrote:
>>> It could even work out of the box. There shouldn't be a problem
>>> distributing apache/nginx linked against OpenSSL in the sage
>>> tarball.
>> Why not direc
On 02/11/2012 04:37 PM, Jonathan wrote:
Making Sage work well with a proxy is no simple matter. I run a
number of web sites where we proxy through Apache to get SSL and
generally more robust web services facing the outside world. For this
to work well your backend needs to be proxy aware, or th
Le dimanche 12 février, Keshav Kini a écrit:
> Yes, but Michael said "distributing apache/nginx linked against
> OpenSSL in the sage tarball", which is what Jeroen was responding to.
Putting them in the same archive isn't a problem, or distributions
would have problem.
The licences cover derived
On 2/11/12 3:41 PM, Jonathan wrote:
On Feb 11, 3:18 pm, Jason Grout wrote:
That sounds reasonable. I *think* OpenSSL is also a requirement for
OpenID, so they'd lose that as well.
So exactly what error happens when you try to install sagenb on a system
with the headers? I assume we need t
On 02/11/2012 04:39 PM, Jason Grout wrote:
The GPL extends to cover all code shipped together, IIRC. So it is
different, in my understanding.
That's fine. I don't think any of us are lawyers, thank god, so like I
said in my response to Jeroen we could make it a separate tarball and
still ac
On Feb 11, 3:18 pm, Jason Grout wrote:
>
> That sounds reasonable. I *think* OpenSSL is also a requirement for
> OpenID, so they'd lose that as well.
>
> So exactly what error happens when you try to install sagenb on a system
> with the headers? I assume we need to work around that, and then
On 2/11/12 3:36 PM, Michael Orlitzky wrote:
On 02/11/2012 04:11 PM, Jason Grout wrote:
On 2/11/12 3:05 PM, Michael Orlitzky wrote:
On 02/11/2012 03:48 PM, Keshav Kini wrote:
As long as we provide instructions on how to use nginx as a backend to
provide SSL, we're not really losing functionalit
On 02/11/2012 04:12 PM, Jeroen Demeyer wrote:
On 2012-02-11 22:05, Michael Orlitzky wrote:
It could even work out of the box. There shouldn't be a problem
distributing apache/nginx linked against OpenSSL in the sage tarball.
Why not directly link to OpenSSL then? If you require people to have
Making Sage work well with a proxy is no simple matter. I run a
number of web sites where we proxy through Apache to get SSL and
generally more robust web services facing the outside world. For this
to work well your backend needs to be proxy aware, or the proxy has to
know a lot about the backen
On 02/11/2012 04:11 PM, Jason Grout wrote:
On 2/11/12 3:05 PM, Michael Orlitzky wrote:
On 02/11/2012 03:48 PM, Keshav Kini wrote:
As long as we provide instructions on how to use nginx as a backend to
provide SSL, we're not really losing functionality, just increasing
inconvenience a bit for th
On Sun, Feb 12, 2012 at 05:21, Julien Puydt wrote:
> Le samedi 11 février, Jeroen Demeyer a écrit:
>> On 2012-02-11 22:05, Michael Orlitzky wrote:
>> > It could even work out of the box. There shouldn't be a problem
>> > distributing apache/nginx linked against OpenSSL in the sage
>> > tarball.
>>
Le samedi 11 février, Jeroen Demeyer a écrit:
> On 2012-02-11 22:05, Michael Orlitzky wrote:
> > It could even work out of the box. There shouldn't be a problem
> > distributing apache/nginx linked against OpenSSL in the sage
> > tarball.
> Why not directly link to OpenSSL then? If you require peo
On 2/11/12 3:14 PM, Volker Braun wrote:
On Saturday, February 11, 2012 12:19:17 PM UTC-8, Jonathan wrote:
So you are suggesting that the openssl support be automatically
removed if the libssl-dev is missing, when somebody tries to compile?
Yes. That is exactly what Python already does,
On Saturday, February 11, 2012 12:19:17 PM UTC-8, Jonathan wrote:
>
> So you are suggesting that the openssl support be automatically
> removed if the libssl-dev is missing, when somebody tries to compile?
Yes. That is exactly what Python already does, the _ssl module isn't built
if the headers
On Sun, Feb 12, 2012 at 05:05, Jeroen Demeyer wrote:
> So I guess COPYING.txt should be updated then...
Yes, IMO it should. See http://trac.sagemath.org/sage_trac/ticket/12447 .
-Keshav
Join us in #sagemath on irc.freenode.net !
--
To post to this group, send an email to sage-devel@googl
On 2012-02-11 22:05, Michael Orlitzky wrote:
> It could even work out of the box. There shouldn't be a problem
> distributing apache/nginx linked against OpenSSL in the sage tarball.
Why not directly link to OpenSSL then? If you require people to have
OpenSSL for apache/nginx, you might as well sk
On 2/11/12 3:05 PM, Michael Orlitzky wrote:
On 02/11/2012 03:48 PM, Keshav Kini wrote:
As long as we provide instructions on how to use nginx as a backend to
provide SSL, we're not really losing functionality, just increasing
inconvenience a bit for those who want to use SSL.
It could even wor
On 2012-02-11 21:59, Keshav Kini wrote:
> On Sun, Feb 12, 2012 at 04:54, Jason Grout
> wrote:
>>> I will say it more strongly: Sage *is* violating the GPL by distributing
>>> GPLv3-only packages (such as cvxopt) under a GPLv2+ licence.
>>>
>>
>> Sage is changing the license for packages? I thoug
On 02/11/2012 03:48 PM, Keshav Kini wrote:
As long as we provide instructions on how to use nginx as a backend to
provide SSL, we're not really losing functionality, just increasing
inconvenience a bit for those who want to use SSL.
It could even work out of the box. There shouldn't be a proble
On 2/11/12 2:59 PM, Keshav Kini wrote:
The complete Sage distribution is GPLv3+. The core Sage library
(written in Python and Cython) is GPLv2+. However, many of the
components of Sage are GPLv3+.
I suppose if we are really shipping GPLv3-*only* components, then the
distribution isn't re
On Sun, Feb 12, 2012 at 04:54, Jason Grout wrote:
>> I will say it more strongly: Sage *is* violating the GPL by distributing
>> GPLv3-only packages (such as cvxopt) under a GPLv2+ licence.
>>
>
> Sage is changing the license for packages? I thought the Sage distribution
> was GPLv3 because of GP
On 2/11/12 2:51 PM, Jeroen Demeyer wrote:
On 2012-02-11 17:54, Dr. David Kirkby wrote:
I believe the license of Sage is very dubious at best
I will say it more strongly: Sage *is* violating the GPL by distributing
GPLv3-only packages (such as cvxopt) under a GPLv2+ licence.
Sage is changing
On 2012-02-11 17:54, Dr. David Kirkby wrote:
> I believe the license of Sage is very dubious at best
I will say it more strongly: Sage *is* violating the GPL by distributing
GPLv3-only packages (such as cvxopt) under a GPLv2+ licence.
--
To post to this group, send an email to sage-devel@googlegr
On Sun, Feb 12, 2012 at 04:27, Michael Orlitzky wrote:
> Rather than build SSL support into the application servers, everyone
> deployed apache or nginx as an SSL proxy in front of them. Could this work
> for the sage notebook?
>
> The notebook would always run on e.g. localhost:8080 unencrypted,
On 02/11/2012 03:12 PM, Volker Braun wrote:
If you want to compile the flask notebook then I think we should
recommend installing openssl-dev but not require it. So on machines
without ssl it'll just build without ssl support, easy.
For distributed binaries we don't need ssl headers, only ssl li
On Feb 11, 2:12 pm, Volker Braun wrote:
> If you want to compile the flask notebook then I think we should recommend
> installing openssl-dev but not require it. So on machines without ssl it'll
> just build without ssl support, easy.
So you are suggesting that the openssl support be automatica
If you want to compile the flask notebook then I think we should recommend
installing openssl-dev but not require it. So on machines without ssl it'll
just build without ssl support, easy.
For distributed binaries we don't need ssl headers, only ssl libraries. Its
fine (by most legal opinions)
On 02/11/12 02:57 PM, Jason Grout wrote:
So I'd support adding openssl-dev as a requirement of Sage.
That probably means a lot more users would need to be root to install Sage,
since if the development headers are not present, they would have a bit of a
problem.
I believe also OpenSSL does
On Sun, Feb 12, 2012 at 01:55, Jason Grout wrote:
> IIRC, the question is not so much distributing our source that just has an
> import statement, but distributing binaries that we've compiled.
Right, of course... if we're talking about distributing binaries then
what I said goes out the window.
On 2/11/12 11:50 AM, Jonathan wrote:
Since it allows redistribution of source and binaries with
acknowledgement, I'm not sure it is really incompatible with GPL,
That makes the OpenSSL license GPL-incompatible. See
http://people.gnome.org/~markmc/openssl-and-the-gpl.html
Thanks,
Jason
--
On 2/11/12 11:47 AM, Keshav Kini wrote:
IANAL but I find it hard to believe that simply having
non-GPL-compatible software as a dependency disqualifies us from
releasing Sage under the GPL. If that were true, surely it would be
impossible to license Windows programs under the GPL, as in order to
Alex is correct. I stand corrected. The header files that are a
problem are part of libssl-dev. I did a quick read of their copyright
license. Since it allows redistribution of source and binaries with
acknowledgement, I'm not sure it is really incompatible with GPL,
although their secondary li
IANAL but I find it hard to believe that simply having non-GPL-compatible
software as a dependency disqualifies us from releasing Sage under the GPL.
If that were true, surely it would be impossible to license Windows
programs under the GPL, as in order to run them you must first install
Micros
On 2/11/12 10:54 AM, Dr. David Kirkby wrote:
On 02/11/12 02:57 PM, Jason Grout wrote:
On 2/11/12 8:52 AM, Jonathan wrote:
What is the policy on system dependencies?
Here is the situation. The latest flask-notebook contains support for
OpenSSL. In order to compile properly it needs access to bo
On 02/11/12 02:57 PM, Jason Grout wrote:
On 2/11/12 8:52 AM, Jonathan wrote:
What is the policy on system dependencies?
Here is the situation. The latest flask-notebook contains support for
OpenSSL. In order to compile properly it needs access to both the
openssl and openssl-dev packages. At le
On Sat, Feb 11, 2012 at 9:57 AM, Jason Grout
wrote:
> So I'd support adding openssl-dev as a requirement of Sage. What systems
> does it come default on? I don't recall having a problem on OSX, for
> example.
On Debian (and presumably Ubuntu as well), the correct package name
appears to be lib
On 2/11/12 8:52 AM, Jonathan wrote:
What is the policy on system dependencies?
Here is the situation. The latest flask-notebook contains support for
OpenSSL. In order to compile properly it needs access to both the
openssl and openssl-dev packages. At least on my Ubuntu system the
openssl pac
65 matches
Mail list logo
