[SciPy-dev] Re: [SciPy-user] plotting enhancements and copyright
jochen at unc.edu
Thu Nov 1 09:48:46 CST 2001
-----BEGIN PGP SIGNED MESSAGE-----
eric> SciPy is and always will be Open Source.
Nice. I never seriously doubted that.
eric> Allowing patches to alter copyrights is dangerous because of the
eric> precedent it sets.
I still do not understand, but that might be me. What do you think of here?
eric> You have sent a 50+ line patch to a code base to a 850+ line
eric> wxplt.py module that is an integral part of a 3000 line code
eric> base (the plt package). Based on this patch, you have
eric> copyrighted the entire wxplt.py module. This is inappropriate.
Ok. I initially had the C-notice in the class documentation. But I
think that wouldn't make differene if that class source is in wxplt.py
and is an integral part of it.
eric> Over the next few years, wxplt.py is likely to get (and
eric> needs... : | ) multiple patches of the same size or larger than
eric> the one you submitted.
I hope so.
You know I was still working on it.
eric> If each of these patches again included a copyright, we could
eric> potentially have 5+ copyrights attached to each file.
eric> I am not a lawyer and do not know, nor do I want to know, all the
eric> implications of having files encumbered by multiple copyrights.
Me too. Although I would like to learn about implications, esp. the
ones why it is considered to be bad practice.
eric> I did, however, watch the unpleasant copyright battle over
eric> and have read Guido's frustrated emails. I have also looked at
eric> the Python source code for hints as to how this sort of issue
eric> should be handled. I did not find a single source file that had
eric> multiple copyrights.
eric> It seems dangerous then, to break with this established approach
eric> by blurring the ownership of large and important source files
eric> for the sake of single patches.
I just looked at the XEmacs cvsweb. From the first 5 src-files I
picked three had multiple copyrights, 2 were only copyrighted by FSF.
And wxWindows, which is obviously also closely related to wxplt, has a
1whole bunch of files with multiple copyrights in there. I am not sure
what the individual contributions to these files are, though.
eric> SciPy will follow a similar path as Python. The overall license
eric> is the very broad BSD license.
Fine. And it definitely does make sence to follow python, as that is
what it definitely depends on.
eric> We wanted to use the Python license, but were advised not to
eric> because it is written for an institution instead of a
As was the BSD license.
Do you want to share the problems your advisors foresaw in the Python
license used by a corporation? And how this is less of a problem with
eric> Still, the BSD license is as open of a license as I know, so I
eric> don't think this is an issue.
To my mind that's a different issue. Not to be included here.
eric> We have asked for and received permission to use the modules.
Well, feel free to do so. If you ever want to include stuff from me,
ask. I am confident that in many cases I won't have trouble to let you
change the license to BSD.
eric> I am not interested in accepting patches that require an extra
eric> copyright even to these modules because of the possible hassles
eric> it creates.
Well, I am still not clear what possible hassles you are thinking of?
eric> As far as your contributed zoom feature, it is very cool, and I
eric> would like to see it in SciPy.
If you lool at my jkext next week you will find a class implementing
that. (As I need that for my own application.) Feel free to put it
eric> I then suggested that you separate your code into a second
eric> module and copyright this module, but leave to original source
eric> that you did not write un-encumbered by your copyright.
This is how I initially did it. This is how I will do it again. If you
want to include that module into scipy, now problem with me. (v.s.)
eric> As such, someone in the future would probably redo your work in
eric> the original module. Until this happens though, you can submit
eric> your module with its copyright for inclusion in SciPy. From the
eric> tone of your news group posting, I gather that this is also
That is not correct. I am not willing to restrict myself to rules I
don't really like without any benefit. I will write that module and
let you know when I think it is worhwhile including it into scipy.
(It's almost useful by know.) Feel free whatever you wanna do within
it's license. (v.s.)
eric> Jochen, thanks for raising such an important issue as it is
eric> better to learn where the hitches are gonna occur sooner rather
eric> than later.
:) ... :( ...... ;)
eric> We'll work on a formal policy for contributions as soon as
Don't make it too formal, or more people won't like it.
eric> I am sorry you disagree with me on this issue of not allowing
eric> patch authors to assume partial ownership and control over
eric> module source code, but I am also secure in knowing that the
eric> decision follows a precedent established by Python and is for
eric> the good of SciPy.
As I said before, I wish SciPy good luck. If this decision will help
in the end you are a wise man! It is unfortunate that the enhancements
are not included in plt, but their functionality will come at some
I don't have any strong sentiments about that issue overall. I am
simply on a different track with regard to the very issue and as such
we have to work in parallel instead of coacting.
I'll keep in touch, at least as a user of SciPy, and we'll see where
University of North Carolina phone: +1-919-962-4403
Department of Chemistry phone: +1-919-962-1579
Venable Hall CB#3290 (Kenan C148) fax: +1-919-843-6041
Chapel Hill, NC 27599, USA GnuPG key: 44BCCD8E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6-cygwin-fcn-1 (Cygwin)
Comment: Processed by Mailcrypt and GnuPG <http://www.gnupg.org/>
-----END PGP SIGNATURE-----
More information about the Scipy-dev