[SciPy-dev] plotting enhancements and copyright
eric at scipy.org
Wed Oct 31 23:21:10 CST 2001
SciPy is and always will be Open Source. Allowing patches to alter
copyrights is dangerous because of the precedent it sets.
Let me be clear about the issue:
You have sent a 50+ line patch to a code base to a 850+ line wxplt.py module
that is an integral part of a 3000 line code base (the plt package). Based
on this patch, you have copyrighted the entire wxplt.py module. This is
inappropriate. Over the next few years, wxplt.py is likely to get (and
needs... : | ) multiple patches of the same size or larger than the one you
submitted. If each of these patches again included a copyright, we could
potentially have 5+ copyrights attached to each file.
I am not a lawyer and do not know, nor do I want to know, all the
implications of having files encumbered by multiple copyrights. I did,
however, watch the unpleasant copyright battle over Python
(http://www.onlamp.com/pub/a/python/2000/08/14/pythonnews.html) and have
read Guido's frustrated emails. I have also looked at the Python source
code for hints as to how this sort of issue should be handled. I did not
find a single source file that had multiple copyrights. They did
occasionally list authors, but, if a copyright existed, it appeared to be
held by the original author. The same approach is mirrored in many open
source projects. As an example, the following is cut from the QPL license
at http://www.troll.no/qpl/. 3.a is the relative statement here.
3. You may make modifications to the Software. In order to preserve
the integrity of the unmodified version of the Software,
modifications must be distributed in the form of patches, and the
following restrictions apply to each patch:
a. Application of the patch must not modify copyright notices
in the Software.
b. The patch must be explicitly licensed by the following
clauses without additional restriction:
Permission is hereby granted, free of charge, to any person
obtaining a copy of this patch, to deal in the patch
without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute,
sublicense, and/or sell copies of the patch, subject to the
following conditions: Any copyright notice and this
permission notice must be included in all copies or
substantial portions of the patch.
c. The patch must include an accurate description of the modification,
the date of the modification and the author of the modification.
It seems dangerous then, to break with this established approach by blurring
the ownership of large and important source files for the sake of single
SciPy will follow a similar path as Python. The overall license is the very
broad BSD license. We wanted to use the Python license, but were advised
not to because it is written for an institution instead of a corporation.
Still, the BSD license is as open of a license as I know, so I don't think
this is an issue. As far as individual modules, there are multiple modules
in SciPy with copyrights held by other people (Travis Oliphant, Ivan Frohne,
Gary Strangman, etc.) This is perfectly fine. We have asked for and
received permission to use the modules. It is relatively easy to do this
from a single source. It is not easy from multiple sources. I am not
interested in accepting patches that require an extra copyright even to
these modules because of the possible hassles it creates.
As far as your contributed zoom feature, it is very cool, and I would like
to see it in SciPy. I initially suggested we acknowledge your contribution
in the THANKS file. This was not acceptable. I then suggested that you
separate your code into a second module and copyright this module, but leave
to original source that you did not write un-encumbered by your copyright.
I also suggested that this was logistically a bit of hassle since the module
is only 50 or so lines and should really be folded into the original code.
As such, someone in the future would probably redo your work in the original
module. Until this happens though, you can submit your module with its
copyright for inclusion in SciPy. From the tone of your news group posting,
I gather that this is also unacceptable. This is unfortunate because zoom
is a welcomed enhancement.
Jochen, thanks for raising such an important issue as it is better to learn
where the hitches are gonna occur sooner rather than later. We'll work on a
formal policy for contributions as soon as possible. I am sorry you
disagree with me on this issue of not allowing patch authors to assume
partial ownership and control over module source code, but I am also secure
in knowing that the decision follows a precedent established by Python and
is for the good of SciPy.
----- Original Message -----
From: "Jochen Küpper" <jochen at unc.edu>
To: "eric" <eric at scipy.org>
Cc: "scipy-dev" <scipy-dev at scipy.net>; "scipy-user" <scipy-user at scipy.org>
Sent: Wednesday, October 31, 2001 4:57 PM
Subject: [SciPy-dev] plotting enhancements and copyright
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Cc'ed to the scipy lists.
> Should also make it into the archive.
> This message is to inform the users and developers od SciPy what's
> going on in politics.
> The plot_window class (an earlier version of which I send to this
> lists) or respective changes to plot_canvas and some further changes
> to scipy.plt won't get included in scipy 'cause of politcal issues.
> This is sad as it provided a first implementation of zooming and an
> *useful* interface to use scipy.plt as wxWindow in other applications.
> See below for more.
> Because this is new for most people I cite a little more.
> eric> 4) Do you feel strongly about the inclusion of the copyright?
> For clarification: This is refering to a line at the top of the
> respective source file: "#Copyright (C) 2001 Jochen Küpper"
> >> Yes. The code is copyrighted by me anyway, so why not tell everybody?
> eric> Ok. Unfortunately, I am not interested in encumbering the
> eric> existing code with another copyright for a single or even
> eric> multiple additional features. This sort of thing is almost
> eric> never done because it can lead to major hassles in the future
> eric> trying to work with the 20 people who have added feature patches
> eric> and bug fixes to a file over its lifetime.
> What problems are you thinking of here? Changing the license?
> What else?
> eric> So I guess the best thing to do then if for you to derive a new
> eric> plot_canvas class and add/override the methods you need to and
> eric> place it in a new module.
> That's what I did to begin with.
> eric> You can then copyright this module.
> Yeah. I guess I just put it into jkext, so I can everything the way I
> like it, not restricted by scipy rules. (I do not want to argue about
> these rules. I think there have to be rules and the ones that are
> there are appropriate for the project from my point of view.) The
> module is GPL'ed.
> eric> I guess you need to include the Enthought/BSD copyright also if
> eric> any or my original code is in the modules and you plan on
> eric> distributing it separately.
> eric> As for how it is handled in SciPy, I'm not sure. We can include
> eric> your module, but the zoom capability is also likely to be folded
> eric> back into the original class once someone has the time to sit
> eric> down and work on the graphics code (with someone having to redo
> eric> your work).
> It isn't hard, as I showed.
> I actually spent more time to fit it into scipy than writing the stuff
> in the first place:( And this while I was learning wxPython.
> eric> I guess we'll need to add a policy that copyrights for patches
> eric> and bug fixes will need to be assigned to the original code
> eric> author or copyright holder. Contributors will be acknowledged in
> eric> the THANKS file. This is the standard practice in OS projects
> eric> so I didn't feel the need to make it explicit, but I will now to
> eric> prevent future confusion on the issue. New modules can retain
> eric> the authors copyright, as long as it is BSD compliant (or
> eric> whatever we eventually end up with).
> I think you are confusing things here. "Copyright" and "license" are
> two distinct features. Any code I write I do have a copyright on, no
> matter what the license is. I can give up my copyright i.e. by
> transfering it to someone else, but unless I explicitely do that I'll
> own the copyright.
> The license is whole different story. (I am ok with the BSD style
> licens, esp. since I see that there is (good) reasoning behind it.)
> Many people never write the FSF-papers. So far I am one of them. (Not
> that they would seriously need mine.)
> For now I am not going to transfer my copyright on BSD licensed code
> to a company, sorry.
> I wish SciPy good luck!
> - --
> Einigkeit und Recht und Freiheit
> Liberté, Égalité, Fraternité GnuPG key: 44BCCD8E
> Sex, drugs and rock-n-roll
> -----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-----
> Scipy-dev mailing list
> Scipy-dev at scipy.net
More information about the Scipy-dev