Which license to use for MFC based software?

Thu Jun 3 00:51:35 UTC 2004

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" <rick at linuxmafia.com>
To: <license-discuss at opensource.org>
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. (rdixon at cyberspaces.org):
>
> > 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
> rick at linuxmafia.com       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