Which license to use for MFC based software?

[Rick Moen]

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