[SciPy-dev] Re: [SciPy-user] plotting enhancements and copyright

[Jochen Küpper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eric, 

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.

Yes.

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> Python
eric> (http://www.onlamp.com/pub/a/python/2000/08/14/pythonnews.html)
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
eric> corporation.

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
BSD?

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

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

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

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

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

Greetings,
Jochen
- -- 
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/>

iD8DBQE74W7eiJ/aUUS8zY4RApxmAJ9hXGHBNnYTq5i90UnF0YPv1l6htwCfUPzb
2dTgq49xx3mf7zmIqITOcmw=
=iZOt
-----END PGP SIGNATURE-----