[SciPy-user] plotting enhancements and copyright

[eric]

Hello Jochen,


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

I've explained it as clearly as I know how.  Maybe A.J. Rossini's response
adds some insight that I was unable to convey.

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

I agree.  Copyrights in documentation would have the same affect as a
copyright in the header and therefore are not a good idea.  I need to check
on this, but I also think that a patch submitted with such  a restriction
would not be accepted by the Python team into Python itself.

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

Again, see A.J. Rossini's post for a concrete example.

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

Python's license history is unpleasant and confusing.  Therefore, saying
SciPy is covered by the Python license is also confusing.  The Python
license (http://www.python.org/2.1.1/license.html) has
multiple sections from 4 different organizations, none of which have
anything to do with SciPy.  The PSF section at the top looks reasonable to
me, but again, I am no expert.  So, if we made th necessary changes to the
top portion of the license and omitted the other sections, is it still the
Python license?  Can you say it is covered by the Python license?  Very few
people read the actual license, and the term "covered by the Python license"
is unfortunately now loaded.  We did not want there to be any ambiguity
about the usage of SciPy and therefore chose a license without the storied
history.

The BSD license is not specific to 4 organizations, it is written in a
general way for *anyone* to use, It seems to have the same overall intent as
the Python license, and *is* used by other corporations.
Compare the BSD license to the Intel's Open Source license:

http://www.opensource.org/licenses/bsd-license.html
http://www.opensource.org/licenses/intel-open-source-license.html


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

I'm sorry.  I have no other arguments to make other than to again refer you
to A.J. Rossini's post.

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

After this thread of emails, it seems prudent to explicitly state the
policy.  I'm really not interested in spending a lot more time writing
emails like this.  I do not enjoy it, and it isn't the best use of time.
I'm pretty sure the policy will be as discussed here:  Patches to an
existing file cannot modifiy the original copyright.  I'll ask around the
Python community and see what other recommendations we get.

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

Ok.  I'm sorry we will not get your contributions, but the great thing about
Open Source is that people can have different opinions, and users still have
access to code.  Users that need 'zoom' instantly can grab it from your site
which is good.  However, I've thought through it a little more and adding a
50 line patch as a new module to SciPy just isn't a good idea from the code
maintenance standpoint.  We'll just have to wait till someone submits a zoom
patch to wxplt.py without the copyright restrictions.

thanks,
eric