Re: [Numpy-discussion] Re: Purchasing Documentation
Paul F. Dubois wrote:
The original sources were in Framemaker. I am not positive where they are. In any case they are copyrighted by the Regents of the University of California. I am not a lawyer and don't know what the consequences of that are. LLNL granted free distribution of the printed document with the Numeric source code but I don't know what their position would be on using their copyrighted text in a new document or on giving away the sources.
OK, thanks Paul. That may have implications for you, Travis, if you are planning to base your SciPy Core book on the existing NumPy documentation. Given the circumstance which Paul describes, perhaps the only way forward is to create a freely available addendum to the freely available, existing NumPy documentation which describes how and where SciPy Core differs or extends NumPy? Or to write entirely new documentation from scratch.
I believe that under U.S. copyright law, a person may lend their copy of a book to anyone but not reproduce it and give them a copy.
Yes, likewise here in Oz, and in most countries. Of course, the publisher of a book can impose additional restrictions to which the purchaser of the book must agree, such as 'You may not show or lend your copy of this book to your colleagues, or to anyone else.' However, who in their right mind would buy a book which was sold with such restrictions attached to it?
Given the way open source capitalism works, I would not be surprised if someone produces a 'quick reference guide' that they give away, or writes a book on 'Using scipy.core in biology' that they sell for $88. Let a thousand flowers bloom.
Yes, I agree entirely. Travis, you are at perfect liberty to create commercial documentation for SciPy Core, but please don't object if others try to organise to create free open source documentation as well. Tim C
Tim Churches wrote:
Travis Oliphant wrote:
Tim Churches wrote:
Travis Oliphant wrote:
Tim Churches wrote:
Travis, are you saying that this agreement only allows a single person to read the single printed copy? If so, I think you need a formally worded legal license to make that stick - certainly Australian copyright law (nor copyright law in other countries, I suspect) does not provide any support for such severe restrictions in the use of a printed document. Under copyright law, you may not make unauthorised copies of a printed document, but you can certainly lend that copy to others, or sell or give it to them, or share it as a bench manual.
I'm just stating what I think is fair. I'm not going to try and use the power of the Australian state or any other to try and enforce it.
My point was that you won't get any help from the State if what you think is fair extends to restricting who can read a single printed copy of your documentation. You will need to resort to tort law to enforce such restrictions, and thus you really need a formal documentation license, if that is your aim.
Many of those downloads are for "t[y|i]re-kicking" - potential users determining whether it meets their needs. If those potential users have to pay for documentation up-front, then a large proportion will go elsewhere. The rest are probably existing NumPy users upgrading (or testing the upgrade waters). The latter group may well pay for documentation, but how large is that group? For example, how many people are subscribed to the numpy-discussion mailing list?
Don't know. But, there is enough free documentation to get started, I think. Lack of documentation has hampered more people than cost of existing documentation, I think.
I have to disagree on this point. Granted the existing documentation for NumPy is not fantastic - some aspects of it are positively obscure - but overall it is better than good-enough, we have found, and was not a barrier to our decision to use NumPy. Having to cough up $50 to even peek at the documentation would be a far, far greater barrier to uptake than the occasional obscure wording of some of the function descriptions, IMHO.
Travis, although many of us are grateful for your efforts on SciPy Core, no-one made you do it. If you wanted to earn (more) money by doing other things, you should have done them.
I'm really thinking about the future here. If I can succesfully raise money to support work on this using a simple time-delay documentation encouragement, then perhaps others will do the same, and we can all have more. Waiting for people to "donate" their time to develop scientific python is rather slow.... I've been freely donating time for a long time, and there are few who help. So, we'll try a slightly different route and see where that goes.
Yes, fair enough. My point was that 7 years is far too long a time delay. Given that SciPy Core will probably take another year to become rock-solid, I would happily buy several copies of your documentation at $50 per copy if I knew that in a year the documentation could be freely distributed to all God's children. But in 7 years? Nope, too long to wait, not interested in supporting that.
I think there needs to be some community debate about this. Is there sufficient interest for people other than Travis to start with the Numeric documentation and update it as necessary to become a free SciPy Core documentation? The NumPy documentation is available in HTML format as the basis of this - perhaps the original source (LaTeX?) for the Numeric docs is also available?
I don't know why you would want to undermine my efforts in this way by duplicating effort.
Travis, I don't want to undermine your efforts, but you must understand that one of the attractions of NumPy and thus Scipy Core is that they are free, open source software, which implies that there exists adequate free, open source documentation for them, or if such free, open source documentation does not exist, then taht users are collectively at liberty to create it. That's a basic FOSS tenet. What you are are proposing is the creation of proprietary documentation for SciPy Core. No-one objects to this, but only if it is supplementary to free, open source "core" documentation, not instead of it.
Perhaps, instead you could have people donate $$ instead of time to releasing the documentation. I give away copies of the documentation to people who participate in the development process all the time (and that comes off the total price --- though I haven't advertised this as of yet). So, why don't you encourage people who don't have the money to contribute to the project instead.
I understand that open source software and its documentation don't just appear out of thin air, and I fully support the idea of funded or collectively-commissioned open source development. But only if the results of that funded or commissioned development is, in fact, free and open sourced. By preventing free distribution of the documentation you are creating for 7 years, the end product cannot even remotely be described as open source, thus personally I am disinterested in funding it. If the delay until open sourcing was just one year, then that's a different matter, but you do not seem to be proposing that.
Hence I think the NumPy/SciPy Core user community should establish a SciPy Core documentation project, with the aim of updating and enhancing the existing NumPy documentation so that it covers the new and changed features of SciPy Core, and making that documentation available on teh same free, open source basis as NumPy/SciPy Core itself.
To that end, are the original LaTeX or whatever sources for the currenet NumPy documenattion available somewhere (apart from the HTML and PDF versions, that is).
Tim C
------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
First of all, I certainly don't want to prevent Travis from recovering something for all the effort he has put into scipy_core. Nor do I wish to discourage anyone that wishes to provide alternative free documentation if they so choose. But I will note some facts about numarray documentation below that may prove useful to anyone considering the latter. On Oct 4, 2005, at 1:32 AM, Tim Churches wrote:
Paul F. Dubois wrote:
The original sources were in Framemaker. I am not positive where they are. In any case they are copyrighted by the Regents of the University of California. I am not a lawyer and don't know what the consequences of that are. LLNL granted free distribution of the printed document with the Numeric source code but I don't know what their position would be on using their copyrighted text in a new document or on giving away the sources.
The numarray User's Manual was derived from the Numpy manual that LLNL originally sponsored David Ascher to write (if that is incorrect I'm sure Paul will correct me). We dutifully propagated the legal notice in the original to the numarray version. Although IANAL I'll note that the text seems to permit changes by others, but it also seems mis-worded as it refers to software, not documentation regarding the rights. What that really means in the end I'm not sure. In any case, Jochen Kupper (I hope I have that right) converted the format from Framemaker to the Python document latex style. The source for the numarray version is currently on sourceforge (under the numarray/doc directory). I'll also note much of the capabilities in scipy_core are very similar to those of numarray. There are differences, though I don't believe it would take a great deal of work to udpate the numarray version to reflect these (e.g. the changes in the types system, how rank-0 issues, the C-API, object array details and the names of the standard packages within scipy_core.)
OK, thanks Paul. That may have implications for you, Travis, if you are planning to base your SciPy Core book on the existing NumPy documentation.
From what I've seen of it, I don't believe it is based at all on the original manual or any derivative, but I'll leave that for Travis to comment further on. Perry
Perry Greenfield wrote:
First of all, I certainly don't want to prevent Travis from recovering something for all the effort he has put into scipy_core. Nor do I wish to discourage anyone that wishes to provide alternative free documentation if they so choose. But I will note some facts about numarray documentation below that may prove useful to anyone considering the latter.
On Oct 4, 2005, at 1:32 AM, Tim Churches wrote:
Paul F. Dubois wrote:
The original sources were in Framemaker. I am not positive where they are. In any case they are copyrighted by the Regents of the University of California. I am not a lawyer and don't know what the consequences of that are. LLNL granted free distribution of the printed document with the Numeric source code but I don't know what their position would be on using their copyrighted text in a new document or on giving away the sources.
The numarray User's Manual was derived from the Numpy manual that LLNL originally sponsored David Ascher to write (if that is incorrect I'm sure Paul will correct me). We dutifully propagated the legal notice in the original to the numarray version. Although IANAL I'll note that the text seems to permit changes by others, but it also seems mis-worded as it refers to software, not documentation regarding the rights. What that really means in the end I'm not sure.
In any case, Jochen Kupper (I hope I have that right) converted the format from Framemaker to the Python document latex style. The source for the numarray version is currently on sourceforge (under the numarray/doc directory). I'll also note much of the capabilities in scipy_core are very similar to those of numarray. There are differences, though I don't believe it would take a great deal of work to udpate the numarray version to reflect these (e.g. the changes in the types system, how rank-0 issues, the C-API, object array details and the names of the standard packages within scipy_core.)
OK, thanks Paul. That may have implications for you, Travis, if you are planning to base your SciPy Core book on the existing NumPy documentation.
From what I've seen of it, I don't believe it is based at all on the original manual or any derivative, but I'll leave that for Travis to comment further on.
Perry
Perry, It would be helpful if you gave some indication of your organization's intention with respect to numarray. Will it be maintained, as in the past, fully in the public domain and without charge for either the code or the API information needed to make use of the code? New versions have been produced every few months, will this continue? Colin W.
Exactly, I'm wondering the same questions. Provided that numarray is an excellent and mature piece of code, I'd like to hear a declaration of principles on that subject. Regards, A Dijous 06 Octubre 2005 01:55, Colin J. Williams va escriure:
Perry,
It would be helpful if you gave some indication of your organization's intention with respect to numarray.
Will it be maintained, as in the past, fully in the public domain and without charge for either the code or the API information needed to make use of the code?
New versions have been produced every few months, will this continue?
Colin W.
------------------------------------------------------- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
--
0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-"
A Dijous 06 Octubre 2005 11:52, Francesc Altet va escriure:
Exactly, I'm wondering the same questions. Provided that numarray is an excellent and mature piece of code, I'd like to hear a declaration of principles on that subject.
Er, I think I'd better said "declaration of intentions", sorry. Cheers, --
0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-"
Sorry for the tardy response. Transatlantic flights don't yet have convenient internet service. I've been meaning to put out a message of this sort soon anyway. This is few days earlier than I was planning, but close enough. Our basic position has been and continues to be that if scipy_core provides all the capabilities that we need, we will switch to it. We have been involved in installing it on the platforms we need it for (namely Solaris, which has proven difficult to build on) and testing it (which is ongoing). So far things look pretty promising and barring any unforseen problems, we will likely begin porting recarray to it next week. As Travis has already mentioned, the whole point of scipy_core was to unify the two existing projects, not introduce a 3rd. I have been involved all along in design and interface discussions with Travis on this project. We will maintain numarray until the point at which we switch all of our code to scipy_core (i.e., all libraries and applications that depend on it). This may take several months for some (likely the most work is for C extensions that use the numarray C-API). When this is complete (including testing), we may support numarray for a while in the sense of answering questions, but it would not likely see any more new releases after that point. We do not have the resources to support two different numeric packages indefinitely. We will report on our progress in this switchover (most likely our libraries and applications will be set up to work with both in the interim). While I appreciate the pain that this may cause those who have written C-extensions for numarray, it's hard to deny that unification will bring great benefits. It's as much pain for us as anyone. It should not be as painful to port python code since scipy_core should support all capabilities. But some changes will be needed since things are not always done the same way (e.g., dtype for type). Perry Francesc Altet wrote:
Exactly, I'm wondering the same questions. Provided that numarray is an excellent and mature piece of code, I'd like to hear a declaration of principles on that subject.
Regards,
A Dijous 06 Octubre 2005 01:55, Colin J. Williams va escriure:
Perry,
It would be helpful if you gave some indication of your organization's intention with respect to numarray.
Will it be maintained, as in the past, fully in the public domain and without charge for either the code or the API information needed to make use of the code?
New versions have been produced every few months, will this continue?
Colin W.
A Divendres 07 Octubre 2005 14:51, Perry Greenfield va escriure:
Our basic position has been and continues to be that if scipy_core provides all the capabilities that we need, we will switch to it. We have been involved in installing it on the platforms we need it for (namely Solaris, which has proven difficult to build on) and testing it (which is ongoing). So far things look pretty promising and barring any unforseen problems, we will likely begin porting recarray to it next week. As Travis has already mentioned, the whole point of scipy_core was to unify the two existing projects, not introduce a 3rd. I have been involved all along in design and interface discussions with Travis on this project.
Ok. That's clear enough and satifies my curiosity, thank you. I must confess, though, that I'm a bit disappointed becuase I was hoping that numarray, now that has arrived to maturity, was going to stay for long time (as any other good piece of software deserves). Anyway, as a long-time user of numarray I can't express enough my gratitude towards you and your team for suporting and enhancing a beast like numarray, that introduced a lot of new features that missed Numeric and that without it all of our current projects (and I guess many others around the world) simply would not have been possible.
We will maintain numarray until the point at which we switch all of our code to scipy_core (i.e., all libraries and applications that depend on it). This may take several months for some (likely the most work is for C extensions that use the numarray C-API).
Yeah, I do think so. However, what it worries me is, in my (limited) experience, that substituting large packages like Numeric or numarray, is not a trivial task at all (after all, how much time took until numarray was able to be a good substitute of Numeric?). So, I forsee a transitional time no shorter than a year before arriving to the high standards of quality that numarray has nowadays. This is why I'm not precisely eager to quickly switch to scipy_core until it has proven to be, at least, as solid as it is numarray. Having said that, we are in the mood of offering our implementation of a NestedRecArray class that allows nested fields in RecArray objects. This class has been included in PyTables for some months and has proven to be stable, comes with a nice set of unit tests, and is highly efficient (at least, as much as RecArray for most operations). Also, until ready-for-production scipy_core arrives, I'd ask you (and the maintainers of scipy_core) to provide an array protocol to share data as efficiently as possible between numarray and scipy_core, just to easy the transition between the packages. If you want, we will be happy to collaborate on that area as well.
While I appreciate the pain that this may cause those who have written C-extensions for numarray, it's hard to deny that unification will bring great benefits. It's as much pain for us as anyone.
Sure, but migration work is not the biggest problem (hopefully) for us. As I said before, the key point to migrate to scipy_core is to make sure that is stable enough, featured enough, coner-cases-proof enough and well-documented enough as it is numarray now. Thanks again for all your work in numarray, --
0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-"
Francesc Altet wrote:
Also, until ready-for-production scipy_core arrives, I'd ask you (and the maintainers of scipy_core) to provide an array protocol to share data as efficiently as possible between numarray and scipy_core, just to easy the transition between the packages. If you want, we will be happy to collaborate on that area as well.
There is an array protocol in place already (see the Array Interface section on numeric.scipy.org). I think it is fully supported in numarray. Also, I have a PEP for placing a simple array object in Python that is nothing more than a shell for passing data around. If somebody would like to push that forward they are welcome. Right now what I have is available in an SVN server. http://svn.scipy.org/svn/PEP get it with svn co http://svn.scipy.org/svn/PEP PEP -Travis
All, following all this up and down I decide to write a short email for two reasons: First of all I want to thank all developers of Numeric, numarray, and the yet to fly scipy_core, esp. Perry/Todd and Travis. I hope that this apparent joining of forces will really get Numeric Python a big step ahead. On the other hand I have personally stepped down from using Python for larger numerical calculation projects, because it was too much of an hassle to get sysops convinced to install it, and because overall the hassles to follow releases, adopting code and explaining colleagues was to big to make up for the ease of coding compared to C++. Yep, there we are. I am REALLY looking forward to the day when I can start a larger project in Python again. I wish and hope that you guys are paving the road for me;) [1] Using scipy_core I would also be happy to work on public documentation, as that is where everybody using scipy_core can easily contribute his share. Maybe it would be a nice team effort to get the numarray Python-style documentation cut down and updated to a good and current reference-manual, pretty much a nicer and cross-linked version of the doc-strings, maybe with more of the examples that were discussed here before. I am sure that Travis writes a good user-manual, and, voila, both would be in the right place! To all the guys actually doing the work: Thank you very much, nevertheless! Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de Liberté, Égalité, Fraternité GnuPG key: CC1B0B4D (Part 3 you find in my messages before fall 2003.)
Jochen Küpper wrote:
All,
following all this up and down I decide to write a short email for two reasons:
First of all I want to thank all developers of Numeric, numarray, and the yet to fly scipy_core, esp. Perry/Todd and Travis. I hope that this apparent joining of forces will really get Numeric Python a big step ahead.
On the other hand I have personally stepped down from using Python for larger numerical calculation projects, because it was too much of an hassle to get sysops convinced to install it, and because overall the hassles to follow releases, adopting code and explaining colleagues was to big to make up for the ease of coding compared to C++. Yep, there we are. I am REALLY looking forward to the day when I can start a larger project in Python again. I wish and hope that you guys are paving the road for me;) [1]
Using scipy_core I would also be happy to work on public documentation, as that is where everybody using scipy_core can easily contribute his share. Maybe it would be a nice team effort to get the numarray Python-style documentation cut down and updated to a good and current reference-manual, pretty much a nicer and cross-linked version of the doc-strings, maybe with more of the examples that were discussed here before. I am sure that Travis writes a good user-manual, and, voila, both would be in the right place!
I actually do think that converting the numarray manual will be easier. Because it is closer in function to what current scipy is. Advanced indexing has all been explained (the PEP for SciPy explains what is in current SciPy a bit better --- especially when it comes to mixing slices and integer indexing arrays. So, I would start from there. Hopefully in response to Jochen's other question (regarding hassles of install) we can get to the point where scipy core is installed by default on everybody's system.... :-) No need to give up C++ coding either with weave and pyrex (and f2py which can wrap C-code as well). -Travis
Travis Oliphant wrote:
No need to give up C++ coding either with weave and pyrex
And SWIG and Boost::Python, which appears to have NumPy support...Has anyone used that, and can tell me about how well it works? -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception
Travis Oliphant
I actually do think that converting the numarray manual will be easier.
easier than?
Because it is closer in function to what current scipy is.
closer than what?
No need to give up C++ coding either with weave and pyrex (and f2py which can wrap C-code as well).
I don't really want to program C++ -- I want a simple environment that's available on the typical number cruncher... Therefore, having scipy on every system would be a solution;) Greetings, Jochen -- Einigkeit und Recht und Freiheit http://www.Jochen-Kuepper.de Liberté, Égalité, Fraternité GnuPG key: CC1B0B4D (Part 3 you find in my messages before fall 2003.)
A Dilluns 10 Octubre 2005 23:39, Travis Oliphant va escriure:
No need to give up C++ coding either with weave and pyrex (and f2py which can wrap C-code as well).
No, pyrex is not ready for C++ yet (at least natively, i.e. without C wrappers), but it would eventually be, with Greg permission. --
0,0< Francesc Altet http://www.carabos.com/ V V Cárabos Coop. V. Enjoy Data "-"
participants (7)
-
Chris Barker -
Colin J. Williams -
Francesc Altet -
Jochen Küpper -
Perry Greenfield -
Tim Churches -
Travis Oliphant