-----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, 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. Yes. 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! Bye, Jochen - -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de 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/> iD8DBQE74HPBiJ/aUUS8zY4RAkg8AJ9/samJAatCoGs8HtHZiyFYGa2LQQCfT0OY aFLQzbp5IzVZZKaUGovzZFA= =4r2z -----END PGP SIGNATURE-----
Jochen, 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 patches. 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. sincerely, eric jones ----- Original Message ----- From: "Jochen Küpper" <jochen@unc.edu> To: "eric" <eric@scipy.org> Cc: "scipy-dev" <scipy-dev@scipy.net>; "scipy-user" <scipy-user@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,
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.
Yes.
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!
Bye, Jochen - -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de 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/>
iD8DBQE74HPBiJ/aUUS8zY4RAkg8AJ9/samJAatCoGs8HtHZiyFYGa2LQQCfT0OY aFLQzbp5IzVZZKaUGovzZFA= =4r2z -----END PGP SIGNATURE-----
_______________________________________________ Scipy-dev mailing list Scipy-dev@scipy.net http://www.scipy.net/mailman/listinfo/scipy-dev
participants (2)
-
eric -
Jochen Küpper