[Mono-devel-list] ByteFX development

Jonathan Pryor jonpryor at vt.edu
Tue Sep 21 21:11:42 EDT 2004


On Tue, 2004-09-21 at 07:45, Joshua Tauberer wrote:
> Jonathan Pryor wrote:
> > On Mon, 2004-09-20 at 18:48, Michael L Torrie wrote:
> > 
> >>On Mon, 2004-09-20 at 15:29 -0700, Michael J. Ryan wrote:
> >>
> >>>Okay, but if my code only accesses ByteFx's dll, and doesn't embed
> >>>any code from it, I am safe (commercially) from it, correct?

Just to answer this, NO, you're not safe if you "only" access ByteFx's
Dll.  Not as long as ByteFx's DLL is GPL.  See below for a (hopefully
good) explanation.

> >>If the DLL is LGPL, then yes you can link a non-GPL, non-LGPL program
> >>against it.
> >>
> > Just to clarify this, the term "link" really isn't a useful term.
> > 
> > The *real* question is this: is the GPL'd code in your address space? 

I really need to avoid over-simplifying things.  It's less help than I
think it is... :-/

I've tried to clarify things below, though I've probably botched that up
as well...

> I think the reasoning behind this is that when you reference an 
> assembly, some metadata about the assembly ends up in your program. 
> That metadata is derived from the original work, and thus protected 
> under copyright law, and so you've now got limitations.

Yes, and no.  The metadata is sufficiently small (assembly name,
version, public key, referenced classes, etc.) that it could probably be
declared "fair use".  I wish I could find a good URL to back that up,
but all I have is the memory (from several years ago) stating that you
could use "small" portions of a GPL'd program's header files (such as
constants and small macros) within a proprietary program because of fair
use.  It also mentioned that the meaning of "small" was also up for
debate, so this shouldn't be pushed, but it would work for trivial
things (symbolic constants via #define, etc.).

Thus, I need to provide a more thorough reason for why a GPL'd ByteFX
assembly can't be used within your proprietary program.

Again, I'm not a lawyer (but I've read far too much).

	http://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL

First, remember that the mono program itself is GPL.  Why is it OK for
your proprietary program to be executed by mono?  Because mono is an
interpreter, and your program is "just data".  You feed mono an
assembly, and it JIT's it and executes it.  Period.

We can dig deeper, and realize that mono is actually JITting the code,
optimizing it, implementing exception handling, reflection, remoting,
and a host of other nice things.  But these things are implemented by
the LGPL libmono.so library (JIT, etc.) or the MIT/X11 runtime library. 
Your program *never* uses the GPL'd facilities of mono or mint (as these
are primarily "front-ends" to libmono.so, initializing the program so
things can get started).

When does an GPL'd interpreter start requiring that the programs be
GPL'd as well?  When the interpreter provides "bindings" to GPL'd
facilities (libraries, etc.).  This isn't the case for Mono, but it *is*
the case with ByteFX -- it provides GPL'd facilities that your program
relies on, the facilities of MySQL communication.

So, to simplify (is that safe?), your program must be GPL'd if it
directly or indirectly relies upon GPL'd facilities, *unless* it's "just
data" for those facilities.  The definition of "just data" is beyond the
scope of my addled brain, beyond my stipulation that your .NET programs
are "just data" to mono.

With that, I finish with my disclaimer (found somewhere online; I wish I
could properly attribute the original author):

        Disclaimer: Any resemblance between the above views and those of
        my employer, my terminal, or the view out my window are purely
        coincidental. Any resemblance between the above and my own views
        is non-deterministic. The question of the existence of views in
        the absence of anyone to hold them is left as an exercise for
        the reader.  The question of the existence of the reader is left
        as an exercise for the second god coefficient. (A discussion of
        non-orthogonal, non-integral polytheism is beyond the scope of
        this article.)

 - Jon





More information about the Mono-devel-list mailing list