sage release plan

[Jason Grout]

I see that 5.1 is starting to get up there in betas, and I'm curious
what the plan was for Sage releases over the next few months. I was
hoping that 5.2 would be ready by the start of August or so (for the
fall semester). Does that fall in line with what Jeroen is thinking?

Thanks,

Jason

[Jeroen Demeyer]

sage-5.1.beta6 is surely the last beta for sage-5.1. I have a few more
tickets lined up for sage-5.1.rc0. The two remaining blockers for
sage-5.1 are easily "solved" by unmerging the tickets which caused them.
I expect a release of sage-5.1.rc0 in the next few days and sage-5.1
one week after that if no new issues arise.

I can try for a quick sage-5.2 release, but one month is fairly tight.
I also depends a lot on how much troubles we get with the new notebook
(and OpenSSL), which will hopefully finally get merged.

[Andrey Novoseltsev]

Hi Jeroen,

I also would like to have Sage with new notebook ready by the start of
the next term (a bit in advance for testing and setting up) - is it
possible perhaps to make 5.2 just for the notebook switch?..

Thank you,
Andrey

[Jeroen Demeyer]

On 2012-06-26 10:54, Andrey Novoseltsev wrote:
> Hi Jeroen,
>
> I also would like to have Sage with new notebook ready by the start of
> the next term (a bit in advance for testing and setting up) - is it
> possible perhaps to make 5.2 just for the notebook switch?..

Are you talking about sagenb-0.9.0 (#11080) or sagenb-0.10.0 (#13121)?

[Andrey Novoseltsev]

At least 0.9.0, as it should fix a number of issues present in the old
one. It is also annoying creating interacts in the notebook and then
discover that something works differently with Sage cell server. As I
understand it, differences should be reduced by the switch.

Having a beta version with everything included is not really an option
for course usage - I'd like students to be able to install the same
version as the class one on their own computers, if they wish, and
ideally is should not include figuring out how to use betas. Besides
having a beta name is scary ;-)

[Jeroen Demeyer]

On 2012-06-26 13:46, Andrey Novoseltsev wrote:
> At least 0.9.0, as it should fix a number of issues present in the old
> one. It is also annoying creating interacts in the notebook and then
> discover that something works differently with Sage cell server. As I
> understand it, differences should be reduced by the switch.

Hmm, I would actually prefer to wait for sage-0.10.0, i.e. not release
the final sage-5.2 with sage-0.9.0.

[kcrisman]

I agree with Andrey and Jason that having a "non-beta" release ready for sysadmins to install for mid-August term begin dates is essential.  I'm looking forward to the new Sagenb.  Even with 0.9.0 would be better, in my view.  

In fact, I think it would be totally appropriate to have a Sage 5.2 that was ONLY the new notebook and ancillaries, released relatively quickly, maybe even in conjunction with Sage 5.3 or whatever - Jason, is sagenb.org running sagenb 0.10 yet? - so that it would indeed be ready by then.  5.3 could just start with whatever seemed appropriate.

[Jason Grout]

Actually, it's running on a commit a few commits before 0.10, but way
after 0.9.0.

Jason

[Julien Puydt]

Le 25/06/2012 22:01, Jeroen Demeyer a �crit :

> I can try for a quick sage-5.2 release, but one month is fairly tight.
> I also depends a lot on how much troubles we get with the new notebook
> (and OpenSSL), which will hopefully finally get merged.

Beware of OpenSSL and the GPL :
http://people.gnome.org/~markmc/openssl-and-the-gpl.html

By the way, https://github.com/sagemath/sagenb lacks some important
files : AUTHORS, LICENSE, COPYRIGHT. The license stanzas in the source
files aren't very good either : they say "GPL" (no version), and point
to http://www.gnu.org/licenses/ where now GPL=GPL-3 while many of them
have been written before it was even published! And did I mention a
number of the file lack even that?

Snark on #sagemath

[Keshav Kini]

Julien Puydt <julien...@laposte.net> writes:

> Le 25/06/2012 22:01, Jeroen Demeyer a écrit :
>> I can try for a quick sage-5.2 release, but one month is fairly tight.
>> I also depends a lot on how much troubles we get with the new notebook
>> (and OpenSSL), which will hopefully finally get merged.
>
> Beware of OpenSSL and the GPL :
> http://people.gnome.org/~markmc/openssl-and-the-gpl.html

We're not shipping OpenSSL, just requiring it as a dependency. We also
provide it as an optional supplementary download for those who don't
have the authority to install OpenSSL globally on their system. Neither
of these have any legal problems AFAIK.

> By the way, https://github.com/sagemath/sagenb lacks some important
> files : AUTHORS, LICENSE, COPYRIGHT. The license stanzas in the source
> files aren't very good either : they say "GPL" (no version), and point
> to http://www.gnu.org/licenses/ where now GPL=GPL-3 while many of them
> have been written before it was even published! And did I mention a
> number of the file lack even that?

Wanna submit a pull request? :)

-Keshav

----
Join us in #sagemath on irc.freenode.net !

[Jeroen Demeyer]

On 2012-06-27 11:12, Keshav Kini wrote:
> We're not shipping OpenSSL, just requiring it as a dependency. We also
> provide it as an optional supplementary download for those who don't
> have the authority to install OpenSSL globally on their system.

> Neither of these have any legal problems AFAIK.

Debian disagrees with this...

[Volker Braun]

Debian is also pretty much the only one who disagrees with this.

[Michael Orlitzky]

Debian wants to ship only Free Software. If your Free Software requires
non-Free software, it ain't Free.

[Volker Braun]

On Wednesday, June 27, 2012 4:24:29 PM UTC+1, Michael Orlitzky wrote:

Debian wants to ship only Free Software. If your Free Software requires
non-Free software, it ain't Free.

This has nothing to do with the issue at hand. Both Apache v1.0 and GPL are Free Software Licenses. They are incompatible, but Free.See also http://www.gnu.org/licenses/license-list.html

[Michael Orlitzky]

Yes, but "Sage is a free open-source mathematics software system
licensed under the GPL." You can replace "Free Software" in my previous
message with "GPL" if you like.

How closely does the notebook integrate with OpenSSL? Does it link to it
or do something equivalent?

If you combine GPL and GPL-incompatible software and redistribute the
result, you have a problem. An example:

1) I release libfoo under GPL3. In particular, that means that if you
link to my code and redistribute it, you may not impose additional
restrictions on your users.

2) You write a utility that encrypts foos. You use OpenSSL
to do this, and you link both OpenSSL and libfoo.

3) You distribute the work.

Now, do your users have to abide by the OpenSSL advertising clause?

All advertising materials mentioning features or use of this
software must display the following acknowledgement:
"This product includes cryptographic software written by
Eric Young (e...@cryptsoft.com)"
The word 'cryptographic' can be left out if the rouines from the
library being used are not cryptographic related :-).

If not, you've violated its license. If so, you've violated mine.

[William Stein]

On Wed, Jun 27, 2012 at 11:25 AM, Michael Orlitzky <mic...@orlitzky.com> wrote:
> On 06/27/12 11:40, Volker Braun wrote:
>> On Wednesday, June 27, 2012 4:24:29 PM UTC+1, Michael Orlitzky wrote:
>>
>>     Debian wants to ship only Free Software. If your Free Software requires
>>     non-Free software, it ain't Free.
>>
>>
>> This has nothing to do with the issue at hand. Both Apache v1.0 and GPL
>> are Free Software Licenses. They are incompatible, but Free.See
>> also http://www.gnu.org/licenses/license-list.html
>
> Yes, but "Sage is a free open-source mathematics software system
> licensed under the GPL." You can replace "Free Software" in my previous
> message with "GPL" if you like.
>
> How closely does the notebook integrate with OpenSSL? Does it link to it
> or do something equivalent?
>
> If you combine GPL and GPL-incompatible software and redistribute the
> result, you have a problem. An example:
>
>  1) I release libfoo under GPL3. In particular, that means that if you
>     link to my code and redistribute it, you may not impose additional
>     restrictions on your users.
>
>  2) You write a utility that encrypts foos. You use OpenSSL
>     to do this, and you link both OpenSSL and libfoo.
>
>  3) You distribute the work.

We are not distributing openssl + Sage.

We indirectly support an *optional* (and little used) feature for the
Sage notebook called "ssl support", and for people to use it, they
must either use the system-wide ssl on their computer or install an
optional package themselves. In fact the actual code that uses ssl
is in Twisted, which is MIT licensed, and Twisted just sits in front
of the sage notebook as a WSGI server.

We should just relicense the sage notebook as BSD to completely
eliminate this problem (since the notebook and the GPL'd sage itself
are completely separate processes/libraries). The only person who
hasn't responded to my permission request for that is Mitesh Patel,
who did his work on the notebook employed by me, and no doubt would be
fine with the relicensing.

-- William

>
> Now, do your users have to abide by the OpenSSL advertising clause?
>
>  All advertising materials mentioning features or use of this
>  software must display the following acknowledgement:
>  "This product includes cryptographic software written by
>  Eric Young (e...@cryptsoft.com)"
>  The word 'cryptographic' can be left out if the rouines from the
>  library being used are not cryptographic related :-).
>
> If not, you've violated its license. If so, you've violated mine.
>

> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org



--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[Jeroen Demeyer]

On 2012-06-27 19:46, William Stein wrote:
> We indirectly support an *optional* (and little used) feature for the
> Sage notebook called "ssl support", and for people to use it, they
> must either use the system-wide ssl on their computer or install an
> optional package themselves.

It's not optional, it's *required*. The spkg is only optional in the
sense that you don't need the OpenSSL spkg if your operating system
already has OpenSSL. But to build and to run Sage requires OpenSSL in
one way or another.

[William Stein]

I'm sorry -- I was only addressing the situation with respect to the
*notebook*.

Why is OpenSSL required to build and run Sage without the notebook?????

-- William

[Volker Braun]

On Wednesday, June 27, 2012 6:25:19 PM UTC+1, Michael Orlitzky wrote:

If you combine GPL and GPL-incompatible software and redistribute the
result, you have a problem.

Not necessarily, this is the System Library exception in the GPL.

[David Kirkby]

On 25 June 2012 21:01, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:

> I can try for a quick sage-5.2 release, but one month is fairly tight.
> I also depends a lot on how much troubles we get with the new notebook
> (and OpenSSL), which will hopefully finally get merged.

I'm sure Jeroen knows this, but I think I'll raise the point anyway.
Trying to rush a release because certain people want feature X, Y or Z
is dangerous. There is far more chance of getting bugs. Also, whilst I
apprecaite some system admins don't like installing beta software, you
need to weigh that against they might not like installing Sage again
if a supposidly "stable" release caues them problems.

We used to have a much quicker release cycle, and it just seemed to
cause endless problems. As soon as a release was made, we had to make
another to fix a serious bug. I recall for example we introduced
something which needed "iconv", but many systems did not have this, so
another release had to be rushed out with iconv added.

Dave

Dave

[David Kirkby]

Yes, which says

"The “System Libraries” of an executable work include anything, other
than the work as a whole, that (a) is included in the normal form of
packaging a Major Component, but which is not part of that Major
Component, and (b) serves only to enable use of the work with that
Major Component, or to implement a Standard Interface for which an
implementation is available to the public in source code form. A
“Major Component”, in this context, means a major essential component
(kernel, window system, and so on) of the specific operating system
(if any) on which the executable work runs, or a compiler used to
produce the work, or an object code interpreter used to run it."

I can't see how OpenSSL is a major essential component of the
operating system, given several systems don't ship with it
preinstalled.

I must admit I feel the same about the Window system - it is far from
an essential requirement. Most competent system admins would not
install a window system on a server. The same goes for a compiler.

Dave

[Volker Braun]

The "system library exception" does not require or imply any popular consensus about what an operating system should ship with.

MinGW and Cygwin both link to proprietary libraries under the system library exception, yet nobody in their right mind would want those proprietary libraries in their operating system.

[Dima Pasechnik]

On Thursday, 28 June 2012 09:58:39 UTC+1, Dr. David Kirkby wrote:

On 27 June 2012 19:17, Volker Braun <vbrau...@gmail.com> wrote:
> On Wednesday, June 27, 2012 6:25:19 PM UTC+1, Michael Orlitzky wrote:
>>
>> If you combine GPL and GPL-incompatible software and redistribute the
>> result, you have a problem.
>
>
> Not necessarily, this is the System Library exception in the GPL.

Yes, which says

"The “System Libraries” of an executable work include anything, other
than the work as a whole, that (a) is included in the normal form of
packaging a Major Component, but which is not part of that Major
Component, and (b) serves only to enable use of the work with that
Major Component, or to implement a Standard Interface for which an
implementation is available to the public in source code form. A
“Major Component”, in this context, means a major essential component
(kernel, window system, and so on) of the specific operating system
(if any) on which the executable work runs, or a compiler used to
produce the work, or an object code interpreter used to run it."

I can't see how OpenSSL is a major essential component of the
operating system, given several systems don't ship with it
preinstalled.

it falls under "implement(s) a Standard Interface for which an 

implementation is available to the public in source code form", isn't it?

I must admit I feel the same about the Window system - it is far from
an essential requirement. Most competent system admins would not
install a window system on a server. The same goes for a compiler.

This shows that your argument does not hold water, rather than otherwise...

Indeed, openssl is a major essential component of a desktop/laptop system...

 

Dave

[Jason Grout]

On 6/28/12 3:37 AM, David Kirkby wrote:
> I'm sure Jeroen knows this, but I think I'll raise the point anyway.
> Trying to rush a release because certain people want feature X, Y or Z
> is dangerous. There is far more chance of getting bugs. Also, whilst I
> apprecaite some system admins don't like installing beta software, you
> need to weigh that against they might not like installing Sage again
> if a supposidly "stable" release caues them problems.

Agreed. That's why I asked about the schedule. We should also note
that the new notebook (the major feature of 5.2) has been tested for
over a year in the largest production Sage servers (for better or for
worse...), so it isn't exactly like it's unproven code that has never
really been run before.

Thanks,

Jason

[kcrisman]

Correct.  If it's a matter of having a release with only #11080 in it that is ready for people to upgrade (and for us to advertise to people to upgrade) significantly before the time many Northern hemisphere universities begin, but doesn't have #13121, that would be fine.  I don't see why a notebook-only upgrade couldn't be done for 5.2, release end of July, if that really was pretty much all that was included.  But I think I say the same thing earlier in this thread and on other tickets...

[Jeroen Demeyer]

On 2012-06-28 14:36, Jason Grout wrote:
> On 6/28/12 3:37 AM, David Kirkby wrote:
>> I'm sure Jeroen knows this, but I think I'll raise the point anyway.
>> Trying to rush a release because certain people want feature X, Y or Z
>> is dangerous. There is far more chance of getting bugs. Also, whilst I
>> apprecaite some system admins don't like installing beta software, you
>> need to weigh that against they might not like installing Sage again
>> if a supposidly "stable" release caues them problems.
>
>
> Agreed. That's why I asked about the schedule. We should also note
> that the new notebook (the major feature of 5.2) has been tested for
> over a year in the largest production Sage servers

...on one particular operating system.

In terms of portability, it did not get much testing I think.

[kcrisman]

I don't think that's quite fair.  A lot of the development of the new notebook has been done by people on Mac, from what I can tell, while it's been run on Linux.  And most of the web app stuff has been "tested" by people using all kinds of different browsers and systems from all over the world - doubtless Jason and Google analytics have some stats on this.

[Jeroen Demeyer]

On 2012-06-28 15:27, kcrisman wrote:
> I don't think that's quite fair. A lot of the development of the new
> notebook has been done by people on Mac, from what I can tell, while
> it's been run on Linux. And most of the web app stuff has been "tested"
> by people using all kinds of different browsers and systems from all
> over the world - doubtless Jason and Google analytics have some stats on
> this.

I'm glad to be proven wrong.

[Jeroen Demeyer]

On 2012-06-28 14:47, kcrisman wrote:
> I don't see why a notebook-only upgrade couldn't be done for 5.2, release
> end of July, if that really was pretty much all that was included.

I doubt that adding more stuff will significantly slow down the release.

[kcrisman]

Haha, assuming that "from what I can tell" is true ;-)  I'm sure Jason and others will comment on the portability question with more authority. 

[Jason Grout]

I've done my development on OS X.

Jason

[William Stein]

On Thu, Jun 28, 2012 at 2:37 AM, David Kirkby <david....@onetel.net> wrote:
> On 25 June 2012 21:01, Jeroen Demeyer <jdem...@cage.ugent.be> wrote:
>
>> I can try for a quick sage-5.2 release, but one month is fairly tight.
>> I also depends a lot on how much troubles we get with the new notebook
>> (and OpenSSL), which will hopefully finally get merged.
>
> I'm sure Jeroen  knows this, but I think I'll raise the point anyway.
> Trying to rush a release because certain people want feature X, Y or Z
> is dangerous. There is far more chance of getting bugs. Also, whilst I
> apprecaite some system admins don't like installing beta software, you
> need to weigh that against they might not like installing Sage again
> if a supposidly "stable" release caues them problems.
>
> We used to have a much quicker release  cycle, and it just seemed to
> cause endless problems. As soon as a release was made, we had to make
> another to fix a serious bug.

The same happens on releases that take a long time.

We took *forever* to release sage-5.0 -- certainly it was the longest
time between releases ever. And, we still had to make a new release
quickly thereafter to address a serious issue, hence sage-5.0.1.

"Release early, release often." (The Cathedral and the Bazaar)

-- William

[David Kirkby]

On 28 June 2012 16:17, William Stein <wst...@gmail.com> wrote:


> "Release early, release often."  (The Cathedral and the Bazaar)
>
>  -- William

That is unlikely to go down well with system admins. One of the early
comments was that system admins would not want install beta versions.

I personally think bug-fix-only releases is the way to go in order to
get stable versions that someone can install and be reasonably
confident they wont have to install a new version a week later.

Release early, release often is good for computer litterate users who
have the time and desire to keep installing different versions of
software. It's not so good for those that want stable software, or to
have a system install it and not keep ****ing him/her off saying they
need it upgraded because of a bug.

Dave

[Jeroen Demeyer]

On 2012-06-28 17:17, William Stein wrote:
> We took *forever* to release sage-5.0 -- certainly it was the longest
> time between releases ever.

Sure, the longest time ever. On the other hand, it was *only* 4 months,
which I wouldn't call "forever". But it did take so long for a good
reason: we wanted to support OS X 10.7. If you set explicit goals like
that, it takes as long as it needs to take.

[William Stein]

In retrospect, I'm not complaining at all. I'm happily using sage-5.0
right now, and loving it.

-- William

[kcrisman]

Okay, but to play devil's advocate - if the explicit goal is merging #11080 and releasing something without problems otherwise, could that take shorter?  For instance, all that currently seems needed there is for someone other than the author of the Lion patch for http://trac.sagemath.org/sage_trac/ticket/13126 to test the new openssl package.

Of all the 74 current positive review tickets, 17 are invalid or dupes, many are pending (such as regarding #13121, which could be in a Sage 5.3), and most of the rest have nothing to do with the notebook (many are graph theory or upgrading various other spkgs).

I'm not trying to sage-flame, just hoping to convince that a 5.2 entering rc stage early on (even if a lot of new functionality gets plopped in a parallel 5.3 because of it) would be very useful.  Not least for marketing purposes.  I realize that I do not have the prowess to do a release completely on my own at this point (particularly given that sagenb is now upstream) - I'm very grateful, like everyone else, for the high quality of even early betas and for the many tickets rejected for minor doctest issues :) which in the long run strengthens things a lot.  But it is a very strong suggestion.

[Benjamin Jones]

On Thu, Jun 28, 2012 at 4:20 PM, kcrisman <kcri...@gmail.com> wrote:
>
>
> On Thursday, June 28, 2012 4:45:00 PM UTC-4, Jeroen Demeyer wrote:
>>
>> On 2012-06-28 17:17, William Stein wrote:
>> > We took *forever* to release sage-5.0 -- certainly it was the longest
>> > time between releases ever.
>> Sure, the longest time ever.  On the other hand, it was *only* 4 months,
>> which I wouldn't call "forever".  But it did take so long for a good
>> reason: we wanted to support OS X 10.7.  If you set explicit goals like
>> that, it takes as long as it needs to take.
>
>
> Okay, but to play devil's advocate - if the explicit goal is merging #11080
> and releasing something without problems otherwise, could that take shorter?
>  For instance, all that currently seems needed there is for someone other
> than the author of the Lion patch for
> http://trac.sagemath.org/sage_trac/ticket/13126 to test the new openssl
> package.
>
> Of all the 74 current positive review tickets, 17 are invalid or dupes, many
> are pending (such as regarding #13121, which could be in a Sage 5.3), and
> most of the rest have nothing to do with the notebook (many are graph theory
> or upgrading various other spkgs).
>

I just finished the last part of the review on #13126, it's ready to go.

--
Benjamin Jones

[Jeroen Demeyer]

On 2012-06-28 23:20, kcrisman wrote:
> Okay, but to play devil's advocate - if the explicit goal is merging
> #11080 and releasing something without problems otherwise, could that
> take shorter?

I really doubt it would take significantly shorter time. I can make a
release with fewer tickets than usual, sure. But 5 tickets or 50
tickets isn't going to make the difference.

Most of the time needed for release management is testing, both on the
buildbot and by developers installing betas. The time needed is
essentially independent of the number of tickets merged.

[kcrisman]

Is it dependent on the number of betas?  That seems to have been the determining factor in the last year or so.  I find it hard to believe that a release with only one beta would take two months - again, with the caveat that IANARM.

[Jeroen Demeyer]

On 2012-06-29 13:51, kcrisman wrote:
> Is it dependent on the number of betas? That seems to have been the
> determining factor in the last year or so.

Yes, probably this is the most important factor.

[Fernando Perez]

Minor note from the peanut gallery:

On Wed, Jun 27, 2012 at 10:46 AM, William Stein <wst...@gmail.com> wrote:
> We should just relicense the sage notebook as BSD to completely
> eliminate this problem

speaking from the IPython side, this would be great for us. We're
starting to have real collaboration between ipython and sagenb (again,
thanks largely to J. Grout's outstanding cross-project bridge building
work, e.g. https://github.com/ipython/ipython/pull/2051). But
obviously it would be much better from our perspective if code could
flow both ways creating a real symmetric, collaborative relationship.
Right now our code can happily go into sagenb as needed, but not the
other way around (you guys have been great at relicensing specific
snippets when asked, but that's not really a viable solution for
everyday ongoing work).

Cheers,

f

[Jan Groenewald]

Hi

Would this symmetric flow not also be possible if ipython relicensed to GPL?
Honest question.

Regards,
Jan

--
  .~.
  /V\     Jan Groenewald
 /( )\    www.aims.ac.za
 ^^-^^

[Fernando Perez]

On Fri, Jun 29, 2012 at 11:46 AM, Jan Groenewald <j...@aims.ac.za> wrote:
> Would this symmetric flow not also be possible if ipython relicensed to GPL?
> Honest question.

Certainly, but that's not in the cards. All the 'scipy ecosytem'
(python, numpy, scipy, matplotlib, ipython, pandas, statsmodels,
scikit-learn, scikits-image, pytables, networkx, cython, etc) is BSD
licensed and there's no intention of changing that. Besides at this
point even if I wanted (which I don't) to change it I couldn't, as
there are by now way too many ipython contributors who made their
contributions to the project as BSD. It would be likely impossible to
get them to agree to a GPL relicensing.

Note that I'm not *pushing* for you guys to change anything, I just
gave my '+1' to William's comment, in light of the recent upswing in
collaboration we've had with Jason G. Obviously it's perfectly fine
if Sagenb remains GPL, and it will always be able to continue using
ipython, numpy, etc as it always has. As I said, I just pinged
because William brought it up.

Cheers,

f

[Andrea Lazzarotto]

Besides at this

point even if I wanted (which I don't) to change it I couldn't, as
there are by now way too many ipython contributors who made their
contributions to the project as BSD.  It would be likely impossible to
get them to agree to a GPL relicensing.

Can't it be an issue for Sage in the opposite direction?

But my humble question is: why should Sage risk to donate the hard work to companies such Apple (only an example) which use open source to make money without giving back? For what I saw on the website (as a complete novice who I am) I understood that Sage was born to be and remain free as in freedom.

Best regards,

--
Andrea Lazzarotto - http://andrealazzarotto.com

[Jeroen Demeyer]

On 2012-06-29 20:54, Fernando Perez wrote:
> On Fri, Jun 29, 2012 at 11:46 AM, Jan Groenewald <j...@aims.ac.za> wrote:
>> Would this symmetric flow not also be possible if ipython relicensed to GPL?
>> Honest question.
>
> Certainly, but that's not in the cards. All the 'scipy ecosytem'
> (python, numpy, scipy, matplotlib, ipython, pandas, statsmodels,
> scikit-learn, scikits-image, pytables, networkx, cython, etc) is BSD
> licensed and there's no intention of changing that. Besides at this
> point even if I wanted (which I don't) to change it I couldn't, as
> there are by now way too many ipython contributors who made their
> contributions to the project as BSD. It would be likely impossible to
> get them to agree to a GPL relicensing.

I don't think you need anybody's permission to relicense under GPL. You
might piss people off, but technically speaking you could take code
under the revised BSD license and release it as GPL.

[Jason Grout]

On 6/29/12 1:54 PM, Fernando Perez wrote:
> It would be likely impossible to
> get them to agree to a GPL relicensing.

But you wouldn't have to, right? You could just add one file that was
GPL, and start distributing that, and IPython would switch to GPL
(though the files already there would be BSD, of course).

That would probably ruin goodwill in your community, of course, and
certainly not something I'd suggest. I'm just pointing out that it
would not be impossible to switch to GPL, even without retroactively
getting user's permission.

On the other hand, we can't switch sagenb to BSD because one major
contributor has effectively disappeared. So we'd need to rewrite their
code.

Jason

[Jason Grout]

The BSD files themselves would still be BSD, even if the distribution
was GPL, right? You can't just delete the BSD header and change it to
GPL, can you?

Jason

[Andrea Lazzarotto]

Il giorno 29/giu/2012 23:20, "Jason Grout" <jason...@creativetrax.com> ha scritto:
> The BSD files themselves would still be BSD, even if the distribution was GPL, right?  You can't just delete the BSD header and change it to GPL, can you?

You can change a single character and release your modified version as GPL. :-)

--
Andrea Lazzarotto

[Jason Grout]

On 6/29/12 4:30 PM, Andrea Lazzarotto wrote:
> Il giorno 29/giu/2012 23:20, "Jason Grout" <jason...@creativetrax.com

> <mailto:jason...@creativetrax.com>> ha scritto:

> > The BSD files themselves would still be BSD, even if the distribution
> was GPL, right? You can't just delete the BSD header and change it to
> GPL, can you?
>
> You can change a single character and release your modified version as
> GPL. :-)
>

No, that wouldn't work. For one, the BSD license says:

Redistributions of source code must retain the above copyright notice,
this list of conditions and the following disclaimer.

So you can't just delete the BSD header and replace it with GPL. But
maybe we're talking past each other.

However, suppose you distributed a GPL readme file along with the BSD
file. Now the distribution (*together*) becomes GPL, but you could
still take the BSD files out and they would be purely BSD. At least,
that's how I understand it. You could easily change the IPython
distribution to be GPL, but the individual BSD files themselves would
require copyright holder's approval to change the license.

Anyways, we're nitpicking at details here. IPython isn't going to
change to GPL, which is just fine with me.

Jason

[Andrea Lazzarotto]

Ok sorry, probably I was confusing with the revised BSD and the fact that the license happily allows proprietary software to use and abuse open source components. But yes, you are right about the single files.

--
Andrea Lazzarotto

[Fernando Perez]

On Fri, Jun 29, 2012 at 2:37 PM, Jason Grout
<jason...@creativetrax.com> wrote:
> No, that wouldn't work.  For one, the BSD license says:
>
> Redistributions of source code must retain the above copyright notice, this
> list of conditions and the following disclaimer.
>
> So you can't just delete the BSD header and replace it with GPL.  But maybe
> we're talking past each other.

Yup, that's right.

> Anyways, we're nitpicking at details here.  IPython isn't going to change to
> GPL, which is just fine with me.

Indeed, we're not. And again, I wasn't trying in any way to push
sagenb to change either: I only expressed a 'peanut gallery +1' as
commentary to William's post. If the sagenb doesn't want to or can't
for whatever reason switch to BSD, that's completely OK too and I'll
be the last to bug you about it. BSD works well for the 'scipy
ecosystem', that's all.

Cheers,

f