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. > 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. Point taken. > > ... > > 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. > > ... [and other "who knows?" objections] ... > > 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>. 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 > >>> 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 ? > > [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. 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.) > 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? 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. > 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. True. > > 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 ;-) > > 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. Oh boy... -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4