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-----
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-user] 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-user mailing list SciPy-user@scipy.net http://www.scipy.net/mailman/listinfo/scipy-user
-----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-----
"Jochen" == Jochen Küpper <jochen@unc.edu> writes:
Jochen> I just looked at the XEmacs cvsweb. From the first 5 Jochen> src-files I picked three had multiple copyrights, 2 were Jochen> only copyrighted by FSF. And wxWindows, which is Jochen> obviously also closely related to wxplt, has a 1whole Jochen> bunch of files with multiple copyrights in there. I am not Jochen> sure what the individual contributions to these files are, Jochen> though. Actually, what you are referring to was for many years (and still is) the primary difference between Emacs and XEmacs. Not fair, though it is relevant. Submission of GPL'd code for inclusion to Emacs (I'm lead coordinator/developer for ESS, an IDE-like environment using (x)emacs for statistical data analysis), requires signing over all copyright to the FSF. It makes it easier to fight for in that context. I can't submit ESS for inclusion with Emacs without tracing down _ALL_ of the authors, and getting clearance from them. This, I don't have time to do. Now, to avoid any GPL wars, let me point out that the issue is "what would need to happen to modify the license in the future". The need to go back to copyright holders, or at least verify what they mean, intend, or will allow, is annoying. With a BSD license, I think there is less of an issue. However, it is still cleaner to have a single license and copyright holder, than to force people to make sure that each module is properly usable. The Omegahat project (http://www.omegahat.org/), had to handle that as well (its goal is to work on the next generation of statistical computing frameworks), and chose to enforce the single license/single copyright holder. Of course, this is counter-balanced by the need to recognize contributors in such a way that they feel it is worthwhile. eric> We'll work on a formal policy for contributions as soon as eric> possible. Jochen> Don't make it too formal, or more people won't like it. Actually, it should be "formal", in the sense that it lays out the ground work (yet another problem...). It should not necessarily be technical, though. Anyway, this should be hashed out soon. Not that I'm involved in anyway, just a bystander at this point. best, -tony -- A.J. Rossini Rsrch. Asst. Prof. of Biostatistics U. of Washington Biostatistics rossini@u.washington.edu FHCRC/SCHARP/HIV Vaccine Trials Net rossini@scharp.org -------------- http://software.biostat.washington.edu/ -------------- FHCRC: M-W: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email UW: T-Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX Rosen: (Mullins' Lab) Fridays, and I'm unreachable except by email.
On 1 Nov 2001, A.J. Rossini wrote: [...]
With a BSD license, I think there is less of an issue. However, it is still cleaner to have a single license and copyright holder, than to force people to make sure that each module is properly usable. The [...]
I guess many of the possible contributors work at universities, who usually (like other employers) claim copyright on everything that their staff produce in the course of their work, so I'm wondering: do people ever actually take this seriously for relatively small (or large, for that matter) pieces of software without obvious commercial value? Even if universities are happy to give permission for free use in some sense, remembering the CNRI/Python case, it wouldn't suprise me if some institutions insist on retaining copyright, or even restricting use to non-commercial users, as a matter of policy. Mind you, it also wouldn't suprise me if people generally ignored the legal requirement to get permission from their employer... Of course, in the case of Scipy, there *is* obvious commercial value in it (independent of whether or not it is being sold). John
"JJL" == John J Lee <jjl@pobox.com> writes:
JJL> I guess many of the possible contributors work at JJL> universities, who usually (like other employers) claim JJL> copyright on everything that their staff produce in the JJL> course of their work, so I'm wondering: do people ever JJL> actually take this seriously for relatively small (or large, JJL> for that matter) pieces of software without obvious JJL> commercial value? Yes, this can be a real problem if university lawyers want to make it a problem. It is why I generally restrict contributions towards and use GPL'd projects (the so-called "viral" nature is one means of getting around IP problems if you are producing research-quality (which I'll unfairly claim is generally of lower quality than commercial) software for others to use. I make exceptions sometimes, but one needs to be careful in those cases. For those of us with multiple (joint) appointments, this concern is exponentially more problematic... best, -tony -- A.J. Rossini Rsrch. Asst. Prof. of Biostatistics U. of Washington Biostatistics rossini@u.washington.edu FHCRC/SCHARP/HIV Vaccine Trials Net rossini@scharp.org -------------- http://software.biostat.washington.edu/ -------------- FHCRC: M-W: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email UW: T-Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX Rosen: (Mullins' Lab) Fridays, and I'm unreachable except by email.
On 1 Nov 2001, A.J. Rossini wrote:
"JJL" == John J Lee <jjl@pobox.com> writes:
[about copyright ownership by employees (universities in particular)]
Yes, this can be a real problem if university lawyers want to make it a problem. [...] (the so-called "viral" nature is one means of getting around IP problems if you are producing research-quality (which I'll unfairly claim is generally of lower quality than commercial) software for others to use). [...]
I don't understand: if you don't have permission to license something, you can't 'get around it' by claiming you've GPL'd it -- you don't have the authority to do so. Am I right? John
"JJL" == John J Lee <jjl@pobox.com> writes:
JJL> On 1 Nov 2001, A.J. Rossini wrote: >> >>>>> "JJL" == John J Lee <jjl@pobox.com> writes: JJL> [about copyright ownership by employees (universities in JJL> particular)] >> Yes, this can be a real problem if university lawyers want to >> make it a problem. JJL> [...] >> (the so-called "viral" nature is one means of getting around IP >> problems if you are producing research-quality (which I'll >> unfairly claim is generally of lower quality than commercial) >> software for others to use). JJL> [...] JJL> I don't understand: if you don't have permission to license JJL> something, you can't 'get around it' by claiming you've GPL'd JJL> it -- you don't have the authority to do so. Am I right? Sort of. But not quite. The point is the range of allowable licenses that can be placed on the work. To redistribute a work which integrates GPL'd devices, it must be GPL'd. If it's part of my research to provide a means to recreate my research (typical and expected in the computational sciences, esp in genomics amoung others), then the organization can control which of the range of licenses can be used. However, for de novo software, since there is a wide range, the organization can restrict the possible licenses under which the software can be redistributed. Different research/academic organizations have different views on software; some view software as a publication, and you retain ownership. Some view it as a product, to which they maintain ownership. I've worked for (and still work for) groups with both views. But this is completely off-topic, since SciPy isn't a GPL'd product, and the choice of the license belongs to the owners, the decision having already been made. best, -tony -- A.J. Rossini Rsrch. Asst. Prof. of Biostatistics U. of Washington Biostatistics rossini@u.washington.edu FHCRC/SCHARP/HIV Vaccine Trials Net rossini@scharp.org -------------- http://software.biostat.washington.edu/ -------------- FHCRC: M-W: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email UW: T-Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX Rosen: (Mullins' Lab) Fridays, and I'm unreachable except by email.
Hey Tony, I haven't heard any major complaints about this, but it does seem somewhat relevant to the current conversation, so I'll toss this out. There are reasons why SciPy is not GPL'd beyond the fact that Enthought is a commercial entity. I would have made the same choice for SciPy had I remained in academics. By its very nature, SciPy (and Python itself to some extent) is most valuable as a building block integrated into larger systems -- not as a stand-alone package. Pretty much anything that computes and needs signal/image processing, optimization algorithms, etc. can benefit from SciPy. This includes both Open Source packages as well as commercial software and hardware. Commercial entities cannot use GPL'd code (at least how I read it) in their products unless the product is free, so a GPL'd SciPy would be useless to them. However, a BSD style license opens SciPy to use and contributions from these companies. If SciPy can serve and be developed by both communities, it will grow more quickly. I believe SciPy is good for science (both academic and commercial), and the faster it grows the better. Packages like Emacs don't have the same issues because, while they are used by companies to develop products, they do not become a part of products. As a result, companies that are happy using Emacs would pass over SciPy and choose to either roll-their-own or purchase a licensed alternative when it came to scientific tools. As you said, the licensing decision has already been made. Still, I thought it worthwhile to explain, at least in part, the reasoning behind the choice. 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
participants (4)
-
eric -
Jochen Küpper -
John J. Lee -
rossini＠blindglobe.net