[SciPy-User] Central File Exchange for SciPy
Sat Oct 30 21:47:49 CDT 2010
On Sat, Oct 30, 2010 at 10:32 PM, Fernando Perez <email@example.com> wrote:
> 2010/10/30 Jochen Schröder <firstname.lastname@example.org>:
>> Secondly, the argument that most Python code is already BSD, one could
>> just as well make the argument that most OSS code is GPL so use GPL.
> It's not an argument of majority, it's one of free flow of code across
> projects and of reciprocity and fairness.
> The GPL has an asymmetric relationship re. BSD code: gpl projects can
> incorporate all the bsd code they want, but bsd projects can't
> incorporate gpl code (without relicensing, which is often impossible
> when there are many copyright holders, and is in any case a major
> burden on a project). This asymmetry is at the heart of this
> discussion: numpy, scipy, matpotlib, mayavi, ipython and most of the
> open source projects around here are BSD-licensed and it means we can
> all freely share code across all of them (and we do, very often,
> freely copy pieces from one to the other as needed, this is not a
> hypothetical statement). In fact, I relicensed ipython from its early
> LGPL license (the one that I'm probably happiest with *personally*) to
> BSD precisely based on this argument of free flow of code across
> projects, made by John Hunter at the time. And I'm glad I did, as
> we've been able to copy code at various points in time across projects
> without any worries.
> When an author takes a piece of BSD code, modifies or builds upon it,
> and makes the new work available as GPL (something I've sadly seen
> done many times), he's most certainly *not* behaving in a spirit of
> reciprocity towards the author of the original BSD code. The BSD
> author can no longer benefit from the improvements to his code:
> despite the fact that those improvements remain open source, they are
> no longer available to him unless he relinquishes his original license
> terms and switches to the GPL. I find that practice actually worse
> than building proprietary extensions on open source code, because when
> this is done typically companies at least are doing some other
> business-related stuff that the open source developers are unlikely to
> engage in.
>> Furthermore your argument also ignores the fact that if you're using
>> (ctypes, cython) wrappers around C-code you will probably be bound by
>> the licence of the C-library so some code might not have a choice.
> In this case obviously there's no choice and no argument either, but I
> don't think anyone here is ignoring it, as it's the most basic ground
> truth of any licensing discussion.
>> Finally the biggest problem I have is with the notion that forcing a
>> specific OSS choice onto developers is ok. If someone chooses a licence,
>> they have a reason to do so and it is their choice. The funny thing is
>> that the "free software crowd", often gets accused of this, however I've
>> found that often the BSD crowd is a lot worse, and often quite hostile
>> towards GPL licensing. Anyway I don't want to start a licence flamewar.
> Nobody is *forcing* anything onto anyone. A community is free to say:
> if you want to use our tools, these are our terms. This is a
> community that shares code under the terms of the BSD license and sets
> up a website for that purpose. The rest of the whole internet is
> available to anyone who wishes to publish GPL improvements to Numpy
> and Scipy, just not on the Scipy servers :)
> My personal opinion is that in the long run, it would be beneficial to
> have this 'file exchange' have BSD-only code (or public domain, since
> employees of the US Federal government as far as I understand must
> publish their codes under public domain terms). The reason is simple:
> snippets put there, when good, are prime candidates for integration
> into numpy/scipy proper. It would be a shame, and frankly somewhat
> absurd, to have a bunch of great codes sitting on the scipy server
> that we couldn't integrate into scipy. At least it seems so to me...
Or for integration into other Scipy related packages.
That's exactly my opinion on this.
> SciPy-User mailing list
More information about the SciPy-User