[Jack Jansen]

The question I mean is that the GPL says "You shall not link against commercial libraries, unless they are part of the base OS". The second part of that sentence could be considered true for the VC6 version of MSVCRT, but not for the VC7 one. Actually, Microsoft strongly suggest you ship msvcr71.dll (or whatever the name) with the application, and not put it into /System. That appears to me to be a definite no-no for GPL software.

Python isn't released under the GPL, so what specifically are you asking about? Whether an author of a Python 2.4 derivative work targeting Windows can put their work under the GPL? I expect that's more a question of the conditions under which Microsoft licenses msvcr71.dll. They've had some goofy language in the past purporting to prevent redistribution of MS redistributables in packages under "viral" licenses. Maybe they still do. I expect that by "You shall not link ..." (which doesn't appear in the GPL), you have in mind the confusing requirements of GPL Version 2 Section 3. That exempts copiers and distributors from including full source code for "major components ... of the operating system on which the executable runs", *except* "unless that component itself accompanies the executable". Python installers have always included the MS C runtime DLLs, so there was no relief in the GPL for VC6. I suggest asking the FSF directly what they believe. Regardless of internal consistency, I expect they'll develop a rationale for saying "sure, fine". The questions really have nothing to do with Python.

On Saturday 26 June 2004 10:59 am, "Martin v. Löwis" wrote:

Jack Jansen wrote:

...

The question I mean is that the GPL says "You shall not link against commercial libraries, unless they are part of the base OS". The second part of that sentence could be considered true for the VC6 version of MSVCRT, but not for the VC7 one. Actually, Microsoft strongly suggest you ship msvcr71.dll (or whatever the name) with the application, and not put it into /System. That appears to me to be a definite no-no for GPL software.

Ah. I don't think this has been discussed before. We will definitely include msvcr71.dll with Python, and I don't see a violation of the GPL by doing so (as Python is not released under the terms of the GPL).

The potential problem would be for GPL extension modules. They could be used with Python VC6, but not with Python VC7. Are there are any GPLed modules used on Windows? Phil

On Saturday 26 June 2004 11:33 am, "Martin v. Löwis" wrote:

Phil Thompson wrote:

...

The potential problem would be for GPL extension modules. They could be used with Python VC6, but not with Python VC7.

Why is that?

Because of Jack's original point. GPL code cannot be linked against proprietary libraries unless they are part of the base system. Python itself is Ok because it's not GPL. Phil

On Saturday 26 June 2004 12:37 pm, "Martin v. Löwis" wrote:

Phil Thompson wrote:

...

Because of Jack's original point. GPL code cannot be linked against proprietary libraries unless they are part of the base system. Python itself is Ok because it's not GPL.

As Tim says, if you want to know for sure, ask the FSF for clarification.

It is not true that GPL code cannot be linked against proprietary libraries. If you have the code, you can link it against whatever you want. The GPL does not restrict your right to link the application against libraries.

The GPL only talks about distribution of things. If you include MSVCR71.DLL in your binary Python module, you would need to provide source code to MSVCR71.DLL as well. The solution is very simple: just don't ship MSVCR71.DLL with the binary Python module. It will work on the target system because Python has already installed that DLL.

Actually, it's simpler than that. From the GPL FAQ: "I'm writing a Windows application with Microsoft Visual C++ (or Visual Basic) and I will be releasing it under the GPL. Is dynamically linking my program with the Visual C++ (or Visual Basic) run-time library permitted under the GPL? Yes, because that run-time library normally accompanies the compiler or interpreter you are using." My (incorrect) understanding was that "operating system" was meant rather than "compiler or interpreter". Phil

...

...

...

...

"Tim" == Tim Peters writes:

Tim> [Phil Thompson] >> Actually, it's simpler than that. From the GPL FAQ: >> "I'm writing a Windows application with Microsoft Visual C++ >> (or Visual Basic) and I will be releasing it under the GPL. Is >> dynamically linking my program with the Visual C++ (or Visual >> Basic) run-time library permitted under the GPL? >> Yes, because that run-time library normally accompanies the >> compiler or interpreter you are using." That's weird; that kind of blanket statement simply is not compatible with the letter of the GPL. I wonder if Eben Moglen vets that FAQ. They must be assuming that the run-time library is "compiler helper" stuff, eg-but-not-limited-to code to handle long long ints and set up the C++ exception and global constructors, etc. So msvcrt should be fine. The interpretation is that this is code whose presence is mandated in one form or another by the language definition. Then it could be generated at build time by the compiler, but instead it's "pregenerated" and supplied as a library. The GPL doesn't care whether the translator is implemented via inline code generation or by library calls. In other words, if you call any functions in mscvrt directly, then you've probably got GPL issues. If you use proprietary language extensions implemented as library calls, you may have GPL issues. But if all calls are implicit in standard C code that could just as well be open-coded, or linked with cygwin.dll or libgcc1 and crt.o, no problem. >> My (incorrect) understanding was that "operating system" was >> meant rather than "compiler or interpreter". Unfortunately, not all official statements by the FSF are vetted by lawyers. Don't conclude you were incorrect until you've gotten legal advice from a lawyer with his lawyer hat on (either yours or the FSF's). However, in this case I would guess that this has nothing to do with the "operating system exception." Tim> Heh. That's what I meant by Tim> Regardless of internal consistency, I expect they'll Tim> develop a rationale for saying "sure, fine". Heh, good luck. Ask Peter Deutsch or the guys at TrollTech about that. Tim> This is why you have to ask the FSF directly about what they Tim> mean: since the meaning Of the GPL has never been clarified Tim> via court rulings, in practice it means whatever the FSF says Tim> it means, and that can't always be predicted from what the Tim> GPL actually says. The real reason for asking the FSF, of course, is that legal advice from the FSF is free-as-in-free-beer, while your lawyer will get a vacation on the Riviera for answering that question, despite being far less expert than Eben Moglen. [Aside: It's both not as bad as you suggest, and far worse than that. But that's not relevant today.] Of course, the usual dysclaimer: I ANAL. But-I'm-writing-this-to-avoid-my-real-work-ly y'rs, -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your bu

...

...

...

...

"Martin" == Martin v Löwis writes:

Martin> Stephen J. Turnbull wrote: >> They must be assuming that the run-time library is "compiler >> helper" stuff, eg-but-not-limited-to code to handle long long >> ints and set up the C++ exception and global constructors, etc. >> So msvcrt should be fine. The interpretation is that this is >> code whose presence is mandated in one form or another by the >> language definition. Martin> I think the reasoning is different: in order to run Martin> software, you need an operating system. It is ok if free Martin> software doesn't ship with its own operating system, but Martin> if users of the software already have an operating Martin> system. Likewise, it is ok if free software doesn't ship Martin> with the compiler to compile it - users who want to build Martin> the software are expected to obtain a copy of the Martin> compiler. No. I've never seen either rms or Eben Moglen admit such reasoning that I know of (of course one or both may have approved the FAQ, but I don't know that). The operating system is a _specific_ exception written into the GPL for those reasons, but that doesn't mean the logic can be extended to compilers at the licensee's option. There is never a problem with building GPL sources. You are always permitted to do that, and as far as the GPL is concerned, you may link with anything (although I've heard that some MSFT licenses prohibit the reverse). What is restricted by the GPL is _redistribution_ of the product of linking (which includes source that is "intended" to be linked). Thus, under copyright law, the binary may be a derivative of the runtime library. Determining that is a delicate matter. If you ship only source which does not depend on extensions in the runtime, your logic is correct. However, if you distribute Python binaries that require that DLL, your logic that users already have it if they're going to build Python is irrelevant. Isn't distribution of binaries, including the runtime DLL, what is being discussed here? -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.

If you include MSVCR71.DLL in your binary Python module, you would need to provide source code to MSVCR71.DLL as well.

If that's true, then it's illegal to distribute *any* GPL software compiled with VC7 -- or with any other language implementation that links in a non-open-source runtime library -- and has been for a long time. I find it hard to believe that's the intent of the GPL. There must be a lot of software out there that does this -- is it all breaking the law? 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 +--------------------------------------+