Andrew Kuchling <akuchlin@mems-exchange.org> writes:
You mean as separate modules like import curses import panel ? Hm. A panel object is associated with a window object, so it's created from a window method. This means you'd need to add window.new_panel() to PyCursesWindow_Methods[] and curses.update_panels(), curses.panel_above() and curses.panel_below() (or whatever they're called after we're through discussing this ;-)) to PyCurses_Methods[]. Also, the curses.panel_{above,below}() wrappers need access to the list_of_panels via find_po().
Thomas, do you feel capable of implementing it as a separate module, or should I work on it?
It's probably finished a lot sooner when you do it; OTOH, it would be fun to try it. Let's carry this discussion a bit further.
That's easy. The problem is that we want to extend those basic objects in _curses.
Sure, if we solve this for panel, the others are a SMOP. :-) tg
Thomas Gellekum writes:
Or better yet: import curses import curses.panel
Do these new functions have to be methods on the window objects, or can they be functions in the new module that take a window as a parameter? The underlying window object can certainly provide slots for the use of the panel (forms, ..., etc.) bindings, and simply initialize them to NULL (or whatever) for newly created windows.
Also, the curses.panel_{above,below}() wrappers need access to the list_of_panels via find_po().
There's no reason that underlying utilities can't be provided by _curses using a CObject. The Extending & Embedding manual has a section on using CObjects to provide a C API to a module without having to link to it directly.
That's easy. The problem is that we want to extend those basic objects in _curses.
Again, I'm curious about the necessity of this. I suspect it can be avoided. I think the approach I've hinted at above will allow you to avoid this, and will allow the panel (forms, ...) support to be added simply by adding additional modules as they are written and the underlying libraries are installed on the host. I know the question of including these modules in the core distribution has come up before, but the resurgence in interest in these makes me want to bring it up again: Does the curses package (and the associated C extension(s)) belong in the standard library, or does it make sense to spin out a distutils-based package? I've no objection to them being in the core, but it seems that the release cycle may want to diverge from Python's. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
Fred L. Drake, Jr. <fdrake@acm.org>:
Curses needs to be in the core for political reasons. Specifically, to support CML2 without requiring any extra packages or downloads beyond the stock Python interpreter. And what makes CML2 so constrained and so important? It's my bid to replace the Linux kernel's configuration machinery. It has many advantages over the existing config system, but the linux developers are *very* resistant to adding things to the kernel's minimum build kit. Python alone may prove too much for them to swallow (though there are hopeful signs they will); Python plus a separately downloadable curses module would definitely be too much. Guido attaches sufficient importance to getting Python into the kernel build machinery that he approved adding ncurses to the standard modules on that basis. This would be a huge design win for us, raising Python's visibility considerably. So curses must stay in the core. I don't have a requirement for panels; my present curses front end simulates them. But if panels were integrated into the core I could simplify the front-end code significantly. Every line I can remove from my stuff (even if it, in effect, is just migrating into the Python core) makes it easier to sell CML2 into the kernel. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> "Experience should teach us to be most on our guard to protect liberty when the government's purposes are beneficient... The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well meaning but without understanding." -- Supreme Court Justice Louis Brandeis
On the other hand you may want to be conservative. You already have to require Python 2.0 (I presume). The panel stuff will be available in 2.1 at the earliest. You probably shouldn't throw out your panel emulation until your code has already been accepted... --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum <guido@python.org>:
Yes, that's how I am currently expecting it to play out -- but if the 2.4.0 kernel is delayed another six months, I'd change my mind. I'll explain this, because python-dev people should grok what the surrounding politics and timing are. I actually debated staying with 1.5.2 as a base version. What changed my mind was two things. One: by going to 2.0 I could drop close to 600 lines and three entire support modules from CML2, slimming down its footprint in the kernel tree significantly (by more than 10% of the entire code volume, actually). Second: CML2 is not going to be seriously evaluated until 2.4.0 final is out. Linus made this clear when I demoed it for him at LWE. My best guess about when that will happen is late January into Februrary. By the time Red Hat issues its next distro after that (probably May or thenabouts) it's a safe bet 2.0 will be on it, and everywhere else. But if the 2.4.0 kernel slips another six months yet again, and our 2.1 commes out relatively quickly (like, just before the 9th Python Conference :-)) then we *might* have time to get 2.1 into the distros before CML2 gets the imprimatur. So, gentlemen, vote for panels to go in if you think the 2.4.0 kernel will be delayed yet again :-). -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Ideology, politics and journalism, which luxuriate in failure, are impotent in the face of hope and joy. -- P. J. O'Rourke
On Wed, Dec 13, 2000 at 05:03:59PM -0500, Eric S. Raymond wrote:
I don't think that is a very safe bet. Python 2.0 missed the Debian Potato boat. I have no idea when Woody is expected to be released but I expect it may take longer than that if history is any indication. Neil
I don't think that is a very safe bet. Python 2.0 missed the Debian Potato boat.
This may have had to do more with the unresolved GPL issues. I recently received a mail from Stallman indicating that an agreement with CNRI has been reached; they have agreed (in principle, at least) to specific changes to the CNRI license that will defuse the choice-of-law clause when it is combined with GPL-licensed code "in a non-separable way". A glitch here is that the BeOpen license probably has to be changed too, but I believe that that's all doable.
And who or what is Woody? Feeling-left-out, --Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, Dec 13, 2000 at 06:03:31PM -0500, Guido van Rossum wrote:
I can't remember the exact dates but I think Debian Potato was frozen before Python 2.0 was released. Once a Debian release is frozen packages are not upgraded except under unusual circumstances.
This is great news.
Woody would be another character from the Pixar movie "Toy Story" (just like Rex, Bo, Potato, Slink, and Hamm). I believe Bruce Perens used to work a Pixar. Debian uses a code name for the development release until a release number is assigned. This avoids some problems but has the disadvantage of confusing people who are not familiar with Debian. I should have said "the next stable release of Debian". Neil (aka nas@debian.org)
On Wed, Dec 13, 2000 at 06:03:31PM -0500, Guido van Rossum wrote:
One of the Debian releases. Dunno if it is the "next" release, but there ya go. Cheers, -g -- Greg Stein, http://www.lyra.org/
On Wed, Dec 13, 2000 at 06:03:31PM -0500, Guido van Rossum wrote:
This is very likely. Debian is very licence -- or at least GPL -- aware. Which is a pity, really, because I already prefer it over RedHat in all other cases (and RedHat is also pretty licence aware, just less piously, devoutly, beyond-practicality-IMHO dedicated to the GPL.)
I have no idea when Woody is expected to be released but I expect it may take longer than that if history is any indication.
BTW, I believe Debian uses a fairly steady release schedule, something like an unstable->stable switch every year or 6 months or so ? I seem to recall seeing something like that on the debian website, but can't check right now.
And who or what is Woody?
Woody is Debian's current development branch, the current bearer of the alias 'unstable'. It'll become Debian 2.3 (I believe, I don't pay attention to version numbers, I just run unstable :) once it's stabilized. 'potato' is the previous development branch, and currently the 'stable' branch. You can compare them with 'rawhide' and 'redhat-7.0', respectively :) (With the enormous difference that you can upgrade your debian install to a new version (even the devel version, or update your machine to the latest devel snapshot) while you are using it, without having to reboot ;) Note to the debian-pythoneers: woody still carries Python 1.5.2, not 2.0. Someone created a separate set of 2.0-packages, but they didn't include readline and gdbm support because of the licencing issues. (Posted on c.l.py sometime this week.) I'm *almost* tempted enough to learn enough about dpkg/.deb files to build my own licence-be-damned set, but it'd be a lot of work to mirror the current debian 1.5.2 set of packages (which include numeric, imaging, mxTools, GTK/GNOME, and a shitload of 3rd party modules) in 2.0. Ponder, maybe it could be done semi-automatically, from the src-deb's of those packages. By the way, in woody, there are 52 packages with 'python' in the name, and 32 with 'perl' in the name... Pity all of my perl-hugging hippy-friends are still blindly using RedHat, and refuse to listen to my calls from the Debian/Python-dark-side :-) Oh, and the names 'woody' and 'potato' came from the movie Toy Story, in case you wondered ;) -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
On Thu, Dec 14, 2000 at 01:05:34AM +0100, Thomas Wouters wrote:
I've had Python packages for Debian stable for a while. I guess I should have posted a link: http://arctrix.com/nas/python/debian/ Most useful modules are enabled.
I'm *almost* tempted enough to learn enough about dpkg/.deb files to build my own licence-be-damned set
Its quite easy. Debian source packages are basicly a diff. Applying the diff will create a "debian" directory and in that directory will be a makefile called "rules". Use the target "binary" to create new binary packages. Good things to know are that you must be in the source directory when you run the makefile (ie. ./debian/rules binary). You should be running a shell under fakeroot to get the install permissions right (running "fakeroot" will do). You need to have the Debian developer tools installed. There is a list somewhere on debian.org. "apt-get source <packagename>" will get, extract and patch a package ready for tweaking and building (handy for getting stuff from unstable to run on stable). This is too off topic for python-dev. If anyone needs more info they can email me directly. Neil
On Thu, Dec 14, 2000 at 01:05:34AM +0100, Thomas Wouters wrote:
By the way, in woody, there are 52 packages with 'python' in the name, and 32 with 'perl' in the name...
Ah, not true, sorry. I shouldn't have posted off-topic stuff after being awoken by machine-down-alarms ;) That was just what my reasonably-default install had installed. Debian has what looks like most CPAN modules as packages, too, so it's closer to a 110/410 spread (python/perl.) Still, not a bad number :) -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Thomas Wouters wrote:
About the GPL issue: as I understood Guido's post, RMS still regards the choice of law clause as being incompatible to the GPL (heck, doesn't this guy ever think about international trade terms, the United Nations Convention on International Sale of Goods or local law in one of the 200+ countries where you could deploy GPLed software... is the GPL only meant for US programmers ?). I am currently rewriting my open source licenses as well and among other things I chose to integrate a choice of law clause as well. Seeing RMS' view of things, I guess that my license will be regarded as incompatible to the GPL which is sad even though I'm in good company... e.g. the Apache license, the Zope license, etc. Dual licensing is not possible as it would reopen the loop-wholes in the GPL I tried to fix in my license. Any idea on how to proceed ? Another issue: since Python doesn't link Python scripts, is it still true that if one (pure) Python package is covered by the GPL, then all other packages needed by that application will also fall under GPL ? Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
On Thu, Dec 14, 2000 at 11:55:38AM +0100, M.-A. Lemburg wrote:
Only RMS is under the belief that the Apache license is incompatible. It is either clause 4 or 5 (I forget which) where we state that certain names (e.g. "Apache") cannot be used in derived products' names and promo materials. RMS views this as an "additional restriction on redistribution", which is apparently not allowed by the GPL. We (the ASF) generally feel he is being a royal pain in the ass with this. We've sent him a big, long email asking for clarification / resolution, but haven't heard back (we sent it a month or so ago). Basically, his FUD creates views such as yours ("the Apache license is incompatible with the GPL") because people just take his word for it. We plan to put together a web page to outline our own thoughts and licensing beliefs/philosophy. We're also planning to rev our license to rephrase/alter the particular clause, but for logistic purposes (putting the project name in there ties it to the particular project; we want a generic ASF license that can be applied to all of the projects without a search/replace). At this point, the ASF is taking the position of ignoring him and his controlling attitude(*) and beliefs. There is the outstanding letter to him, but that doesn't really change our point of view. Cheers, -g (*) for a person espousing freedom, it is rather ironic just how much of a control freak he is (stemming from a no-compromise position to guarantee peoples' freedoms, he always wants things done his way) -- Greg Stein, http://www.lyra.org/
[MAL]
About the GPL issue: as I understood Guido's post, RMS still regards the choice of law clause as being incompatible to the GPL
Yes. Actually, I don't know what RMS really thinks -- his public opinions on legal issues appear to be echoes of what Eben Moglen tells him. Like his views or not, Moglen is a tenured law professor
Yes.
is the GPL only meant for US programmers ?).
No. Indeed, that's why the GPL is grounded in copyright law, because copyright law is the most uniform (across countries) body of law we've got. Most commentary I've seen suggests that the GPL has its *weakest* legal legs in the US!
Yes.
You can wait to see how the CNRI license turns out, then copy it if it's successful; you can approach the FSF directly; you can stop trying to do it yourself and reuse some license that's already been blessed by the FSF; or you can give up on GPL compatibility (according to the FSF). I don't see any other choices.
Sorry, couldn't make sense of the question. Just as well, since you should ask about it on a GNU forum anyway <wink>.
Tim Peters wrote:
But it's his piece of work, isn't it ? He's the one who can change it.
Strange, then how come he sees the choice of law clause as a problem: without explicitely ruling out the applicability of the UN CISC, this clause is waived by it anyway... at least according to a specialist on software law here in Germany.
Huh ? Just an example: in Germany customer rights assure a 6 month warranty on everything you buy or obtain in some other way. Liability is another issue: there are some very unpleasant laws which render most of the "no liability" paragraphs in licenses useless in Germany. Even better: since the license itself is written in English a German party could simply consider the license non-binding, since he or she hasn't agreed to accept contract in foreign languages. France has similar interpretations.
I guess I'll go with the latter.
Isn't this question (whether the GPL virus applies to byte-code as well) important to Python programmers as well ? Oh well, nevermind... it's still nice to hear that CNRI and RMS have finally made up their minds to render Python GPL-compatible -- whatever this means ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
I'm not going to argue about the GPL. Take it up with the FSF! I will say that if you do get the FSF's attention, Moglen will have an instant counter to any objection you're likely to raise -- he's been thinking about this for 10 years, and he's heard it all. And in our experience, RMS won't commit to anything before running it past Moglen. [MAL]
But it's his [RMS's] piece of work, isn't it ? He's the one who can change it.
Akin to saying Python is Guido's piece of work. Yes, no, kinda, more true at some times than others, ditto respects. RMS has consistently said that any changes for the next version of the GPL will take at least a year, due to extensive legal review required first. Would be more clearly true to say that the first version of the GPL was RMS's alone -- but version 2 came out in 1991.
Guido quoted the text of your Wed, 06 Sep 2000 14:19:09 +0200 "Re: [License-py20] Re: GPL incompability as seen from Europe" msg to Moglen, who dismissed it almost offhandedly as "layman's commentary". You'll have to ask him why: MAL, we're not lawyers. We're incompetent to have this discussion -- or at least I am, and Moglen thinks you are too <wink>.
[Tim]
Sorry, couldn't make sense of the question. Just as well, since you should ask about it on a GNU forum anyway <wink>.
[MAL]
Isn't this question (whether the GPL virus applies to byte-code as well) important to Python programmers as well ?
I don't know -- like I said, I couldn't make sense of the question, i.e. I couldn't figure out what it is you're asking. I *suspect* it's based on a misunderstanding of the GPL; for example, gcc is a GPL'ed application that requires stuff from the OS in order to do its job of compiling, but that doesn't mean that every OS it runs on falls under the GPL. The GPL contains no restrictions on *use*, it restricts only copying, modifying and distributing (the specific rights granted by copyright law). I don't see any way to read the GPL as restricting your ability to distribute a GPL'ed program P on its own, no matter what the status of the packages that P may rely upon for operation. The GPL is also not viral in the sense that it cannot infect an unwitting victim. Nothing whatsoever you do or don't do can make *any* other program Q "fall under" the GPL -- only Q's owner can set the license for Q. The GPL purportedly can prevent you from distributing (but not from using) a program that links with a GPL'ed program, but that doesn't appear to be what you're asking about. Or is it? If you were to put, say, mxDateTime, under the GPL, then yes, I believe the FSF would claim I could not distribute my program T that uses mxDateTime unless T were also under the GPL or a GPL-compatible license. But if mxDateTime is not under the GPL, then nothing I do with T can magically change the mxDateTime license to the GPL (although if your mxDateTime license allows me to redistribute mxDateTime under a different license, then it allows me to ship a copy of mxDateTime under the GPL). That said, the whole theory of GPL linking is muddy to me, especially since the word "link" (and its variants) doesn't appear in the GPL.
I'm not sure it means anything yet. CNRI and the FSF believed they reached agreement before, but that didn't last after Moglen and Kahn each figured out what the other was really suggesting.
Tim Peters wrote:
I'm not going to argue about the GPL. Take it up with the FSF!
Sorry, I got a bit carried away -- I don't want to take it up with the FSF, simply because I couldn't care less. What's bugging me is that this one guy is splitting the OSS world in two even though both halfs actually want the same thing: software which you can use for free with full source code. I find that a very poor situation.
Point taken.
I'm not a lawyer either, but I am able to apply common sense and know about German trade laws. Anyway, here a reference which covers all the controversial subjects. It's in German, but these guys qualify as lawyers ;-) ... http://www.ifross.de/ifross_html/index.html There's also a book on the subject in German which covers all aspects of software licensing. Here's the reference in case anyone cares: Jochen Marly, Softwareüberlassungsverträge C.H. Beck, München, 2000
This is very controversial: if an application Q needs a GPLed library P to work, then P and Q form a new whole in the sense of the GPL. And this even though P wasn't even distributed together with Q. Don't ask me why, but that's how RMS and folks look at it. It can be argued that the dynamic linker actually integrates P into Q, but is the same argument valid for a Python program Q which relies on a GPLed package P ? (The relationship between Q and P is one of providing interfaces -- there is no call address patching required for the setup to work.)
No. What's viral about the GPL is that you can turn an application into a GPLed one by merely linking the two together -- that's why e.g. the libc is distributed under the LGPL which doesn't have this viral property.
True.
Oh boy... -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
"M.-A. Lemburg" <mal@lemburg.com>:
I don't see how Q can *need* any particular library P to work. The most it can need is some library with an API which is compatible with P's. So I don't buy that argument. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
"GE" == Greg Ewing <greg@cosc.canterbury.ac.nz> writes:
GE> I don't see how Q can *need* any particular library P to GE> work. The most it can need is some library with an API which GE> is compatible with P's. So I don't buy that argument. It's been my understanding that the FSF's position on this is as follows. If the only functional implementation of the API is GPL'd software then simply writing your code against that API is tantamount to linking with that software. Their reasoning is that the clear intent of the programmer (shut up, Chad) is to combine the program with GPL code. As soon as there is a second, non-GPL implementation of the API, you're fine because while you may not distribute your program with the GPL'd software linked in, those who receive your software wouldn't be forced to combine GPL and non-GPL code. -Barry
Greg Ewing wrote:
It's the view of the FSF, AFAIK. You can't distribute an application in binary which dynamically links against libreadline (which is GPLed) on the user's machine, since even though you don't distribute libreadline the application running on the user's machine is considered the "whole" in terms of the GPL. FWIW, I don't agree with that view either, but that's probably because I'm a programmer and not a lawyer :) -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
"M" == M <mal@lemburg.com> writes:
M> It's the view of the FSF, AFAIK. You can't distribute an M> application in binary which dynamically links against M> libreadline (which is GPLed) on the user's machine, since even M> though you don't distribute libreadline the application running M> on the user's machine is considered the "whole" in terms of the M> GPL. M> FWIW, I don't agree with that view either, but that's probably M> because I'm a programmer and not a lawyer :) I'm not sure I agree with that view either, but mostly because there is a non-GPL replacement for parts of the readline API: http://www.cstr.ed.ac.uk/downloads/editline.html Don't know anything about it, so it may not be featureful enough for Python's needs, but if licensing is really a problem, it might be worth looking into. -Barry
On Fri, Dec 15, 2000 at 11:17:08AM -0500, Barry A. Warsaw wrote:
It doesn't work with the current readline module. It is much smaller than readline and works just as well in my experience. Would there be any interest in including a copy with the standard distribution? The license is quite nice (X11 type). Neil
Neil Schemenauer wrote:
+1 from here -- line editing is simply a very important part of an interactive prompt and readline is not only big, slow and full of strange surprises, but also GPLed ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
On Fri, Dec 15, 2000 at 04:03:04AM -0800, Neil Schemenauer wrote:
Definately +1 from here. Readline reminds me of the cold war, for some reason. (Actually, multiple reasons ;) I don't have time to do it myself, unfortunately, or I would. (Looking at editline has been on my TODO list for a while... :P) -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
[MAL]
Sorry, I got a bit carried away -- I don't want to take it up with the FSF, simply because I couldn't care less.
Well, nobody else is able to Pronounce on what the FSF believes or will do. Which tells me that you're not really interested in playing along with the FSF here after all -- which we both knew from the start anyway <wink>.
What's bugging me is that this one guy is splitting the OSS world
There are many people on the FSF bandwagon. I'm not one of them, but I can count.
RMS would not agree that both halves want the same thing; to the contrary, he's openly contemptuous of the Open Source movement -- which you also knew from the start.
[stuff about German law I won't touch with 12-foot schnitzel]
OTOH, a German FSF advocate assured me: I also tend to forget that the system of the law works different in the US as in Germany. In Germany something that most people will believe (called "common grounds") play a role in the court. So if you knew, because it is widely known what the GPL means, than it is harder to attack that in court. In the US, when something gets to court it doesn't matter at all what people believed about it. Heck, we'll let mass murderers go free if a comma was in the wrong place in a 1592 statute, or send a kid to jail for life for using crack cocaine instead of the flavor favored by stockbrokers <wink>. I hope the US is unique in that respect, but it does makes the GPL weaker here because even if *everyone* in our country believed the GPL means what RMS says it means, a US court would give that no weight in its logic-chopping.
Understood, but have you reread your question above, which I've said twice I can't make sense of? That's not what you were asking about. Your question above asks, if anything, the opposite: the *application* Q is GPL'ed, and the question above asks whether that means the *Ps* it depends on must also be GPL'ed. To the best of my ability, I've answered "NO" to that one, and "YES" to the question it appears you meant to ask.
As before, I believe the FSF will say YES. Unless there's also a non-GPL'ed implementation of the same interface that people could use just as well. See my extended mxDateTime example too.
No, you cannot. You can link them together all day without any hassle. What you cannot do is *distribute* it unless the aggregate is first placed under the GPL (or a GPL-compatible license) too. If you distribute it without taking that step, that doesn't turn it into a GPL'ed application either -- in that case you've simply (& supposedly) violated the license on P, so your distribution was simply (& supposedly) illegal. And that is in fact the end result that people who knowingly use the GPL want (granting that it appears most people who use the GPL do so unknowing of its consequences).
-- that's why e.g. the libc is distributed under the LGPL which doesn't have this viral property.
You should read RMS on why glibc is under the LGPL: http://www.fsf.org/philosophy/why-not-lgpl.html It will at least disabuse you of the notion that RMS and you are after the same thing <wink>.
Tim Peters wrote:
I know, it was backwards. Take an example: I have a program which wants to process MP3 files in some way. Now because of some stroke is luck, all Python MP3 modules out there are covered by the GPL. Now I could write an application which uses a certain interface and then tell the user to install the MP3 module separately. As Barry mentioned, this setup will cause distribution of my application to be illegal because I could have only done so by putting the application under the GPL.
:-) Let's stop this discussion and get back to those cheerful things like Christmas Bells and Santa Clause... :-) -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
Tim Peters wrote: ...
The GNU license is transitive. It automatically extends on other parts of a project, unless they are identifiable, independent developments. As soon as a couple of modules is published together, based upon one GPL-ed module, this propagates. I think this is what MAL meant? Anyway, I'd be interested to hear what the GNU forum says. ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com
Eric S. Raymond writes:
So, gentlemen, vote for panels to go in if you think the 2.4.0 kernel will be delayed yet again :-).
Politics aside, I think development of curses-related extensions like panels and forms doesn't need to be delayed. I've posted what I think are relavant technical comments already, and leave it up to the developers of any new modules to get them written -- I don't know enough curses to offer any help there. Regardless of how the curses package is distributed and deployed, I don't see any reason to delay development in its existing location in the Python CVS repository. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
On Wed, Dec 13, 2000 at 05:03:59PM -0500, Eric S. Raymond wrote:
The kernel is not going to be delayed that much. Linus wants it to go out this month. Worst case, I could see January. But no way on six months. But as Fred said: that should not change panels going into the curses support at all. You can always have a "compat.py" module in CML2 that provides functionality for prior-to-2.1 releases of Python. I'd also be up for a separate _curses_panels module, loaded into the curses package. Cheers, -g -- Greg Stein, http://www.lyra.org/
Greg Stein <gstein@lyra.org>:
I know what Linus wants. That's why I'm estimating end of January or earlier Februrary -- the man's error curve on these estimates has a certain, er, *consistency* about it. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Alcohol still kills more people every year than all `illegal' drugs put together, and Prohibition only made it worse. Oppose the War On Some Drugs!
On Wed, Dec 13, 2000 at 10:19:01AM -0500, Fred L. Drake, Jr. wrote:
Panels and windows have a 1-1 association, but they're separate objects. The window.new_panel function could become just a method which takes a window as its first argument; it would only need the TypeObject for PyCursesWindow, in order to do typechecking.
Also, the curses.panel_{above,below}() wrappers need access to the list_of_panels via find_po().
The list_of_panels is used only in the curses.panel module, so it could be private to that module, since only panel-related functions care about it. I'm ambivalent about the list_of_panels. It's a linked list storing (PyWindow, PyPanel) pairs. Probably it should use a dictionary instead of implementing a little list, just to reduce the amount of code.
Consensus seemed to be to leave it in; I'd have no objection to removing it, but either course is fine with me. So, I suggest we create _curses_panel.c, which would be available as curses.panel. (A panel.py module could then add any convenience functions that are required.) Thomas, do you want to work on this, or should I? --amk
Thomas Gellekum writes:
Or better yet: import curses import curses.panel
Do these new functions have to be methods on the window objects, or can they be functions in the new module that take a window as a parameter? The underlying window object can certainly provide slots for the use of the panel (forms, ..., etc.) bindings, and simply initialize them to NULL (or whatever) for newly created windows.
Also, the curses.panel_{above,below}() wrappers need access to the list_of_panels via find_po().
There's no reason that underlying utilities can't be provided by _curses using a CObject. The Extending & Embedding manual has a section on using CObjects to provide a C API to a module without having to link to it directly.
That's easy. The problem is that we want to extend those basic objects in _curses.
Again, I'm curious about the necessity of this. I suspect it can be avoided. I think the approach I've hinted at above will allow you to avoid this, and will allow the panel (forms, ...) support to be added simply by adding additional modules as they are written and the underlying libraries are installed on the host. I know the question of including these modules in the core distribution has come up before, but the resurgence in interest in these makes me want to bring it up again: Does the curses package (and the associated C extension(s)) belong in the standard library, or does it make sense to spin out a distutils-based package? I've no objection to them being in the core, but it seems that the release cycle may want to diverge from Python's. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
Fred L. Drake, Jr. <fdrake@acm.org>:
Curses needs to be in the core for political reasons. Specifically, to support CML2 without requiring any extra packages or downloads beyond the stock Python interpreter. And what makes CML2 so constrained and so important? It's my bid to replace the Linux kernel's configuration machinery. It has many advantages over the existing config system, but the linux developers are *very* resistant to adding things to the kernel's minimum build kit. Python alone may prove too much for them to swallow (though there are hopeful signs they will); Python plus a separately downloadable curses module would definitely be too much. Guido attaches sufficient importance to getting Python into the kernel build machinery that he approved adding ncurses to the standard modules on that basis. This would be a huge design win for us, raising Python's visibility considerably. So curses must stay in the core. I don't have a requirement for panels; my present curses front end simulates them. But if panels were integrated into the core I could simplify the front-end code significantly. Every line I can remove from my stuff (even if it, in effect, is just migrating into the Python core) makes it easier to sell CML2 into the kernel. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> "Experience should teach us to be most on our guard to protect liberty when the government's purposes are beneficient... The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well meaning but without understanding." -- Supreme Court Justice Louis Brandeis
On the other hand you may want to be conservative. You already have to require Python 2.0 (I presume). The panel stuff will be available in 2.1 at the earliest. You probably shouldn't throw out your panel emulation until your code has already been accepted... --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido van Rossum <guido@python.org>:
Yes, that's how I am currently expecting it to play out -- but if the 2.4.0 kernel is delayed another six months, I'd change my mind. I'll explain this, because python-dev people should grok what the surrounding politics and timing are. I actually debated staying with 1.5.2 as a base version. What changed my mind was two things. One: by going to 2.0 I could drop close to 600 lines and three entire support modules from CML2, slimming down its footprint in the kernel tree significantly (by more than 10% of the entire code volume, actually). Second: CML2 is not going to be seriously evaluated until 2.4.0 final is out. Linus made this clear when I demoed it for him at LWE. My best guess about when that will happen is late January into Februrary. By the time Red Hat issues its next distro after that (probably May or thenabouts) it's a safe bet 2.0 will be on it, and everywhere else. But if the 2.4.0 kernel slips another six months yet again, and our 2.1 commes out relatively quickly (like, just before the 9th Python Conference :-)) then we *might* have time to get 2.1 into the distros before CML2 gets the imprimatur. So, gentlemen, vote for panels to go in if you think the 2.4.0 kernel will be delayed yet again :-). -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Ideology, politics and journalism, which luxuriate in failure, are impotent in the face of hope and joy. -- P. J. O'Rourke
On Wed, Dec 13, 2000 at 05:03:59PM -0500, Eric S. Raymond wrote:
I don't think that is a very safe bet. Python 2.0 missed the Debian Potato boat. I have no idea when Woody is expected to be released but I expect it may take longer than that if history is any indication. Neil
I don't think that is a very safe bet. Python 2.0 missed the Debian Potato boat.
This may have had to do more with the unresolved GPL issues. I recently received a mail from Stallman indicating that an agreement with CNRI has been reached; they have agreed (in principle, at least) to specific changes to the CNRI license that will defuse the choice-of-law clause when it is combined with GPL-licensed code "in a non-separable way". A glitch here is that the BeOpen license probably has to be changed too, but I believe that that's all doable.
And who or what is Woody? Feeling-left-out, --Guido van Rossum (home page: http://www.python.org/~guido/)
On Wed, Dec 13, 2000 at 06:03:31PM -0500, Guido van Rossum wrote:
I can't remember the exact dates but I think Debian Potato was frozen before Python 2.0 was released. Once a Debian release is frozen packages are not upgraded except under unusual circumstances.
This is great news.
Woody would be another character from the Pixar movie "Toy Story" (just like Rex, Bo, Potato, Slink, and Hamm). I believe Bruce Perens used to work a Pixar. Debian uses a code name for the development release until a release number is assigned. This avoids some problems but has the disadvantage of confusing people who are not familiar with Debian. I should have said "the next stable release of Debian". Neil (aka nas@debian.org)
On Wed, Dec 13, 2000 at 06:03:31PM -0500, Guido van Rossum wrote:
One of the Debian releases. Dunno if it is the "next" release, but there ya go. Cheers, -g -- Greg Stein, http://www.lyra.org/
On Wed, Dec 13, 2000 at 06:03:31PM -0500, Guido van Rossum wrote:
This is very likely. Debian is very licence -- or at least GPL -- aware. Which is a pity, really, because I already prefer it over RedHat in all other cases (and RedHat is also pretty licence aware, just less piously, devoutly, beyond-practicality-IMHO dedicated to the GPL.)
I have no idea when Woody is expected to be released but I expect it may take longer than that if history is any indication.
BTW, I believe Debian uses a fairly steady release schedule, something like an unstable->stable switch every year or 6 months or so ? I seem to recall seeing something like that on the debian website, but can't check right now.
And who or what is Woody?
Woody is Debian's current development branch, the current bearer of the alias 'unstable'. It'll become Debian 2.3 (I believe, I don't pay attention to version numbers, I just run unstable :) once it's stabilized. 'potato' is the previous development branch, and currently the 'stable' branch. You can compare them with 'rawhide' and 'redhat-7.0', respectively :) (With the enormous difference that you can upgrade your debian install to a new version (even the devel version, or update your machine to the latest devel snapshot) while you are using it, without having to reboot ;) Note to the debian-pythoneers: woody still carries Python 1.5.2, not 2.0. Someone created a separate set of 2.0-packages, but they didn't include readline and gdbm support because of the licencing issues. (Posted on c.l.py sometime this week.) I'm *almost* tempted enough to learn enough about dpkg/.deb files to build my own licence-be-damned set, but it'd be a lot of work to mirror the current debian 1.5.2 set of packages (which include numeric, imaging, mxTools, GTK/GNOME, and a shitload of 3rd party modules) in 2.0. Ponder, maybe it could be done semi-automatically, from the src-deb's of those packages. By the way, in woody, there are 52 packages with 'python' in the name, and 32 with 'perl' in the name... Pity all of my perl-hugging hippy-friends are still blindly using RedHat, and refuse to listen to my calls from the Debian/Python-dark-side :-) Oh, and the names 'woody' and 'potato' came from the movie Toy Story, in case you wondered ;) -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
On Thu, Dec 14, 2000 at 01:05:34AM +0100, Thomas Wouters wrote:
I've had Python packages for Debian stable for a while. I guess I should have posted a link: http://arctrix.com/nas/python/debian/ Most useful modules are enabled.
I'm *almost* tempted enough to learn enough about dpkg/.deb files to build my own licence-be-damned set
Its quite easy. Debian source packages are basicly a diff. Applying the diff will create a "debian" directory and in that directory will be a makefile called "rules". Use the target "binary" to create new binary packages. Good things to know are that you must be in the source directory when you run the makefile (ie. ./debian/rules binary). You should be running a shell under fakeroot to get the install permissions right (running "fakeroot" will do). You need to have the Debian developer tools installed. There is a list somewhere on debian.org. "apt-get source <packagename>" will get, extract and patch a package ready for tweaking and building (handy for getting stuff from unstable to run on stable). This is too off topic for python-dev. If anyone needs more info they can email me directly. Neil
On Thu, Dec 14, 2000 at 01:05:34AM +0100, Thomas Wouters wrote:
By the way, in woody, there are 52 packages with 'python' in the name, and 32 with 'perl' in the name...
Ah, not true, sorry. I shouldn't have posted off-topic stuff after being awoken by machine-down-alarms ;) That was just what my reasonably-default install had installed. Debian has what looks like most CPAN modules as packages, too, so it's closer to a 110/410 spread (python/perl.) Still, not a bad number :) -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Thomas Wouters wrote:
About the GPL issue: as I understood Guido's post, RMS still regards the choice of law clause as being incompatible to the GPL (heck, doesn't this guy ever think about international trade terms, the United Nations Convention on International Sale of Goods or local law in one of the 200+ countries where you could deploy GPLed software... is the GPL only meant for US programmers ?). I am currently rewriting my open source licenses as well and among other things I chose to integrate a choice of law clause as well. Seeing RMS' view of things, I guess that my license will be regarded as incompatible to the GPL which is sad even though I'm in good company... e.g. the Apache license, the Zope license, etc. Dual licensing is not possible as it would reopen the loop-wholes in the GPL I tried to fix in my license. Any idea on how to proceed ? Another issue: since Python doesn't link Python scripts, is it still true that if one (pure) Python package is covered by the GPL, then all other packages needed by that application will also fall under GPL ? Thanks, -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
On Thu, Dec 14, 2000 at 11:55:38AM +0100, M.-A. Lemburg wrote:
Only RMS is under the belief that the Apache license is incompatible. It is either clause 4 or 5 (I forget which) where we state that certain names (e.g. "Apache") cannot be used in derived products' names and promo materials. RMS views this as an "additional restriction on redistribution", which is apparently not allowed by the GPL. We (the ASF) generally feel he is being a royal pain in the ass with this. We've sent him a big, long email asking for clarification / resolution, but haven't heard back (we sent it a month or so ago). Basically, his FUD creates views such as yours ("the Apache license is incompatible with the GPL") because people just take his word for it. We plan to put together a web page to outline our own thoughts and licensing beliefs/philosophy. We're also planning to rev our license to rephrase/alter the particular clause, but for logistic purposes (putting the project name in there ties it to the particular project; we want a generic ASF license that can be applied to all of the projects without a search/replace). At this point, the ASF is taking the position of ignoring him and his controlling attitude(*) and beliefs. There is the outstanding letter to him, but that doesn't really change our point of view. Cheers, -g (*) for a person espousing freedom, it is rather ironic just how much of a control freak he is (stemming from a no-compromise position to guarantee peoples' freedoms, he always wants things done his way) -- Greg Stein, http://www.lyra.org/
[MAL]
About the GPL issue: as I understood Guido's post, RMS still regards the choice of law clause as being incompatible to the GPL
Yes. Actually, I don't know what RMS really thinks -- his public opinions on legal issues appear to be echoes of what Eben Moglen tells him. Like his views or not, Moglen is a tenured law professor
Yes.
is the GPL only meant for US programmers ?).
No. Indeed, that's why the GPL is grounded in copyright law, because copyright law is the most uniform (across countries) body of law we've got. Most commentary I've seen suggests that the GPL has its *weakest* legal legs in the US!
Yes.
You can wait to see how the CNRI license turns out, then copy it if it's successful; you can approach the FSF directly; you can stop trying to do it yourself and reuse some license that's already been blessed by the FSF; or you can give up on GPL compatibility (according to the FSF). I don't see any other choices.
Sorry, couldn't make sense of the question. Just as well, since you should ask about it on a GNU forum anyway <wink>.
Tim Peters wrote:
But it's his piece of work, isn't it ? He's the one who can change it.
Strange, then how come he sees the choice of law clause as a problem: without explicitely ruling out the applicability of the UN CISC, this clause is waived by it anyway... at least according to a specialist on software law here in Germany.
Huh ? Just an example: in Germany customer rights assure a 6 month warranty on everything you buy or obtain in some other way. Liability is another issue: there are some very unpleasant laws which render most of the "no liability" paragraphs in licenses useless in Germany. Even better: since the license itself is written in English a German party could simply consider the license non-binding, since he or she hasn't agreed to accept contract in foreign languages. France has similar interpretations.
I guess I'll go with the latter.
Isn't this question (whether the GPL virus applies to byte-code as well) important to Python programmers as well ? Oh well, nevermind... it's still nice to hear that CNRI and RMS have finally made up their minds to render Python GPL-compatible -- whatever this means ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
I'm not going to argue about the GPL. Take it up with the FSF! I will say that if you do get the FSF's attention, Moglen will have an instant counter to any objection you're likely to raise -- he's been thinking about this for 10 years, and he's heard it all. And in our experience, RMS won't commit to anything before running it past Moglen. [MAL]
But it's his [RMS's] piece of work, isn't it ? He's the one who can change it.
Akin to saying Python is Guido's piece of work. Yes, no, kinda, more true at some times than others, ditto respects. RMS has consistently said that any changes for the next version of the GPL will take at least a year, due to extensive legal review required first. Would be more clearly true to say that the first version of the GPL was RMS's alone -- but version 2 came out in 1991.
Guido quoted the text of your Wed, 06 Sep 2000 14:19:09 +0200 "Re: [License-py20] Re: GPL incompability as seen from Europe" msg to Moglen, who dismissed it almost offhandedly as "layman's commentary". You'll have to ask him why: MAL, we're not lawyers. We're incompetent to have this discussion -- or at least I am, and Moglen thinks you are too <wink>.
[Tim]
Sorry, couldn't make sense of the question. Just as well, since you should ask about it on a GNU forum anyway <wink>.
[MAL]
Isn't this question (whether the GPL virus applies to byte-code as well) important to Python programmers as well ?
I don't know -- like I said, I couldn't make sense of the question, i.e. I couldn't figure out what it is you're asking. I *suspect* it's based on a misunderstanding of the GPL; for example, gcc is a GPL'ed application that requires stuff from the OS in order to do its job of compiling, but that doesn't mean that every OS it runs on falls under the GPL. The GPL contains no restrictions on *use*, it restricts only copying, modifying and distributing (the specific rights granted by copyright law). I don't see any way to read the GPL as restricting your ability to distribute a GPL'ed program P on its own, no matter what the status of the packages that P may rely upon for operation. The GPL is also not viral in the sense that it cannot infect an unwitting victim. Nothing whatsoever you do or don't do can make *any* other program Q "fall under" the GPL -- only Q's owner can set the license for Q. The GPL purportedly can prevent you from distributing (but not from using) a program that links with a GPL'ed program, but that doesn't appear to be what you're asking about. Or is it? If you were to put, say, mxDateTime, under the GPL, then yes, I believe the FSF would claim I could not distribute my program T that uses mxDateTime unless T were also under the GPL or a GPL-compatible license. But if mxDateTime is not under the GPL, then nothing I do with T can magically change the mxDateTime license to the GPL (although if your mxDateTime license allows me to redistribute mxDateTime under a different license, then it allows me to ship a copy of mxDateTime under the GPL). That said, the whole theory of GPL linking is muddy to me, especially since the word "link" (and its variants) doesn't appear in the GPL.
I'm not sure it means anything yet. CNRI and the FSF believed they reached agreement before, but that didn't last after Moglen and Kahn each figured out what the other was really suggesting.
Tim Peters wrote:
I'm not going to argue about the GPL. Take it up with the FSF!
Sorry, I got a bit carried away -- I don't want to take it up with the FSF, simply because I couldn't care less. What's bugging me is that this one guy is splitting the OSS world in two even though both halfs actually want the same thing: software which you can use for free with full source code. I find that a very poor situation.
Point taken.
I'm not a lawyer either, but I am able to apply common sense and know about German trade laws. Anyway, here a reference which covers all the controversial subjects. It's in German, but these guys qualify as lawyers ;-) ... http://www.ifross.de/ifross_html/index.html There's also a book on the subject in German which covers all aspects of software licensing. Here's the reference in case anyone cares: Jochen Marly, Softwareüberlassungsverträge C.H. Beck, München, 2000
This is very controversial: if an application Q needs a GPLed library P to work, then P and Q form a new whole in the sense of the GPL. And this even though P wasn't even distributed together with Q. Don't ask me why, but that's how RMS and folks look at it. It can be argued that the dynamic linker actually integrates P into Q, but is the same argument valid for a Python program Q which relies on a GPLed package P ? (The relationship between Q and P is one of providing interfaces -- there is no call address patching required for the setup to work.)
No. What's viral about the GPL is that you can turn an application into a GPLed one by merely linking the two together -- that's why e.g. the libc is distributed under the LGPL which doesn't have this viral property.
True.
Oh boy... -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
"M.-A. Lemburg" <mal@lemburg.com>:
I don't see how Q can *need* any particular library P to work. The most it can need is some library with an API which is compatible with P's. So I don't buy that argument. Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
"GE" == Greg Ewing <greg@cosc.canterbury.ac.nz> writes:
GE> I don't see how Q can *need* any particular library P to GE> work. The most it can need is some library with an API which GE> is compatible with P's. So I don't buy that argument. It's been my understanding that the FSF's position on this is as follows. If the only functional implementation of the API is GPL'd software then simply writing your code against that API is tantamount to linking with that software. Their reasoning is that the clear intent of the programmer (shut up, Chad) is to combine the program with GPL code. As soon as there is a second, non-GPL implementation of the API, you're fine because while you may not distribute your program with the GPL'd software linked in, those who receive your software wouldn't be forced to combine GPL and non-GPL code. -Barry
Greg Ewing wrote:
It's the view of the FSF, AFAIK. You can't distribute an application in binary which dynamically links against libreadline (which is GPLed) on the user's machine, since even though you don't distribute libreadline the application running on the user's machine is considered the "whole" in terms of the GPL. FWIW, I don't agree with that view either, but that's probably because I'm a programmer and not a lawyer :) -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
"M" == M <mal@lemburg.com> writes:
M> It's the view of the FSF, AFAIK. You can't distribute an M> application in binary which dynamically links against M> libreadline (which is GPLed) on the user's machine, since even M> though you don't distribute libreadline the application running M> on the user's machine is considered the "whole" in terms of the M> GPL. M> FWIW, I don't agree with that view either, but that's probably M> because I'm a programmer and not a lawyer :) I'm not sure I agree with that view either, but mostly because there is a non-GPL replacement for parts of the readline API: http://www.cstr.ed.ac.uk/downloads/editline.html Don't know anything about it, so it may not be featureful enough for Python's needs, but if licensing is really a problem, it might be worth looking into. -Barry
On Fri, Dec 15, 2000 at 11:17:08AM -0500, Barry A. Warsaw wrote:
It doesn't work with the current readline module. It is much smaller than readline and works just as well in my experience. Would there be any interest in including a copy with the standard distribution? The license is quite nice (X11 type). Neil
Neil Schemenauer wrote:
+1 from here -- line editing is simply a very important part of an interactive prompt and readline is not only big, slow and full of strange surprises, but also GPLed ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
On Fri, Dec 15, 2000 at 04:03:04AM -0800, Neil Schemenauer wrote:
Definately +1 from here. Readline reminds me of the cold war, for some reason. (Actually, multiple reasons ;) I don't have time to do it myself, unfortunately, or I would. (Looking at editline has been on my TODO list for a while... :P) -- Thomas Wouters <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
[MAL]
Sorry, I got a bit carried away -- I don't want to take it up with the FSF, simply because I couldn't care less.
Well, nobody else is able to Pronounce on what the FSF believes or will do. Which tells me that you're not really interested in playing along with the FSF here after all -- which we both knew from the start anyway <wink>.
What's bugging me is that this one guy is splitting the OSS world
There are many people on the FSF bandwagon. I'm not one of them, but I can count.
RMS would not agree that both halves want the same thing; to the contrary, he's openly contemptuous of the Open Source movement -- which you also knew from the start.
[stuff about German law I won't touch with 12-foot schnitzel]
OTOH, a German FSF advocate assured me: I also tend to forget that the system of the law works different in the US as in Germany. In Germany something that most people will believe (called "common grounds") play a role in the court. So if you knew, because it is widely known what the GPL means, than it is harder to attack that in court. In the US, when something gets to court it doesn't matter at all what people believed about it. Heck, we'll let mass murderers go free if a comma was in the wrong place in a 1592 statute, or send a kid to jail for life for using crack cocaine instead of the flavor favored by stockbrokers <wink>. I hope the US is unique in that respect, but it does makes the GPL weaker here because even if *everyone* in our country believed the GPL means what RMS says it means, a US court would give that no weight in its logic-chopping.
Understood, but have you reread your question above, which I've said twice I can't make sense of? That's not what you were asking about. Your question above asks, if anything, the opposite: the *application* Q is GPL'ed, and the question above asks whether that means the *Ps* it depends on must also be GPL'ed. To the best of my ability, I've answered "NO" to that one, and "YES" to the question it appears you meant to ask.
As before, I believe the FSF will say YES. Unless there's also a non-GPL'ed implementation of the same interface that people could use just as well. See my extended mxDateTime example too.
No, you cannot. You can link them together all day without any hassle. What you cannot do is *distribute* it unless the aggregate is first placed under the GPL (or a GPL-compatible license) too. If you distribute it without taking that step, that doesn't turn it into a GPL'ed application either -- in that case you've simply (& supposedly) violated the license on P, so your distribution was simply (& supposedly) illegal. And that is in fact the end result that people who knowingly use the GPL want (granting that it appears most people who use the GPL do so unknowing of its consequences).
-- that's why e.g. the libc is distributed under the LGPL which doesn't have this viral property.
You should read RMS on why glibc is under the LGPL: http://www.fsf.org/philosophy/why-not-lgpl.html It will at least disabuse you of the notion that RMS and you are after the same thing <wink>.
Tim Peters wrote:
I know, it was backwards. Take an example: I have a program which wants to process MP3 files in some way. Now because of some stroke is luck, all Python MP3 modules out there are covered by the GPL. Now I could write an application which uses a certain interface and then tell the user to install the MP3 module separately. As Barry mentioned, this setup will cause distribution of my application to be illegal because I could have only done so by putting the application under the GPL.
:-) Let's stop this discussion and get back to those cheerful things like Christmas Bells and Santa Clause... :-) -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
Tim Peters wrote: ...
The GNU license is transitive. It automatically extends on other parts of a project, unless they are identifiable, independent developments. As soon as a couple of modules is published together, based upon one GPL-ed module, this propagates. I think this is what MAL meant? Anyway, I'd be interested to hear what the GNU forum says. ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net 14163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com
Eric S. Raymond writes:
So, gentlemen, vote for panels to go in if you think the 2.4.0 kernel will be delayed yet again :-).
Politics aside, I think development of curses-related extensions like panels and forms doesn't need to be delayed. I've posted what I think are relavant technical comments already, and leave it up to the developers of any new modules to get them written -- I don't know enough curses to offer any help there. Regardless of how the curses package is distributed and deployed, I don't see any reason to delay development in its existing location in the Python CVS repository. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Digital Creations
On Wed, Dec 13, 2000 at 05:03:59PM -0500, Eric S. Raymond wrote:
The kernel is not going to be delayed that much. Linus wants it to go out this month. Worst case, I could see January. But no way on six months. But as Fred said: that should not change panels going into the curses support at all. You can always have a "compat.py" module in CML2 that provides functionality for prior-to-2.1 releases of Python. I'd also be up for a separate _curses_panels module, loaded into the curses package. Cheers, -g -- Greg Stein, http://www.lyra.org/
Greg Stein <gstein@lyra.org>:
I know what Linus wants. That's why I'm estimating end of January or earlier Februrary -- the man's error curve on these estimates has a certain, er, *consistency* about it. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Alcohol still kills more people every year than all `illegal' drugs put together, and Prohibition only made it worse. Oppose the War On Some Drugs!
On Wed, Dec 13, 2000 at 10:19:01AM -0500, Fred L. Drake, Jr. wrote:
Panels and windows have a 1-1 association, but they're separate objects. The window.new_panel function could become just a method which takes a window as its first argument; it would only need the TypeObject for PyCursesWindow, in order to do typechecking.
Also, the curses.panel_{above,below}() wrappers need access to the list_of_panels via find_po().
The list_of_panels is used only in the curses.panel module, so it could be private to that module, since only panel-related functions care about it. I'm ambivalent about the list_of_panels. It's a linked list storing (PyWindow, PyPanel) pairs. Probably it should use a dictionary instead of implementing a little list, just to reduce the amount of code.
Consensus seemed to be to leave it in; I'd have no objection to removing it, but either course is fine with me. So, I suggest we create _curses_panel.c, which would be available as curses.panel. (A panel.py module could then add any convenience functions that are required.) Thomas, do you want to work on this, or should I? --amk
participants (13)
-
Andrew Kuchling -
barry＠digicool.com -
Christian Tismer -
Eric S. Raymond -
Fred L. Drake, Jr. -
Greg Ewing -
Greg Stein -
Guido van Rossum -
M.-A. Lemburg -
Neil Schemenauer -
Thomas Gellekum -
Thomas Wouters -
Tim Peters