[Mono-dev] Off topic: Reflection and Licensing question

[Michael B. Trausch]

On Wed, 29 Apr 2009 19:12:41 -0400
Miguel de Icaza <miguel at novell.com> wrote:

> Loading GPL code into a proprietary application is not allowed by the
> GPL.    You can do that in the privacy of your home, but you can not
> redistribute this configuration without infringing the license.

I am not sure what you mean by that.  Linking GPL code into a
proprietary application is certainly not permitted.  If I author a
proprietary application and I link against a library that is GPL, then
I must either retain the application in-house and never distribute it,
or I must distribute it under the GPL when I _do_ distribute it.  Since
the GPL's effects only kick in upon distribution, and not usage, this
makes sense.

Here's a couple of examples to illustrate.

Example 1:
  Let's say that I have a proprietary application, and we'll call it
  TheApplication.  (No, I am not creative; oh, well.)  TheApplication
  depends on MySQL, but the driver libraries for MySQL are GPL'd.
  Having written the application, I don't feel like keeping it in
  development for several more days/weeks/months/whatever just to write
  an adapter to the database to replace the GPL'd library.  So,
  instead, I write a "shim" and GPL this shim.  The shim exposes the
  MySQL client library's API via a named pipe and I just connect to the
  named pipe and call the client library's functions by asking the shim
  to do so for me.

Example 2:
  Let's say that I have the same proprietary application,
  TheApplication.  However, I say, "I will not write the database
  functionality.  I will leave this up to you to provide.  Here is the
  interface that I expect to be able to use, you give me the file, I
  will load it, and I will use its interfaces."  So, John Doe decides
  that he needs to use this application with MySQL, and creates a GPL'd
  module for this application program which enables the proprietary
  software to work with MySQL.  He then distributes his work under the
  GPL, because he likes freedom.  He doesn't have the time to write
  a clone of TheApplication, so this is the best he can do.

In example 1, I as the application developer have intentionally and
deviously attempted to get out of my responsibility to release my code
under the GPL by creating a wrapper, to separate the MySQL client
library from my program by intentionally placing the library in a
different address space.  This is wrong.  It goes exactly against what
the GPL tries to do with regards to liberating software.  Basically, I
have said, "Nah-nah-nah-boo-boo, stick your head in doo-doo," and taken
free software and used it improperly.  This isn't cool.

In example 2, however, I decide instead that it's not a good idea for
me to try to support eleventy-one databases directly; I cannot
anticipate my end-user's needs.  So instead, I say, "Here is the
application software.  If your needs are simple, you can use SQLite,
which I have written a module for, and is in the public domain.  If you
need to support another database in your environment, that's up to
you.  Here are the interfaces that I will use in a module."  John Doe
does just that.  It doesn't _matter_ what license someone writes a
module for, that module isn't a derived work, and it's not linked into
my program.  It's distributed by someone else as a completely separate
work.  John Doe did just that, and he should be commended for choosing
the GPL for the module that he wrote.  This is just fine.  It's less
than ideal (at least in my opinion, as I believe that all software
should be free software in the manner in which the FSF has defined it),
but TheApplication doesn't try to do anything nasty or uncool, and John
Doe has provided a very useful and free software module that people are
free to improve upon and redistribute (separately, of course, from the
application, for obvious reasons).

The line between the two examples is indeed a fine one.  However,
interface usage does not constitute linking.  Dependencies do.

As has already been mentioned elsewhere in this thread, if mechanisms
like LoadLibrary() or dlopen() or Java or CLR Reflection were
considered linking, the ramifications would be very troublesome and
dangerous for those who did write proprietary software.  So much so
that they would choose either to not write it at all, or make it free
software in the first place.

Let's not forget that the GPL does not apply to usage.  It _only_
applies to distribution.  If I write a free software module for a
proprietary program and distribute it, I have in no way violated GPL.
What the GPL covers is not determined by whether or not code lives in a
single address space.  It is determined at build time for the program
in question.  If you statically link against a GPL'd component, then
you must also be GPL by definition.  If you dynamically link against a
GPL'd component, there is no difference from static linking other than
a technical one.  Dynamic linking was designed to reduce memory and
storage requirements since many programs use the same libraries.
However, dlopen() and LoadLibrary()'s usage isn't linking.  It's
declaring a dependency on an interface, not a library.  Reflection is
functionally equivalent to using dlopen() and/or LoadLibrary(), but
significantly more powerful due to the technical nature of the CLR.
And even so, if there were an agreed-upon convention that made it
possible to preserve metadata in native executables, then we'd have
reflection at a native level, which still wouldn't be linking.

	--- Mike

-- 
Unix is user friendly - it's just picky about it's friends.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090430/00e873ca/attachment-0001.bin