From eric at scipy.org Thu Nov 1 00:20:35 2001 From: eric at scipy.org (eric) Date: Thu, 1 Nov 2001 00:20:35 -0500 Subject: [SciPy-user] plotting enhancements and copyright References: <86hesgzmdm.fsf@bock.chem.unc.edu><001201c161c7$cd474230$777ba8c0@ericlaptop><867ktbk71g.fsf@bock.chem.unc.edu><008401c16236$b66f7b80$c700a8c0@ericlaptop> <86u1wfiibj.fsf_-_@bock.chem.unc.edu> Message-ID: <00af01c16294$efb03930$777ba8c0@ericlaptop> 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" To: "eric" Cc: "scipy-dev" ; "scipy-user" 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 > > iD8DBQE74HPBiJ/aUUS8zY4RAkg8AJ9/samJAatCoGs8HtHZiyFYGa2LQQCfT0OY > aFLQzbp5IzVZZKaUGovzZFA= > =4r2z > -----END PGP SIGNATURE----- > > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From jochen at unc.edu Thu Nov 1 10:48:46 2001 From: jochen at unc.edu (Jochen =?iso-8859-1?q?K=FCpper?=) Date: 01 Nov 2001 10:48:46 -0500 Subject: [SciPy-user] plotting enhancements and copyright In-Reply-To: <00af01c16294$efb03930$777ba8c0@ericlaptop> References: <86hesgzmdm.fsf@bock.chem.unc.edu> <001201c161c7$cd474230$777ba8c0@ericlaptop> <867ktbk71g.fsf@bock.chem.unc.edu> <008401c16236$b66f7b80$c700a8c0@ericlaptop> <86u1wfiibj.fsf_-_@bock.chem.unc.edu> <00af01c16294$efb03930$777ba8c0@ericlaptop> Message-ID: <864roeija9.fsf@bock.chem.unc.edu> -----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 iD8DBQE74W7eiJ/aUUS8zY4RApxmAJ9hXGHBNnYTq5i90UnF0YPv1l6htwCfUPzb 2dTgq49xx3mf7zmIqITOcmw= =iZOt -----END PGP SIGNATURE----- From rossini at blindglobe.net Thu Nov 1 11:20:28 2001 From: rossini at blindglobe.net (A.J. Rossini) Date: 01 Nov 2001 08:20:28 -0800 Subject: [SciPy-user] plotting enhancements and copyright In-Reply-To: <864roeija9.fsf@bock.chem.unc.edu> References: <86hesgzmdm.fsf@bock.chem.unc.edu> <001201c161c7$cd474230$777ba8c0@ericlaptop> <867ktbk71g.fsf@bock.chem.unc.edu> <008401c16236$b66f7b80$c700a8c0@ericlaptop> <86u1wfiibj.fsf_-_@bock.chem.unc.edu> <00af01c16294$efb03930$777ba8c0@ericlaptop> <864roeija9.fsf@bock.chem.unc.edu> Message-ID: <87zo66mpir.fsf@jeeves.blindglobe.net> >>>>> "Jochen" == Jochen K?pper 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 at u.washington.edu FHCRC/SCHARP/HIV Vaccine Trials Net rossini at 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. From eric at scipy.org Thu Nov 1 13:17:32 2001 From: eric at scipy.org (eric) Date: Thu, 1 Nov 2001 13:17:32 -0500 Subject: [SciPy-user] plotting enhancements and copyright References: <86hesgzmdm.fsf@bock.chem.unc.edu><001201c161c7$cd474230$777ba8c0@ericlaptop><867ktbk71g.fsf@bock.chem.unc.edu><008401c16236$b66f7b80$c700a8c0@ericlaptop><86u1wfiibj.fsf_-_@bock.chem.unc.edu><00af01c16294$efb03930$777ba8c0@ericlaptop> <864roeija9.fsf@bock.chem.unc.edu> Message-ID: <01e301c16301$79b44920$777ba8c0@ericlaptop> 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 From jjl at pobox.com Thu Nov 1 14:48:12 2001 From: jjl at pobox.com (John J. Lee) Date: Thu, 1 Nov 2001 19:48:12 +0000 (GMT) Subject: [SciPy-user] plotting enhancements and copyright In-Reply-To: <87zo66mpir.fsf@jeeves.blindglobe.net> Message-ID: 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 From rossini at blindglobe.net Thu Nov 1 16:14:37 2001 From: rossini at blindglobe.net (A.J. Rossini) Date: 01 Nov 2001 13:14:37 -0800 Subject: [SciPy-user] plotting enhancements and copyright In-Reply-To: References: Message-ID: <87lmhqjirm.fsf@jeeves.blindglobe.net> >>>>> "JJL" == John J Lee 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 at u.washington.edu FHCRC/SCHARP/HIV Vaccine Trials Net rossini at 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. From jjl at pobox.com Thu Nov 1 17:06:39 2001 From: jjl at pobox.com (John J. Lee) Date: Thu, 1 Nov 2001 22:06:39 +0000 (GMT) Subject: [SciPy-user] plotting enhancements and copyright In-Reply-To: <87lmhqjirm.fsf@jeeves.blindglobe.net> Message-ID: On 1 Nov 2001, A.J. Rossini wrote: > >>>>> "JJL" == John J Lee 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 From eric at scipy.org Thu Nov 1 16:11:00 2001 From: eric at scipy.org (eric) Date: Thu, 1 Nov 2001 16:11:00 -0500 Subject: [SciPy-user] patch copyrights, and Guido's comments Message-ID: <02ce01c16319$b555dd00$777ba8c0@ericlaptop> Folks, I pinged Guido and asked him about Python's policy on this issue. With his permission, I've posted his comments below. I think for now it is safe to say we will continue with the "patches cannot add copyrights" policy -- unless someone on the list comes up with an acceptable plan. It sounds like an alternative acceptable policy is legally involved and would require a lot of effort. The Python folks are working on this, and, once Python formalizes their policies, we'll review things again. The direction they are leaning has definite possiblities. thanks, eric ------------------ Eric Hello Guido, I'm part of the team developing SciPy (www.scipy.org), an early stage effort to create a large package of modules for Scientific Computing. We're trying to follow the general license, copyright process of Python with the exception that we are using the BSD license instead of the Python license because of the quagmire it was in when SciPy came out. Changing to the Python license may be in the future, but that is not the issue here. We have had our first issue with someone unhappy about a copyright policy. It concerns whether patches submitted to modules should be able to attach a copyright notice to the file they patch. This seems to be a bad idea to me, and from looking through the code in Python, it doesn't appear that this is allowed in Python either. The thread discussing the issue is archived here: http://scipy.net/pipermail/scipy-dev/2001-October/000072.html and continues here: http://scipy.net/pipermail/scipy-dev/2001-November/000073.html I'm inclined to allow only a single copyright per file, but the copyright can be owned by someone other than Enthought. Travis Oliphant and others have copyrighted modules in SciPy right now. I would like to get feedback on whether this is an appropriate policy and how you handle this in Python. Sorry to bother you with legal matters, but your experience in this area could probably save some future headaches. thanks, eric --------------------- Guido Hi Eric, We don't have an explicit policy against multiple copyright notices in files; it's just that most of our contributors don't care. Personally, I think it's pretty murky whether it makes sense to assert copyright on a 50-line patch to a 500-line file. Python currently doesn't have strict guidelines about who owns contributions, but we realize this is not good, and the PSF is planning to work on fixing this situation. There are three possible ways to deal with this: - Copyright assignment: murky, because in most European countries you can't assign the "moral" rights - Licensing: clear, but must be careful that the PSF has the right to change the license -- imagine having to go back to hundreds of contributors for a change in license - Joint ownership: this is an experimental approach taken by Zope Corp. See: http://dev.zope.org/CVS/ContributorIntroduction We're currently leaning towards JO for regular contributors and large contributions, and some light form of licensing for smaller contributions (like most patches) for which ownership seems overkill. We haven't decided yet; in a couple of months, check the PSF website for an outcome. (Are you coming to python10?) --Guido van Rossum (home page: http://www.python.org/~guido/) -------------- Guido in a follow-up Actually, Python has a lot of contributed modules that have an outside copyright notice and license, and we've always be fine with those as long as it was a BSD or Python style license. I just don't recall people wanting a copyright notice for a relatively small change; instead, we typically have a comment saying "Author: XXX" or "Patched by: XXX". Ehm, we do have multiple copyrights in a few files. Tools/scripts/trace.py has at least 4! I guess I should have said that it's rare but that we do allow multiple copyrights per file. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rossini at blindglobe.net Thu Nov 1 17:26:40 2001 From: rossini at blindglobe.net (A.J. Rossini) Date: 01 Nov 2001 14:26:40 -0800 Subject: [OFF-TOPIC]: organizations and licenses Re: [SciPy-user] plotting enhancements and copyright In-Reply-To: References: Message-ID: <87668ujffj.fsf@jeeves.blindglobe.net> >>>>> "JJL" == John J Lee writes: JJL> On 1 Nov 2001, A.J. Rossini wrote: >> >>>>> "JJL" == John J Lee 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 at u.washington.edu FHCRC/SCHARP/HIV Vaccine Trials Net rossini at 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. From eric at scipy.org Thu Nov 1 17:09:42 2001 From: eric at scipy.org (eric) Date: Thu, 1 Nov 2001 17:09:42 -0500 Subject: [OFF-TOPIC]: organizations and licenses Re: [SciPy-user] plotting enhancements and copyright References: <87668ujffj.fsf@jeeves.blindglobe.net> Message-ID: <030001c16321$e8e1d770$777ba8c0@ericlaptop> 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 From jochen at jochen-kuepper.de Thu Nov 1 21:47:53 2001 From: jochen at jochen-kuepper.de (Jochen =?iso-8859-1?q?K=FCpper?=) Date: 01 Nov 2001 21:47:53 -0500 Subject: [SciPy-user] feature request: Reading in arrays. In-Reply-To: References: Message-ID: Besides everything else... On Thu, 25 Oct 2001 12:03:25 -0400 (EDT) Travis Oliphant wrote: Travis> As eric pointed out reading arrays of ASCII data is actually Travis> quite easy (and fairly sophisticated). Would it be possible to allow empty lines in the file (and simply skip them)? For ,----[test.dat] | # Hallo | | 1 2 | 3 4 | 5 6 `---- I get Python 2.1.1 (#1, Aug 28 2001, 19:51:39) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-85)] on linux2 Type "copyright", "credits" or "license" for more information. >>> from scipy.io import * Plotting methods available: ['xplt', 'gplt'] >>> x = read_array('test.dat') Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.1/site-packages/scipy/io/array_import.py", line 272, in read_array a.resize((row,colsize)) ValueError: Newsize is zero. Cannot delete an array in this way. >>> Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de Libert?, ?galit?, Fraternit? GnuPG key: 44BCCD8E Sex, drugs and rock-n-roll From magnus at thinkware.se Sat Nov 3 09:47:55 2001 From: magnus at thinkware.se (Magnus =?iso-8859-1?Q?Lyck=E5?=) Date: Sat, 03 Nov 2001 15:47:55 +0100 Subject: [SciPy-user] State of stats modules? Message-ID: <5.1.0.14.0.20011103145347.02423130@localhost> Hi, I'm a new scipy user, and I'm still a little lost... I've looked through the mailing list archeives and the web site, but I guess I might have missed some info I should have spotted... Anyway, I'll ask some questions here... I start with this one: What's the state of the stats module? Just at random, I tried the aanova function and get: Traceback (most recent call last): File "", line 1, in ? File "G:\Python21\scipy\stats\stats.py", line 3933, in aanova M = pstat.collapse(data,Bscols,-1,None,None,mean) TypeError: collapse() takes at most 5 arguments (6 given) collapse wants: def collapse (listoflists,keepcols,collapsecols,sterr=None,ns=None): In other words... No mean... Removing the last parameter in lines 3933, 3988 and 4372 I get a result, but I won't hang my neck out and say that it's correct (or not). Also, what happens is that the aanova function uses "print" to display the result. Fine for interactive use if I just want to see how things stand, but less amusing if I want to use the results from the anova programmatically in further computations, or for plotting or what ever. The return value from the function is None. :-( There is obviously code in ststs.py that assumes that collapse can work with other stuff than means, as it seems to do now: collapsed = pstat.collapse(M,btwcols,-1,None,len,mean) # Obviously needed for-loop to get source cell-means embedded in collapse fcns contrastmns = pstat.collapse(collapsed,btwsourcecols,-2,sterr,len,mean) # Collapse again, this time SUMMING instead of averaging (to get cell Ns) contrastns = pstat.collapse(collapsed,btwsourcecols,-1,None,None, sum) # Collapse again, this time calculating harmonicmeans (for hns) contrasthns = pstat.collapse(collapsed,btwsourcecols,-1,None,None, harmonicmean) I assume that it's the following snippet in pstat.collapse that should use the sixth parameter: if keepcols == []: means = [0]*len(collapsecols) for i in range(len(collapsecols)): avgcol = colex(listoflists,collapsecols[i]) means[i] = stats.mean(avgcol) <=== supplied function here? return means But I don't feel that I understand enough of statistics or the plan here to patch things on my own... Anyone caring for this? -- Magnus Lyck?, Thinkware AB ?lvans v?g 99, SE-907 50 UME? tel 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus at thinkware.se From magnus at thinkware.se Sat Nov 3 10:29:08 2001 From: magnus at thinkware.se (Magnus =?iso-8859-1?Q?Lyck=E5?=) Date: Sat, 03 Nov 2001 16:29:08 +0100 Subject: [SciPy-user] Odd result from plt.IsShown() Message-ID: <5.1.0.14.0.20011103154807.02483910@localhost> I'm using plt to display some x-y diagrams in a wxPython app, and I update the plot when I shift or change my data if it's visible, checking plt.IsShown(). This works as it should. When I close the app, I also close the plot window if IsShown() returns true, but sometimes this fails, which causes a Windows error message when I try to close a non-existing window. I start showing my data when I press a "Plot button" like this: def OnPlotButton(self, evt): #Construction of "age" and "y" lists snipped self.plot = plt.plot(age, y) plt.title(self.case.idNr) plt.xtitle('Age (years)') plt.ytitle('Height / Weight (cm /kg)') This works OK. When I change data set, or modify my data set, I do the following: if self.plot.IsShown(): self.OnPlotButton(None) This always works. If the diagram is showing, the data is updated, but if it was closed, or never opened, no new plot will be shown. In other words, IsShown() works as expected. It always runs OnPlotButton when a plot window is open, and it never starts a new window it it's closed. I'll have to press the plot button again, just as I intended. When I close the application, I run: def OnClose(self, event): self.db.close() print "Saving and exiting" try: print "In try block" if self.plot.IsShown(): print "In if..." self.plot.Close() print "After close" else: print "In else" except: print "In except" pass event.Skip() If I never used plot, all is fine. self.plot doesn't exist, so I get an attribute error which I catch in my except clause, printing "In except" before returning my prompt. If the plot windows is active, it will close nicely. If I have used plotting, closed the plot window and then changed data set or modified the current data set before I close the app, all is fine. But if I close the plot window, and then close the app directly, I get a crash on exit. The program prints "Saving and exiting", and then "In if...", indicating that IsShown() quite unexpectedly returned 1! I might have pressed my save button, or clicked away in some other way after closing the plot window, but I haven't changed data in such a way that there would have been a re-plot in case the plot window had been open. I'm quite stunned here, because it seems self.plot.IsShown() acts quite differently in the different places in my code! (And yes, it's all in the same class. :-) I can make my program available if someone would like to take a closer look at it. Another unexpected thing is that I get a Python prompt in the command window where I started my app when I open my plot window! I can't type anything in it, and it closes when I exit my app. BTW, plot seems to leak memory. On a normal exit it says: 16:04:20: There were memory leaks. 16:04:20: ----- Memory dump ----- 16:04:20: wxPrintData at $1B8E4E0, size 112 16:04:20: wxFont at $1B8EEF8, size 12 16:04:20: wxFont at $1B8D2C0, size 12 16:04:20: wxFont at $1B8C940, size 12 16:04:20: wxFont at $1B8C1D0, size 12 16:04:20: wxFont at $1B8B500, size 12 16:04:20: wxEvtHandler at $1B8A830, size 40 16:04:20: wxPyCallback at $1B88AB0, size 12 16:04:20: wxObject at $1B88A20, size 28 16:04:20: 16:04:20: 16:04:20: ----- Memory statistics ----- 16:04:20: 1 objects of class wxObject, total size 28 16:04:20: 1 objects of class wxPyCallback, total size 12 16:04:20: 1 objects of class wxEvtHandler, total size 40 16:04:20: 5 objects of class wxFont, total size 60 16:04:20: 1 objects of class wxPrintData, total size 112 16:04:20: 16:04:20: Number of object items: 9 16:04:20: Number of non-object items: 0 16:04:20: Total allocated size: 252 16:04:20: 16:04:20: -- Magnus Lyck?, Thinkware AB ?lvans v?g 99, SE-907 50 UME? tel 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus at thinkware.se From europax at home.com Sun Nov 18 17:34:32 2001 From: europax at home.com (Rob) Date: Sun, 18 Nov 2001 14:34:32 -0800 Subject: [SciPy-user] my first compile try fails Message-ID: <3BF83777.CBD1CC2F@home.com> Hi, I just wanted to try out the compiler and used this one line of code as a test: cez="dstore[1:nx,1:ny,0]=Dz[1:nx,1:ny,0]" scipy.compiler.compiled_exec(cez,locals()) But it is giving me this error. Whats wrong? Note my code runs fine with plain old Numpy. Rob. Traceback (most recent call last): File "/home/rob/newfdtd/xyzblitz.py", line 721, in ? scipy.compiler.compiled_exec(cez,locals()) File "/usr/local/lib/python2.1/site-packages/scipy/compiler/compile_code.py", line 83, in compiled_exec if not size_check.check_expr(expr,local_dict): File "/usr/local/lib/python2.1/site-packages/scipy/compiler/size_check.py", line 40, in check_expr exec(expr,values) File "", line 1, in ? File "/usr/local/lib/python2.1/site-packages/scipy/compiler/size_check.py", line 175, in __getitem__ if end == sys.maxint or end is None: File "/usr/local/lib/python2.1/site-packages/scipy/compiler/size_check.py", line 112, in __cmp__ if len(self.shape) == len(other.shape) == 0: AttributeError: 'int' object has no attribute 'shape' -- The Numeric Python EM Project www.members.home.net/europax From eric at scipy.org Mon Nov 19 10:04:33 2001 From: eric at scipy.org (eric) Date: Mon, 19 Nov 2001 10:04:33 -0500 Subject: [SciPy-user] my first compile try fails References: <3BF83777.CBD1CC2F@home.com> Message-ID: <004101c1710b$7f729840$c200a8c0@ericlaptop> Hey Rob, I get the same thing you do. I'll poke around and see what the issue is. By the way, this looks suspiciously like a finite difference electromagnetics code. : ) I'll get back to you. eric ----- Original Message ----- From: "Rob" To: Sent: Sunday, November 18, 2001 5:34 PM Subject: [SciPy-user] my first compile try fails > Hi, I just wanted to try out the compiler and used this one line of > code as a test: > > cez="dstore[1:nx,1:ny,0]=Dz[1:nx,1:ny,0]" > scipy.compiler.compiled_exec(cez,locals()) > > But it is giving me this error. Whats wrong? Note my code runs fine > with plain old Numpy. Rob. > > Traceback (most recent call last): > File "/home/rob/newfdtd/xyzblitz.py", line 721, in ? > scipy.compiler.compiled_exec(cez,locals()) > File > "/usr/local/lib/python2.1/site-packages/scipy/compiler/compile_code.py", > line 83, in compiled_exec > if not size_check.check_expr(expr,local_dict): > File > "/usr/local/lib/python2.1/site-packages/scipy/compiler/size_check.py", > line 40, in check_expr > exec(expr,values) > File "", line 1, in ? > File > "/usr/local/lib/python2.1/site-packages/scipy/compiler/size_check.py", > line 175, in __getitem__ > if end == sys.maxint or end is None: > File > "/usr/local/lib/python2.1/site-packages/scipy/compiler/size_check.py", > line 112, in __cmp__ > if len(self.shape) == len(other.shape) == 0: > AttributeError: 'int' object has no attribute 'shape' > > > > > > -- > The Numeric Python EM Project > > www.members.home.net/europax > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From rlytle at tqs.com Mon Nov 19 15:08:37 2001 From: rlytle at tqs.com (Lytle, Robert TQO) Date: Mon, 19 Nov 2001 12:08:37 -0800 Subject: [SciPy-user] RE: my first compile try fails Message-ID: <81E1D2E15CCBD311A74700A0C9E1CC8E03A4B2A5@chunky.tqs.com> Thanks Eric, Yes that is some FDTD code. Question: as I understand it from the docs, I can only compile one line of code. Or am I reading that wrong from the docs? Would be nice to compile the entire FDTD field update part of the program by making it one giant string. Rob. From eric at scipy.org Mon Nov 19 14:17:44 2001 From: eric at scipy.org (eric) Date: Mon, 19 Nov 2001 14:17:44 -0500 Subject: [SciPy-user] RE: my first compile try fails References: <81E1D2E15CCBD311A74700A0C9E1CC8E03A4B2A5@chunky.tqs.com> Message-ID: <00a401c1712e$ddf57590$c200a8c0@ericlaptop> Hey Rob, I haven't tried multiple lines yet. I think it could be done if you separated the expressions by a semi-colon. Something like: expr = \ """ expr1; expr2; expr3; """ compiled_exec(expr,locals()) I haven't tried this though. You can also just call them separately, and the overhead should be minimal compared to the FDTD updates. compiled_exec(expr1,locals()) compiled_exec(expr2,locals()) compiled_exec(expr3,locals()) Again, let me know if you want the corrections I've made to handle the error you found. I'll have to send it as a zip or tgz as the CVS version is two different from 0.1 to work. eric ----- Original Message ----- From: "Lytle, Robert TQO" To: Sent: Monday, November 19, 2001 3:08 PM Subject: [SciPy-user] RE: my first compile try fails > Thanks Eric, > > Yes that is some FDTD code. Question: as I understand it from the docs, I > can only compile one line of code. Or am I reading that wrong from the > docs? Would be nice to compile the entire FDTD field update part of the > program by making it one giant string. > > Rob. > _______________________________________________ > SciPy-user mailing list > SciPy-user at scipy.net > http://www.scipy.net/mailman/listinfo/scipy-user > From rlytle at tqs.com Fri Nov 30 15:21:49 2001 From: rlytle at tqs.com (Lytle, Robert TQO) Date: Fri, 30 Nov 2001 12:21:49 -0800 Subject: [SciPy-user] Numeric Python EM Project Moved Message-ID: <81E1D2E15CCBD311A74700A0C9E1CC8E03B1029A@chunky.tqs.com> As @home is teetering on death, I have hosted the website at Verio. You can now get it at www.pythonemproject.com I expect to soon have some nice SciPy compiler examples in there, plus I now have 200Meg, so I can put up all the fancy simulation pictures. Rob. ps. Verio is first class, they had me up and running in 24 hours.