Thanks for the summary, Rick. This is definitely a serious matter, if it turns away developers from open source. I still think Carsten may be able to accomplish his goals.
The problem identified sounds less like a legal issue than it does a potential programmer's nightmare. The visual basic (or Visual C++) runtimes are likely to be distributed by Microsoft as part of the operating system. The lack of runtime distribution for programs made with Microsoft's visual tools was a problem with older versions of the OS, but I believe they have overcome this issue with Windows 2000 and XP, which probably have all the libraries needed for a typical app. to dynamically access a procedure in a shared library. As for the licensing issue, since Microsoft can only control the distribution of its copyright protected works, there should not be a problem with dynamic linking an open source work created in a popular visual language. As someone else suggested, if Microsoft's copyright protected libraries somehow provide a real stumbling block, there may be other shared libraries that constitute good substitutes. I am assuming that Carsten bought a Microsoft IDE in some visual language, and in exchange Microsoft granted a royalty-free license for distribution of shared libraries. Aside from the above, I must admit that it would be terrible to suggest that one may need to consult a lawyer to parse the software license(s) that may accompany Microsoft's tools, but it does sound as if there may be terms its licenses intending to bind end-users that are barely beyond nonsense. I am not sure what the end-user has obtained in exchange for all of the additional conditions cited by a previous post. - Rod ----- Original Message ----- From: "Rick Moen" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, June 02, 2004 7:06 PM Subject: Re: Which license to use for MFC based software? > Quoting Rod Dixon, J.D., LL.M. ([EMAIL PROTECTED]): > > > Forgive me, if I am responding to the wrong question. The thread to this > > discussion is a little hard to follow. > > Indeed, and I'll attempt to remedy that, below. > > > The answer is yes, if the question is strictly analyzed as a copyright > > question involving copyright law in the U.S. It is important to > > remember that whether dynamic linking to a shared library somehow > > creates a derivative work is a question of copyright law, not the > > interpretation of a software license. Since the GPL does not reach > > modifications that do not constitute derivate works (recall that the > > GPL is supposed to be a copyright license, not a contract), the > > Copyright Act applies in the first instance. In that regard, section > > 117(a)(1) may apply; that section ostensibly would permit an end-user, > > the lawful owner of a COPY of the copyright-protected program, to run > > an open source program that calls a run-time distributed by OS > > developer like Microsoft. Even if an open source program made a highly > > unpredictable call to a shared library during run-time and one could > > persuasively argue that in that instance the dynamic linking, itself, > > created a modified work, section 117(a)(1) would seem to render the > > "adaptation" permissible as a matter of Copyright law. > > I just consulted the archive copy of Carsten Kuckuk's original post: > He mentioned his understanding that Microsoft's MFC toolkit may not > be used to create GPL codebases, and asked what alternative licensing > regime he might use comes closest to the GNU GPL without running afoul > of Microsoft Corporation's prohibitions. > > Several posts then ensued, reflecting different guesses about what > specific impediment Carsten is worried about. Nick Moffitt posted a > well-worded explanation of how to use non-GPLed libraries in otherwise > GPLed works -- reflecting Nick's surmise that Carsten had in mind MFC > libraries' licence-compatibility problem. > > Then, I posted, because I recalled a news item from two years ago, that > Microsoft had begun inserting in its SDK EULA language a clause banning > the SDKs' use in (1) developing copylefted code, or (2) distributing > their components (such as runtime libraries) in conjunction with > copylefted code. > > So, essentially, I was saying that Carsten's recollection (that > Microsoft's MFC toolkit may not be used to create GPL codebases) may > _indeed_ be correct, and that he should check its EULA for language > similar to what I cited. (I also pointed out that that EULA language > does its best to sabotage development using _all_ forms of copyleft.) > > Carsten clarified in a follow-up that he's speaking of development under > either Microsoft Visual C++ or Microsoft Visual BASIC -- so he should > indeed be concerned about the licensing of those toolkits' respective > runtime libraries, as well as of their developer-use portions. > > (In a further follow-up, he detailed sundry restrictions in the terms of > use for Visual Studio 6.0 and Visual Studio.NET 2003. And Evan pointed > out the real solution -- open source.) > > Carsten wrote: > > > I read the GPL years ago, and did not remember the fine points well, > > so I was under the impression that the MFC could be a roadblock here. > > Nick and the GPL FAQ make it appear as if this is not a problem. > > Carsten, you're confusing two issues: (1) If you were to issue your > creation under GPL without additional clauses, the result would be a > derivative work (your GPLed code plus Microsoft runtime libraries) that > third parties could not lawfully redistribute: Doing so would violate > your copyright by contravening your required conditions that recipients > must agree to honour (GNU GPL). (2) Microsoft Corporation have > introduced additional impediments in their _runtime libraries'_ licence > terms, not to mention some of the company's development tools. > > Nick (and the GPL FAQ) explain how you, as copyright owner of your > codebase, can remedy problem #1: You attach a licence exception, > allowing use under GPL terms with the additional proviso that users may > link your code with this-or-that Microsoft runtime library. > > That does nothing to address problem #2 (the one I spoke of), in cases > where Micrsoft's licence terms are particularly heinous. To find out > whether a problem exists in your particular situation, read the licence > and find out. > > Yes, skirting that problem by switching to an open-source toolchain does > impose a new and regrettable learning curve. Sorry about that. At some > point in the future, we of the open source movement hope to be able to > cheerfully refund your wasted time. ;-> > > -- > Cheers, "Learning Java has been a slow and tortuous process for me. Every > Rick Moen few minutes, I start screaming 'No, you fools!' and have to go > [EMAIL PROTECTED] read something from _Structure and Interpretation of > Computer Programs_ to de-stress." -- The Cube, www.forum3000.org > -- > license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3 > -- license-discuss archive is at http://crynwr.com/cgi-bin/ezmlm-cgi?3
